can't not login

I can't enter my password manually

I wrote my ID and password on config.ini

The password is not applied to the screen and an error is displayed.

My current os is W10 RS5 64bit
The same symptoms occur when the vaccine is turned on or off.

use the cookie method, see on readme.txt for details
  Q3. I cannot login to pixiv!
      - Check your password.
      - Try to login to the Pixiv Website.
      - Try to use the config.ini on the [Authentication] section.
      - Check your date and time setting (e.g.: https://www.timeanddate.com/)
      - Disable Daylight Saving Time and try again.
      - Copy your session values from browser:
        1. Open Firefox.
        2. Go to Pixiv website and login, remember to enable [Remember Me]
           check box.
        3. Right click the page and select View Page Info.
        4. Click the Security tab.
        5. Click the View Cookies button.
        6. Look for Cookie named = PHPSESSID.
        7. Copy the content value.
        8. Open config.ini, go to [Authentication] section, paste the value
           to cookie, set keepsignedin = 1.

I've checked all the above, but I can't settle it.

(1)

(2)

(3)

If the cookie is given, password will not be used
Try to login using your username, not email (It shouldn't matter, just in case)
I notice you got the getaddrinfo failed, meaning it cannot resolve the pixiv ip address. Do you have any firewall that blocking the dns resolution?
Can you try on other pc?

Nandaka , i have a problem, i reinstalled windows today and i use windows 10 enterprise
but i cant log in  pixiv with the prog
https://cdn.discordapp.com/attachments/465470547476873228/596002597735759889/unknown.png
this is what i get


Integrate Rollbar

https://docs.rollbar.com/docs/javascript
client token: 6c41d7f381264bfcb064f34ad4a98501

@jhash this is how I'm setting the environment on the server:
config.environment = ENV["HEROKU_APP_NAME"] || ENV['RAPID_SKILLS_ENVIRONMENT'].presence || 'production'

We ended up using the relative URL in the app, since I couldn't get access to the HEROKU_APP_NAME environment variable in time. But I think we can access RAPID_SKILLS_ENVIRONMENT in the Dockerfile.prod file so then we can at least distinguish between staging and production (review apps will get lumped in with staging).

@littleforest where is RAPID_SKILLS_ENVIRONMENT defined?

@littleforest also, should I be (prep/app)ending something to change the environment to be specific to the frontend?

@jhash it was only defined in Heroku's env vars because I wasn't using it for development, but I just pushed a commit to your branch that sets it in development in the docker vars. You'll have to restart the web service for it to get picked up.


[Feature Request]:  Want to implement the navbar of the bootstrap project as original website and completing the copy to clipboard functionality

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
I want to implement the navbar on the bootstrap as original website
I want to complete the copy to clipboard functionlity to the project
Use Case
It will looks more like the original one
Benefits
No response
Add ScreenShots

Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[ ] I'm a SSOC'24 contributor
[X] I have starred the repository

@Ayushmaanagarwal1211 u are assigned .but at first please try to complete previously assigned issue.

@apu52 yes yes actually i already created the page for amazon and raised a pr just now and now i am starting working on this
#1110


Docker Compose - Extend or Override

Continuation of #131 (need to remember to look in old issues)
Extend, override, or use include:
https://docs.docker.com/compose/multiple-compose-files/
Question is how portainer handles this.
We know override works.
Think if we had a base file:

dagstger-deamon
dagsgter-ui
postgres
tasks

Then for each community we could have an override with it's ingest and other custom code
but customize the env variables with a prefix (replace GLEANERIO in the substitution with ECO)
- GLEANERIO_DOCKER_GLEANER_CONFIG=${GLEANERIO_DOCKER_GLEANER_CONFIG:-gleaner}
- GLEANERIO_GRAPH_SUMMARY_ENDPOINT=${GLEANERIO_GRAPH_SUMMARY_ENDPOINT:-${GLEANERIO_GRAPH_URL}}
- GLEANERIO_MINIO_ADDRESS=${GLEANERIO_MINIO_ADDRESS}

becomes
- GLEANERIO_DOCKER_GLEANER_CONFIG=${ECO_DOCKER_GLEANER_CONFIG:-gleaner}
- GLEANERIO_GRAPH_SUMMARY_ENDPOINT=${ECO_GRAPH_SUMMARY_ENDPOINT:-${GLEANERIO_GRAPH_URL}}
- GLEANERIO_MINIO_ADDRESS=${ECO_MINIO_ADDRESS}

So for ECO we define containers:

dagster-code-eco-ingest
dagster-code-ecrr

and for IOW, etc
customize the env variables with a prefix (replace GLEANERIO in the substitution with IOW)

dagster-code-iow

This would allow a long list of ENV variables for a community, and we could run  multiple communities ingest from one dagster.

#131


design and implement named bindings

named bindings are replaced by child clusters. the last one is already drafted in the code.


Fix Banning Problem

Niantic starts to bann People who use a Bot how can we fix this issue ?
We must check how the algorithm Niantic use to recognize Bots work to make a workaround we must make some experiments to get it out.

All accounts banned here :'(

my 3 accounts banned..
You use snipe functions?

Not for all


md-dialog doesn't seem to work well with dark theme by default (pre.7)

Maybe there's some trick to style it properly, but default is barely legible:

 <md-dialog id="terms-dialog" width="300">

           ${msg('Terms and conditions')}

          ${msg(
          'By continuing, you agree to our Terms of Service and Privacy Policy.' }
        )}

        <md-filled-button slot="footer" dialogAction="close">
          Cancel
        </md-filled-button>
        <md-filled-button
          id="confirm-button"
          slot="footer"
          @click=${this.handleAcceptTermsAndConditions}>
          ACCEPT
        </md-filled-button>
      </md-dialog>

If I change my --md-sys-color-on-surface-variant-dark: black; the the text shows up black so it's legible.
It appears to be using the dark theme for the text color, but light theme for the surface of the dialog. I can see this when I switch from dark to light, everything else changes except the dialog backgrounds.

Same bug here for md-menu!

This is a pretty bad regression, makes pre.7 basically unusable, can we get a quick hotfix for this and a pre.8 release?

As per comment in https://github.com/material-components/material-web/issues/4145#issuecomment-1509437477.
If you're using @material/material-color-utilities, the library broke due to the new tonal surface updates.

Is there an ETA for this? Would be nice to know.

This is more of an issue with the material color utilities project, not MWC :/
I heard they were working on it though! @rodydavis and @e111077 might know more

If you are using material theme builder, the tokens there are missing the container tokens. While the team is updating that, please use the "Dynamic" scheme here to generate your tokens to match the behavior of material theme builder's color generator
https://lit.dev/playground/#gist=abcc77f636c1b76506df860db6dc0faf&view-mode=preview

@rodydavis container are still not included in theme builder, is there a way to generate them?

Working on preparing the release! It will be on the next update

@rodydavis awesome, thanks! is there a place to track theme builder's releases?

This released yet?

Md-dialog should work with the latest tokenset. Confirmed in pre.16

I tried the material theme builder again today and it still doesn't have any new tokens.

I tried the material theme builder again today and it still doesn't have any new tokens.

Have you tried the Material Figma plugin? I think that's up to date for generating the new surface tokens
https://www.figma.com/community/plugin/1034969338659738588/Material-Theme-Builder
https://github.com/material-foundation/material-color-utilities would be the best place to raise these types of issues with the TS library.
According to https://github.com/material-foundation/material-color-utilities/issues/98, it looks like the changes have landed. Maybe verify that you're on the latest? One of the comments suggested running npm install<EMAIL_ADDRESS>--save-exact, since npm wasn't auto updating it.

I'm using this one linked from the material spec site: https://m3.material.io/theme-builder#/custom

I'm using this one linked from the material spec site: https://m3.material.io/theme-builder#/custom

Unfortunately I don't know when that tool will be updated. I'd suggest trying out the figma plugin if possible


Detect accidental duplication in production bundles

This adds a code snippet to detect cases where complex bundle setups or certain monorepo setups lead to duplicated inclusion of both the CJS and ESM versions of our library in the final production bundle. The problem with that is that object instances generated with one "runtime copy" of the library end up being sent to APIs from the other "runtime copy", which leads to various bugs.
This is a proposed fix for #432.
Not sure if I actually like this solution. Would love to get everyone's opinion on this? Good idea? Terrible idea? A different approach?

I don't see any downside to this solution but I don't know if it's the best approach.
I will do more research tomorrow but could we use the Approach #1 from the Nodejs doc on "Writing dual packages while avoiding or minimizing hazards" ?

…could we use the Approach #1 from the Nodejs doc…

Ah! There it was! I've been trying to find back a blog post of some kind that I read about that trick in the past, but couldn't recollect it. This Node doc page was exactly what I was trying to recall — thanks for surfacing it for me.
I remember studying this once when I wanted to do the same thing for publishing decoders, but found it to be too cumbersome to set up. I think I didn't want to bother writing a custom code generator for those wrappers, and also didn't feel like maintaining the mapping manually. Back then I didn't find a tool that would enable this wrapping automatically for all exported symbols.
Will take a look to see if it's any easier today.

Was thinking of adding the following section to the Troubleshooting section in the docs to link to in the warning message:

Avoiding bundling Liveblocks twice in your production bundle
We publish Liveblocks packages to NPM in both CJS and ESM formats. When your bundler supports modern code, it will automatically use the ESM sources. This has several benefits, like tree-shaking.
However, in certain complex bundler setups, we've seen cases where Liveblocks code  accidentally gets included twice—both the CJS and ESM implementations end up in production bundles. If this happens, it self-detects this case and issues the following warning in the console at runtime:
@liveblocks/client appears twice in your bundle (as CJS and ESM).

This scenario should obviously be avoided. On the one hand, it means your production bundle size is unnecessarily bloated. But worse, it leads to hard-to-debug bugs caused by two separately running Liveblocks client states. When you hit this situation, it's well possible that the Liveblocks package isn't the only package that is getting included twice, so please do double-check your bundlers configuration and dependency tree.

Not sure if we can be more helpful/concrete in the actual way to debug this issue, since so much of the nitty gritty details here depend on the actual bundler and their configuration that there are myriad ways to end up in this scenario…?
Ideas?

Let's forget the wrapping solution then. It looks like there is no "standard" solution. The warning that contains a link to the documentation is enough I think.

I dug a little deeper here, and I think the problem might be bigger than we originally anticipated. This isn't an issue just for complex bundler setups or monorepos. Even our relatively standard Next.js e2e test app setup (basically a standard npx create-next-app unless I'm overlooking something here) seems to be affected and is bundling our app twice… 🤔
After some deeper debugging, this seems to happen in the bundle:
==> First import of @liveblocks/client CJS in .next/server/pages/storage/list.js:17:75)
==> Dupe import of @liveblocks/client ESM in .next/server/pages/storage/list.js:21:77)

