Get ResourceLimitExceeded error when I start the training session

Hi Gabe,
Thank you for your sample. I try to follow your code but I got this error when I start the training session as below
`
%%time
import time
now = str(int(time.time()))
training_job_name = 'IC-' + dataset_name.replace('_', '-') + '-' + now
image_classifier.fit(inputs=data_channels, job_name=training_job_name, logs=True)
job = image_classifier.latest_training_job
model_path = f"{base_dir}/{job.name}"
print(f"\n\n Finished training! The model is available for download at: {image_classifier.output_path}/{job.name}/output/model.tar.gz")
`
Error show as below

ResourceLimitExceeded: An error occurred (ResourceLimitExceeded) when calling the CreateTrainingJob operation: The account-level service limit 'ml.p3.2xlarge for training job usage' is 0 Instances, with current utilization of 0 Instances and a request delta of 1 Instances. Please contact AWS support to request an increase for this limit.

Do you have any suggestion for this ?

As checked from this https://github.com/awslabs/amazon-sagemaker-examples/issues/307
and follow their instruction by asking support to increase service limit.
This issue is resolved.


Allow usage with atomics as well as wgpu on wasm32

Is your feature request related to a problem? Please describe.
I'd like to move some single threaded heavy work that creates a lot of data into a background thread on wasm, and put a lot of time into preparing to do this with shared memory. At the same time I do render the results of that calculation, and may in the future move some parallelizable work, into webgpu shaders. So I use egui-wgpu. But egui-wgpu depends on wgpu with fragile-send-sync-non-atomic-wasm. This means that its fundamentally incompatible with wasm_thread, wasm-bindgen-rayon and wasm-mt, as well as any other project that wants to use Wasm-Workers with SharedArrayBuffer.
Describe the solution you'd like
Ideally of course the removal of that feature. But some indication why this was required would be helpful already, and perhaps a guess about the difficulty of getting rid of this feature.
If no solution is reached, then a warning in some spot would be very helpful. Someone that uses webgpu could be expected to also want to have shared memory multithreading on the web. Had I known about this beforehand I had not put so much energy into solving other issues around having that kind of multithreading.
Describe alternatives you've considered
Well, getting rid of WebGPU isn't gonna be easy at this point, and likely will also make performance much worse. So IDK.
Additional context
This commit seems to have introduced this feature. Its a merge commit, in that merge, this commit seems to have introduced it. In that case all it did was remove a conditional import of either the concurrent or non-concurrent typemap. I don't know if the gained concurrency was used for something else somewhere else.

I've tested my application with a patched eframe etc, with the relevant changes simply reverted, and it seems to work without issue.
Note that that is on the commit just before switching to wgpu 22.0, as my application is currently stuck at 0.20.1 because of another dependency.

@emilk my suggestion would be to put this behind a default feature flag, to avoid breaking anyone depending on this (unless they use no-default-deatures, but IDK what to do about that). I've not got any issues with the application since I switched to my patched branch. The pipeline is broken in that project, but with it behind a feature flag, that is likely to be fixed. You would not actively test that flag that way, of course, but I guess that'd be my weight to carry.
Would you accept a PR that introduces such a feature and documents it?

@9SMTM6  I looked around a bit to familiarize myself with the story here again and I agree with your rationale & proposal! Putting send/sync egui-wgpu renderer/callbacks behind a feature flag makes perfectly sense me.
Personally, I'd be even leaning towards making it opt-in, but I know that a lot of people are struggling with the Send/Sync restriction and not a lot of folks are actually using atomics on the web so it's probably better to have it opt-out as you propose (i.e. all the same reasons wgpu has fragile-send-sync-non-atomic-wasm in the first place!)

You would not actively test that flag that way, of course, but I guess that'd be my weight to carry.

I think there should be a cargo check job on ci (as part of check_wasm in rust.yml) with the right feature flag combination to ensure that this code path doesn't break at random. I figure that should catch almost all issues that would ensue from the "web-atomics/no-web-atomics variants" :)

Would you accept a PR that introduces such a feature and documents it?

Emil pinged me to have a look at this issue, so you can see this as a yes 😄
Thank you so much for looking into this and willing to contribute your findings back upstream! :)

Personally, I'd be even leaning towards making it opt-in

I've thought a bit about this while creating the actual PR, but I decided to stick with it being on by default.
The original reason, not making a breaking change, doesn't really pull I guess. egui has plenty of breaking changes here and there, thankfully usually easy to solve, as would probably be the case here.
However it being enabled by default in here is better for discoverability, IMO. The default is to have the 'same behavior' on native and web, which makes things easier for normal users, and then when one wants to do multithreading, there is a nice compiler error in wgpu. That should point people to the wgpu flag, and hopefully they will find the respective egui-wgpu flag as well. If the feature is off by default, if people use frame, finding the corresponding flag in egui-wgpu isn't that easy, since you depended on it indirectly, and don't get a compiler error that points you to at least the start of the fix.
To that point, I'm not sure if it might be better to keep the same name as wgpu, or use the IMHO easier to understand name I gave it in my PR. For people that know their way around cargo.toml it should still be easy enough to spot, and I thought this makes it easier to understand for newcomers looking at these flags.

leaning towards using the same name, see pr review


The Edit Listing modal takes too long to load the first time.

The first time the edit listing modal loads it takes a few seconds to appear. It appears that the bottleneck is probably that it's going to the translation file for the display names of hundreds of crypto currencies.
Many of them are missing translations. Not sure if missing ones slow things down more than present ones..?
In either case, here are some potential improvements:

Upon start-up, get the translations in a Web Worker (i.e. a seperate thread), so they will likely already be there by the time the Edit Listing modal (or any other interested party) needs them. A seperate thread should prevent the process from slowing anything else down.
Reconfigure the Edit Listing modal so they are not retrieved  immediately, but only once you start to make a crypto listing. Non-crypto listings should not be slowed down due to data required solely for crypto listings.

fixed via #1585


Scheduling thread can die silently

Steps to reproduce:

Install rufus-scheduler version 3.8.1 (the latest version at present)
Run the following script:require 'rufus-scheduler'

scheduler = Rufus::Scheduler.new
scheduler.every '10s', blocking: true do
  puts 'job triggered'
  t = Thread.current
  Thread.new do
    sleep 1
    t.raise('example exception')
  end
end
scheduler.join

Observed behavior:

The job is triggered only once, then the script hangs forever but the job isn't run again

Desired behavior:

The aborted scheduler thread causes the script to exit
Maybe join raises an exception if the scheduling thread died abnormally?

Workarounds:

Ensure that "example exception" is not raised on the calling thread
Don't use blocking jobs (in the code above only the worker thread will die and the cron will keep firing and spawning new worker threads)

Notes, explanation, and context:
The code that just triggers an exception in the originating thread seems weird but it's a simulation of how the bunny gem (RabbitMQ client) handles some network errors - a new bunny connection creates some listener threads which by default raise an exception in the originating thread when they encounter a network error).  This behavior is configurable, but it also seems like the rufus code is a bit brittle in this regard.
In particular, this code - maybe rejoin should be in an ensure to make sure it always gets called at the end of the thread?  It would also be nice in this case to know from join that the scheduler thread raised an exception.
As a side note, in our current architecture we run rufus as a dedicated process whose only purpose is to schedule jobs.  It seems like the dedicated thread for scheduling jobs is unnecessary in this case?  But rufus doesn't provide an interface for scheduling synchronously on the calling thread.
These changes seem relatively straightforward, if there's buy-in I'm happy to submit a pull request with them.

Hello Thalia,
thanks for your issue report.
Have you had a look at #on_error, you might exit your script from there.

As a side note, in our current architecture we run rufus as a dedicated process whose only purpose is to schedule jobs. It seems like the dedicated thread for scheduling jobs is unnecessary in this case?

If I were in your shoes, I'd probably reduce the script to something like:
require 'fugit'

#CRON = Fugit.parse('every 10s')
CRON = Fugit.parse('*/2 * * * *')

FREQUENCY = [ CRON.rough_frequency / 2, 60 ].min

nt = CRON.next_time

loop do
  n = Time.now
  if n > nt
    p [ n, :doing_the_job ]
    nt = CRON.next_time
  else
    puts '.'
  end
  sleep FREQUENCY
end

on_error seems useful in general but it won't work in this case - the exception is oftenraised while the scheduler thread is sleeping, not while it is currently invoking a job.
I provided a simplified example for reproduction but in reality our scheduler process is handling potentially dozens of cron schedules at once, which is why we're using rufus in the first place.

What version of Ruby are you using?
on ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-openbsd6.7]
the script does exit with return code 1 and outputs:
job triggered
#<Thread:0x00000ce4ae2ee4c0@/home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:630 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
        1: from /home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:638:in `block in start'
/home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:638:in `sleep': example exception (RuntimeError)
Traceback (most recent call last):
        1: from /home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:638:in `block in start'
/home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:638:in `sleep': example exception (RuntimeError)
        3: from thalia.rb:13:in `<main>'
        2: from /home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:148:in `join'
        1: from /home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:599:in `no_time_limit_join'
/home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:599:in `pop': No live threads left. Deadlock? (fatal)
1 threads, 1 sleeps current:0x00000ce48b8c1c00 main thread:0x00000ce4b47d4800
* #<Thread:0x00000ce4a77cc638 sleep_forever>
   rb_thread_t:0x00000ce4b47d4800 native:0x00000ce51369f878 int:0
   /home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:599:in `pop'
   /home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:599:in `no_time_limit_join'
   /home/jmettraux/w/rufus-scheduler/lib/rufus/scheduler.rb:148:in `join'
   thalia.rb:13:in `<main>'

Ah no worries, I see the symptoms you describe on ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-openbsd6.8].

Please tell me if the above change suits your need.
It seems ok when seen from:
require 'rufus-scheduler'

scheduler = Rufus::Scheduler.new
scheduler.every '10s', blocking: true do
  puts 'job triggered'
  t = Thread.current
  Thread.new do
    sleep 1
    t.raise('example exception')
  end
end
def scheduler.on_error(x, y)
  p [ '>>>>', x, y ]
  exit 1
end
scheduler.join

The ruby version thing is an interesting find.  I think in practice we have more threads running so that exception is never hit regardless though (ActiveRecord seems to spawn a thread, Bunny spawns a couple).  I added the following to the top of the script and it's now consistent: Thread.new { sleep }
The change in 3fe5a02 looks reasonable.  Having the whole thing crash in this case would make sense too but I'm not too particular between the two.

Closing. Work moved to gh-337.


Request: Start from "now"

