Unclear documentation/behavior regarding the use of context

When I proposed PR #576, I had some uncertainty about how Preact handles context. Currently, the TypeScript declarations do provide for context?: any in a few locations, so I just followed that convention. That said, it looks like Preact does not(?) support -- or at least make use of -- contextTypes. I searched the documentation and the source to learn more about this, and so far have two issues (that I'll file here as one issue):

I couldn't find anything in the documentation about whether Preact actually does make use of contextTypes. I'm assuming that it doesn't, since it doesn't make use of propTypes. My impression from the source is also that it does not. I think this should probably be documented somewhere (I'm happy to PR it; just want to check that I'm right and that I didn't actually miss some documentation, first).

Also, from looking at the source, it looks like Preact's behavior with respect to context may not be exactly the same as React's. Is this intended? As I understand it, in React, if a component does not define some context on contextTypes, then the component does not receive that context (see here, for example: https://github.com/facebook/react/blob/e452e3374135c116ef687a8bb3a5d277e3cde8fb/src/isomorphic/classic/tests/ReactContextValidator-test.js#L40). But if Preact doesn't use contextTypes at all, then it presumably doesn't have this behavior. Is that right, and is it intended? This might create some subtle issues with migrations from React to Preact, especially if (as in point 1 above) it isn't documented anywhere, so I wanted to check.

Mostly, I'm looking for clarification on these things and seeing whether it would be helpful for me to try to PR some docs and/or some changes to the treatment of context. Thanks!

Both absolutely correct!  The decision to automatically pass context down rather than relying on contextTypes comes from the size constraints placed on Preact.  Since context is an undocumented/hidden (less-documented) API in React, the change has never caused much trouble that I'm aware of.
Definitely lacking in the documentation, though part of that comes from the docs needing to walk a fine line between catering to React devs (who would understand contextTypes) and web devs approach Preact without having written React (who would be fine knowing "context is automatically passed down").  However we can document this such that is explains things to both groups of people would be awesome.  Definitely open to PRs for docs, you seem to be a very good writer!
That said, having preact-compat inject context mutation that does mirror the subscription behavior of React is an issue I've had on the backburner for a while now. I don't think there's a Github issue set up for it, so we might want to open one in preact-compat.  That seems like the type of thing people would submit a PR for (preact-compat is mostly community maintained at this point, which is awesome).

Cool, and thanks for the quick response! That all sounds good. I'll try to take a look at the docs as time permits.

Hi guys, I'm interested in getting started as a contributor and would love to take a shot at this.

@paulsevere I'd say go for it! The "help wanted" label is attached, and I'm not expecting that I will have a lot of time to do this myself any time soon (despite reporting the issue).

We added a section about context starting with Preact X in our docs: https://preactjs.com/guide/v10/context


Fix the a11y addon

@storybook/addon-a11y error
a11yRunner.js:10 Uncaught SyntaxError: The requested module '/@fs/Users/zander/code/my/project/node_modules/@storybook/addon-a11y/node_modules/axe-core/axe.js?v=ad04bc2d' does not provide an export named 'default'

Originally posted by @mrmartineau in https://github.com/eirslett/storybook-builder-vite/issues/4#issuecomment-822373486

Btw., any idea on where this might originate? Would be willing to try my hands on this!
The one addon we're actually really missing right now :)

It could be related to cjs/esm module issues. Maybe it's including axe.js directly instead of including axe-core?

I hit a few dozen similar cases where I needed to add sub-dependencies to my optimizeDeps.include in viteFinal(config).  I think this is likely due to https://github.com/vitejs/vite/issues/3024.  Hopefully the issue will resolve itself when vite behaves correctly, but for now, we're stuck with big optimizeDeps.include lists I think.

@julrich are you able to get addon-a11y working with the new 0.0.7 version of this builder (and with specifying it in your optimizeDeps.include)?

Will give it a try! Last time I tried I just gave up, because it seemed really tedious.
Do you have some example you could link / paste on how it's done some othrr place, maybe?

I haven't quite cleaned this up all the way, but here's the viteFinal that I ended up with in my own project.  You may not need all of it, but hopefully it's a start:
async viteFinal(config) {
    const mergedConfig = {
      ...config,
      // Use the standard cache dir, to make it easy to clear
      cacheDir: path.resolve(__dirname, '../node_modules/.vite'),
      optimizeDeps: {
        // This is relative to the root, which is buried in node_modules.
        entries: ['../../../**/*.stories.tsx'],
        include: [
          'axe-core',
          'acorn-jsx',
          '@mdx-js/react',
          '@storybook/addon-actions',
          '@storybook/addon-docs',
          '@storybook/addon-docs/blocks',
          '@storybook/addons',
          '@storybook/client-api',
          '@storybook/client-logger',
          '@storybook/csf',
          '@storybook/react',
          '@storybook/testing-react',
          'classnames',
          'deep-object-diff',
          'doctrine',
          'escodegen',
          'fast-deep-equal',
          'global',
          'hoist-non-react-statics',
          'html-tags',
          'lodash/cloneDeep',
          'lodash/isFunction',
          'lodash/isPlainObject',
          'lodash/isString',
          'lodash/mapValues',
          'lodash/pickBy',
          'lodash/uniq',
          'memoizerific',
          'prop-types',
          'storybook-dark-mode',
          'ts-dedent',
          'qs',
          'util-deprecate',
          'uuid-browser/v4',
        ],
      },
    };

Great, thanks a lot. Will report back 🙏

Not really sure how and why, but updating to storybook-builder-vite version 0.0.8, updating to Storybook 6.3.0-rc.4 and re-adding @storybook/addon-a11y my problems in dev mode have gone away completely (pretty sure the "production" build  was already working before).
I did not have to add anything to my viteFinal for this to work!
I had a quick look at the last a11y-changes, and it seems like this could've been related:
https://github.com/storybookjs/storybook/commit/04acc44510fc189003e643c3262e1db46275f859
But pretty sure it wasn't working on some alpha-release for us in the past, and that PR was already part of those.
Any idea, how that could've fixed itself (at least from my limited perspective :D)?
Does it work for you without those viteFinal includes, @IanVS?

I added axe-core to the optimizeDeps list, that could have helped?

Maybe the combination of those to did it?

https://github.com/eirslett/storybook-builder-vite/commit/eda3b5afbebe6156776e7b99603d56510b977f05
https://github.com/eirslett/storybook-builder-vite/commit/f8d84c824384aba7dcab2cf4a1563f6e3556dec0

Maybe @IanVS can confirm if his own project works without those in viteFinal, too!

Cool, I was able to simplify my config greatly:
async viteFinal(config) {
  return {
    ...config,
    // Use our standard cache dir, to make it easy to clear
    cacheDir: path.resolve(__dirname, '../node_modules/.cache/vite'),
    optimizeDeps: {
      ...config.optimizeDeps,
      // Entries are specified relative to the root
      entries: [`${path.relative(config.root, path.resolve(__dirname, '../src'))}/**/*.stories.tsx`],
      include: [...config.optimizeDeps.include, 'storybook-dark-mode'],
    },
  };
},

I'll close out the issue, but let us know if you have any other trouble.  Glad it seems to be working for you now.


Multiple post install commands with "do"

What?
I have a usecase where as part of installing coc.nvim through Plug, I want to specify multiple dependencies to be installed which are:

:CocInstall <bunch of plugins>
!brew install watchman
I'm unsure in terms of how to do that as do only support providing a single command.

Minimal config
call plug#begin('~/.vim/plugged')
Plug 'neoclide/coc.nvim', {'branch': 'release', 'do': ':CocInstall coc-tsserver coc-json coc-css coc-html coc-pyright coc-styled-components'}
" I want to add 'brew install watchman' as a dependency when coc.nvim is installed
call plug#end()

:version
NVIM v0.7.0
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by<EMAIL_ADDRESS>

Type:

[ ] Bug
[x] Enhancement
[x] Feature Request
[x] Question

OS:

[ ] All/Other
[ ] Linux
[x] macOS
[ ] Windows

Vim:

[ ] Terminal Vim
[ ] GVim
[x] Neovim

coc.nvim, there is a variable called g:coc_global_extensions, and you can use that variable to automatically install LS.
so, you can write only brew install watchman to do of vim-plug

You can specify a function as the post-update hook.
See https://github.com/junegunn/vim-plug/issues/944

Ah thanks, this worked! Thanks!
This is what I used for the above usecase:
" How post update hook works
" https://github.com/junegunn/vim-plug/blob/master/README.md#post-update-hooks
function! PostInstallCocNvim(info)
  if a:info.status == 'installed' || a:info.force
    !brew install watchman
    CocInstall coc-tsserver  "... other plugins
  endif
endfunction

Plug 'neoclide/coc.nvim', {'branch': 'release', 'do': function('PostInstallCocNvim') }


Float texture receiver not working with negative values

I'm sending a texture in RG_32F format.
It appears to be coming in correctly in both the Spout Receiver example and Touch Designer, but not in Unity. The Unity receiver looks like it's flipping the negative values to always be positive. I am setting up my render texture with format R32G32B32A32_SFLOAT.

I think it's a bug, but please advise if you have any suggestions for fixing it. Thanks!

It's one of the limitations of the current implementation; The texture format is hardcoded as ARGB32.
If you need a workaround, try modifying the following lines.
https://github.com/keijiro/KlakSpout/blob/master/Assets/Klak/Spout/Runtime/SpoutReceiver.cs#L139
https://github.com/keijiro/KlakSpout/blob/master/Extras/KlakSpoutPlugin/KlakSpout/KlakSpoutSharedObject.h#L127

Ok, thanks for this!
I added an editable field for the TextureFormat and that seems to work. If I have a bit more bandwidth, I'll clean it up and try to get the format from the incoming texture raw pointer and send a PR.

I'm streaming points clouds from touchdesigner to unity. NDI has no support for floats, so I tested a way with spout. Besides of the texture format issue, I had to disable the gamma lut in "Blit.shader" to fix distortion of 3d positions:
        //#if !defined(UNITY_COLORSPACE_GAMMA)
        //col.rgb = GammaToLinearSpace(col.rgb);
        //#endif

I created a new TODO issue: #71
I close this issue for now. Please follow the new issue if you're still interested in it.


Migrating Question.

Following the, Migrating towards jsonapi-server from ExpressJS,  I have a mock up of some resources and I am curious how I can access the "main" express application. Specifically I have Express & JWT working using https://github.com/auth0/express-jwt which sets req.user for me. For migrating I was hopeful that my new routes could go through my existing middleware stack app.use() functions and I could get access to the req.user value.
Any help is appreciated. I tried playing around with jsonApi.getExpressServer() but did not have much luck.
If not, is there a sample on how/where to validate and use a JWT?
Thanks!

Hi @thejones. Apologies for the late reply. Is this something you're still looking into? I should have time this weekend to investigate this for you.


chore: remove mention of "MSP" from org names

Description

How has this been tested?

Checklist

[ ] changelog was updated with notable changes
[ ] documentation was updated

/e2e --help

/e2e --refs substra-backend=chore/no-msp
Not sure distributed will work

End to end tests: :hourglass_flowing_sand: STARTING


Adding Code Louisville group and icon

Getting Code Louisville's first meetup event on the calendar....hopefully

LGTM! 👍
@ericlathrop ok to merge?


Disallow blank submissions

Describe the bug
The form should not be accepting content like this:
This is an automated message indicating a new speaker nomination:

Time: 2020-09-01T08:04:28.000Z
Name: /
Email:
Company:
Bio:
Submitted by:
Submitter Email:

To Reproduce
Steps to reproduce the behavior:

Go to https://speakher.jp/nominate-speaker
Fill out the form... more investigation needed, because I can't get this to validate.
Check the Airtable for a mostly-blank row

Expected behavior
We shouldn't allow invalid, blank submissions
Additional context
Add any other context about the problem here.

So I could reproduce this. If you check the network tab while sending in the form, both the database ID and the token are visible. (Don't want to create some test entry on production so I didn't check there, this is on my local)
I then copy pasted all of that into Postman, copy pasted the request body, set all fields to empty and I could create an entry with all fields empty.
I saw you want to add a backend for airtable access already, so maybe it should be prioritized? :)

Yes we are aware of that in #15. Thanks for the helpful reproduction notes!

oh sorry I missed that issue somehow 😅  I can help with setting up a backend if necessary :)


Incorrect num parsing

Hi, thanks for this great package. It's been very helpful for my project.
I encountered an issue with parsing num on version 1.5.6
It generates
sellingPrice: json['selling_price'] != null ? num.parse(json['selling_price']) : 0,

Which results in errors like
Unhandled Exception: type 'double' is not a subtype of type 'String'
Unhandled Exception: type 'int' is not a subtype of type 'String'
So to fix it I added toString() after the json[key]:
sellingPrice: json['selling_price'] != null ? num.parse(json['selling_price'].toString()) : 0,

I'm guessing the problem is somewhere in this line https://github.com/mmvergara/supadart/blob/f2d03975d325c5a833f5b33e20ab2352ddf4f6e1/cli/lib/generators/class/from_json.dart#L59

@damywise should be fix. please update your cli to 1.5.7  https://github.com/mmvergara/supadart/pull/68
please let me know if you're still having problems, thanks again

Can confirm it's fixed thanks


Set up necessary custom vocabularies for Invenio fields

How will we align creator roles with Datacite, since Datacite doesn't have that field?

Custom vocabularies needed for

creator and contributor roles
resource types
???


Replace deprecated gethostbyname by getaddrinfo

try to resolve: #3683

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#3685
@topazus
@tzanio
@sebastiangrimberg + @v-dobrev + @tzanio
6/11/23
11/9/23
11/12/23

PR Checklist

[ ] Code builds.
[ ] Code passes make style.
[ ] Update CHANGELOG:

[ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
[ ] Does it make sense to create a new section in the CHANGELOG to group with other related features?

[ ] Update INSTALL:

[ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
[ ] Have the version ranges for any required or optional libraries changed?
[ ] Does make or cmake have a new target?
[ ] Did the requirements or the installation process change? (rare)

[ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)

[ ] .github
[ ] .appveyor.yml

[ ] Update .gitignore:

[ ] Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
[ ] Add new patterns (just for the new files above) and re-run the above test.

[ ] New examples:

[ ] All sample runs at the top of the example source file work.
[ ] Update examples/makefile:

[ ] Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
[ ] Add any files generated by it to the clean target.
[ ] Add the example binary and any files generated by it to the top-level .gitignore file.

[ ] Update examples/CMakeLists.txt:

[ ] Add the example code to the ALL_EXE_SRCS variable.
[ ] Make sure THIS_TEST_OPTIONS is set correctly for the new example.

[ ] List the new example in doc/CodeDocumentation.dox.
[ ] If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add example-specific documentation, see e.g. the src/examples.md.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] In examples.md, list the example under the appropriate categories, add new categories if necessary.
[ ] Add a short description of the example in the "Extensive Examples" section of features.md.

[ ] New miniapps:

[ ] All sample runs at the top of the miniapp source file work.
[ ] Update top-level makefile and makefile in corresponding miniapp directory.
[ ] Add the miniapp binary and any files generated by it to the top-level .gitignore file.
[ ] Update CMake build system:

[ ] Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
[ ] Add/update the CMakeLists.txt file in the new miniapp directory.
[ ] Consider adding a new test for the new miniapp.

[ ] List the new miniapp in doc/CodeDocumentation.dox
[ ] If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
[ ] If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
[ ] Add a short description of the miniapp in the "Extensive Examples" section of features.md.

[ ] New capability:

[ ] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
[ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
[ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
[ ] Consider adding new sample runs in existing examples to highlight the new capability.
[ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
[ ] If this is a major new feature, consider mentioning it in the short summary inside README (rare).
[ ] List major new classes in doc/CodeDocumentation.dox (rare).

[ ] Update this checklist, if the new pull request affects it.
[ ] Run make unittest to make sure all unit tests pass.
[ ] Run the tests in tests/scripts.
[ ] (LLNL only) After merging:

[ ] Update internal tests to include the new features.

Refs:

POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html
WIN32: https://learn.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfo

@v-dobrev Thanks for the posting links. Can you review on this?

@v-dobrev Thanks for the posting links. Can you review on this?

I'll add the ready-for-review label -- this will start the review process.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

Merged in next for testing...

I'm having issues with GLVis (on a Mac with M2 chip) after this was merged.
Did anyone test (on any platform) running examples with GLVis visualization with this PR?

I am seeing the same issue as @sebastiangrimberg (M1 Max)

Old macs also don't connect to GLVis.

Wow, sorry about this guys... @topazus can you confirm you can address this?

It seems that hints.ai_flags needs to be specified on my computer Fedora Linux (Gnome on Xorg).
diff --git a/general/socketstream.cpp b/general/socketstream.cpp
index 28ea0d27c..fdaf8a8ae 100644
--- a/general/socketstream.cpp
+++ b/general/socketstream.cpp
@@ -106,9 +106,11 @@ int socketbuf::open(const char hostname[], int port)

    hints.ai_family = AF_UNSPEC;
    hints.ai_socktype = SOCK_STREAM;
+   hints.ai_flags = 0;
    hints.ai_protocol = 0;

-   int s = getaddrinfo(hostname, NULL, &hints, &res);
+   std::string portStr = std::to_string(port);
+   int s = getaddrinfo(hostname, portStr.c_str(), &hints, &res);
    if (s != 0)
    {
       socket_descriptor = -3;
@@ -142,6 +144,7 @@ int socketbuf::open(const char hostname[], int port)
          socket_descriptor = -2;
          continue;
       }
+      break;
    }

    freeaddrinfo(res);

I doubt that Xorg and Wayland differences are caused by how you initialize sockets.

Should it include the second patch as well?


Fullscreen broken on X11 with HiDPI

Repro:

Set display DPI to something other than 96:
echo Xft.dpi: 144 | xrdb -merge
Run examples/windowsize
Press F

Observe that a large part of the screen is cut off (see screenshots).

Note how Xft.dpi does not influence the Device Scale Factor, but it does change the initial window size and causes this weird fullscreen scale up.
Reproduced on:

X11/i3
Wayland/Sway/Xwayland

Does NOT reproduce on:

Cinnamon

Most likely because ebiten has its own support for querying device scale that is specific to Cinnamon and GNOME, while not supporting anything else; at the same time, glfw has its different support and these two disagree.
Maybe we should just always use glfw's content scale?
Note though:
// deviceScaleFactor() is a scale by desktop environment (e.g., Cinnamon), while GetContentScale() is X's scale.

I do not quite understand this - when do these two ever differ, except when there simply is no desktop environment managing this at all? In fact, do we ever handle the case of these two differing right?

Yeah, so this means that we have to support i3 and the other desktop environments at deviceScaleFactor.

I do not quite understand this - when do these two ever differ, except when there simply is no desktop environment managing this at all? In fact, do we ever handle the case of these two differing right?

 Ebiten tries to follow the former to make the window size more natural to users.
I'm not familiar with X's scalings but IIUC, if X is in HiDPI mode, everything is small unless the desktop environment specifies a scale. In your case, doesn't i3 have a scale like 200%?

Generally there are two places where X tracks scale:

Physical size of the monitor (usually rather unused)
Font sizing (this is what Xft.dpi does)

i3 does not really care about anything else, and all X11 window sizes are measured in actual device pixels.

Having said that, in the specific case of fullscreen mode, all this should not matter. The texture should just be rendered from screen corner to corner (with potential letterboxing), so the only influence scale factors should have there is in the arguments to Layout().
While at it - should a game that returns w, h from Layout(w, h) be assumed to have a screen in device pixels (so all scaling is done by the game) or device independent pixels (so ebiten scales)? It seems based on the implementation that the latter is the case - which means a game that wants to avoid all scaling needs to return wdeviceScaleFactor, hdeviceScaleFactor.
So assuming that this is how Layout() works, it gets device independent pixel size of the window/screen as input and returns the intended texture size in "raw" pixels as output.
Now the current impl calls Layout() on toFramebufferPixel(fromGLFWMonitorPixel(videoModeSize, deviceScaleFactor)) or toFramebufferPixel(fromGLFWPixel(windowSize)).
Expanding these terms, we actually pass videoModeSize/deviceScaleFactorcontentScale/deviceScaleFactor in the former case (VERY WEIRD), and windowSize/contentScalecontentScale/deviceScaleFactor (device independent pixels, assuming windowSize is truly the raw window size in physical pixels) in the latter case.
Sadly I don't know what kind of scaling GLFW itself applies.

Hm.
On Windows, the conversions are:

fromGLFWMonitorPixel is /deviceScale
fromGLFPixel is /deviceScaleFactor
toGLFWPixel is *deviceScaleFactor
toFramebufferPixel is the identity

Assuming this, Layout() gets called on videoModeSize/deviceScale or windowSize/deviceScaleFactor, respectively. Not sure why window and fullscreen mode sizes would be measured in different units, but maybe that's just the reality - don't know. Or actually... it just LOOKS that way, as on Windows deviceScale and u.deviceScaleFactor() are always the same.
Generally it'd help if these functions were clearer named, to indicate what units they expect on the respective "other end". Like, what kind of pixel is toFramebufferPixel converting from?

Hmm, that's interesting. I'm not sure what is the best solution so far. I'd like to understand Linux's desktop environments more.

Font sizing (this is what Xft.dpi does)

If this value changes to like 72, is the fullscreen scale's result affected?

While at it - should a game that returns w, h from Layout(w, h) be assumed to have a screen in device pixels (so all scaling is done by the game) or device independent pixels (so ebiten scales)? It seems based on the implementation that the latter is the case - which means a game that wants to avoid all scaling needs to return wdeviceScaleFactor, hdeviceScaleFactor.

Yes this is correct and intended. And your comments following this seem correct.

Generally it'd help if these functions were clearer named, to indicate what units they expect on the respective "other end". Like, what kind of pixel is toFramebufferPixel converting from?

Yeah right, sorry for confusion. All the 'from' functions convert from a device-independent unit to something, and 'to' functions convert to a device-independent unit from something. I'll rename this.

Trying to use other conversions as a "proxy" to find a chain that should be the identity.

Mouse position handling: window.GetCursorPos() (physical pixel) -> fromGLFWMonitorPixel(., deviceScaleFactor) -> AdjustPosition(multiplies with deviceScaleFactor, divides by screenScale)
Drawing: multiply by screenScale to get from texture pixel to physical pixel

This suggests that the combination of all these conversions should always be the identity.
Thus, fromGLFWMonitorPixel . (* deviceScaleFactor) . (/ screenScale) . (* screenScale) must be the identity, so fromGLFWMonitorPixel can always just divide by deviceScaleFactor.
Let's see if I can find more such relations to solve this.

By naming, toFramebufferPixel sounds like it must be the exact inverse of fromGLFWMonitorPixel; however then we call Layout() wrong. It seems like to call Layout correctly, toFramebufferPixel must be the identity in ui_unix too.
However, just changing that breaks windowed mode for me - it now is "letterboxed". So this isn't all.
One thing that does work is making toFramebufferPixel the identity and using deviceScaleFactor in all three functions. It does not seem to make sense to me that GLFW would use different units for monitor pixels and window pixels, although maybe it does? This would be "happy" on my system - it'd then entirely ignore Xft.dpi and just use the Cinnamon or GNOME provided data when in those, and 1.0 otherwise.

FYI: I found a comment of an investigation: https://github.com/hajimehoshi/ebiten/issues/1307#issuecomment-694393662

I cannot yet confirm that GLFW ever returns a scaled monitor size.
However there are some interesting tidbits in GLFW source:

Content scale is applied to window sizes when wndconfig->scaleToMonitor is set. Do we set that?
Otherwise GLFW appears to nowhere ever use the content scale.

What I did:

Search for contentScaleX, contentScaleY.
Used only where it's computed, and:

_glfwPlatformGetMonitorContentScale

Only called from glfwGetMonitorContentScale

Only exported API + called from tests

_glfwPlatformGetWindowContentScale

Only called from glfwGetWindowContentScale

Only exported API + called from tests

inside createNativeWindow if wndconfig->scaleToMonitor is set

So if we make sure scaleToMonitor is off, then GLFW's scaling is nowhere used on X11. Didn't also track this down for Windows and OS X though.

Another way to verify this independently: with my proposed change - never using GLFW's scale, always ebiten's - things work fine. If I then mess around with Xft.dpi, nothing at all changes. That seems a pretty strong sign that after my changes, GLFW's own scaling stops mattering.
Now for trying the same out in Cinnamon...

Tried a bit more - and found a case that breaks with my changes.
To break it, you need to set up a fractional device scale in Cinnamon (like 150%).
The regular normal/HiDPI setting does NOT break.
So let's see what that setting even does...

In the with my changes failing, without working, Cinnamon configuration, we indeed have deviceScaleFactor=1.500023 (seems to come from Xft.dpi: 192) and ContentScale=2 (seems to indicate the screen is 2x upscaled). It seems like the Cinnamon monitor dialog allows setting these two separately.
According to xrandr, my monitor now has 1.3333x its normal resolution, so Cinnamon is using xrandr-based scaling for this.

Clearly there is something special going on when Cinnamon is involved that I do not know - it does not appear to be GLFW's doing.
I am beginning to get somewhere...
If I set XDG_DESKTOP_NAME=None, I am disabling ebiten's Cinnamon logic while keeping GLFW's scaling as is. And voila, the bug appears.
Adding debug prints to Layout() shows that despite my xrandr screen size being 2560x1440, Layout() gets passed 3840x2160 when I do this.
It basically appears as if Cinnamon has some special nonstandard handling for fullscreen windows. In particular, according to xwininfo I still have a 2560x1440 window.
First of all I should mention, SuperTux has broken fullscreen in Cinnamon with this setup; only ebiten stuff appears to work. This speaks very much for a bug in Cinnamon that you're working around than anything else... so maybe the solution is to turn on this handling only if Cinnamon is actually used? In other words, if we default the scale factor to "whatever glfw returns", but only override when there IS a DE with this hackery, things should work everywhere.

Next experiment: making all the from/to functions return x as-is and setting XDG_CURRENT_DESKTOP=None to disable Cinnamon hackery. Result: still broken fullscreen.
If only I could trace what actually happens at X11 level...

Running an xtrace shows that the only place the value 3840 could be coming from is GetScreenResourcesCurrent.
Sudden realization: what if GLFW returns the MAXIMUM mode, but we need the CURRENT mode?

I've figured it out.
The issue is that Cinnamon doesn't use a lower video mode, but the Xrandr scale feature.
So a Cinnamon-less repro (broken in current code TOO) is:
xrandr --output DP-1 --scale 1.5x1.5
./whatever-ebiten-game

This is broken in ALL environments. And I strongly suspect the issue needs to be fixed in GLFW, not Ebiten. The cause is that GLFW requests the current mode's resolution, BUT does not scale it by the current output scale factor.
Once fixed, Ebiten can remove the Cinnamon-specific hackery and just a single deviceScaleFactor for everything (I'd propose to be using the GLFW provided one). This then will be consistent with font rendering, which is usually the right way to go.

Having said that, I'd strongly like to have a workaround I can use till then for my game; as xrandr --scale generally leads to poor display quality (blurry) and as Cinnamon even advises against it in its tooltip, I assume the majority of users aren't using the fractional scaling feature.
Also, given SDL has precisely the same bug, I'd like to make the "political decision" for my game to be equally broken as SDL when xrandr --scale is used, rather than ONLY working in GNOME and Cinnamon and not anywhere else (status quo).
So, what if we for now create a setting (be it a build tag or a runtime variable of some sort) to toggle the behavior to just use one scale factor for everything?

Having said that, I'd strongly like to have a workaround I can use till then for my game; as xrandr --scale generally leads to poor display quality (blurry) and as Cinnamon even advises against it in its tooltip, I assume the majority of users aren't using the fractional scaling feature.
Also, given SDL has precisely the same bug, I'd like to make the "political decision" for my game to be equally broken as SDL when xrandr --scale is used, rather than ONLY working in GNOME and Cinnamon and not anywhere else (status quo).
So, what if we for now create a setting (be it a build tag or a runtime variable of some sort) to toggle the behavior to just use one scale factor for everything?

Minimal workaround that works for me in EVERY configuration (i3, sway, ebiten, no matter if scaled or not):
diff --git a/internal/uidriver/glfw/ui.go b/internal/uidriver/glfw/ui.go
index 6c18f6a4..c25bc31c 100644
--- a/internal/uidriver/glfw/ui.go
+++ b/internal/uidriver/glfw/ui.go
@@ -929,7 +929,7 @@ func (u *UserInterface) updateSize() (float64, float64, bool) {
        u.toChangeSize = false

        var w, h float64
-       if u.isFullscreen() {
+       if u.isFullscreen() && false {
                v := currentMonitor(u.window).GetVideoMode()
                ww, wh := v.Width, v.Height
                s := u.deviceScaleFactor()

Yes, I'm just turning off the fullscreen-specific handling in updateSize(), thereby not using the broken data from GetVideoMode().
The contentScale provided by Cinnamon is still used this way and is used solely to decide sizes of new windows; for rendering including fullscreen, everything works as it should.
Note that this does not fix everything; in partiuclar, ebiten functions that return the screen size before creating a window will keep returning wrong (too large) data. It does seem good enough for me, at least if on all platforms u.window.GetSize() is valid and correct when fullscreen. If not, maybe this workaround is only OK for Linux.
So as a temporary hack, could I get a way to toggle this? The proper GLFW fix then can wait a bit longer (I'll have to find a pure GLFW repro for this first).

Sorry, this temp hack alone is NOT enough - it only works when toggling into fullscreen, not when starting as fullscreen to begin with (well, of course I could just do the toggling myself in the first Update() call).
Any idea how to better handle this?

The GLFW boing.c example does NOT exhibit this bug.
But reading its code, it does not rely on monitor sizes - it instead uses the framebuffer size callback from GLFW to get informed about a successful resize.
Ebiten already waits for this callback but optionally with a timeout. The timeout seems to be there to guard against a race condition (#1618).
Also, I can no longer reproduce any issues with my temp hack from https://github.com/hajimehoshi/ebiten/issues/1774#issuecomment-902923730; I guess I just hit the odd case of it taking more than one second to get the new window size.

This is broken in ALL environments. And I strongly suspect the issue needs to be fixed in GLFW, not Ebiten. The cause is that GLFW requests the current mode's resolution, BUT does not scale it by the current output scale factor.

I'm not sure what is correct, but if you are right, can we add something or ignore GLFW's API to treat the 'correct' values?

Also, given SDL has precisely the same bug, I'd like to make the "political decision" for my game to be equally broken as SDL when xrandr --scale is used, rather than ONLY working in GNOME and Cinnamon and not anywhere else (status quo).
So, what if we for now create a setting (be it a build tag or a runtime variable of some sort) to toggle the behavior to just use one scale factor for everything? I personally don't care which one to use, although I'd be leaning towards "just force all scale factors to 1.0" given I already compute a "good window size" in my game anyway by multiplying game size by an integer factor "as big as possible" to leave some desktop environment borders.

Hmm, so are you suggesting to make things broken for consistency rather than hacks only for Gnome and Cinnamon, which seems inconsistent? Would it be feasible to make everything work, which is also consistent and ideal?

Making everything work seems almost possible:

Do not rely on the monitor sizes for computing fullscreen size; instead
update based on the GLFW callback for framebuffer size. This is what the
example that comes with GLFW does, although you apparently had a case where
the callback never came.
Failing that, use the window size approach always (which is what my
attempted patch does).

Catch is, if we call GetSize too early, we will stay at the wrong size -
and I believe this happened to me once, although I cannot repro. Would it
actually be OK to just call GetSize every frame, or is that call expensive?
What this can NOT fix (which is why this is just an "almost") is predicting
the screen size BEFORE entering fullscreen. This is plain impossible using
GLFW's API. I guess the way to fix this is filing a GLFW feature request to
either return "adjusted for scale" resolutions, or to include the scale
factor as an additional struct member in the monitor info.
Impact of this breakage to many games would be displaying the wrong
fullscreen size in the graphics settings menu, but everything else would
work.
Impact of this breakage to my game in specific would be that I will
calculate a too large initial window size in windowed mode on such systems.
Luckily it appears that the desktop environments clip this overly large
size to the screen size then, so this is kinda OK (plus I provide a setting
for window size anyway).
On Sat, Aug 21, 2021, 02:48 Hoshi, Hajime (星一) @.***>
wrote:

Also, given SDL has precisely the same bug, I'd like to make the
"political decision" for my game to be equally broken as SDL when xrandr
--scale is used, rather than ONLY working in GNOME and Cinnamon and not
anywhere else (status quo).
So, what if we for now create a setting (be it a build tag or a runtime
variable of some sort) to toggle the behavior to just use one scale factor
for everything? I personally don't care which one to use, although I'd be
leaning towards "just force all scale factors to 1.0" given I already
compute a "good window size" in my game anyway by multiplying game size by
an integer factor "as big as possible" to leave some desktop environment
borders.
Hmm, so are you suggesting to make things broken for consistency rather
than hacks only for Gnome and Cinnamon, which seems inconsistent? Would it
be feasible to make everything work, which is also consistent and ideal?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/1774#issuecomment-903070369,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5NMENQKIK45HWZKJKDOLT55D3XANCNFSM5CQWKZSQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

Okay, so from what I see I guess the first thing to decide is, what should Ebiten's device scale factor be?
It seems like Ebiten primarily uses it to map from game-defined to actual window sizes, but also - sadly - in lots of other places.
So my very first question would be: why? Can't this be simplified and deviceScaleFactor be used way less?
Then there is GLFW's own content scale. This is entirely unnecessary but "nice to have".
What I would suggest as correct behavior:

In GLFW, ebiten.DeviceScaleFactor() shall return GLFW's content scale.
When querying video modes (ScreenSizeInFullscreen), translate GLFW resolution using BOTH ebiten.DeviceScaleFactor() AND "the XRandR scale".
For internal usage, however, do not rely on this conversion; instead create a fullscreen window, wait for it to be done and then query its size to find what you actually got.
In order to call Layout(), first translate the input using ebiten.DeviceScaleFactor() only.
Similarly, translate CursorPosition(), TouchPosition(), WindowSize(), SetWindowPosition(), SetWindowSize().
Internal code outside these API calls shall not use the device scale factor at all. I.e. Ebiten internally "thinks" in window system pixels (post-XRandR, pre-ContentScale).

This way should work perfectly on X11. Can't tell it will work this way on Windows or Mac - depends on what kind of coordinates GLFW returns on these platforms.

Now wondering though if there could be a fix without this massive refactor.
What about this:

deviceScaleFactor is always GLFW's

this is somewhat tricky as the devicescale library can't use our GLFW window - that'd cause a dependency cycle. For this I'd probably put this in the glfw ui driver itself, and ignore the devicescale library for anything GLFW (meaning devicescale library can entirely drop its X11 and Windows support, and only remains used for JS and mobile)

ONLY when converting the fullscreen resolution, also apply the XRandR scale factor (i.e. what you currently get via cinnamon and GNOME config files or commands)

Speaking of XRandR - it seems like the GLFW issue we are primarily fighting with - and why you needed the Cinnamon and GNOME hacks - is that GLFW gives you the wrong kind of resolution. When I run xrandr:
XWAYLAND0 connected 1360x768+0+0 (normal left inverted right x axis y axis) 310mm x 170mm
   1360x768      59.98*+

Ebiten needs the "upper" 1360x768, but GLFW provides the "lower" 1360x768. It appears that the upper one comes from XRRCrtcInfo, the lower one from XRRModeInfo. Indeed, GLFW exclusively uses XRRModeInfo, except where matching against Xinerama screen indexes. The problem with XRRCrtcInfo for GLFW's use case is that it does not help when one wants to know the output resolution when a specific different video mode is selected.
I am now somewhat tempted to suggest Ebiten shall have its own X11 connection in addition to GLFW's, so it can query the XRandR stuff itself (e.g. via https://pkg.go.dev/github.com/BurntSushi/xgb/randr). Or, given you seemed to be OK with spawning an external utility anyway... could even just do this: https://github.com/vcraescu/go-xrandr (but then the xrandr utility must be installed).
Failing that, we could also just give up on predicting fullscreen size properly, and just do that:

deviceScaleFactor is always GLFW's (same as above)
do not rely on predicted screen size; somehow fix initialization of fullscreen mode so we always eventually get the correct size

That'll yield the minimum size patch, rather sure, but ebiten.ScreenSizeInFullscreen would remain broken with that.
I can try making the patch - however I only have Linux systems so I won't be able to test on Windows or Mac.

Thank you for the details! Sorry I was quite busy today. I'll reply tomorrow when I'm available.

On Fri, Aug 27, 2021 at 11:32 AM Hoshi, Hajime (星一) <
@.***> wrote:

OK so, in the current implementation, what we should do is

DeviceScaleFactor should use XRandR's scale.
fromGLFWMonitorPixel should use XRandR's scale
fromGLFWPixel can remain as it is (the monitor's content scale)

I am not 100% convinced. Let's see how they interact:

Let XRandr scale be r (i.e. 2 if physical resolution is 2x window
system's)
Let dpi based scale be d (i.e. dpi of rendered pixels is 96*d). This is
the one GLFW returns as ContentScale.

Here are the "backwards" conversions for window size:
monitor res -> fromGLFWMonitorPixel -> toFramebufferPixel must apply factor
1 / (r * d), as this is the proper conversion from physical to device
independent resolution
window res -> fromGLFWPixel -> toFramebufferPixel must apply factor 1 / d,
as this is the proper conversion from window to device independent
resolution
Here are the "forward" conversions for window size:
requested res -> toGLFWPixel must apply factor d
Also, as this is clearly intended:
fromGLFWPixel and toGLFWPixel must be inverses.
From this we get:

fromGLFWPixel(x) = x / d
toGLFWPixel(x) = x * d
toFramebufferPixel(x) = x
fromGLFWMonitorPixel(x) = x / (r * d)
DeviceScaleFactor generally should be d, too.

This is basically the same implementation as in ui_windows, with
deviceScaleFactor() being somehow initialized using GLFW's value.  The only
difference is in fromGLFWMonitorPixel, which will in addition also apply
the XRandR scale.

Are these correct? Sorry if I'm wrong. I'm not sure about especially the
third item.

XRandR's (and also GNOME's and Cinnamon's scale - the thing
currently set
as DeviceScaleFactor) should only be used for converting GLFW's screen
resolution data to "window system pixels".

Yes. And arguably this might actually be a GLFW bug.

The alternative I suggested was instead skipping GLFW's functions to
return video modes, and to instead trust XRandR itself on this.

Yes; breaks with Wayland of course.

Another alternative would be not querying video modes at all but to
instead accept the window size we actually get, although this is
currently
not feasible as Ebiten provides an API to query the fullscreen
resolution
before creating the window.

Yes.

Your suggestions are:

Use XRandR's scale only for fromGLFWMonitorPixel
Use XRandR's scale for fromGLFWMonitorPixel and DeviceScaleFactor
Use GLFW's monitor size: (don't we already do this)?

Not quite; see above where I actually resolved the equations.

Are these correct?
I'm fine to fix the issue only for X, and let's keep the current behavior
for non-X system if possible.

Sounds good.

Let the current DeviceScaleFactor call r'. r' is very similar to r but makes sense only on Gnome and Cinnamon.
The current implementation is:

fromGLFWMonitorPixel(x) = x / r'
fromGLFWPixel(x) = x / d
toGLFWPixel(x) = x * d
toFramebufferPixel(x) = x * d / r'
DeviceScaleFactor() = r'

And your suggestion is to adjust them like this:

fromGLFWMonitorPixel(x) = x / r
fromGLFWPixel(x) = x / d
toGLFWPixel(x) = x * d
toFramebufferPixel(x) = x / d / r
DeviceScaleFactor() = d

My current questions are:

toFramebufferPixel seems completely different, but is this really correct?
If DeviceScaleFactor is d, can we really achieve Hi-DPI resolution?

On Sat, Aug 28, 2021, 02:33 Hoshi, Hajime (星一) @.***>
wrote:

Let the current DeviceScaleFactor call r'. r' is very similar to r but
makes sense only on Gnome and Cinnamon.
The current implementation is:

fromGLFWMonitorPixel(x) = x / r'
fromGLFWPixel(x) = x / d
toGLFWPixel(x) = x * d
toFramebufferPixel(x) = x * d / r'
DeviceScaleFactor() = r'

And your suggestion is to adjust them like this:

fromGLFWMonitorPixel(x) = x / r
fromGLFWPixel(x) = x / d
toGLFWPixel(x) = x * d
toFramebufferPixel(x) = x / d / r
DeviceScaleFactor() = d

My current questions are:

toFramebufferPixel seems completely different, but is this really
correct?

No; toFramebufferPixel should be the identity (just x). Exactly like on
Windows and OS X - basically this conversion will no longer be needed
anywhere. All fullscreen specifics go into fromGLFWMonitorPixel.

If DeviceScaleFactor is d, can we really achieve Hi-DPI resolution
when we want?

Absolutely. Ebiten will always allocate the internal screen as Hi-DPI, and
a game that wants to render to Hi-DPI will have to multiply the input by
DeviceScaleFactor() in Layout(). Like now.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/1774#issuecomment-907581341,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5NMBQBFGJP5RPGMLSYB3T7B7KBANCNFSM5CQWKZSQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thanks, so is your suggestion

fromGLFWMonitorPixel(x) = x / r
fromGLFWPixel(x) = x / d
toGLFWPixel(x) = x * d
toFramebufferPixel(x) = x
DeviceScaleFactor() = d

?
I'd be very happy if you could send a PR for this. I'm not confident this would work perfectly yet as I don't understand about XRandR, but I'd like to test this on my some Linux machines.

Sounds good, will try.
The main complication will be that I can't use the devicescale mode or it'd
cause a cyclic dependency. I'll probably at least at first just skip that
module entirely for the GLFW/X11 code path.
The other complication is that there's no "explicitly intended" way to get
the scale from XRandR - one can get a matrix, or the current mode and the
current output size. I think I'll go for the latter and just divide. Have
to see though how that interacts with panning (which one can set up too in
XRandR).
On Sat, Aug 28, 2021 at 8:16 AM Hajime Hoshi @.***>
wrote:

Thanks, so is your suggestion

fromGLFWMonitorPixel(x) = x / r
fromGLFWPixel(x) = x / d
toGLFWPixel(x) = x * d
toFramebufferPixel(x) = x
DeviceScaleFactor() = d

?
I'd be very happy if you could send a PR for this. I'm not confident this
would work perfectly yet as I don't understand about XRandR, but I'd like
to test this on my some Linux machines.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/1774#issuecomment-907618590,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5NMFLSNRSNCQIDBO67KLT7DHSPANCNFSM5CQWKZSQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Working on it now - https://github.com/divVerent/ebiten/tree/devicescale
Not filed the PR yet - first want to get it to work on all platforms I can
try. In particular Linux/Sway (tested), Linux/Cinnamon, Linux/GNOME,
Windows/WINE (sorry, don't have real Windows anywhere, but at least I can
set up HiDPI there).
I am unsure about OS X; the previous code looked horribly wrong (like not
supporting device scale at all). I believe my changes are NOP for OS X, but
can I ask you to test/fix OS X support once I have tested for the above
listed platforms?
On Sat, Aug 28, 2021 at 8:47 AM Rudolf Polzer @.***> wrote:

Sounds good, will try.
The main complication will be that I can't use the devicescale mode or
it'd cause a cyclic dependency. I'll probably at least at first just skip
that module entirely for the GLFW/X11 code path.
The other complication is that there's no "explicitly intended" way to get
the scale from XRandR - one can get a matrix, or the current mode and the
current output size. I think I'll go for the latter and just divide. Have
to see though how that interacts with panning (which one can set up too in
XRandR).
On Sat, Aug 28, 2021 at 8:16 AM Hajime Hoshi @.***>
wrote:

Thanks, so is your suggestion

fromGLFWMonitorPixel(x) = x / r
fromGLFWPixel(x) = x / d
toGLFWPixel(x) = x * d
toFramebufferPixel(x) = x
DeviceScaleFactor() = d

?
I'd be very happy if you could send a PR for this. I'm not confident this
would work perfectly yet as I don't understand about XRandR, but I'd like
to test this on my some Linux machines.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/1774#issuecomment-907618590,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5NMFLSNRSNCQIDBO67KLT7DHSPANCNFSM5CQWKZSQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thank you for your dedicating work!

but can I ask you to test/fix OS X support once I have tested for the above listed platforms?

Sure, I'll test on my macOS and Windows!

Filed these GLFW bugs:

https://github.com/glfw/glfw/issues/1960
https://github.com/glfw/glfw/issues/1961

Note that a fix to any of these might need an Ebiten update in response. As Ebiten's go.mod controls the GLFW version used, this can then be in sync.
For now, I figured out that querying the workarea only sometimes works (namely, when the desktop environment is setting one), so I am now switching to an approach that doesn't use the workarea query but really operates at XRandR level.

Okay, now switched to using the xgb module to query RANDR data. Works so far on sway and i3. Now testing Cinnamon.

Windows/WINE/XWayland/Sway at 144dpi also working.

WINE with xrandr --scale broken.
Not sure if this is WINE's bug though. Will see if I can repro with other fullscreen games in WINE.

WINE breakage predates my changes (happens on Ebiten main too). Strongly suspect WINE has the exact same bug as GLFW does - it returns the hardware video modes, not the logical resolutions.

I'm rather confident about correctness for Windows now.
Relevant deltas for Windows:

fromGLFWMonitprPixel applies the given scale and the deviceScaleFactor. The given scale is always 1.0; previously the deviceScaleFactor was given, so this should be a NOP, but a potentially broken refactor. Worth verifying.
Otherwise, although GLFW and Ebiten have both their own implementation of device scale factor querying, I assume the changes are NOP. It appears they use the same APIs though.

Relevant deltas for OS X:

Added device scale support at all. Not sure if that was a good or a bad idea. It is possible that the OS X conversions actually should just be "return x" with my changes too, which would imply that GLFW wants device independent coordinates on OS X (even though it wants frame buffer pixels anywhere else).
Am unsure about fromGLFWMonitorPixel, as it depends on what kind of data GLFW returns. Might have to be x or x / (screenScale * u.deviceScaleFactor()) like in all other backends.
Am unsure if screenScale is relevant on OS X at all. Suspecting it isn't and always having it 1.0 is right.
Mouse cursor position conversion changed; previous code just returned coordinates as is, new code divides by device scale factor. Rather sure this is a positive improvement.

Awesome work!
I think I'd like to see the actual code, which would be easier to understand what to do. Anyway I'm looking forward to your PR.

Filed https://github.com/hajimehoshi/ebiten/pull/1797 but let's consider it
WIP for now.
On Sat, Sep 4, 2021 at 5:41 AM Hajime Hoshi @.***>
wrote:

Awesome work!
I think I'd like to see the actual code, which would be easier to
understand what to do. Anyway I'm looking forward to your PR.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/1774#issuecomment-912943499,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5NMBPIFFAIFTQIHZ3MG3UAHSVRANCNFSM5CQWKZSQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

PR #1800 will fix most of this, and https://github.com/divVerent/ebiten/commit/1449b68d0beb6adc4c2cb5da0973a134df9ca36d (PR to be filed when #1800 is in, as it can't be merged independently) will then fix the rest. Can't really split that commit up further, sadly, but at least the OS-dependent stuff is mostly out of there already.


Visual Studio Library Linking Documentation

I just worked through building this project and linking it in Visual Studio, and wanted to share some helpful info that could be added to the Building docs.
After linking the headers and library to my project, I tried to compile the following line of code from the listener hook example:
(void)uvgrtp::frame::dealloc_frame(frame);

And got the following linker errors:
uvgrtp.lib(socket.obj) : error LNK2001: unresolved external symbol in6addr_any
uvgrtp.lib(hostname.obj) : error LNK2019: unresolved external symbol __imp_GetUserNameA referenced in function "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl uvgrtp::hostname::get_username(void)" (?get_username@hostname@uvgrtp@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)

I ended up needing to add ws2_32.lib and Advapi32.lib to the Linker > Input > Additional Dependencies panel. The final working entry in that field is uvgrtp.lib;ws2_32.lib;Advapi32.lib

Hi,
I assume you are not using CMake? I guess we could add a few words about this, but I think CMake should handle this automatically.
BR, Joni

I added mention of this to BUILDING.md. This will be pushed soon.


Fixed #2039: Check for overflow in calculations.

While basically functional correct the changes, especially the new variable alignmem (vs. parameter alignment) makes it much harder to read and to follow.
Big +1 for the checks
-1 for the new variables

@mfleisz could you recheck? The new code should be more readable.


Update Node version in package-lock.json

Follow-up PR to #862. Parallels getodk/central-backend#991.
Before submitting this PR, please make sure you have:

[x] run npm run test and npm run lint and confirmed all checks still pass OR confirm CircleCI build passes
[x] verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

I merged this without a review, since it seems low-risk, and I wanted to get it in before regression testing (though possibly that wasn't needed). @alxndrsn or @sadiqkhoja, would one of you mind reviewing this PR after the fact?

LGTM :+1:


fastlane init

New Issue Checklist

[ x ] Updated fastlane to the latest version
[ x ] I read the Contribution Guidelines
[ x ] I read docs.fastlane.tools
[ x ] I searched for existing GitHub issues

Issue Description
fastlane init can't detect my bundle id. I have one, as you can see here:

Complete output when running fastlane, including the stack trace and command used

You can use: --capture_output as the last commandline argument to get that collected for you

✅ fastlane environment ✅
Stack

Key
Value

OS
10.12.6

Ruby
2.3.0

Bundler?
false

Git
git version 2.7.0

Installation Source
~/.rvm/rubies/ruby-2.3.0/bin/fastlane

Host
Mac OS X 10.12.6 (16G29)

Ruby Lib Dir
~/.rvm/rubies/ruby-2.3.0/lib

OpenSSL Version
OpenSSL 1.0.2h  3 May 2016

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
8.3.3

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL

LANGUAGE

fastlane files:
No Fastfile found
No Appfile found
fastlane gems

Gem
Version
Update-Status

fastlane
2.58.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

did_you_mean
1.0.0

executable-hooks
1.3.2

bundler-unload
1.0.2

rubygems-bundler
1.4.4

bundler
1.13.7

io-console
0.4.5

slack-notifier
1.5.1

CFPropertyList
2.3.5

claide
1.0.2

colored2
3.1.2

nanaimo
0.2.3

xcodeproj
1.5.1

rouge
2.0.7

xcpretty
0.2.8

terminal-notifier
1.8.0

unicode-display_width
1.3.0

terminal-table
1.8.0

plist
3.3.0

public_suffix
2.0.5

addressable
2.5.2

multipart-post
2.0.0

word_wrap
1.0.0

tty-screen
0.5.0

babosa
1.0.2

colored
1.2

highline
1.7.8

commander-fastlane
4.4.5

excon
0.58.0

faraday
0.13.1

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20170404

http-cookie
1.0.3

faraday-cookie_jar
0.0.6

fastimage
2.1.0

gh_inspector
1.0.3

json
1.8.3

mini_magick
4.5.1

multi_json
1.12.1

multi_xml
0.6.0

rubyzip
1.2.1

security
0.1.3

xcpretty-travis-formatter
0.0.4

dotenv
2.2.1

faraday_middleware
0.12.2

uber
0.1.0

declarative
0.0.9

declarative-option
0.1.0

representable
3.0.4

retriable
3.1.1

mime-types-data
3.2016.0521

mime-types
3.1

little-plugger
1.1.4

logging
2.2.2

jwt
1.5.6

memoist
0.16.0

os
0.9.6

signet
0.7.3

googleauth
0.5.3

httpclient
2.8.3

google-api-client
0.13.5

generated on: 2017-09-21

Can you share the output when running fastlane init please?

$ fastlane init
[08:49:13]: Get started using a Gemfile for fastlane https://docs.fastlane.tools/getting-started/ios/setup/#use-a-gemfile
[08:49:16]: Detected iOS/Mac project in current directory...
[08:49:16]: This setup will help you get up and running in no time.
[08:49:16]: fastlane will check what tools you're already using and set up
[08:49:16]: the tool automatically for you. Have fun!
[08:49:16]: $ xcodebuild -showBuildSettings -project ./Broccoli.xcodeproj
[!] Could not detect bundle identifier of your react-native app. Make sure to open the Xcode project and update the bundle identifier in the General section of your project settings. Restart fastlane init once you're done!

According to this article, I should have created my react native app with a custom package name:

...create a new React Native app from the command line but make sure you pass in a package name as a param otherwise you’ll hit some pain down the line renaming your package.

react-native init AwesomeProject -package=net.applification.awesomeproject cd AwesomeProject
I assume this vaguely refers to the issue I'm having now. However, it's inconvenient for me to change my bundle id, let alone re-initialize my entire project. Is it possible to use my current bundle id?

I am also currently experiencing an identical issue.

I'm also trying to work through the same issue.

Is there any update to this? Just found this issue as I am trying to setup fastlane for the first time.

@puradox @viperfx By opening the project in XCode and setting a new Bundle Identifier in the General project settings I was able to move past this error.  I still don't have fastlane setup, but I am no longer triggering this error.

The thing is, there is a bundle identifier set. I even removed it and
changed it. All in xcode. However running fastline init still gives that
error.
On Oct 3, 2017 00:18, "Will Porter"<EMAIL_ADDRESS>wrote:

@puradox https://github.com/puradox @viperfx
https://github.com/viperfx By opening the project in XCode and setting
a new Bundle Identifier in the General project settings I was able to move
past this error. I still don't have fastlane setup, but I am no longer
triggering this error.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fastlane/fastlane/issues/10394#issuecomment-333734403,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUCQbMPspI4-cM9so1ZX8U0ldhDbWZ6ks5sobV7gaJpZM4Pf_3c
.

Just wanted to leave a comment and say I resolved the issue. For me, the issue was that I noticed the fastlane command was using the workspace file rather than xcode project file. So I delete the workspace file and the fastlane init command worked for me.

This seems to be an issue with Xcode 9.  I am have this exact problem, and I am absolutely sure that my bundle id is set under the general tab in Xcode.  I believe in Xcode 9 that  xcodebuild -showBuildSettings -project ./AwesomeProject.xcodeproj does not list the BUNDLE_ID, but if you grep the ./AwesomeProject.xcodeproj it is there:  grep -R BUNDLE *
AwesomeProject.xcodeproj/project.pbxproj:				BUNDLE_LOADER = "$(TEST_HOST)";
AwesomeProject.xcodeproj/project.pbxproj:				BUNDLE_LOADER = "$(TEST_HOST)";
AwesomeProject.xcodeproj/project.pbxproj:				PRODUCT_BUNDLE_IDENTIFIER = "com.facebook.REACT.AwesomeProject-tvOS";
AwesomeProject.xcodeproj/project.pbxproj:				PRODUCT_BUNDLE_IDENTIFIER = "com.facebook.REACT.AwesomeProject-tvOS";
AwesomeProject.xcodeproj/project.pbxproj:				BUNDLE_LOADER = "$(TEST_HOST)";
AwesomeProject.xcodeproj/project.pbxproj:				PRODUCT_BUNDLE_IDENTIFIER = "com.facebook.REACT.AwesomeProject-tvOSTests";
AwesomeProject.xcodeproj/project.pbxproj:				BUNDLE_LOADER = "$(TEST_HOST)";
AwesomeProject.xcodeproj/project.pbxproj:				PRODUCT_BUNDLE_IDENTIFIER = "com.facebook.REACT.AwesomeProject-tvOSTests";

I had the same issue. This solved my problem (and I don't know why).

Delete the Bundle Identifier
fastlane init (it will fail)
Add the Bundle Identifier back exactly as it was before deleting it
fastlane init (it worked this time magically)


Converting MediaPipe Handpose model to TFLite model

HI team,
I am developing an embedded IOT device and I wanted to use the Handpose model for hand-tracking and gesture recognition but I didnt yet find a guide for converting Mediapipe models to TFLite model. Could you please provide a guide if its possible.
Thanks

@akshayvernekar,
I have transferred this issue from TF Hub repository to TF Lite Repository, as the issue is related to Lite.

@akshayvernekar Did you get a chance to look at mediapipe/models?
For hand detection models see https://github.com/google/mediapipe/tree/master/mediapipe/models#hand-detection-and-tracking

Thanks @ymodak this is exactly what I was looking for, the repository has the necessary .tflite files .

Glad I could help. Closing this issue now. Thanks!

@ymodak link provided is void
the tflite model for hands was deleted from repo

@ymodak link provided is void
the tflite model for hands was deleted from repo

The same problem, model was deleted

The same problem, model was deleted

@TheBricktop I found this https://github.com/google/mediapipe/blob/master/mediapipe/modules/palm_detection/palm_detection.tflite

@TheBricktop I found this https://github.com/google/mediapipe/blob/master/mediapipe/modules/palm_detection/palm_detection.tflite

@kinivi do you have any idea how to convert pbtx to tflite? I need it for gpu accelerated palm and hand landmark

@kinivi do you have any idea how to convert pbtx to tflite? I need it for gpu accelerated palm and hand landmark

@TheBricktop I can mislead, but I think you can use tflite model with GPU acceleration just by checking one parameter in the interpretator.

@TheBricktop I can mislead, but I think you can use tflite model with GPU acceleration just by checking one parameter in the interpretator.

Hand tflite https://github.com/google/mediapipe/blob/master/mediapipe/modules/hand_landmark/hand_landmark.tflite

Hello, the tflite model for hands was deleted from repo.
Could anyone please help me?


Change repo name to serverbot

Finished in https://github.com/nozel-org/serverbot/commit/37f9862ee620f7509a48278305ac4335665fe13b.


Add an ADOP theme

and ensure it is possible to set that theme as default at Hygieia instance creation time.
NB. ADOP refers to this project: http://accenture.github.io/adop-docker-compose/

A new favicon image was created related to ADOP which is going to replace the existing capital one.
There is a Hygieia transparent image with white letters that is already being used in slate theme so there is no need of creating a new one with white background.
Next step is to make a couple of modifications in parts of the code I have already found in order to check the result and finalize the theme.


attach node name label in ip cr

[x] Make sure you have followed Kube-OVN Code Style.

What type of this PR
Features

Which issue(s) this PR fixes:
Fixes #2317
WHAT

🤖 Generated by Copilot at 3075070
This pull request adds node name label support to IP CRD objects for node IPAM feature. It also refactors the subnet name label logic to use a constant from the util package.

🤖 Generated by Copilot at 3075070

Node name label is the key to the gate
Unleash the power of the IP CRD fate
Subnet name logic is not enough
We need to label all the nodes and stuff

HOW

🤖 Generated by Copilot at 3075070

Add and set a new label for node name to IP CRD objects (link, link, link)

Define a constant for the label key in pkg/util/const.go (link)
Use the constant to add the label with the node name as the value in pkg/controller/node.go (link)
Update the existing logic of setting the subnet name label to also set the node name label in the same function in pkg/controller/node.go (link)

Thanks! @mingoooo

Thanks! @mingoooo

Happly to help and become a contributor 😉


a thank you page for eli cohen for finding this

A slick modern looking one page thank you website for finding a cool generative AI open source repo for generating  UI

wrong repo :)

@MendyLanda Hi, you can experience it three times after star this repo.

@MendyLanda Hi, you can experience it three times after star this repo.

I appreciate it, already forked it and have it working with my own key. This repo deserve a star regardless 🫶


Fix custom mesh pipelines

Objective
Fixes #3379
Solution
The custom mesh pipelines needed to be specialized on each mesh's primitive topology, as done in queue_meshes()

Nice fix! Just pushed small tweaks that I think slightly improve legibility.

bors r+


pkg: Migrate from cluster-config-v1 to Infrastructure.config.openshift.io

Mostly, this is replacing cluster-config-v1 (which is deprecated) with the Infrastructure config object.  As part of that, I'm dropping UserTags support (see discussion here and here).  I'm also replacing the openshiftClusterID tag with a kubernetes.io/cluster/{infraName}: owned tag, see here and here.
This also replaces OperatorFailing with OperatorDegraded, catching up with openshift/api#287.
I've taken the vendor bump in two steps, since dep sees a lot in master's vendor/ that it doesn't think we need.  Let me know if you'd rather have me squash that down into a single commit, or split the second vendor bump out into individual pivots.
[EDIT: expanding on the above motivation a bit, the OperatorFailing -> OperatorDegraded bit is going to be a 4.1 blocker soon (registry Bugzilla should be landing tonight, for now, there is this).  Dropping cluster-config-v1 in favor of Infrastructure simplifies user-facing docs because all you need to tear down an AWS cluster is the kubernetes.io/cluster/{infrastructureName}: owned tag.  And it's tied up in the 4.1-targetted rhbz#1685089.  There may be some slush about delivering that bug, although at one point it was a beta-blocker].

e2e-aws:
$ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1304/artifacts/e2e-aws/installer/.openshift_install.log | grep fatal
time="2019-04-23T06:07:45Z" level=fatal msg="failed to initialize the cluster: Cluster operator image-registry is still updating: timed out waiting for the condition"
$ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1304/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-fc9948cc-b767n_cluster-image-registry-operator.log.gz | gunzip
I0423 05:43:03.599910       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g38fc8f9-dirty
...
I0423 05:43:04.942285       1 bootstrap.go:38] generating registry custom resource
E0423 05:43:04.942775       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: GroupVersion is required when initializing a RESTClient, requeuing
...
I0423 05:47:50.891197       1 bootstrap.go:38] generating registry custom resource
E0423 05:47:50.891602       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: GroupVersion is required when initializing a RESTClient, requeuing
W0423 05:49:33.748130       1 reflector.go:270] k8s.io/client-go/informers/factory.go:131: watch of *v1.ServiceAccount ended with: too old resource version: 10505 (11039)
W0423 05:50:03.482668       1 reflector.go:270] k8s.io/client-go/informers/factory.go:131: watch of *v1.ConfigMap ended with: too old resource version: 11916 (16477)
...
W0423 05:50:03.602167       1 reflector.go:270] github.com/openshift/client-go/route/informers/externalversions/factory.go:101: watch of *v1.Route ended with: The resourceVersion for the provided watch is too old.
W0423 05:52:51.403461       1 reflector.go:270] k8s.io/client-go/informers/factory.go:131: watch of *v1.ConfigMap ended with: too old resource version: 16622 (17342)
...
W0423 05:52:51.505446       1 reflector.go:270] github.com/openshift/cluster-image-registry-operator/pkg/generated/informers/externalversions/factory.go:101: watch of *v1.Config ended with: too old resource version: 13353 (17476)
W0423 05:58:14.444641       1 reflector.go:270] k8s.io/client-go/informers/factory.go:131: watch of *v1.ConfigMap ended with: too old resource version: 17477 (18844)
I0423 05:59:48.418350       1 bootstrap.go:38] generating registry custom resource
E0423 05:59:48.418814       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: GroupVersion is required when initializing a RESTClient, requeuing
...

So something seems to be broken with my REST-client initialization.

Looks like RESTClientFor requires GroupVersion which InClusterConfig does not set.  I will switch to UnversionedRESTClientFor, which can fill this in.

I will switch to UnversionedRESTClientFor, which can fill this in.

Done with f96b28b5 -> d89aeb13.

Heh:
 $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1305/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-66d8b56784-5wt9v_cluster-image-registry-operator.log.gz | gunzip | head -n7
I0423 09:21:42.998300       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-g64d5f62-dirty
I0423 09:21:42.998640       1 main.go:19] Go Version: go1.10.8
I0423 09:21:42.998689       1 main.go:20] Go OS/Arch: linux/amd64
I0423 09:21:43.039920       1 controller.go:406] waiting for informer caches to sync
I0423 09:21:44.345449       1 controller.go:415] started events processor
I0423 09:21:44.345677       1 bootstrap.go:38] generating registry custom resource
E0423 09:21:44.346403       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: NegotiatedSerializer is required when initializing a RESTClient, requeuing