So first the CJS version is required from L17, then the ESM version is imported from L21. That seems bad!
That generated Webpack code looks like:

Here, L17's CJS-style import corresponds to the original source's line: https://github.com/liveblocks/liveblocks/blob/main/e2e/next-sandbox/pages/storage/list.tsx#L1
Next L21's import corresponds to https://github.com/liveblocks/liveblocks/blob/main/e2e/next-sandbox/pages/storage/list.tsx#L4 which in turn does https://github.com/liveblocks/liveblocks/blob/main/e2e/next-sandbox/utils/createClient.ts#L1
It's unclear to me why the first one uses the CJS module, while the second is using an ESM module. The dual package hazard problem seems real.
@ofoucherot @GuillaumeSalles Perhaps it would be better to follow the ESM wrapping technique after all, and sacrifice tree-shakability in return?

Closing this in favor of #441.


Use 'common=true' arguments in our framework

Although there is not special treatment of this arguments currently in Barclay, it will be soon and like that we will be able to organize the command line in a better way. The arguments that should be common are the following:
ReadToolsWalker

[ ] secondsBetweenProgressUpdates
[ ] referenceFile

RTInputArgumentCollection

[ ] forceQualityEncoding: this is also considered adavanced, and this may be a problem.

Maybe in RTInputArgumentCollection the inputPair and interleaved should be considered common. If we do so, we should add documentation of the mandatory input to point out  that these options exists for input pair-end data.
Finally, maybe we should generate an argument collection for where the barcodes are stored. We use then in different places, and may be considered common for some tools (but not for others).

This depends on what is going to happen in Barclay. So added "wontfix" for now...

We will add them, and then do the changes as Barclay evolves.


[WFLY-4819][WFLY-4981] Upgrade to JBossWS 5.1.0.Beta1 / Apache CXF 3.1.2

.. also ensure the same jandex version is used for dependencies and plugin dependencies, otherwise we end up with a version shipped in the distro that's not the same used for generating -jandex jars.

Linux with security manager Build 2142 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Windows Build 2327 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Linux Build 7273 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Linux with security manager Build 2142 outcome was FAILURE using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 737, ignored: 277; exit code 1 (new) Build time: 0:04:33
Build problems:
Process exited with code 1

Linux Build 7273 outcome was FAILURE using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 737, ignored: 277; exit code 1 (new) Build time: 0:04:39
Build problems:
Process exited with code 1

Windows Build 2327 outcome was FAILURE using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 737, ignored: 277; exit code 1 (new) Build time: 0:06:24
Build problems:
Process exited with code 1

retest this please

Linux with security manager Build 2143 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Linux Build 7274 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Windows Build 2328 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Linux with security manager Build 2143 outcome was FAILURE using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 737, ignored: 277; exit code 1 Build time: 0:04:01
Build problems:
Process exited with code 1

Linux Build 7274 outcome was FAILURE using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 737, ignored: 277; exit code 1 Build time: 0:04:01
Build problems:
Process exited with code 1

Windows Build 2328 outcome was FAILURE using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 737, ignored: 277; exit code 1 Build time: 0:05:28
Build problems:
Process exited with code 1

retest this please

Linux with security manager Build 2147 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Linux Build 7278 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Windows Build 2332 is now running using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a

Linux with security manager Build 2147 outcome was SUCCESS using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 896, ignored: 285 Build time: 0:06:19

Windows Build 2332 outcome was SUCCESS using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 3088, ignored: 367, muted: 1 Build time: 0:48:38

Linux Build 7278 outcome was SUCCESS using a merge of 70237a7f50ec164419227ce7bd991f62fed9714a
Summary: Tests passed: 3090, ignored: 366 Build time: 0:48:42


Get this into Linux package managers

This is such an amazing tool that has become part of my everyday workflow. I think it would help developers a lot who are getting into Nostr.
I think we should try to get this into Debian. You should be able to apt install nak.

If you have homebrew you can
brew tap nostorg/nostr
brew install nak

@alexgleason
To extend on what you said, if nak could be avaiable as a service/daemon, then lots of work of implementing NIPS in different programming languages could be saved, because a server could just call nak to validate messages, dns, etc.
This would save people from reinventing the wheel many times and release more resources to be applied in other interesting areas.
Now that I think of it, maybe thats the idea behind relayerhttps://github.com/fiatjaf/relayer ?

fyi link target was off: https://github.com/fiatjaf/relayer
nak is also in the Arch AUR


test change do not merge

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12425/
Test FAILed.

hi bot

alluxio-bot, check this please

alluxio-bot, check this please

good bot


Refactor how rustc_codegen_spirv is compiled

Summary
rustc_codegen_spirv is compiled and discovered in a very hacky way. Cargo compiles rustc_codegen_spirv because it is inside spirv-builder's Cargo.toml as a dependency, and then spirv-builder discovers the rustc_codegen_spirv's dylib by this super hacky function: find_rustc_codegen_spirv. I think this should be avoided.
Motivation
When I've tried to build something using spirv-builder this hacky discovery was not working for me.
Also rustc_codegen_spirv is compiled using the same profile as spirv-builder and we end up with rustc_codegen_spirv being build without optimizations (if we are in debug mode). This is a big problem because compiling rustc_codegen_spirv is a one time cost, but while developing one would recompile thier shaders many times.
Proposed solution is much more elegant than current implemention.
Solution
Let's move rustc_codegen_spirv into another trait witch will compile rustc_codegen_spirv and provide path to it's dylib file.
I've crated an example of how this could be implements: https://github.com/watjurk/spirv-builder-alternative, here is a short summary:
All of this happens inside crates/rustc_codegen_spirv:
Cargo.toml:
[package]
name = "rustc_codegen_spirv_compiler"

src/lib.rs:
pub fn dylib_path() -> PathBuf {
// Compile rustc_codegen_spirv using cargo and return path to it's dylib file.
}

src/rustc_codegen_spirv
Folder with the `rustc_codegen_spirv` crate.

Future
In the future this approach could be modified without breaking code that relies on dylib_path function, for example we can serve pre-builed dylib's of rustc_codegen_spirv and dylib_path instead of building rustc_codegen_spirv will download one of the pre-build dylib's depending on user's hardware.

I agree it's noticeably suboptimal right now, and we have been wondering for a while about alternatives.
However, there are more variations to what we could do (cc @repi @oisyn).
How should rustc_codegen_spirv be built?
(:stop_sign: used below to represent "downsides" aka "cons" in a easy-to-spot way)

Dependency (current): by Cargo only because it's a dependency (of spirv-builder)
:stop_sign: copying rust-toolchain from Rust-GPU is mandatory (and your own code has to also be built with that nightly, if it depends on spirv-builder, not just the codegen backend dylib)
:stop_sign: unoptimized build by default, without changing Cargo.toml (esp. if spirv-builder is a build

dependency kind:

normal (current)
:stop_sign: if spirv-builder is used both as a normal and build dep itself, this will likely lead to multiple builds of rustc_codegen_spirv
build
:stop_sign: always has the unoptimized issue (see above)

Spirv-builder: spirv-builder running cargo build -p rustc_codegen_spirv itself
:stop_sign: if spirv-builder is a build dependency, it's tricky (if even possible) to show build progress

when to run the build:

dynamic: when spirv_builder::... APIs are used
(IIUC, @watjurk is suggesting specifically this choice)
:stop_sign: extra "is it fresh" checks every time
:stop_sign: may be inadvertently affected by e.g. environment variables
build: build script (spirv_builder::... refer to a path compiled-in via env!)
:stop_sign: exacerbates the progress issue (see above)

how to determine the version:

hardcoded: every time we publish we change spirv-builder source code
:stop_sign: manual work or scripting required (pretty messy)
same: get it from env!("CARGO_PKG_VERSION") of spirv-builder
:stop_sign: have to assume either https://github.com/EmbarkStudios/rust-gpu or crates.io
:stop_sign: can't work for specific git revisions (since they're not part of the version)
unbuilt-dep: make spirv-builder depend on rustc_codegen_spirv but with impossible conditions, or optional (could just make spirv-builder/build.rs error if enabled), so that Cargo fetches the dependency and we can find it through e.g. cargo metadata (or build it with -p etc.)
:stop_sign: may still pollute Cargo.lock, introduce versioning conflicts, etc.
bundled: have the packaging process archive all the relevant source code
:stop_sign: would skip relying on Cargo to fetch that source code, but it's still an additional step in a weird place, and so has all the problems of hardcoded and same

what toolchain to use:

rustup: we rely on rust-toolchain and/or explicit rustup commands to run the build
:stop_sign: not everyone might have rustup installed, they might be running the outermost build with some pinned version scheme of their own choice etc.
download: we basically pretend to be rustup and do the above
:stop_sign: pretty much a bad idea across the board (e.g. distros can provide rustup that works slightly better, or at all, and this would just break in those cases)
stable: we abuse RUSTC_BOOTSTRAP and support specific stable versions
:stop_sign: I doubt we could even get rustc-dev, and very likely not from non-rustup distro packages either - and RUSTC_BOOTSTRAP is terrible to mess with anyway, let's not...

where to cache the built backend dylib:

target-dir: we nest it in $OUT_DIR or at most go up a bit from it (could use a temporary build dir, like cargo install does, then move the resulting dylib to $OUT_DIR)
:stop_sign: built once per Cargo workspace, potentially even profile
per-toolchain: somewhere in .rustup/toolchains/$our_current_nightly/...
:stop_sign: we'd have to hash all the relevant version/source-path/etc. details to use as a "cache key", cache invalidation is hard, file locking, there's quota concerns, rustup might not like toolchain dirs being altered, etc.
per-user: somewhere in $XDG_CACHE_HOME (i.e. ~/.cache)
:stop_sign: same as per-toolchain above, except even less scoped (e.g. the files would be kept around even if the user removes the relevant rustup toolchain)

Manually: separate "install Rust-GPU" step (e.g. into .rustup/toolchains/...)
:stop_sign: like spirv-build automatic per-toolchain/per-user caching, but requiring user interaction outside of Cargo builds