Hi,
I really love your tool and use it a lot!
A feature request of mine would be, to have an option, to start the recording not from the beginning, but from "now" (means with the current fragment).
I would need this feature, because yt-dlp is not able to record 4k livestreams, and doesn't record longer livestreams than 6 hours. I would use this for livestreams, that go for several days.
Would this be possible?
KInd regards

Well, given you gave an actual reason, yeah I guess I can do this.
Just based on the title I was going to say "May as well just use yt-dlp or streamlink" but if they don't support 4k or haven't fixed the 6 hour token refresh issue, then it makes sense to add support starting from the current time to ytarchive.

That'd be amazing.
Here's a 4K livestream to test a bit, it will be going until July 31st:
https://www.youtube.com/watch?v=Sj57a1mP_n0

Any news here? :-)

this feature is badly missing. I dont't need to / want to download the last 5 days of a stream just to grab the last couple of hours

Added by keredau in #198


Add session token to cloudfront invalidation for STS users

Adds sessionToken to the cloudfrontinvalidation auth props so STS users can authenticate successfully. WIthout the session token that accompanies an STS users access and secret key, all auth calls fail.
Return the file that caused uploading to fail for easy debugging
Show error message when cloudfront invalidation fails for easy debugging

Love the plugin! Saves me a ton of time! The code is really clean and concise. I use an IAM role I obtain from STS and need to add the session token for my creds to work.
I tested with an STS cred set WITH a security token, and then with a regular account WITHOUT the security token and verified it does not break backwards.
I tested the error messages as well. Here is sample output from a failed upload
Uploading [                           -------------------------------------------------------------------------] 27% 0.1sError:
failed uplaoding file: /local/home/user/Website/src/Website/build/manifest/manifest.json err: BadRequest: null
at handleErrors (/local/home/user/Website/src/Website/node_modules/webpack-s3-uploader/s3_uploader.js:33:6)
at getAssetFiles.then.then.then.then.catch.e (/local/home/user/Website/src/Website/node_modules/webpack-s3-uploader/s3_uploader.js:92:21)
at run (/local/home/user/Website/src/Website/node_modules/core-js/modules/es6.promise.js:75:22)
at /local/home/user/Website/src/node_modules/core-js/modules/es6.promise.js:92:30
at flush (/local/home/user/Website/src/Website/node_modules/core-js/modules/_microtask.js:18:9)
at process._tickCallback (internal/process/next_tick.js:172:11)
Adding the file name in there saves me a ton of time figuring out which file is causing the failure, and then I can go update my excludes as needed without manually accounting for all my generated files.
What do you think about the changes?

I see 4 tests are failing, all on
Error: S3Plugin-RequiredS3UploadOpts: Bucket
I don't think my changes could have caused this, but I want to check with you to see whats up with the tests.

Hey @infinateone,
Thx for PR. Changes look ok. Only one thing - could you remove the last commit you made? I will bump up version with a tag and publish it to registry.
I need to figure out what is wrong with tests today, so most likely publish will take place within one day.

Cleaned it up. Thanks for getting to this so quick! All of us Cognito users appreciate it!


Extensions: Install Missing Dependencies does not detect dependencies in Extension Development Host

Does this issue occur when all extensions are disabled?: No, but it's in the gray area

VS Code Version: 1.74.3
OS Version: Windows 10 22H2

I've created a stackoverflow question here:
https://stackoverflow.com/questions/75197093/vscode-extension-development-host-does-not-allow-enabling-extension-dependencies
Steps to Reproduce:

Create a VS Code extension where there it will get another extension, example below
await vscode.extensions.getExtension("michaelcurrin.auto-commit-msg"
Place the extension dependency in package.json, example below

  "extensionDependencies": [
    "michaelcurrin.auto-commit-msg"
  ],

Enter the Extension Development Host and attempt to run "Extensions: Install Missing Dependencies" from the Command Palette.
There will be an error saying: There are no missing dependencies to install.

Enabling the extension manually cannot be done because the button will be greyed out, and the Extensions: Enable All Extensions does not do anything either.

Does this issue occur when all extensions are disabled?: No, but it's in the gray area

VS Code Version: 1.74.3
OS Version: Windows 10 22H2

I've created a stackoverflow question here: https://stackoverflow.com/questions/75197093/vscode-extension-development-host-does-not-allow-enabling-extension-dependencies
Steps to Reproduce:

Create a VS Code extension where there it will get another extension, example below
await vscode.extensions.getExtension("michaelcurrin.auto-commit-msg"
Place the extension dependency in package.json, example below

  "extensionDependencies": [
    "michaelcurrin.auto-commit-msg"
  ],

Enter the Extension Development Host and attempt to run "Extensions: Install Missing Dependencies" from the Command Palette.
There will be an error saying: There are no missing dependencies to install.

Enabling the extension manually cannot be done because the button will be greyed out, and the Extensions: Enable All Extensions does not do anything either.

I'm not sure what you are trying to say, you've just repeated my post without any additional information.

Enter the Extension Development Host

After entering Extension Development Host, have you seen any error message?

No, it is just when I run the code which tries to get the extension it will say it can't because the dependency extension is disabled.

No, it is just when I run the code which tries to get the extension it will say it can't because the dependency extension is disabled.

Do you have the dependency extension installed then? May I know how you are running the extension?

I just run it using F5, as specified in the documentation.
I can't install the dependency extension, that is the issue I am having. The enable button is greyed out and the commands Extensions: Enable All Extensions and Extensions: Install Missing Dependencies don't do anything.

May be I am missing something here, can you please provide a gif/video of what you are doing?

Extensions: Install Missing Dependencies (the command) doesn't work in Extension Development Host. You can't enable the extensions you want manually because the button is greyed out.
Here is the video:
https://user-images.githubusercontent.com/118122811/214938890-3feaa5d3-6e92-4666-a7b3-cefca5464052.mp4

It seems all extensions are temporarily disabled in the extension debugging window. Can you please share your debug launch config?

This is the launch config:
"args": [
        "--disable-extensions",
        "--extensionDevelopmentPath=${workspaceFolder}"
],

I am aware that the dependency would be enabled if I removed the --disable-extensions argument but I want only the dependency extension to be enabled and no other extensions to be enabled.
If there is a command-line argument to enable just 1 extension please tell me.

Please use profiles for this scenario - https://code.visualstudio.com/updates/v1_72#_extension-debugging-in-a-clean-environment


#plugin google_maps_flutter

I've been working with the google_maps_flutter and I am having problems using "add marker" and set markers at the same time. Is it possible to place markers onmapcreated? Then to use "markers:" and an if clause to add markers?

@kgdthomas
Your question is better suited for support channels like StackOverflow, so please ask this question there.
Closing from here as this doesn't seem to be a bug or feature request.


Lottie with RN60 swiftShims missing!

Description
[Description of the bug]
After installing lottie react native and lottie ios on RN 0.60.4, I get xcode error
:0: error: module map file '/Users/cloudx91/Desktop/RN/trail/frond/ios/Pods/Headers/Public/Lottie/lottie-ios.modulemap' not found
:0: error: module map file '/Users/cloudx91/Desktop/RN/trail/frond/ios/Pods/Headers/Public/Lottie/lottie-ios.modulemap' not found
:0: error: missing required module 'SwiftShims'
Steps to Reproduce
React-native init App RN60

[First Step]
install react native lottie, and<EMAIL_ADDRESS>
Expected behavior: [What you expected to happen]
Build success
Actual behavior: [What actually happened]
Build fails with error
<unknown>:0: error: module map file '/Users/cloudx91/Desktop/RN/trail/frond/ios/Pods/Headers/Public/Lottie/lottie-ios.modulemap' not found
<unknown>:0: error: module map file '/Users/cloudx91/Desktop/RN/trail/frond/ios/Pods/Headers/Public/Lottie/lottie-ios.modulemap' not found
<unknown>:0: error: missing required module 'SwiftShims'

Versions
You can get this information from executing npm version.

Did you try the suggestions on this stackoverflow thread?
https://stackoverflow.com/questions/41849335/missing-required-module-swiftshims-error-generated-by-xcode-in-project

We ran into this problem as well.
Tried "everything" mentioned in various stack overflow posts but could not get it to work ...
If anyone has a solution to this please share.
Thanks in advance.

npm i
cd ios
pod install
open terminal
cd ~/Library/Developer/Xcode/DerivedData
rm -rf Build/* see below if you have a customized build location
rm -rf ModuleCache/*
8 Close a terminal app
Open xcworkspace
Buld app

Worked with my project.

Seems we ran into this little f%&/%/ https://github.com/airbnb/lottie-ios/issues/859
"lottie-ios": "3.0.3",
"lottie-react-native": "3.1.0",
Used 1.7.0 upgraded to 1.7.5 and we got the Lottie folder etc.

@nirre7 thanks it worked

I try all written above and now got error:
Module map file '/Users/${user}/Library/Developer/Xcode/DerivedData/Klarna-bbrrptwofrjhjvfuwxsyuzflzjxo/Build/Products/Debug-iphonesimulator/lottie-ios-iOS10.3/Lottie.modulemap' not found

Module map file '/Users/${user}/Library/Developer/Xcode/DerivedData/Klarna-bbrrptwofrjhjvfuwxsyuzflzjxo/Build/Products/Debug-iphonesimulator/lottie-ios-iOS10.3/Lottie.modulemap' not found

Underlying Objective-C module 'lottie_react_native' not found

/Users/${user}/projects/company-app/clients/node_modules/lottie-react-native/src/ios/LottieReactNative/AnimationViewManagerModule.swift:5:8: Cannot load underlying module for 'Lottie'

@lorenc-tomasz Which XCode version should we use?

Followed this approach: https://stackoverflow.com/a/56176956/3863146
Basically add a dummy swift file and then at last go to Build Settings -> Always embed swift standard libraries, make it Yes.
I am using XCode 10.1.

Execute the following on your terminal to get the latest stable version:
sudo gem install cocoapods
Add --pre to get the latest pre release:
sudo gem install cocoapods --pre

This library is difficult to install
:0: error: module map file '/xxxxxxxxxxxxx/ios/Pods/Headers/Public/Lottie/lottie-ios.modulemap' not found
:0: error: module map file '/xxxxxxxxxxxxx/ios/Pods/Headers/Public/Lottie/lottie-ios.modulemap' not found
:0: error: missing required module 'SwiftShims'

@OleksandrKucherenko Did adding use_frameworks! solve your issue?

@OleksandrKucherenko Did adding use_frameworks! solve your issue?

thanks @a-c-sreedhar-reddy use_frameworks! works for me 🎉
this are the versions of my project:

COCOAPODS: 1.8.4
"react-native": "0.61.5"
"lottie-ios": "3.1.3"
"lottie-react-native": "3.3.2"

@OleksandrKucherenko you saved my week 🙌

I'm closing this as a version update should solve this issue.


Aragorn not talking to ICEES DILI

https://arax.ncats.io/?source=ARS&id=0cdc5dab-49ba-4a3d-9688-8f36f95b964d

Still true after new strider deployment

query:
{
  "edges": {
    "e0": {
      "object": "n1",
      "predicates": [
        "biolink:correlated_with"
      ],
      "subject": "n0"
    }
  },
  "nodes": {
    "n0": {
      "ids": [
        "MONDO:0005359"
      ],
      "is_set": false,
      "name": "drug-induced liver injury"
    },
    "n1": {
      "categories": [
        "biolink:DiseaseOrPhenotypicFeature"
      ],
      "is_set": false,
      "name": "Disease Or Phenotypic Feature"
    }
  }
}

Now fixed.


how to register users

I would like to register users  preferably using http api is there support for this...and do u provide disk persistence for username and password
thanks

etc/emqttd.config

 {auth, [
            %% Authentication with username, password
            {username, []},

Cli

#add user, and store in mnesia database
./bin/emqttd_ctl  useradd

在 2015年8月6日，下午6:56，yon86<EMAIL_ADDRESS>写道：
I would like to register users preferably using http api is there support for this...and do u provide disk persistence for username and password
thanks
—
Reply to this email directly or view it on GitHub https://github.com/emqtt/emqttd/issues/229.

@yon86, this issue has been moved to emqttd_dashboard project.


Cron configuration overwrites default post-start hooks

When using the example below, my post-start hooks from my config.yml is overwritten by the ones from https://github.com/drud/ddev-contrib/blob/master/recipes/cronjob/config.cron.yml
I expected these to be usable in parallel.
If I add the ones from config.cron.yml to my config.yml there are all executed as expected.
Did I overlook something in the configuration?

To see what the merged hooks look like, use ddev debug configyaml
My experience is the same as yours - the add-on config.*.yaml overwrites the post-start hook. I guess it's not unexpected. Somebody has to win probably.  The entire post-start section is won by the addon. If you had a post-stop or pre-something, those don't conflict and get merged as expected.
(It's not clear what "the example below" is, but the behavior is as you describe)

With the example below, I meant the link.
But you description matched my case.  I would have expected them to be merged though.
Thanks for your reply. I can accept having them in the default config.yml no big deal , it's not like it's a lot of extra lines.

You can also include in your config.cron.yaml (or whatever) all the hooks you want, and it will work out fine. Sounds like you have a way to go with it.

Thanks. Found a solution that worked out for me.


Keywords in keywords.json should be case insensitive

As people may be using keywords.json to compare with the card data, the keywords should all be lowercase to emphasize that the keywords don’t always have capitalization (like flying or investigate).

Looking for additional feedback before considering a change on this

I would agree.. the uppercase can always be applied via CSS on the consuming app


init() got an unexpected keyword argument 'logits_processors'

Why does this parameter appear to be missing during operation?

Closing this issue as stale as there has been no discussion in the past 3 months.
If you are still experiencing the issue you describe, feel free to re-open this issue.


Improve keyboard accessibility

Type: Feature Request
It seems there is no way at all to switch between the sidebar accordions using keyboard. Why? It seems like an obvious feature and serious hindrance with regards to keyboard navigation instead of forcible switching using a pointer device every time we need to switch between the subviews. Basically, things like these basic ommisions render pure keyboard control and navigation in VSCode impossible which is surprising given the amount of control we have over all settings and keyboard shortcuts otherwise. Please improve this asap
VS Code version: Code 1.87.1 (1e790d77f81672c49be070e04474901747115651, 2024-03-06T00:21:36.258Z)
OS version: Windows_NT x64 10.0.19045
Modes:

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.2. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

I mean the sub-sections in the sidebar.

Works for me using tab/shift-tab or up-down arrow keys to move focus and return or space to select.
https://github.com/microsoft/vscode/assets/191085/4ffca784-e8c0-4ed1-9a43-4de1d436f5c7

@grgar Okay, now try to actually focus on individual accordions and tab into them over all of the jumps you have to make to pass all the icons and buttons present in various sections. Then imagine doing that every time you just want to interact with content in the section of interest and switching focus between editor and different sidebar panels - thanks for the effort but this is not really a viable solution due to the multitude of switching and tabbing involved in most cases. If there was a way to just move across the accordions with no need to jump over all the icons and buttons before actually arriving at the content of the subsection then that would be a proper solution - until then this is a very impractical solution only usable in an emergency, not at all for regular daily interaction. I would suggest finding a way to distinguish between the desire to merely shift between the tabs and skipping all the intermediate elements along the way or the alternative (different hotkeys?).

I propose CTRL+DOWN arrow like it works in the Search section to move focus to the search results similarly. Overall the hotkeys for navigation within the sidebar are and not unified and working in different ways in different panels which is really confusing and eventually leads to having to use a pointer instead to avoid the confusion altogether. There is just too many things, icons, buttons in the way and every time the interactions work in different ways in each panel. IMHO this needs some serious improvement and unification / cleanup. Did I miss anything? Is there a way to interact with just the subsections and navigate between them without having to deal with all the extra distractions and elements along the way?

Now, we need something similar for interaction with the accordions outside the actual subsection contents.

@cybairfly Can you pls simplify your request? It's not clear to me how this is working any differently from the search/ SCM views.

I propose CTRL+DOWN arrow
IE what are you proposing this would do in this context?

Keyboard navigation between accordions in the sidebar is not straight-forward because there is too much noise along the way, buttons, dropdowns, etc. We need a clear path to switching between the inner panels - I proposed CTRL+DOWN for the outside, since it already works this way inside of the panels (e.g. shift focus from commit input to commit tree or from search input to the search results). Similarly, it could be used to shift focus from the accordion headers to the inner contents. Currently, only tab can be used works but due to the clutter along the way, it is clumsy.

@isidorn do you have context here or know who might have some?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Added a progress parameter to the reactive providers

This pull requests adds a progress parameter to the reactive providers to track progress changes of upload & download tasks. Currently it's impossible to track these changes and to use the same Moya provider for download & upload tasks.

SwiftLint found issues
Warnings

File
Line
Reason

RxMoyaProvider.swift
24
Opening braces should be preceded by a single space and on the same line as the declaration.

  Generated by :no_entry_sign: danger

Ah indeed, I've fixed that. Also updated for the SwiftLint issue.

Two tests seem to be failing:
a_subsclassed_reactive_provider_that_tracks_cancellation_with_delayed_stubs__cancels_network_request_when_subscription_is_cancelled, expected to be true, got <false>

provider_with_SignalProducer__a_subsclassed_reactive_provider_that_tracks_cancellation_with_delayed_stubs__cancels_network_request_when_subscription_is_cancelled, expected to be true, got <false>

Hmm, you're right. It's strange though, as it's executing exactly the same request method, only with the progress parameter added.
I'll look into it further tomorrow!

Ok, I've fixed the tests, everything seems to be OK now. The only thing I want to discuss here, is that another solution is already available for progress tracking:
func requestWithProgress(token: Target) -> SignalProducer<ProgressResponse, MoyaError>

However, this doesn't really fit in our JSON parsing functionalities and needs some more code to write on our side to make it easy to track progress.
With this pull request we're introducing another way of tracking progress, which is quite more easy to use and feels simpler.
How do you guys think about this?

The implementation in the PR makes sense to me.

I am all for any suggestions to make the progress handling more straight forward in the reactive providers. However, I am not sure this is the right direction to take. A goal of the observer pattern is to replace the callback pattern. So, to have our reactive providers use elements of both the observer pattern and the callback pattern seems muddled to me. This would encourage the propagation of both observables and callbacks in the users' code.
Perhaps we could refine the current approach with ProgressResponse? Instead of it being a struct with a Response? and a Progress?, it could be:
enum ProgressResponse {
  case progress(double)
  case response(response)
}

That would simplify handling of progress/response emissions. In fact, we could go further and provide reactive operators like onlyProgress() and onlyResponse() that could flatmap the Observable<ProgressResponse> into a Observable<Double> and Observable<Response>, respectively. This would go further to support separating the flow of progress and response without needing to introduce inconsistent patterns.

We already have a ProgressResponse
public struct ProgressResponse {
    public let response: Response?
    public let progressObject: Progress?

    public init(progress: Progress? = nil, response: Response? = nil) {
        self.progressObject = progress
        self.response = response
    }

    public var progress: Double {
        return progressObject?.fractionCompleted ?? 1.0
    }

    public var completed: Bool {
        return progress == 1.0 && response != nil
    }
}

a method called requestWithProgress for both reactive extensions and two Observable operators to filter progress and response.
extension ObservableType where E == ProgressResponse {
    /**
     Filter completed progress response and maps to actual response
     - returns: response associated with ProgressResponse object
     */
    public func filterCompleted() -> Observable<Response> {
        return self
            .filter { $0.completed }
            .flatMap { progress -> Observable<Response> in
                // Just a formatlity to satisfy the compiler (completed progresses have responses).
                switch progress.response {
                case .some(let response): return .just(response)
                case .none: return .empty()
                }
            }
    }

    /**
     Filter progress events of current ProgressResponse
     - returns: observable of progress events
     */
    public func filterProgress() -> Observable<Double> {
        return self.filter { !$0.completed }.map { $0.progress }
    }
}

I don't think this PR will add anything that our current implementation is not handling.

Oops @leoneparise. I totally missed that we had the filterCompleted() and filterProgress() operators already. Thanks for pointing that out! I'm not sure the naming is unambiguous though (e.g. RxOptional's filterNil() takes optionals out of the observable, we follow the opposite semantics).

No problem @scottrhoyt! Yeah, we can change the method names like progress and response to be more readable. But, in my head, this PR only adds complexity. A progress closure inside a observable? I can't agree with that.

Good discussion, I agree with the above. We'll look further into implementing it using the suggested methods. Thanks!


Does not compile on latest commit

neovim-gtk [master] rustc --version
rustc 1.25.0
neovim-gtk [master] cargo --version
cargo 0.26.0
neovim-gtk [master]

Ahh this is awkward. That was meant for a different repo. Sorry.


Out of Memory while using HTreeMap to populate a List