Why is this so difficult? :p

Ok, with 1cbcb4da, I'm washing through typed/core/v1's NewForConfig to get defaults for both GroupVerision and NegotiatedSerializer.  I'm curious to see how specific those defaults are...

$ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1306/artifacts/e2e-aws/pods/openshift-image-regist$ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1306/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-7f59899bf6-8c8x8_cluster-image-registry-operator.log.gz | gunzip | head -n7
I0423 10:44:51.121540       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-gfa5b59b-dirty
I0423 10:44:51.123383       1 main.go:19] Go Version: go1.10.8
I0423 10:44:51.123407       1 main.go:20] Go OS/Arch: linux/amd64
I0423 10:44:51.153584       1 controller.go:406] waiting for informer caches to sync
I0423 10:44:52.461600       1 controller.go:415] started events processor
I0423 10:44:52.461691       1 bootstrap.go:38] generating registry custom resource
E0423 10:44:52.464035       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: infrastructures "cluster" is forbidden: User "system:serviceaccount:openshift-image-registry:cluster-image-registry-operator" cannot get resource "infrastructures" in API group "" at the cluster scope, requeuingry_cluster-image-registry-operator-7f59899bf6-8c8x8_cluster-image-registry-operator.log.gz | gunzip | head -n7
I0423 10:44:51.121540       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-gfa5b59b-dirty
I0423 10:44:51.123383       1 main.go:19] Go Version: go1.10.8
I0423 10:44:51.123407       1 main.go:20] Go OS/Arch: linux/amd64
I0423 10:44:51.153584       1 controller.go:406] waiting for informer caches to sync
I0423 10:44:52.461600       1 controller.go:415] started events processor
I0423 10:44:52.461691       1 bootstrap.go:38] generating registry custom resource
E0423 10:44:52.464035       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: infrastructures "cluster" is forbidden: User "system:serviceaccount:openshift-image-registry:cluster-image-registry-operator" cannot get resource "infrastructures" in API group "" at the cluster scope, requeuing