could be offered in conjunction with extra automation, to ensure spirv-builder doesn't itself also need to build the toolchain, but also allowing more direct usage?
this also ties into artifact dependencies which would likely always require a modified toolchain if we want to use them
(mostly included for completeness, it can't possibly be a full solution IMO, not without having a way to put something in rust-toolchain)

(I tried using a table and it feels like I would need 3D or 4D tables to make it work well... in the end I opted to list mostly cons and not so much pros - also, I gave each aspect names so that I can refer to them later but it didn't end up being useful)
You may notice that I've even included "really bad ideas" in there (decided to use strikethrough to indicate them) - I really want to be clear about the size of the solution space, so that we don't make too many assumptions without realizing.
Even ignoring the unviable options, there's still 14 combinations (12 if we assume S).

If I had to pick one, S when=build version=unbuilt-dep toolchain=rustup cache=per-toolchain is probably a local optimum: it may upset Cargo and/or rustup, reporting progress may be annoying/hard/impossible, but it would ideally minimize configuration (use it directly from stable code or any toolchain!), maximize reuse between different build dirs, always have an optimized backend, be directly usable from runtime code for e.g. a hot reloading (without the hacks we need in-tree for all that), etc.
But hybrids are also interesting, e.g. version=same for published versions and something different when developing on Rust-GPU itself (to avoid storing a zillion unique dylibs, and also to enable incremental etc.).
Also, to be perfectly clear: I am not strongly attached to any one idea, all I want to is to present as much as possible so that we can choose knowing what we're deciding against. And it's also possible I missed things, I may edit this comment or try to figure out a better presentation for all the options (might be easier if we decide on some of them first).

I think that this is not what I meant, I'd like to decouple the process of compiling rustc_codegen_spirv from spirv-builder, so that for spirv-builder obtaining the dylib is just a matter of calling something like this:
let path_to_dylib = rustc_codegen_spirv:: dylib_path();

If you think about it spirv-builder should not be responsible for building  rustc_codegen_spirv, this logic should be contained inside rustc_codegen_spirv and. I'd opt for the bundled version, just like in my example the target_crate is contained within the rust_cargo_build_nested crate. In my opinion this option is the most correct one because then we get the version from the parent crate.
The unbuilt-dep poposition would still work in this scenario just that rust_cargo_build_nested would depend on the target_crate.
The next question is, from what perspective are we looking at it? For example from user's perspective who is running spirv-builder inside thier's build.rs script the compilation of rustc_codegen_spirv is really happening at compiletime.

I think that this is not what I meant, I'd like to decouple the process of compiling rustc_codegen_spirv from spirv-builder

This is orthogonal from pretty much everything I described, at least AFAICT. You can imagine that (almost) every time I said spirv-builder I meant some new rustc_codegen_spirv-builder crate that spirv-builder depends on, and which provides the dylib_path method you're thinking of (though really it should be a constant), it doesn't change almost anything about the solution space matrix (at most it's just another axis).
(We really don't want to change what rustc_codegen_spirv is, i.e. it should remain the dylib that rustc loads when we pass -Z codegen-backend=..., you can use -... after its name to indicate some helper crate related to it, but not rename the crate itself)

I'd opt for the bundled version

bundled is not really workable because we would need some kind of shell script to make a .tar.gz or .zip or something with the contents of crates/rustc_codegen_spirv and then require that on every cargo publish, and there would be no easy way to use a git dependency, and it's so unidiomatic and an ops nightmare that you can just ignore it (even if you can trick cargo publish into bundling it for you as "extra files" in the crate, it's still a lot of trouble for something very fragile).

just like in my example the target_crate is contained within the rust_cargo_build_nested crate

Oh that's in an src/ directory? So that would probably fit into "trick cargo publish into including it".
I'm still not extremely confident it won't break in some weird way but I can see why you brought it up now.
This probably means we need to split up bundled into two ("manual archive" vs "nested crates"). My earlier confusion stems from thinking "manual archive" when I wrote the bundled entry, and also taking a while to notice the precise way you have placed a whole Cargo package directory inside the src/ of another.

The next question is, from what perspective are we looking at it? For example from user's perspective who is running spirv-builder inside thier's build.rs script the compilation of rustc_codegen_spirv is really happening at compiletime.

"What needs to run every time you change the shaders" is how I see it (and this applies to both build scripts and hot reloading usecases) - there's no reason (IMO) to keep checking if we need to rebuild rustc_codegen_spirv every time the shaders change, if we can avoid it (and Cargo has various ways of minimizing the cost of checking if rebuilds are necessary, for the things that it is in control).
But that is a quite minor point compared to everything else, a microoptimization almost.
Generally, I'm trying to describe how spirv-builder (or rustc_codegen_spirv-builder, if you want) work internally, while still worrying about end-user UX like rust-toolchain/Cargo.toml configuration friction, how build progress is indicated, etc. (a bit like if an user of Rust-GPU had an "xray view" of the whole process).

I'll point out some things:

rustc_codegen_spirv requires the following components to compile: ["rustc-dev", "llvm-tools-preview"], so in order to install them we are forced to use rustup, so as a consequence our users are forced to use rustup, so the issue of installing toolchain is gone because we must have rustup.
rustc_codegen_spirv should not have any features that user can enable/disable, I'd even argue that we should remove use-installed-tools and use-compiled-tools, for reasons I'll explain later.
rustc_codegen_spirv should be it's own fully self-contained crate that would not be influenced by user in any way.

I'd like to have all of this to prepare rustc_codegen_spirv for the Future. By the Future I mean that we should not require users to compile rustc_codegen_spirv, instead we should provide pre-build binaries that would be downloaded by dylib_path function. The overall interface would stay the same just that we would not compile rustc_codegen_spirv , we would download it. In order to do this seamlessly rustc_codegen_spirv cannot depend on user input in any way, that's why I think we should remove use-installed-tools and use-compiled-tools.
Lastly, when you download rust are you compiling rustc's backend? No, you are getting it pre-build, I think the same should happen in rust-gpu's case.
Ps: The "nested-creates" approach (my proposed solution) would satisfy the 3rd point.

Finally took a stab at something like this, in:

https://github.com/EmbarkStudios/rust-gpu/pull/1103

It's S when=build version=unbuilt-dep toolchain=rustup cache=target-dir, in my old taxonomy (i.e. the only difference from my previous thoughts is that I used to think cache=per-toolchain made sense - maybe it still does, but this stuff is awkward enough as-is within one target-dir, and would likely need custom locking and cache invalidation etc. to make it per-toolchain, not to mention the many rebuilds while working on Rust-GPU).
While version=unbuilt-dep was possible in the end, it's pretty convoluted (even using cargo_metadata, Cargo doesn't really want to let you enable optional dependencies except if you have control of the the workspace).
Also, I've kept the dual features that @watjurk disliked, but I can kinda see how bad they are for this, I ended up having to treat them like they cause different rustup toolchains to be used (i.e. nothing is shared between use-compiled-tools builds and use-installed-tools builds) - it's a shame, but I'm not sure what we can do in the long term (other than stop needing SPIRV-Tools entirely, but that's not happening any time soon).

New (conceptual) development:

#1137

This is simultaneously very similar to existing setups (mostly only what decides the Rust-GPU version changes!), but also unlocks a lot more, because we can make a single version of some CLI tool work with many backend versions, as long as it's picked up from the shader crate (whether spirv-std or rust-gpu etc.).
AFAICT in the original nomenclature earlier in the thread, S/version= could only be one of:
hardcoded, same, unbuilt-dep, bundled - but they all refer to spirv-builder + rustc_codegen_spirv, whereas the new one would pull it from the shader itself (even if likely a lot like #1103).
The easiest thing we could try would be:
S when=dynamic version=shader-* toolchain=rustup cache=target-dir
(not sure what version= names would even make sense. I denoted changes from #1103 in italics, but build->dynamic is not that big of the deal when you control the whole build, mostly an issue of being careful around env vars)
Also, if we get -Z script working for shaders, those might end up having their ~/.cargo-backed target dirs anyway, even if we don't come up with our own global caching (in fact, we could probably rely on -Z script to trigger the rustc_codegen_spirv build, so Cargo can both cache it globally and ideally reuse it).


Add criteria for community resources

Adds suggested message so community resources cannot be mistaken for official parts of the Design System.
Fixes https://github.com/alphagov/govuk-design-system/pull/1606

You can preview this change here:
Built with commit 71a742d582d523c7bc74b94a028947c8e33b9b70
https://deploy-preview-1606--govuk-design-system-preview.netlify.app


Quit shortcuts and menus are missing. The white dot disappears.

When I look at the dock, it is not clear whether the application is open or not on Dock icon. The white dot disappears.
https://user-images.githubusercontent.com/36481442/137536436-156570ff-6aff-4a0e-b501-2bb679134f53.mov

Also application does not appear in the quick switch interface. Command+Tab | Comman+Q.

There is no Quit option when right clicked on the Dock icon.

Weird issue and I cannot reproduce. What exact macOS version are you on?

Weird issue and I cannot reproduce. What exact macOS version are you on? Can you try restarting your computer and see if the issue persists?

macOS BigSur 11.6 (20G165) I restarted the system and it didn't fix it.

Alright. I figured out what's going on. You had Keep in Dock enabled on the Dock icon and then enabled the Show in menu bar setting. However, the Show in menu bar setting, means it will no longer work from the Dock. There's also no way to automatically remove the Dock icon if you have Keep in Dock enabled.
I will make the setting name clearer in the next version.


Creating extra curricular GH section

Follows the content goals in issue #211
@dmc314 I would love some ideas on what else this could include. I would add you as a reviewer, but I can't seem to from the tab on the right.

you know @mrodriguez3313, let me ping the fil-lobby and see if there are any lurking experts!

Lets merge this so then I can get feedback at the github section @enoldev


Ordering of output in sentiment_pipe function

In the notebook gpt2-sentiment-control.ipynb (Optimize model section) ,
logits = [torch.tensor(output[1]["score"]) for output in sentiment_pipe(texts, **sentiment_pipe_kwargs)]
Why do we store output[1]["score"] as the reward? I assumed that "We will use the logits for positive class as a reward signal for the language model." but does sentiment_pipe always has the output[1] as an index for the the positive class?

I just checked and you are right, this is not always the case! I will fix the example. cc @younesbelkada maybe this explains the spikes.


change url parameter from $order_by to $orderby

Hello,
Exact online API returns an exception claiming $order_by is not supported. The documentation of OData also uses $orderby as parameter. The problem can be easily repreduced by running this line:
Elmas::Account.new.find_all(order_by: :created)

I only changed the uri-parameter. For code consistency I could have changed all related variables from order_by to orderby, but this would have resulted in less backwards compatibility with the old name. So I kept the change as little invasive as possible.
regards,
Daniel

Ah awesome! I'll merge this when travis can install the gems, i don't expect failing specs after this change. Changing the ruby variable is debatable. I'd like to keep it as ruby syntax like as possible which is underscored by words. But it might be confusing.

Hi, what's the status? The specs failed outside of my code change.

Ill make a new version for you tomorrow
Sent from my iPhone

On 17 May 2016, at 16:52, Daniel Senff<EMAIL_ADDRESS>wrote:
Hi, what's the status? The specs failed outside of my code change.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

https://rubygems.org/gems/elmas/versions/2.2.1 was just pushed, thanks again for the fix.


fix(typo): change not coverage to no coverage

Assuming this should be "no coverage" instead of "not covered" based on the context around this log message

Thanks!


block external IP

Description:
I was looking for the auth issue by @awarecan to link the new webhook trigger PR #17246 when I stumbled upon #15427. I wish I had seen this earlier or that it was escalated.
Anyway, here is a PR to block all external IPs from accessing the emulated Hue APIs.
Could probably be a decorator but wanted to get this out fast.
I really hate the emulated Hue component, it's been such a source of problems.
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code does not interact with devices:

[x] Tests have been added to verify that the new code works.

As long as 8300 port is not accessible from external we should be fine, but yes, a block for all external IP access is a quick fix.


In aggregate event handlers are working

Solution to #117

There are problems with the code, please see the comments we've added, fix the issue, then resubmit.


RSA key generation fails sporadically when under high load since OpenSSL 3.0.2

Since running with OpenSSL 3.0.2 we encounter sporadic RSA key generation failures.
EVP_PKEY_keygen() fails but no error is set (ERR_print_errors_fp() shows nothing). This seems to be workload dependent, it seems to happen only if key gens a running concurrently (in different processes though).
I have debugged this and it turned out that it fails in ossl_bn_rsa_fips186_4_derive_prime() (file crypto/bn/bn_rsa_fips186_4.c) at step 8-10, where i >= imax. So it just took too many loops to derive the prime....
            /* (Step 8-10) */
            if (++i >= imax || !BN_add(Y, Y, r1r2x2))
                goto err;

What is an application program supposed to do in such case ? Just retry the key gen?
Would also be nice if an appropriate error could be set in that case, so that the application has a chance to identify this situation.
I understand that you don't want run the loop forever, but now the problem is just pushed to the application deciding how often to retry the RSA key gen....
In my case it happens for 2048 or 4096 bit keys, with an given public exponent of 3. I haven't seen it for any other public exponent so far.... Maybe a such small public exponent of 3 makes it more likely to required many iterations?
What is the reason for the too many loops being driven? Could it be that the random pool is depleted, because too many random bytes are read in relatively short time? Would this lead to such situation? Shouldn't the random-read just block until the entropy pool has been filled up instead?
This did not fail on OpenSSL 1.1.1. I can't tell if it also failed with earlier OpenSSL 3.0 releases...

The algorithm is taken from the FIPS standard verbatim. Notably the smallest public exponent allowed by FIPS standard is the Fermat number 4 - 65537. The algorithm requires the resulting prime value - 1 having GCD 1 with the public exponent. I suppose this might not work so well with public exponent being 3.
Why are you using 3 as the public exponent? There are some security implications of such small public exponent.

One option would be to fall back to the old key generation algorithm when public exponent is < 65537 (in default provider).

@slontis any opinions, Shane?

Note that the current draft for FIPS 186-5 changes the limits for these algorithms, specifically see NIST FIPS 186-5, appendix B.9, step 9. I suspect this may be related to Allen Roginsky's comment on FIPS 186-4 (see Comments received on FIPS 186-4 (Dec. 2015), page 68), which mentioned a similar problem in Integer Factorization Cryptography Key Pair Generation using the "Generation of Random Primes that are Probably Prime" method (B.3.3 in 186-4, A.1.3 in 186-5 draft).

Why are you using 3 as the public exponent?

Its a series of testcases testing various combinations of key sizes and exponents. Even though a public exponent of 3 is probably not the best choice for the real world, I still would like to continue to test it....

Note that the current draft for FIPS 186-5 changes the limits for these algorithms

It now loops 20/2 * nbits instead of 5/2 * nbits as OpenSSL code does currently.

This seems to be workload dependent, it seems to happen only if key gens a running concurrently (in different processes though).

I think this is a red herring - I would not expect this failure to be workload dependent.

The proper check for e using this algorithm is actually
e must be odd AND 2^16 < e < 2^256
For backwards compatibility we dont do this check. This is probably not a good starting point.
Potentially we could go back to using the simpler method in the default provider. This algorithm became quite a bit slower when the number of Miller Rabin rounds got increased.

I think this is a red herring - I would not expect this failure to be workload dependent.

Yes, quite possible. I guess its simply more likely to happen the more key gens are performed.

This algorithm became quite a bit slower when the number of Miller Rabin rounds got increased.

Actually it is slower even without that. I've tested that and changing the number of Miller-Rabin rounds even to much lower values did not have a big effect.

Yes it is a way more complex algorithm

Just out of curiosity:
Assuming that this condition is true: e must be odd AND 2^16 < e < 2^256, is it then guaranteed that the algorithm produces a key in any case, or could it still return with an error?
If there is still the possibility that an error is returned, then the question remains: How is an application supposed to behave when the key gen fails, and how can it detect that its this situation?
I guess the FIPS provider will keep this algorithm (even if you change the default provider to use  the simpler algorithm), so an application using the FIPS provider may have to be aware of such a situation anyway....

We also see sporadical RSA key generation failures in the EVP_PKEY_generate function, but we always use e=65537.
The probability of the failure is really low (a few times out of hundreds of thousands), we didn't have a chance to debug the cause yet.

It is still not guaranteed to generate the prime even with e=65537, just the probability of failure is much lower than with e=3.
That's the reason for the 20/2 * nbits limit upgrade in FIPS 186-5. With that limit and e=65537 the probability of failure would be sufficiently negligible.

As usual a PR would be welcomed.  I've raised an issue for the OpenSSL contractors to do this, but I've no idea as to the priority at this point.


Get Trusted Publishing working on saltext-vmware, so release can get published to PyPI

Work with Derek to get Trusted Publishing working on saltext-vmware, so release can get published to PyPI

Closing this since now have test_publish (publishes to test.pypi.org) and release (publishes to pypi.org) done, see PRs :

https://github.com/saltstack/salt-ext-modules-vmware/pull/413
https://github.com/saltstack/salt-ext-modules-vmware/pull/412
https://github.com/saltstack/salt-ext-modules-vmware/pull/411
https://github.com/saltstack/salt-ext-modules-vmware/pull/410


[CLOUD-376] Default keystore for JDG JGroups

This appears to be a commit for both CLOUD-376 and CLOUD-337, can you separate them out?


Use of generics seem to break the JSONDoc UI

We have a generic wrapper for lists (our front end team requested this...)
When I use this generic wrapper, the JSONDoc UI breaks. I believe this is because it is trying to evaluate ListWrapper and it can't figure out what "E" is

This looks like it is the same as ISSUE-151, but I think the issue is still there


Fix missing hostname

The hostname was missing if it was set directly without inventory. The lack of a hostname causes an empty $SPOT_REMOTE_NAME value

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

7 of 7 (100.0%)  changed or added relevant lines in 2 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.04%) to 84.557%

Files with Coverage Reduction
New Missed Lines
%

pkg/runner/runner.go
2
89.69%

Totals

Change from base Build<PHONE_NUMBER>:
-0.04%

Covered Lines:
2683

Relevant Lines:
3173

💛  - Coveralls


getThreadInfo API is broken

Looks like the threadinfo request runs into a 404 -- the URI must be old or broken. Does anyone know a workaround for this?
ERR! getThreadInfo Error: parseAndCheckLogin got status code: 404. Bailing out of trying to parse response.

ThreadInfoGraphQL is working in giving you a pretty up to date info, what I found strange is that you get unread messages but they are your unread messages, what about the person you talk to unread messages? Messenger has it, even facebook, why doesn't this API have anything for it?

is everything okey now? can we close?

@tarungog getThreadInfo has been updated in npm and github to use the graphql version. :)


add image upload

suggest API POST {image} /{owner}/{collection}/images
-> OK if user is collection owner (collection is owned by user), or if user is member of the organization (collection is owned by an organization), or whatever else makes it allowed per #40
So the UI would have an image upload feature (TBD) that allows posting images via the API.

Completed in api.py


Add reference to CreateDispatcherQueueController API

@MikeHillberg : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

#sign-off


chore: bump vitest in create-cloudflare templates

What this PR solves / how to test
This simply updates the create-cloudflare templates to use a newer vitest version, as a followup to https://github.com/cloudflare/workers-sdk/pull/5458 now that's been released.
Fixes #[insert GH or internal issue number(s)].
Author has addressed the following

Tests

[ ] TODO (before merge)
[ ] Included
[ ] Not necessary because:

E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)

