Does not work with react 16

I was trying to update our app to the react 16-beta.2 and react knova is running into the following error. Any help would be appreciated.
ERROR in ./~/react-konva/src/react-konva.js
Module not found: Error: Can't resolve 'react/lib/React' in '.../react-konva/src'
ERROR in ./~/react-konva/src/react-konva.js
Module not found: Error: Can't resolve 'react-dom/lib/ReactInstanceMap' in '.../react-konva/src'
ERROR in ./~/react-konva/src/react-konva.js
Module not found: Error: Can't resolve 'react-dom/lib/ReactMultiChild' in '.../react-konva/src'
ERROR in ./~/react-konva/src/react-konva.js
Module not found: Error: Can't resolve 'react-dom/lib/ReactUpdates' in '.../react-konva/src'

got the same issue here...

I guess there is nothing much that can be done. This library is really old and the issue is coming from the way it imports react and react-dom.
var React = require('react/lib/React');

var ReactInstanceMap = require('react-dom/lib/ReactInstanceMap');
var ReactMultiChild = require('react-dom/lib/ReactMultiChild');
var ReactUpdates = require('react-dom/lib/ReactUpdates');

I will clarify current situation.
react-konva depends on some React private internals. There is no way to implement react-konva with using public API only (actually there is a way, but VERY VERY slow).
I am happy to update react-konva for support of React v16. But v16 has a lot of internal changes (new Fiber reconciler). With v16, we can't use old private API and I don't see a way to use new private API.
But I am tracking status of Fiber API here: https://github.com/facebook/react/issues/9103
As soon as I will have more info, I will update react-konva.

Hey @lavrton, just wondering if you had a chance to take a look at the recently released react v16. Thanks!

@ppong I am waiting for this issue to be resolved: https://github.com/facebook/react/pull/10758
Then we can update react-konva for react v16.

@lavrton https://github.com/facebook/react/pull/10758 has been merged. Can you update react-konva for react v16?

Give him some time, I'm sure he's looking into it when he's available to, as he already expressed that he will. I also figure he'd need some time to figure out and rewrite stuff as react-konva can't depend on no longer existing private internals. Yes, the new reconciler package has been merged. If you are eager to get react-konva have a go at it and make a PR!

Current status. "React Reconciler Package" PR is merged. But react-reconciler package is not released yet in npm (just empty v0). As soon as it will be released I will start work with it.
Stay tuned and show your love. 🙌

react-reconciler is released.
Support for v16 is almost finished. All tests are green. 😻
Now I am going to test react-konva with the real app.
Also, I am going to release beta version. So you can test as well.

Great timing!

Excellent! Now I can resume my plan to take over the world! MUAHAHAHA💥
On Fri, Nov 3, 2017 at 1:35 AM, John Lombardo<EMAIL_ADDRESS>wrote:

Great timing!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lavrton/react-konva/issues/120#issuecomment-341625675,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE-A-QzJ_KKOhKE6h8opLCDnR5xY0Njyks5syqYTgaJpZM4Os1Lx
.

Published beta version. You can try with:
npm install<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
I am going to make a master release when react v16.1.0 is out.

Awesome work! Thanks.
A small glitch, for some reason on android-chrome onClick is not working. But I am still using react 16.0.0, hope that is not the issue here.

@lavrton I just did i try on my project, and everything is working perfectly, thanks for your effort.

@lavrton add konva package in install command
npm install<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>konva

I made a release 1.6.2. It should work ok with React v16.


Room mention - Room mention is highlighted when different room is created from whisper

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.76
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team
Issue found when executing PR https://github.com/Expensify/App/issues/40857
Action Performed:

Go to staging.new.expensify.com
Go to any room
Mention a non-existing room (#hello) and send it
Edit the message in Step 3 and add another word right behind the room mention (#helloworld)
Save the edit
Click Yes on the whisper room creation message

Expected Result:
The new room mention in edit message in Step 4 will not be highlighted because the mentioned room is different from the room created from the whisper
Actual Result:
The first half of the room mention is highlighted when the room mention is different
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/72c34807-6fe8-4325-8382-78249d5c5b3d
View all open jobs on GitHub

We think that this bug might be related to #vip-vsp

This seems like an edge case so I am going to make it a medium priority bug but if we get someone to fix it, great!

I think the issue is from the backend.
When we mentionned non-created room, the Concierge Expensify will ask the user to create the room because it doesn't exist. So when we edit the comment and change the room name, and click yes (before asking us to create room) to concierge expensify, the bot doesn't change the room name from updated comment.  For example: The bot asking to create room1 but when we changed the room name to room12, the bot doesn't update the room name.  So, when we click yes, the bot will wrap the room1 text only and do not wrap the 2 last character inside mention-room tag
But for the functionlity wraping text in the mention room tag is on the backend not on the frontend

Raised it to $500.

Proposal
Please re-state the problem that we are trying to solve in this issue.
The first half of the room mention is highlighted when the room mention is different
What is the root cause of that problem?
We called an API to update a comment. I saw that the text was updated, but the last message HTML mention-report did not update yet. We then called ResolveActionableReportMentionWhisper to resolve the action report mention whisper with the report action ID, but it used the old, not updated text, causing the issue.
What changes do you think we should make in order to solve the problem?
Check the UpdateComment API to see why the text did not update
What alternative solutions did you explore? (Optional)

BE issue

I feel this issue is backend.
I'm not sure how backend is resolving the whisper message, we're receiving a new reportAction i.e whisper message with a param reportNames with the mention we've done. After we update the comment we're not receiving or updating the whisper message when we click yes for whisper message we're just sending the reportActionID for the whisper message.
I think we should update the whisper reportAction with the newly updated comment.
Maybe a new API call calling from frontend or backend directly can update the whisper report-action using the updateComment method itself.

@allgandalf hope you read the comments above, we think it's backend issue. Are you confident this can be solved from frontend that's why you're waiting for proposals or is there any other reason?!

This is on VIP VSB, which itself is paused at the moment. So let's close this issue for now and reopen down the line when we're prioritizing chat.


Re-upgrade chef-zero to latest

So just for context, do we want chef-zero to be serving up API V1? This is where supporting multiple API versions gets tough...

I think your ChefFS changes are going to break other things. If you look at chef/user.rb and chef/api_client.rb you'll notice that there is handling for both versions. I think that is something we'll have to do here too.

@tylercloke we don't support both versions yet in ChefFS or chef-zero, do we? At the moment I think it's all v0.

What are you worried will break here? I can download all the data from one of my orgs via knife, if that's the concern.

More specifically, I can successfully do this sequence from my Hosted Chef org:
$ knife download /
$ knife diff /
$ knife upload / --force

:+1:


fix(resolve): improve browser filed substitutions

Description
Fixes https://github.com/vitejs/vite/issues/2598.
Browser filed spec is unmaintained, this issue of esbuild has made a detailed explaination. I think Vite can use the same strategy as esbuild to handle browser field. This PR also refers to test case of esbuild.

Additional context

Didn't mapping all test case from esbuild. I think its test case is a bit redundant.

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

Would it work with .mjs extensions or any other user specified extensions from in ResolveOptions.extentions?
And AFAIK it could be even not a relative path but any other node-resolvable notation.

Thanks a lot for this PR @fi3ework and the detailed explanation and links! 💯
It helped a lot to understand what was the problem.

I think @ljharb is right, that ideally browser field should follow node resolution algorithm as close as possible. This would allow developers to substitute or set to ignore native modules like:
browser: {
  'util': false
}

instead of relying on contraptions like that.
Also node resolution algorithm is well known and established and I don't see good reason for deriving separate syntax from current implementations  that vary so much.

@Timsonrobl as Evan Wallace said, he was following webpack as much as possible because it is what currently most projects were using. I think we could merge this PR that already fixes several issues at this point.
And we could later have another PR to improve this further if you or someone else would like to add more test cases and review the diffs with other tools.

@fi3ework Could you merge main into your branch? (Or rebase)
That should fix your appveyor test I think

@fi3ework Could you merge main into your branch? (Or rebase)
That should fix your appveyor test I think

@Shinigami92 Done, appveyor passed. 😆


Help porting a Stylish theme to the official repo

I created a (work in progress) Sylish theme that overhauls the CSS:

Without the theme:

Assuming you're willing to accept these changes (I certainly hope so 😄 ), could I receive some help porting it to the official theme? (since I'm not familiar with the codebase)
(you can find the theme here)

I would be against adding this in a way such as a toggle. One thing we are wanting to do is be able to modify some basic CSS properties in the configuration file. In order for us to start this, we need to merge https://github.com/rtfd/sphinx_rtd_theme/pull/404

@Blendify

I would be against adding this in a way such as a toggle.

Could you clarify?

I would rather allow users to easily change major theme colors rather than distributing other sub-themes. Or if we do we can simply distribute different theme.conf files.

@Blendify Good idea- perhaps the default theme should look better, though?

There are a few tweaks that I have been merging in but overall I think it is still the cleanest Sphinx theme.

@Blendify What about making the text body full-width and making the search box square?

I think a full-width body is bad for readability and rounded vs square search box is irrelevant (=you'll find as many opinions as people...)

Being able to optionally change it is something I would like to see us support.

@Blendify, that could be nice, for pages with long lines of code or better handling of zoomed-in contents.
I don't see how this theme looks better, otherwise. Almost everything has been changed, and the contrast is jarring.

@Blendify is that option available now? I'd like to be able to change the color to match my company's standard color options without hacking my way around the code too much.

No once #404 gets merged we can add more customization options. In the meantime, this is a general todo (see the readme) so there is no need to keep this open.


Running format fix under docker fails

Title: *Running format fix under docker fails *
Description:
Running format fix under docker fails  with the following error:
Building wheels for collected packages: functools32
Running setup.py bdist_wheel for functools32 ... error
Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;file='/tmp/pip-build-jDucWG/functools32/setup.py';exec(compile(getattr(tokenize, 'open', open)(file).read().replace('\r\n', '\n'), file, 'exec'))" bdist_wheel -d /tmp/tmpeqmKS5pip-wheel- --python-tag cp27:
/usr/lib/python2.7/dist-packages/setuptools/dist.py:285: UserWarning: Normalizing '3.2.3-2' to '3.2.3.post2'
normalized_version,
usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: -c --help [cmd1 cmd2 ...]
or: -c --help-commands
or: -c cmd --help
error: invalid command 'bdist_wheel'

Failed building wheel for functools32
Running setup.py clean for functools32
Failed to build functools32
Installing collected packages: configparser, pycodestyle, functools32, mccabe, enum34, typing, entrypoints, pyflakes, flake8, yapf
Running setup.py install for functools32 ... done
Successfully installed configparser entrypoints enum34 flake8 functools32 mccabe pycodestyle pyflakes typing yapf
You are using pip version 8.1.1, however version 20.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Traceback (most recent call last):
File "/source/tools/code_format/format_python_tools.py", line 6, in
from yapf.yapflib.yapf_api import FormatFile
ImportError: No module named 'yapf'

/cc @PiotrSikora @kyessenov @jplevyak @mattklein123


^M symbol in TIME.ASM (v2.0)

https://github.com/Microsoft/MS-DOS/blob/80ab2fddfdf30f09f0a0a637654cbb3cd5c7baa6/v2.0/source/TIME.ASM#L231

https://github.com/Microsoft/MS-DOS/blob/80ab2fddfdf30f09f0a0a637654cbb3cd5c7baa6/v2.0/source/CHKDSK.ASM#L901
Same.

I see that, what is it mean?!

Ctrl+M is ASCII carriage return.  It sometimes displays like that when a file is in MS-DOS format and has a bare CR with no LF following.
Bill

We'd like to avoid making changes to source file contents to protect as much byte-accurate historical content as possible.


python310Packages.atc-ble: init at 0.1.0

Description of changes
Library for ATC devices with custom firmware
https://github.com/Bluetooth-Devices/atc-ble

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 187325 run on x86_64-linux 1

2 packages built:

python310Packages.atc-ble
python39Packages.atc-ble


cronjob timings modified for knative ppc64le jobs

Signed-off-by: Valen Mascarenhas<EMAIL_ADDRESS>
Which issue(s) this PR fixes:
Fixes
This PR modifies the cronjob timings for knative ppc64le jobs.

@cardil if everything looks good , could u please merge the PR ?


follow up to public contributor PR, fix other versions

Follow up to public contributor PR https://github.com/Kong/docs.konghq.com/pull/2642.
Minor format error also in versions 2.2 and 2.1.
Direct review links:
https://deploy-preview-2646--kongdocs.netlify.app/gateway-oss/2.2.x/pdk/kong.response/#kongresponseexitstatus-body-headers
https://deploy-preview-2646--kongdocs.netlify.app/gateway-oss/2.1.x/pdk/kong.response/#kongresponseexitstatus-body-headers

The second half of the problem is in line 499, where it starts a lua codeblock. That line should be removed - someone accidentally formatted a codeblock inside a codeblock.
Since this doc is generated from the code, can you also open a PR against the source file in kong/kong: https://github.com/Kong/kong/blob/master/kong/pdk/response.lua#L773 - this line and line 776 should be removed, otherwise the error will return in the next release.

@lena-larionova I see what you're saying:

I'll log a ticket to get it fixed in the source.

The second half of the problem is in line 499, where it starts a lua codeblock. That line should be removed - someone accidentally formatted a codeblock inside a codeblock.
Since this doc is generated from the code, can you also open a PR against the source file in kong/kong: https://github.com/Kong/kong/blob/master/kong/pdk/response.lua#L773 - this line and line 776 should be removed, otherwise the error will return in the next release.

Logged https://konghq.atlassian.net/browse/DOCS-1624


(Revised): [HacktoberFest2023]: Added Hacking C++ cheatsheets and infographics page under C++ cheatsheets

What does this PR do?
Add resource
For resources
Description

Added Hacking C++ cheatsheets and infographics page under C++ cheatsheets

Why is this valuable (or not)?

Hacking C++ website is a collection of various C++ learning resources
It's a one-shop stop for anything C++ which contains links to educational videos, conference talks, C++ learning materials and C++ books
Special highlight in Hacking C++ are their C++ cheatsheets and infographics which serve as quick reference for  beginners & professional C++ programmers

How do we know it's really free?

Visit Hacking C++ cheatsheets webpage

For book lists, is it a book? For course lists, is it a course? etc.
Checklist:

[X] Read our contributing guidelines.
[X] Search for duplicates.
[X] Include author(s) and platform where appropriate.
[X] Put lists in alphabetical order, correct spacing.
[X] Add needed indications (PDF, access notes, under construction).
[X] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

Thanks, and welcome to free-programming-books!


adds the ability to access fragments

Is this pull request associated with an issue(s)?
No
Description
FragmentedChemicalSystem did not let you access the FragmentedMolecule inside it. Similarly FragmentedMolecule did not expose the FragmentedNuclei in it. This PR fixes that.
TODOs
None. R2g.

🚀 [bumpr] Bumped! New version:v1.2.6 Changes:v1.2.5...v1.2.6


Extend metadata for RSpec cops?

@Darhazer  Does RuboCop-RSpec need to add the same kind of metadata that was added to RuboCop in https://github.com/rubocop-hq/rubocop/pull/6293 in order to work properly after RuboCop’s next release?

Generally - yes, this way we would be able to use the new options in Rubocop. I'll take care of this

@Darhazer do you mind sharing your branch? I can take this over if you like.

Oh, I see it https://github.com/rubocop-hq/rubocop-rspec/pull/721

Thank you @pirj for tackling this


Multiline message

Hello. Thanks for this awesome library. Is it possible for the toast message to be multiline instead of truncated text?

#11 Will allow 2 lines at least.

Added in v0.10.0


http://external.system.id=

https://github.com/plaid/plaid-link-examples/blob/master/webviews/android/link-android-webview-example.iml#L1-L21

Please create a new issue with the description of your bug. A random link is not sufficient without any other information provided.


Weather data in Local Weather App example is not displaying

In the The Local Weather App example (http://codepen.io/AdventureBear/pen/yNBJRj), the weather information (temperature, current weather, and wind speed) is no longer showing up. The reason appears to be that the Open Weather Map API where the app is pulling the data from now requires you to sign up for an API key. I tested this out on my own version and once I added the key, the page worked again.

Closing as duplicate of #3714
Please see https://github.com/FreeCodeCamp/FreeCodeCamp/wiki/Searching-for-Your-Issue-on-Github
Happy Coding!


SqlAGReplica: SESSION_TIMEOUT parameter missing?

ISSUE TITLE:
SqlAGReplica: SESSION_TIMEOUT parameter missing
ISSUE DESCRIPTION:
I don't see SessionTimeout parameter added.  Is it part of any other resource?
Details of the scenario you tried and the problem that is occurring
Using <IP_ADDRESS>
Verbose logs showing the problem
None
Suggested solution to the issue
NA
The DSC configuration that is used to reproduce the issue
    SqlAGReplica "AddReplica"
    {
        Ensure                     = 'Present'
        Name                       = node
        AvailabilityGroupName      = agname
        ServerName                 = nodename
        InstanceName               = sqlinstance
        PrimaryReplicaServerName   = nodename
        PrimaryReplicaInstanceName = nodename
        FailoverMode               = "Automatic"
        AvailabilityMode           = "SynchronousCommit"
    }

SQL Server edition and version the target node is running
SQL Server 2016
SQL Server PowerShell modules present on the target node
Name      Version    Path
SqlServer 21.0.17279 C:\Program Files\WindowsPowerShell\Modules\SqlServer\21.0.17279\SqlServer.psd1
The operating system the target node is running
OsName               : Microsoft Windows Server 2016 Standard
OsOperatingSystemSKU : StandardServerEdition
OsArchitecture       : 64-bit
WindowsBuildLabEx    : 14393.2430.amd64fre.rs1_release_inmarket_aim.180806-1810
OsLanguage           : en-US
OsMuiLanguages       : {en-US}
Version and build of PowerShell the target node is running
Name                           Value
PSVersion                      5.1.14393.2430
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.2430
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
Version of the DSC module that was used
Name         Version  Path
SqlServerDsc <IP_ADDRESS> C:\Program Files\WindowsPowerShell\Modules\SqlServerDsc\<IP_ADDRESS>\SqlServerDsc.psd1

Adding this as enhancement and help wanted so that someone in the community can run with this.


Need the PhoneCamera Configuration items

Need the PhoneCamera Configuration items like BackGround etc.
Error coming up at line 55
NullReferenceException: Object reference not set to an instance of an object
PhoneCamera.Start () (at Assets/Scripts/PhoneCamera.cs:55)

Hi @frajos100,
Sorry for late response. I rechecked the sample and indeed, it works without any changes. You probably made some accidental changes to the project when opening it. Resetting branch or cloning from scratch should fix it.


Allow setting RTC time

Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝

[ ] I have updated existing examples or added new ones (if applicable).
[ ] I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
[ ] My changes were added to the CHANGELOG.md in the proper section.
[ ] My changes are in accordance to the esp-rs API guidelines

Extra:

[x] I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖
Description
esp-idf has gettimeofday (see here) and settimeofday (see here) functions, allowing the user to get and set the internal RTC time. While esp-hal allows getting the RTC time, it does not allow setting it.
esp-idf sets the RTC time by storing the boot time (see here for getting, here for setting, here for esp32s3 register info). It calculates the current time by adding the boot time and the RTC time. Therefore, you can set the current time by setting the boot time to the new current time minus the RTC time. esp-idf also does some more advanced things like calculating the offset between RTC and systimer and adjusting the boot time, which I haven't taken the time to understand or implement since the current implementation is good enough for my needs.
This PR contains a very WIP implementation of this functionality in the Rtc struct. It only supports the esp32s3, but support for other chips should be trivial to add (just need to change the registers for boot time high and low). In addition, I haven't added any tests or examples, but I am willing to if this seems like a desired addition to esp-hal and when the API is finalized.
As for the API, I made the old get time functions private, since the new get_time_us will behave the same as the old get_time_us as long as the boot time is 0 (if the user hasn't set the time). When setting the time, there is currently possibility for an overflow to happen if the user tries to set the time to something smaller than the time since boot (causing the boot time to be negative and therefore overflowing). This is currently handled but the user will not know—a solution may be to return a Result and Err if an overflow would've happen. We could also make the boot time an i64.
There are also some traits in the rtcc crate that may be worth implementing.
Testing
This PR has been tested on a esp32s3.

Absolutely, but first I'd like to know what the preference is for general API (for instance, should the boot time functions be public?) and for implementing the rtcc traits. There is also the "boot time adjustment" and rtc offset to consider, but I don't really think they're needed.

I've deprecated Rtc::get_time_raw, added the missing get_time functions, added documentation, updated the rtc_time example, updated the changelog, and checked to ensure that RTC set supports all chips. While I only have an esp32s3 to test with, this PR should be ready for merging, unless further changes are wanted.

Oh, cool that you have checks for different devices (Or any at all?)
Yea, it doesn't compile for the c6, gonna look for a solution

For the c6 I think only this was needed:
        #[cfg(any(esp32h2))]
        let rtc_cntl = unsafe { &*LP_TIMER::ptr() };
        #[cfg(any(esp32c6))]
        let rtc_cntl = unsafe { &*LP_AON::ptr() };

using LP_AON instead of LP_TIMER
Some resources:
https://github.com/espressif/esp-idf/blob/8e4454b285ad39881c5bf3f440d8be617a2f18a8/components/esp_rom/esp32c6/include/esp32c6/rom/rtc.h#L60-L61
https://github.com/espressif/esp-idf/blob/8e4454b285ad39881c5bf3f440d8be617a2f18a8/components/newlib/port/esp_time_impl.c#L110-L121

Yes, that's correct. I saw LP_AON in the register headers but assumed it was the same as LP_TIMER, especially since LP_TIMER is used for the other RTC stuff. I'll add a fix when I have some time

I've realized that currently current_time and set_current_time use fugit::Duration when it makes much more sense to use fugit::Instant. However fugit::Instant has no helper methods for converting into units such as microseconds and therefore using it would make everything much more complicated since we'd have to do conversion manually (fugit's helpers are not publicly exposed). One option is converting from fugit::Instant to fugit::Duration, and then using its to_micros function. Thoughts?

Is there any chance of this being reviewed further?

Sorry for the delay in review.
I think code wise the impl looks great, but I also share your concerns about the API surface. I'm not sure even an Instant makes sense here, what we really want is wall clock time, just like the esp-idf APIs.
Perhaps we should return some time or chrono structs? It seems like embassy went this way (with there own structs too): https://github.com/embassy-rs/embassy/blob/main/embassy-stm32/src/rtc/datetime.rs

current_time and set_current_time now use chrono's NaiveDateTime. I'm guessing that the preference will be to avoid adding chrono as a dependency and instead use our own DateTime type like embassy, but chrono is definitely a simpler approach.
Currently, set_current_time will panic if the NaiveDateTime is before the Unix epoch. Wrapping should be possible but it's a little more complicated so I didn't implement it (and even if it was implemented, I don't know why anyone would want to set the time to before the Unix epoch).

Any chance of further review? It's been more than a month and it would be great to get this merged.

Changelog and examples are updated, so this PR should be ready to be merged

There is some overlap now between rtc_cntl::Rtc::current_time and time::current_time - not something that should be addressed here - just mentioning

Hmm good point, but I would somewhat argue that we should change time::current_time to something else, probably time::now, given that it returns an instant (not wall clock time)?
Imo Rtc::current_time fits quite well for wall clock time.

Hmm good point, but I would somewhat argue that we should change time::current_time to something else, probably time::now, given that it returns an instant (not wall clock time)?
Imo Rtc::current_time fits quite well for wall clock time.

👍  Sure - I'd vote for time::uptime() or similar - even the docs say "system uptime"

Thanks - probably you should revert fe8446899747c88d5b9f945f319e1133b90773ee since it's already done and merged in #2091

After a rebase this should be fine I guess

The PR has been rebased, and some basic info has been added to the migration guide


render spree partials in comfy

I try to render spree partials in comfy layout via {{ cms:partial:path/to/partial }} but have problems with methods.
Is it possible a closer integration comfy+spree?
I understand that add any decorators is need...
Thank you for your work!
Kate.

Hmm, more info please...
spree and comfy versions, code example

i can't repeat a problem
need more info: what partial, debug log...

thanks for the reply,
when I try to execute any partials containing
<%= link_to truncate(product.name, :length => 50), product, :class => 'product-name', :title => product.name %>
I am
get the error:
undefined method `product_path'
Completed 500 Internal Server Error in 396ms
ActionView::Template::Error (undefined method product_path' for #<#<Class:0x007fe278a041c0>:0x007fe279e47998>):     21: </figure>     22:      23:      24: <%= link_to truncate(product.name, :length => 50), product, :class => 'product-name', :title => product.name %>   app/helpers/spree/base_helper.rb:161:in method_missing'
app/views/spree/shared/_fancy_product.html.erb:24:in _3a7f93737a6043cb63f10bad2aa471e9'   app/views/spree/shared/_hits.html.erb:39:in block in _4c66e115f0ade9c23da3d87a23c25ebb'
app/views/spree/shared/_hits.html.erb:38:in each'   app/views/spree/shared/_hits.html.erb:38:in _4c66e115f0ade9c23da3d87a23c25ebb'

ok. try now.
9d07c9c7cc792e09a068ff1fd40eb680595bc32d

Hi, Alex,
I use your solution - all great. In difficult cases (for ex. when need render any spree-related partial in comfy), I use something like - :locals => { :products => @products, :taxon => @taxon }
Sorry, did not answer immediately.
Thank you so much!
Kate.

Great!
Feel free to post another issue.

This is a revolutionary solution for Spree.
Thank you for good product, Alex.

Thanks to https://github.com/comfy/comfortable-mexican-sofa
Not me.
But sounds good, thank you ))


melonDS: init at 0.8.3

Motivation for this change
melonDS is a useful DS emulator. It's still a WIP, but it is compatible with some games. I used the release version, although the git version has better compatibility, I'll update this when the next version comes out
Things done
Create a new package for the melonDS emulator

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
That's me

I'm not really sure why the eval check fails. :confused: Feel free to revert d94de75 if no one else looks at this, sorry about that.

I never actually figured out what rec did before! I fixed that and squashed.


Question: Why is txAdmin's latest stable version async from FXServer's artifacts?

Less of an issue and just curious why txAdmin's latest stable version is not in line with Latest Stable from the artifacts site?
I currently use a CI/CD pipeline to build a docker image for our FiveM server that runs daily. If the latest stable artifact changes, it updates the base image with the artifact build number. It also stores images with previous FXServer artifacts so we can roll back if needed. Today I noticed that txAdmin is prompting for an update when running on 3922 and I see that txAdmin is recommending 4022.
Just wondering what the logic here is and whether I should modify my CI/CD configuration?

That's because txAdmin is just one part of fxserver, and it being stable does not mean that fxserver at that version will also be stable.
Generally, all txAdmin releases are considered stable, but this time CitizenFX will only update the Latest Recommended in the next update, since the txAdmin menu is currently in beta, which doesn't seem much, but for the menu to work, we are using some cutting edge features from fxserver that are actually untested, like the way to webpipe http requests from the NUI to the fxserver.
I'm closing this issue, but feel free to comment more.

FiveM's Artifact website is heavily cached and not constantly updated, the way I like to know the most "stable" version is to check the FiveM changelog either in the client or on the server's website, which shows the latest version production clients of FiveM are running on, currently anyone playing FiveM is running on build 4011, so personally, I would update my server to 4011, just to stay in sync with what most are currently using, if someone is running the canary build though they would be using build 4042 now.
Changelog:
https://servers.fivem.net/changelog
You can get the latest artifact by doing !artifact in the txAdmin Discord:
https://runtime.fivem.net/artifacts/fivem/build_server_windows/master/?646_fix_cache_4042
This is just how I would personally update my server as I know the "recommended" button on the artifacts page is constantly updated and can sometimes fall months behind what is really recommended.

Ah I see, thank you both for the replies. That is exactly how I'm getting the latest build number at the moment. Something like
echo "BUILD_VERSION=$(curl https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/ | grep "LATEST RECOMMENDED" | grep -oP "\d{4}")" > build.env

Sounds like this may not be the most reliable solution :)

You can also do:
https://changelogs-live.fivem.net/api/changelog/versions/linux/server?someRandomBs

Thanks! That looks a little cleaner


Allow to specify client url as an absolute url

In my opinion current approach when specifying the client url is a bit confusing.
quarkus.cxf.endpoint."/foo".client-endpoint-url=http://localhost:8081/soap/greeting

This configuration requires that the part /foo is constant. And if that suffix changes, it is necessary to modify all config entries to accommodate that change.
I think the ability to specify the absolute url of the client service could be useful in some cases - especially if that url needs to be dynamically set e.g via an environment variable.
Looking forward to your thoughts on that (or maybe I missed some obvious solution with the current impelmentation?).

can you open an issue, and we can talk with @shumonsharif  @Dufgui @bnazare or any other of community about better solution.  I want to avoid new boolean config if possible...

I'm in complete agreement with you @dufoli - we should not be introducing a new config, if at all possible.
@jakubpietrzak96 Would you kindly share some more details on what you are trying to achieve, and why it can't be handled with Quarkus' property expressions and environment variables?
https://quarkus.io/guides/config-reference#combine-property-env-var

An additional note - I haven't done this before, but if you must have a need to make /foo dynamic, I believe a much better approach would be through:  https://smallrye.io/docs/smallrye-config/interceptors/interceptors.html#relocate-interceptor

Closing as agreed in #131


updates features section

Description

This PR fixes #1201

Notes for Reviewers
Signed commits

[ ] Yes, I signed my commits.

@thisiskaransgit Also I feel the cloud native catalog card images doesn't go well with the gray background

hii @thisiskaransgit
Let's discuss it on the websites call.
Please add this as an agenda item in the meeting minutes, if you would :)
https://docs.google.com/document/d/1XczAHXVe2FIWPqiF57ospJ43zw5cZQ7ui8mn39v5EvA/edit#heading=h.lohhtewfwima

@Chadha93 I did

@Chadha93, thanks for pointing out, two points were left to update, did that. Additionally, there was a design issue after updating the branch to the latest, which I fixed.


Add line numbers when reporting broken content

Position in a source file is followed when building source maps only, but it would be nice to do it at all times to point to a place with a broken content.
See #449

This is fixed on master as well thanks to the new tokenizer.


helm creates efs-provisioner only with fs-12345678 default setting

Is this a request for help?:

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Version of Helm and Kubernetes:
1.10
Which chart:
efs-provisioner
What happened:
my command
helm install stable/efs-provisioner --name=provis --set efsFileSystemId=fs-2c2f4685 --set awsRegion=us-west-2
kubectl describe pods provis-efs-provisioner-xxxxx
Output: Running scope as unit run-29329.scope.
mount.nfs: Failed to resolve server fs-12345678.efs.us-east-2.amazonaws.com: Name or service not known
mount.nfs: Operation already in progress
What you expected to happen:
pod config must have correct value
How to reproduce it (as minimally and precisely as possible):
follow readme in efs-provisioner
Anything else we need to know:

The docs are incorrect. You need to use e.g.
helm install stable/efs-provisioner --set efsProvisioner.efsFileSystemId=fs-ae098765 --set efsProvisioner.awsRegion=eu-west-1 --set efsProvisioner.path=/ --set efsProvisioner.storageClass.reclaimPolicy=Retain --name efs-provisioner --version 0.1.1

This should become part of the docs!

Has anyone had any recent success with this chart?  I have an EFS in the same region as my k8s nodes and with the same sg policy, but consistently failing to mount:
mount.nfs: Failed to resolve server <EFS DNS>: Name or service not known

I also noticed this issue is struggling to pass, just based on a readme update:
https://github.com/helm/charts/pull/7603
Thanks!

:arg:  From https://docs.aws.amazon.com/efs/latest/ug/troubleshooting-efs-mounting.html
If you are using a custom VPC, make sure that DNS settings are enabled.
Desired state on VPC:

@jl-gogovapps Was you able to find a solution to the error
mount.nfs: Failed to resolve server <EFS DNS>: Name or service not known
when using this chart?

@kevinfaguiar according to AWS docs at https://docs.aws.amazon.com/efs/latest/ug/manage-fs-access-vpc-peering.html

You can't use DNS name resolution for EFS mount points in another VPC. To mount your EFS file system, use the IP address of the mount points in the corresponding Availability Zone.

I've never personally done this, but it sounds like DNS not working for EFS across the peering connection is expected behavior as far as Amazon's docs are concerned. I would try setting the efsProvisioner.dnsName value to one of the EFS endpoint IPs directly and seeing if that works. If it does, then you may want to consider setting up custom DNS as suggested in the docs I linked so you can avoid hardcoding the IP. If that doesn't work, then you may want to contact Amazon support.

Thank you so much @drakedevel! My scenario is one where I need the API and the UI (two different services, with two different deployments, which can scale to as many pods as possible) to share a folder (/tmp). So, studying a little, I thought that using EFS was the best solution.
However, my region (sa-east-1) does not has EFS available... Do you happen to know another solution for my scenario (using some AWS storage which permits ReadWriteMany) which doesnt means rewriting my app? I can't help but think this is a probably common scenario for putting legacy applications into pods, and it feels really hard. But there is the other side too: that sharing an folder which is essential to both services is an anti-pattern in Kubernetes.


Automate deployment procedure to k8s cluster via GitHub Action CI/CD

Impact of the new feature
Automate deployment procedure to cmsweb k8s cluster via GtiHub Action CI/CD pipeline
Is your feature request related to a problem? Please describe.
Reduce operational cost associated with current deployment procedure
Describe the solution you'd like
Use GitHub CI/CD pipeline to trigger automatic builds of all WMCore services upon new tag creation. The build should include the following steps:

build new release, python tar ball, and upload it to PyPI
perform basic test of new release
build new docker image and upload it to CERN registry
upload new image to cmsweb testbed k8s cluster via image bot
if necessary perform/run basic workflow tests

Describe alternatives you've considered
Some of the functionality exists in Jenkins, but it is limited to testing new release and does not take into account docker image and integration with k8s infrastructure
Additional context
With fully automated builds we can significantly reduce cost of operations, especially if you start managing multiple services.

I want to share with you that I was able for the first time to successfully build WMCore in GitHub Action. To make this thing I setup independent repository [1] where I'm testing GitHUb Action builds.
The build is based on Debian distribution (GitHub action does not support cern/cc7) and pypi WMCore build. You can view the GitHub action workflow over here [2].
It almost build everything with only few hick-ups I found during the build:

there is no gfal2-python package on Debian and so far I did not found clear recipe how to build it manually
I also found that pycurl requires curl-config which comes from libcurl library which I install manually via apt-get
I also found that our requirements.txt uses dbs3-client version 4.0.10 depends on pycurl~=<IP_ADDRESS> and build fails since we have pycurl~=7.45

for this item I do not really know if we managed to build WMCore via pypi   using the requirements.txt Does anybody know?
anyway, I replaced the version of pycurl to be <IP_ADDRESS> and finally got the   first GitHub WMCore build using pypi.

This repo [1] and my recipe [2] can be used as initial point in further progress towards CI/CD and GitHub Actions. We need to polish details but the proof-of-concept is there and it shows that we may have a GitHub Action build. The next step would be to make Docker image based on this build, and if we manage it, then I can add action to deploy the image to k8s cluster(s).
[1] https://github.com/vkuznet/wmcore-builds
[2] https://github.com/vkuznet/wmcore-builds/blob/main/.github/workflows/python-app.yml

This is great news, Valentin.
Reviewing our recent discussions on PyPi, RPM-less packaging and deployment, I would suggest to reduce the scope of this GH issue to only "automated build of docker image and upload to CERN registry". Otherwise it's very hard to accomplish everything that you mention in the initial description. What do you think?

yes, we can easily reduce the scope to only building the image and upload to CERN registry. So far, I'm in a stage of make a normal WMCore build, not even build the image. If someone, e.g. @goughes , will tell me how to invoke python build xxx for specific systems then I can try to build these systems. Then, if it is successful we can build the image. If you have Dockerfiles laying around please also tell me which one to use for which build, otherwise I'll use my experience to use generic Dockerfile and build some image(s).

There is an issue with wmagent, and reqmgr2ms installation, see https://github.com/dmwm/WMCore/issues/11327 It should be addressed before we can move forward with this one.

Based on suggestion in https://github.com/dmwm/WMCore/issues/11327#issuecomment-1274847371 we should adapt building docker images automatically via CI/CD pipeline. The procedure can be used from https://github.com/dmwm/WMArchive/blob/master/.github/workflows/build.yml#L65 till the end of the file which fetches image, then build it and upload to registry and even put it on testbed

The scope of this GH is too large. IMO, it should simply request the following deliverables:

build new docker image and upload it to CERN registry

build to PyPi has been done already. Automatic deployment of images to the kubernetes infrastructure (dev/testbed/production) is likely to be further discussed, and well worth it its own GH issue. Run some basic workflows would also deserve its own GH issue.
@vkuznet can you please update the initial description here?

@amaltaro , I updated (simplified) description of this issue and will proceed with it. This is what we discussed on a zoom call, i.e. once we have images we'll automate their creation and upload to registry. The only technical detail we need to agree is tagging naming convention. For instance the tag should include release tag plus pypi prefix or suffix, e.g. 1.2.3-pypi. Do you agree?

We can easily move with this issue since now pypi images are built and I even validated reqmgr2, see https://github.com/dmwm/WMCore/issues/11354
@amaltaro I need your input on this and #11339 to move forward with this. Once #11339 is incorporated then we will have full CI/CD in place.


Demo Kit Demo App "Application Best Practices "Add new product" not working with german locale

OpenUI5 version: openui5-sdk-1.22.8
Browser/version (+device/version): Firefox 32.0 Windows 7 32 bit German locale
Any other tested browsers/devices(OK/FAIL): no other device / browser tested
URL (minimal example if possible):
/openui5-sdk-1.22.8/test-resources/sap/m/demokit/tdg/index.html?responderOn=true
User/password (if required and possible - do not post any confidential information here):
Steps to reproduce the problem:

Start demo app "Application Best Practives"
Press + to add new product
Choose 15.9.2014 (German date notation) from the datepicker in field "Release Date:"
Additionally fill in the other fields like "Product Name" ....
Press Save button

What is the expected result?
New product should be added
What happens instead?
Pop up: Warnung Problem creating new product.
A new product is not created.
Any other information? (attach screenshot if possible)
See screenshot.
I think this issue might be a side effect of fixing issue #90

I am closing this issue as the TDG app has been removed via 8bb457df4ea937607c3e396cedb5d4c24d50f26b in favor of new best practices apps. See #414 for more information.


Simplify column segments in Details page

The first column could be removed and when there is more than one segment, the number of segment could be drawn on the canvas.

The number of segments drawn on the canvas:

Implemented in release v4.2.2.


[Suggestion] Remove V3 node from Radarr page now that its the only supported version.

It's a bit unnecessary to have to expand "V3" to see the Radarr guides now that v2 support has been dropped. The guides should be all at the root level now and clickable without expanding a tree node first.

That's true and I was looking at it last weekend,
but if I change it we will break all direct links to it,
and when Radarr decides to start with Radarr v4 it would mean I need to move it again.
I will take a look if I'm able to set it to auto expand for only this page but I'm not sure if that's possible.

That's true and I was looking at it last weekend,
but if I change it we will break all direct links to it,
and when Radarr decides to start with Radarr v4 it would mean I need to move it again.
I will take a look if I'm able to set it to auto expand for only this page but I'm not sure if that's possible.

Perhaps a more modular approach would be a dedicated page for each version of Radarr. How you want to structure the links to those pages is up for debate, but I'd likely go with a navigation tree on the main page, something like:
Radarr
     -> V4
     -> V5
(etc)

Perhaps a more modular approach would be a dedicated page for each version of Radarr. How you want to structure the links to those pages is up for debate, but I'd likely go with a navigation tree on the main page, something like:
Radarr
     -> V4
     -> V5
(etc)

these are the main entries to the guides for a specific application
and the navigation on the left are the sub sections
So adding a v2/v3 to the top is one big mess
Example how Sonarr looks

these are the main entries to the guides for a specific application
and the navigation on the left are the sub sections
So adding a v2/v3 to the top is one big mess
Example how Sonarr looks

To better show what I'm suggesting, an alternative would be a hover submenu that pops up on the main menu that allows you to navigate to a specific version. Steps:

Hover mouse cursor over "Radarr" on the main menu
A submenu appears with "V2" and "V3" under it
Click one of the versions to be taken to the Radarr page for that version, with a tree view on the left (as it is today) but without the collapsing sections, making it more navigation friendly and straightforward.

The benefit to this is that when a new version is released, you don't have to go change existing pages, you just add a new one. It makes it easier to maintain.

To better show what I'm suggesting, an alternative would be a hover submenu that pops up on the main menu that allows you to navigate to a specific version. Steps:

Hover mouse cursor over "Radarr" on the main menu
A submenu appears with "V2" and "V3" under it
Click one of the versions to be taken to the Radarr page for that version, with a tree view on the left (as it is today) but without the collapsing sections, making it more navigation friendly and straightforward.

The benefit to this is that when a new version is released, you don't have to go change existing pages, you just add a new one. It makes it easier to maintain.

The benefit to this is that when a new version is released, you don't have to go change existing pages, you just add a new one. It makes it easier to maintain.

I don't need to change anything on the existing page,
i just create a new folder and start adding the new guides to it and it's automatically created.
Keep in mind the Guide site makes use of mkdocs,
I can only use plugins/add-ons what exists for it.
So if you find one tell me and i can check if i can add it.
I'm not going to search for something like that active, I better waste my time creating more "needed" guides. ;)
You can re-open it when you found one.

The benefit to this is that when a new version is released, you don't have to go change existing pages, you just add a new one. It makes it easier to maintain.

I don't need to change anything on the existing page,
i just create a new folder and start adding the new guides to it and it's automatically created.
Keep in mind the Guide site makes use of mkdocs,
I can only use plugins/add-ons what exists for it.
So if you find one tell me and i can check if i can add it.
I'm not going to search for something like that active, I better waste my time creating more "needed" guides. ;)
You can re-open it when you found one.

As a compromise, would it be reasonable (or even doable) to have the latest version in the tree expanded by default?

As a compromise, would it be reasonable (or even doable) to have the latest version in the tree expanded by default?

That isn't possible it's all or nothing,
i already asked => https://github.com/squidfunk/mkdocs-material/discussions/2185

That isn't possible it's all or nothing,
i already asked => https://github.com/squidfunk/mkdocs-material/discussions/2185


python310Packages.nexia: 0.9.13 -> 1.0.0

Description of changes
Update to latest upstream release 1.0.0

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 173638 run on x86_64-linux 1

1 package failed to build:

home-assistant-component-tests.nexia

2 packages built:

python310Packages.nexia
python39Packages.nexia


Upstream fix for numeric_only default [WIP]

I started to work on a fix for the numeric_only CI failure we are seeing. I've only covered one file, but I wonder if this is the approach we want to pursue. If so I can continue adding all the other files.

[x] Closes #9204
[ ] Tests added / passed
[x] Passes pre-commit run --all-files

cc: @jsignell @ian-r-rose and @pavithraes because I know you were looking at this one.

Thanks for starting this Naty! I would think that the approach would be to change the default on the method definition itself. The part that is up in the air is whether the default value of numeric_only should depend on the version of pandas or not.

I would think that the approach would be to change the default on the method definition itself. The part that is up in the air is whether the default value of numeric_only should depend on the version of pandas or not.

Do you mean like here for example for the mean?
https://github.com/dask/dask/blob/ecbab9d7cb52a2d96cb1b8dc397a87811e6f8059/dask/dataframe/groupby.py#L1475-L1480
Do you want to change it on the method to be numeric_only=True, regarding of the pandas version? This will be an inconsistency as Pandas default will be numeric_only=False, is this the way we want to go?. Unless I'm missing something here.

Oh. I hadn't fully internalized that pandas is explicitly trying to make people specify numeric_only. This seems super verbose, but I guess yeah what you have is right if we are committed to exposing dask users to the future warnings from pandas. Sorry for the distraction.

@ncclementi @ian-r-rose and I looked at this today.
According to this changelog entry:

for pandas=1.5, numeric_only=None has been deprecated and set to True by default
however, there is a deprecation warning that says it will be False by default in a future release (looks like 2.0)
there are also new functions that have "gained" this numeric_only kwarg -- same defaults as the previous two points

Next,

Currently in Dask we don't support numeric_only=False (see here)
If this will be the default in pandas, do we want to support it? (probably not?)
We can also set the default to False in the definition but continue to only support the True case (like we do with apply, axis=1 here)

Should we support this intermediate numeric_only=True case? Or, shall we jump to False directly?
It'll be nice to get a consensus beforehand because we'll be touching many functions with this.
Sidenote, current docs (example here) says we don't support numeric_only because it's not in the function definition, but we actually do support (at least numeric_only=True) because pandas does.

I think short term we should add support for numeric_only=False and then when pandas switches to False so can we.

for pandas=1.5, numeric_only=None has been deprecated and set to True by default

Yeah I think that's right and it raises a warning unless you explicitly set numeric_only:
In [1]: import pandas as pd
   ...:
   ...: df = pd.DataFrame({"a": [1,2,3], "b": ["a", "b", "c"]})

In [2]: df.mean()
<ipython-input-2-c61f0c8f89b5>:1: FutureWarning: The default value of numeric_only in DataFrame.mean is deprecated. In a future version, it will default to False. In addition, specifying 'numeric_only=None' is deprecated. Select only valid columns or specify the value of numeric_only to silence this warning.
  df.mean()
Out[2]:
a    2.0
dtype: float64

If False will be the default in pandas, do we want to support it? (probably not?)

I think it would be fairly easy to support. And it would eagerly fail (like pandas does) most of the time since we try to run functions on the meta first.

We can also set the default to False in the definition but continue to only support the True case.

I don't like this idea very much.

Should we support this intermediate numeric_only=True case? Or, shall we jump to False directly?

I think even longer term in pandas the intention is to get rid of this kwarg so probably we can just jump to False and delete the whole thing when pandas goes to 2.0 and we can just stop supporting versions of pandas where numeric_only isn't a valid kwarg.

Linking here the reply on the pandas repo about the defaults status for all the affected operations.
https://github.com/pandas-dev/pandas/issues/46560#issuecomment-1180871534

@jsignell and I were chatting about this one, I'm closing  this PR in favor of #9269


[WIP] Progressive loading for 2D and 3D data

🧰 Task
A little background on the text: the text that I am initially adding here was developed for an internal process from Dec 2022 - Feb 2023, but is being shared out to make the effort 100% public. This is my preference as well. This document is closely related to code in this repository: https://github.com/kephale/napari-multiscale-rendering-prototype. After this document was written fun things happened and we now have a great community effort with @jni @alisterburt @GenevieveBuckley @ppwadhwa. Please take this document lightly because we've changed quite a few things since the original writing (e.g. starting on 3D first instead of 2D) :)
Progressive Loading for napari
napari users need to be able to visualize large datasets efficiently, especially for out-of-core data (data that is larger than system or GPU memory).  While there are numerous approaches to visualizing out-of-core datasets, there are some underlying motifs in the design of these approaches.  This document presents these motifs as individual requirements, and the corresponding engineering efforts address the exploration, design, and implementation of algorithms to address each requirement.
Large array data (e.g. dask, zarr) uses different representations than small array data (e.g. numpy), where the array is subdivided into chunks.  This facilitates data access and, in the case of zarr, can improve writing performance.  The use of chunks also makes it easier to perform tiled rendering, where a subset of tiles/chunks can be rendered at any given time.  Tiled rendering is the primary strategy for incrementally updating a display with subsets of data.
Tiled rendering is not sufficient on its own.  If we only perform tiled rendering, then the user will often see partially empty images due to tiles that have yet to be loaded/rendered.  To smooth this experience for the user we use multiscale rendering, where downsampled versions of the image are quickly loaded first and repainted with higher resolution data.  Multiscale rendering minimizes the amount of time the user sees an empty canvas.
Caching is an important aspect of loading large data, because data is often loaded from a remote data source.  Any implementation of Progressive Loading should include a caching strategy, and the caching strategy should accommodate multiple large data sources and data types.  The implementation of the caching strategy may require 2 components: a disk cache and a GPU memory cache, where the disk cache is important for CPU-based Progressive Loading and the GPU cache is important for 3D volume rendering.
Tunable quality and memory constraints are desirable. In particular, being able to guarantee an upper-bound on the memory usage is a feature that makes it easier to ensure that the rendering method can run on performance-constrained hardware. Similar concerns are relevant to the management of cache size when multiple Progressive Loading layers are being used.
Ultimately, the Progressive Loading effort should introduce support for 2D and 3D visualization of Image, Label, and Point datasets for datasets that exceed system memory. Within the scope of the effort addressed by this RFC, prototypes will be developed that provide this support. These prototypes will go through user testing and will be used to determine the best way to achieve a polished product.
Approach
The goal of our approach for providing Progressive Loading involves developing Python-based large data rendering prototype plugins, as well as exploring the prospect of developing a napari plugin around an existing tool that supports large data rendering, BigDataviewer.
Key points:

These prototype plugins will be evaluated by documenting the experiences of select members of the community with exemplary use cases (cc @LCObus @dgmccart @chili-chiu ).
Python-based prototypes will leverage dask and zarr to display out-of-core images in napari.
The Python-based large data renderer will require improved support for dask delayed, and a custom caching strategy within the napari ecosystem.
The Python prototype of a large image volume renderer may require exploration of additional rendering libraries, such as the CZI EOSS funded project vispy2.
Alternative renderers, like BigDataViewer, require a different approach that is addressed being addressed in parallel (DM @kephale; will update here as things are posted).

Communication
This RFC describes a learning effort that is focused on developing multiple prototypes for new technologies. Scheduling deadlines for these prototypes can lead to unnecessary re-planning because there is significant community interest and activity related to large image data and progressive loading; some of the work will have to be prioritized opportunistically. However, to support transparency and observability activity on the project will be actively shared on an ongoing basis (see existing Zulip stream for example)., including a monthly shareout at community meetings.
Some places for tracking updates about this project include:

Developer discussion: https://napari.zulipchat.com/#narrow/stream/212875-general/topic/poor-mans-octree

Core Design
For simplicity, the basic architecture will be developed with a focus on 2D; however, 3D prototypes will simultaneously be explored to ensure generalizability beyond 2D.  The initial version has been prototyped to include, simplified tiled rendering, basic caching, and a multiscale rendering strategy.  However, there are some key limitations in the existing prototype:

the vispy/GPU component of the renderer is currently a hack that will break with extremely large 2D data (e.g. when the 2D canvas array exceeds available GPU memory)
only the x and y axis work (Z is hard coded); the user can only see/access a 2D slice of the image
UI for selecting groups/hierarchical data
chunk data fetching is not threading safe
chunk data should be fetched with a Dask executor instead of threading module
a more advanced cache should be used to support multiple large image layers

These efforts can be partitioned into 3 focus areas: rendering, UI, and data fetching/caching.  Finally, some tooling work to support testing data size and type limits and visually debugging the resulting prototypes is also necessary.
Development is based upon the latest version of the napari repository (and other plugins), and may potentially leverage unreleased features and private variables. When the prototypes are adapted for production, version pinning will take place.
Prioritization of effort is key for the development of progressive loading because there are a number of potential bottlenecks (data fetching, caching, data/chunk prioritization, texture updates, etc.). Ultimately we would like napari to have the highest quality rendering possible, including the progressive loading aspect. However, given that the current vispy will be replaced by vispy2, there is strong motivation to focus as much effort as possible into implementing progressive loading with minimal usage of vispy and/or GPU-specific code. Achieving ideal rendering quality will eventually require this type of more focused computer graphics effort, but within the scope of this effort, the goal is to develop a progressive loading implementation for 2D and 3D that will be robust to future code change.
Rendering
The rendering efforts here refer to the implementation of tiled rendering and GPU memory management.
The current 2D prototype assumes that it is possible to pre-allocate a large 2D plane that represents a cross-section of the dataset.  This works in many cases, but will fail in cases with a large 2D extent.  Furthermore, it is not efficient and leads to overallocation of GPU memory.  The 2D memory allocation should be revised to be determined based upon napari's current display size.
In principle, the 3D implementation for tiled, multiscale rendering may follow the same design as 2D.  The key differences are: rendering 3D data to a canvas requires more data than 2D, and rendering 3D data benefits from GPU power, but this requires GPU memory management.  These differences are significant because the amount of additional data that volume rendering requires is large enough that it is often not possible to render the image data at the highest resolution.  This necessitates rendering and caching strategies that efficiently move data between remote, local, and GPU storage in a way that leverages multiscale representations.
A special consideration in the case of rendering effort is "vispy2."  vispy2 is funded by CZI's EOSS program, and the vispy2 library is designed to replace vispy, which is napari's current rendering backend.  Not only does vispy2 propose numerous modern features, but vispy itself is built on top of OpenGL which is depracated on MacOS.  After discussions with the vispy2 team, it is clear that the progressive loading effort should not expect to build on top of vispy2 with the current timeframe, but we are enthusiastic about the opportunity to stay engaged with vispy2 during their development process.
User Interface
UI efforts will focus on multiple needs:

A feature to select different renderers (existing Image renderer and large data renderer) to support user testing (this feature may not be needed in production),
UI controls need to work with the large data layer (e.g. channel, Z, time sliders), and
a new ability to interactively open/select datasets from HDF5/zarr hierarchical files.

UI efforts will leverage napari-hierarchical, which is a plugin that allows users to explore HDF5 and zarr datasets (note that there is other related work planned on savable viewer states in napari that may leverage napari-hierarchical).  For example, menu items for selecting renderers will be exposed as context menus in napari-hierarchical.  Note that these UI choices are about the convenience of prototyping, and UX feedback will be recorded during user testing reports.
Work packages are described in this github issue.
The user experience testing tool may have a basic data collection component that would allow users to export properties of their data that will be informative for development, such as: data dimensionality, image size, and file size.
Data Fetching and Caching
Data fetching and caching is critical for large data handling.  Datasets are generally fetched from remote sources and often exceed local resources (disk, system memory, and GPU memory).  As a consequence it is important to carefully manage data retrieval and caching.
Data retrieval can be accelerated by using multiple threads, which is the case in the current 2D multiscale tiled rendering prototype. However, the current implementation uses Python’s threading module but with a naive batch parallelization strategy, where N threads start fetching chunks at the same time but all threads must wait until all threads are complete. Dask executors are an abstraction for parallel processing that work in local and remote environments. Large data processing in napari is already heavily reliant on Dask array data structures. Dask provides support for monitoring threads and controlling Python’s threading module, making it a better option than threading when something more than simple threads are needed. On the other hand, other tools that support parallel processing, such as Ray, Joblib, etc., either would require new dependencies to be added to napari or do not have native support for large arrays.
Although naive caching strategies can be easily implemented, it is important to consider multiscale-aware caching strategies, where particular scales can be cached to ensure a natural user interaction. These caching strategies are important in the context of support for multiple layers.  Cache resources must be shared evenly across layers, otherwise the users may observe uneven performance when working with multiple layers simultaneously.
Some attention will be invested into considering the possibility of a persistent cache.  There are many cases where a user will work with a particular large image dataset across multiple napari sessions.  A persistent cache would speed up the user's experience on subsequent napari sessions, after an initial session that loads the data.
While the prototype leveraged the native Python functools-based cache, a Dask cache (based on cachey) will need to be developed.  This will require exposing the cache contents to enable more intelligent methods for cache clearing.  The approach will require adapting element prioritization within the cache.
Finally, the design of caches will need to be aligned with the Dask cache, the GPU cache (in the case of volume rendering), and the potential persistent cache.
Tooling Work
Overall the goal of the proposed tooling work is to support the Progressive Loading development process, but these tools are not direct goals of the effort. The Large Data Generator tools have the goal of accelerating the development cycle by reducing reliance on remote downloads of 100s of GB of data during feature testing, and increasing the availability of different data sizes and types. The Visual Debugger is important for confirming that the Progressive Loading effort has been successful by inspecting the resolutions of image data as they are loaded. The amount of effort required is expected to be minimal (approximately ~1 FTE week).
Large Data Generators
There are a number of parameters of each dataset we consider, such as number of scales, pixel type, layer type, dimensionality, and size.  All combinations of these parameters are not present in our example test data.  To support testing across wide combinations of parameters, we will leverage simple synthetic data generators.
The use of synthetic data generators to support napari development is discussed and explored in a separate CZI-internal document (DM @kephale, happy to share out and plan to do so regardless of whether any one asks).  In this work we consider 2 simple data generators: checkerboards and fractals (see Figure FractalExample).  Both of these patterns can be easily generated on-the-fly, and do not require on-disk storage that can otherwise be prohibitive for storing large test datasets.  Our current large datasets for testing are specific precomputed real-world datasets, which means they cannot be easily/efficiently adjusted to have different features like size and shape.  In particular, the generative dataset generators will produce multiscale datasets with tunable numbers of scales, dimensions, and image size.

Figure FractalExample. An example of a generative fractal based on the Julia Set displayed in napari.
Visual Debugger
The development process for multiscale and tiled renderers is vulnerable to some typical bugs.  Half-pixel offset bugs are common in multiscale rendering, where the downsampling method that was used to create a given multiscale dataset affects how the multiscale rendering should be performed.  Loading and positioning errors with tiles are also common, where tiles may be loaded from incorrect scales, in the wrong order, or put into the wrong location.  While a test suite will ultimately prevent these bugs from being introduced into the final product, during intermediate states of development visual debugging is often critical.
To address these issues, a visual debugging tool will be developed that provides the developer with visual overlays to indicate scale and other source information about chunks/tiles, see (Figure VisualDebugger) for a 2D mockup and this video for a demo that shows a visual debugger overlay of resolutions for 3D.

Figure VisualDebugger: An overlay view will help developers debug multiscale rendering issues by using color overlays to indicate the active scale level.
Notes
Q1: How to handle napari’s current strategy for arbitrary slicing of volumes? (See Lorenzo’s message) Can the slicing plane be used for chunk prioritization similar to the current implementation with camera?
Decision1: (Kyle has a proposed solution in Lorenzo’s thread)

Really enjoyed reading this @kephale, thanks for sharing out! Clarified my thinking on the relationship between multiscale and progressive rendering. Super excited to see how this work pans out!

Very cool Kyle!  I like the way you are thinking about this.
Looking forward to see what will happen here!

Hi Folks!
I recorded a walkthrough of the current version of the code from https://github.com/kephale/napari/tree/poor-mans-octree which demonstrates the end-to-end test for multiscale volume rendering. This is not the full volume renderer!
You can see a quick demo of what the code does here:
https://drive.google.com/file/d/10W5z-z9QAzKVL4WGNXjjO5NyAbUOyU6K/view?usp=sharing
The walkthrough is here: https://drive.google.com/file/d/117Tnh2acUUq1yFhlxrPXS5DNNV766RT2/view?usp=sharing. More ramble-y than I'd hoped but it is better to work on the follow up work than re-record.
Cheers,
Kyle

Thanks @kephale! My hope is that we can share as much code between the two paths as possible, using functional abstractions to separate them, e.g. should_fetch_chunk() -> bool would have 2D and 3D paths, chunk_priority() -> float same, but the render loop (has the camera moved, if so grab chunks asynchronously until the scene is how we want it) should be the same for both. Does that make sense? Are there reasons why that can't work?

Hello Friends!
Cool demo today:
I've derived an example from an awesome Mandelbrot demo made by the Vizarr team (see original here: https://colab.research.google.com/github/hms-dbmi/vizarr/blob/main/example/mandelbrot.ipynb).
Here you can see 2D tiled loading in napari of a 134,217,728 x 134,217,728, 8-bit image with 18 scales (~18.0143985 petabytes). There are still plenty of things to improve, and yes the Mandelbrot set is rotated from its normal orientation.
This isn't the visual experience that will be delivered at the end of the day. The main point and excitement of this demo is the size of the image being visualized in napari with tiled loading that does not block user input.
https://github.com/napari/napari/assets/400105/01614e78-1e4c-402b-a31e-9345a0253817

Wow, this is super exciting, @kephale ! @jluethi might be interested in this.

so so so sick!!!

Very nice! Is the mandelbrot example reusable as an independent napari script? Or is it tightly coupled to the implementation right now? I'd be curious to try it out with https://github.com/napari/napari/pull/5816 - I'm pretty confident it will be quite a bit worse (maybe even a non-starter), but it's hard to avoid the comparison.

Very nice! Is the mandelbrot example reusable as an independent napari script? Or is it tightly coupled to the implementation right now? I'd be curious to try it out with https://github.com/napari/napari/pull/5816 - I'm pretty confident it will be quite a bit worse (maybe even a non-starter), but it's hard to avoid the comparison.

Reusable! I'll clean the code up next week, some of the changes that made this demo possible leaked into the Mandelbrot part of the code.

@kcpevey has been helping out recently as well and was a great help when puzzling through some of the recent bugs!

Very cool demo! 🤯

I've derived an example from an awesome Mandelbrot demo made by the Vizarr team (see original here: https://colab.research.google.com/github/hms-dbmi/vizarr/blob/main/example/mandelbrot.ipynb).

I tried running this and found I needed to make the following change for it to work
- store = MandlebrotStore(levels=50, tilesize=512, compressor=Blosc())
+ store = zarr.storage.KVStore(MandlebrotStore(levels=50, tilesize=512, compressor=Blosc()))

Without this, you get the error
ValueError: Starting with Zarr 2.11.0, stores must be subclasses of BaseStore, if your store exposes the MutableMapping interface wrap it in Zarr.storage.KVStore. Got <__main__.MandlebrotStore object at 0x7f0bf0bc7010>

@kephale my god it's beautiful

@kephale This is so awesome. Love it!

Many thanks to @psobolewskiPhD for helping with the scale bar behavior! Otherwise it can get confusing when you're deep in the Mandelbulb.

A day late for you @royerloic, but the plan is for Zebrahub to be the next dataset we focus on for this project.

This is really exciting!!!! We will put it use too!

Ahhh so exciting!

Tracking some next steps:

[ ] combine individual scale layers into a single layer/vispy node
[ ] visualize loading order to ensure correctness (address https://github.com/napari/napari/issues/4633 at same time?)
[ ] team w/ @andy-sweet to integrate with async (which should provide the new loading indicator for free: https://github.com/napari/napari/pull/5342)

Tracking this comment from one of @andy-sweet's PR reviews: https://github.com/napari/napari/pull/6043#discussion_r1289079140 about tile2data

Here is a super early demo of visualizing images from Zebrahub (@royerloic @JoOkuma and friends). The new thing here is visualizing data with a dimensionality other than the viewing mode (2D or 3D), in this case the data is 4D. In the video I move through a few timesteps and a few scales.
This is still a bit hacky and there are things to improve, so I look forward to doing some cleaning at the hackathon next week.
https://github.com/napari/napari/assets/400105/24edab40-54ac-4e3f-8412-409c7ac05539

Paired with @kevinyamauchi to make a very satisfying debugging visualization.
https://github.com/napari/napari/assets/400105/9392b2e3-cd51-4635-a5af-3fa0fe78f222


feat: update metrics

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

45 of 56 (80.36%)  changed or added relevant lines in 7 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 85.157%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

service/router.go
1
3
33.33%

metrics/metrics.go
0
9
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.4%

Covered Lines:
1876

Relevant Lines:
2203

💛  - Coveralls


Fetch docs with git clone instead of GitHub API

Docs folder now fetched with git clone and sparse checkout. Tests updated as well to mock local repo docs.

Hello and welcome! Sorry to have kept you waiting so long. Huge thanks for working on this! 🙇 I (or one of my colleagues) will try to get back to you with a proper review as soon as poss.

Hi @sengi, thanks for the code review, please see my updated change (which should pass CI now).

Thanks @Dylan-fa! One of my colleagues will hopefully be able to take a look for you soon so we can get that second approval and then hopefully we'll be good to go 🚀


Blank frequency on map

Blank frequency on map should show unknown

@shawaj This is happening because the field in the spreadsheet is blank, the corresponding column is the output of a couple formatting formulas that displays raw numerical output for use in the google chart/map. I'll see if I can tweak the formula to insert 'unknown' if no frequency is available.


Enchantment Bugs?

Cowardice enchantment Seems to have the effects intended for reckless enchantment doesn’t seem to have any effects at all.

This should be fixed now in the latest beta. A rare vbug there still exists, buty that too is already fixed in latest alpha (alpha's only available to Patreons)


[Only for review purpose] Dev rework layout

Link: http://gofullstack.me:3100/
This is not a fix on the current master HEAD, but is a rework from https://github.com/loklak/loklak_webclient/commit/098f5a38203fbc2a29a96554fc325cc4eb8c9c46 from master 22/06. This branch however, does contain the latest functionality from master HEAD.
The purpose behind this branch is to reproduce the targeted twitter style from current http://test.loklak.net, while also fix home view, and maintain functionality and composition in search & wall view, with minimum and inobstrusive style change.
Developers for search, and wall, and map, can now refer to the style of home view to make  changes accordingly in their own modules.
If this gets a go ahead, prior to this merge, master will be reverted to https://github.com/loklak/loklak_webclient/commit/098f5a38203fbc2a29a96554fc325cc4eb8c9c46 before merge, to avoid compliation in codebase as well as merge conflicts.

This looks good to me for the start. It is possible to mimik the behaviour of the top bar with twitter more closely?

@mariobehling, updated.

@fuksi Looks good to me.More functionalities working now :+1:


[Reflection] Gracefully handle the absence of objc_debug_taggedpointer_ext_* variables.

rdar://problem/48483373

@swift-ci please test and merge

Oops, thanks!

@slavapestov Sure thing. It's so very easy to forget that these things don't exist all the way back.


Feature request : permalinks

For sharing, add a permalink button. most playgrounds do the following:

encode the sources or turn them into Base64
put them in the url as params/hashes

When called

if called with params
decode params
put the sources in place
compile

Thanks :D

That would be a neat feature! If you opened a PR, I would happily merge it. :)

I don't use react a lot (as I saw), if it is something other than React I would help because I don't have any time lately to invest on catching/learning about the latest changes in React API :D, maybe in June or July (studies D:), thx.


updates to binary search

What it says on the tin ^

Closing in favor of #175 with merge conflicts against current tandem-mvp resolved.


Question regarding CompositionPropertySet

Why does CompositionPropertySet have a property called Properties of type CompositionPropertySet?

Hey @ratishphilip,
CompositionPropertySet has this since it is derived from Composition Object which has a property called "properties" which is of type CompositionPropertySet. Note, that in the case where you create a CompositionPropertySet myPropertySet and reference it's "properties" property, we return myPropertySet.

@patsiu Thanks for the reply. I needed the clarification for my CompositionExpressionToolkit which allows the use of lambda expressions to set the Expression value of ExpressionAnimation.


citra and yuzu-ea conflict

Describe the bug
Attempting to install citra (3DS Emulator) and yuzu-ea (Switch Emulator) at the same time is not currently possible without changing the priority of one of the packages.

error: collision between '/nix/store/80nnwn3v1h5rcwkg06h9mgwcc5y8vrc9-yuzu-ea-2945/share/cmake/tsl-robin-map/tsl-robin-mapTargets.cmake'and '/nix/store/zsk1n9q57cg3b3ygd3y7p64h9sakf5m0-citra-nightly-1873/share/cmake/tsl-robin-map/tsl-robin-mapTargets.cmake'

Correct me if I'm wrong, but shouldn't the cmake files not be included in the final output, for either package?
Steps To Reproduce
Steps to reproduce the behavior:

Attempt to install both packages side by side

Expected behavior
They install and work side by side. (They did previously, I'm not sure exactly when that stopped being the case)
Additional context
I'm installing both via Home Manager, but afaik that shouldn't cause any huge issues.
Notify maintainers
Both packages seem to be maintained by the same four people:
 ashley / @kira64xyz
 ivar / @IvarWithoutBones
 joshuafern / @JoshuaFern
 sbruder / @sbruder

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.105, NixOS, 22.11 (Raccoon), 22.11.20230409.48dcbaf`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.1`
 - channels(root): `"nixos"`
 - nixpkgs: `/nix/store/40w1i37kf1s1ljj3a22ngi5b66bsd225-source`

@lasers I take it this is an upstream issue?

@Atemu No idea. I just know they're not there anymore. Maybe this? https://github.com/citra-emu/citra-nightly/commit/9c81dc0dd8bca65722d31670ebe9f937bd97c2cf
Comparing: https://github.com/citra-emu/citra-nightly/compare/nightly-1873...nightly-1880


fix e2e EnvoyShutdown

What type of PR is this?

What this PR does / why we need it:

add test into codecov ignore path
trying to fix #3262 by increasing the HTTPRoute Duration and move load generation after the deployment has been restarted
fix the order of merge-gateways e2e test in makefile

Which issue(s) this PR fixes:

Fixes #3262

/retest

move load generation after the deployment has been restarted

Hi @shawnh2! The purpose of the tests is to run load during the restart and assert that there's no loss of requests... Running it after restart means that we're not really testing for hitless shutdown anymore..

move load generation after the deployment has been restarted

Hi @shawnh2! The purpose of the test is to run load during the restart and assert that there's no loss of requests... Running it after restart means that we're not really testing for hitless shutdown anymore..

Thanks for the clarification, by root causing this e2e test case, sometimes after the restart process, the url that one request send to may be a 404 path, meaning there are some loss requests.
Maybe by sending another request to detect the url path right after the restart process can avoid this situation.

move load generation after the deployment has been restarted

Hi @shawnh2! The purpose of the test is to run load during the restart and assert that there's no loss of requests... Running it after restart means that we're not really testing for hitless shutdown anymore..

Thanks for the clarification, by root causing this e2e test case, sometimes after the restart process, the url that one request send to may be a 404 path, meaning there are some loss requests.
Maybe by sending another request to detect the url path right after the restart process can avoid this situation.

Maybe the upgrade process isn't hitless anymore, I hadn't noticed the 404 issue before, so perhaps that's a new. Maybe worth to workaround it for now ,however, we probably solve the real issue causing requests to 404.

Hi @shawnh2 , @alexwo  - that's interesting input. Yes, I assume that if failures are 404s, then we have a problem with new  envoy proxies receiving traffic before they are programmed.
In that case, I think we can split this activity to two parts:

Run load and log load stats, but only assert on success of converging single-user requests. Basically, only make sure that restarted proxies are eventually functional and stop this test from being flaky.
Investigate how to fix the underlying issue causing 404s.

WDYT?

Hi @shawnh2 , @alexwo - that's interesting input. Yes, I assume that if failures are 404s, then we have a problem with new envoy proxies receiving traffic before they are programmed.
In that case, I think we can split this activity to two parts:

Run load and log load stats, but only assert on success of converging single-user requests. Basically, only make sure that restarted proxies are eventually functional and stop this test from being flaky.
Investigate how to fix the underlying issue causing 404s.

WDYT?

It's also possible that existing proxies may refresh their cache when attempting to obtain a new cache snapshot version from newly started EGs. Maybe something as initialDelaySeconds suggested here can help:
https://github.com/envoyproxy/gateway/issues/2810#issuecomment-1981979019
Or potentially:
https://github.com/envoyproxy/gateway/pull/2918

this test skiped in https://github.com/envoyproxy/gateway/pull/3306, can you remove this SkipTests?

hey @shawnh2 is this PR still needed ?

close this for now, will raise a fix if we have a clue.


[FR] Master Extension On/Off Switch

Hey folks!
I'm unsure if this has already been implemented (waiting on chrome store release) or proposed in issue/discussion, but a master switch to toggle tubemod on/off within the extension UI would be phenomenal.
Going to look into it for a PR when I get some time off uni, but thought I'd at least open this if anyone has any thoughts already (or if it already exists!)
Take care,
C

Hey, @colinhehn !
Sounds like a fun ideia, I might try to do that 😄


Fix post-build hook

"exec" needs to come after the environment variables.

(tested locally with a little script to print $TEST and running TEST=bar exec /tmp/test in /bin/sh)


Differences between semantic-kernel and langchain?

Hello,
Seems like these two projects have a lot in common. What are the definite differences?
Thank you

Hi @SeaDude,
We haven't done a detailed comparison. This space is moving very quickly, and our objective has been to move as fast as possible reacting to feedback and feature asks from devs working in any language.
Thanks!

As far as I know, semantic-kernel do support .Net, which langchain doesn't, that's all.

Overheard from the /Build conference: LangChain is an open-source alternative to Semantic Kernel for AI orchestration alongside other options like Haystack, Hugging Face Agents Transformers. Each AI orchestrator has different strengths and weaknesses. Semantic Kernel's strength is how it interlocks with the many existing and emergent AI Platform components at Microsoft while still enabling completely OPEN access to components outside of the Microsoft stack by design.

If we talk in terms of python, what are the key differences between langchain and semantic kernel?

@priya-27
LangChain has many agents, tools, plugins etc. out of the box.
More over, LangChain has 10x more popularity, so has about 10x more developer activity to improve it.
Semantic Kernel architecture and quality is better, that's quite promising for Semantic Kernel.
https://python.langchain.com/en/latest/modules/agents.html


Elaborate mutable globals?

Hi,
I started reading the Rustonomicon. This is a great read. thx!
https://doc.rust-lang.org/nomicon/references.html

Tragically, plenty of data doesn't reside on the stack, and we must also accommodate this. Globals and thread-locals are simple enough to model as residing at the bottom of the stack (though we must be careful with mutable globals). Data on the heap poses a different problem.

I think I understand well up to this point about paths in the ownership tree, but get lost as to why mutable globals need a special attention.
Can you elaborate this part?
Thx

The short answer is, thread safety. Mutable globals can be mutated by multiple threads, and so are prone to data races.
(I'll leave this ticket open to track making this more clear in the text)

thx Steve. that makes sense.
I did not think of data race or thread safety in reading this part.
So a quick mention would help, I think.


Remove unnecessary inner interface and improve javadoc on local plugin resolution types

The inner Reference type and its implementation seem to be unnecessary.  This PR simplifies the ProjectPublicationRegistry slightly by removing them.

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

I think we should abandon this. It looks like a time sink to figure out how to make this better for local plugin resolution.

OK. Abandoning.


Fanout is not working when having multiple replicas

I have five replicas of a certain microservice on the cloud. I designed the exchange to be fanout and I noticed that these five consumers are attached to the same queue and when sending message to that queue only one of them will consume the message. I also  added the mirroring policy on the exchange from the rabbitmq UI and it still produces the same issue. Here is my configuration
Sender:
            rabbit:
                bindings:
                    ExchangeName:
                        producer:
                            exchangeType: fanout
                            auto-bind-dlq: true

    cloud:
        refresh:
            # https://github.com/spring-cloud/spring-cloud-commons/issues/355
            refreshable: none
        stream:
            bindings:
                ExchangeName:
                    content-type: application/json
                    destination: x.exchange

Consumer:
 stream:
            rabbit:
                bindings:
                    ExchangeName:
                        consumer:
                            auto-bind-dlq: true
                            exchangeType: fanout

            bindings:
                ExchangeName:
                    content-type: application/json
                    destination: x.exchange
                    group: x.queue
                    consumer:
                        max-concurrency: 5
                        max-attempts: 3
                        exchangeType: fanout

Making the exchange fanout makes no difference on the consumer side. If you only have one queue, each message will go to one consumer only.

group: x.queue

You need a different group for each instance; then each one will get its own queue and all messages.

Closing this due to no activity.


[Bug]: Ios resetDatabase crashes the app

Mapbox Implementation
Mapbox
Mapbox Version
default
Platform
iOS
@rnmapbox/maps version
10.0.3
Standalone component to reproduce
await MapboxGL.offlineManager.resetDatabase()

Observed behavior and steps to reproduce
When called, the following error is thrown:

Expected behavior
Function should work without an error.
Notes / preliminary analysis
No response
Additional links and references
No response

It was merged with this PR https://github.com/rnmapbox/maps/commit/565a539f1afe162caa9e2528201a7edb377b2a69 so please try a later 10.0.4 release


Major Table Update: Service Parity, Issue Fixes, and Batch / Transaction error handling updated

This is an update to #1017  by @RunyaoFan .
I have modified the transaction rollback to only backup copies of entities which are changed, rather than the collection.
Performance is significantly better for larger collections.
Tests have been added for the various operation types within a transaction.

Sorry for late response, pretty corrupted these days, checking on this.

Fixes #1216

@edwin-huber, I've tried this branch on the NuGet.Insights repo and found some issues. I was able to write patches for all of the problems which I have included in the issues linked above 👆. I am having trouble getting tests working in your branch but I'd like to contribute PRs including tests if I can get things working. With all of my local changes, all of my NuGet.Insights tests are now passing! Great work on this PR 🥇!

@joelverhagen many thanks for the effort you have put in here and providing solutions to help resolve the issues.
I'm working through them and shall sync with Xiaoning to get the PR merged soon with each of these issues resolved.

Fixes #1282

/azp run


UE scrub of gRPC services

Expand or combine with tutorial doc.

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

ID: 4e072aff-35c1-1fc2-3f94-97dc7a809414
Version Independent ID: 2f05b9da-0d50-ce84-d6af-332da7d9d625
Content: gRPC services with ASP.NET Core
Content Source: aspnetcore/grpc/aspnetcore.md
Product: aspnet-core
GitHub Login: @JunTaoLuo
Microsoft Alias: johluo

@JunTaoLuo - I think I'm going to move all this info into your gRPC tutorial

Fixed in #12522