Ok, progress :).  Looks like we need something like this, and I've pushed 1cbcb4da -> a2481824 with a stab at that.

images:
release "release-latest" failed: pod release-latest was already deleted

$ oc delete project ci-op-yk62f9di
error: You must be logged in to the server (Unauthorized)

so I've waited long enough for the namespace to be reaped.
/retest

Hrm, still haven't cracked the RBAC incantation:
$ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-image-registry-operator/260/pull-ci-openshift-cluster-image-registry-operator-master-e2e-aws/1312/artifacts/e2e-aws/pods/openshift-image-registry_cluster-image-registry-operator-554c68f744-5s7g7_cluster-image-registry-operator.log.gz | gunzip
I0423 17:16:59.933261       1 main.go:18] Cluster Image Registry Operator Version: 4.0.0-142-gcae9f2c-dirty
...
E0423 17:17:01.269295       1 controller.go:235] unable to sync: unable to get storage configuration from cluster install config: infrastructures "cluster" is forbidden: User "system:serviceaccount:openshift-image-registry:cluster-image-registry-operator" cannot get resource "infrastructures" in API group "" at the cluster scope, requeuing
...

/assign @legionus
We need someone to get this code over the finish line - can you or @dmage fork @wking 's branch and address the RBAC issues?

/retest
looks like a bunch of install failures, let's try to get some real errors