[ ] I don't know
[ ] Required / Maybe required
[ ] Not required because:

Changeset (Changeset guidelines)

[ ] TODO (before merge)
[ ] Included
[ ] Not necessary because:

Public documentation

[ ] TODO (before merge)
[ ] Cloudflare docs PR(s): https://github.com/cloudflare/cloudflare-docs/pull/...
[ ] Not necessary because:

I'll run the e2e tests before merging...

Thanks. There are some other type errors here that I'm not really sure why are happening honestly. I'll see if I can get a chance to look over them at some point this week.

Didn't notice this open PR, I picked it up in https://github.com/cloudflare/workers-sdk/pull/6076. I did only mark vitest to 1.5.0, I'll mark it up in 1.5.3 in the next release. Thank you very much for your PR!


Auto-delete players / delete categories

a setting that automatically removes people that are only in the default category and haven't been seen in more than a certain time, like 2 weeks or so.. cause that list is getting loooong for me.  ideally I could pick which categories to cull even.

Please this. Running Bozjan has resulted in a practically unmanageable list.

I want to add to not auto-delete if

You have something written in the Summary tab: Tag or Notes
Character is in a Category

Reason: the player could be taking a break from the game.

A version of this is in V3.1 just pending PRs. This won't run automatically but can review how many records are going to be deleted and clean them up. This might be less of an issue in V3 since performance is (hopefully) significantly improved and database size has been reduced by 50%.


Return AlreadyExists instead of Conflict for 409 response codes

This aligns the response with that given by Kubernetes API server for 409 responses. I'm not sure if there is a case where we should set it to 'Conflict', but I think this will be correct for most foreseeable cases.

I did wonder whether this change would have been better expressed by subclassing ConflictExeption <- AlreadyExistsException and replacing the existing uses with the narrower type. This would save the surprise that would arrive if someone started using a 409 more generally elsewhere.

