Crashes on Windows 10 1607

Tested on Windows 10 Home 32-bit version 1607 (build 14393.187).
ShowKeyPlus 1.0.5835 seems to work fine (both installed key retrieval and check key functions).
ShowKeyPlus 1.0.6084 on the other hand throws the following exception:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
   at ShowKey.frmKeyInfo.bgwVersion_RunWorkerCompleted(Object sender, RunWorkerCompletedEventArgs e)
   at System.ComponentModel.BackgroundWorker.OnRunWorkerCompleted(RunWorkerCompletedEventArgs e)
   at System.ComponentModel.BackgroundWorker.AsyncOperationCompleted(Object arg)

************** Loaded Assemblies **************
mscorlib
    Assembly Version: <IP_ADDRESS>
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
ShowKeyPlus
    Assembly Version: 1.0.6084.20018
    Win32 Version: 1.0.6084.20018
    CodeBase: file:///E:/ShowKeyPlus.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: <IP_ADDRESS>
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_<IP_ADDRESS>__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: <IP_ADDRESS>
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_<IP_ADDRESS>__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: <IP_ADDRESS>
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_<IP_ADDRESS>__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Accessibility
    Assembly Version: <IP_ADDRESS>
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_<IP_ADDRESS>__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
System.Xml
    Assembly Version: <IP_ADDRESS>
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_<IP_ADDRESS>__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Configuration
    Assembly Version: <IP_ADDRESS>
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_<IP_ADDRESS>__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Core
    Assembly Version: <IP_ADDRESS>
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_<IP_ADDRESS>__b77a5c561934e089/System.Core.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

Trying to check a key also displays the following error dialog:
---------------------------
ShowKeyPlus.exe - Bad Image
---------------------------
C:\Users\<username>\AppData\Local\pidgenx2.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. Error status 0xc000035a.
---------------------------
OK
---------------------------

Couple of additional points:

It's a great utility, but how come it has grown to more than double the size between 5835 and 6084?

The check key tab states: "Enter a product key to check it's edition". Please change that to "its" instead.

Thanx for the feedback.
The first exception comes from the Version check on startup, where it checks here for the current version in order to alert of an upgrade. I will check what changed to break that functionality and report back
The second is dll hell - incompatible architecture, most likely - I expanded the code base to include Window 7 backward compatibility on Windows 8 and  Windows 10.
I will correct the grammar with the next release as well.


Fix: Editor is always in dark mode

Summary
Fixes issue #693
Changes Made

Fix issue where CodeEditorViewWrapper did not adapt to system appearance.
Add missing properties from EditorTheme to AuroraTheme.EditorColors.
Update theme loaders with default attrs (values taken from existing Aurora theme).

Testing
Verified that theme does adapt to selected system appearance (even if user explicitly selects a light theme, makes sense since all other UI elements currently adapt to system appearance anyway).
Screenshots/GIFs
https://github.com/user-attachments/assets/3470fd44-d734-4c15-9aeb-46c298b266f5
Checklist
Please ensure all of the following are completed before submitting the PR:

[x] Code has been tested and verified.
[x] Documentation has been updated to reflect the changes.
[x] All tests pass successfully.
[x] Code follows the project's coding guidelines and style.
[x] The branch is up-to-date with the latest changes from the main branch.
[x] Reviewed by at least one other contributor.

Related Issues
#693

Thanks for submitting a pull request!
We will review it as soon as possible.

Nice PR, it seems like you have some linting issues, can you fix that please?

@0xWDG I wonder if we shouldn't just go the way of only light or dark mode themes and remove universal in general..... Because currently there are 3 categories for themes but I think 2 categories light and dark makes more sense.

@0xWDG I wonder if we shouldn't just go the way of only light or dark mode themes and remove universal in general..... Because currently there are 3 categories for themes but I think 2 categories light and dark makes more sense.

We should support a auto (and that should be the default), not everyone uses or light or dark mode, i run a program on my mac which switches the system appearance according to the lightsensor of my mac.

@0xWDG I wonder if we shouldn't just go the way of only light or dark mode themes and remove universal in general..... Because currently there are 3 categories for themes but I think 2 categories light and dark makes more sense.

We should support a auto (and that should be the default), not everyone uses or light or dark mode, i run a program on my mac which switches the system appearance according to the lightsensor of my mac.

I'm not talking about that, auto is system wide we don't have to implement it as long as we use the colorScheme variable.... I'm talking about the universal tab in settings for themes

@0xWDG I wonder if we shouldn't just go the way of only light or dark mode themes and remove universal in general..... Because currently there are 3 categories for themes but I think 2 categories light and dark makes more sense.

We should support a auto (and that should be the default), not everyone uses or light or dark mode, i run a program on my mac which switches the system appearance according to the lightsensor of my mac.

I'm not talking about that, auto is system wide we don't have to implement it as long as we use the colorScheme variable.... I'm talking about the universal tab in settings for themes

Agreed, but we need to revamp the whole theme thing...
But yes, we can remove the universal.

@0xWDG I wonder if we shouldn't just go the way of only light or dark mode themes and remove universal in general..... Because currently there are 3 categories for themes but I think 2 categories light and dark makes more sense.

We should support a auto (and that should be the default), not everyone uses or light or dark mode, i run a program on my mac which switches the system appearance according to the lightsensor of my mac.

I agree: Modern apps should have a top-level option to "use system appearance", "always dark", or "always light" (just like in System Settings).
Related:

I think the light/dark themes should be packaged as variants of a theme (e.g. I had to write a function in ThemeModel to convert a light theme to its dark theme counterpart, when ideally, a theme should just know what variants it provides).
Having themes contain variants means we could also add variants like "neutral", "accessibility" or "dyslexic" to a particular theme/design system.
To use macOS's system settings as an example, there's the system color schemes "dark" and "light", and there's accent colors like "purple" or "orange", and depending on the color scheme, the accent colors will adapt accordingly.  Here, accent colors are the "theme/design system", so to speak.

@0xWDG I wonder if we shouldn't just go the way of only light or dark mode themes and remove universal in general..... Because currently there are 3 categories for themes but I think 2 categories light and dark makes more sense.

We should support a auto (and that should be the default), not everyone uses or light or dark mode, i run a program on my mac which switches the system appearance according to the lightsensor of my mac.

I'm not talking about that, auto is system wide we don't have to implement it as long as we use the colorScheme variable.... I'm talking about the universal tab in settings for themes

One side note, colorScheme is not reliable on initialization of a view.

Interesting, is this something happening in Aurora or have you seen this behaviour elsewhere? I don't recall having experienced this in the past.

@0xWDG I wonder if we shouldn't just go the way of only light or dark mode themes and remove universal in general..... Because currently there are 3 categories for themes but I think 2 categories light and dark makes more sense.

We should support a auto (and that should be the default), not everyone uses or light or dark mode, i run a program on my mac which switches the system appearance according to the lightsensor of my mac.

I'm not talking about that, auto is system wide we don't have to implement it as long as we use the colorScheme variable.... I'm talking about the universal tab in settings for themes

One side note, colorScheme is not reliable on initialization of a view.

Interesting, is this something happening in Aurora or have you seen this behaviour elsewhere? I don't recall having experienced this in the past.

On iOS the parameters will be updated after initialization, I used it for setting a specific background to a view (Gradient), and I always saw after initialization of the view that the background of the screen changed to the correct color.

@0xWDG I wonder if we shouldn't just go the way of only light or dark mode themes and remove universal in general..... Because currently there are 3 categories for themes but I think 2 categories light and dark makes more sense.

We should support a auto (and that should be the default), not everyone uses or light or dark mode, i run a program on my mac which switches the system appearance according to the lightsensor of my mac.

I agree: Modern apps should have a top-level option to "use system appearance", "always dark", or "always light" (just like in System Settings).
Related:

I think the light/dark themes should be packaged as variants of a theme (e.g. I had to write a function in ThemeModel to convert a light theme to its dark theme counterpart, when ideally, a theme should just know what variants it provides).

Having themes contain variants means we could also add variants like "neutral", "accessibility" or "dyslexic" to a particular theme/design system.

To use macOS's system settings as an example, there's the system color schemes "dark" and "light", and there's accent colors like "purple" or "orange", and depending on the color scheme, the accent colors will adapt accordingly.  Here, accent colors are the "theme/design system", so to speak.

Yes we can
I agree we need more variation options
We do use the accent color for (custom) elements

Our biggest issue right now is that we support 3 different systems for theming.

using a json file in "Aurora editor format";
using a TextMate theme;
using a Visual Studio Code theme;

This is not ideal because it is made too complicated to maintain.
In a ideal world we make one theme definition (struct or protocol).
Then we can subclass that for example to get the vs code theme into the theme definition.

@0xWDG @nanashili You guys are probably more familiar with why Periphery might be failing here, there's a lot of noise in that failure log, and I don't see it saying specifically what it's failing on. Help greatly appreciated =)

@0xWDG @nanashili You guys are probably more familiar with why Periphery might be failing here, there's a lot of noise in that failure log, and I don't see it saying specifically what it's failing on. Help greatly appreciated =)

It's mostly for unused code, that it's complaining about. It's not required to pass so don't stress to much. Also I'll review your PR in 5 mins.

Not going to lie, I think I prefer light mode lol

Hey @boscojwho,
Thanks for your contribution.
Your PR has been merged!
Your name will appear on https://auroraeditor.com/#contributors in a few moments, if you have contributed to the editor.
Thanks again for your contribution!
Kind Regards,
Aurora Editor Team.

Thanks for testing @nanashili


x/build: windows installer: image contains outdated URL

What version of Go are you using (go version)?
go1.19.4
What did you do?

install https://go.dev/dl/go1.19.4.windows-amd64.msi

What did you expect to see?

The image in the installer has a URL starting with https instead of http.
The image in the installer links to go.dev instead of golang.org.

What did you see instead?

CC @golang/release


[Image Resizer] Layout not vertically aligned

Environment
Windows build number: Microsoft Windows [Versione 10.0.18362.719]
PowerToys version: 0.17.0
PowerToy module for which you are reporting the bug (if applicable): Image Resizer