Once #265 has merged I will see what I can do with this getting this fixed up.

Replaced by #267


distribution_new_customer Enhancements

The _distribution_new_customer internal method was originally written for sampling from the latent purchase and dropout distributions of CLV models. It is even more useful for posterior predictive checks, but is taking 1000 samples for each customer in the dataset, which is quite wasteful.
This can be fixed by simply adding an n_samples parameter to _distribution_new_customer, and a default argument of 1 to the distribution_new_customer_recency_frequency external method. On that note, _distribution_new_customer is unique to each model, but the external methods that call it can probably be moved into CLVBaseModel.

Hi @ColtAllen - I just made an attempt on this. Understand the it's low priority but it was easy enough to do this quickly. Have a look at my PR https://github.com/pymc-labs/pymc-marketing/pull/1061


Fix alignment of demographics questions

This was probably already fixed in recently deployed studies. Ctrl+C + Ctrl+V ?

Just removing the "fieldClass": "row" looks better

Done as part of larger project upgrade (commit 297ae9c).


chore(test): Automation of Kubernetes e2e tests

Signed-off-by: Anton Misskii<EMAIL_ADDRESS>What does this PR do?
Modifies Kubernetes tests to run on the Linux platform in GitHub Actions, introduces a workflow to run only Kubernetes tests, and configures the e2e-main workflow to run all test suites using the test:e2e:all npm target.
What issues does this PR fix or reference?
https://github.com/podman-desktop/podman-desktop/issues/10001
How to test this PR?