I agree. Attempting to do this revealed a need to add a dependency betweeen keycloak-user-api and api-common which contains the predefined exceptions.  I would like to cleanup/move some parts of api-common before doing that.


Cannot run "test" or "test:watch"

When I try to run either of the following commands,
$ npm run test
OR
$ npm run test:watch
I get error. Below is the npm-debug.log:
0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/bin/node', '/usr/local/bin/npm', 'run', 'test' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'pretest', 'test', 'posttest' ]
5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 silly lifecycle<EMAIL_ADDRESS>no script for pretest, continuing
7 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>8 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true
9 verbose lifecycle<EMAIL_ADDRESS>PATH: /usr/local/lib/node_modules/npm/bin/node-gyp-bin:/Users/ptiw10/Desktop/practice/react/react-unit-testing/node_modules/.bin:/usr/local/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
10 verbose lifecycle<EMAIL_ADDRESS>CWD: /Users/ptiw10/Desktop/practice/react/react-unit-testing
11 silly lifecycle<EMAIL_ADDRESS>Args: [ '-c',
11 silly lifecycle   'mocha --compilers js:babel-core/register --require ./test/test_helper.js --recursive ./test' ]
12 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null
13 info lifecycle<EMAIL_ADDRESS>Failed to exec test script
14 verbose stack Error<EMAIL_ADDRESS>test: mocha --compilers js:babel-core/register --require ./test/test_helper.js --recursive ./test
14 verbose stack Exit status 1
14 verbose stack     at EventEmitter. (/usr/local/lib/node_modules/npm/lib/utils/lifecycle.js:239:16)
14 verbose stack     at emitTwo (events.js:106:13)
14 verbose stack     at EventEmitter.emit (events.js:191:7)
14 verbose stack     at ChildProcess. (/usr/local/lib/node_modules/npm/lib/utils/spawn.js:24:14)
14 verbose stack     at emitTwo (events.js:106:13)
14 verbose stack     at ChildProcess.emit (events.js:191:7)
14 verbose stack     at maybeClose (internal/child_process.js:877:16)
14 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
15 verbose pkgid<EMAIL_ADDRESS>16 verbose cwd /Users/ptiw10/Desktop/practice/react/react-unit-testing
17 error Darwin 14.5.0
18 error argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "test"
19 error node v7.0.0
20 error npm  v3.8.6
21 error code ELIFECYCLE
22 error<EMAIL_ADDRESS>test: mocha --compilers js:babel-core/register --require ./test/test_helper.js --recursive ./test
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>test script 'mocha --compilers js:babel-core/register --require ./test/test_helper.js --recursive ./test'.
23 error Make sure you have the latest version of node.js and npm installed.
23 error If you do, this is most likely a problem with the redux-simple-starter package,
23 error not with npm itself.
23 error Tell the author that this fails on your system:
23 error     mocha --compilers js:babel-core/register --require ./test/test_helper.js --recursive ./test
23 error You can get information on how to open an issue for this project with:
23 error     npm bugs redux-simple-starter
23 error Or if that isn't available, you can get their info via:
23 error     npm owner ls redux-simple-starter
23 error There is likely additional logging output above.
24 verbose exit [ 1, true ]

It seems I have the same issue.  What version of Node and npm are you running?

@andrit the version information as at the top of debug.log

@mikeerickson right, thanks.  Have you had this issue at all?

@andrit no, it works fine for me. I will have a look at this closer in the morning when back In computer.  I am sure it will be a straightforward fix

