[data reusables] Typo in command_line.open_the_multi_os_terminal?

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
All articles that use the macro {% data reusables.command_line.open_the_multi_os_terminal %}.
I stumbled across the unclear wording in Generating a new GPG key.
I've attached a screenshot with the text-in-question highlighted.

What changes are you suggesting?
On my browser, expansion of the {% data reusables.command_line.open_the_multi_os_terminal %} reads "Open TerminalTerminalGit Bash.". This does not sound correct, which is why I'm suggesting a change.
Given the data is titled "multi_os", I don't have a good cross-platform suggestion here other than maybe just "Open Terminal/Git Bash."
The expected outcome is for that reusable sentence - which boils down to asking the user to open a terminal/Git bash with Git installed - to be less ambiguous.
Additional information
No response

The reusable file is available here.
You can see that there are actually 3 <span> tags with classes that are specifically designed to show based on the platform users are on(maybe using navigator.platform) and hide the others.
But in your case it seems like none of the span tags got hidden. I wonder what browser you are using :/
I personally think this is not the proper way cuz now if you open the same docs page on any other device(like android, iPad etc), it just hides all the span tags. weird.

@aprotyas - thank you so much for letting us know about this problem in the docs and for digging in to see where the problem was ✨
The docs engineering team have made several changes to how the site works recently and it seems as if those <span> tags were being ignored when you looked at that page. As far as I can tell, the page is now displaying correctly again.
I'm going to close this issue, but if you find that the page still looks broken in your browser, please reopen it and we can investigate further.

CLOSED...
On Thu, 2 Dec 2021, 8:43 pm Felicity Chapman, @.***>
wrote:

Closed #12469 https://github.com/github/docs/issues/12469.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/github/docs/issues/12469#event-5705576328, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ASCF2TVDJATAF3H7ULEUOODUO5SXXANCNFSM5JA2E63A
.

Just confirming that the page is displaying correctly on my end as well. Thank you!


JS/TS language features keep restarting

Type: Bug
Unfortunately, I have no idea how to reproduce this, but am happy to demonstrate in a pairing session with someone.
Description: For the last week or so, I've seen VS Code attempting, and failing, to fully load its JS/TS language features. VS Code eventually shows a prompt, which reports that the extension has crashed and been restarted repeatedly in the last five minutes, and that it may be related to the Svelte plugin. However, I have disabled that plugin (as well as the Glint plugin we use for our Ember code) and it continues to occur, and in fact I have done the "Reload with extensions disabled" command and that has the same problem.

It does indeed reproduce in that mode.
https://user-images.githubusercontent.com/2403023/214440004-58915119-8816-4e2b-a2fb-e34a38fb41ee.mp4

My colleague @hmajoros did some further debugging and found a bit more info:

vscode attempts to create a TS project to better analyze the non-TS package you are in, and kicks off a build for every single reference ’d project we have in the top level tsconfig.json

As suggested by that, we have a “solution”-style tsconfig.json for a mixed-TS-and-JS project.

Can you please try collecting the TS Server log from the crashed instance. To do this:
1.In your setting Set "typescript.tsserver.log": "verbose"

Restart VS Code and reproduce the problem

Open the TypeScript section of the output panel

At the very top, find the first line that prints to path to the semantic error log file. It should look something like:
[Info  - 19:54:59.247] <semantic> Log file: /Users/matb/Library/Application Support/Code - Insiders/logs/20200213T104930/exthost55/vscode.typescript-language-features/tsserver-log-ZT2zau/tsserver.log

That file contains the typescript logs.

Look through that log file for the first error or stack trace you see and please share that. If you can share the log, I can take a look to see if anything stands out

⚠Warning: The TypeScript log may include information from your workspace, including file paths and source code. If you have any concerns about posting this publicly on Github, just let me know and we can arrange something else. On our side, we only use these logs to investigate issues like this

here are the last few lines of my tsserver.log
Info 10594[12:08:05.077] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/addons/organization-shared/addon/components/tsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10595[12:08:05.077] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/addons/organization-shared/addon/components/jsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10596[12:08:05.077] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/addons/organization-shared/addon/tsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10597[12:08:05.077] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/addons/organization-shared/addon/jsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10598[12:08:05.077] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/addons/organization-shared/tsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10599[12:08:05.077] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/addons/organization-shared/jsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10600[12:08:05.077] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/addons/tsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10601[12:08:05.077] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/addons/jsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10602[12:08:05.078] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/tsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10603[12:08:05.078] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/packages/jsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10604[12:08:05.078] FileWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/jsconfig.json 2000 undefined WatchType: Config file for the inferred project root
Info 10605[12:08:05.079] Starting updateGraphWorker: Project: /dev/null/inferredProject1*
Info 10606[12:08:05.087] DirectoryWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/node_modules 1 undefined Project: /dev/null/inferredProject1* WatchType: Failed Lookup Locations
Info 10607[12:08:05.087] Elapsed:: 0.008130013942718506ms DirectoryWatcher:: Added:: WatchInfo: /Users/hmajoros/Job/voyager-web/node_modules 1 undefined Project: /dev/null/inferredProject1* WatchType: Failed Lookup Locations
Info 10608[12:08:05.087] FileWatcher:: Added:: WatchInfo<EMAIL_ADDRESS>2000 undefined Project: /dev/null/inferredProject1* WatchType: File location affecting resolution
Info 10609[12:08:05.089] FileWatcher:: Added:: WatchInfo<EMAIL_ADDRESS>2000 undefined Project: /dev/null/inferredProject1* WatchType: File location affecting resolution
Info 10610[12:08:05.096] FileWatcher:: Added:: WatchInfo<EMAIL_ADDRESS>2000 undefined Project: /dev/null/inferredProject1* WatchType: File location affecting resolution

once we get to this point, in the Output tab we see a new tsserver log created, and this loops on indefinitely:
[Info  - 17:07:02.51] Starting TS Server
[Info  - 17:07:02.51] Using tsserver from: /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js
[Info  - 17:07:02.53] <syntax> Log file: /Users/hmajoros/Library/Application Support/Code/logs/20230131T115846/window1/exthost/vscode.typescript-language-features/tsserver-log-CQctWX/tsserver.log
[Info  - 17:07:02.53] <syntax> Forking...
[Info  - 17:07:02.55] <syntax> Starting...
[Info  - 17:07:02.56] <semantic> Log file: /Users/hmajoros/Library/Application Support/Code/logs/20230131T115846/window1/exthost/vscode.typescript-language-features/tsserver-log-J4pOhd/tsserver.log
[Info  - 17:07:02.56] <semantic> Forking...
[Info  - 17:07:02.57] <semantic> Starting...
[Error  - 17:08:19.15] TSServer exited. Code: null. Signal: SIGABRT
[Info  - 17:08:19.15] TSServer log file: /Users/hmajoros/Library/Application Support/Code/logs/20230131T115846/window1/exthost/vscode.typescript-language-features/tsserver-log-J4pOhd/tsserver.log
[Info  - 17:08:19.16] Starting TS Server
[Info  - 17:08:19.16] Using tsserver from: /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js
[Info  - 17:08:19.17] <syntax> Log file: /Users/hmajoros/Library/Application Support/Code/logs/20230131T115846/window1/exthost/vscode.typescript-language-features/tsserver-log-svW805/tsserver.log
[Info  - 17:08:19.17] <syntax> Forking...
[Info  - 17:08:19.18] <syntax> Starting...
[Info  - 17:08:19.19] <semantic> Log file: /Users/hmajoros/Library/Application Support/Code/logs/20230131T115846/window1/exthost/vscode.typescript-language-features/tsserver-log-55o6Vv/tsserver.log
[Info  - 17:08:19.19] <semantic> Forking...
[Info  - 17:08:19.20] <semantic> Starting...
[Error  - 17:09:29.604] TSServer exited. Code: null. Signal: SIGABRT
[Info  - 17:09:29.604] TSServer log file: /Users/hmajoros/Library/Application Support/Code/logs/20230131T115846/window1/exthost/vscode.typescript-language-features/tsserver-log-55o6Vv/tsserver.log
[Info  - 17:09:29.604] Starting TS Server
[Info  - 17:09:29.604] Using tsserver from: /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js
[Info  - 17:09:29.605] <syntax> Log file: /Users/hmajoros/Library/Application Support/Code/logs/20230131T115846/window1/exthost/vscode.typescript-language-features/tsserver-log-Wwwoes/tsserver.log
[Info  - 17:09:29.605] <syntax> Forking...
[Info  - 17:09:29.606] <syntax> Starting...
[Info  - 17:09:29.606] <semantic> Log file: /Users/hmajoros/Library/Application Support/Code/logs/20230131T115846/window1/exthost/vscode.typescript-language-features/tsserver-log-6SWIni/tsserver.log
[Info  - 17:09:29.606] <semantic> Forking...
[Info  - 17:09:29.607] <semantic> Starting...

let me know if you need additional info. FWIW I didn't see any specific Error logs in the tsserver.log

Hey @mjbvz, this issue might need further attention.
@chriskrycho, you can help us out by closing this issue if the problem no longer exists, or adding more information.

This is still an issue in our large monorepo; I believe @hmajoros had made a little more progress on why but not much. Net, it seems like Code is trying to start up a new TSServer instance for every project in the monorepo—and failing. Given hundreds of packages in the monorepo, this makes for quite the noisy experience!


Certain constants appear to be missing (e.g. WINSTA_ALL_ACCESS)

Summary
One example is WINSTA_ALL_ACCESS (MSDN link) that is defined in WinUser.h:
#define WINSTA_ALL_ACCESS           (WINSTA_ENUMDESKTOPS  | WINSTA_READATTRIBUTES  | WINSTA_ACCESSCLIPBOARD | \
                                     WINSTA_CREATEDESKTOP | WINSTA_WRITEATTRIBUTES | WINSTA_ACCESSGLOBALATOMS | \
                                     WINSTA_EXITWINDOWS   | WINSTA_ENUMERATE       | WINSTA_READSCREEN)

The other WINSTA_* constants are included here:
https://github.com/microsoft/windows-rs/blob/a2fbd102010a20ac35ff0d950e44f193cd032751/crates/libs/sys/src/Windows/Win32/UI/WindowsAndMessaging/mod.rs#L2345-L2353
Another random example of missing constants is WVR_REDRAW (defined as WVR_HREDRAW | WVR_VREDRAW), where similarly other WVR_* constants do exist.
However not all constants of the same shape are missing. E.g. WS_OVERLAPPEDWINDOW is defined in the similar way from WinUser.h and is indeed included here.
Crate manifest
No response
Crate code
No response