[ ] Tests are covering the bug fix or the new feature

test workflow run: https://github.com/amisskii/podman-desktop/actions/runs/12397338079

test workflow run: https://github.com/amisskii/podman-desktop/actions/runs/12409039313


Add a reference to metal3 github page

Metal3 website link is now added under the Metal3-io in CNCF projects list here, which redirects to the Metal3 website. However, there is no reference in the home page that would redirect the user to the Metal3-io github page. Adding a reference to https://github.com/metal3-io  in the website homepage would be better from the user's perspective.

/kind bug

kind feature

/kind feature

/remove-kind bug


Images: image alt tags

Priority from accessibility task force:
use abstract or description field in MODS

div hero doesn't have image alt
all others implemented for thumbnails, alt tags


SR-106: New floating-point description implementation

This is tbkka's commits cherry-picked onto a clean checkout from master in an attempt to resolve the issues he's been having with swift-ci. Hopefully this works. His original description follows:

This replaces the current implementation of description and
debugDescription for the standard floating-point types with a new
formatting routine that provides both improved performance and
better results.
Unlike the earlier code based on sprintf with a fixed number of
digits, this logic automatically chooses the optimal number of digits,
generating compact output where possible while ensuring round-trip
accuracy. As such, we can now use the exact same output for both description and
debugDescription (except of course that debugDescription provides
full detail for NaNs).
This resolves SR-106, SR-454, SR-491, SR-3131 and other related issues that have complained
about the floating-point description and debugDescription properties being inexact
and/or inconsistent.
Ergonomics
With the new code, the REPL generally prints the values you would expect.
(swift) 1.1
// r0 : Double = 1.1
(swift) (1.1).description
// r1 : String = "1.1"
(swift) 1e23
// r2 : Double = 1e+23
(swift) print("\(1e23.nextDown) \(1e23) \(1e23.nextUp)")
9.999999999999997e+22 1e+23 1.0000000000000001e+23
(swift) 1.100000000000001
// r3 : Double = 1.100000000000001
(swift) print("\(1.100000000000001)")
1.100000000000001
(swift) 1.0 / 10.0
// r4 : Double = 0.1
(swift) 1.0 / 10.0 + 1.0
// r5 : Double = 1.1