@mikeerickson thatd be great.
I also found this in my terminal:
SyntaxError: /Users/UserName/Directory/react-redux-starter/test/test_helper.js: Unexpected token (21:4)
19 | function renderComponent(ComponentClass, props = {}, state = {}) {
20 |   const componentInstance =  TestUtils.renderIntoDocument(

21 |     <Provider store={createStore(reducers, state)}>
|     ^
22 |       <ComponentClass {...props} />
23 |
24 |   );

@andrit : How did you get the repo ? I mean did you use "Download Zip" or "Open in Desktop" ?
I was having this problem when I downloaded the zip. But then, it worked fine when I used the other option, which is "Open in Desktop". I hope this will fix it. At least it worked for me. Not sure how and why though !!

@prakashgbid Actually I used git clone in my terminal.  I'll try it the other way though.  Thanks.

@prakashgbid & @mikeerickson
This fixed it for me:
I didnt have a .babelrc file for some reason.
contents must match whats found here: https://github.com/StephenGrider/AdvancedReduxCode/blob/master/testing/.babelrc


fix(allow-scripts): add corepack to bannedBins

Part of Node.js bundled package manager management tooling.
https://nodejs.org/api/corepack.html
https://www.npmjs.com/package/corepack

Makes sense to add this. Altho I'm not happy with how complex the overall implementation is and I'm not sure if I want this feature out of experimental.


bug: export default

There not supposed to be the need of destructuring when importing the getIndex() function.

Fixed by commit 43f216223b589ca25b8802dd83013f9c25a55c54


data available

Hi
I'd like to inquire whether the input for the program should be 'subread.bam' or a BAM file processed through CCS? And is there any sample data available for testing purposes?
Best
Zhongyu

Hello,
The input to MethBat is actually the output from pb-CpG-tools, and pb-CpG-tools accepts an aligned HiFi bam file as input.  More information on usage is available in the user guide: https://github.com/PacificBiosciences/MethBat/blob/main/docs/user_guide.md#quickstart
We currently do not have a small test dataset to verify the tool is working.  However, there are publicly available CCS datasets you could use.  Some datasets sequenced on Revio can be found here: https://downloads.pacbcloud.com/public/revio/2022Q4/.  Those datasets include a pre-aligned BAM file, so you would just need to download the file, run pb-CpG-tools to get individual methylation loci, and then MethBat to summarize across the CpG islands.
This is an alpha release tool, so we welcome any suggestions or feedback you may have!
Matt

Closing for now, feel free to re-open if needed.


Add API validation script to CI

SwiftNIO uses a script built on top of the Swift API digester command line tool to validate that PRs do not cause semver major breaking changes. This script could be adapted for the use cases of protobuf as well, and help avoid ambiguity around whether a change is breaking or not.
Note that, while this script is helpful, it does encounter some false positives. In particular it tends to believe that adding a protocol customisation point with a default implementation is a semver major, when so far as we can tell it is not (it's ABI breaking, I think, but not a semver major).

Happened to find https://github.com/ltetzlaff/swift-api-diff today.  Don't suppose SwiftNIO is looking at make a standard github action out of this?

The script also needs jq installed, which isn't on macOS be default.

If the community has already done a standard GitHub action I'm more than happy to defer to that!

Since it seems to have a copy of the script, i wasn't sure how insync it is staying, etc.  Is there any coordination with them?

It also looks like it posts back to the comments, which means it needs a github token.  That likely means someone on Apple's side would need to sign off on it before we could use it here.
@tbkka I'm guessing the need for a secret to post back means it shouldn't be used here?

Also looks like despite the script having xcrun support, the Xcode toolchains don't include swift-api-digester, so it also requires a custom toolchain install for macOS.

@thomasvl -- Yeah, we should avoid anything that needs a secret to post back.

@Lukasa should I open a nio issue asking for a standard action that doesn't require write access?

@thomasvl Sure, worst-case we can say we think it's out of scope. But I think an action is a nice approach.

Opened https://github.com/apple/swift-nio/issues/1600


Live

Test

Docs Build status updates of commit 25476ec:
:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Test PR


Carpentry@UiO websites: can we have 1 (outside UiO domain) website?

Board discussed Carpentry@UiO relevant websites.
Now under UiO/UB, we have pages relevant to the community (https://www.ub.uio.no/english/writing-publishing/dsc/carpentry-uio/index.html) and workshops (https://www.ub.uio.no/english/courses-events/courses/other/Carpentry/), but only designated UB staff can edit them, and thus it is not optimal to have only these pages.
Meanwhile, Carpentry@UiO has the following websites, in addition to use of GitHub repo as source of various important information, such as onboarding.
https://uio-carpentry.github.io/
https://uio-carpentry.github.io/studyGroup/
https://governance.readthedocs.io/
Ideally, it is best to have everything in one place, but if this is not reasonable/possible at least as few places as possible.
From user point of view, what is the optimal solution here?
Personally, I see the following advantages and disadvantages for each option:

ReadtheDocs format (the one used for governance)

Advantage: it is very neat and nicely fits manual-type of documents, probably also for archiving minutes or reports as well.
Disadvantage: Migration from MD file is a bit difficult?

MD-based solution, such as "bookdown" (ex. https://cdh.carpentries.org/)

Advantage: Based on R Markdown. Could be more people in the community who knows about this well?
Disadvantage: change in the URL?

Using GitHub repos as they are

Advantage: not much works need to be done
Disadvantage: not very visible, difficult to find information?

I agree with you Naoe, that there are too many Carpentry @ UiO  websites. I'm actually surprised by how up to date the information on all of them is! I suppose that's only thanks to your and Annika's ability to keep on top of this chaos!
My thoughts on streamlining our web presence:
What?
I think we should have two websites:

the UiO website(s) should be our official point of contact with "outsiders". It should have all the information about workshops and "who are we". All that people need to find workshops, learn about the Carpentries, contact us and sign up.  it should be the main "point of contact". I understand maintenance by non-UiO members is not possible, but I wonder if that is actually a problem, given how things are organized at the moment? Having the UiO branding is important, I think.

Ideally, the two pages on the UiO website (one, two) should be one, but I understand there might be reasons for this, and the separation into "info" and "workshop announcements" is not too bad.
(Sidenote: there are a couple of missing images in the workshop list)
The UiO site should link to our Github page https://uio-carpentry.github.io/ for the study group and other day to day activities.

https://uio-carpentry.github.io/ should be the home to "less official" stuff and "day to day" activities, such as governance docs, board meeting minutes, but also study group activities.

We should avoid duplicating content from the UiO website (!) In particular: What is the value of maintaining the past course list and future announcements on Github?
I would make the study group related content part of https://uio-carpentry.github.io/ The study group isn't active enough to need its own website, and it is better if there is only one site to maintain.
I suggest to incorporate the governance docs into https://uio-carpentry.github.io. The URL https://governance.readthedocs.io/ sounds like it's not specific for UiO Carpentries. From what I can tell it's basically one medium-length markdown document split across multiple files, with a nice template. Migration from .rst to .md shouldn't be a problem.

How?

I'd use a markdown-based static site generator. In combination with GitHub Actions, setting up a site that rebuilds automatically when changes to the markdown are made is straightforward. Personally, I like Hugo. It builds quickly, isn't too hard to customize and has lots of themes.
We could use R's blogdown or distill. That way, people who are comfortable with using RStudio have a nice IDE to make changes to the markdown, submit pull requests,  etc.
I could fork the current website repo, set up a Hugo site there, add the governance and study group content and make a PR. But we need to decide together what should be on that site.

Awesome!! Thanks for the great suggestion and volunteering! Looking forward to seeing your HUGO based website 🥰
Reg. 1-1, as it was explained at the board meeting.
2-2, i have been aware, but actually on the event page, the figure is shown. So i have no idea how to fix them. Can anyone help here?

Hei!
To give my two cents to this discussion:
I agree that the University Library needs the website(s) hosted at UiO for workshops, incl. an overview website like the one we have now. This is at least as important for how we communicate about the Carpentries workshops and to our learners as it is internally for how we communicate our efforts to the library which generously pays the annual membership.
When it comes to the materials on GitHub, I see the following scenario:

the "backlog" of our workshops, now its own repo under (https://github.com/uio-carpentry/uio-carpentry.github.io), could be moved into (https://github.com/uio-carpentry/organisational), i.e. the "index.md" file that contains the backlog could be moved into https://github.com/uio-carpentry/organisational/reporting. It's mainly been used for keeping an overview of what we have done, our "history" so to speak.

ACTION: move index.md to https://github.com/uio-carpentry/organisational/reporting, rename to backlog.md
ACTION: disable GitHub Pages, update README.md with info about move and archiving the repo and then archive (https://github.com/uio-carpentry/uio-carpentry.github.io)

the governance repo hosts mainly our statutes. I would argue that there should be an easy way to access and display the contents of our statutes on the web. Since we are not an official UiO organisation, I'd rather it NOT be on the UiO web, but, for example, stay on GitHub. Since the governance repo is a live document, it needs updating and a maintainer. I would argue that it is the duty of the UiO-Carpentry Board to keep the contents up to date and that a Board member should be assigned the task to be active maintainer and implement changes etc.
the organisational repo has all our community documents. It's mainly used by the local coordinators and other community members and contains info on how we run things here at UiO-Carpentry. It has no website, and I strongly believe that it doesn't need one. I would see it as our "archive" where we keep meeting minutes, reports, workshop how-tos, onboarding documents, but also our logo files, templates, etc. I would strongly advice against moving content out of this repo or using other repos for the same functions (i.e. the governance should not contain meeting minutes etc.).
StudyGroup is its own thing, but I agree with @Teebusch that it's contents could be incorporated somewhere else, however, the repo has two main functions: (1) List of events and activities, (2) backlog of materials for StudyGroup sessions for reference. How could this be handled smoothly when moving StudyGroup content somewhere else? Also, the studygroup repo was created by @annefou, she should be part of the discussion!

Cheers,
Annika

I'm not sure if I understand the suggested ACTION correctly, but I wouldn't disable the uio-carpentry.github.io, just make the separation of concerns clearer and consolidate the 3 github-based websites into one.
We could even keep the backlog on uio-carpentry.github.io, but we should tell people who are interested in participating that they should go to the UiO site.
Migrating the study group repo's content into uio-carpentry.github.io smoothly should be possible with a bit of git. Same for the governance docs. Instead of merging the repos into one, we could also load the governance and/or study group repos as a submodule. That way we can keep the documents in a separate repos but render all in the same place, i.e. uio-carpentry.github.io
I agree that keeping the organisational repo separate is best and that the org repo doesn't need a website for itself. If we want to render some of the org documents on uio-carpentry.github.io, we can also load the repo as a git submodule. I think the checklists and reports would actually be nice to include on the website. But for starters, we could simply add links.

@naoe-tatara

2-2, i have been aware, but actually on the event page, the figure is shown. So i have no idea how to fix them. Can anyone help here?

It's a problem with the parentheses in the filename:
Link on the course website (works):
/english/courses-events/courses/other/Carpentry/images/jekyll_%28software%29_logo.png**
Link on the workshop list website (doesn't work):
/english/courses-events/courses/other/Carpentry/images/jekyll_%2528software%2529_logo.png?vrtx=thumbnail

%28 %29 are escape charaters for parentheses ( and )
%25 is escape character for the % (see here)

So it seems like the parehteses in the original image name are being escaped twice.
I don't know how things are connected in Vortex and why the double escaping occurs, but I think an easy fix would be to remove the parenthesis from the original image filename...

I'm not sure if I understand the suggested ACTION correctly, but I wouldn't disable the uio-carpentry.github.io, just make the separation of concerns clearer and consolidate the 3 github-based websites into one.

OK, if we want to keep the URL, that makes sense!

We could even keep the backlog on uio-carpentry.github.io, but we should tell people who are interested in participating that they should go to the UiO site.

I think it's not important enough info to keep it there. I'd move it into organisational/reporting. One less thing to keep updated in its own repo. Organisational is constantly monitored, so updating is taken care of.

Migrating the study group repo's content into uio-carpentry.github.io smoothly should be possible with a bit of git. Same for the governance docs. Instead of merging the repos into one, we could also load the governance and/or study group repos as a submodule. That way we can keep the documents in separate repos but render all in the same place, i.e. uio-carpentry.github.io

Right, it doesn't need to be all in one repo. However, I think in regards to maintenance, it's easier to have overview over what's going on and what needs updating in one repo than in 2 or more. Might be solved with clear communication and actually assigning repo maintainers; in this case: a website maintainer as well.

I agree that keeping the organisational repo separate is best and that the org repo doesn't need a website for itself. If we want to render some of the org documents on uio-carpentry.github.io, we can also load the repo as a git submodule. I think the checklists and reports would actually be nice to include on the website. But for starters, we could simply add links.

Hm… ok, I see that reports and workshop docs are of a broader interest and thus could be displayed on a website. If this would work with an integration that allows for the material to stay in organisational, I'm all for it! But if it's too much hassle and maintenance, I'd rather have them not displayed, but only linked to.
Best,
A.

I don't know how things are connected in Vortex and why the double escaping occurs, but I think an easy fix would be to remove the parentheses from the original image filename...

@Teebusch , thank you so much, it worked!!! Yay! Great that I could learn new things today, too 💯

Thank you for the active discussion on this issue! I edited the title of this issue to avoid some confusions ;)
If the repos can be kept as they are but still we can have one place i.e. https://uio-carpentry.github.io/ to gather things to be published (or at least linked from, to md files such as minutes), I think it is great. Personally we can assign one person for each repo to make the maintenance easier. If necessary, that person can assign someone else to work on things.

While I agree with @Teebusch on his first comment 1 and 2, I wonder about information duplicates on these places.
Indeed we should avoid having same information in different places, while probably it would be nice to have "sufficient" information on the community intro page, hereafter INTRO page  under ub.uio to invite other people as well as to make it visible to UB people. Also annual reports should be either separately linked from INTRO page or even PDF files should be archived in Vortex?
But then what is "sufficient" information?
I understand that the current INTRO page may be a bit overwhelming and not really "inviting". How can we improve this page? Should we actually keep only

"Join us" (until "contact") on top (as suggested by Tobias on the last board meeting) with a link to uio-carpentry.github.io for more details,
"who we are" next in accordion style with A) board members, B) all in org. mailing list, and C) alumni, (of course after getting consent from each, which is on my To-Do list),
and grey box about the Carpentries at the bottom?

I personally think the following 2 sections can be left out from INTRO page:

Vision/Mission Statement -> ATM it is copy and paste from the governance document. To avoid duplicates, we can keep the INTRO page simple to eventually improve the first headlines (in italic, right under the logo) and leave out this section?
Code of conduct -> I think it is reasonable to have one for workshops under workshop intro page (https://www.ub.uio.no/english/courses-events/courses/other/Carpentry/) and the other under https://uio-carpentry.github.io/ or inside governance document

I set up a "proof of concept" Hugo site. You can see it here: https://github.com/Teebusch/uio-carpentry.github.io
(repository).
It's very rough around the edges and the theme isn't exactly pretty, but...

It loads the government docs and reports from the org / gov repos (using Hugo modules)
it renders automatically when changes are made to any of the files in the repo (using Github actions). It won't render automatically when changes are made to the org / gov repos, but there's probably a way to make that automatic, too.
The study group page has a lot of content. Making it fit the new structure will be a bit of work, so I didn't bother.

Excellent work, @Teebusch !! Great that it works 💯  I have no idea about Hugo and probably that is why, it was not easy to see how the site was generated. But maybe this is the theme for the next study group session? Anyways, I think this is a great way to integrate everything into one place.
sidenote: probably Carpentry@UiO is not "a part of" UiO, but rather "supported by" UiO/UB? As there are many people who have no official connection to UiO.

That's awesome! I am really very happy to see such improvement. We have done lots of things in the past that probably made sense at that time but are now completely obsolete! Time to move forward!!!!

Two important questions: would it be okay for me to ...

completely merge the study group page into the github.io page, and eventually archive the study group repo? That would mean study group activity should be tracked in the github.io repo. I will try to make sure no content is lost, of course.
strip down the readthedocs governance repo to markdown files, and remove all the "readthedocs" stuff.  Actually I would prefer to simply merge the charter and intro into the github.io repo, too, given how little content it is. But I understood that  not everyone agrees.

@naoe-tatara

sidenote: probably Carpentry@UiO is not "a part of" UiO, but rather "supported by" UiO/UB? As there are many people who have no official connection to UiO.

Good point. I've fixed it. Generally, I am not keen on doing the editorial work, so I'll leave it up to others to brush up the text once everything is in place. I'm happy to be fiddle around with all the web technology stuff, though! :)
(And sure, we could make a study group session where we do an intro to Hugo and then a little hackalong, where we fix up the site.)

I agree on the 2 points above. From @annefou 's comment above, I don't think anyone disagree on 1 at least. IMO, if folders are clearly labeled within github.io repo, it should be fine.
And I understand about the text and the theme :)

I agree on both points. I think it is a good way to move forward. Many thanks @Teebusch

I've done a bit of work on the redesign of the page now. A lot of little things aren't quite working yet, and the theme isn't very exciting. But I'd be happy to get some feedback. I suggest to handle feedback in the pull request, unless it's "big picture" stuff.

Thank you for the great works, @Teebusch !!
If the workshops are fed automatically, this is fantastic 💯  I went through all the menus shown on the left-hand side one, but will make comments and change-suggestions (like links etc.) later.
Maybe one possibly big picture comment: "email examples" and "post workshop template" could be left out, as they can be actually implemented in Pindena, which only local coordinators need as info and they are not actually used by instructors.
In that case, they should not be in the corresponding repo/folder in this GitHub account, either, right?

As I said at the PR, this is really nice! Thanks @Teebusch. Once we agree to use this design, we could have a small session to go over all text together and submit PR's for improvement. If you haven't noticed, the theme is responsive to my Mac's Light/Dark Appearance setting also!
I'd also appreciate a StudyGroup session on HUGO-based websites...
By the way, I suspect that when you write 'backlog', you mean past workshops, not backlog as things-still-to-be-done...

As I said at the PR, this is really nice! Thanks @Teebusch. Once we agree to use this design, we could have a small session to go over all text together and submit PR's for improvement. If you haven't noticed, the theme is responsive to my Mac's Light/Dark Appearance setting also!
I'd also appreciate a StudyGroup session on HUGO-based websites...
By the way, I suspect that when you write 'backlog', you mean past workshops, not backlog as things-still-to-be-done...

I wonder if it's time to close this issue?

Absolutely. I will close this.


Carla crashes with some scenarios when recording

Describe the bug
Some scenarios, e.g., FollowLeadingVehicle_1 lead to a crash when the --record flag is set. Other scenarios can be recorded, e.g., when OpenScenario is used or ChangeLane_1 don't.
The crash occurs with the call of:
self.client.start_recorder(recorder_name, True) in scenario_runner.py
I'm using the release version of carla. I also tried it with the docker container. Both have the same behavior.
There are some very rare random occasions when this doesn't lead to a crash, but I cannot see why.
To Reproduce

Start FollowLeadingVehicle_1 scenario with --record path/to/file

Desktop (please complete the following information):

OS: [e.g. Ubuntu 20.04]
CARLA Version [e.g. CARLA 0.9.13]
Python version [e.g. 3.8]

it crashes with

Signal 11 caught.
Malloc Size=65538 LargeMemoryPoolOffset=65554
CommonUnixCrashHandler: Signal=11
Malloc Size=131160 LargeMemoryPoolOffset=196744
Malloc Size=131160 LargeMemoryPoolOffset=327928
Engine crash handling finished; re-raising signal 11 for the default handler. Good bye.
Segmentation fault (core dumped)

It doesn't happen when the SCENARIO_RUNNER_ROOT is not set right.

One additional information I found out today: When I use self.client.start_recorder(recorder_name, True) it crashes. When I replace True with False there is no problem any more. However, then the metric tool doesn't have all information available.


[AVM Module Issue]: Site module doesnot support flex consumption  functionapp

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Feature Request
Module Name
avm/res/web/site
(Optional) Module Version
No response
Description
Flex functionapp creation is not supported at the moment as it looks for Site.FunctionAppConfig for deployment .
Error message : Site.FunctionAppConfig is invalid.  The FunctionAppConfig section was not specified in the request, which is required for Flex Consumption sites. To proceed, please add the FunctionAppConfig section in your request.
(Optional) Correlation Id
No response

Hi @sonalika-roy Thanks for opening the issue. I will have a look at it.

[like]  Sonalika Roy reacted to your message:

From: Pankaj Agrawal @.>
Sent: Wednesday, October 2, 2024 1:41:48 PM
To: Azure/bicep-registry-modules @.>
Cc: Sonalika Roy @.>; Mention @.>
Subject: Re: [Azure/bicep-registry-modules] [AVM Module Issue]: Site module doesnot support flex consumption functionapp (Issue #3389)
Hi @sonalika-royhttps://github.com/sonalika-roy Thanks for opening the issue. I will have a look at it.
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/bicep-registry-modules/issues/3389#issuecomment-2388676625, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AT564SRUIWWNHI6IIOJN7DTZZPZZZAVCNFSM6AAAAABPHVXWI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBYGY3TMNRSGU.
You are receiving this because you were mentioned.Message ID: @.***>

This has been addressed in 0.10 today. Thanks all.

[heart]         Sonalika Roy reacted to your message:

From: Pankaj Agrawal @.>
Sent: Monday, October 7, 2024 8:00:30 AM
To: Azure/bicep-registry-modules @.>
Cc: Sonalika Roy @.>; Mention @.>
Subject: Re: [Azure/bicep-registry-modules] [AVM Module Issue]: Site module doesnot support flex consumption functionapp (Issue #3389)
This has been addressed in 0.10 today. Thanks all.
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/bicep-registry-modules/issues/3389#issuecomment-2396195730, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AT564SSSKX53V43EDWQFG2TZ2I5R5AVCNFSM6AAAAABPHVXWI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJWGE4TKNZTGA.
You are receiving this because you were mentioned.Message ID: @.***>


Refresh gmail page through GmailJS API

Hi,
Here is my query,

Does the library supports to invoke Google refresh button.
Does gmail.observe.before('refresh', function(x,y,z){}); event fires when Gmail implicitly refresh the page when new message arrives.

Thanks in Advance.
Regards,
Shashikiran

I'm not sure I follow.
I think the simplest way for you to find out if this library covers your need, is to simply run the demo-extension found in this repo and try using the API yourself in the web-console.


Swift concurrency fails consistently under load

Description
Even really simple swift concurrent tasks fail under load repeatedly

Steps to reproduce
Download and this really simple task group based looping example:
https://github.com/brianm998/SwiftConcurrentBug/blob/develop/Sources/main.swift
I've tested this on macos on the command line, the above repo is a barely modified stock swift cli app.
While failure is not 100%, it fails about half the time, more when the system is under load from other processes as well.
The code is really simple (slightly condensed from the repo above):
let maxNumberOfTasks = ProcessInfo.processInfo.activeProcessorCount*10
let maxNumber = 10000000

let dispatchGroup = DispatchGroup()
dispatchGroup.enter()
Task {
    await withTaskGroup(of: Void.self) { taskGroup in
        for _ in 0..<maxNumberOfTasks {
            taskGroup.addTask() {
                var base = 0
                for _ in 0..<maxNumber {
                    base += 1
                }
            }
        }

        await taskGroup.waitForAll()
    }
    dispatchGroup.leave()
}
dispatchGroup.wait()

All this code is doing is incrementing a variable 'base' which should be local to each Task that is running it.  No other memory access should be taking place from within each Task.
I ran into this problem when developing https://github.com/brianm998/nighttime_timelapse_airplane_remover, and using the thread sanitizer to figure out why the crash was happening.
My solution has been to implement a 'limited' task group https://github.com/brianm998/nighttime_timelapse_airplane_remover/blob/develop/NtarCore/Sources/NtarCore/LimitedTaskGroup.swift
which mostly works, as long as the system isn't busy with something else too.
With this limited task group I can reduce the number of currently executing tasks to hit a given number, which is better than nothing.
However this bug still pops up frequently during my video processing workflow as my machine is oftentimes at 0.1% idle due to lots of processes competing for CPU time.

Expected behavior
I expect this code to always run to completion, and not to crash with memory corruption

Environment

Swift compiler version info
Apple Swift version 5.8 (swiftlang-<IP_ADDRESS>.2 clang-14<IP_ADDRESS>.100)
Target: x86_64-apple-macosx13.0

Xcode version info
Xcode 14.3
Build version 14E222b

Deployment target: macOS 10.15

Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64
swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-<IP_ADDRESS>.2 clang-14<IP_ADDRESS>.100)
I was able to catch it in lldb with the malloc_error_break set, as was suggested by a previous crash.
This was not hard to repro.
Sun Apr 30 13:36:07 PDT 2023
Garth:SwiftConcurrentBug brian$ lldb .build/debug/SwiftConcurrentBug
(lldb) target create ".build/debug/SwiftConcurrentBug"
Current executable set to '/Users/brian/git/SwiftConcurrentBug/.build/debug/SwiftConcurrentBug' (x86_64).
(lldb) b malloc_error_break
Breakpoint 1: where = libsystem_malloc.dylib`malloc_error_break, address = 0x00007ff80023b78d
(lldb) run
Process 33949 launched: '/Users/brian/git/SwiftConcurrentBug/.build/debug/SwiftConcurrentBug' (x86_64)
Hello, cruel world!
SwiftConcurrentBug(33949,0x70000b6a4000) malloc: *** error for object 0x600000c00210: pointer being freed was not allocated
SwiftConcurrentBug(33949,0x70000bc45000) malloc: Heap corruption detected, free list is damaged at 0x600000bfffd0
*** Incorrect guard value: 0
SwiftConcurrentBug(33949,0x70000b6a4000) malloc: *** set a breakpoint in malloc_error_break to debug
SwiftConcurrentBug(33949,0x70000c475000) malloc: Heap corruption detected, free list is damaged at 0x600000bfffd0
*** Incorrect guard value: 0
SwiftConcurrentBug(33949,0x70000bc45000) malloc: *** set a breakpoint in malloc_error_break to debug
SwiftConcurrentBug(33949,0x70000b392000) malloc: Heap corruption detected, free list is damaged at 0x600000bfffd0
*** Incorrect guard value: 0
Process 33949 stopped
* thread #9, queue = 'com.apple.root.user-initiated-qos.cooperative', stop reason = breakpoint 1.1
    frame #0: 0x00007ff805d6a78d libsystem_malloc.dylib`malloc_error_break
libsystem_malloc.dylib`malloc_error_break:
->  0x7ff805d6a78d <+0>: pushq  %rbp
    0x7ff805d6a78e <+1>: movq   %rsp, %rbp
    0x7ff805d6a791 <+4>: nop
    0x7ff805d6a792 <+5>: nopl   (%rax)
  thread #20, queue = 'com.apple.root.user-initiated-qos.cooperative', stop reason = breakpoint 1.1
    frame #0: 0x00007ff805d6a78d libsystem_malloc.dylib`malloc_error_break
libsystem_malloc.dylib`malloc_error_break:
->  0x7ff805d6a78d <+0>: pushq  %rbp
    0x7ff805d6a78e <+1>: movq   %rsp, %rbp
    0x7ff805d6a791 <+4>: nop
    0x7ff805d6a792 <+5>: nopl   (%rax)
Target 0: (SwiftConcurrentBug) stopped.
(lldb) bt
* thread #9, queue = 'com.apple.root.user-initiated-qos.cooperative', stop reason = breakpoint 1.1
  * frame #0: 0x00007ff805d6a78d libsystem_malloc.dylib`malloc_error_break
    frame #1: 0x00007ff805d5b5b8 libsystem_malloc.dylib`malloc_vreport + 761
    frame #2: 0x00007ff805d5e951 libsystem_malloc.dylib`malloc_report + 151
    frame #3: 0x00007ff8143dabef libswiftCore.dylib`protocol witness for Swift.Collection.subscript.read : (τ_0_0.Index) -> τ_0_0.Element in conformance Swift.Dictionary<τ_0_0, τ_0_1>.Keys : Swift.Collection in Swift with unmangled suffix ".resume.0" + 15
    frame #4: 0x00007ff81434a1ff libswiftCore.dylib`Swift.IndexingIterator.next() -> Swift.Optional<τ_0_0.Element> + 399
    frame #5: 0x0000000100006526 SwiftConcurrentBug`closure #1 in closure #1 in closure #1 in  at main.swift:18:21
    frame #6: 0x0000000100006f10 SwiftConcurrentBug`thunk for @escaping @callee_guaranteed @Sendable @async () -> (@out A) at <compiler-generated>:0
    frame #7: 0x0000000100007040 SwiftConcurrentBug`partial apply for thunk for @escaping @callee_guaranteed @Sendable @async () -> (@out A) at <compiler-generated>:0
(lldb) quit
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] y
Garth:SwiftConcurrentBug brian$ date
Sun Apr 30 13:39:18 PDT 2023
Garth:SwiftConcurrentBug brian$ swift --version
swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-<IP_ADDRESS>.2 clang-14<IP_ADDRESS>.100)
Target: x86_64-apple-macosx13.0
Garth:SwiftConcurrentBug brian$ uname -v
Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64

cc @ktoso

Thanks for reporting, this seems very suspicious, not quite sure what to make of it just yet.
It does not seem to reproduce on an M1 machine, we'll have to check on x86 probably.
The task group isn't really doing much here, hm...
You mention your workaround also fails;

Does the same issue happen in your actor implementation of a "group" (I would not call that a group, it does not create child tasks, but I understand it's just a workaround attempt).
Have you tried writing the same reproducer with async let, statically declare as many asynclets as this task group would declare and see if the failure happens -- it would help if you could check if it reproduces there as well, we could see if it narrows it down to the group or is general problem with child tasks somehow

rdar://108836511

When I filed this a few days ago, I was able to get the referenced code to crash easily.  My machine was also running lots of other tasks at that time, not sure if that's related.
Today I tried to implement what @ktoso suggested, getting rid of the task group and defining lots of tasks in another way.  After failing to get any of those implementations to fail, I went back to the checked in code that I did see fail.
However, I was unable to get that to fail today, even when running three at the same time.  No other processes were active on my machine.
TL;DR;
This is less than 50% repro, and can be hard to reproduce in testing.

Thanks for attempting to reproduce, it definitely helps to know it's a rare thing like that. We'll see if we can find out what's happening here, thanks


Analyzer speed improvements

This PR is mostly about improving the analysis browser so it can export diffable versions of DBs.
The analyzer perf improvement comes from deferring all files from *.test[s].* packages into a second analysis. Effectively, we let test packages import from their surrounding package, but not feed analysis back into them. This results in significantly less results, most of which appear as fewer parameter types (which are basically unused anyway).
In a majority of cases, these look like improvements (losing incorrect information), while there are some cases where we lose correct information about some attribute types. Given the speed improvement in the initial analysis, this seems to be worthwhile.
We also now ensure that all analyzer packages are loaded when analyzing others, and allow the order to be overridden to ensure certain packages are analyzed first (addresses #1136).

LGTM other than the slightly odd loop

The loop is basically unavoidable, and I don't really like any of the alternatives I can think of for a transpose operation like that.


Also returns Views

The description of the TABLE_TYPE column strongly hints that INFORMATION_SCHEMA.TABLES also returns views, but since this is SQL Server documentation and, in SQL Server lingo, an View is not a Table, the first line should read: "Returns one row for each table and view ..." instead of "Returns one row for each table ...".

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

ID: e30b4e4b-db09-dca7-eb8d-41cf92e44f7c
Version Independent ID: 8cc873ab-faef-83bb-44c9-dc3ade947f76
Content: TABLES (Transact-SQL) - SQL Server
Content Source: docs/relational-databases/system-information-schema-views/tables-transact-sql.md
Product: sql
Technology: system-objects
GitHub Login: @CarlRabeler
Microsoft Alias: carlrab

@HeinziAT - thank you for this comment. We're updating the docs. The update should be live in the next ~24 hours


1.21.1 support

Does 1.21.1 support already exist? And if so, can the modrindth page be updated?

1.21.x should work already
I'm in the process of preparing v3 right now, so all the project pages are gonna be updated shortly anyways


docs: Mention passing name instead of locale ID

Passing locale as name instead of ID (public code) is more user friendly and branching friendly option. It was there, but not mentioned in the documentation previously.

@theSoenke _as_id suggests that the identifier is passed as id (and not as locale_id). There are other endpoints that would benefit from a similar clarification, and they would have project_id_as_id or account_id_as_id for example.


Guarantee that dict keep order ?

With Python 3.6+, dict are guarantee to keep insertion order.
Currently, tree and tf.nest both seems to keep dict order, but jax.tree_util does not. It's not clear if this is an implementation detail or if this behavior is guaranteed.
I'm worried that the internal discussions from https://github.com/deepmind/tree/pulls#1 may lead to a regression if Jax implementation is reused.
import tree
import tf
import jax

def fn(x):
  return x

data = {'z': None, 'a': None}

print(tf.nest.map_structure(fn, data))  # {'z': None, 'a': None}
print(tree.map_structure(fn, data))     # {'z': None, 'a': None}
print(jax.tree_map(fn, data))           # {'a': None, 'z': None}  << Oups, keys order inverted

It would be great if this behavior was documented and there was a unittest to avoid regression.

Hey @Conchylicultor I think JAX tree functions will always return keys in sorted order because that is the order that they are iterated inside the map function:
>>> d = {'e': 'e', 'a': 'a', 'b': 'b'}
>>> _ = jax.tree_map(print, d)
a
b
e

Tree and tf.nest actually have the same behavior (traverse dictionaries in sorted order):
>>> _ = tree.map_structure(print, d)
a
b
e

So perhaps it is a bit odd that the return value has the insertion order of the first tree passed to map_structure (if you imagine us inserting results into the output in traversal order you would expect insertion order on the result to be sorted). Another perhaps odd quirk is that if both input dicts have different orders we use the order from the first:
>>> d1 = {'e': 'e1', 'a': 'a1', 'b': 'b1'}
>>> d2 = {'a': 'a2', 'b': 'b2', 'e': 'e2'}
>>> str(tree.map_structure(lambda *_ : None, d1, d2))
{'e': None, 'a': None, 'b': None}
>>> str(tree.map_structure(lambda *_ : None, d2, d1))
{'a': None, 'b': None, 'e': None}

That said, this library is sufficiently popular that making a change to iteration order of the result would be a fairly major change (e.g. we would need to make sure this did not break our users) and there is no work currently planned to make this happen.
I'm not sure if the tree team want to commit to keeping insertion order for the first argument to map for ever, but I don't think this is likely to change any time soon.

If we were replacing dict by OrderedDict, then your above points wouldn't hold anymore. On the contrary, it would be an argument in favour of keeping insertion order.
It would feel quite inconsistent that dict and OrderedDict behave differently in Python 3.6 when dict are guarantee to keep insertion order.
OrderedDict sort the keys:
>>> tree.map_structure(print, collections.OrderedDict({'e': 'e', 'a': 'a', 'b': 'b'}))
a
b
e

But keep insertion order, even when there are additional arguments:
>>> d1 = collections.OrderedDict({'e': 'e1', 'a': 'a1', 'b': 'b1'})
>>> d2 = collections.OrderedDict({'a': 'a2', 'b': 'b2', 'e': 'e2'})
>>> print(dict(tree.map_structure(lambda *_ : None, d1, d2)))
{'e': None, 'a': None, 'b': None}

The insertion key sorting is required to make sure that flattening a dict and OrderedDict match independently of the key order.
I really believe Jax behavior is a bug and the behavior should be guarantee in Tree.


ShortcutEvents are not working on mobile platform.

Is there an existing issue for this?

[X] I have searched the existing issues

Flutter Quill version
10.8.5
Steps to reproduce

Write '' at first and then jot something down and write '' at last.
Write '-' at first and then press the Spacebar.
Write '#' at first and then press the Spacebar.

Expected results
On Step 1, characters should be changed to Italic style.
On Step 2, the block style of this line should be changed to the bulleted list.
On Step 3, the block style of this line should be changed to the numbered list.
Actual results
Nothing are changed.
Additional Context

Screenshots / Video demonstration
https://github.com/user-attachments/assets/3601d263-a235-45b5-90b6-e23d29095954
https://github.com/user-attachments/assets/69a5e360-34b3-4d5e-acf8-773d3e92cd96

Source Codes
import 'package:flutter/material.dart';
import 'package:flutter_quill/flutter_quill.dart' as quill;

class FlutterQuillWidget extends StatefulWidget {
  const FlutterQuillWidget({super.key});

  @override
  State<FlutterQuillWidget> createState() => _FlutterQuillWidgetState();
}

class _FlutterQuillWidgetState extends State<FlutterQuillWidget> {
  late quill.QuillController _controller;
  final _editorFocusNode = FocusNode();
  final _editorScrollController = ScrollController();
  bool canScroll = false;

  @override
  void initState() {
    super.initState();
    _controller = quill.QuillController(
        document: quill.Document(),
        selection: const TextSelection.collapsed(offset: 0));
  }

  @override
  void dispose() {
    _controller.dispose();
    _editorFocusNode.dispose();
    _editorScrollController.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        resizeToAvoidBottomInset: false,
        appBar: AppBar(
          title: const Text('Flutter Quill'),
        ),
        body: Column(
          children: [
            Expanded(
                child: SingleChildScrollView(
                    controller: _editorScrollController,
                    child: Column(children: [
                      quill.QuillToolbar.simple(controller: _controller),
                      quill.QuillEditor(
                        controller: _controller,
                        scrollController: _editorScrollController,
                        focusNode: FocusNode(),
                        configurations: quill.QuillEditorConfigurations(
                            scrollable: false,
                            characterShortcutEvents:
                                quill.standardCharactersShortcutEvents,
                            spaceShortcutEvents:
                                quill.standardSpaceShorcutEvents,
                            expands: false,
                            placeholder: "Add your data here..."),
                      ),
                    ])))
          ],
        ));
  }
}

Any plan to support shortcut events for mobile devices?

Currently, it's unsupported by default using Flutter, if we had plans, we would need platform code for Android and iOS, which will be in the plugin quill_native_bridge.
This plugin is not in a state where we can add more features, need to fix the TODOs and the current issues first.