Thanks, will move this to upstream metadata repository where the bug lies.


autotools-based build system

This PR switches Bifrost to an autotools-based build system would should solve many of the installation issues that people report, e.g., #109, #134, and #154.  It also adds a .m4 and a pkg-config file to help other projects that may depend on Bifrost find an installation.
This also address a few outstanding issues with Bifrost, including:

support for the cuda_managed memory space on Pascal and later devices (#111)
support for the ci32 data type in bf.map (#130)
PEP479 support (#147)
switch to an "official" version of ctypesgen (#161)

Finally, this PR also moves away from TravisCI in favor of GitHub Actions.

Codecov Report

Merging #157 (1766cbe) into master (1681fde) will increase coverage by 0.64%.
The diff coverage is 70.64%.

:exclamation: Current head 1766cbe differs from pull request most recent head a1596cd. Consider uploading reports for the commit a1596cd to get more accurate results

@@            Coverage Diff             @@
##           master     #157      +/-   ##
==========================================
+ Coverage   58.46%   59.10%   +0.64%
==========================================
  Files          65       65
  Lines        5549     5661     +112
==========================================
+ Hits         3244     3346     +102
- Misses       2305     2315      +10

Impacted Files
Coverage Δ

python/bifrost/psrdada.py
1.63% <0.00%> (-0.01%)
:arrow_down:

python/bifrost/sigproc2.py
45.94% <20.00%> (-7.66%)
:arrow_down:

python/bifrost/blocks/binary_io.py
93.44% <33.33%> (-6.56%)
:arrow_down:

python/bifrost/dtype.py
25.00% <33.33%> (+0.82%)
:arrow_up:

python/bifrost/DataType.py
64.86% <42.85%> (-0.81%)
:arrow_down:

python/bifrost/ndarray.py
75.91% <45.45%> (-1.21%)
:arrow_down:

python/bifrost/proclog.py
32.43% <50.00%> (-0.45%)
:arrow_down:

python/bifrost/blocks/serialize.py
89.11% <66.66%> (-0.62%)
:arrow_down:

python/bifrost/sigproc.py
86.69% <70.00%> (-0.06%)
:arrow_down:

python/bifrost/pipeline.py
83.69% <75.00%> (-0.90%)
:arrow_down:

... and 33 more

Continue to review full report at Codecov.

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

@telegraphic and @league what do you think about this?  Do you think it is ready to be merged in or does it need more work/testing?

I'm wondering though, is it your experience that the GPU-requiring tests are reliably passing? I have a VM with GeForce RTX 3090 and CUDA 11 that succeeds through configure (it auto-detects GPU arch 80) and builds, but it's reporting a few failures.
Ran 275 tests in 713.388s
FAILED (failures=4, errors=24, skipped=5)

I vaguely recall running into something like this in the past with regards to the FFT tests but it wasn't consistent.  Are all of your failures related to the FFT tests?  Also, what do the errors look like?

This could be a really small (but compelling) use case for a reproducible build step… once we can define clearly what autoconf needs to do the right thing (which maybe won't be easy), we can leave the job of regenerating ./configure to that tool. But in general I agree it's a mistake to leave configure out of the repo and push the problem onto the user with a bootstrap script.

I looked into how I build the configure file and I use autotools installed via homebrew on my laptop.  I get around the various m4 problems with a cache of m4 files that I found I needed.  Even with all of this I still end up with "possible undefined macro: AM_DEFAULT_VERBOSITY" error which pops up from the doxygen configuration step.

I don't mean to delay the autoconf merge any further, I think it could become master ASAP. But I noticed this message a lot when running ./configure:
./configure: line 7404: /usr/bin/file: No such file or directory

It seems like the absolute path to file originates with libtool? But the file command is not guaranteed to be installed, it's not part of coreutils. And even if it is installed, it may not be in /usr/bin. This error occurs on colab because their ubuntu doesn't have file installed. The same may be true on qblocks. And on NixOS it's not part of the base install either, but even when it is installed, it won't be in /usr/bin. So why doesn't libtool just get it from the PATH? If it's a real dependency, I guess we can specify it as such, but configure shouldn't hard-code its location.
I can't tell where this error has caused any harm. I guess it's trying to determine object format, and whether it requires special linker flags... and on these 64-bit gcc/gnu/linux boxes, we don't need them.

Hrm, I hadn't noticed that /usr/bin/file problem.  Maybe we could do something like this?  https://lists.gnu.org/archive/html/bug-libtool/2014-06/msg00005.html

Interesting how Ludovic got some push-back on that thread! (He's a Guix developer, which is very similar to NixOS). It's funny, for those systems this is pretty easily solved (if it even matters) by a patch step that would just sed references to /usr/bin/file into the appropriate hashed version in /nix/store/zzzzz-file/bin/file.
What was more curious/alarming to me is that I see the same message on Ubuntu. It seems that file is not part of a basic install, and not even part of build-essential. So we don't have it on Google colab or a default ubuntu docker image either:
$ docker run -it --rm ubuntu:latest file --version
docker: Error response from daemon: OCI runtime create failed:
container_linux.go:380: starting container process caused: exec: "file":
executable file not found in $PATH: unknown.

But none of these platforms seem to need those linker flags libtool is detecting, so perhaps moot point. Maybe this is just something to keep an eye on. Or just recommend file as one of our prerequisites: sudo apt install exuberant-ctags file

In the absence of a clear direction to go in maybe we just leave the file thing alone.


fix: use exact version instead of range operator when bumping prerelease or with a specific preid

Resolves #31

This new prerelease pulls in a version of unicorn-magic that has a poorly configured conditional export which causes rollup to be unable to bundle it. I would drop execa ideally:
<EMAIL_ADDRESS>/Users/wtodd/Projects/Netflix/fifteen
└─┬<EMAIL_ADDRESS>-> ./packages/utils
  └─┬<EMAIL_ADDRESS>    └─┬<EMAIL_ADDRESS>      └─┬<EMAIL_ADDRESS>        └──<EMAIL_ADDRESS>

thanks for the feedback. I can rollback the dep updates for this, to see if that addresses. dropping execa is a bit out of scope for this PR

if you'd like to try out a version (local only, unpublished) of this without execa, feel free to take a look at the diff here for this branch:
https://github.com/benduran/lets-version/compare/drop-execa?expand=1
Branch: drop-execa

actually, I published a version. it passes the test suite with the updates made in this PR, but YMMV. I don't currently have an enterprise testbed project in my current role, so I have to lean on you to try it out<EMAIL_ADDRESS>


feat(techdocs-module-lightbox): Enable zoom for techdocs images inside lightbox

Hey, I just made a Pull Request!
Most of our users did not figure out themselves, that it's possible to zoom the images in the techdocs by scrolling. Therefore they found their own workarounds for this issue (e.g. writing under each image that it must be opened in a new tab by rightclicking in order to zoom).
We'd like to solve this issue now by allowing the users to zoom the image to fit the viewport when clicking on the zoom icon. The icon automatically changes (based on the mechanism used by photoswipe itself (issue, code)
These images demonstrate the behaviour changes:

The zoom icon in the top right corner is visible - per default it displays the zoom icon, once zoomed in it shows the zoom out icon.
On click it zooms the image to fit in the viewport

:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[x] ~Tests for new functionality and regression tests for bug fixes~
[x] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

In my opinion this definitely is not stale.. Could someone take a look at this PR, please? :)

Thanks for the approval :)
Over the Weekend I had the idea, that it might be good not to zoom further then fullwidth via the button. I'll try to adjust this PR to that behaviour today :)

I've updated the PR and the code :)
What do you thing @backstage/techdocs-maintainers ?

Still not stale in my opinion :)

Hey @backstage/techdocs-maintainers could you please take a look at the PR? It's a rather small change. Please let me know if you have any questions.


Build and run inside docker image

Motivation
Proposal rendered as image:

Essentially, right now our build pipeline is pretty complex:

We're doing a lot of work to be able to build arm64 images, but then we never end up using them.
We're building static binaries, even though we're still running them inside containers (kind defeats the purpose)
We have 2 separate Dockerfiles, 3 places in which we set the Rust version.
We have to setup QEMU on our pipeline in order to build for the proper architecture - again, never using the problematic architecture in the end.

What I'm proposing is a drastic simplification:
A single Dockerfile in the sequencer repo
A single place to set the Rust version
No explicit support for arm64
We build the binary inside the container in which it will be run
We build the binary "the normal way", i.e. with dynamic linking

Solution

PR Checklist

[ ] Added Tests
[ ] Added Documentation

Codecov Report

Merging #562 (e0a33d3) into main (e13a4f3) will increase coverage by 0.01%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##             main     #562      +/-   ##
==========================================
+ Coverage   56.25%   56.27%   +0.01%
==========================================
  Files          49       49
  Lines       10111    10108       -3
==========================================
  Hits         5688     5688
+ Misses       4423     4420       -3

Flag
Coverage Δ

test
56.27% <ø> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes

Continue to review full report in Codecov by Sentry.

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


Can't install via pip

" Could not find a version that satisfies the requirement joypy (from versions: )
No matching distribution found for joypy"

...probably because I'm on 2.7.
Sorry about that.


Query to find all object with a certain custom field value

Hello,
My request is, I have different Post Types and some of them are linked. ( I have my post type "place" and my post type "news", one news is linked to a place via a custom field )
On my "Place" page, I'd like to list all the news related to it. What I do for the moment is I created a Helper function, which finds all the news for the place. My worry is I'm doing a query which is too long to execute :
mesAnims = CamaleonCms::Site.first.posts.sort_by_field("date-de-debut", "desc").where(post_type: 69)
In other words, i find all the news. And then I do a loop to get only the ones for my current item.
`lesAnims = []
  mesAnims.each do |anim|

    if !anim.get_fields('bistrot-associe',0)[0].nil? && anim.get_fields('bistrot-associe',0)[0] == @post.id.to_s

        lesAnims.push(anim)

    end

  end`

I would like to know if I could avoid this loop to directly add a "Where mycustomfieldslug = myvalue" .
Thanks a lot,

Hi @floreasy I improved this part and also I added small docs (sorting, filtering, preloading) here:
http://camaleon.tuzitio.com/documentation/category/40756-uncategorized/custom-fields-1.html
Please review and let me know if it works well for you.

Hi @owen2345 and thanks a lot for improving this documentation.
However, I just do not get one thing, in this :
Cama::PostType.first.posts.includes(:custom_field_values).merge(CamaleonCms::CustomFieldsRelationship.where(custom_field_slug: 'my_slug_key'))
What is "custom_field_slug:" ? Is it like the name of the slug ? For example if the slug is like a city, would it be something like : where(my_slug_for_city: "Paris" ? Or am I wrong ?
Hopefully then I'll be OK with my queries :)
Thanks a lot again,
Flo

By the way, when i use .includes(:custom_field_values) I have an error :
The association scope 'custom_field_values' is instance dependent (the scope block takes an argument). Preloading instance dependent scopes is not supported.

custom_field_slug is the DB column name to save the custom_field key.
Example:
Cama::PostType.first.posts.includes(:custom_field_values).merge(CamaleonCms::CustomFieldsRelationship.where(custom_field_slug: 'my_slug_for_city', value: 'Paris'))
# Filtering all posts that contains custom field key = "my_slug_for_city" and custom field value is "Paris".

Check image for the structure:

Please bundle update, I released another version with the changes *.11

Yes, I just found out 5 minutes ago and now I see it on your comment :)
Anyway, thanks a lot, and indeed I had also to bundle update.
Thank you !


HBASE-25680  Non-idempotent test in TestReplicationHFileCleaner

The test org.apache.hadoop.hbase.master.cleaner.TestReplicationHFileCleaner.testIsFileDeletable is not idempotent and fail if run twice in the same JVM, because it pollutes some states shared among tests. It may be good to clean this state pollution so that some other tests do not fail in the future due to the shared state polluted by this test.
Detail
Running TestReplicationHFileCleaner.testIsFileDeletable twice would result in the second run failing due to the following assertion error:
java.lang.AssertionError: Cleaner should allow to delete this file as there is no hfile reference node for it in the queue.

The root cause is that the a hfile reference is added during the first test run, which doesn't get removed upon test exits. Therefore, in the second test run , cleaner.isFileDeletable(fs.getFileStatus(file))) would return false, resulting in the assertion error.
The suggested fix is to remove the hfile reference created during the test when the test exits.
With the proposed fix, the test does not pollute the shared state (and passes when run twice in the same JVM).
Jira link: https://issues.apache.org/jira/browse/HBASE-25680

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 40s
Docker mode activated.

Is there a JIRA that goes w/ this PR? Thanks.

@lzx404243  Please see above comments. Thanks.

@saintstack I've created a jira issue for this: https://issues.apache.org/jira/browse/HBASE-25680
Thanks!

Thanks @lzx404243  I fixed the subject so it points to your new JIRA. Did you see @Apache9 's comment above? Thanks

Thanks @saintstack for updating the subject.
@Apache9 Please let me know what you think of my reply to your comment (See above).  Thanks!

Thanks @saintstack for updating the subject.
@Apache9 Please let me know what you think of my reply to your comment (See above). Thanks!

Sorry, missed your previous reply. It will be good to remove all HFileRefs in tearDown.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
4m  0s
Docker mode activated.

 Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

 Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

 Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 47s
the patch passed

+1 :green_heart:
compile
1m 17s
the patch passed

+1 :green_heart:
javac
1m 17s
the patch passed

+1 :green_heart:
shadedjars
9m 18s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 41s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
201m 48s
hbase-server in the patch passed.

237m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2984/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2984

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 184f8e841a84 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / e65fc9226f

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2984/2/testReport/

Max. process+thread count
3161 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2984/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Thanks @Apache9  for the approval! Is there anything I can do before this can be merged? Thanks!

Oh, sorry... Will merge soon.
Thanks for the reminding~


Allow use of tokens (eg date, time, etc) in output filenames

Would be useful for allowing logs to be tracked over time

From README.md:
Note: if any of the file elements in resourceLog or auditLog contain tokens of the format: %xxxx these will be replaced by datetime tokens per https://moment.github.io/luxon/#/formatting?id=table-of-tokens. In this way, output files can be named uniquely based on the current datetime. For example:
  csv:
    file: 'resources.%yyyy%LL%dd.csv'


Error after Queuing in Classic LFGBrowser

When queuing in <IP_ADDRESS>716 Anniversary Realms, the addon throws an error after listing yourself for a dungeon and you cannot browse groups anymore in the finder.
Error:
6x [ADDON_ACTION_BLOCKED] AddOn 'GearScoreClassic+' tried to call the protected function 'Search()'.
[string "@!BugGrabber/BugGrabber.lua"]:485: in function <!BugGrabber/BugGrabber.lua:485>
[string "=[C]"]: in function Search' [string "@Blizzard_GroupFinder_VanillaStyle/Blizzard_LFGVanilla_Browse.lua"]:250: in function LFGBrowse_DoSearch'
[string "@Blizzard_GroupFinder_VanillaStyle/Blizzard_LFGVanilla_Browse.lua"]:189: in function SearchActiveEntry' [string "@Blizzard_GroupFinder_VanillaStyle/Blizzard_LFGVanilla_ParentFrame.lua"]:95: in function LFGParentFrame_SearchActiveEntry'
[string "@Blizzard_GroupFinder_VanillaStyle/Blizzard_LFGVanilla_Listing.lua"]:77: in function <...pFinder_VanillaStyle/Blizzard_LFGVanilla_Listing.lua:54>
Locals:
_ = Frame {
}
event = "ADDON_ACTION_BLOCKED"
events =  {
}

Hey,
thanks for the report!
Sadly i dont have the capacity to update this plugin anymore. Ill mark it as such.
However this plugin was made to fix a bug with scaling in SOD. Since your playing the new Classic servers you do not have low level Epic items (what caused the bug).
I recommend switching over to the other popular GearScore plugin!
Thanks for using GearScoreClassic!


Remove duplicate fields from Contact page and ui change of vertical scrollbar

Hey, the contact form and map occur two times and that's not needed so I want to remove one from them. Also, I want to change the vertical scrollbar UI. Can you please assign it to me?

Want to fix this issue, please assign it to me @Anupkjha2601


[CSL-2331] improve synchronisation / communication between outbound queue threads and client threads

Previously: when enqueueing the caller gets a Map NodeId (m (Either SomeException t)) as soon as the outbound queue has completed enqueueing. The ms in that map will block until the relevant conversation (to the given NodeId) has been dequeued and completed.

It's impossible to abort an enqueued conversation before it is dequeued.
It's impossible to get a hold of the conversation's thread id and, for instance, throw exceptions to it, or link it to another thread in the Async style.

This implements the improved interface:
enqueue
    :: OutboundQ msg nid buck
    -> MsgType nid
    -> msg a
    -> IO [(nid, TVar (PacketStatus a))]

data PacketStatus a = InFlight (Async a) | Pending | Aborted

-- Abort a pending enqueued thing. No-op if it's already in flight.
-- [Not implemented in this ticket but easy to do]
abortPacket :: TVar (PacketStatus a) -> IO ()

-- Block until the packet is in flight. Give Nothing if it's aborted (outbound queue itself never aborts them).
-- [Not implemented in this ticket but easy to do]
threadForPacket :: TVar (PacketStatus a) -> IO (Maybe (Async a))

This will help @karknu with the implementation of CSL-2148
Part of this change is to make the outbound queue use IO explicitly, rather than Mockable/MonadIO/MonadThrow/WithLogger etc. Turns out it still fits nicely into cardano-sl. I think we ought to make the full diffusion layer use IO as well, and ditch our Network.Transport.Abstract shim. Fact is: whenever we need a forall y . hugeMonadTransformer y -> IO y we have one.

Need a review please.
@dcoutts @coot @karknu

Pushed a new commit to make the logging aspect of outbound queue a bit more sane.
I wanted it to be in IO, so the log-warper stuff was problematic: we need a HasLoggerName m instance, which IO does not have. So now we can't use IO, simply because of our choice of logging system.
Solution: outbound queue uses a Trace ~ Op (IO ()) (Severity, Text) value to do logging. One can be made from a LoggerName and String queue name. In practice for the full diffusion layer we use "diffusion.outboundqueue" and the queue name comes from the network configuration.


Forks

Completing the second sprint. Code base now includes MsgRegisterBtcDepositAddress, MsgRegisterReserveAddress and MsgConfirmBtcDeposit.
"btc" token now gets minted on the chain after receiving the ConfirmBtcDeposi message from the btc-oracle.

Merging without review in interest of time.


[bug / misconfig]: externalip=ipv6:customport creates weird getinfo with pubkey@[ipv6:9735]:customport

Background
Trying to get all three declarations into the config, ipv4, tor and ipv6. I've played with various configuration options for listen and externalip, but there might be a bug with custom-ports and ipv6 and I'd like this to be validated.
Your environment

version of lnd: 0.17.0-beta commit=v0.17.0-beta
which operating system (uname -a on *Nix): Linux Debian12 bookworm
version of btcd, bitcoind, or other backend: Bitcoin Core version v25.0.0 pruned
any other relevant environment details

Steps to reproduce

IPv4 = port 9736
Tor = usual port 9735
IPv6 = port 9737 (if using the same port for listen, LND can't start due to bind issues

Oct 17 15:07:03 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 lnd[1925967]: unable to create server: listen tcp [::1]:9736: bind: address already in use
Oct 17 15:07:03 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 systemd[1]: lnd.service: Main process exited, code=exited, status=1/FAILURE
Oct 17 15:07:03 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 systemd[1]: lnd.service: Failed with result 'exit-code'.
Oct 17 15:07:03 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 systemd[1]: lnd.service: Consumed 2.019s CPU time.

So I've tried two options to achieve the custom ports
lnd.conf Option 1
listen=<IP_ADDRESS>:9736
listen=[::1]:9737
externalip=2a01:4ff:1f0:84c0::1
nat=false
debuglevel=info
externalip=<IP_ADDRESS>:9736

results in the following lncli getinfo, taking the standard-port 9735
    "uris":  [
        "02dad1bfca6b7da45746783955f6765601b1f8c4208deef38f48cdf43dff7da58a@[2a01:4ff:1f0:84c0::1:9735]",
        "02dad1bfca6b7da45746783955f6765601b1f8c4208deef38f48cdf43dff7da58a@<IP_ADDRESS>:9736",

lnd.conf Option 2
So how about defining the custom-port 9737 in the externalip attribute?
listen=<IP_ADDRESS>:9736
listen=[::1]:9737
externalip=2a01:4ff:1f0:84c0::1:9737
nat=false
debuglevel=info
externalip=<IP_ADDRESS>:9736

This creates a weird IPv6 declaration, with both the standard-port and the custom-port showing up
    "uris":  [
        "02dad1bfca6b7da45746783955f6765601b1f8c4208deef38f48cdf43dff7da58a@[2a01:4ff:1f0:84c0::1:9735]:9737",
        "02dad1bfca6b7da45746783955f6765601b1f8c4208deef38f48cdf43dff7da58a@<IP_ADDRESS>:9736",

Expected behaviour
When setting a custom-port on IPv6 externalip, it should override the standard port 9735 for gossip.
Actual behaviour
For what it's worth, on LND startup, the listening entry for both IPv4 and IPv6 seem to be working:
Oct 17 15:09:02 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 lnd[1926899]: 2023-10-17 15:09:02.342 [INF] CMGR: Server listening on [::]:9736
Oct 17 15:09:02 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 lnd[1926899]: 2023-10-17 15:09:02.342 [INF] SRVR: Initializing peer network bootstrappers!
Oct 17 15:09:02 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 lnd[1926899]: 2023-10-17 15:09:02.342 [INF] SRVR: Creating DNS peer bootstrapper with seeds: [[nodes.lightning.directory soa.nodes.lightning.directory] [lseed.bitcoinstats.com ]]
Oct 17 15:09:02 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 lnd[1926899]: 2023-10-17 15:09:02.342 [INF] CMGR: Server listening on [::1]:9737

Is that some configuration issue on my side, or is that an edge case bug for IPv6 custom ports?

Thanks.
Applied the change, now the custom port on IPv6 apparently changed their sequence
pubkey@[ipv6:custom]:default
Startup-logs
Oct 17 18:36:53 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 lnd[2018756]: 2023-10-17 18:36:53.299 [INF] CMGR: Server listening on [::]:9736
Oct 17 18:36:53 debian-m-4vcpu-8gb-hil1-02-tunnelsats-8 lnd[2018756]: 2023-10-17 18:36:53.299 [INF] CMGR: Server listening on [::1]:9737

lncli getinfo
    "uris":  [
        "02dad1bfca6b7da45746783955f6765601b1f8c4208deef38f48cdf43dff7da58a@[2a01:4ff:1f0:84c0::1:9737]:9735",
        "02dad1bfca6b7da45746783955f6765601b1f8c4208deef38f48cdf43dff7da58a@<IP_ADDRESS>:9736",
        "02dad1bfca6b7da45746783955f6765601b1f8c4208deef38f48cdf43dff7da58a@ylbwl6clzy5cr6bhnjknxh4um7c3afxwwajzwx7f52oxrbq3qddav2qd.onion:9735"
    ],

That looks good @sputn1ck 👍
results into 02dad1bfca6b7da45746783955f6765601b1f8c4208deef38f48cdf43dff7da58a@[2a01:4ff:1f0:84c0::1]:9737
Now I'll just setup another server and try to connect via IPv6 to validate. Will close the issue here as soon I was able to confirm. If it works, I'll probably follow up with a PR for the lnd-sample.conf, I think the documentation around listen / externalhost/ip on IPv6 can be improved.

Works, I was able to connect to an IPv6 address outbound and established the connection.
listen=tcp6://[::1]:9737
externalip=[2a01:4ff:1f0:84c0::1]:9737

was the setting that solved for it.


Switching from all to bin wrapper in an existing project fails the build

Given an existing project. Switching from an all wrapper to a bin wrapper will fail all builds if the ~/.gradle/wrapper folder does not contain both wrappers. Something is cached in the projects .gradle folder and the ./gradlew execution will try to access the all wrapper for the project even though it should use the bin.
The following exception is present:
> java.nio.file.NoSuchFileException: /Users/<username>/.gradle/wrapper/dists/gradle-7.0.1-all/9uuh8w1zvoizo76q69rcku82c/gradle-7.0.1/lib/plugins/gradle-diagnostics-7.0.1.jar`

Expected Behavior
Switching from all to bin wrapper works without issues.

I took a look. Here are closer reproduction instructions:
> gradle wrapper --gradle-version 7.0.1 --distribution-type all

> ./gradlew build

> ./gradlew --status
   PID STATUS   INFO
 19642 IDLE     7.0.1

> gradle wrapper --gradle-version 7.0.1 --distribution-type bin

> rm -rf ~/.gradle/wrapper/dists/gradle-7.0.1-*

> ./gradlew --status
   PID STATUS   INFO
 19642 IDLE     7.0.1

> ./gradlew build
FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'daemon-all-vs-bin'.
> java.nio.file.NoSuchFileException: ~/.gradle/wrapper/dists/gradle-7.0.1-all/9uuh8w1zvoizo76q69rcku82c/gradle-7.0.1/lib/plugins/gradle-diagnostics-7.0.1.jar

> ./gradlew --status
   PID STATUS   INFO
 19642 IDLE     7.0.1

So the problem is that a Gradle daemon is running, and we re-use this Gradle daemon no matter if the all distribution is used or the bin distribution is used. So if a daemon is running started from the all distribution, then the distribution type is changed and then you run another build the daemon running with the all distribution is still in use.
If you now remove the downloaded distributions, when running a new build the wrapper will correctly re-download the bin distribution, though the daemon is still running with the classpath pointing to the all distribution. So on the next invocation the build fails.
It is not very surprising that a Gradle daemon does not work after the files from its distribution have been deleted. The only thing you need to do is to run ./gradlew --stop before/after deleting the downloaded wrapper directory. Then everything will work again afterwards.
I am not sure we need to do something on the Gradle side here. We could make the distribution type an input to the daemon, so we would automatically start a new daemon when the distribution type changes. Though I am not sure that is necessary.

I agree with the analysis provided. Since you can only hit this issue when actually deleting a downloaded wrapper and leaving a daemon running, I do not see us prioritizing making the distribution type an input to the daemon.


[bug] linux 导出数据失败

Describe the bug

Reproduction
No response
Expected behavior
No response
Application and system information
{
  "appName": "EcoPaste",
  "appVersion": "0.2.0-beta.2",
  "tauriVersion": "2.0.3",
  "platform": "linux",
  "platformArch": "aarch64",
  "platformVersion": "22.4.0"
}

Additional context
No response

问题跟踪：https://github.com/tauri-apps/plugins-workspace/issues/1927


[stable/datadog] Fix RBACs

Which issue this PR fixes

fixes https://github.com/helm/charts/issues/22045

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

/lgtm


add support for envFrom on enterprise chart

Summary
Adds the ability to specify envFrom on the enterprise chart, allowing for an easier setup of lots of environment variables for configuration (pulling all k/v pairs in as envs rather than having to add 1 by 1).
Ticket Link
None opened but happy to open an issue if this warrants further discussion.

Hello @mjnagel,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Thank you @mjnagel for your contribution 🚀


first commit

created a branch, created a file and made a commit, and opened a pull request

Okay


Delete resources

This what the alertbox looks like right now. Do we want more styling?

Thoughts on using a modal? https://semantic-ui.com/modules/modal.html
@katiejiang @HanaPearlman

Also, was thinking of using this:
https://sweetalert.js.org/docs/#configuration

Ooh that's such a pretty alert! The only problem is that it doesn't exactly match our style, but I think the difference is small, so would be down to either use that or use a Semantic UI modal @stephanieyshi @robertaninfeliz

This is really cool! I would switch the order of Yes and Cancel, and change the text from "Yes" to "Yes, delete this resource" and make the color red, and make the color of the cancel button grey. Or make both grey!

Modal looks good!

I think it might be helpful to add a flash in the redirect after the resource is deleted to let them know that their resource has been successfully deleted.
Could you also move the position of the delete button? Feel free to use whatever you think is best! Can also consider using a Semantic UI divider between the "Save Resource" button and the "Delete Resource" button.


Error Handler: Compact offsets and symbol displacements

This PR implements compact offsets and symbol displacements in MD Debugger and Error Handler to save screen space and avoid line-breaks.

Offsets are 24-bit when displaying locations (e.g.: 00000200 EntryPoint  -> 000200 EntryPoint ;
Displacements now use shorter format with leading zeroes trimmed: (e.g. SomeRoutine+000E -> SomeRoutine+E).

TODO

[ ] Test 24-bit offsets more thoroughly (esp. memory locations);
[x] An option to revert to 32-bit offsets;
[ ] Test an option to revert to 32-bit offsets;
[ ] Test Windows Makefile.

This PR was merged before testing was fully completed, however, it's not necessary since a major structure overhaul is coming, which requires a lot of re-testing either way.


testing: deadlock repro test

Do I see this correctly that your AlephBFT patch fixed the issue?

yes

fixed by #4116


fix: Explicitly provide the host-triple of the version to install

Rustup has a default-host-triple setting, that may different than the actual host environment. Proto currently don't support these two being different, andit would previously fail to find the executables for the version it had just installed.
While a better solution may to respect Rustup's default-host-triple and support manually specifying the host-triple, this patch at least leaves you with a working installation.
Ran into this because I apparently never ran rustup-init to configure the setting, after installing it on my M1 macbook via Homebrew, so it currently installs x86_64-apple-darwin but Proto looks for aarch64-apple-darwin.
Error log

proto install rust-test 1.76
info: syncing channel updates for '1.76.0-x86_64-apple-darwin'
info: latest update on 2024-02-08, rust version 1.76.0 (07dca489a 2024-02-04)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
info: downloading component 'rust-std'
info: downloading component 'rustc'
 55.1 MiB /  55.1 MiB (100 %)  30.5 MiB/s in  1s ETA:  0s
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-docs'
 14.7 MiB /  14.7 MiB (100 %)   5.4 MiB/s in  1s ETA:  0s
info: installing component 'rust-std'
 25.3 MiB /  25.3 MiB (100 %)  19.1 MiB/s in  1s ETA:  0s
info: installing component 'rustc'
 55.1 MiB /  55.1 MiB (100 %)  21.3 MiB/s in  2s ETA:  0s
info: installing component 'rustfmt'
1.76.0-x86_64-apple-darwin installed - (timeout reading rustc version)
info: checking for self-update
Error: proto::execute::missing_file
× Unable to find an executable for Rust, expected file ~/.rustup/toolchains/1.76.0-aarch64-apple-darwin/bin/cargo does not exist.

@Phault The change makes sense. I think we should update like 177 also.

@milesj Good catch, I've updated that line as well now.

Thanks! It may be a while before it lands in proto, so if you need it now, you can manually set the plugin in your config.


executeWatchdogAfter returns NaN

executeWatchdogAfter returns NaN causing the execution to not wait for the checkingInterval
processDescription.pm2_env.min_uptime can be 'undefined' wich causes the minUptime - processUptime to become NaN and thus it seems this value is used with Math.max

@ma-zal

Hi @taniman.
Thank you, very much, for you fix!
I would like to apologise for not responding for a long time. I did not received any notification from GitHub. :(


[PL] Translation of OTP Supervisors

In scope of issue #202.
@kdebowski :)

You may use automatic TOC generation as was described here.


comments of different indent levels alligned equally

Hi, I like comment closing brackets of conditions with condition to easily see what a indent level implies, sorta like this

pub fn main() {
    let x = 5;

    if x == 3 {
        x = 4;

        /*
        a
        lot
        of
        code
        ...
        */
    } // if x == 3
    // end of block
}

If I put another comment right after the end of the basic block/curly bracket, rustfmt will align the two comments equally altough the comments refer to different scopes:
    } // if x == 3
      // end of block

is there a way to disable comment alignment for this case?
edit: rustfmt 0.4.1- ( )

Closed by #3833.


Foreign language WINE applications break with oh-my-zsh active

Hello,
The high level issue I'm having is that I regularly run several Windows applications from the command line using WINE, and some of these programs do not work anymore after installing oh-my-zsh.
I am using Arch Linux. I used the oh-my-zsh installation script from this repo. I confirmed this behavior with no oh-my-zsh plugins or themes active.
I restored my old .zshrc to test, and I confirmed that the applications do run in vanilla zsh, but do not run in oh-my-zsh with no other changes.
One thing all the broken applications have in common is that they are expected to only work when run in a Japanese locale. I usually do this with a terminal command of the form LANG=ja_JP.UTF-8 wine ...
Is there an expected change of behavior when using the LANG variable in oh-my-zsh compared to vanilla zsh?
I am not positive that the problem is related to the foreign language, but it is my best guess at the moment.
These WINE applications are an important part of my workflow, so I would greatly appreciate any help you can give in overcoming this issue. I am happy to do anything I can on my end to provide more information.

If you think this is related to locale post the output of locale both with OMZ and without it. It would be helpful as well to know what you mean specifically by "broken applications" and "do not work anymore".

Thank you for your reply.
vanilla zsh:
$ locale

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ LANG=ja_JP.UTF-8 locale

LANG=ja_JP.UTF-8
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=

with oh-my-zsh:
$ LANG=ja_JP.UTF-8 locale
LANG=ja_JP.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=

Please note that LC_CTYPE is not updated by the LANG variable, which I believe is a problematic bug.
I can now use a shell command of the form LANG=ja_JP.UTF-8 LC_CTYPE=ja_JP.UTF-8 wine ..., and my WINE applications work again.
FYI a "broken" WINE application in this case simply crashes on startup.
Thank you for pushing me to look at the locale output. I now have a usable workaround, but I hope you consider treating this behavior of LC_CTYPE as a bug, because I believe it will cause issues in many cases where the LANG variable is used.

It's possible that this happens because of these lines https://github.com/robbyrussell/oh-my-zsh/blob/7b2c4327e7d40ec17b72fe7fce3031dfc92fb165/lib/misc.zsh#L34-L37
but I don't see why given that LC_CTYPE isn't empty before sourcing OMZ, which is one of the conditions.

Please note that LC_CTYPE is not updated by the LANG variable, which I believe is a problematic bug.

This is by design. If you want to override LC_CTYPE you can use LC_ALL instead of LANG, which sets all LC_* locale env variables.

but I don't see why given that LC_CTYPE isn't empty before sourcing OMZ, which is one of the conditions.

I do not intentionally set LC_CTYPE, but it appears to have been explicitly defined nonetheless.
➜  ~ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
➜  ~ unset LANG
➜  ~ locale
LANG=
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Once again, I disable oh-my-zsh:
mv .zshrc .zshrc.oh-my-zsh
mv .zshrc.pre-oh-my-zsh .zshrc

Opening a new terminal window shows that LC_CTYPE is not explicitly set.
% locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
% unset LANG
% locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

My conclusion is that something related to oh-my-zsh sets LC_CTYPE explicitly. This behavior is present with no plugins and the default theme. Of course, I've only tested on my computer, so I am curious if this is reproducible.

This is by design. If you want to override LC_CTYPE you can use LC_ALL instead of LANG, which sets all LC_* locale env variables.

I accept that this is the correct behavior for when LC_CTYPE is explicitly defined. I am still not sure why LC_TYPE is explicitly defined with oh-my-zsh.

Can you check if commenting out the lines in https://github.com/robbyrussell/oh-my-zsh/issues/7942#issuecomment-506684475 the problem disappears?

Yes, with those lines commented, the problem disappears.
➜  ~ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
➜  ~ unset LANG
➜  ~ locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=


Iteration Plan for December 2019

December 2019 Plan
Auth

[ ] ~Support bringing your own identity management provider (Firebase Authentication and Auth0) with App Center Auth [#637]~
[ ] ~Enable developers to connect their Active Azure Directory to Auth [#994]~

Data

[ ] ~Continue Free Tier investigatory work [#799]~
[ ] ~Traffic Map in Metrics Explorer [#660]~
[ ] ~Engineering Design Work on Data Change Notifications [#1121]~

Diagnostics

[x] Show unsymbolicated crashes and include in total counts [#110, #939 ]
[x] Manually upload crash logs in the UI [#289, #1317]
[x] Support deobfuscation for DexGuard [#220]

Distribution

[ ] ~Updated tester experience [#986, #140, #369, #1176]~

General

[x] Research for compute backend-as-a-service from App Center [#993]
[x] Support Azure Active Directory security groups in App Center shared distribution groups

https://github.com/microsoft/appcenter/issues still refers to December, which is still open.


add different patch type support

Description
Currently the create-patch command only support json merge patch, while our ks can accept both json patch and json merge patch. This PR adds the support specify which patch to be used, and if no method specified, the app will interpret from the provide file content
Type of Change

[ ] Bug Fix
[x] New Feature
[ ] Breaking Change
[ ] Refactor
[ ] Documentation
[ ] Other (please describe)

Checklist

[x] I have read the contributing guidelines
[ ] Existing issues have been referenced (where applicable)
[x] I have verified this change is not present in other open pull requests
[x] Functionality is documented
[x] All code style checks pass
[ ] New code contribution is covered by automated tests
[x] All new and existing tests pass

Codecov Report

Merging #75 (8ade830) into main (90f15d3) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main      #75   +/-   ##
=======================================
  Coverage   32.63%   32.63%
=======================================
  Files          27       27
  Lines        3536     3536
=======================================
  Hits         1154     1154
  Misses       2292     2292
  Partials       90       90

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Looks good to me, my only question is: have we tested this out on c0?

yes, i have tested it on c0


Info page - Content restructuring

We could restructure the info page https://test-dhcr.clarin-dariah.eu/info in order to simplify the menu and make the content user-friendlier.
About
Purpose and Audience

[x] I would replace the title with How to Use DHCR
[ ] The content needs slight improvement.

** #19 **

[ ] If we add contact cards of all the moderators, the section will be very long (just an observation).
[ ] The text needs improvement: The DHCR maintains a system of national moderators, who review newly entered courses, help with registration issues and are encouraged to disseminate the DHCR initiative among institutions of their countries. For not moderated countries, please contact the administrators (listed below). -> The course entries in the DH registry are moderated by a group of national moderators whose details you can find below. The role of the national moderators is to provide assistance with any registration issues and review newly submitted courses. In case there is no national moderator available in your country, please contact the administrators (add link to the Contact page).

Contact: Admin & Bug Report

[x] I suggested keeping this simple Contact or Contact Us. Note that under Purpose and Audience, we have a Contact Us button. We should be consistent everywhere.

Dissemination and Impact

[ ] Some of the text concerning the dissemination material needs improvement.
[ ] I suggest we move the selected presentations and publications to a Zotero library and just insert the link here. This way, we make the content user-friendlier and we can also keep adding new publications to the Zotero library.

Data and API

[x] Title not consistent with Data Export and API (Sitemap)

CLARIN and DARIAH

[ ] The content and the logos on https://test-dhcr.clarin-dariah.eu/info#clarin-dariah can be moved up under the introduction text. Then you can remove the CLARIN  and DARIAH drop-down button.

Social Media

[ ] Change Social Media into Follow Us to make this consistent with the title in the Sitemap menu. You can then remove Follow the DH Course Registry text.

FAQ

[x] We should add a bit more text here: Please check our Frequently Asked Questions page to find answers to specific questions regarding the use of the platform.
[ ] We should list the FAQ questions in alphabetical order so that the users can quickly find what they need.

Credits
ok
Imprint

[x] - [ ] Display this only at the bottom of the page, not needed in the menu, in my opinion.

Release Notes

[x] Add text: If you are curious about the latest technical developments and enhancements, check our release notes on Github.

Version

[x] You could move the Version number to the Release Notes section to simplify the menu.

@IvdL22:
Thanks for all the suggestions as well as the comments here: https://github.com/acdh-oeaw/dhcr-main/issues/19#issuecomment-1329450891
I've added it to the agenda for our next meeting, so we can find a way how to deal with so many points.

@PixlTracer  @IvdL22 : Today in the JFX we decided to postpone this issue until jan-23, so we can focus now on releasing the work which is (almost) finished.

Can and should the contact form be permanently removed?

@patrickakk Which contact form do you refer to? As agreed, in Contact us, our email addresses should be removed and replaced with the general helpdesk address.

@IvdL22  The contact form which was there until nov-22 and is now hidden.

I recommend to talk about this in a meeting.

dear Patrick,
thank you for all the suggestions

I am fine with everything but the zotero library; we can discuss this in the meeting.

@IvdL22  @PixlTracer
Can you review this?
I've checked the boxes above for requests which are implemented.
You can find the result here:
https://dev-dhcr.clarin-dariah.eu/info
and in the menu.

The text needs improvement: The DHCR maintains a system of national moderators, who review newly entered courses, help with registration issues and are encouraged to disseminate the DHCR initiative among institutions of their countries. For not moderated countries, please contact the administrators (listed below). -> The course entries in the DH registry are moderated by a group of national moderators whose details you can find below. The role of the national moderators is to provide assistance with any registration issues and review newly submitted courses. In case there is no national moderator available in your country, please contact the administrators (add link to the Contact page).

I couldn't find the text. Maybe it moved here: https://dev-dhcr.clarin-dariah.eu/national-moderators
or here:
https://dev-dhcr.clarin-dariah.eu/info#contact
Which parts should be replaced?

The content and the logos on https://test-dhcr.clarin-dariah.eu/info#clarin-dariah can be moved up under the introduction text. Then you can remove the CLARIN and DARIAH drop-down button.

I would recommend to keep them there. Moving them to the top will fill the whole screen with text and images and makes all the menu options/accordions invisible.

Change Social Media into Follow Us to make this consistent with the title in the Sitemap menu. You can then remove Follow the DH Course Registry text.

The "Social Media" item at the info page is redundant and contains the exact same data as https://dev-dhcr.clarin-dariah.eu/follow#social-media

[ ] We could also remove it completely, since there is already "Follow Us" as main menu item. Would that be ok?

The "Follow Us" contains 3 components: Course alert, Social Media and Contributor Mailing list. So changing the text from social media to follow us, would exclude the two other components. Can you specify the preferred change?

We should list the FAQ questions in alphabetical order so that the users can quickly find what they need.

You can change the order of the questions yourself at: Dashboard / Category Lists / FAQ Questions, then choose a category and move questions up and down.
The current implementation allows you, as administrator, to create every order you want. Even move more important questions to the top?
Would that help?

Display this(imprint) only at the bottom of the page, not needed in the menu, in my opinion.

I've removed it from the menu. For technical reasons it might be easier to keep it in the accordion menu. If you still want it to disappear there, I should spend some more time on it and move it to a separate page.
Please let me know what you think of all this and if additional changes are needed.

Btw the menu and accordeons at the info page are also inconsistent: "National Moderators" appears in the menu, but at the Info page we've merged it under "Contact Us". What should be do about that?

simply keep 'contact us' ---> the user can find out more then via the National Moderators page, which is linked there

@PixlTracer Done. The entry "National Moderators" has been removed from the menu.
@PixlTracer @IvdL22
Could you answer the questions above? See https://github.com/acdh-oeaw/dhcr-main/issues/23#issuecomment-1618262560
Can you review this issue, maybe that a look at (your own) suggestions above, and specify if additional changes are needed? Or can the label be changed to done?

I've checked everything and to me it looks fine; if Iulianna agrees, we can set the label to done

Fine with me as all @PixlTracer and @patrickakk !Thank you for the changes, Patrick.

Implemented in 2023-08.


Some secrets simply crash with 'Incorrect padding'

All secrets generated by fastmail see to make the library crash. I can't find any common pattern for them:
>>> import onetimepass
>>> onetimepass.get_totp('7uzthj2u3te6dopflwqbwa5n6u', as_string=True, token_length=6)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/site-packages/onetimepass/__init__.py", line 169, in get_totp
    token_length=token_length,
  File "/usr/lib/python3.6/site-packages/onetimepass/__init__.py", line 113, in get_hotp
    key = base64.b32decode(secret, casefold=casefold)
  File "/usr/lib/python3.6/base64.py", line 205, in b32decode
    raise binascii.Error('Incorrect padding')
binascii.Error: Incorrect padding

The one included in the above example is safe to share since I never added confirmed adding that one to my account. :)

On, this is onetimepass v1.0.1, python 3.6.1.

Base32 takes 8 output bytes to encode each 5 input bytes. 1-4 input bytes still require 8 output bytes, appending = characters as padding.
In other words, otp asserts that len(secret) % 8 == 0. Appending ====== to your example makes it correct.
Solution: otp should provide an option to autopad secrets. (Or just to it by default.)

Sure, this could be done to make it more user friendly.

Solution: otp should provide an option to autopad secrets. (Or just to it by default.)

Do you think this solution is enough / correct: https://stackoverflow.com/a/9807138/548696?

Looks good. (The condition is unnecessary though.) Tests should be easy to write too.


Don't open Tabnine welcome when extension is installed via settings sync

Currently, it Tabnine, seems to open a welcome url in the browser when installed. While this is fine for the initial install, it is not desirable when the extension is sync'd to other machines (especially Codespaces).
The extension could store some synchronized state (using the vscode apis), to ensure that the welcome experience is only shown once per "user".

Thank you for your feedback,
We currently open the welcome page when there is no tabnine_config.json file exists (in the user preferences directory).
It is the first complaint we heard about this matter, so we are not going to address it for the time being.
If it's urgent for you, you are welcome to open a PR that fixes this behavior.

@talcodota While I can certainly understand that -- I would just recommend looking into this sooner than later. Given more and more users are using VS Code with containers, remote boxes, and Codespaces, this issue with IMO quickly become a blocker for them. It caused me to disable the extension while I was working in Codespaces for a few days because every time I opened a new one, I got taken out of the Codespace browser tab to a new Tabnine Welcome tab (which is very disruptive).
While I'm largely asking about this for me (and your users), we on the VS Code team are also trying to encourage extensions to adopt the new sync mechanisms to improve the welcome experiences that extensions show to their users -- to keep them as a desired experience rather than undesired.
You can see an example of this in my GitLens extension:
https://github.com/eamodio/vscode-gitlens/blob/e27da912e1adaa2617a209c81872079b60417879/src/extension.ts#L191-L198
There I setup some data storage keys to be synchronized, so that I can read them (in the standard way) on the other machines and avoid the welcome and other experiences.
Thanks for your consideration.

I think it is a good idea to add this feature, I agree with @eamodio, the number of developers using VS Code with containers is increasing day by day.
In the meantime, and while TabNine doesn't solve this problem, you can add this to your .devcontainer/devcontainer.json file.
It is more like a monkey patch, but it is better than nothing.
"postCreateCommand": "mkdir -p $HOME/.config/TabNine && touch $HOME/.config/TabNine/tabnine_config.json"

I came across the same issue but i didn't just want to create an empty file. I also wanted to have my model linked into my containers.
I had to do some tricks with mounting the directories and creating symlinks so that other stuff did not break.
Here are the relevant parts of my devcontainer.json
{
	"name": "xxx",
	"extensions": [
		"TabNine.tabnine-vscode"
	],
	// mounts for using TabNine in Devcointainer
	"mounts": [
		"source=${localEnv:HOME}/.config/TabNine/,target=/home/vscode/tabnineConfig/,type=bind,consistency=cached",
		"source=${localEnv:HOME}/.local/share/TabNine/,target=/home/vscode/tabnineApp/,type=bind,consistency=cached"
	],
	"onCreateCommand": "mkdir -p /home/vscode/.config/TabNine && mkdir -p /home/vscode/.local/share/TabNine",
	"postCreateCommand": "ln -s /home/vscode/tabnineConfig/* /home/vscode/.config/TabNine/ && ln -s /home/vscode/tabnineApp/* /home/vscode/.local/share/TabNine/",
	"remoteUser": "vscode"
}

This gives me the same experience like working locally and it does not open the welcome page.


DashCase and CamelCase intrinsic string types, or similar

Search Terms
dashcase snakecase
Suggestion
It would be great to also have DashCase and CamelCase and similar!
Use Cases
It is common in DOM libs to map from JS camelCase properties to DOM dash-case attributes (f.e. el.fooBar = 123 and <el foo-bar="123">), or CapitalizedClass names to dash-case custom element names (f.e. class FooBar extends HTMLElement and <foo-bar>).
Examples
type T1 = Dashcase<'fooBar' | 'BarBaz'> // 'foo-bar' | 'bar-baz'
type T2 = Camelcase<'foo-bar' | 'bar-baz'> // 'fooBar' | 'barBaz'

Or similar.
Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

Something that’s important to clarify in this suggestion is whether it’s important that these types be intrinsic or if you just want some solution built into lib.d.ts. Various comments in #40336 demonstrate that these transformations are already possible, but are complex to write. If they were written into lib.d.ts, but were not intrinsics, would that be a good solution, or would there be performance / depth limit issues?

Type Camelcase could take an optional initialism list a la github.com/golang/lint but overall I think this will be a useful standard lib intrinsic.
If there's no consensus on a standard I don't know how typescript plans to regulate custom intrinsic implementations... would they be fishable like node_modules/@types? It would probably never end up in the standard lib but a jsonschema validator would be a favorite of mine.

I don't know how typescript plans to regulate custom intrinsic implementations

We don’t plan to allow custom intrinsic implementations.

@andrewbranch why not? Wouldn't e.g. a graphql schema parser be unoptimized written as a type have concerns about recursion depth? Right now graphql-codegen works but at the very least a non-async pure function seems stable enough.
function mockingly<S extends string>(s: S): intrinsic {
  return s.split('').map((c, i) => c[i % 2 ? 'toUpperCase' : 'toLowerCase']().join(' ')
}

Expect<typeof mockingly("hello world"), "H e L l O   W o R l D">

Wouldn't e.g. a graphql schema parser be unoptimized written as a type and have concerns about recursion depth?

Yes, absolutely. We would not recommend you do that either! 😄

Right now graphql-codegen works

Great, problem solved! Preprocessing is our recommendation for this kind of problem in general. We’re not interested in performing arbitrary code execution during compile time. (At any rate, this discussion is off-topic for this issue, which is asking us to add new instrinsics ourselves.)

Personally standard lib or intrinsic is fine for me as someone who will simply use it. I'll leave it to the TS experts what's better. From my point of view as an end user, lib.d.ts and actual intrinsics are all "intrinsic" in the end-user sense: built-in types that I get to use.

I instead toyed with the idea of a general Split<K, "-">with which one could implement a CamelCase or DashCase oneself: https://github.com/sindresorhus/meow/issues/155#issuecomment-718639981
Enabling something like:
type CamelCase<K extends string> = `${Split<K, "-">[0]}${Capitalize<Split<K, "-"|"_"|" ">[1] | "">}

type CamelCasedProps<T> = {
    [K in keyof T as CamelCase<K>]: () => T[K]
};

interface KebabCased {
    "foo-bar": string;
    foo: number;
}

type CamelCased = CamelCasedProps<KebabCased>;

I think Split<> has to be intrinsic, but I don't think either of CamelCase or KebabCase (isn't that the more common name for DashCase?) has to be intrinsic.

Actually, scratch that, as shown in the top description of https://github.com/microsoft/TypeScript/pull/40336, a Split<> doesn't have to be intrinsic at all but is actually possible right now in the current nightly and with that comes the creation of eg. CamelCase<>.
Trick is to use infer within the template string literal, like:
S extends `${infer T}-${infer U}` ? [T, D] : S

I made a test on the playground which I'm pasting here:
type Split<S extends string, D extends string> =
    string extends S ? string[] :
    S extends '' ? [] :
    S extends `${infer T}${D}${infer U}` ? [T, ...Split<U, D>] :
    [S];

type SplitOnWordSeparator<T extends string> = Split<T, "-"|"_"|" ">;
type UndefinedToEmptyString<T extends string> = T extends undefined ? "" : T;
type CamelCaseStringArray<K extends string[]> = `${K[0]}${Capitalize<UndefinedToEmptyString<K[1]>>}`;
type CamelCase<K> = K extends string ? CamelCaseStringArray<SplitOnWordSeparator<K>> : K;
type foo3 = CamelCase<"foo-bar">; // Becomes "fooBar"
type foo5 = CamelCase<"foo bar">; // Becomes "fooBar"
type foo6 = CamelCase<"foo_bar">; // Becomes "fooBar"
type foo4 = CamelCase<"foobar">; // Becomes "foobar"

type CamelCasedProps<T> = {
    [K in keyof T as CamelCase<K>]: T[K]
};

interface KebabCased {
    "foo-bar": string;
    foo: number;
}

// Becomes
// {
//    fooBar: string;
//    foo: number;
// }
type CamelCased = CamelCasedProps<KebabCased>;

Sorry for spamming, but just wanted to add an implementation of DashCase/ KebabCase as well. See this updated playground.
It's a bit more awkward as it eg. as to split on all A-Z uppercase chars as well:
type UpperCaseChars = 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 'T' | 'U' | 'V' | 'X' | 'Y' | 'Z';

@voxpelli great work! The only thing I would point out is that the implementation in your latest linked playground cannot properly handle strings which start with a separator or have multiple separators side by side. Example:
interface KebabCased {
    "-webkit-animation": string;
    "--main-bg-color": string;
    "something--else": string;
}

// Becomes
// {
//    Webkit: string;
//    '': number;
//    something: string;
// }
type CamelCased = CamelCasedProps<KebabCased>;

See this updated playground.
I was working on my own CamelCase utility type as well. It handles those cases, but it's far less generic than what you've come up with.
type Separator = ' ' | '-' | '_';

type CamelCase<T extends string> =
  T extends `${Separator}${infer Suffix}`
  ? CamelCase<Suffix>
  : T extends `${infer Prefix}${Separator}`
  ? CamelCase<Prefix>
  : T extends `${infer Prefix}${Separator}${infer Suffix}`
  ? CamelCase<`${Prefix}${Capitalize<Suffix>}`>
  : T;

type CamelCasedProps<T> = { [K in keyof T as `${CamelCase<string & K>}`]: T[K] }

type SnakeObject = {
  '-webkit-animation': string;
  '--main-bg-color': string;
  'something--else': string;
}

// Becomes
// {
//    webkitAnimation: string;
//    mainBgColor: number;
//    somethingElse: string;
// }
type CamelObject = CamelCasedProps<SnakeObject>;

See this playground.

@knpwrs your solution kills the playground tab in my browser (and the TS language service in my VSC 😅 ) when I use the following keys:
'Awa_bbb-ccc' |  '-Awa_bbb-ccc' | '_Awa_bbb-ccc'

I came up with my own implementation and it seems to be working better for strings up to 15 characters long. Unfortunately anything longer than that triggers the
Type instantiation is excessively deep and possibly infinite.ts(2589)

error 😞 (but doesn't kill the IDE 😅 )

@voxpelli Your solution has been working super great, but today I ran into a weird one. Based on your code, I tried this:
type DashCasedProps<T> = {
    [K in keyof T as KebabCase<K>]: T[K]
};

type test = DashCasedProps<{dracoDecorderPath: number}>

And the resulting test type is
type test = {
    dracoDecorderPath: number;
    dracoDecorderDecorderPath: number;
    "draco-dath": number;
    "draco-path": number;
    "dracoDecorder-dath": number;
    "dracoDecorder-path": number;
    dracoDecorderPecorderath: number;
    "draco-decorderath": number;
    "draco-pecorderath": number;
    dracoDecorderDecorderPecorderath: number;
    "dracoDecorder-decorderath": number;
    "dracoDecorder-pecorderath": number;
}

playground link (see at the bottom)
Anyone know why that happens with that particular example?

@knpwrs Expanding on your example, what would the opposite SnakeCasedProps type look like?

@trusktr Is the same issue happening with the version of it that we're maintaining in https://github.com/sindresorhus/type-fest ?

@voxpelli thx for the good work. Your implementation works only If word has only two segments. I upgraded it to work with an endless number of segments
type Split<S extends string, D extends string> =
    string extends S ? string[] :
        S extends '' ? [] :
            S extends `${infer T}${D}${infer U}` ? [T, ...Split<U, D>] :
                [S];

type SplitOnWordSeparator<T extends string> = Split<T, "-"|"_"|" ">;
type UndefinedToEmptyString<T> = T extends undefined ? "" : T;
type CapitalizeStringsInTuple<T extends any[]> =
    T extends [infer First, ...infer Rest] ?
        [First, ...(Rest extends string[] ? CapitalizeStringsInTuple<Rest> : [])] :
        [];

// Converts an array of strings to a camelCase string
type JoinStringsAsCamelCase<T extends any[], Prev extends string = ''> =
    T extends [infer First, ...infer Rest] ?
        Rest extends string[] ?
            JoinStringsAsCamelCase<Rest, `${Prev}${First extends string ? Capitalize<First> : ''}`> :
            `${Prev}${First}` :
        Prev;

type CamelCase<K> = K extends string ? JoinStringsAsCamelCase<SplitOnWordSeparator<K>> : K;

@michalica 👍 You can find the latest iteration of mine in the type-fest module, and PR:s are welcome there 😊


Print user-friendly error message mapped from error code on eosio_assert_code assertion failure

This is the continuation of the remaining work left over from issue #2561 that PR #3190 did not complete.
The eosio_assert_code intrinsic can be used to provide an error code rather than a message string on assertion checks. If the assertion fails, the provided error code will be made available through the exception message. However, it is more user-friendly if the software (we have to figure out if this would be done in nodeos or cleos) automatically looks up the error code in the ABI of the contract and provides the user-friendly error message provided in the ABI.

I recently asked a question on stackexchange. Is this the answer to it?


[stable/nats] Configure number of connect retries for implicit routes

Signed-off-by: devKlausS<EMAIL_ADDRESS>Is this a new chart
NO
What this PR does / why we need it:
added possibility to configure number of connect retries for implicit routes. see pull request of nats server https://github.com/nats-io/nats-server/pull/409
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

@bitnami-bot

🤦♂ #20651 was merged by the CI/CD some minutes ago, it seems you need to rebase from master before merge this one

/ok-to-test

🤦♂ #20651 was merged by the CI/CD some minutes ago, it seems you need to rebase from master before merge this one

done

/lgtm


Compile a sysimage for faster startup

Using PackageCompiler.jl, a sysimage containing all the code could be created so that the LSP starts faster.

Try julia.CompileLanguageServer, this will compile LanguageServer.jl to ~/.config/coc/extensions/coc-julia-data/JuliaLS.
In my tests, compiled LS can be started in 2 seconds!

Thanks, that's great!
However, when I checkout master and run the command, I get this...
$ > cd /home/user/.config/coc/extensions/node_modules/coc-julia/server && sh ./compile.sh /
home/user/.config/coc/extensions/coc-julia-data/JuliaLS
-e Compiling...
 Activating environment at `~/.config/coc/extensions/node_modules/coc-julia/server/JuliaLS/Project.toml`
   Updating registry at `~/.julia/registries/General`
   Updating git-repo `https://github.com/JuliaRegistries/General.git`
  Resolving package versions...
ERROR: expected the file `src/JuliaLS.jl` to exist for package `JuliaLS` at `/home/user/.config/coc/extensions/node_modules/coc-julia/server/JuliaLS`
Stacktrace:
 [1] pkgerror(::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Types.jl:52
 [2] read_package(::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Types.jl:418
 [3] collect_project!(::Pkg.Types.Context, ::Pkg.Types.PackageSpec, ::String, ::Dict{Base.UUID,Array{Pkg.Types.PackageSpec,1}}) at /buildworker/worker/package_linu
x64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Operations.jl:243
 [4] collect_fixed!(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}, ::Dict{Base.UUID,String}) at /buildworker/worker/package_linux64/build/usr/share/julia/s
tdlib/v1.5/Pkg/src/Operations.jl:293
 [5] resolve_versions!(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Oper
ations.jl:349
 [6] targeted_resolve at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Operations.jl:1114 [inlined]
 [7] tiered_resolve(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Operati
ons.jl:1086
 [8] _resolve at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Operations.jl:1120 [inlined]
 [9] add(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}, ::Array{Base.UUID,1}; preserve::Pkg.Types.PreserveLevel, platform::Pkg.BinaryPlatforms.Linux) at /b
uildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/Operations.jl:1135
 [10] add(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}; preserve::Pkg.Types.PreserveLevel, platform::Pkg.BinaryPlatforms.Linux, kwargs::Base.Iterators.Pai
rs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/API.jl:188
 [11] add(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/API.jl:139
 [12] #add#21 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/API.jl:67 [inlined]
 [13] add at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/API.jl:67 [inlined]
 [14] #add#20 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/API.jl:66 [inlined]
 [15] add(::Array{String,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Pkg/src/API.jl:66
 [16] top-level scope at none:3
-e Compiled

Reproduced.

npm publish ignored some jl source files, I'll publish a new release ASAP.

Try v0.5.1

Hi, thanks for the quick response, v0.5.1 works just fine :)
Not only is the startup much faster (I jump around files quite a lot, so the slow start was really noticeable...), it seems to me to be overall snappier...
:tada: :tada: :tada:


Video Generation Model

Hi
Thanks for sharing this awesome work.
Are there plans to release the video generation model?
Best

Thanks for your interests in our work. We do have plans to release the video generation model and code, but the exact timeline is yet to be determined. Please stay tuned for updates.


Enable docker to choose a different graphdriver for volume

The volume driver other than VFS would create internal directory under /var/docker/volumes, rather than /var/docker, to avoid conflict with graphdriver for images
This patch has been tested briefly using device mapper graphdriver. There is no migration path from other volume drivers(vfs) yet.
I don't think one volume driver per docker daemon is prefect, but that's what we have currently in docker, so this patch would live with for now. I think it's good for each volume should able to have an separate driver in some way, which would provide us much bigger flexibility on deployment.
Some related discussion happened on https://github.com/docker/docker/pull/8484#issuecomment-78374504

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "volumedriver" git@github.com:yasker/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

This will update the existing PR, so you do not need to open a new one.

NOTLGTM The basic gist of this can be done today with binds and what we really want is to be able to have a mix of volumes, I'd rather not introduce this stop-gap.

At least this patch would enable the people to try and explore the usage of graphdriver during the transition time. I understand we would have per volume driver later, but in the meantime, I think enabled the possibility to use other graphdriver is a good thing, and would encourage people to involve more into the discussion that how volume driver should looks like in the future once they found graphdriver like device mapper is workable with volume.
And I am not sure how long it would take to introduce the volume driver. I think probably we can give this a try for now.

Actually the use of VFS here is only because it does not use a CoW filesystem and it's just used for directory management.  You actually don't want to use a CoW filesystem for storing volumes because of performance for reads and writes.  It will be slower and you don't want your database sitting on top of a CoW filesystem.
Also using a CoW like devicemapper or btrfs kinda creates a box for your data which is hard to get out and inspect.  I would not feel comfortable promoting the use of CoW for volume(persistent data that I care about).

@crosbymichael
What's wrong with using COW based volumes? I don't understand it. We are ready to use container roots and images as COW based but not volumes. That's strange. I think it is up to the user to decide what volume can be. If user wants a volume to be backed by a COW based mechanism, that's perfectly fine. It should not be docker limiting that choice.
Reads of COW based thing should not be a problem as we are reading existing. Copy. Only initial write will initiate a copy and might be slow. But again, it is up to the use case of user to decide whether they want to play that initial penalty or not. Otherwise they can create volume in a different way.
Also why it is hard to to get out and inspect data on COW based systems?
I think this conclusion that cow based volumes are bad, needs to be justified. COW based devices/files are enterprise class features to store data. And for some reason these enterprise class features are not suitable for docker volumes, that's little strange.

Using volume for database is just one example. I am looking into a use case where I just want to be able to mount image/container root into another container and do the inspection. This primarily requires reading and COW based backend is great for this purpose. Create a quick snapshot of image/container root and mount it in a different container.
Given that we already have the notion of volumes, I think it makes sense to take snapshots of images or containers which show up as volume and now these volumes can be mounted inside other containers.
And for this use case, cow based volumes are perfect. So we should not limit this choice at docker level. It is up to the user based on use case whether they want a cow based volume or not.

@yasker
If I am using devicemapper as storage driver and I want to use same for volume driver, how do I do that with your patch. Basically I want to use same pool to have images, container roots and volumes.

@cpuguy83
If one wants to have volumes in same pool as images and container root (so that one can easily take snapshots), then bind mount solution will not work.
Supporting multiple volume drivers is just fine. But that should not exclude the case of being able to use storage driver as volume driver.
I am sort of little surprised that why did not we start from that. We already had the capability to create
images and containers from graphdriver and creating volumes also is such a natural extension to that logic. And option to use VFS as volume driver could be specified using command line option.
But we instead did it other way where we assumed that user would never want to use overlay, aufs, btrfs or devicemapper as volume driver. So let us hardcode it to VFS.

@rhvgoyal
Currently this patch separate the pool used by image and volume, because I encountered some errors when try to use the same pool. I guess it because I was using a new DeviceSet but with the same underlaying pool. Change base directory for volume solve the issue, but I can give it try in another way as well, say using the same driver instance for volume.
If I got some time next week, I probably can make a patch using the same pool for image and volume.

@yasker
I don't think you can create another instance of same graphdriver to manage same pool. And that explains the reason that you could not use same pool.
And that's why I think that default volumedriver option should have been user specified storage driver. And we should allowed user to override that with a volumedriver option to VFS or to something else.

@rhvgoyal I'm working on a volume driver interface, which will possibly be a subset of the graphdriver interface...but if not it can at least be wrapped. We can certainly do something like using the already instantiated graphdriver if someone requested a volume with that driver.

@cpuguy83
Nice.
So have you already put some code out somewhere which I can play with a bit and see how it is shaping up.
As long as this new interface provides me the option to create/manage volumes from existing stroage driver managing images and containers, that should help meet my needs.


Add clusters for Matter 1.2 device types

Adds new Matter 1.2 clusters for these types directly to the driver. Cluster definitions have been stripped down to just the essentials that are used in the drivers.

Added remaining clusters for Matter 1.2 device types. So far I have tested the matter-appliance and matter-sensor drivers and they both seem to be working on a hub without Matter 1.2 clusters (i.e with old lua libs). I'll test the other drivers and report the results here as well.

Updated PR that was merged here: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/pull/1390


Removes holding storages in AccountsHashVerifier for fastboot

🚧 builds on https://github.com/anza-xyz/agave/pull/118 🚧
Problem
TODO
Summary of Changes
Remove holding storages in AccountsHashVerifier for fastboot
Fixes https://github.com/solana-labs/solana/issues/35431 and https://github.com/solana-labs/solana/issues/35376

Codecov Report
Attention: Patch coverage is 63.26531% with 18 lines in your changes are missing coverage. Please review.

Project coverage is 81.8%. Comparing base (c161351) to head (c6f77de).
Report is 3 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##           master     #120     +/-   ##
=========================================
- Coverage    81.8%    81.8%   -0.1%
=========================================
  Files         838      837      -1
  Lines      225947   225660    -287
=========================================
- Hits       184971   184705    -266
+ Misses      40976    40955     -21


add "clean" script in package.json

This should be remove node_modules, ... to have the same repository you had right after clone.

This is good idea, so is think simple of implement.


Added a config files test

Hi @asamalik ,
I'm working on the CI for testing the config files (as we discussed). Here's the test file the CI workflow will be calling for running the test.

Thank you!


ISPN-6609 failedTestLogs.sh doesn't work with the new test suite listeners

https://issues.jboss.org/browse/ISPN-6609
Also fix the test name for ConcurrentStartChanelLookupTest and
ConcurrentStartForkChannelTest.

Looking...

Integrated in master. Thanks @danberindei !


feat: Allow singleton directories

I often have single projects laying around and I want to add them to the list too. Currently whaler will always search for subdirectories. This PR makes it possible to add singleton directories by prefixing the path with an =. This is a similar mechanism to the one used by other neovim project plugins and originated AFAIK on airblade/vim-rooter.

First of all, thank you for contribution!
Now, I do understand your point to have individual directories added. But I dont like the idea of using the same parameter in the configuration as they are two completely different things in my opinion.
What Im saying is I will add the feature but use another config option for single directories.
Thank you!

@SalOrak no problem at all. I also considered adding another config option for it but finally went the other way.
I'm ok with not merging, obviously, it's your repo, but it would be greatly appreciated if you did your work on top of the commits in this PR and #9 so that my contribution to the plugin doesn't get forever lost. Other than that happy to discuss implementations or any other thing really.
Best of luck

Of course! If you are willing to do yourself I would greatly appreciated, and of course, I would have added on top of this PR!
I was thinking about adding a new paramenter configuration called singleton_dirs or similar. This would be a list of directories, such as the directories that would be directly added to final directory list (in the M.dirs() or after). This way it won't interfere with the already functional directories parameter.
What do you think? How do you see it?
I'd love to know,
Thank you so much for the contribution, I'm happy you are enjoying this project ;)

Sure singleton_dirs works just fine. As I said I was on the fence about it. Having two options makes sense and it's more intuitive but I prefered the terseness of a single option and the magic =. I'm happy either way. Other options for the name:

singletons: Less descriptive by itself but enough IMO
singleton_directories: Consistent with the currently available option but longer to type
oneoffs and oneoff_directories: Same as above but shorter than singleton.

Will get it done this week.
=====
whaler strikes just the right balance for me. There are many projects similar to this but they all end up trying to be too magical with detection of root directories and autodiscovery mechanisms for projects and much more. In addittion to that it's small enough that I can easily look under the hood and figure out what is going on easily.

Now it uses the singleton_directories option although I would favour of the shorter versions. This is however a trivial renaming. @SalOrak I will go with whatever you prefer.
If this gets merged I'll rework  #9 to use the new system.

@GCBallesteros I agree, I think oneoff_directories fits much better.
Oh! Yeah sure, if you add the #9 would be great too!
Thank you. And yeees, I had the same problem with other plugins, that is why I created Whaler because nothing seemed to fit and other options were like killing a bird with a tank.
Again, thank you for the contribution I greatly appreciated.

I think that should be ready now. Next is #9 which still needs some work, specially regarding documentation.


fix: handle anti-meridian in point to bbox

Make an utils function for point to bbox conversion.

We may re-open this later, but not worth spending more time on it for the moment


Roll Flutter Engine from 1376288f5c2a to a1700b9ea2db (2 revisions)

https://github.com/flutter/engine/compare/1376288f5c2a...a1700b9ea2db
2024-09-17<EMAIL_ADDRESS>Roll Skia from be871a37a154 to ad08229fd016 (1 revision) (flutter/engine#55252)
2024-09-17<EMAIL_ADDRESS>Roll Skia from 0409718f34c6 to be871a37a154 (1 revision) (flutter/engine#55250)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC chinmaygarde@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.