Layout not properly vertically aligned.
Screenshots

The fix is now available in 0.18 https://github.com/microsoft/PowerToys/releases


PIP Fails to install requirements.txt

Looks like requirements.txt is busted. This breaks "pip install -r requirements,.txt," which also breaks Travis.

Thanks for mentioning. Please check my commit on this.


no ./scripts/build.sh anymore

this https://substrate.dev/docs/en/getting-started/installing-substrate#manual-build (in version "Substrate Developer Hub 1.0.0") says
# Build the wasm runtime
./scripts/build.sh

but that does not exist.

I could continue now, after a
git checkout v0.9.2

That release v0.9.2 is half a year old.
When will be a new new release?
Should I work with that v0.9.2, or rather risk a newer/st version? Which one do you recommend?

In master the process is simplified, you only have to do cargo build and it will take care of building the runtime as well. Yeah, I guess that documentation you linked needs to be updated to instruct how to check out the v1.0 branch. You should do git checkout -b v1.0 origin/v1.0. cc @shawntabrizi
Feel free to close the issue if this is solved for you.

that documentation you linked needs to be updated

Yes. That the  ./scripts/build.sh step is obsolete. That part was misleading. Even though the heading of the page said "v1.0.0".
I know it is difficult to keep many separate manuals uptodate. That was actually one of the worst aspects of learning Ethereum: half of the manuals were faulty, because not updated. Uncountable dead ends I ran into because of that, raised dozens of issues, etc.. Lost so much time.
I don't know how you can prevent that. By better planning or tooling. Ideas?

to instruct how to check out the v1.0 branch

Or better, I should be able to just checkout the head of the master branch, no?
Or yes, if not that, then include some "checkout lastrelease" thingy into the instructions.
So you recommend against 0.9.2, and instead recommend v1.0 ?
Then I am trying this now:
git checkout -b v1.0 origin/v1.0
./scripts/init.sh
cargo clean
RUSTFLAGS=-Awarnings cargo build

right?

nope:
RUSTFLAGS=-Awarnings cargo build

[...]

   Compiling node-executor v1.0.0 (~/paritytech_substrate/node/executor)
error: couldn't read node/executor/src/../../runtime/wasm/target/wasm32-unknown-unknown/release/node_runtime.compact.wasm: No such file or directory (os error 2)
  --> node/executor/src/lib.rs:26:100
   |
26 | native_executor_instance!(pub Executor, node_runtime::api::dispatch, node_runtime::native_version, include_bytes!("../../runtime/wasm/target/wasm32-unknown-unknown/release/node_runtime.compact.wasm"));
   |                                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `node-executor`.

To learn more, run the command again with --verbose.

The master branch tracks what will eventually become Substrate 2.0, therefore there are some breaking changes compared to 1.0 and there are no stability guarantees. On v1.0 we guarantee some API stability. I also think documentation will be more up-to-date regarding v1.0 (since it's more stable).
Besides init.sh you need to run build.sh. I think the following should work:
git checkout -b v1.0 origin/v1.0
./scripts/init.sh
./scripts/build.sh
cargo build
cargo build -p subkey

Substrate is still early in development and changing rapidly so I think it's a bit understandable that documentation might be a bit lacking. I'm not working on learning resources myself but either way I see that these are getting improved and more documentation is available.

Ah, now ./scripts/build.sh is back again? Thanks.
So it is really only missing in master branch? What about then still having a simple ./scripts/build.sh in master with echo obsolete - then I might have already been successful there now.
On the other hand, perhaps it is good that this obstacle was in the way, because:

On v1.0 we guarantee some API stability.

Perfect, that is what I want. Thanks.

Maybe my explanation earlier wasn't clear:

on master

cargo build

on v1.0

./scripts/build.sh
cargo build

You only need to run ./scripts/init.sh once (in either branch) in order to install the required rust compiler. You can run it again in the future in order to keep updating it but there's no need to do it every time you want to build.

Yes, cargo build --release should give you a significantly faster binary (but the build will be slower).

Yes, I had understood that by now. Thanks again. Just add it to your manuals  ...

Hooray, it finally worked:
target/debug/subkey --version; target/debug/substrate --version
subkey 1.0.0
substrate 1.0.0-2f1b89f4-x86_64-linux-gnu

target/release/subkey --version; target/release/substrate --version
subkey 1.0.0
substrate 1.0.0-2f1b89f4-x86_64-linux-gnu

ls target/{debug,release}/{subkey,substrate} -lh | awk '{print $5, $9}'

109M target/debug/subkey
500M target/debug/substrate
6.1M target/release/subkey
38M target/release/substrate

Thanks a lot for your help.
CanClose

Hello @andresilva,
IF I understand correctly what I was told over there, then you might have pointed me to a "dead" version, i.e. which has reached its EOL?
Of course, I don't want to invest myself into a dead version. Please reopen this (or the other) issue, and

you discuss with @bkchr what's the best policy on this, and
advise me what to do then.

Thanks a lot.

If you want to experiment with building your own time runtime you are probably interested in API stability and in that case v1.0 is better, master is changing everyday.
@bkchr mentioned that those kinds of bugs are not being looked into on v1.0, it's a minor thing (pruning is delayed) and not breaking. If you can replicate the same issue in master (probably it's there too but a lot of code has changed) open an issue and we will look into it.
My recommendation is that you read the existing documentation, figure out what you want to do (create a runtime, just run a node and connect to an existing network, create your private network, etc.). And based on that decide if master or v1.0 is more appropriate for your what you want to do.

Yes, thanks. I am just worried to to work with an unsupported version. I had that before, and it can be super depressing, putting lots of time into the wrong thing. Perhaps I better don't touch ANY version of substrate, and just further delay my work here until 2.0 is stable?
Additional info from @shawntabrizi in the chat:

Stability of 2.0 should be coming soon, so you are a bit in limbo for the time being. If you are doing runtime module development, I would build against 1.0, and do a one time migration (should be relatively low pain) once we announce 2.0 stability.

If you want to test performance, networking, other other aspects of Substrate, run a 2.0 node. Let me know if this helps.

If you build a runtime with 1.0, it should be relatively easy to change to 2.0. in many cases you will need to make no changes at all.
I would recommend you build on 1.0 as mostly everything is the same. There should be documentation and plenty of support to migrate things after the fact.

Thanks @shawntabrizi and @andresilva - so I'd be using this tag, right?
--> https://github.com/paritytech/substrate/releases/tag/v1.0.0
It's 4 months old now. Will there a be a newer one soon?

@drandreaskrueger That tutorial does use master.
We are in the midst of changing. If you want docs for master you can find them under next:
https://substrate.dev/docs/en/next/
Note many pages still in development. Tutorials will come too, you can follow this:
https://substrate.dev/docs/en/next/tutorials/creating-your-first-substrate-chain/

Great, thank you very much. That looks helpful indeed.
Here:
# Switch to the proper commit
git checkout 7d7e74fb

Exactly, that's what I meant. I'd tag that version. Even though that's "24 Sep", so perhaps some selected newer commit would be more appropriate? There haven't been any tags for ~4 months?

Not sure: Is https://github.com/substrate-developer-hub/substrate-node-template obsolete now perhaps?
Because https://substrate.dev/docs/en/next/tutorials/start-a-private-network-with-substrate#compiling-the-tools is using https://github.com/paritytech/substrate and it says:

The second is a more minimal runtime that lives in the node-template directory.
We'll be using the node template in this tutorial because ...

that sounds as if.

@drandreaskrueger there are two choices when writing docs on bleeding edge software:

Write content that constantly breaks, and the user suffers.
Write content that is fixed to a point in time that works.

What are you trying to learn here? The content on the page or something very specific about the last 1 month of commits?
Until Substrate 2.0 is actually released, we can only provide so much support and time constantly updating the docs. I can say in general that the content in these tutorials should not be so out of date they are unusable.
If you wish to work on the bleeding edge of master, you probably can figure it out using these docs and some critical thinking, but we wont have stuff that will hand hold you through the process.

Thanks for the explanations. I understand that it's not easy to accommodate very different needs.
My focus:

as stable as possible
while not working with something that is outdated soon

Sorry for my too many questions, but I have made the experience of working into dead ends too many times now - so I rather ask before. And already it was good, because you pointed me to that amazing collection of instructions. Thanks a lot.
So I guess I stick to the 7d7e74fb then? It's tested and definitely works with your tutorial, and will very probably suit my needs. Sorry, you are right, Sep 25 is really not long ago. True.
Why then not ask the paritytech/substrate maintainer to tag this version 7d7e74fb?
Tags and releases are really helpful for us endusers of your code - to sort out all those questions you mentioned ... by ourselves.

And what about the substrate-developer-hub/substrate-node-template vs /paritytech/substrate/node-template question? Obsolete? Which one do you suggest to use?
Thanks.

@drandreaskrueger substrate-developer-hub/substrate-node-template is our version of "tagging" for tutorials and docs.
We take a snapshot of the paritytech/substrate/node-template and keep in the dev hub to be referenced by all of our docs.
As it updates, we will update all versions of our docs that depend on it if there is a breaking change.

is our version of "tagging" for tutorials and docs.

Ah great. That makes a lot of sense.
Nice. Good to know.

snapshot of the  ... to be referenced by all of our docs.

I understand. Now.
The question is whether "outsiders" will understand that.
(me, I would always search for a stable-but-most-recent tag in the main repo, i.e. paritytech/substrate)
Idea: Put your ^ sentence at the top of the README perhaps?  (Perhaps additionally a link back to your repo from /paritytech/substrate.)
Thanks for all the infos. A lot. Much appreciated.
I have been successful, by the way. My new scripts are now starting "a swarm of" nodes, bootnode-interconnected, each with their own (babe,gran)-keys, entered into the chainspec, etc. Was a bit difficult in the middle - but also very rewarding. Good that I have that now. Will make it available.
Some suggestions for your tutorial: https://github.com/substrate-developer-hub/substrate-developer-hub.github.io/issues/327


endless loop

Netty version（4.1.23.Final-SNAPSHOT）