In comparison, the previous implementation routinely prints extraneous digits for debugDescription (used by the REPL) and omits significant digits in description (used by print):
Welcome to Apple Swift version 4.1 (swiftlang-902.0.38 clang-902.0.31). Type :help for assistance.
  1> 1.1
$R0: Double = 1.1000000000000001
  2> (1.1).description
$R1: String = "1.1"
  3> 1e23
$R2: Double = 9.9999999999999991E+22
  4> print("\(1e23.nextDown) \(1e23) \(1e23.nextUp)")
1e+23 1e+23 1e+23
  5> 1.100000000000001
$R3: Double = 1.100000000000001
  6> print("\(1.100000000000001)")
1.1
  7> 1.0 / 10.0
$R4: Double = 0.10000000000000001
  8> 1.0 / 10.0 + 1.0
$R5: Double = 1.1000000000000001

Of course, this only changes how the floating-point numbers are printed.  The actual parsing, storage, and arithmetic operations are unaffected and are still subject to the same rounding issues common to all floating-point arithmetic.
About the Algorithm
The SwiftDtoa.c file here implements a variation of Florian Loitsch' Grisu2
algorithm with changes suggested by Andrysco, Jhala, and Lerner's 2016
paper describing Errol3.
The implementation is:

Fast.  It uses only fixed-width integer arithmetic and has constant
memory and time requirements.