I am trying to use HTreeMap from mapDB to populate a List of million entries in a CSV file, but every time I insert data into the List, the previous entry is overwritten for the HTreeMap.
The only way to avoid overwriting an HTreeMap in the final List of values is to create another DB connection of a hashmap, but with this solution, there is an exception of Java Heap Size.
Is there a subtle way to use HTreeMap in reading a million plus records and adding it to a List without duplicating the data? My code is as below...
public GapList<HTreeMap<String, Object>> fn_ReadCSV_GapListHTMap(File fileCSV) {

   BufferedReader bfrdrCSVReader = null;
   String strLine = "";
  String[] arrHeaders;

  //Gaplist is used for collecting the data read as map from the CSV.
  GapList<HTreeMap<String, Object>> glhtmapReadCSV = new GapList<>();
  try {

   bfrdrCSVReader = new BufferedReader(new FileReader(fileCSV));

   //reading header for the .csv file, which by default is the first line of file.
   String headerLine = bfrdrCSVReader.readLine();
   arrHeaders = headerLine.split(",");

   //using mapDB to read voluminous data from the CSV which is in tunes of a million.
    DB dbReadCSV = DBMaker.memoryDB().closeOnJvmShutdown().make();

    HTreeMap<String, Object> htmapLineData = (HTreeMap<String, Object>) dbReadCSV.hashMap("htmapLineData").keySerializer(Serializer.STRING).expireMaxSize(25).createOrOpen();

   //read each line of the .csv file.
   while((strLine = bfrdrCSVReader.readLine()) != null) {

       //intCSVLine ++;
       String[] arrTokens = strLine.split(",",-1);

       //When I used hashmap, I reset it here after adding the read data to
       //the list, but this type of behavior can't be done for HTreeMap.
       //Map<String, Object> mapLineData = new HashMap<>();

        //as stated in the problem statement, one needs to create new instance of DB
        //such that the new HTreeMap initialized later points to new memory location
        //and when finally added to the list, doesn't duplicate the data in the list.
        dbReadCSV = DBMaker.memoryDB().closeOnJvmShutdown().make();

        HTreeMap<String, Object> htmapLineData = (HTreeMap<String, Object>) dbReadCSV.hashMap("htmapLineData").keySerializer(Serializer.STRING).expireMaxSize(25).createOrOpen();

       for(int intLineNum = 0; intLineNum < arrHeaders.length; intLineNum++) {

           //based on the header read, read each value for that header & add to the map.
           htmapLineData.put(arrHeaders[intLineNum].trim(), arrTokens[intLineNum].trim());
       }
       //once a map for a line read is created, add it to the final list of entries.
       glhtmapReadCSV.add(htmapLineData);

       //The below code creates an issue wherein the entire DB connection is closed
       //and the error states it to be "com.sun.jdi.InvocationException occurred invoking method."
       //resulting into a corrupt list of data.

       //closing the DBMaker to enable refreshing of the HTreeMap.
       //dbReadCSV.close();
   }

   bfrdrCSVReader.close();
   }
   catch(Exception exceptionCSVReader) {

   StringWriter stack = new StringWriter();
   exceptionCSVReader.printStackTrace(new PrintWriter(stack));
   log.debug("DEBUG: The exception while reading CSV file is: "+stack);
   assertTrue(false, "ERROR: CSV file can't be read; hence exiting with exception !");
   }

   return glhtmapReadCSV;
}

@jankotek , can you please put some light to this behavior ? As in a subtle way to reset the HTreeMap w/o closing or re-initializing the DBMaker ?

@jankotek  any update on this behavior ?


Tag renaming broke old builds

I'm a downstream dependent on this repository. At some point in the past - and I suspect within the last couple days - all of the version tags in this repository were renamed from an older "X.Y.Z" style to a newer "vX.Y.Z" style.
This had the effect of breaking the build of older versions, at least the commit for 1.4.0 that I have pinned as a submodule. I get CMake configure output like:
-- The C compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- stlink version: v1.4.0
--           Major  Minor  Patch
...
CMake Error at CMakeLists.txt:104 (set_target_properties):
  set_target_properties called with incorrect number of arguments.

-- Manpage generation disabled
-- Debian-based Linux OS detected
-- Configuring incomplete, errors occurred!
See also "${MYSANDBOX}/external/stlink/build/Debug/CMakeFiles/CMakeOutput.log".
See also "${MYSANDBOX}/external/stlink/build/Debug/CMakeFiles/CMakeError.log".

Note how the stlink version extraction did not match any version numbers.
Can you please rename older tags back to the older format, or add duplicates with the old name? I've forked for the time-being so that I can add the tag myself as necessary.

A note: Now that I've gotten my fork up, I've found that I need the renamed tag to be deleted in order for the build to not be broken by the new v1.4.0 tag and to be able to find the 1.4.0 tag.

Well, I decided to just update to point at the latest release, since I would have had to fix the CMake version script in order to tolerate CI clones that had leftover tag refs anyway.


Update to 6.2.5

It seems that the latest version now is 6.2.5

I am no longer maintaining this snap, please check out https://github.com/snapcrafters/postman
At the moment all it would take to update is rebuilding the snap and reuploading it.

OK, so they also need to modify the contact in the snap, because it's still pointing here.
Thanks!


For command lines options, we now follow a simpler subclassing.

We now work with instances, not classes. It allows for more flexibility when defining command lines options. I believe it's more intuitive overall.

Coverage increased (+0.004%) to 85.31% when pulling e5099fd7f509c61b3e364a4e10e2185f211c8b43 on gabrieldemarmiesse:simpler_options into d3fe102ff5e0dbe12e4b1735ec391f63e2ce7fb7 on IDSIA:master.

Looks good in principle. It seems like the original approach tried to emulate a singleton per command line option, which is valid as well but seems unnecessarily complicated without yielding any real benefits. However, similar to #567 this seems to break a user facing API. So we need to think about how we would like to change the API and then go through a deprecation cycle.

I'll work on a solution to transition cleanly. That's quite challenging actually.

Closing as it won't be merged in this form.


Update UserGuide.md with correct clear command in summary table

resolves #185
Summary table still shows clearp instead of clear for the command input, changed it to clear

Codecov Report

Merging #229 (3e5203e) into master (7e5408a) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #229   +/-   ##
=========================================
  Coverage     67.02%   67.02%
  Complexity      688      688
=========================================
  Files           122      122
  Lines          2311     2311
  Branches        280      280
=========================================
  Hits           1549     1549
  Misses          636      636
  Partials        126      126

Impacted Files
Coverage Δ

...in/java/seedu/address/model/order/DateChecker.java
75.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Adding button for fastly add estimated time

Hello,
It's possible to add button for fastly add time like 15min,30min,45min,1hours and make this incremental when we click two time to 1hours adding 2 hours
Thanks.

Hi @aytirix5,
That is a good idea. What I'm thinking is when timer is running we could add a few extra buttons to fast-forward or back-track the time with these intervals. The challenge is that Activity timer doesn't just increment, but we physically store the start time of the tracking. So in order to shift the time we will need to shift the start time, which is OK.
Keen to hear your thoughts on the above.


bug: cannot use module on linux due to too long file names

Too long file names in repository.
Description
On linux: go get or git clone cannot use 'github.com/consensys/gnark-crypto' due to unzip not able to handle too long file names.
Expected Behavior
git clone or go mod tidy can download and unzip the repository
Actual Behavior

git clone git@github.com:Consensys/gnark-crypto.git
Cloning into 'gnark-crypto'...
remote: Enumerating objects: 70877, done.
remote: Counting objects: 100% (19537/19537), done.
remote: Compressing objects: 100% (2695/2695), done.
remote: Total 70877 (delta 17573), reused 17767 (delta 16669), pack-reused 51340 (from 1)
Receiving objects: 100% (70877/70877), 35.89 MiB | 13.81 MiB/s, done.
Resolving deltas: 100% (56461/56461), done.
error: unable to create file internal/generator/addchain/1eed5b76b77315c55824fc3c6ad19eb92f19a5f5859d13f7e464428aa2c74d998d5ce788548db3d6059025d409f55414fd63967a0dcc8dc5259a2bdb6c8d4a860554784b1bcfbda16d0bd0d0a49d80678fcc7f0d0: File name too long
error: unable to create file internal/generator/addchain/24cc67981e6bec7f8342e9e03ae556b51f9b18ebaf3a58e9cb2ed35b377b45f02a54d81f5bd492171b53ebd07eaf892fc1d10a1db7b480faf6b9cf57073844a7a6d37a6228fee79ae922dd48ae0001: File name too long
error: unable to create file internal/generator/addchain/48ba093ee0f382b461f250013ebfcfae49861aa07451a214a09d7be021ef905c1ee98e39613a4640f3aebfc96d08c121a2723b44be7f641c7734f71cfaffcba62845b09599ea3e05833e2bbabc290df9a44f9a1c000020bd27400000000023: File name too long
error: unable to create file internal/generator/addchain/7bb56ddaddcc57156093f0f1ab467ae4bc6697d616744fdf91910a2a8b1d366635739e215236cf581640975027d55053f58e59e8373237149668af6db2352a181551e12c6f3ef685b42f43429276019e3f31fc34200000000000000000000: File name too long
error: unable to create file internal/generator/addchain/9174127dc1e70568c3e4a0027d7f9f5c930c3540e8a34429413af7c043df20b83dd31c72c2748c81e75d7f92da11824344e476897cfec838ee69ee39f5ff974c508b612b33d47c0b067c577578521bf3489f34380000417a4e800000000045: File name too long
error: unable to create file internal/generator/addchain/93319e6079afb1fe0d0ba780eb955ad47e6c63aebce963a72cbb4d6cdded17c0a953607d6f52485c6d4faf41fabe24bf07442876ded203ebdae73d5c1ce1129e9b4de988a3fb9e6ba48b7522b80006: File name too long
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

Possible Fix
Use shorter file names.
Steps to Reproduce
Use git clone git@github.com:consensys/gnark-crypto.git on linux.
Context
I was originally trying to use 'go mod tidy' in my repo:
go mod tidy

go: finding module for package github.com/consensys/gnark-crypto/ecc/bn254
-> unzip<EMAIL_ADDRESS>open<EMAIL_ADDRESS>file name too long

Your Environment
Linux  5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
git version 2.34.1
go version go1.23.2 linux/amd64
gnark-crypto v0.12.0 or v0.14.0

Hey -- I suspect that's a issue not related to this repo; we (and other projects importing gnark-crypto) use Linux/Ubuntu in various settings with no problem on that front.
Couldn't reproduce on a clean AWS machine.

Can you also provide unzip -v? I think that for example when running in a Alpine image you may be using busybox version of unzip.

Hmm - this has also appeared before - see https://github.com/golang/go/issues/58915. And indeed in some cases the full filename (e.g. in the current report<EMAIL_ADDRESS>has 261 characters) is bigger than 256. Generally the name limit is 256, but path limit is usually bigger. What does getconf PATH_MAX / say?

Hmm - this has also appeared before - see golang/go#58915. And indeed in some cases the full filename (e.g. in the current report<EMAIL_ADDRESS>has 261 characters) is bigger than 256. Generally the name limit is 256, but path limit is usually bigger. What does getconf PATH_MAX / say?