it in io.netty.util.Recycler.Head.run(), I think it will endless loop!

@liuhanjim this was reported before and was fixed. Update to latest 4.1.x release (4.1.29.Final).

thanks


More reflection!

So far when building shaders with --reflection for C and Zig it does not make enough functions to be able to build a complete list of stuff like the names and offsets of all of the uniforms in a Uniform Block.
The easy path here would be to add more reflection functions, like one where you could ask for the names of all of the uniforms in a given uniform block. Then you could loop through and use the other reflection functions to get the offsets and such.
Another path here would be to just include a YAML version of the shader inside the built shader file, and let people parse that themselves. That would let people do similar shader reflection parsing between both bare_yaml files and other built in shaders.
Do you have a preference on which way you would prefer for new PRs?

I'll just throw a couple of thoughts in here for now, because I've been thinking about similar stuff while working on the resource-bindings-cleanup branch (https://github.com/floooh/sokol/tree/issue1037_bindings_cleanup)

For a while I was thinking about whether it makes sense to add reflection-information to sg_shader_desc which would be ignored by sokol-gfx itself, but would be useful as reflection info for user code, in the end I rejected that idea, but I think the general idea to return a separate 'reflection info struct' instead of a bunch of functions would make sense, e.g. instead of a function which returns the number of uniforms in a uniform block, and then another function which returns information about that uniform by index, just have a separate struct which basically contains the same information that we are currently returning in in the YAML file

Another thing is that a lot of the current reflection information won't strictly be needed anymore after the bindings cleanup, because one idea is to introduce a flexible mapping between sokol-gfx bind slots, and 3D backend bind slots, to allow the sokol-gfx bind slot structure to be defined by the user, and to allow 'gaps' in the bindings. For instance the user code should be able to say 'the sokol-gfx texture bind slot number 3 is always the normal map for the lighting formula', no matter if a specific shader variation even uses a normal map. This means that no reflection information would be needed anymore to populate the sg_bindings struct, but only for cases like exposing the interior of uniform blocks to a material editor.

The good news is that all of this are breaking changes anyway, so we don't need to hold back with new ideas (like replacing the current set of runtime reflection functions with a struct).
I would suggest that you could create an experimental PR where we can check the 'look and feel' of such a new way to return reflection information, but to hold back that PR until the resource bindings cleanup is nearing completion (and then maybe integrate that PR into the bindings cleanup branch - there will also be one for sokol-shdc, currently there are only branches in the sokol and sokol-samples repo, and I'm very much at the beginning of that work still).

Yeah, having a fully populated reflection info struct for shaders would be the most ideal and really straightforward to work with - the reflection functions currently are hard to work with when you also don't have the full list of names to pass into them.
 Ideally I could grab the size of a uniform block, allocate that memory, and then lookup the uniform offsets by name to write into that data, ignoring uniforms that don't exist.

Looking into this some, it does seem like making a whole new set of structs just for the Shader Reflection info seems like a lot of duplication when so far it looks like all of these structs have the required info:
ShaderAttrDesc
ShaderUniformBlockDesc
ShaderStorageBufferDesc
ShaderImageDesc
ShaderSamplerDesc
ShaderImageSamplerPairDesc
ShaderStageDesc
ShaderDesc

And this one is missing just the offset:
ShaderUniformDesc
Does it make sense to add the offset field to ShaderUniformDesc and re-use that same set of structs between both shader creation as it is now, and for the fully populated reflection info?

That was exactly my thinking when I thought about integrating the reflection info into the shader-desc struct, but after the bindings cleanup those structs will drop some information (like any string names), and other structs would need to be extended with information that's only useful for user code as reflection info, but not needed in sokol-gfx for resource binding.
That's why I think it's better to build a separate reflection info struct, even if it partly overlaps with the shader-desc structs.


cc-wrapper-test: support cross compilers

Motivation for this change
Run compiled check programs under an emulator, in order to make cc-wrapper tests work with cross compilers.
Things done

Built on platform(s)

[ ] x86_64-linux
[x] riscv64-linux (cross)
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 163117 run on aarch64-darwin 1

Emulator is an empty string when not cross-compiling? Or does it always use qemu now?

Emulator is an empty string when not cross-compiling? Or does it always use qemu now?

It would be sh if I remembered correctly.

Also, this seems to be broken on Darwin if I understand what @siraben posted. Can we prevent that?

Removed the platform restrictions and did a rebase, however cc-wrapper-gcc is now failing on aarch64-linux, complaining error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory, which, is in the rpath of the binary in question.

I also found that the sanitizer tests are broken on Darwin. A comment in the file says that too, but they seem to be enabled anyway... https://hydra.nixos.org/build/199311100/nixlog/2

Seems that sanitizers does not work under qemu-user either.

After disabling sanitizer when cross compiling, the tests now passes on aarch64, I would assume it to be some weird interaction between our cc-wrapper and qemu-user.

@ofborg build tests.cc-wrapper-gcc tests.cc-wrapper-clang

What's wrong with our clang's address sanitizer? It's failing everywhere.

I was wondering the same. It might've been broken already though, lemme check

Found a gcc issue, which is indeed fixed, however clang is still somehow affected, https://bugzilla.redhat.com/show_bug.cgi?id=1950244

This does not looks great: https://hydra.nixos.org/eval/1786622?filter=cc-wrapper&compare=1786593&full=#tabs-still-fail

Thanks for going down the rabbit hole with me. Hopefully this helps a bit :)

I guess I forgot to press the button, thanks!


Update terragrunt.hcl

Ran Plan for dir: . workspace: default
Plan Error
running "/usr/local/bin/terraform plan -input=false -refresh -out \"/atlantis-data/repos/italorafaeltavares/Atlantis/24/default/default.tfplan\"" in "/atlantis-data/repos/italorafaeltavares/Atlantis/24/default": exit status 1
╷
│ Error: No configuration files
│
│ Plan requires configuration to be present. Planning without a configuration
│ would mark everything for destruction, which is normally not what is
│ desired. If you would like to destroy everything, run plan with the
│ -destroy option. Otherwise, create a Terraform configuration file (.tf
│ file) and try again.
╵

Plan Error
parsing atlantis.yaml: yaml: unmarshal errors:
  line 8: field terragrunt not found in type raw.Project
  line 13: cannot unmarshal !!map into string

Plan Error
parsing atlantis.yaml: yaml: unmarshal errors:
  line 12: cannot unmarshal !!map into string

Plan Error
parsing atlantis.yaml: yaml: unmarshal errors:
  line 12: cannot unmarshal !!map into string

Plan Error
parsing atlantis.yaml: yaml: unmarshal errors:
  line 13: cannot unmarshal !!map into string

Plan Error
parsing atlantis.yaml: repo config not allowed to set 'workflow' key: server-side config needs 'allowed_overrides: [workflow]'

atlantis plan

Plan Error
parsing atlantis.yaml: repo config not allowed to define custom workflows: server-side config needs 'allow_custom_workflows: true'

atlantis plan

Ran Plan for dir: . workspace: default
Plan Error
running "/usr/local/bin/terraform plan -input=false -refresh -out \"/atlantis-data/repos/italorafaeltavares/Atlantis/24/default/main-default.tfplan\"" in "/atlantis-data/repos/italorafaeltavares/Atlantis/24/default": exit status 1
╷
│ Error: No configuration files
│
│ Plan requires configuration to be present. Planning without a configuration
│ would mark everything for destruction, which is normally not what is
│ desired. If you would like to destroy everything, run plan with the
│ -destroy option. Otherwise, create a Terraform configuration file (.tf
│ file) and try again.
╵

atlantis apply

Ran Apply for 0 projects:

Locks and plans deleted for the projects and workspaces modified in this pull request:

dir: . workspace: default


hit location for i18n

Ok, got a chance to look at it.    I'm going to reject it mainly because all of the hitlocation stuff is now in module/hitlocation/hitlocation.js and actor.js.      And while I normally agree with removing "magic" strings, we wouldn't be saving much effort here.    Since the actual names of hit locations are really only important during the import, and after that, they are just displayed.   So there is no code in the rest of the system that refers to "LEFT_ARM".    A static for this would only be using during the text matching of the import... and during that, I would prefer see the actual text, instead of referencing back to a list of static variables.

Ok, got a chance to look at it.    I'm going to reject it mainly because all of the hitlocation stuff is now in module/hitlocation/hitlocation.js and actor.js.      And while I normally agree with removing "magic" strings, we wouldn't be saving much effort here.    Since the actual names of hit locations are really only important during the import, and after that, they are just displayed.   So there is no code in the rest of the system that refers to "LEFT_ARM".    A static for this would only be using during the text matching of the import... and during that, I would prefer see the actual text, instead of referencing back to a list of static variables.

OK, not a bother! I have only myself to blame - I took very long to resolve
the merge conflicts. Thanks for the feedback!
Gustavo Tomazi Ludwig
<EMAIL_ADDRESS>https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Jan 22, 2021 at 4:42 PM Chris Normand<EMAIL_ADDRESS>wrote:

Ok, got a chance to look at it. I'm going to reject it mainly because all
of the hitlocation stuff is now in module/hitlocation/hitlocation.js and
actor.js. And while I normally agree with removing "magic" strings, we
wouldn't be saving much effort here. Since the actual names of hit
locations are really only important during the import, and after that, they
are just displayed. So there is no code in the rest of the system that
refers to "LEFT_ARM". A static for this would only be using during the text
matching of the import... and during that, I would prefer see the actual
text, instead of referencing back to a list of static variables.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/crnormand/gurps/pull/171#issuecomment-765540448, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABY65UU5HFKXZOZI72UZDYDS3GTITANCNFSM4V7U5OQA
.

OK, not a bother! I have only myself to blame - I took very long to resolve
the merge conflicts. Thanks for the feedback!
Gustavo Tomazi Ludwig
<EMAIL_ADDRESS>https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Jan 22, 2021 at 4:42 PM Chris Normand<EMAIL_ADDRESS>wrote:

Ok, got a chance to look at it. I'm going to reject it mainly because all
of the hitlocation stuff is now in module/hitlocation/hitlocation.js and
actor.js. And while I normally agree with removing "magic" strings, we
wouldn't be saving much effort here. Since the actual names of hit
locations are really only important during the import, and after that, they
are just displayed. So there is no code in the rest of the system that
refers to "LEFT_ARM". A static for this would only be using during the text
matching of the import... and during that, I would prefer see the actual
text, instead of referencing back to a list of static variables.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/crnormand/gurps/pull/171#issuecomment-765540448, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABY65UU5HFKXZOZI72UZDYDS3GTITANCNFSM4V7U5OQA
.


Sandstone is not generated naturally

I am currently running

SpongeForge version: 1.12.2-2768
SpongeVanilla version: 1.12.2-7.1.5
Java version: 8
Operating System: Linux (dockered debian 8 and fedora 28)

Plugins/Mods: none

Issue Description
On desert biomes (I didn't check beaches) sandstone is not generated naturally. I've tried Sponge versions mentioned above and vanilla Minecraft 1.12.2. On vanilla Minecraft sandstone is generated correctly.
Seed I've checked: -4474001698482465191
Location I've been at: -775 65 -1373
Refer: https://minecraft.gamepedia.com/Sandstone section "Natural generation"

It looks like MixinBiome.buildPopulators() will need to be updated to add an extra GroundCoverLayer when the block is sand or red sand. However, I don't know how to set that up properly to match the vanilla behavior - in vanilla, the depth of sandstone also depends on the height of the ground, which GroundCoverLayer doesn't currently support. The actual code vanilla uses to determine the height (see Biome.generateBiomeTerrain()) is:
if (blocksRemaining == 0 && blockToPlace.getBlock() == Blocks.SAND && layerNum > 1) {
    blocksRemaining = rand.nextInt(4) + Math.max(0, currentY - 63); // currentY is the lowest position that regular sand will be placed
    blockToPlace = blockToPlace.getValue(BlockSand.VARIANT) == BlockSand.EnumType.RED_SAND ? RED_SANDSTONE : SANDSTONE;
}

Isn't it possible to actually provide the Y coordinate to the blockState function inside GroundCoverLayer? It seems doable in org.spongepowered.common.world.gen.SpongeChunkGenerator with slight modification to blockState function signature. I could try to do that myself and provide a PR to fix this issue but I'm not absolutely certain that this is a good approach.

I have a fix ready, pending review of the related SpongeAPI changes.  See https://github.com/SpongePowered/SpongeCommon/pull/2270 and https://github.com/SpongePowered/SpongeAPI/pull/2009.

This right here is the reason why we are tossing our gen API in 8 and layering directly on Vanilla...


Need help accessig a token

Hi, Matthias. I am trying to sign a PDF but encountered the following:
Command:
pyhanko sign addsig --field Sig1 beid --lib /usr/lib/libaetpkss.so ii.pdf o.pdf
Error:
(several lines eliminated...)
raise PKCS11Error(
pkcs11.exceptions.PKCS11Error: Could not find (unique) cert with label 'Root'.
Error: Generic processing error.

Perhaps the issue has to do with beid, but I don't know what to put in place.
Also, It would be very good if you could point me towards a sample code the allows me to sign a PDF using the API instead of using the CLI.
Thank you.
Fernando Cabral

Hi Fernando, thanks for your interest in pyHanko!
The beid subcommand is a convenience wrapper specifically for Belgian eID cards, and presumably your PKCS#11 token has a different layout. You'll want to use the pkcs11 subcommand instead.
$ pyhanko sign addsig pkcs11 --help
Usage: pyhanko sign addsig pkcs11 [OPTIONS] INFILE OUTFILE

  use generic PKCS#11 device to sign

Options:
  --lib FILE          path to PKCS#11 module  [required]
  --token-label TEXT  PKCS#11 token label  [required]
  --cert-label TEXT   certificate label  [required]
  --key-label TEXT    key label
  --slot-no INTEGER   specify PKCS#11 slot to use
  --skip-user-pin     do not prompt for PIN (e.g. if the token has a PIN pad)
                      [default: False]

  --help              Show this message and exit.

It's not quite as "batteries included" as beid, but with the help of a PKCS#11 inspection tool (like this one) you should be able to piece together which parameters to pass to --cert-label, --token-label and possibly --key-label. Let me know how  that goes.
I know that pyHanko's documentation on generic PKCS#11 devices is a bit lackluster, I'll have to do something about that at some point.

Sorry, I didn't notice your other question about API usage.
For more information on signing files using the pyHanko API in general, take a look at the relevant section in the docs. For PKCS#11-specific issues, you might want to get some inspiration from the tests for the PKCS#11 signing code, and the API reference docs for PKCS11Signer.

Matthias, thank you for your help.
I wonder if you have a pointer to PKCS11Signer. It is refered to in the paragraph reproduced bellow, but there is no link, as is one to SimpleSigner (which is not
about PKCS11).
Providing detailed guidance on how to implement your own Signer subclass is beyond the scope of this guide—the implementations of SimpleSigner and PKCS11Signer should help. This subsection merely highlights some of the issues you should keep in mind.
Thank you.
Fernando Cabral
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Em segunda-feira, 7 de junho de 2021 às 16:09, Matthias Valvekens @.***> escreveu:

Sorry, I didn't notice your other question about API usage.

For more information on signing files using the pyHanko API in general, take a look at the relevant section in the docs. For PKCS#11-specific issues, you might want to get some inspiration from the tests for the PKCS#11 signing code, and the API reference docs for PKCS11Signer.

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub, or unsubscribe.[https://github.com/notifications/beacon/AQS4BGQ7HPEMIZCXVSMR5PDTRUKPZA5CNFSM46IHVLI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGMEGKHA.gif]

Oops, that's probably a typo in the rst file from which that page in the docs was generated, I'll fix that.
Here's a link to the API reference for PKCS11Signer:  https://pyhanko.readthedocs.io/en/latest/api-docs/pyhanko.sign.pkcs11.html. Looking at the tests might also be helpful.

Hi Matthias, looking for simpler things to start using pyHanko, I tried to check the signature with the commando pyhanko sign validate a.pdf. Nevertheless, I got the messages I reproduce bellow. The same signature has been correctly found and identified by okular, mypdfsigner and acrobat reader.
~/pyhanko$ pyhanko sign validate a.pdf
2021-06-09 09:17:30,409 - pyhanko.cli - ERROR - An error occurred while validating this signature: sha1
Traceback (most recent call last):
  File "/home/fernando/.local/lib/python3.8/site-packages/pyhanko/cli.py", line 327, in _signature_status
    status = validation.validate_pdf_signature(
  File "/home/fernando/.local/lib/python3.8/site-packages/pyhanko/sign/validation.py", line 1263, in validate_pdf_signature
    status_kwargs = _validate_cms_signature(
  File "/home/fernando/.local/lib/python3.8/site-packages/pyhanko/sign/validation.py", line 160, in _validate_cms_signature
    intact, valid = validate_sig_integrity(
  File "/home/fernando/.local/lib/python3.8/site-packages/pyhanko/sign/general.py", line 750, in validate_sig_integrity
    raise WeakHashAlgorithmError(md_algorithm)
pyhanko.sign.general.WeakHashAlgorithmError: sha1
Signature1:37e897b3a8e2095f2dc286ddf487e707a5cfc9260726a65252e9e47a3fbf8f17:INVALID

Any hints?

Well, I made the command line work. Neverthess, I couldn't find a way to control font size for the stamp-styles.
Is there a way to specify the font size?

I tried to check the signature with the commando pyhanko sign validate a.pdf. Nevertheless, I got the messages I reproduce bellow. The same signature has been correctly found and identified by okular, mypdfsigner and acrobat reader.

As the error message indicates, pyHanko is complaining that the signature uses a weak hashing algorithm (SHA-1), not that it doesn't find the signature. SHA-1 is broken, and it's a shame that none of the big name PDF readers actually make a stink about that. The industry is very averse to breaking compatibility with older workflows...
You can't turn off this behaviour from the CLI right now, but if you're an API user you can pass in a different set of weak hash algorithms to your ValidationContext. The default list includes SHA-1, MD5 and MD2.

Is there a way to specify the font size?

The TextBoxStyle you pass to a text stamp style has a font_size parameter that you can use. That said, the stamping routine's auto-scaling might get in the way of that. All things considered, pyHanko's appearance generation code isn't very good, and I'm working on some improvements in that department, but it's a slow process.

Thank you, Matthias. With your help I am almost there.
I don't understand why pyHanko can't build a "validation path". As far as I can see, all the information is available on the token. See error message bellow:
  raise PathBuildingError(pretty_message(
pyhanko_certvalidator.errors.PathBuildingError: Unable to build a validation path for the certificate "Common Name: FERNANDO JOSE CASTRO CABRAL:12436666687; Organizational Unit:<PHONE_NUMBER>0115, AR CONFIANCA EMPREENDIMENTOS DIGITAL, VALID, RFB e-CPF A3, Secretaria da Receita Federal do Brasil - RFB; Organization: ICP-Brasil; Country: BR" - no issuer matching "Common Name: AC VALID RFB v5, Organizational Unit: Secretaria da Receita Federal do Brasil - RFB, Organization: ICP-Brasil, Country: BR" was found

To me, at least, the trust chain seems to be correct and complete.

Matthias, sorry for bothering you with small stuff like this, but I couldn't find any references on the docs.
Is there a way to pass the user pin on the CLI? Or perhaps in the configuration file?
(I understand it can be done with the API, but at this moment I am trying to fully understand the CLI before adventuring into the API).
Thank you

Hmmm, I thought that Python's getpass would also work if stdin is not a TTY (thus allowing you to pass the PIN with a pipe), but apparently that's not the case. So for now, the answer seems to be 'no'.
I'll put in some plumbing around getpass to make that possible. I could also put in a flag to read the PIN code from a file, if that's easier. Putting it in the configuration file is something I'd prefer to avoid, though.
I'm also not planning to provide an easy option to pass the PIN as a command line argument directly. On a typical Linux system, the argument list of any given process is globally visible, which is problematic. That kind of exposure can be acceptable for a file password (hence why the decrypt command does have a --password flag for those who really want it), but for a PKCS#11 token PIN, the stakes are quite a bit higher.
I've added it to the backlog :)

Hmmm, I thought that Python's getpass would also work if stdin is not a TTY (thus allowing you to pass the PIN with a pipe), but apparently that's not the case. So for now, the answer seems to be 'no'.
I'll put in some plumbing around getpass to make that possible. I could also put in a flag to read the PIN code from a file, if that's easier. Putting it in the configuration file is something I'd prefer to avoid, though.
I'm also not planning to provide an easy option to pass the PIN as a command line argument directly. On a typical Linux system, the argument list of any given process is globally visible, which is problematic. That kind of exposure can be acceptable for a file password (hence why the decrypt command does have a --password flag for those who really want it), but for a PKCS#11 token PIN, the stakes are quite a bit higher.
I've added it to the backlog :)
EDIT: You should be able to input your PIN from the terminal prompt, though, unless your PKCS#11 token manages its own PIN input (that sometimes happens). In that case, you should use the --skip-user-pin flag.

I understand your point. The problem I face is that I use to call the pdf signer from my text editor (libreoffice). Using a python macro and subprocess.run(), I can save the odt file, create a PDF from the same file, calculate where I want the visible signature to appear, sign the file and have it saved. All with a single command. In this scenario, I don't have access to the standard i/o.
The two solution I know of are jsignpdf, which takes the pin from the command line and mypdfsigner, which takes the pin from a file.
Mypdfsigner's config file accepts an encrypted password. I would guess this is not very safe, but there are some protection since only the file's owner and the administrator could read that file.
As to jsignpdf, I have never checked if the pin provided on the command line lingers around, but I would guess it would be possíble to delete any argument manipulating the sys.argv[] (I'll check if this is true. It used to be many decades ago when linux did not exist, unix was king and C was the preferred language in that environment).
Best regards.

As for putting it in the configuration: I agree that that would probably be fine in terms of leaking information, since you can (as you say) provide some extra protection by setting proper permissions on the config file. I was mostly thinking about setups where you would need to be able to switch between multiple different PKCS#11 setups.
That said, I could maybe add a pkcs11-env section to the configuration file, containing (possibly several) PKCS#11 token configurations, including a PIN if you so desire. You can already do that for validation contexts, so I guess it makes sense to extend the same courtesy to PKCS#11 settings. Would that work?

I see. About putting it in the configuration: I agree that that would probably be fine in terms of information leaks, since you can (as you say) provide some extra protection by setting proper permissions on the config file. I was mostly thinking about setups where you would need to be able to switch between multiple different PKCS#11 setups.
That said, I could maybe add a pkcs11-env section to the configuration file, containing (possibly several) PKCS#11 token configurations, including a PIN if you so desire. You can already do that for validation contexts, so I guess it makes sense to extend the same courtesy to PKCS#11 settings. Would that work?

Yes, I think that would work nicely.

Great! Then I'll change the title of this issue accordingly, and slap on an 'enhancement' tag. Thanks for the productive conversation :)

Hi, I've addressed this issue in commit f05b781. I haven't added it to the CLI documentation yet, but in pyHanko 0.7.0 you'll be able to put this in your config file:
pkcs11-setups:
  test-setup:
    module-path: /usr/lib/libsofthsm2.so
    token-label: testrsa
    cert-label: signer
    user-pin: 1234

and invoke it with
 pyhanko sign addsig pkcs11 --p11-setup test-setup input.pdf output.pdf

I'll close this issue now. Feel free to reopen if you have other questions related to this particular item, but please open a new issue for any other questions you might have. Thanks!

PS: Last weekend, I also pushed the first "batch" of the appearance generation code overhaul I've been working on for the last couple of weeks or so. It's not quite where I want it yet, but provided that I manage to expose enough of the new settings from the configuration file by the time 0.7.0 rolls around, you should get some more control over your signature appearances as well.


⚠ Bofrost.de has degraded performance

In e06cb3c, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1163 ms

Resolved: Bofrost.de performance has improved in 17f20a6 after 41 minutes.


Run autoformat for *.yml files too

Summary
autoload configs for YAML files only consider the .yaml extension,
which makes the plugin ignore autoformat-on-save settings on .yml
files. As the latter is a very common format, I thought of including
that to the list.
Test Plan
Tested this out in my local copy on both yaml and yml files. Ran
yarn run tests, and they pass.

Oops, should've seen #246


Minimum Azure CLI requirement confusion

This page states that 2.0.49 is required, but https://github.com/Azure/azure-devops-cli-extension states that 2.0.69 is required

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 97bc681f-09a5-d6ad-bf6f-46d644cd2c8e
Version Independent ID: 0431d071-1fdd-70a2-25cd-742ddca6cfcc
Content: Learn about Azure DevOps command line interface extension - Azure DevOps
Content Source: docs/cli/index.md
Product: devops
Technology: devops-ref
GitHub Login: @KathrynEE
Microsoft Alias: geverghe

@KathrynEE -- please review private PR 1350.


refactor(reqresp)!: add ReqResp async iterable to events

Motivation

See https://github.com/ChainSafe/lodestar/issues/5379

Description
Implement async iterable bridge to handle both incoming and outgoing requests. Emitter and handler are in the same thread, which is currently pointless but necessary for moving libp2p to a thread.

Superseeded by libp2p thread PR


Preliminary version see #381

Preliminary version of a parent mixin class for AnalogSignal and IrregularlySampledSignal -- Issue #381

Coverage decreased (-0.03%) to 49.77% when pulling cdc42843aae581f5b18ba70cd5597ebea2be12f4 on msenoville:issue381 into dcf9f1bb2f3735d0fd9e508bacdbb318879c6ba7 on NeuralEnsemble:master.

OK for me. Thank you!


Fix Windows delaylink generation for qemu-plugin.symbols removal

qemu-plugin.symbols is to be removed (https://gitlab.com/qemu-project/qemu/-/commit/8ac1719df75cba01e7095e990265b957aed4f1c2) so we need to figure out what to do about Windows delaylink library generation. Unfortunately I think this leaves three options:

Build QEMU and look for symbols
Parse the header file
Maintain our own list

I'm kind of partial to #2 since this is a development-time list, so we'll be able to fix any issues, and it doesn't require us to manually keep it up to date.
@tocklime let me know if you have any thoughts, since this only affects Windows.

Actually now that I work at Microsoft maybe I should start putting some effort into the Windows side, but the only Windows PC I have is my work computer 😋


Add nbest translation (continued)

This is an update of #532, as @bricksdont is currently busy.
Important: To preserve ownership of the changes, don't squash when merging.
Pull Request Checklist

[x] Changes are complete (if posting work-in-progress code, prefix your pull request title with '[WIP]'
until you can check this box.
[x] Unit tests pass (pytest)
[x] Were system tests modified? If so did you run these at least 5 times to account for the variation across runs?
[x] System tests pass (pytest test/system)
[x] Passed code style checking (./style-check.sh)
[x] You have considered writing a test
[x] Updated major/minor version in sockeye/__init__.py. Major version bump if this is a backwards incompatible change.
[x] Updated CHANGELOG.md

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks for figuring out what was wrong with the test! Looks good to me (I know my vote does not count :-).

Everyone's really busy, but this is a very useful feature to have I think, so I took the liberty and addressed the last comments here, @davvil @tdomhan.

Thanks for this! It fell under my radar again, although I have been using it extensively since the PR.
When merging we should make sure that @bricksdont contributions don't get lost. I'll organize the merge with @tdomhan.

Agreed this is really @bricksdont work. If not squashing would create too many individual commits, I would suggest squashing it and changing the commit author to @bricksdont.


Add "direct to binary" option for DaciukMihovAutomatonBuilder and use it in TermInSetQuery#visit

Description
Adds the ability to directly build a binary automaton for a string union using the Daciuk-Mihov algorithm, and uses it to make the TermInSetQuery#visit implementation a little more optimal. I'm hoping we end up moving to an automaton approach in general for TermInSetQuery (see #12312), but I think this is a good iterative step for now, as suggested by @rmuir / @mikemccand in #12310.

Updated based on the prior feedback, except for one outstanding testing suggestion. I'll have a look at that soon. I think the builder logic is much cleaner now between building string/binary automata.

Resolving the class naming conflicts from main was a bit of a hassle with an incremental git history.

Woops, sorry!

Thanks @mikemccand! Did a pass to address your comments. Much appreciated! I also added some testing around the minimization aspect of the automaton building. I think all feedback has been addressed at this point, but no rush on having another look. Thanks again!

Thanks @mikemccand! Appreciate you making time for this! 🎉

We have had 3 failures of TestStringsToAutomaton on Policeman/Apache Jenkins since this change was merged that we were not getting before, so I wonder if it's related. I opened https://github.com/apache/lucene/issues/12451 earlier today that has a reproducible seed.

Thanks @jpountz. I'll have a look soon.


Temporary fix for widen-search-field

Technically fixes #2435

GitHub made some weird changes to their css regarding .subnav selector on Issues and Pull Requests pages. It looks like they are migrating from the old .float-left/right model to flexbox, but at the same time they ignore existing "semantic" classes.
You can also see it on the Releases page where they are using the old .subnav and .d-flex.flex-justify-between.
I would call this PR a temporary workaround until things settle down with GitHub changes. Also, we should probably expect some more broken features soon.
Test

Open issues or pull request page and see.

The .subnav is used across the site so I’m not keen on merging temporary fixes that aren’t tested on all pages where that bar appears.
Either it’s tested and not temporary or we can’t risk merging this and breaking another part 😅

Makes sense, in that case it would be best to disable this feature for the time being.

I use Stylus extension to add custom css and fix this. unset keyword works fine too.
It will be the same as just delete these two selectors, i think ?

Issue page

Pull requests page

Labels page

Needs further testing, but this fixes the height. widen-search-field however remains broken.
It can be merged before the next release (in 13 hours) unless bugs are found.


wrong day numbers

Environment
"@material-ui/core": "1.0.0-rc.1",
"material-ui-pickers": "1.0.0-rc.9",

Actual behavior

The numbers are starting with 1 on the first of january and are rising to 365 in december.
Steps to reproduce
I have absolutely no idea how to reproduce it. This seems to happen since around @material/core 1.0.0-rc.  Some of the builds SEEM very rarely to be working though and the numbers of the days are correct again. Maybe an issue with semantic versioning? I tried to fix all relevant versions in my package.json. But no luck. This is just a guess! It's happening very often. And maybe the working builds are just some cache issues.
I'm on it for several hours now. But I really am out of ideas how to fix it...
A downgrade to
"material-ui": "^1.0.0-beta.47",
"material-ui-pickers": "1.0.0-rc.7",

seems to fix the issue permanently.

 Sorry for the duplicate. The issue was indeed semantic versioning of "date-fns": "^2.0.0-alpha.7"


🎉  All pages in /overview are finished!

🎉 For now, all pages in /overview are finished!

nice work!


HARP-5925: Sky and ground atmospheric scattering for globe projection.

Provide physical approximation of real life atmospheric scattering effect.
Patchset includes:

MapViewAtmosphere - main atmosphere controller exposed for the users,
GroundAtmosphereMaterial - material with a shader approximating rayleigh
and mia scattering effect visible on globe surface,
SkyAtmosphereMaterial - material containing shader for simulation of
atmosphere around the globe,
AtmosphereChunks - GLSL shader chunks with common functions used withing
the shaders,
rendering_globe-atmosphere - example showing use case with spherical
projection,
Atmosphere interface - base Theme interface for further theme based
configuration.

Signed-off-by: Krystian Kostecki<EMAIL_ADDRESS>Thank you for contributing to harp.gl!
Before requesting a pull request, please remember to check the following documents:

contribution guidelines
coding style

If you are adding new functionality we would highly appreciate if you can describe what is the capability you are adding and even better if you can add some examples. Please also remember to add tests for it.
CI Check
Our bots will check whether your PR can be directly integrated into the mainline. We have some internal integration tests running on the background, our bots will inform you of the next steps and someone from our team will take a look and help if needed!
And please do not forget to sign-off your commit! You can read more about DCO here. But, in short, you just need to use git commit -s or append --signoff when you are committing to the repo.
Happy contributing!

Codecov Report

Merging #1378 into master will decrease coverage by 0.31%.
The diff coverage is 11.55%.

@@            Coverage Diff             @@
##           master    #1378      +/-   ##
==========================================
- Coverage   54.25%   53.93%   -0.32%
==========================================
  Files         256      257       +1
  Lines       23493    23710     +217
  Branches     5268     5318      +50
==========================================
+ Hits        12745    12788      +43
- Misses      10748    10922     +174

Impacted Files
Coverage Δ

@here/harp-datasource-protocol/lib/Theme.ts
100% <ø> (ø)
:arrow_up:

@here/harp-mapview/lib/ClipPlanesEvaluator.ts
51.7% <0%> (ø)
:arrow_up:

@here/harp-mapview/lib/MapViewAtmosphere.ts
10.61% <10.61%> (ø)

@here/harp-mapview/lib/MapView.ts
61.03% <100%> (-2.13%)
:arrow_down:

@here/harp-materials/lib/SkyAtmosphereMaterial.ts
8.45% <8.45%> (ø)

...ere/harp-materials/lib/GroundAtmosphereMaterial.ts
8.45% <8.45%> (ø)

@here/harp-mapview/lib/DataSource.ts
79.12% <0%> (-7.47%)
:arrow_down:

...re/harp-mapview/lib/geometry/overlayOnElevation.ts
43.13% <0%> (-3.68%)
:arrow_down:

...e/harp-mapview/lib/geometry/TileGeometryManager.ts
32.67% <0%> (-1.95%)
:arrow_down:

... and 15 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7313c34...7eb4c40. Read the comment docs.

I think the branch just needs to be rebased for IBCT to pass(a shadow rendering test is falining).


locale in URL

hello,
is there a way to have in url : ....app_dev.php/pt-br/admin/post/
instead of : app_dev.php/pt_BR/admin/post/
there are some recommendations in SEO to not use underscore symbol and avoid uppercase
thank you,

The first thing to take into account is that pt_BR is the valid locale for the Brazilian Portuguese language and pt-br is not.
If the locale is correct, Symfony handles everything automatically, saving you a ton of work. If you want to use a value that is not a valid locale, you must treat it like any other routing parameter and do all that work yourself. We can't change the Symfony Demo app because of that and I'd say is a good trade-off to not do that in any of your applications either.

I'm closing this as "won't fix" because of the above reasons: the effort required to change this is not worth it for the Demo app. Thanks!


Use pytorch to run the lua in eval?

Hi,
Noticed you have python calling java, and then communicating with lua via json files.
Just so you know, pytorch lets you run lua classes directly from python :-)
pytorch is here: https://github.com/hughperkins/pytorch
Example usage here:

https://github.com/hughperkins/cifar.pytorch
https://github.com/hughperkins/pytorch-residual-networks

(since this isnt an issue, but just for info, I will close this)

Is there a pytorch version of this code?

Hugh was talking about a previous project called pytorch which is unrelated to the new framework from FAIR.
There is not yet a PyTorch implementation of DenseCap as far as I know.

@jcjohnson Thanks!


Profile tool: fix printing of task failed reason

In the profiling tool task failed table, we were just doing a toString on the task end reason. This caused it to some times have an address in the output and that address could change between runs.  Fix it so we use the toErrorString to get the nicely formatted string.

build

build


update docs

Bringing the docs up to speed and giving them a bit of an overhaul where necessary. Would like to improve the styles/readability a bit while we're at it

Partial TODO (will add to this as I think of stuff):

[ ] AMP
[ ] CLI
[ ] Adapters
[ ] Configuration

What's the idea behind renaming some of the docs to xx-? Will they still show up? If so, in what order?

the xx- docs are things that i want to get rid of, but which contain paragraphs that might be useful. they are excluded from the page


add csv-export

closes #334

is it necessary to have an endpoint to download all data in the database (which then also includes the suggestions, projectsuggestions and requiredskills tables) or are these enough?
@lisadejonghe

I don't really know very well which fields will be returned, but if the project on which a student/coach is assigned and how a student got accepted etc. will be in the csv export, it's good for me :).

i have changed the endpoints to return zip files containing multiple csv files instead of one csv file
now all requested data should be included


BearLibTerminal ignores keyboard layout

In linux, changing the X11 keyboard layout does not affect BearLibTerminal applications.

Check with BLT itself, as I doubt we change anything thereregarding in the Rust FFI.
On another note, updating https://github.com/nabijaczleweli/BearLibTerminal with trunk might be helpful.

I repushed the v1.3.1 tag, so hopefully new features/bugfixes will land in binary form there soon.


Add a context id to streaming requests

Add a context id that will be used to uniquely identify when the context for a completion changes

This will be used to link requests/streams that are related to the same completion

It will be used by the frontend to determine when a response is no longer valid and should be discarded rather than being added to the notebook.

buf push
buf.build/jlewi/foyle:86c4c8cbe96c4a4a94604f4609919b84


fix(docs): line space

close https://github.com/dream-num/univer-pro/issues/1777

Pull Request Checklist

[x] Related tickets or issues have been linked in the PR description (or missing issue).
[x] Naming convention is followed (do please check it especially when you created new plugins, commands and resources).
[x] Unit tests have been added for the changes (if applicable).
[x] Breaking changes have been documented (or no breaking changes introduced in this PR).

问题1：
还是选中了部分内容

问题2：
场景2未修复https://github.com/dream-num/univer-pro/issues/1793

@oumomomo 刚才是不是没有 build 好？我刚才试了下，是好的。场景 2 没有修复。另外的 PR 修复


webrick

This must be the only web server I've ever seen, without a single console/network warning!
Please run
bundle add webrick

I can make a pull request, as you like

That will be great, please go ahead. Thanks a lot.

https://github.com/abhinavs/cookie/pull/7

Thanks for the PR - merged it.


Change default title for flex_corr_matrix function

Inside the flex_corr_matrix(), the title defaults to Cervical Cancer Data: Correlation Matrix if the title parameter is omitted.

Fixed: Title has been reset to None, unless user specifies it.


cache Response.text

Response.text is a pure function, seems pointless doing the same conversions in repeated calls.
Cached
In [4]: %timeit any(word in resp.text for word in words)
The slowest run took 6.20 times longer than the fastest. This could mean that an intermediate result is being cached
100000 loops, best of 3: 17.4 µs per loop

Not cached
In [5]: %timeit any(word in resp.text_old for word in words)
10000 loops, best of 3: 64.4 µs per loop

len(words) == 3 in these examples, in a real world use case it could be much longer.

Thanks for this! However, requests.text is not a pure function, and cannot be safely cached. This is actually explicitly called out in the docs:

If you change the encoding, Requests will use the new value of r.encoding whenever you call r.text.

This is intentional and desirable. For this reason, we want to prevent text from being cached.
Sorry we can't accept your contribution! =(


Add Web Browsers

Awesome List URL: Awesome Web Browsers
PRs reviewed #1623 #1640 #1655
Ran awesome-lint with successful output:
✔ Linting

[Explain what this list is about and why it should be included here]

A list of various web browsers to use or develop for.
This list is unique as it exposes readers to the different web browsers that exist, not just the popular ones or the ones that come installed on our computers or phones.

By submitting this pull request I confirm I've read and complied with the below requirements 🖖
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
Requirements for your pull request

Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
You have to review at least 2 other open pull requests.
Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration.
You have read and understood the instructions for creating a list.
This pull request has a title in the format Add Name of List.

✅ Add Swift
✅ Add Software Architecture
❌ Update readme.md
❌ Add Awesome Swift
❌ Add swift
❌ Adding Swift
❌ Added Swift

Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.

✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
✅ - [Framer](…) - Prototyping interactive UI designs.
❌ - [iOS](…) - Resources and tools for iOS development.
❌ - [Framer](…)
❌ - [Framer](…) - prototyping interactive UI designs

Your entry should be added at the bottom of the appropriate category.
The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.
Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
Includes a succinct description of the project/theme at the top of the readme. (Example)

✅ Mobile operating system for Apple phones and tablets.
✅ Prototyping interactive UI designs.
❌ Resources and tools for iOS development.
❌ Awesome Framer packages and tools.

It's the result of hard work and the best I could possibly produce.
If you have not put in considerable effort into your list, your pull request will be immediately closed.
The repo name of your list should be in lowercase slug format: awesome-name-of-list.

✅ awesome-swift
✅ awesome-web-typography
❌ awesome-Swift
❌ AwesomeWebTypography

The heading title of your list should be in title case format: # Awesome Name of List.

✅ # Awesome Swift
✅ # Awesome Web Typography
❌ # awesome-swift
❌ # AwesomeSwift

Non-generated Markdown file in a GitHub repo.
The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
Not a duplicate. Please search for existing submissions.
Only has awesome items. Awesome lists are curations of the best, not everything.
Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
Includes a project logo/illustration whenever possible.

Either centered, fullwidth, or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
Includes the Awesome badge.

Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics header.

Should link back to this list.

Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of nested lists, preferably none.

Has an appropriate license.

We strongly recommend the CC0 license, but any Creative Commons license will work.

Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=master&template=cc0-1.0 (replace <user> and <repo> accordingly).

A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
Place a file named license or LICENSE in the repo root with the license text.
Do not add the license name or text to the readme. GitHub already shows the license name at the top of the repo.
To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.

Has contribution guidelines.

The file should be named contributing.md. Casing is up to you.

Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

Doesn't include a Travis badge.You can still use Travis for list linting, but the badge has no value in the readme.
Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

unicorn 🦄

I think the list would be more useful if each entry had a description of what makes that specific browser special, its strengths.

A list of awesome web browsers for Desktop => A list of awesome web browsers for desktop

Includes a project logo/illustration whenever possible.
The image should be high-DPI. Set it to maximum half the width of the original image.

Includes a succinct description of the project/theme at the top of the readme. (Example)

This should include the purpose of the list. "What's the point of listing web browsers?"

For this comment, I would like to add – you should complete the sentence with a dot, please.

Thanks for the feedback! I agree:

I think the list would be more useful if each entry had a description of what makes that specific browser special, its strengths.

I'll spend some time thinking about it more and update.

From the guidelines:

Do not add the license name or text to the readme. GitHub already shows the license name at the top of the repo.

I would say that also accounts for:
License

Market share percentage would be a nice addition too

The image link is not complying with the guidelines:

The image should link to the project website or any relevant website.

Bump :)

I decided to rename master branch to main, and apparently that permanently closes all PRs. Ugh. Sorry about that. Can you reopen this PR targeting the main branch? Include a link to this PR in the new one, so we can quickly see what was discussed previously.


Add styling mixins for the overlay buttons

Users should be able to apply CSS rules for the following elements and states:

the cancel button
the today button

default state, selects today and closes the overlay
scrolling state, scrolls to today instead of selecting it (2 states):

today is before the current visible dates
today is after the current visible dates

disabled state, does nothing

The new Polymer 2 version, with ThemableMixin solves the main issue described here. The different states for the Today button remain, but I’m no longer considering those as a requirement.


fix(LookingGlassXRDevice): override backbuffer FBO in immersive sessions

Whenever gl.bindFramebuffer is nulled to render to the default canvas FBO, the immersive WebXR popup window results in a black, cleared canvas. This is because the polyfill expects all user-rendering to target XRWebGLLayer. I've redirected null (canvas backbuffer) FBO bindings to the live XRWebGLLayer.framebuffer to preserve DOM behavior in an immersive session.
I've committed a local reproduction case based on this gist for iteration. I've since reverted it in https://github.com/Looking-Glass/looking-glass-webxr/pull/5/commits/2578c265ec6248cf8ce252ed0623c5a0c9bb178c, but you can pick it locally for testing.

Thanks for the PR Cody!
So I've added your test gist into the main branch under the examples folder, however upon attempting to test your PR here I noticed some odd behavior.
It seems that modifying the view count isn't quite behaving as expected , the main canvas seems to only be rendering 16 of the views, instead of the full 45.
when loading the example gist, I get the following result:

running the same gist on main, with the userland fix does display the correct result:

As per our discussion @BryanChrisBrown - seems to be rendering all the views but we're only seeing the bottom left-hand corner. Could be an issue with the texture being cropped somehow?

Could be an issue with the texture being cropped somehow?

This would be my only explanation for why we're seeing different behavior than with the user-land fix. I've encountered this earlier when describing blurry behavior after blitting, and I believe it's because of the same issue.

After some further investigation into this issue today I've determined that this issue is due to the blitting function itself, since the blit is happening to a canvas that is a different resolution than the main frame buffer than the views are rendered into.
And so, the "cropped" portion actually matches the resolution of the display, while the views are still rendered at the original size of the framebuffer, but not shown.
I'm still diagnosing the exact cause of this but once it's resolved we should be able to merge this code into main.


Add AudioVideo Audio to .desktop builds in linux

Fixes #853

@MarshallOfSound this follows the freedesktop.org .desktop file spec:
https://standards.freedesktop.org/menu-spec/latest/apa.html


Exclusive doesn't seem to work

Bug Report
Current Behavior
All queues were triggered by quirrel at the same time, causing certain third-party rate limits to be hit, and all the processes to fail.
await RaffleQueue.enqueue(null, {
	id: sanityProduct.shopifyId, // IDs were all different
	override: true,
	exclusive: true,
	runAt: new Date(sanityProduct.date) // six of these dates were the same
})

Expected behavior/code
I expected Quirrel to callback one-by-one, waiting for each to finish before calling another.
Environment

Quirrel version: 1.7.0
Node/npm version: Node 14

Possible Solution

Additional context/Screenshots

Hi @mattjis! I tried reproducing your issue as part of Owl (Quirrel's custom queueing library): https://github.com/quirrel-dev/owl/pull/176 While I found an unrelated bug as part of this, it doesn't seem like I could replicate what you're seeing. Can you confirm this errors because of concurrent calls? "Shopify didn't receive the orders correctly" could point towards something entirely different.

@Skn0tt Thanks for looking in to this!
The "Shopify didn't receive the orders correctly" is an error thrown by my application when it's getting errors back from Shopify. These errors were because the rate limit was being hit.
I'm going to double check all of my code again and make sure there's nothing that would allow it to ever hit this limit (as long as it's not running concurrently). I'll update this soon.

@Skn0tt I am able to reproduce the issue in my local environment.
Shall I just paste the 2 test files below?

Great, please paste your test files, yes!

scheduler.js
import Queue from "pages/api/quirrel/queue"

function generateRandomID() {
	return String(Math.floor(Math.random() * Date.now()))
}

async function handler(req, res) {
	const inTenSeconds = new Date()
	inTenSeconds.setSeconds(inTenSeconds.getSeconds() + 10)

	await Queue.enqueue(null, {
		id: generateRandomID(),
		override: true,
		exclusive: true,
		runAt: inTenSeconds
	})

	await Queue.enqueue(null, {
		id: generateRandomID(),
		override: true,
		exclusive: true,
		runAt: inTenSeconds
	})

	await Queue.enqueue(null, {
		id: generateRandomID(),
		override: true,
		exclusive: true,
		runAt: inTenSeconds
	})

	await Queue.enqueue(null, {
		id: generateRandomID(),
		override: true,
		exclusive: true,
		runAt: inTenSeconds
	})

	await Queue.enqueue(null, {
		id: generateRandomID(),
		override: true,
		exclusive: true,
		runAt: inTenSeconds
	})

	return res.json({
		success: true
	})
}

export default handler

queue.js
import { Queue } from "quirrel/next"

export function sleep(ms, result) {
	return new Promise((res) => setTimeout(res, ms, result))
}

export default Queue("api/quirrel/queue", async (payload, meta) => {
	console.log("Begin processing, this will take 5 seconds...")
	await sleep(5000)

	console.log("Processing complete.")
	return
})

The console log looks like the following:
[0] Received job to api/quirrel/queue:  null
[0] Begin processing, this will take 5 seconds...
[0] Received job to api/quirrel/queue:  null
[0] Begin processing, this will take 5 seconds...
[0] Received job to api/quirrel/queue:  null
[0] Begin processing, this will take 5 seconds...
[0] Received job to api/quirrel/queue:  null
[0] Begin processing, this will take 5 seconds...
[0] Received job to api/quirrel/queue:  null
[0] Begin processing, this will take 5 seconds...
[0] Processing complete.
[0] Processing complete.
[0] Processing complete.
[0] Processing complete.
[0] Processing complete.
[2] ✔ Successfully executed<PHONE_NUMBER>03.
[2] ✔ Successfully executed<PHONE_NUMBER>60.
[2] ✔ Successfully executed<PHONE_NUMBER>67.
[2] ✔ Successfully executed<PHONE_NUMBER>695.
[2] ✔ Successfully executed<PHONE_NUMBER>47.

I would expect it to execute one-by-one, instead of all at the same time.

That is indeed wrong behaviour. Will take a look in the coming days. Is this urgent for you, or can it wait until next week?

We'd love to get it fixed. I've advised my team that they need to make sure nothing ends at the same time (which would trigger these concurrent executions) so I'm not expecting any new errors while they're obeying this workaround.
So it's not URGENT urgent. As long as we don't forget, it should be fine.

I was able to reproduce the behaviour in #733. Will debug tomorrow.

Fixed & released in v1.7.1!


WIP: Critical CSS

Jira
(Enter a link to the Jira issue this PR applies to, if any)
Summary
(Enter a one-line summary of the changes in this PR.  This will be included in the release notes)
Details
(Explain the changes in enough detail fo reviewers to understand.  Raise any questions for reviewers to consider.)
How to test
(List clear steps to test that the changes are working)

@colbytcook closing, code is out of date and I'm not sure this is a strategy we want to implement going forward.


Error when calculating model´s bound box in case of nested models with components

Error when calculating model´s bound box in case of nested models with components. In this case, as component is not in the main model, it bound box is not used in calculation.

sample_with_issue.zip
sample_works.3mf.zip
Sample with similar data, the issue happens when have a reference to a component


Use created_at to find last backup, not number

We use the backup number, which doesn't work when there are imported older backups, and they propagate to the top.

Looks fine, but is there a problem with the current mechanism?

Yep, if you sort by number, the letter prefixes ruin it. I have an open ticket linked in trello for this

Ah, got it. +1.


Inconsistent behaviour between CPUParticles2D and GPUParticles2D when changing node parameters in _process

Godot version
4.0 Alpha 16
System information
Windows 10 (x64), Vulkan, nVidia GTX 980 Ti
Issue description
Background to my issue / what I'm trying to achieve:
I'm emitting particles at the mouse cursor position.  When moving the mouse around the screen, this results in "gaps" between the emitted particles (due to the delta time between render frames).  What I'd like to do, is emit them along a "Line" emission_shape, however, since this doesn't exist, I've resorted to selecting a "Box" / "Rectangle" emission_shape, and then rotating the Node based on the angle between consecutive _process frames.
This "hack" works well for CPUParticles2D, but does not work for GPUParticles2D.  I'm not sure if this inconsistent behaviour is intended, so I'm relying on others who are more familiar with the specific implementations to inform me if this is correct.

Steps to reproduce
Repro project attached
Create two nodes, 1x CPUParticles2D and 1x GPUParticles2D.  Configure them to each emit 10,000 particles with 0 gravity.  Change their respective emission_shape properties to either "Rectangle" (CPUParticles2D) or "Box" (GPUParticles2D).
Test each node separately by toggling the other node's visibility.
CPUParticles2D script:
extends CPUParticles2D

var mouse_pos = Vector2.ZERO
var prev_pos = Vector2.ZERO

func _process(delta):
	mouse_pos = get_global_mouse_position()
	self.position = lerp(prev_pos, mouse_pos, 0.5)
	self.rotation = prev_pos.angle_to_point(mouse_pos)
	self.emission_rect_extents.x = prev_pos.distance_to(mouse_pos) / 2
	prev_pos = mouse_pos

GPUParticles2D script:
extends GPUParticles2D

var mouse_pos = Vector2.ZERO
var prev_pos = Vector2.ZERO

func _process(delta):
	mouse_pos = get_global_mouse_position()
	self.position = lerp(prev_pos, mouse_pos, 0.5)
	self.rotation = prev_pos.angle_to_point(mouse_pos)
	self.process_material.emission_box_extents.x = prev_pos.distance_to(mouse_pos) / 2
	prev_pos = mouse_pos

Minimal reproduction project
Particles_Repro.zip

When moving the mouse around the screen, this results in "gaps" between the emitted particles (due to the delta time between render frames).

See also https://github.com/godotengine/godot/issues/47973.

Can you reproduce this if you disable Interpolate in GPUParticles? Also try changing Fixed FPS to 60, 0 or 1000.

When moving the mouse around the screen, this results in "gaps" between the emitted particles (due to the delta time between render frames).

See also #47973.

Disabling "Interpolate" had no effect.  Changing the "Fixed FPS" to either 0 or 1000, however, appeared to fix the issue.  I'm not entirely sure how this property works though - will this solution still work on lower-spec systems if the render FPS is low?
I also just noticed that CPUParticles2D has this Fixed FPS set to 0 by default, which is what gave it the smooth behaviour.  If I change the CPUParticles2D "Fixed FPS" to 30 (to match the default value on GPUParticles2D), then it has the same choppy behaviour.

I'm not entirely sure how this property works though - will this solution still work on lower-spec systems if the render FPS is low?

It should keep working – you most likely weren't rendering at 1000 FPS, yet setting Fixed FPS to 1000 did the trick :slightly_smiling_face:

I'm not entirely sure how this property works though - will this solution still work on lower-spec systems if the render FPS is low?

It should keep working – you most likely weren't rendering at 1000 FPS, yet setting Fixed FPS to 1000 did the trick 🙂

If I change the CPUParticles2D "Fixed FPS" to 30 (to match the default value on GPUParticles2D), then it has the same choppy behaviour.

CPUParticles doesn't have interpolation, unlike GPUParticles.

Is there any reason why "Fixed FPS" shouldn't just always be set to the highest possible value?  What are the tradeoffs of choosing, say 30fps versus 1000fps?

Is there any reason why "Fixed FPS" shouldn't just always be set to the highest possible value? What are the tradeoffs of choosing, say 30fps versus 1000fps?

Lower FPS values save processing power, as values don't need to be recalculated on the GPU as often. This is especially important when attractors and collision are used.

Is there any reason why "Fixed FPS" shouldn't just always be set to the highest possible value? What are the tradeoffs of choosing, say 30fps versus 1000fps?

Lower FPS values save processing power, as values don't need to be recalculated on the GPU as often. This is especially important when attractors and collision are used.

Gotcha, that makes sense.  As long as that behaviour is preserved at low game FPS, then that would be an acceptable workaround for my purpose.
I'd still love to see an interpolate option, or Line emission_shape added as a longer term solution, but this will work for now.
This issue can probably be closed, as it duplicates #47973.

Closing in favor of https://github.com/godotengine/godot/issues/47973 and https://github.com/godotengine/godot/issues/51318 (not all GPUParticles properties are interpolated yet, even when interpolation is enabled).


Look into submitting adc-streaming for inclusion to conda-forge

We should look into submitting adc-streaming to conda-forge, to make it easy for downstream dependences to install.
This would require creating a feedstock from the current recipe, and understand how we'd want to manage the in-package recipe vs. having it fully in the feedstock.

@mjuric, @spenczar, the current method for determining the version is incompatible with a conda-forge feedstock, since it requires the package to be installed from a git repository and we need to be able to install the package from an archive.
Running command python setup.py egg_info
    fatal: not a git repository (or any of the parent directories): .git
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/tmp/pip-req-build-iqs0q977/setup.py", line 93, in <module>
        version=git_version(),
      File "/private/tmp/pip-req-build-iqs0q977/setup.py", line 32, in git_version
        version = check_output(command.split()).decode('utf-8').strip()
      File "/Users/runner/miniforge3/conda-bld/adc-streaming_1616459830588/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_place/lib/python3.6/subprocess.py", line 356, in check_output
        **kwargs).stdout
      File "/Users/runner/miniforge3/conda-bld/adc-streaming_1616459830588/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_place/lib/python3.6/subprocess.py", line 438, in run
        output=stdout, stderr=stderr)
    subprocess.CalledProcessError: Command '['git', 'describe', '--tags', '--long', '--dirty', '--always']' returned non-zero exit status 128.

Hi Patrick, where is the draft feedstock code (to understand the problem better...)?

Here is the meta.yaml recipe: https://github.com/conda-forge/staged-recipes/pull/14349/files
Here are the logs for a failed job in the PR (now closed): https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=294010&view=logs&jobId=6f142865-96c3-535c-b7ea-873d86b887bd&j=e35d4f76-8ff2-5536-d795-df91e63eb9f7&t=fa7b4b17-b6ff-5c9c-8cfc-15f888c92310

Re-submitted to staged-recipes: https://github.com/conda-forge/staged-recipes/pull/16369

Now on conda-forge: https://anaconda.org/conda-forge/adc-streaming


Crash when path contains "-"

upd3: I think the program doesn't like dashes. If the ini file has the path: "C:\Games\Rimworld Biotech v1.4.3548", the program works fine. But if the ini file is: "C:\WBC\stable-diffusion-webui", the program crashes with code 0x40000015.
FAILURE_PROBLEM_CLASS: FATAL_APP_EXIT
FAILURE_SYMBOL_NAME: libstdc++-6.dll!ZN9__gnu_cxx27__verbose_terminate_handlerEv
FAILURE_BUCKET_ID: FATAL_APP_EXIT_40000015_libstdc++-6.dll!ZN9__gnu_cxx27__verbose_terminate_handlerEv
MODULE_NAME: libstdc___6

Firefox program files named "minidump-analyzer.exe" but no crash in the end


HWKAGENT-56 - no longer pass in tenant ID unless in METRIC mode

this has SNAPSHOT in pom. might want to wait for release of metrics before putting this in master

LGTM, thanks @jmazzitelli !


Not working on M2 Mac

Hi, I am facing a weird issue - log below
``thread'<unnamed>' panicked at src/main.rs:thread 'thread '120:<unnamed>' panicked at src/main.rs:120:41<unnamed>41: : calledResult::unwrap()on anErrvalue: ReadError(Error { kind: InvalidData, message: "stream did not contain valid UTF-8" })calledResult::unwrap()on anErrvalue: MissingAt note: run withRUST_BACKTRACE=1` environment variable to display a backtrace
' panicked at src/main.rs:120:41:
called Result::unwrap() on an Err value: ReadError(Error { kind: InvalidData, message: "stream did not contain valid UTF-8" })
thread '' panicked at src/main.rs:120:41:
called Result::unwrap() on an Err value: MissingAt ``
This is my code
gunzip -c ./00_Nanopore_Data/SO_12538_WBS_Sample2.fastq.gz | chopper -q 7 2> chopper.log | gzip > ./01_Trimmed_Data/SHAL_ONT_filtered.fq.gz
This seems to be coming from some config/incompatibility with the OS? I did download the compiled binary for Mac OS and also Conda install is not working.
I am on a M2 Mac Sonoma. Would be great if you can help me out what's going on?!
Thank you
best,
Vinay

Do you think you could share your input data? Or do you get the same error for other fastq files as well?

Well, that is not how you should gzip it. You have made a tar archive, not a gzipped file. A tar archive is to combine multiple files (which you presumably have).  Tar archives are nice to transfer or archvie data, but are not ready to be used by other tools.
You should gzip yourreads.fastq to create a gzipped fastq file.

@wdecoster It's working fine with the correct gzipped file. Extremely sorry for the issue. Closing it now. Feel free to delete the issue.
best,
Vinay

Glad to hear that things work! Feel free to let me know if there is anything else I can help with.