Simple. It is only a little more complex than Loitsch' original
implementation of Grisu2.  The digit decomposition logic for double is
less than 300 lines of standard C (half of which is common arithmetic
support routines).

Always Accurate. Converting the decimal form back to binary using an
accurate algorithm (such as Clinger's algorithm) will always yield exactly the
original binary value.  For the IEEE 754 formats, the round-trip will
produce exactly the same bit pattern in memory.  This is an essential
requirement for debugging, logging, and JSON serialization.

Always Short.  This always selects an accurate result with the minimum
number of decimal digits.  (So that 1.0 / 10.0 will always print 0.1.)

Always Close.  Among all accurate, short results, this always chooses
the result that is closest to the exact floating-point value. (In case
of an exact tie, it rounds the last digit even.)

Performance
The graph below compares the new code (in green) to the performance of three other
popular algorithms.  Note that this graph benchmarks just the underlying C code; the Swift
description logic must spend additional effort to allocate a returned String.

Dragon4 (in yellow) uses variable-length arithmetic in order to provide accurate results regardless of the number of digits requested.  This causes it to become significantly slower when the input has a large positive or negative exponent.  (The other algorithms here do not offer arbitrary numbers of digits, so can use much faster fixed-width arithmetic.)  This is the algorithm commonly used by C standard library implementations of the printf family of functions.
Grisu3 + Dragon4 (in red) uses fast fixed-width arithmetic for 99% of values and falls back to Dragon4 about 1% of the time.   Note the upper whisker that goes to the same height as Dragon4.
Errol4 (in blue) is a recent algorithm that uses multiple-precision floating-point arithmetic internally.  It is the successor to Errol3 which partly inspired the new Swift implementation.
The new SwiftDtoa implementation (in green) is similar to the Errol algorithms but uses fixed-width integer arithmetic throughout.  This gives it uniform fast performance regardless of the input value.

@swift-ci Please smoke test

... and nope. Something seems totally busted here.

Closing this out since it has exactly the same problem as @tbkka's PR. We don't need a duplicate.


outFile doesn't respect gulp.dest location

Expected behavior:
outFile should be placed relative to the dest folder. (It is the behaviour in version 2.13.0, not working anymore in 2.13.1)
Actual behavior:
outFile is placed relative to project root folder.
Your gulpfile:
Include your gulpfile, or only the related task (with ts.createProject).
var tsProject = ts.createProject(tsConfig.compilerOptions, {typescript: require('typescript')});
gulp.task('compile', function () {
    return gulp.src(config.compile)
        .pipe(sourcemaps.init())
        .pipe(ts(tsProject))
        .pipe(sourcemaps.write('.'))
        .pipe(gulp.dest(config.targetDir));
});

tsconfig.json
Include your tsconfig, if related to this issue.
{
  "version": "1.8.9",
  "compilerOptions": {
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "target": "es5",
    "module": "system",
    "moduleResolution": "node",
    "removeComments": true,
    "sourceMap": true,
    "outFile": "bundle.js"
  },
  "exclude": [
    "node_modules",
    "typings"
  ]
}

Code
Include your TypeScript code, if necessary.

I think this was solved in 9859e4795337da6b490a2c7fbb87565b59a42dd8.

Can you try v2.13.1? It should contain the fix for your issue.

As you can see in the OP, I discovered the issue when I upgraded to the latest (2.13.1) version.

Sorry, I meant 2.13.2. Can you try that version?

The version 2.13.2 put my bundle files now beside the dist folder not inside it ;(
For the record: config.targetDir is set to ../target/dist, and the bundle.js file was created in the ../target folder.

But I can leave with this situation: I set the outFile: 'dist/bundle.js, so it will generated into the dist folder.

Thanks for the details. I have fixed it. The issue was that when the project contained only files in a subdirectory, the base path was incorrect. Can you verify that this has solved your issue? If so, I'll release this update on NPM.

I got a similar problem in v2.13.2, but its fixed in the master branch :)

@ivogabe Could you release the next version? It also would be helpful for easy verifying.

Yes, it's released now.

Thanks for quick response on this. It broke our build yesterday and we couldn't figure out why our built files were ending up in /users/[me]/projects/[project-name]/users/[me]/projects/[project-name]/built. Then this morning after a fresh npm install it miraculously worked!

Sorry for the inconvenience, good to hear it's working again!

My CI process has succeeded. Thanks a lot :tada:

I'll test it only on Monday, but thanks anyway.


Abuse banner

Closes #1328
Depends on #2824

Coverage increased (+0.3%) to 38.233% when pulling 0e5436d3ea6d4e85ca7f74ff6c89fbc10dcd63e9 on na3d:abuse-banner into 5a7767b82f72e68dedca020a30e70b96d0d4668b on linode:develop.


If you have a list with a focusable element, scrolling the list unfocuses it

 Issue by Hixie
Wednesday Oct 07, 2015 at 21:25 GMT
Originally opened as https://github.com/flutter/engine/issues/1529

As each focusable element goes out of the list, we lose its global key, and so we assume that it's gone forever. We might need a way to chain a global key to another global key so that while the master is still alive, the slave isn't considered gone for the purposes of autofocus, or something.

We should fix this and https://github.com/flutter/flutter/issues/105 at the same time. When an input has focus, it should send a notification to tell its ancestor list to keep it alive, so that the keyboard stays up, and if the user types, the text goes to the input, and so forth. If the keyboard is dismissed or the input loses focus, then it should send a release notification.

This is basically the same bu as #105, #170, #172.

Duping to https://github.com/flutter/flutter/issues/10826.

I face issue , when i use Listview in form then focused field goes behind the keyboard so user can't see what is type in input any one can help me if already is faced

@ravipatel147 see #10826 #18291 hopefully to land soon


Glacio ore generated in the Overworld

Haven't seen this before, so I think it's only an issue with Glacio ores (but I could be wrong).

Log if it helps:
latest.log
And the one from when I made the world:
2024-05-20-1.log.gz

i'll look into it.

noice.

Is there an ETA on this being fixed in the 1.20.1 version?


Unexpected log output

By trying to check if this issue was fixed, I tried to push the following dataset: https://gist.githubusercontent.com/okyanusoz/740961e3fc83dc75b9e0a199014e3efd/raw/d90d473b8f542ca29c78c5c6f076ee3a0bf93228/data.json
But I get unexpected logs (too many to paste them, I let you check by reproducing them manually).
I don't get these logs in v0.20.0

Contributions are welcome! Feel free to ask any help or question.

Hi!

I got it with such invocation
➜  ~ value=$(printf -- 'a%.0s' {1..512}); echo '[{"id": 0, "value": "'$value'"}]' | curl -X POST -H 'Content-Type: application/json' --data-binary @- http://<IP_ADDRESS>:9700/documents

Seems like it's because here we're storing a pair of (document_id, word) as a key in LMDB
https://github.com/meilisearch/milli/blob/77de82aaa4ceaee9a5c4ec69c722bc709465f932/milli/src/update/index_documents/store.rs#L454-L485
but the limit on maximum key size not allowing us to store such big words
https://github.com/meilisearch/milli/blob/77de82aaa4ceaee9a5c4ec69c722bc709465f932/milli/src/update/index_documents/store.rs#L37
It can be proven with trying to set a value of length 507, so the key would be 511 bytes in length (4 bytes for key + 507 bytes for word). It works fine.
➜  ~ value=$(printf -- 'a%.0s' {1..507}); echo '[{"id": 0, "value": "'$value'"}]' | curl -X POST -H 'Content-Type: application/json' --data-binary @- http://<IP_ADDRESS>:9700/documents

It looks like a limitation of current implementation on maximum word length which possibly weren't in the previous version (before rewriting the engine), so I'm not sure there's an obvious fix for that. However, if so, I'd be happy to help with that.

Hey @shekhirin,
It seems that those logs that you get are indeed what's we were referring to. Unfortunately, as you said, we can't do very much about them, but maybe always use the bstr crate to log the word that is too large.
The bstr crate can wrap slices of bytes in a BStr struct that is a better debuggable format by always trying to display valid characters when it can and backup on escaped character.

@Kerollmops sounds good. I made a PR with such fix https://github.com/meilisearch/milli/pull/334, could you check that I got your idea right?


local mysql

May I use local mysql in the docker-gerrit? What variables need to set?
issues occured:
➜  ~ docker run --name gerrit -e GERRIT_START_ACTION=supervise -v ~/gerrit_volume:/var/gerrit/review_site -p 8080:8080 -p 29418:29418 -e DATABASE_TYPE=mysql -e DB_ENV_MYSQL_USER=gerrit2 -e DB_ENV_MYSQL_PASSWORD=secret -e DB_ENV_MYSQL_DB=reviewdb -e USER_NAME=xxx openfrontier/gerrit:2.12.3
/gerrit-entrypoint.sh: ignoring /docker-entrypoint-init.d/*
Upgrading gerrit...
fatal: DbInjector failed
fatal: Unable to determine SqlDialect
fatal:   caused by com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
fatal:
fatal: The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
fatal:   caused by java.net.ConnectException: Connection refused

Hi @xinglongjian
You should let the gerrit know where your mysql server is by providing 2 environment variables below.
-e DB_PORT_3306_TCP_ADDR=your mysql host IP addrss
-e DB_PORT_3306_TCP_PORT=your mysql port

I set those 2 environment variables and the result is same!
~docker run --name gerrit -e GERRIT_START_ACTION=supervise -v ~/gerrit_volume:/var/gerrit/review_site -p 8080:8080 -p 29418:29418 -e DATABASE_TYPE=mysql -e MYSQL_USER=gerrit2 -e MYSQL_PASSWORD=secret -e MYSQL_DB=reviewdbb -e DB_PORT_3306_TCP_ADDR=localhost -e DB_PORT_3306_TCP_PORT=3306 -e USER_NAME=xinglongjian openfrontier/gerrit:2.12.3
/gerrit-entrypoint.sh: ignoring /docker-entrypoint-init.d/*
Upgrading gerrit...
fatal: DbInjector failed
fatal: Unable to determine SqlDialect
fatal:   caused by com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
fatal:
fatal: The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
fatal:   caused by java.net.ConnectException: Connection refused

You need wait mysql container ready.


Wrapping in multiple awaits

Is there a way to make the async codemod automatically wrap multiple items in parentheses like this?

Hey,
thanks for filing the issue. This seems indeed like bug. We would appreciate any help on this so please help us out! Have a look at our contributing guidelines and reach out if you have any questions. Cheers!

Oh cool, I'll check it out. I'm actually trying to get the async codemod to work like in the screenshot. When I run the codemod, it only awaits the whole line.


On first every parse of input data field

Store the parsed variable in the input data field. It's easy to generate the input data from the data itself and an ABI, it's hard to generate the parsed data because for every transaction, we have to search through all signatures.  Also-- we should add counter to function and sort the function in the ABI by most frequent first thereby lessening search time.

Moved to https://github.com/Great-Hill-Corporation/quickBlocks/issues/44