There is also indication that the user used eCryptfs - are you also by any chance using it? In that case, have a look at the mitigation there (setting GOMODCACHE env variable to a location outside of the encrypted filesystem)

Closing for now, seems to be a filesystem issue.

Indeed my GOMODCACHE env variable points to an ecryptfs folder. This is where the limit comes from. Thanks a lot!


Change the argument of the Proposing script purpose to `ProposalPro…

Closes #5709

Superseded by #5712


Ember addon stubbing issues

Collecting related issues in this GH issue since I think they might all gravitate around a similar solution:
This repo injects a fake POJO Addon into Ember's build pipline during corber s to mix into platform-specific cordova.js/cordova_plugins.js into the app's JS payload. I've run into a few problems with this approach:

ember-intl searches through all addons for translation files, but barfs at this line because it's expecting more than just the treeFor property on the "addon". I ended up having to fork corber and add a few more stubbed properties just to get it to compile:

...

        return pluginsTree;
      },
      pkg: {
        "ember-addon": {}
      },
      root: "nonexistent",
      name: "stubbed-corber-live-reload-injected-plugin",
      addons: []
    });

Minor point but something I got stuck on for longer than I care to admit: me and my team missed the memo about the defaults pojo that's passed to ember-cli-build that is expected to be passed to the EmberApp that's returned from the fn, and corber is the first addon we've run into that broke due to us omitting that. Specifically, the project that corber clones is ultimately passed in as part of the defaults, so if you don't use defaults, the corber s won't ever call the treeFor hook.

treeFor might be called multiple times, passing in a different "treeName" arg that it wants; in my app, this fn gets called 3 times w the following respective args: "app", "templates", "vendor". Because the cordova/cordova_plugins code was being included in our codebase in 3 different places, it was causing errors where "window.cordova is already defined". I added (to my fork) a conditional check to make return null unless treeName === 'app'. I also just tried defining treeForVendor at one point but it wasn't getting called (there might be some internal ember-cli logic that checks/expects treeFor to be defined.

Conclusion
Not sure, but likely need to find something less stubby/hacky that involves real EmberAddon objects and follows the happy path a bit better.

@machty I ran into the same ember-intl myself. @alexblom any chance we can get his fix merged in if there's a PR?

Fixed in 1.3.0


Bluetooth: Mesh: Mesh Settings commit should after BT

Mesh Settings Commit should after BT.
settings_handler_static_area
                0x0000000000034644      0x168
                0x0000000000034644                _settings_handler_static_list_start = .
 *(SORT_BY_NAME(SORT_BY_ALIGNMENT(._settings_handler_static.static.*)))
 ._settings_handler_static.static.settings_handler__0_bt_
                0x0000000000034644       0x14 zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a(settings.c.obj)
                0x0000000000034644                settings_handler__0_bt
 ._settings_handler_static.static.settings_handler__1_sc_
                0x0000000000034658       0x14 zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a(gatt.c.obj)
                0x0000000000034658                settings_handler__1_sc
 ._settings_handler_static.static.settings_handler__2_bt_mesh_
                0x000000000003466c       0x14 zephyr/subsys/bluetooth/mesh/libsubsys__bluetooth__mesh.a(settings.c.obj)
                0x000000000003466c                settings_handler__2_bt_mesh
 ._settings_handler_static.static.settings_handler_bt_ccc_

I don't exactly understand what is being targeted here. It seems you need some kind of order in the processing of settings? When loading settings they will come in the order they are found on storage, there is no ordering here.

I don't exactly understand what is being targeted here. It seems you need some kind of order in the processing of settings? When loading settings they will come in the order they are found on storage, there is no ordering here.

This solves the mesh stack (and actually any module) dependency on the host being able to register a GATT service:
https://github.com/zephyrproject-rtos/zephyr/blob/4793e00ae803ae6b7948e4c110f7ceef11821ef5/subsys/bluetooth/host/gatt.c#L1737-L1742
which (the GATT service registration) is not allowed until sc_commit sets SC_LOAD flag.
Which in turns requires the mesh stack (which is removed in this PR) to re-schedule an additional delayable work item to try register GATT service over and over again until sc_commit in subsys/bluetooth/host/gatt.c is called.
So it is not about loading. But as @LingaoM said it is about order of h_commit calls for Bluetooth subsystem.

I don't exactly understand what is being targeted here. It seems you need some kind of order in the processing of settings? When loading settings they will come in the order they are found on storage, there is no ordering here.

This solves the mesh stack (and actually any module) dependency on the host being able to register a GATT service:
https://github.com/zephyrproject-rtos/zephyr/blob/4793e00ae803ae6b7948e4c110f7ceef11821ef5/subsys/bluetooth/host/gatt.c#L1737-L1742
which (the GATT service registration) is not allowed until sc_commit sets SC_LOAD flag. Which in turns requires the mesh stack (which is removed in this PR) to re-schedule an additional delayable work item to try register GATT service over and over again until sc_commit in subsys/bluetooth/host/gatt.c is called.
So it is not about loading. But as @LingaoM said it is about order of h_commit calls for Bluetooth subsystem.

Isn't this question of subtree loading sequence? This is sample how I solved the same issue for bsim tests when it emulates secure storage:
https://github.com/zephyrproject-rtos/zephyr/commit/8a51176877c9b74e286303a452c3b5d316d90e96#diff-a075de11be69d631fe1e1944a1782d1c7665a6f8b2ae02be1e355e1de2682562R257-R262

I don't exactly understand what is being targeted here. It seems you need some kind of order in the processing of settings? When loading settings they will come in the order they are found on storage, there is no ordering here.

This solves the mesh stack (and actually any module) dependency on the host being able to register a GATT service:
https://github.com/zephyrproject-rtos/zephyr/blob/4793e00ae803ae6b7948e4c110f7ceef11821ef5/subsys/bluetooth/host/gatt.c#L1737-L1742
which (the GATT service registration) is not allowed until sc_commit sets SC_LOAD flag. Which in turns requires the mesh stack (which is removed in this PR) to re-schedule an additional delayable work item to try register GATT service over and over again until sc_commit in subsys/bluetooth/host/gatt.c is called.
So it is not about loading. But as @LingaoM said it is about order of h_commit calls for Bluetooth subsystem.

Isn't this question of subtree loading sequence? This is sample how I solved the same issue for bsim tests when it emulates secure storage:
https://github.com/zephyrproject-rtos/zephyr/commit/8a51176877c9b74e286303a452c3b5d316d90e96#diff-a075de11be69d631fe1e1944a1782d1c7665a6f8b2ae02be1e355e1de2682562R257-R262

The suggestion from this commit requires changing all existing applications. Moreover, it brings internal information (subtree paths) to the applications. Also it does not allow the use of settings_load().
This PR does not require any changes in the existing apps.

Isn't this question of subtree loading sequence?

No, loading order doesn't matter. Service registration happens in the commit phase (when h_commit is called).

h_commit

I do not think you are right. Please take a look:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/settings/src/settings_store.c#L60
@Laczen, I guess, it is still possible to solve by slightly modifying subtree_load function for bluetooth purposes. When it goes over subtrees in loop, it will ignore bluetooth related subtrees and load them separately in predefined order.
@PavelVPV, it will not require changing samples, applications etc just settings.c. It will be still possible to use settings_load() as is.

OK, the proposal with bt_init_levels also handles the order of h_commit calls. It seems fragile to depend on alphabetical ordering of linker sections (and that static handlers are processed before dynamic handlers).

The order is guaranteed by ITERABLE_SECTION_ROM macro:
https://github.com/zephyrproject-rtos/zephyr/blob/main/include%2Fzephyr%2Flinker%2Fiterable_sections.h#L38-L51

OK, the proposal with bt_init_levels also handles the order of h_commit calls. It seems fragile to depend on alphabetical ordering of linker sections (and that static handlers are processed before dynamic handlers).

The order is guaranteed by ITERABLE_SECTION_ROM macro: https://github.com/zephyrproject-rtos/zephyr/blob/main/include%2Fzephyr%2Flinker%2Fiterable_sections.h#L38-L51

Order is guaranteed by this loop first of all:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/settings/src/settings_store.c#L57-L59

Order of loading and commitment is related to each other.

This PR is not about that, but about the order of h_commit calls.

Order of loading and commitment is related to each other.

This PR is not about that, but about the order of h_commit calls.

Probably this is my fault since I cannot deliver idea about that the order of h_commit depends on order of loaded subtrees.
Even this PR confirms it. It just sorts subtrees in alphabetical order that impacts on order of loading and as consequence on order of h_commit calls.

@PavelVPV, maybe we can put the return value of the h_commit into use and restart the commit loop if an ECANCELED is returned. We should of course limit the amount of restarts.

@PavelVPV, maybe we can put the return value of the h_commit into use and restart the commit loop if an ECANCELED is returned. We should of course limit the amount of restarts.

Making an assumption in the mesh stack that the host didn't allow registering a GATT service because probably it didn't complete its initialization is complicated and risky. We can't rollback what the mesh stack already initialized. The host doesn't also differentiate this error with other errors and returns -EINVAL (gatt_register also returns -EINVAL).

@PavelVPV, maybe we can put the return value of the h_commit into use and restart the commit loop if an ECANCELED is returned. We should of course limit the amount of restarts.

Since this is a bluetooth subsystem specific issue, the last commit with BT_SETTINGS_PRIO_BT and BT_SETTINGS_PRIO_AFT_BT looks good to me.

We can document in settings that static settings handlers are commited in the alphabetical order since settings uses ITERABLE_SECTION_ROM macro which guarantees the order.

We can document in settings that static settings handlers are commited in the alphabetical order since settings uses ITERABLE_SECTION_ROM macro which guarantees the order.

https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/linker/iterable_sections.h#L17
Following byte order is already the default behavior of the system.

@LingaoM, @PavelVPV, I think that what is proposed here could be added and will solve the problem you are facing.
However I think it is a sign of a more general problem that appears in settings. Sometimes commits cannot be handled directly and some commit should be postponed. This is solvable by the technique proposed when it appears in a subsystem but cannot be handled if there is a "dependency" between multiple subsystems.
Therefore it would be good if the settings subsystem would either restart the commit list or a "unhandled" commit list is created that will be handled in a second stage. This could be updated and (boundedly) restarted.
I would go for the presently proposed solution but create an issue that the settings system needs to be modified to handle the more general problem.

We can document in settings that static settings handlers are commited in the alphabetical order since settings uses ITERABLE_SECTION_ROM macro which guarantees the order.

Until it is not documented and well described in public settings API this PR is implementation based on internal implementation third subsytem.

@LingaoM, @PavelVPV, I think that what is proposed here could be added and will solve the problem you are facing.
However I think it is a sign of a more general problem that appears in settings. Sometimes commits cannot be handled directly and some commit should be postponed. This is solvable by the technique proposed when it appears in a subsystem but cannot be handled if there is a "dependency" between multiple subsystems.
Therefore it would be good if the settings subsystem would either restart the commit list or a "unhandled" commit list is created that will be handled in a second stage. This could be updated and (boundedly) restarted.
I would go for the presently proposed solution but create an issue that the settings system needs to be modified to handle the more general problem.

Some subsystems may then need 2 - 3 iterations (depending on subsystems they depend on) before they could complete the commit routine. In that sense I'd rather keep using k_work_delayable with pooling like it has been done and hope it won't fail. The amount of logic we need to build on top of the mesh settings' h_commit handler doesn't worth the effort. The approach with k_work_delayable can be used by anyone without additional overhead in settings or any other subsystem they depend on. I have a feeling this can be more bug prone.
I still think the proposed solution is good enough as it doesn't add any overhead to any of the current subsystems. It also makes sense for me that the Bluetooth host completes its commit routine and the rest Bluetooth subsystems do this after the host.
The order of h_commit calls for statically defined settings handler has been alphabetical de-facto and I bet it would not be a problem if the mesh h_commit handler by coincidence would be called after the host's sc_commit.

@LingaoM, @PavelVPV, I think that what is proposed here could be added and will solve the problem you are facing.
However I think it is a sign of a more general problem that appears in settings. Sometimes commits cannot be handled directly and some commit should be postponed. This is solvable by the technique proposed when it appears in a subsystem but cannot be handled if there is a "dependency" between multiple subsystems.
Therefore it would be good if the settings subsystem would either restart the commit list or a "unhandled" commit list is created that will be handled in a second stage. This could be updated and (boundedly) restarted.
I would go for the presently proposed solution but create an issue that the settings system needs to be modified to handle the more general problem.

Some subsystems may then need 2 - 3 iterations (depending on subsystems they depend on) before they could complete the commit routine. I have a feeling this can be more bug prone. In that sense I'd rather keep using k_work_delayable with pooling like it has been done and hope it won't fail. The amount of logic we need to build on top of the mesh settings' h_commit handler doesn't worth the effort. The approach with k_work_delayable can be used by anyone without additional overhead in settings or any other subsystem they depend on.
I still think the proposed solution is good enough as it doesn't add any overhead to any of the current subsystems. It also makes sense for me that the Bluetooth host completes its commit routine first and the rest Bluetooth subsystems do this after the host.
The order of h_commit calls for statically defined settings handler has been alphabetical de-facto and I bet it would not be a problem if the mesh h_commit handler by coincidence would be called after the host's sc_commit.

Fully Agree.

@LingaoM , @PavelVPV as I have repeatedly stated I would agree with the solution as I think it is good enough for the present problem.
However I do think a follow-up is needed: the approach with k_work_delayable does not seem a sufficient solution or we would not be discussing this.
I am not at all pursuing the need to change anything in the bluetooth subsystem at the moment, whatever solution is proposed it should not require direct changes, but only enable a more generic solution. I have been thinking about how to solve the general problem and I would do it as:

Introduce a settings Kconfig that sets a limit on the commit reprocessing of handlers (setting this to 0 should have 0 effect on code size).
When the reprocessing is set to a value different from 0 each h_commit can return a -ECANCELLED that results in the handler being placed in a cancelled_handlers slist,
When the static handlers are processed the cancelled_handlers slist is processed and every succesfull h_commit removes it from the cancelled_handlers slist.

This should ensure:

Each handler is only called once with succesfull result,
No code is added when the commit reprocessing count is 0,
Allow the proposed change to work without any required extra changes to the bt subsystem, but enabling future changes (if required/deemed advantageous).

This might retrigger going over the cancelled_handlers slist, but this shouldn't be a problem as long as it is bounded.
@alxelax, @Thalley, could you remove the blocking change request ? A follow-up should be capable of providing a more general correction.

Before I remove my change request, I need to fully understand these new changes. To me it looks like the priority is implemented using the name of the settings.
Is that correct?
If so, can we rely on this for only the Zephyr SDK, or any compilers/linkers?
If so, would the change in this PR effectively remove (by not reading existing) settings for all current devices?

Before I remove my change request, I need to fully understand these new changes. To me it looks like the priority is implemented using the name of the settings.
Is that correct? If so, can we rely on this for only the Zephyr SDK, or any compilers/linkers? If so, would the change in this PR effectively remove (by not reading existing) settings for all current devices?

The settings names are left unchanged, the settings_handler names are changed, so there should be no problem for current devices.

@Laczen, I'm not against what you proposal, but I don't see that it can be easily applied in our case.
This is the call stack for the Mesh Proxy GATT service registration which happens during settings_load() without k_work_delayable (like in this PR):
mesh_commit -> bt_mesh_start -> bt_mesh_proxy_gatt_enable -> bt_gatt_service_register
If we want to make use of the solution you propose, we need:

make bt_gatt_service_register return an error different than -EINVAL if the service registration fails due to the host not being ready yet. If this is considered as an API change (a new error code for old behavior), we need to pass the bt wg and architecture reviews.
propagate the error from bt_mesh_proxy_gatt_enable up to mesh_commit. Which means that bt_mesh_start should then return -ECANCELED or any other meaningful error that can be converted to -ECANCELED in mesh_commit function. This IMHO is very confusing if a function completes its job but returns an error code.
add a flag to bt_mesh.flags that the service registration failed.
check this flag in mesh_commit and explicitly call bt_mesh_proxy_gatt_enable one more time.

An option could be to add an API function to the host which the mesh can call from mesh_commit to check if the host is ready to register a GATT service. But this anyway adds more overhead than the solution from the PR. We should also make sure that the Kconfig option (for reprocessing the commit handlers) is correctly configured. From what I also see all bluetooth samples ignore settings_load error code. So if settings_load fails due to this, users may not see why mesh is not running.
Also, if there is a dependency chain, the configuration of the Kconfig option (for reprocessing the commit handlers) (I think) becames complicated as sub-dependencies should also be considered. This may eventually involve a user for proper configuration.
I may of course be wrong and don't see the whole picture so appologize in advance.

@Laczen, I'm not against what you proposal, but I don't see that it can be easily applied in our case.

That is OK, as said there is no intention to enforce my proposal to the bt subsystem. It would just be a follow-up, if the bt subsystem can solve it without my proposal this would be excellent. Even more, all functionality that is available today should remain (including the present PR).

Also, if there is a dependency chain, the configuration of the Kconfig option (for reprocessing the commit handlers) (I think) becames complicated as sub-dependencies should also be considered. This may eventually involve a user for proper configuration.

The Kconfig option would only be to enable reprocessing and setting a limit to the reprocessing. And you are correct, my proposal might not solve all situations, it is possible to create a dependency that will never be solved by reprocessing the handlers.
Maybe an even simpler solution than my proposal is the proposal of @Thalley to include a commit priority in the settings handlers and to have subsystems use this to set a commit priority. This would be a very small change.

Maybe an even simpler solution than my proposal is the proposal of @Thalley to include a commit priority in the settings handlers and to have subsystems use this to set a commit priority. This would be a very small change.

I'd say this is already solved by sorting static handlers. Dynamic handlers can be sorted at the registration.

@alxelax, @Thalley, could you remove the blocking change request ? A follow-up should be capable of providing a more general correction.

Hi @Laczen, I will as soon as feature with ordered static settings entries will be documented and became public documented feature of the settings subsystem.
At the current moment, this PR is based on internal implementation on another module. That might be changed. It for instance has happened recently in Bluetooth Host where adv tx queue handling were redesigned. Some assumptions about another module behavior became not working that caused significant problems. Adding more “assumption based” solution shouldn't be done, I'm quite sure.

@LingaoM , could you please update settings documentation saying that order of h_commit calls for settings handlers initialized by SETTINGS_STATIC_HANDLER_DEFINE is alphabetical? I could also do it, but much later.

@LingaoM ,
The tests_scripts/suspend/gatt_suspend_resume.sh test is failing because of recursive bt_mesh_adv_gatt_start call, which was happening because we called bt_mesh_adv_gatt_send outside adv_ext.c without setting ADV_FLAG_PROXY flag (like we do in adv_ext.c in send_pending_adv handler).
I've created a temporary fix, but not fully sure if it is correct: https://github.com/zephyrproject-rtos/zephyr/commit/e8fd5d4342c3b554037c733f4abaa70e8fc1299e
The tests_scripts/suspend/gatt_suspend_disable_resume.sh test is failing in the legacy advertiser because we were trying to start scanner while advertising and the controller didn't allow us to do that. I've created a very dirty fix by reordering scanner start and advertiser start, but we should think more how to fix this correctly: https://github.com/zephyrproject-rtos/zephyr/commit/f0e1506b2af3582f53eafde22b2007c345650432
The tests_scripts/priv_beacon/proxy_adv_multi_subnet_coex.sh test is failing simply because of timings change after registering GATT service right in the bt_mesh_start call instead of in work handler later. I've added a delay, but the test should be properly fixed: https://github.com/zephyrproject-rtos/zephyr/commit/90de90c4f8fdc1fd4417192e104b282fa56bf912
I would really appreciate if you fix all these issues since you started this PR. I don't have time atm to fix them. But the first two are quite critical I think.

Please also have a look at https://github.com/zephyrproject-rtos/zephyr/pull/79855 from @Laczen :)

Please also have a look at #79855 from @Laczen :)

Make sense. It adds just a little overhead with cprio field, but overall this looks good. Though something like subsys/bluetooth/common/settings.h will still be required to run host's h_commit before mesh one.

I’m curious, is this PR still worth merging after #79855?, or replace SETTINGS_STATIC_HANDLER_DEFINE in common.h with SETTINGS_STATIC_HANDLER_DEFINE_WITH_CPRIO based on this PR(#79855).

The second option with cprio.

I’m curious, is this PR still worth merging after #79855?, or replace SETTINGS_STATIC_HANDLER_DEFINE in common.h with SETTINGS_STATIC_HANDLER_DEFINE_WITH_CPRIO based on this PR(#79855).

@LingaoM It was not my intention for #79855 to intervene with the present PR. The present PR needed a follow-up to ensure that other users would not need to rely on alphabetic ordering (that would be hard for dynamic handlers), #79855 is the follow-up. IMHO #79855 can probably be used to simplify some of the bluetooth setup, and I hope you can use it to your advantage.

I’m curious, is this PR still worth merging after #79855?, or replace SETTINGS_STATIC_HANDLER_DEFINE in common.h with SETTINGS_STATIC_HANDLER_DEFINE_WITH_CPRIO based on this PR(#79855).

@LingaoM It was not my intention for #79855 to intervene with the present PR. The present PR needed a follow-up to ensure that other users would not need to rely on alphabetic ordering (that would be hard for dynamic handlers), #79855 is the follow-up. IMHO #79855 can probably be used to simplify some of the bluetooth setup, and I hope you can use it to your advantage.

The original intention of this PR is to solve the order of commits, thereby avoiding the logic of mesh retry. Generally speaking, this purpose has been achieved :).


Understand many conversion errors and warnings

Exact location of issue
Thanks to the detailed conversion reports, it is now easy to find conversion errors and warnings. But understanding them on a corpus of 2.5 million documents requires power tools. It's not practical to eyeball that many documents, even with several hundred pairs of eyes.
This issue is prompted by a single example. Exploring conversion reports, in https://ar5iv.labs.arxiv.org/log/1910.07940 I came across:
Warning:not_parsed:RELOP.NUMBER>MULOP MathParser failed to match rule 'Anything'
 at shahzamanian_publication.tex; line 99 col 176 - line 99 col 186
 In "$\sim 4\times$"
 ∼[[RELOP]] 4[[NUMBER]]
  > ×[[MULOP]]

I looked at the HTML in my browser, and didn't see anything missing. I then looked at the TeX source. The fragment in context is:
 with a mass of $\sim 4 \times$ $10^{6}$ $\mathrm{M_{\odot}}$

Notice we have two math formulas separated by white space. Now the MULOP warning makes sense. And also, on second sight, some mathmode strange spacing following that formula, in the HTML. And the PDF has the same strange spacing. (Well done for fidelity to the PDF here.)
The task prompted by this example is to find most of the instances where a conversion error math formula is followed, after a space, by another math formula.
Problem details
A good first step would be an easy way to download a representative sample of conversion reports.
My guess is that there will be at least 10,000 examples of such LaTeX coding in the arXiv corpus, and at most 100,000. But that's only a guess.
Once problem-spotters have a representative sample of conversion reports, they can identify frequent problems and start to understand them. They can also estimate their frequence over the whole corpus, thereby meeting the goal of understanding many conversion warnings and errors.
Looking ahead, the word 'many' is imprecise, as is 'almost all'. Understanding 5% would I think already be enough to provide some recommendations for authors. And also automated quality-checking tools.

Hi Jonathan,
Thank you for looking into ar5iv and starting this discussion.
Some general notes first:

Naturally, we've experienced how overwhelming it can be to deal with a large corpus of TeX, so we created a build system to systematically aggregate latexml's log messages already at the original start of the arXMLiv project, back in ~2007. Anyone can query that system at:
https://corpora.mathweb.org/corpus/arxmliv/tex_to_html

For downloading the logs of 10,000 examples, assuming you have a list of arXiv ids, this can be done with a simple loop that fetches https://ar5iv.labs.arxiv.org/log/<arxivid>. The ar5iv site is actively crawled by many interested parties at the moment (most recently I was told that SearchOnMath deployed a search index over ar5iv). So you are very welcome to grab any log entries you may need.

We are always open to monitoring new classes of problems that latexml conversion remains "silent" on today. If there is a pattern that can be automatically recognized during conversion, we can add and emit more messages (in 4 severities: Info/Warning/Error/Fatal), to track them at scale.

I actually find it practical to crowd source collecting concrete problems in ar5iv. In recent years we have had a trend where what used to be considered a "large" number for development has subsided down to "medium" or even "small". A thousand issues may have been seen as large, but is now commonplace. Consider the rust language issues, where we see ~9000 open issues, ~40,000 closed issues and ~60,000 closed pull requests. I think a modern project backed by a large community should aspire to such numbers - and I am hoping the issues in this ar5iv repository will eventually approach this kind of magnitude.

On the formula example:
For math parsing warnings, these are best used specifically to improve latexml's MathGrammar module, but often do not translate into visual degradation in the rendered HTML. latexml has a fallback parsing mode (similar to an extent to the way MathJax and KaTeX deal with math) which takes over when the grammatical parse fails.
Certainly there are many remaining upgrades and inaccuracies to math parsing, and concrete reports of encountering them are always appreciated. Some are sufficiently difficult that resolving them in full requires swapping the entire grammar engine for one capable of dealing with ambiguity, which is one branch of ongoing work in latexml.
The aggregated report for math parsing failures (reported via the ALLCAPS grammatical categories of the concrete latexml grammar) is here:
https://corpora.mathweb.org/corpus/arxmliv/tex_to_html/warning/not_parsed?all=false
As just one example, we've noticed that the most common parsing failure has to deal with unbalanced parens, often in frivolous TeX uses such as $(1+$ z $)^3$ found in astro-ph/0001053. There are other issues for an OPEN not finding its CLOSE, but the report tells us latexml fails to do so in 14% of arXiv articles.
For cases like this where math mode gets interrupted, as is with your example  $\sim 4 \times$ $10^{6}$..., the parse warning is also useful feedback to authors using latexml, who may want to edit their formulas to parse grammatically. latexml already covers a few choice cases that would extract an isolated construct out of math mode and deposit it in a textual element. We have been discussing - but haven't yet settled on - a few choice cases where adjacent math elements may be merge-able, so as to improve the parsing success rates.

And lastly - triaging issues. We have been somewhat disciplined in adding support for the "next most needed" package in arXiv with the limited time we have available for that work. And respectively - fixing the "next most common" Error and Fatal issues.
The aggregate reports are indeed very informative in that regard. But as the issues in this repository often point out, there is a difference between broad coverage over arXiv and pixel-perfect individual articles. Sometimes we will manage to preserve the content (and thus have no log messages emitted by latexml), but be inaccurate with the exact sizing and styling of the emitted HTML elements - which leads to clunky rendering. In those cases especially, having the arXiv community report the problems back is extremely helpful, as they may remain invisible to us otherwise.
Hope some of that is helpful - I think we are very much in alignment on how to generally approach solving the "arXiv to HTML problem".

Thanks again for the conversation and detailed testing of ar5iv!
I will close here, but you are always welcome to open more issues for specific articles, feature requests, or general quality-of-life upgrades for latexml .


When amount + gas fees exceed users' balance, please ask them to terminate

instead of allowing them to continue and click confirm like the current version

Fixed in release_0.4.0


cleanup: resolve revive linter issue

revive linter checks for var-declaration
format.
For example:
e2e/rbd_helper.go:441:36: var-declaration: should drop = nil from declaration of var noPVCValidation; it is the zero value (revive) var noPVCValidation validateFunc = nil
Updates: #1586
Signed-off-by: Yati Padia<EMAIL_ADDRESS>

/retest ci/centos/mini-e2e-helm/k8s-1.19

/retest ci/centos/mini-e2e-helm/k8s-1.19

X Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: Error creating machine: Error in driver during machine creation: IP not available after waiting: machine minikube didn't return IP after 1 minute

/retest ci/centos/upgrade-tests-cephfs

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/k8s-e2e-external-storage/1.21

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/k8s-e2e-external-storage/1.21

/retest ci/centos/mini-e2e/k8s-1.20

/retest ci/centos/mini-e2e-helm/k8s-1.19

/retest ci/centos/mini-e2e-helm/k8s-1.19

Failed to deploy Rook (etcdserver timeout, logs)

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/mini-e2e/k8s-1.19

Failed to deploy Vault (logs):
Jul 14 15:36:58.720: INFO: Running '/usr/bin/kubectl --server=https://<IP_ADDRESS>:8443 --kubeconfig=/root/.kube/config --namespace=cephcsi-e2e-542eff4c create --namespace=cephcsi-e2e-542eff4c -f -'
Jul 14 15:37:08.235: INFO: rc: 1
Jul 14 15:37:08.236: FAIL: failed to create vault configmap error running /usr/bin/kubectl --server=https://<IP_ADDRESS>:8443 --kubeconfig=/root/.kube/config --namespace=cephcsi-e2e-542eff4c create --namespace=cephcsi-e2e-542eff4c -f -:
Command stdout:

stderr:
Error from server: error when creating "STDIN": etcdserver: request timed out

error:
exit status 1

/retest ci/centos/mini-e2e/k8s-1.19

Failed to deploy Vault (logs):
Jul 14 15:36:58.720: INFO: Running '/usr/bin/kubectl --server=https://<IP_ADDRESS>:8443 --kubeconfig=/root/.kube/config --namespace=cephcsi-e2e-542eff4c create --namespace=cephcsi-e2e-542eff4c -f -'
Jul 14 15:37:08.235: INFO: rc: 1
Jul 14 15:37:08.236: FAIL: failed to create vault configmap error running /usr/bin/kubectl --server=https://<IP_ADDRESS>:8443 --kubeconfig=/root/.kube/config --namespace=cephcsi-e2e-542eff4c create --namespace=cephcsi-e2e-542eff4c -f -:
Command stdout:

stderr:
Error from server: error when creating "STDIN": etcdserver: request timed out

error:
exit status 1

Reported as #2288

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/mini-e2e/k8s-1.19

Unsure what happened here, the MON is not responding in a way that is expected (logs):
Jul 14 18:21:12.082: INFO: ExecWithOptions {Command:[/bin/sh -c rbd namespace ls --pool=newrbdpool] Namespace:rook-ceph PodName:rook-ceph-tools-7467d8bf8-v7xfh ContainerName:rook-ceph-tools Stdin:<nil> CaptureStdout:true CaptureStderr:true PreserveWhitespace:true Quiet:false}
Jul 14 18:21:12.082: INFO: >>> kubeConfig: /root/.kube/config
Jul 14 18:21:12.911: INFO: stdErr occurred: 2021-07-14T17:21:12.882+0000 7f861814b700 -1 monclient: get_auth_request but no auth handler is set up

Jul 14 18:21:12.911: FAIL: failed to create rados namespace with error error listing rbd namespace 2021-07-14T17:21:12.882+0000 7f861814b700 -1 monclient: get_auth_request but no auth handler is set up

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/mini-e2e/k8s-1.19

Some Kubernetes API server issue (logs):
Jul 15 15:30:16.463: INFO: waiting for PVC rbd-pvc (90 seconds elapsed)
Jul 15 15:30:19.435: INFO: Error getting pvc "rbd-pvc" in namespace "rbd-1318": rpc error: code = Unknown desc = OK: HTTP status code 200; transport: missing content-type field
Jul 15 15:30:19.435: FAIL: failed to create PVC with error failed to get pvc: rpc error: code = Unknown desc = OK: HTTP status code 200; transport: missing content-type field

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/mini-e2e/k8s-1.19

/retest ci/centos/mini-e2e/k8s-1.19

Failed to deploy rook


run "setup" in MSI, HYPHY and PASTA can not set path automatically

You must either write these in by hand, or add specific directories to $PATH. HyPhy in particular is challenging, since the executable name can take many different forms, depending on the system that compiled it.


Random failures of prognostic run report test

The test_prognostic_run_report test is often randomly failing on CI (about 10-30% of the time), possibly due to running out of memory.
This might be solvable by decreasing the size of the test dataset, though it depends on what is actually causing the random failure.

Do you know how much memory the CI workers have? Agreed that's probably the issue. This test has also gotten pretty slow—I can work on slimming it down.

It looks like they have access to 4GB, based on the resource usage report. Usage increases sharply towards the end before it crashes.


Put alternatives at the top of README

As we'll start to maintain the project soon, I think we'll close this one.
Is this fine @owais?

@fjsj Yes, I came here to say the same.


Use hashes() when checking relationships; Fix dat cmd & enhance dat, undat

This should fix finally the issue @frozenpandaman is dealing with in #16.
We'll (finally) check the portal's port list against all of our hashes. A "hash" can be 1327ca6d4caf3c4665f5b82d72a5dc716ddf24f58f253e857c5703b9b6a69838 (resolved) or elifessler.com (the current domain name).
Latter should get resolved to the actual hash when the portal gets registered, anyway, but it will still cause issues when someone on an older version has got elifessler.com in their ports and eli is checking their portal from 1327...9898.
We could try resolving the URLs in followed portals' ports, but

it'd strain the user's data connection even more
it'd cause unnecessary refreshes once we resolved it
it will be unnecessary once enough people move on to 1.8+ and after some time passes.

(Alternatively, check if the dat field in our own portal.json contains a "masked" URL to check against, but we're moving away from the dat field as it's just causing a handful of other issues...)
This PR also fixes the dat command not working properly and makes the dat and undat commands refresh the portals list and feed.

Awesome, looks great, thank you @0x0ade!


More Explicit Login on Demo

https://nimwc.org/login
It only says "use the test user", Ive tried:

test
test@test
demo
demo@demo
All of the above with and without .com

Honestly I dont know whats the user and password on the Demo.
Maybe just be more explicit, add on the index page something like:
USER<EMAIL_ADDRESS>PASS: test
:thinking:

Good catch! Your bruteforce actually resulted in the correct user and pass ;-<EMAIL_ADDRESS>- but I forgot to compile with -d:demo, which would show the username and password and allowing you to login with the demouser.
I will fix it later or on saturday. Thanks!
https://github.com/ThomasTJdev/nim_websitecreator/blob/master/nimwcpkg/tmpl/user.tmpl#L30-L37
https://github.com/ThomasTJdev/nim_websitecreator/blob/master/nimwcpkg/nimwc_main.nim#L382-L384

Compiled with -d:demo:
https://nimwc.org/login


erratum: Add missing 'request_sigs' flag

Signed-off-by: Lon Hohberger<EMAIL_ADDRESS>

+1 from me.


DEVMS-3097: Script to Create a Report with Tutorials and the Unused Files

Ready to merged?

Ready to merged?

Yes, you can merge @thecodester


Move doctest to the rayon-demo library

We've used doc_comment::doctest! to push the README through rustdoc
testing, but its #[cfg(doctest)] only works on 1.40+, and causes a
hard error on 1.38 and 1.39. Now we move this into rayon-demo so it
doesn't hurt compatibility of the main library.

ref: https://github.com/rayon-rs/rayon/pull/761#discussion_r428639158
bors r+

:+1:


Synapse_handler configuration is not working as mentioned in the documentation

Description
Below is the configuration you have to add to enable a synapse handler
[synapse_handlers.<custom_handler_name>]
 enabled=true
 class="org.wso2.carbon.apimgt.gateway.handlers.<Custom_Handler_Class>"

Related PRs:
https://github.com/wso2/docs-apim/pull/8214
https://github.com/wso2/docs-apim/pull/8220
https://github.com/wso2/docs-apim/pull/8221
https://github.com/wso2/docs-apim/pull/8222
https://github.com/wso2/docs-apim/pull/8223
Steps to reproduce

The steps to be followed to reproduce the issue.

Affected version(s)

The versions that are affected by the issue.

Related issue(s) (optional)

Any related issues such as sub tasks and issues reported in other repositories (e.g., component repositories), similar problems, etc.

Suggested label(s) (optional)

Optional comma-separated list of suggested labels. Non committers can’t assign labels to issues, and thereby, this will help issue creators who are not a committer to suggest possible labels.

Suggested assignee(s) (optional)

Optional comma-separated list of suggested team members who should attend the issue. Non committers can’t assign issues to assignees, and thereby, this will help issue creators who are not a committer to suggest possible assignees.

AFAIK, we need to use the following format added via https://github.com/wso2/docs-mi/issues/258 to configure a Synapse handler in MI
[[synapse_handlers]]
name = "<handlerName>"
class = "<packageName>.<handlerName>"

Hi, I think @SanojPunchihewa is almost right (the suffix of the "class" entry, after the last full stop is the CLASS name, not the HANDLER name).
I would personally keep the current format to avoid refactorings for deployment.toml files that define SynapseHandlers.
With the current format, the only way of disabling an handler is by commenting it out in deployment.toml.
If you want to enable/disable a specific handler without commenting it out, then you might add the "enabled" boolean property with an explicit value of "false" (the default being "true"), like this:
[[synapse_handlers]]
name="<handlerName>"
class="<packageName>.<handlerClassName>"
enabled=false

It would also be nice to know/define what the triggering order of multiple handlers is.
Are they triggered in the same order in which they are defined in the deployment.toml file (thus SynapseHandlers are kept in a LIST) or the triggering order is undefined (thus SynapseHandlers are kept in a SET)?
In the latter case, it could be useful to add yet another attribute (like for IdentityHandlers): "priority".
If HandlerB must be triggered after HandlerA, then this snippet could express this requirement (assuming that handlers with lower values of priority are executed before handlers with higher values of priority):
[[synapse_handlers]]
name="HandlerA"
class="<packageName>.HandlerAImplementationClass"
priority=100

[[synapse_handlers]]
name="HandlerB"
class="<packageName>.HandlerBImplementationClass"
priority=200

All handlers that do not require being triggered in a specific order will not define their priority (as per current implementation).


Support cursor-based media manager pagination

Right now the media manager assumes an "offset"-based pagination. But that doesn't work for many digital asset management APIs. Ideally we can invert that control to the given media manager's implementation.

Related to https://github.com/tinacms/tinacms/pull/1819 and https://github.com/tinacms/tinacms/pull/1838

Consider whatever breaking changes to the media list interface (or any interface in the media implementation) are ok in order to get this up and running. We'll reevaluate the API once we have a production-ready Cloudinary implementation.

proposed: remove limit, offset, totalCount from MediaList. add prevOffset. Make nextOffset required. this is a breaking change that will require a small migration for any existing MediaStore implementation.

Github and Strapi media packages should reflect these changes as well, likely meaning we'll need to do some arithmetic from within those packages


fix: [PL-56199]: support Open API yaml URL with Github API

Summary
Since our harness core repo was converted into private repository, we had to manually create a yaml file in https://github.com/harness/react-api-client repo and add the openApi yaml content for respective service to generate swagger.
With this we are enabling back generation of services using url ("openApi file path" would be better choice of words).
To achieve this user will require

GITHUB Personal Access Token
Path to service's openApi yaml in harness core
Organization, Repository and Branch name

Here is an attached video, where we are trying to generate idp-service swagger
https://drive.google.com/file/d/1lFrfwnAq-H3fFVPVj0ld_LtyUSH9WSFL/view?usp=sharing

Screenshots
NA

Contributor license agreement

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

This pull request has been automatically closed due to 30 days of inactivity. If you believe this was done in error, please feel free to reopen the PR or reach out to the BT team for further assistance. Thank you for your contributions!

This pull request has been automatically closed due to 30 days of inactivity. If you believe this was done in error, please feel free to reopen the PR or reach out to the BT team for further assistance. Thank you for your contributions!

This pull request has been automatically closed due to 30 days of inactivity. If you believe this was done in error, please feel free to reopen the PR or reach out to the BT team for further assistance. Thank you for your contributions!

This pull request has been automatically closed due to 30 days of inactivity. If you believe this was done in error, please feel free to reopen the PR or reach out to the BT team for further assistance. Thank you for your contributions!


UserCacheConfig.java:88: implement getProfileByName method.

The puzzle 1-a7a6a0b8 from #1 has to be resolved:
https://github.com/shiruka/shiruka/blob/6b0739939cb6cc2afb9b8a48439e33121b30016d/src/main/java/net/shiruka/shiruka/config/UserCacheConfig.java#L88-L88
The puzzle was created by @portlek on 30-Jan-21.
Estimate: 5 minutes,  role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

The puzzle 1-a7a6a0b8 has disappeared from the source code, that's why I closed this issue.


Disabled batching in all shaders

Individual object pivots are lost when batching as the vertices are transformed to absolute world space.

Thanks again for the PR.


Throw an error if a requirement exists with conflicting URLs

E.g., if you depend on Flask at one URL, and one of your dependencies depends on Flask at a different URL, we need to throw an error.

Does anyone know a way to explicitly prefer one of the conflicting URLs or work around this error without updating the dependent packages? cc @charliermarsh

@ayush-rathore-quartic -- You can use --override overrides.txt, and put something like:
flask @ git+https://github.com/pallets/flask@commit-sha


Broken pipe playing video

I got this when playing video from the web :
<IP_ADDRESS> - - [14/Oct/2015 22:35:24] "GET /static/uploads/d6dc1856f5c7b822ef04f2a64eb40d1d/Its_been_camouflaged_70_years_ago.webm HTTP/1.0" 200 -
Exception happened during processing of request from ('<IP_ADDRESS>', 38485)
Traceback (most recent call last):
File "/usr/lib64/python2.7/SocketServer.py", line 295, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib64/python2.7/SocketServer.py", line 321, in process_request
self.finish_request(request, client_address)
File "/usr/lib64/python2.7/SocketServer.py", line 334, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib64/python2.7/SocketServer.py", line 651, in init
self.finish()
File "/usr/lib64/python2.7/SocketServer.py", line 710, in finish
self.wfile.close()
File "/usr/lib64/python2.7/socket.py", line 279, in close
self.flush()
File "/usr/lib64/python2.7/socket.py", line 303, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe

That stacktrace looks more related to Flask or whatever server software you were using. CTFd shouldn't really be deployed using the internal server.


update requirements.txt

This node suite is great, but every update through the manager installs the old transformers and it's dependencies.
Would it be possible to check, if the requirements.txt can get an updated version? I've had 0 problems since months now using this with the newest transformers and it's dependencies on the newest updates too.
Thank you for this project and all the work you put into it!

Those are requirements, for things like MiDaS and BLIP.