Update SQLite subcommand to use links

PR for managing databases and links.

I'm going to mark this as ready to review, because it works well already.

@rylev this is a lot of commits but rebasing was a headache. If you aren't opposed, i copied all changes to a different branch. I could push that branch into this one to get us down to one commit: https://github.com/fermyon/cloud-plugin/compare/main...kate-goldenring:sql-links-cli?expand=1

That might be easiest... I wouldn't be opposed.

@rylev done 🎉

@rylev i am putting this back in draft because there are a few things we should figure out before merging:

What is the default DB name
We should improve the deploy flow for when a user cancels db selection during a deploy. It breaks future attempts because the oci image is pushed and storage id is set:

Uploading todo-three version 0.1.1-re3ef23e to Fermyon Cloud...
Deploying...
App "todo-three" accesses a database labeled "default"
Would you like to link an existing database or create a new database?: Create a new database and link the app to it
What would you like to name your database?
Note: This name is used when managing your database at the account level. The app "todo-three" will refer to this database by the label "default".
Other apps can use different labels to refer to the same database.: todo-three-db
Error: Unable to create app

Caused by:
    {"StorageId":["Storage ID not found in storage service"]}

Learn more at https://developer.fermyon.com/cloud/faq

Talking it over with others, we've decided to go with random name generation for now. We can always revisit this in the future.


🐛 Drop non-existent workspace get command from help output

Summary
Drops the kubectl kcp workspace get example from help output as it is not a valid command.
Signed-off-by: hasheddan<EMAIL_ADDRESS>Related issue(s)
n/a

/retest

/retest


[BUG] VS Code extensions are not installing

OS system and architecture in which you are running QHub
GCP
Expected behavior

VS Code extensions should be installable by users
python extension should be installed by default

Actual behavior

Trying to install an extension fails

How to Reproduce the problem?

Attempt to install any extension from VS Code Extensions

Command output
[2022-06-28 10:07:41.756] [window] [info] [Service Worker] registered
[2022-06-28 10:07:41.892] [window] [error] ["Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'","    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919","    at async Promise.all (index 1)","    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)"]
[2022-06-28 10:07:41.982] [window] [error] ["Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'","    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919","    at async Promise.all (index 1)","    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)"]
[2022-06-28 10:07:42.257] [window] [error] Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions': Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'
    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919
    at async Promise.all (index 1)
    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)
[2022-06-28 10:07:45.763] [window] [error] ["Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'","    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919","    at async Promise.all (index 1)","    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)"]
[2022-06-28 10:07:45.945] [window] [error] ["Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'","    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919","    at async Promise.all (index 1)","    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)"]
[2022-06-28 10:07:46.001] [window] [error] ["Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'","    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919","    at async Promise.all (index 1)","    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)"]
[2022-06-28 10:07:46.030] [window] [error] Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions': Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'
    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919
    at async Promise.all (index 0)
    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)
[2022-06-28 10:08:07.310] [window] [error] ["Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'","    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919","    at async Promise.all (index 1)","    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)"]
[2022-06-28 10:08:09.031] [window] [error] ["Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'","    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919","    at async Promise.all (index 1)","    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)"]
[2022-06-28 10:08:16.412] [window] [error] ["Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'","    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919","    at async Promise.all (index 1)","    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)","    at async U.getAllDepsAndPackExtensionsToInstall (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:108:9171)","    at async U.installExtension (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:108:5108)","    at async U.installFromGallery (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:108:3035)"]
[2022-06-28 10:08:16.439] [window] [error] Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions': Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'
    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919
    at async Promise.all (index 1)
    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)
    at async U.getAllDepsAndPackExtensionsToInstall (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:108:9171)
    at async U.installExtension (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:108:5108)
    at async U.installFromGallery (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:108:3035)
[2022-06-28 10:08:16.526] [window] [error] Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions': Internal: Unable to resolve nonexistent file '/opt/conda/envs/default/share/code-server/extensions'
    at /opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:78919
    at async Promise.all (index 1)
    at async i.scanExtensions (/opt/conda/envs/default/share/code-server/lib/vscode/out/vs/server/node/server.main.js:146:79033)

/opt/conda/envs/default/share/code-server/extensions doesn't exist.
/opt/conda/envs/default/share/code-server/ exists, but my user doesn't have permission to create a new folder herer

### Versions and dependencies used.

_No response_

### Compute environment

GCP

### Integrations

_No response_

### Anything else?

Something may have changed recently because I think extensions used to be stored in `~/.local/share/code-server/extensions`

I think this can be achived by seeting VSCODE_EXTENSIONS env variable in the user space, and point that to /home/<user>/.local/code-server/extensions)

@kcpevey  to try setting the VSCode extension env variable
@viniciusdc  will look into a fix as well

This directory does not exist<EMAIL_ADDRESS>

As far as I can tell, there is no way for me to access setting an env var in the shell where vscode is launched. I don't have permissions to edit .bashrc or .profile.
I can set an env var in a terminal, but that won't be the context from which vs code is launched.
Is there some other way to get into the context from which its launched? Actually, I don't even know where its launched from...

Ok, so the issue is that the current way we are installing the vscode server into qhub, uses a post-build installation process during build on conda-forge that sets the installation path to be hardcoded to be in the same path as conda shared dir. This will need to be moved to a future release as a proper fix will require us to re-think the installation process for the server and drop the conda package for more granularity control

Is there a workaround? This is a huge issue if users can't use vscode (the python extension isn't installed so we can't use the IDE to run/debug python)

You can change the location by launching VS Code with the --extensions-dir  command-line option. Some other ways are discussed here.

The default location for linux is supposed to be ~/.vscode/extensions
we might want to explicitely set both of the following:

--extensions-dir=
--user-data-dir=

We can't pass the --extensions-dir to it because it's already set during build in here

We can roll back to how it was implemented before as a quick shortcut (at least we know that it worked before)

Just met with @costrouc, I will soon submit a PR to fix this.

@viniciusdc can we also open an issue on the conda-forge feedstock about this to start a discussion assuming long term we want to use the conda-package.

@viniciusdc can we also open an issue on the conda-forge feedstock about this to start a discussion assuming long term we want to use the conda-package.

Hi, @dharhas I've done that already (see here), but I think that will take a while to get answered, I talked a bit with Chris this afternoon and we found a way to overlook that setting. For now, we will switch back to how we used to install code-server


TakePhoto and cropped bitmap

I use rtspservercamera1 with OpenGlView and when i try to take photo (with both cameras, back and front) the result is a cropped bitmap

Hello,
I tested it with my app and all is working as expected (no cropped).
I did a photo without aspect ratio enabled and with aspect ratio in both modes (adjust and fill).
Can you share me a code example used to reproduce error?
I did tests with this steps:

Replace SurfaceView to OpenGlView in layout:
https://github.com/pedroSG94/RTSP-Server/blob/master/app/src/main/res/layout/activity_camera_demo.xml#L9
Go to example in this line: https://github.com/pedroSG94/RTSP-Server/blob/master/app/src/main/java/com/pedro/sample/CameraDemoActivity.kt#L104
Replace line 104 to

        rtspServerCamera1.glInterface.takePhoto {
          val f = File(getExternalFilesDir(null)?.absolutePath + "/photo.png")
          it.compress(Bitmap.CompressFormat.PNG, 100, FileOutputStream(f))
        }

Compile and open app example and press switch camera to take a photo that you can check in: Android > data > com.pedro.sample > files


Example can be built on macOS

CocoaPods' output:
↳
Preparing
Analyzing dependencies
Inspecting targets to integrate
Using ARCHS setting to build architectures of target Pods-Runner: ()       Using `ARCHS` setting to build architectures of target `Pods-RunnerTests`: ()
Fetching external sources
-> Fetching podspec for FlutterMacOS from Flutter/ephemeral
-> Fetching podspec for audioplayers_darwin from Flutter/ephemeral/.symlinks/plugins/audioplayers_darwin/macos
-> Fetching podspec for mp_audio_stream from Flutter/ephemeral/.symlinks/plugins/mp_audio_stream/macos
-> Fetching podspec for path_provider_foundation from Flutter/ephemeral/.symlinks/plugins/path_provider_foundation/darwin
-> Fetching podspec for record_macos from Flutter/ephemeral/.symlinks/plugins/record_macos/macos
Resolving dependencies of Podfile
CDN: trunk Relative path: CocoaPods-version.yml exists! Returning local because checking is only performed in repo update
CDN: trunk Relative path: all_pods_versions_c_0_4.txt exists! Returning local because checking is only performed in repo update
CDN: trunk Relative path: Specs/c/0/4/Flutter/3.0.0/Flutter.podspec.json exists! Returning local because checking is only performed in repo update
[!] CocoaPods could not find compatible versions for pod "record_macos":
In Podfile:
record_macos (from Flutter/ephemeral/.symlinks/plugins/record_macos/macOS)
Specs satisfying the record_macos (from Flutter/ephemeral/.symlinks/plugins/record_macos/macos) dependency were found, but they required a higher minimum deployment target.
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/molinillo-0.8.0/lib/molinillo/resolution.rb:317:in raise_error_unless_state'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/molinillo-0.8.0/lib/molinillo/resolution.rb:299:in block in unwind_for_conflict'
internal:kernel:90:in tap'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/molinillo-0.8.0/lib/molinillo/resolution.rb:297:in unwind_for_conflict'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/molinillo-0.8.0/lib/molinillo/resolution.rb:682:in attempt_to_activate'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/molinillo-0.8.0/lib/molinillo/resolution.rb:254:in process_topmost_state'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/molinillo-0.8.0/lib/molinillo/resolution.rb:182:in resolve'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/molinillo-0.8.0/lib/molinillo/resolver.rb:43:in resolve'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/resolver.rb:94:in resolve'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/installer/analyzer.rb:1082:in block in resolve_dependencies'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/user_interface.rb:64:in section'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/installer/analyzer.rb:1080:in resolve_dependencies'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/installer/analyzer.rb:125:in analyze'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/installer.rb:422:in analyze'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/installer.rb:244:in block in resolve_dependencies'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/user_interface.rb:64:in section'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/installer.rb:243:in resolve_dependencies'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/installer.rb:162:in install!'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/command/install.rb:52:in run'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/claide-1.1.0/lib/claide/command.rb:334:in run'
/usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/lib/cocoapods/command.rb:52:in run'     /usr/local/Cellar/cocoapods/1.12.0/libexec/gems/cocoapods-1.12.0/bin/pod:55:in <top (required)>'
/usr/local/Cellar/cocoapods/1.12.0/libexec/bin/pod:25:in load'     /usr/local/Cellar/cocoapods/1.12.0/libexec/bin/pod:25:in '

Thanks for reporting. Please try on the latest version.


Clean command is not passed second argument

[x] I have tried upgrading by running bundle update vite_ruby.
[x] I have read the troubleshooting section before opening an issue.

Description 📖
The vite:clean command builds off the default assets:clean task but it adds a second argument, age_in_seconds. This argument is ignored (as in, can't be changed, will always be 3600), when using rake assets:clean because the base task only accepts a single argument, keep:
Reproduction 🐞
$ rails assets:clean[0,0]
[70, 79] in ~/.gem/ruby/3.3.4/bundler/gems/vite_ruby-92aff2135668/vite_ruby/lib/tasks/vite.rake
    70|   unless Rake::Task.task_defined?('assets:clean')
    71|     desc 'Remove old compiled assets'
    72|     Rake::Task.define_task('assets:clean', [:keep, :age])
    73|   end
    74|   Rake::Task['assets:clean'].enhance do |_, args|
=>  75|     debugger
    76|     Rake::Task['vite:clean'].invoke(*args.to_h.values)
    77|   end
    78|
    79|   if Rake::Task.task_defined?('assets:clobber')
=>#0	block {|_=<Rake::Task assets:clean => [environment]..., args=#<Rake::TaskArguments keep: 0>|} in <main> at ~/.gem/ruby/3.3.4/bundler/gems/vite_ruby-92aff2135668/vite_ruby/lib/tasks/vite.rake:75
  #1	block {|act=#<Proc:0x00000001204abd90 /Users/brendana...|} in execute at ~/.gem/ruby/3.3.4/gems/rake-13.2.1/lib/rake/task.rb:279
  # and 29 frames (use `bt' command for all frames)
(rdbg) args
#<Rake::TaskArguments keep: 0>
(ruby) args.to_h
{:keep=>"0"}
(rdbg) exit

Vite Ruby Info
Run bin/rake vite:info and provide the output:
bin/vite present?: true
vite_ruby: 3.5.0
vite_rails: 3.0.17
rails: <IP_ADDRESS>
node: v20.15.1
npm: 10.7.0
yarn: 1.22.22
pnpm: 9.4.0
ruby: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [arm64-darwin23]

To mitigate, one has to run the vite clean command directly, eg. rake vite:clean[0,0]

Closed in 824b4ef.


Simplify hash and equality operations

Also broaden the test coverage with set operation and equality to
different object.
Follow-up on https://github.com/lmmentel/mendeleev/pull/43

The (macos-latest, 3.6) test failure looks like an unrelated internet access failure.

Thanks for the help @kalvdans! I checked your version of __eq__ and __hash__ and I wonder what is your motivation for refactoring it that way. In other words, would you mind explaining why you think your solution should be used instead of the current one?
Also please take into account that python's hash returns the value it get if it's of type integer, e.g.
>>> hash(1)
1
>>> hash(100)
100
>>>

It only computes the actual hash for other types of values:
>>> hash("a")
-2483041677650604276

In your case the calling hash(self.atomic_number) seems redundant.

A hash algorithm is used in hash tables to allow for constant time average lookup time. It should not be used for anything else.
The old implementation of __eq__ will have a slight risk of collission. Since it hashes strings, it gets the random seed mixed in. On 32-bit platsforms the hash is 32 bit. Let's say the hash is perfectly random. The probability of two elements out of the 118 existing ones having the same hash is then 1.62e-6 according to the birthday paradox. So once in every millionth Python invocation, two different elements will compare equal.
On 64-bit architectures, the risk is smaller, but it is just fundamentally wrong to use hash for equality.

In your case the calling hash(self.atomic_number) seems redundant.

You are right. hash() automatically truncates integers to machine precision. I will change that, hang on!

On 64-bit architectures, the risk is smaller, but it is just fundamentally wrong to use hash for equality.

I'm not sure that I agree since python dict and set operations are based on hashing, so if it's good enough for the standard library it's good enough for our use case.
It seems that the solution you are presenting is a weaker equality condition that the one based on hashing since it uses a single attribute for comparison instead of 69 attributes. I don't think that I would like to rely on a single attribute since the odds of someone accidentally assigning a new value to Element.atomic_number or any other attribute may be higher that probability of a hash collision (which is still pretty unlikely). In the case of hash based implementation it would be able to detect that and say the elements are not equal.

I'm not sure that I agree since python dict and set operations are based on hashing, so if it's good enough for the standard library it's good enough for our use case.

They use the hash for inequality only, for equality they still call the __eq__ method, even if two hashes are the same.

someone accidentally assigning

Yes the documentation for __hash__ is clear that the object needs to be immutable. It is a bit tricky to enforce immutability on homemade Python objects, but that could be a future endeavour. Hashing all elements will still be buggy in case the object is already inside a dict.

I cannot see a strong case to get this merged, would like to continue iterating on this?

I care a lot about the quality of the mendeleev package, please tag someone else on the PR to get a third opinion.

I care a lot about the quality of the mendeleev package, please tag someone else on the PR to get a third opinion.

Thanks for your concern. I cannot currently see enough reason to devote more attention to this issue. If you find a concrete example (as in https://stackoverflow.com/help/minimal-reproducible-example) that illustrates any vulnerabilities with the current implementation I would be happy to jump in and help address that.

@mattwthompson, can you have a look at this PR?

Closing due to lack of activity


Fix editAnimeModal to update state properly

The modal should auto-exit and update the state instead refreshing the whole window.

Closed by #138


FailFast in non-HRESULT returning COM impl methods

Confirming here so we are on the same page, the implementation of the COM interface is in managed code, right? We are talking about CCWs.

So... you'd rather see the process exit immediately when an exception is thrown from managed code in a COM method that doesn't return HRESULT?

Yes, I would prefer the fail fast on the managed side to throwing a managed exception and having it propagate. Coming back into unmanaged (i.e., native) code means we are assuming the caller is going to have set up a SEH handler. In my experience this is exceedingly rare and results in DMPs that aren't always that easy to root cause and if it was detected I'm not sure what the caller expects to do with that exception. It also assumes the transition from managed to SEH is something the caller thought about - also unlikely.
COM interfaces that don't return an HRESULT indicate they don't expect a recoverable error in any form, that is how I've always interpreted them. The ITypeInfo members that return void, such as ReleaseVarDesc(), indicate to me that the callee isn't expecting or designed to handle invalid input. One could debate whether NULL is valid or not, but it is taking an arbitrary pointer to release and giving a invalid pointer is expensive to detect and unlikely to have a lot of utility, so fail fast. Alternatively the callee could defer to the dependent memory allocator, which is typically "fail fast" also.
If we are looking to support COM, actual COM not any of the various "subsets", then a member either returns an HRESULT, doesn't expect to have invalid input or swallows all failures and nicely returns. Letting exceptions propagate out from a COM member isn't supported and isn't something the .NET Interop team is going to recommend going forward.
/cc @jkoritzinsky @elinor-fung
Originally posted by @AaronRobinsonMSFT in https://github.com/microsoft/CsWin32/issues/825#issuecomment-1345073881

If we decide that the "swallow" route is the route we want to go instead of FailFast (though I think FailFast is better as it makes it easier to determine where the failure occured), it might make sense to call SetErrorInfo with a CCW for the exception object. That way the error is still discoverable through the COM model.


Provide guidance how to contribute

Provide guidance how to contribute

Info is already in our README through https://github.com/kedacore/external-scalers/pull/15


allow download of cropped splat

As a creative developer creating a 3d scene composed of one or more gaussian splats, I'd like to use a dynamic cutout to place target object and crop unwanted splats, and then to the export a file that only contains the target splats thus discarding the others and creating a much smaller file for use in a scene.
Mentioned in this ticket under future ideas:

allow exporting a lossless PLY again that has "baked" root transformation and cutouts and thus contains less data - suddenly this becomes a nice web editor for PLYs :)

I would vote to NOT support this feature and instead keep this repo as a "viewer" only. Instead there are repos like https://github.com/playcanvas/super-splat which are proposing to offer more advanced splat editing tools. So I will close this ticket for now but others are welcome to re-open if you think it is important to offer this feature in this repo.


Number of records

This PR addresses issues #753 and #785. Both of these buttons also have a tooltip added to them. The tests that I included test the implementation of:

clicking the button to open the input and clicking again to close it
making sure the error case occurs properly and alert shows up when a number greater than the max is input
it also verifies that multiple forms are indeed added when the user submits an appropriate value

The tests do not test filling out the forms and submitting them to the database. I spent some time trying to use the testPresentationAndBasicValidation function in ../specs/recordedit/helpers.js to fill in my forms and submit them but that function is too specific to the case of adding 1 row at a time and verifying that new one can be filled out. I would have to heavily modify that function or write a whole new function for filling out my forms, to test this functionality that is already tested in a slightly different context.
This functionality can be tested here.
Assigning to @howdyjessie and mentioning @shinyichen.

The input field is taller than the checkmark button, anyway to fix that and make them aligned?
Should the pencil icon be that? We use it to mean editing things, which I kinda get why you'd use it in this context (the user is editing how many rows to add), but I don't find it immediately clear what I'm editing. How about a ︙ (︙) or ⋯ (⋯) like a context menu?  Or even glyphicon-triangle-bottom to indicate there's a dropdown there?

Oops I just realized you said this morning you're retracting this PR! Sorry for the premature comments.

@howdyjessie, this issue is ready for review. I have since fixed the position of the input control so it doesn't get placed on top of a trash can icon and made the input group look better.

This looks good, I've merged it.


From worker email get worker information

Link to JIRA ticket
Jira Ticket - Extend the worker endpoint so that given a worker email returns worker information
Describe this PR
What is the problem we're trying to solve
We want to provide users the ability to look up other workers using their email address.
What changes have we introduced
Updated endpoint "/api/v1/residents/workers" to accept an email address as a parameter. DatabaseGateway will now look up a worker by email address.
GetWorkersUseCase handles all the business logic and calls the gateway.
SocialCareCaseViewerApiController calls the UseCase.
Checklist

[ ] Added end-to-end (i.e. integration) tests where necessary e.g to test complete functionality of a newly added feature
[ ] Added tests to cover all new production code
[ ] Added comments to the README or updated relevant documentation (add link to documentation), where necessary.
[ ] Checked all code for possible refactoring
[ ] Code pipeline builds correctly

Follow up actions after merging PR
Communicate with frontend.
Test frontend API calling the endpoint with a valid email address.

Hold off on a review, looking into creating an E2E test which currently has not been done for this project.


Suggestion: More permissions

I think it would be a good feature for server owner if they could give players permissions for crafting the different bows and arrows (#9 and #10) and also permissions to use them (for every bow an extra permission)
for example: ubows.craft.mobBow, ubows.craft.diamondArrow, ubows.use.explosiveBow and ubows.use.netheriteArrow

implemented permissions for using bows.


Import cargo-vet audits from Mozilla

This adds Mozilla as a source of trusted cargo-vet audits. Imported audits are
only cached in imports.lock if the crate is actually used by wasmtime.
The PR also bumps the version of cargo-vet used in CI.

r? @alexcrichton


replace sendFile and json bindings with Js.Json.t

See https://github.com/BuckleTypes/Rexpress/pull/5 for context. Replace loose bindings of 'a with Js.Json.t where appropriate.

Let's wait a bit and test the new JSON serialization/deserialization. The current usage of GADT is a bit inconvenient and for deserialization, you'd have to know the internal representation of bs data structures (very unsafe). Unless during serialization you translate your data structures into vanilla JS data structures and do the opposite for deserialization.
See https://github.com/bloomberg/bucklescript/pull/1382 and the other PRs by @mransan

@chenglou @bassjacob I am pretty much typing the entire Express API because I realize you need to look at everything to understand how everything work. I have lots of PR coming end of this week!
Regarding Js_json I agree it should be used in quite a few places instead of 'a. This will part of my change.

@chenglou @bassjacob  https://github.com/mransan/bs-express/blob/master/src/express.ml is the WIP

First changes at #8

closing this for now. thanks @mransan for the #8 typing :smile:


Equal in 4.0 (Proposal)

I propose to change how equality works in 4.0 to be more structural by default, the idea would be:

consider plain objects, arrays, sets and maps structurally
consider non plain objects (prototype !== Object.prototype) by reference
provide a byReference function backed by a weakmap to consider an instance of an object as by reference

We previously backed off from structural by default due to errors with circular structures but this was mainly due to considering ALL objects structurally (i.e. also custom classes). We should also be able to deal with circular structures by detecting loops.

Does this mean that equals(new Thing(),new Thing()) will be false? 🤔

Does this mean that equals(new Thing(),new Thing()) will be false? 🤔

depends how Thing is defined, not if it is defined via Data


Main

@aman5062  hey ..its a nice feature but can you slow it down ... it's quite straining to the eyes when one looks at it

Yes I will try..
On Thu, 13 Oct 2022, 11:49 am Rishika Garg, @.***>
wrote:

@aman5062 https://github.com/aman5062 hey ..its a nice feature but can
you slow it down ... it's quite straining to the eyes when one looks at it
—
Reply to this email directly, view it on GitHub
https://github.com/RIKI-05/MOMOMIA/pull/161#issuecomment-1277085178, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ARF6KBCR56EB6EKJD6K4ZGDWC6SV7ANCNFSM6AAAAAARD3XD5E
.
You are receiving this because you were mentioned.Message ID:
@.***>


Glitchy behavior of acrylic tabrow

Windows Terminal version
1.19.10302.0
Windows build number
10.0.22631.0
Other Software
No response
Steps to reproduce
Click outside the terminal window to make it lose focus.
Then click on the terminal window again to regain focus.
Expected Behavior
No response
Actual Behavior
The acrylic tabrow can't remain transparent. Random glitches occur with opaque color.
t.webm
In addition
v1.18.3181.0 worked fine.

Thanks for reporting this. Acrylic in the tab row has definitely caused us trouble in the past. We think this is fixed in the canary channel of the insider program, so the fix should be publicly available at some point soon. Thus, closing.


Steps for deploying Azure IoT Edge are out of date

https://docs.microsoft.com/en-us/azure/iot-edge/how-to-install-iot-edge-linux

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

ID: a3b8296d-c923-e990-dcad-35ef2b908a2a
Version Independent ID: 5f85fd7b-f2b6-b3b1-6be2-b6054bb33507
Content: Install Azure IoT Edge on Linux
Content Source: articles/iot-edge/how-to-install-iot-edge-linux.md
Service: iot-edge
GitHub Login: @kgremban
Microsoft Alias: kgremban

@edrickwong Can you clarify what steps are outdated in this doc? There might be other ways to deploy a VM with Edge pre-provisioned, but information here is still valid.

@veyalla This issue was assigned to the wrong article. It's actually for https://docs.microsoft.com/en-us/azure/machine-learning/service/how-to-deploy-and-where which uses some custom scripts made to automate the installation process. Edrick had concerns about those scripts not following best practices.

@YutongTie-MSFT - #please-assign to blackmist

@edrickwong Thanks for reporting this and apologies for any confusion this has caused. I'm checking with the developer who owns the scripts and added them to the document.
Originally, we pointed folks to the IoT Edge docs for this information. I'm guessing that the scripts were added as a way to make this process easier.
My personal view is that we should probably revert the document back to the original process, as there should be a single point of truth for setting up the device and deploying images to it, and that is owned by the IoT Edge folks. I'm waiting to see what response I get back from the development team before making any changes.

@Blackmist I have classified the issue accordingly.

Thanks @sergaz-msft
@edrickwong Thanks again for reporting this. I've spoken to the engineering team and they agree that we should remove the scripts and point to the IoT Hub documents as the single point of truth for provisioning devices and deploying images. The document update should go live later today.
#please-close


New version: yt-dlp.yt-dlp.nightly version 2<IP_ADDRESS>707

Pull request has been created with komac v2.1.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

2024-02-18 18:12:39.935 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:39.957 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:39.980 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:40.056 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:40.123 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:40.196 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:40.269 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:40.350 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:40.351 [CLI ] Terminating context: 0x8a150010 at D:\a_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UpdateFlow.cpp:b8 2024-02-18 18:12:45.845 [CLI ] Installer [X64,portable,Unknown,en-US] not applicable: Machine is not compatible with X64 2024-02-18 18:12:47.233 [CLI ] Installer [X64,portable,Unknown,] not applicable: Machine is not compatible with X64 2024-02-18 18:12:47.233 [CLI ] No suitable installer found for manifest Gyan.FFmpeg with version 6.1.1 2024-02-18 18:12:47.234 [CLI ] Terminating context: 0x8a150104 at D:\a_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\DependenciesFlow.cpp:11a

(Automated response - build 763.)

This appears to be a dependency mismatch.

2024-02-18 18:12:47.233 [CLI ] No suitable installer found for manifest Gyan.FFmpeg with version 6.1.1

For moderators
This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping Exorcism0666.

[!warning]
With the new version of Komac, numerous Pull Requests may contain bugs or unwanted elements. If such issues arise, please tag russellbanks so that these bugs can be addressed in future updates.

[!important]
Please carefully review these Pull Request before merging. If it is a Pull Request for removing incorrect content and the URLs are issue, free upon manual checking, please close this Pull Request directly. (It is best to inform Exorcism0666 of the closure.)

良い一日をお過ごしください！

@wingetbot waivers Add Validation-Installation-Error


Docs.rs fails to build docs with an Internal Compiler Error

Docs for 0.5.0 are not available on docs.rs, build logs here: https://docs.rs/crate/io-reactor/0.5.0/builds/1134663

This is caused by https://github.com/rust-lang/rust/issues/123287
(a regression in the latest rustc in the beta release channel)

Fixed in https://docs.rs/crate/io-reactor/0.5.1


Feature/home screen

Maquetado Home Screen

#1

@TomasLeggireDev  el linter klint fallo por estos 2 errores en CategoryItem:
ktlint: app/src/main/java/ar/edu/unlam/mobile/scaffolding/ui/components/CategoryItem.kt#L56 A multiline expression should start on a new line
ktlint: app/src/main/java/ar/edu/unlam/mobile/scaffolding/ui/components/CategoryItem.kt#L61 Missing trailing comma before ")"
https://github.com/unlam-tec-movil/A3-2024-H2-E1/actions/runs/11564328643


fix MSVC warnings

Fixes C4191 ("'type cast': unsafe conversion from 'FARPROC' to '...'") when compiled with Visual C++ /W3 or above. The warning appears to be C++ only, so the sokol samples don't complain.

Thanks!

Thanks!

PS: strange that I'm not seeing those warnings when compiling the sokol-samples here in C++ mode with warning level 4:
https://github.com/floooh/sokol-samples/blob/89f5825ab5d36906b2dc219efbce3d00be9e7cdf/libs/sokol/CMakeLists.txt#L39-L48
I'm having a deja-vu btw, didn't we discuss this exact same thing a little while ago? :D

PS: strange that I'm not seeing those warnings when compiling the sokol-samples here in C++ mode with warning level 4:
https://github.com/floooh/sokol-samples/blob/89f5825ab5d36906b2dc219efbce3d00be9e7cdf/libs/sokol/CMakeLists.txt#L39-L48
I'm having a deja-vu btw, didn't we discuss this exact same thing a little while ago? :D

Yes, on Twitter about a week ago. :D
Hm, indeed, doesn't warn in sokol-samples. The only difference I see is that I run my code with /Wall, some nitpicky stuff disabled globally, and external headers wrapped in #pragma warning(push: 3). Seems like MSVC does handle this differently.

Yes, on Twitter about a week ago. :D
Hm, indeed, doesn't warn in sokol-samples. The only difference I see is that I run my code with /Wall, some nitpicky stuff disabled globally, and external headers wrapped in #pragma warning(push: 3). Seems like MSVC does handle this differently.

...strange... on AppVeyor (VS2015) I'm now seeing this:
C:\projects\sokol\sokol_gfx.h(8131): warning C4054: 'type cast': from function pointer 'FARPROC' to data pointer 'void *'

...this is the double cast here:
https://github.com/floooh/sokol/blob/9dfe8cd050d7a69deff1f74c3bfd4d1ba0c18cd4/sokol_gfx.h#L8131
...I'll just go ahead and suppress this warning via pragma, makes no sense to add changes just to appease VS2015 I think ;)


Graphics Export doesn't work for .svg files

Basic information

My operating system and version: Windows 11
My MZmine version: 3.9.0

What happened
When exporting a XIC visualizer plot with "Export Graphics..." to .svg format no file is generated. In INFO "Writing image to file: C:..." is printed below and never switch to "Sucess..." as with the other formats.

Still doesn't work for me. It's possible that I may have something configured incorrectly on my end. However, any assistance in resolving this issue would be greatly appreciated as it is important for our workflow to export visualizer plots in .svg format.
Thank you for your time and support!


Prettier error messages for unsupported configurations (UX)

Rationale is being explicit on which configurations are currently supported and allowing a smoother transition between v2 to v3, mainly for older or highly modified setups that uses unusual configuration directives.
Also, some unsupported directives that uses CONFIG_VALUE (e.g. SecConnEngine) now allows the user to keep the configuration directive as long as its set to 'Off'.

merged. thanks.


Terms and requirements for use cases

That tool must be used only in terminal app inside launched gui session, or it must support strict tui modes like grub or putty ssh?

I have tested it on arch linux tty and it works great.
I asked about it,ty.


Parent element (body) isn't my main content element

An option to define my parent element on my page
my main contents that are scrollable are not placed directly inside my body element, which makes it not scrollable. I need an option while initializing AOS that allows me specify what element is my parent element, so that the necessary event listeners can be attached to it
Example :
AOS.init({
offsetParent: document.querySelector('#main-body')
});

哥，你找到替代方案了吗

I bundled a aos with supporting setting.root, @tonyer/aos
guide: AOS.init(root: document.querySelector('#main-body'))


smtpd_proxy_filter - rejecting bad stuff and telling the sender about it

See http://www.postfix.org/SMTPD_PROXY_README.html
It's possible to configure postfix and amavis to pre-process email and reject it back, rather than the more standard way of accepting it and then deleting/tagging it.
It does have some con's - mainly around the max throughput. This isn't generally a problem on modern servers for small domains, but then again who knows who'll use your image. So it might not be appropriate.
So can you consider it? It's quite satisfying to reject spam at the outset, and it has the nice side-effect of bounce messages being sent back by the initiating mail server/person so a false positive has a better chance of being noticed.

If you'll submit a PR, I'll be happy to merge it.
Note that backward compatibility should not be broken, but I assume that postfix experts don't use default config.

Hi @Bwooce, will work on it? Do you need help?

I am working, slowly, on it -- I have it working on my own mail server now I just need to remember how/why I configured it this way. Shall I make it optional? Switch config files based on an environment variable maybe?

You have to remember that this image provided a default set of postfix config files. The question is: "this should be enable or not by default?".
If yes, it can go the default config. (purpose of your issue)
If no, it will be enabled using a custom config file.
I don't really think that we should add complexity in this code to support all possible use cases.

@Bwooce, I close this issue since there's no update on it. Feel free to repoen or push your enhancement when needed.


Network Trace - UX Update - Results

A better experience to view the results.  I find the accordion panel hard to navigate and easy to get lost.
Option to not have an result list for a result, only show in the summary

@MikeMillerGIS
A better experience to view the results.
Currently the accordion displays results for all output layers.
How about we show only one layer at a time. We could either

Provide a dropdown below the summary to choose which output layer to see its result set or
Transition to a new page when user clicks the accordion titles with a back button. The summary section wont move.

Option to not have an result list for a result, only show in the summary
For this we can provide a checkbox for each output in configuration UI
Please let us know what you think.

I like the page transitions idea, review my comments on https://github.com/Esri/solutions-webappbuilder-widgets/issues/208.  I think have the results focus on the summary and then tranistions to explore each result set.  The map can even be filtered to only show data in that result set(hide the other results)

@MikeMillerGIS
Similar to #208 UX for Inputs, the results mock-ups follow the same page transition pattern. Here the difference is that the summary is displayed in place of the input controls.

And on clicking the result titles, the user is taken to the following page with the list of results:

Let us know what you think about both these mock-ups.

They do clean the UI up.  Let me ask the team for feedback.

These look better - i like the option to push to feature service or csv...

verified


nextLast() instead of next("last")

In the plenary which this proposal was first presented, it was suggested (by @codehag if I recall correctly) to use nextBack() instead of next("back"). As #9 / #10 changed "back" to "last", it will be nextLast() instead of next("last").
The reason I didn't follow Rust nextBack() API in the first place, is because the consideration of generators (https://github.com/tc39/proposal-deiter/issues/9#issuecomment-1143128315) . But I'm reconsidering it.
Several points:

It seems could help to solve the confusion @ljharb commented.
Do not need magic string. When I introduced the proposal to the js programmers, people often ask if it possible to not use magic string. Some suggested use symbol. We shouldn't use symbol because symbols are for protocols. Actually it's common to use magic strings as enums in JS APIs, but obviously many people don't like magic string anyway.
nextLast() looks even more consistent with findLast, lastIndexOf and potential iterator helpers takeLast, dropLast, etc.
The existence of  nextLast could be used to test whether an iterator is a double-ended iterator (or support reverse iteration), so we could drop separate symbols @@doubleEndedIterator (or @@reverseIterator), and also do not need separate flag fields (which next("last") may need). This seems the simplest solution of #5 .
next("last") could allow writing deiter in generators with function.sent proposal. Unfortunately, function.sent proposal have several issues, I try to reshape the syntax from meta property function.sent to "receive param", but as previous meeting, we are still far from consensus. So I'd like to drop the initial idea of "direct support writing deiter in generators", focus on the double-ended iterators itself, leave the generator issue to function.sent or future proposals (nextLast() could still be layered on next("last") in such proposals).

The word "next" appearing anywhere is the confusion, imo - "next" means forward, and "nextBack" is just as confusing.

@ljharb Do u have any suggestion of the api name?

prev or previous seems appropriate as an antonym to next, I suppose? (I'm still not convinced it's feasible to add this functionality in a nonbreaking way)

@ljharb prev is not an option, it even worse than the original word back, because prev means bidirectional, not double-ended. I don't know how I can explain it better if u already read the faq.

next("last") is a footgun. imagine an iterator does not support deiter, then this will happen:
let [a,     ...b, c] = noDeiterSupportIteratorOf(0, 1, 2, 3)
//   ^0th  rest^  ^1th

a // 0
c // 1 (!! we call next("last") but "last" is ignored by the next method)
b // 2, 3

but have no idea about what name we should use.

That’s true - but double-ended without being bidirectional is also a confusing concept. It’s more like two separate iterators on the same underlying collection - if it’s one iterator, then it probably shouldn’t have multiple directions/ways to iterate?

@Jack-Works Yes, we always need a mechanism to mark deiters. This was discussed in #5. For next("last"), a possible symbol based solution is https://github.com/tc39/proposal-deiter/issues/5#issuecomment-1019751577 .
As such solution,

let [a, ...rest] = x invoke x[Symbol.iterator]()
let [...rest, b] = x invoke x[Symbol.reverseIterator]()
let [a, ...rest, b] = x invoke x[Symbol.deIterator]()

If we move to nextLast(), all just invoke x[Symbol.iterator](), and check whether the iterator support next and/or nextLast.

@ljharb , bidirectional means u can restore to previous state, double-ended means u can consume in both ends, I think the problem is not they are confusing, but they are relative abstract interfaces/concepts, unfamiliar to the js programmers.

It’s more like two separate iterators on the same underlying collection

Yeah that's why it is called "DOUBLE-ended" iterator. Normally the underlying collection (or similar structure, for example, range(start, end) )  are deque. next() and nextLast() are just shift() and pop() (as C++ style terms, popFront and popBack, as Java style terms, poll and pollLast) .
Of coz we can have two separate iterators. That's reverse iterator . But reverse iterator is not enough for let [a, ...rest, b] = x. And in almost all cases, if an collection could support reverse iterator, it could support double-ended. So I suppose it's better to only write double-ended iterator so u only need maintain the iteration mechanism in one place, though it will be a little hard at first.
The good news is only library authors need to care about iterator, most programmers just use destructuring and never need to worry about them.

If we move to nextLast(), all just invoke xSymbol.iterator, and check whether the iterator support next and/or nextLast.

@hax You never really addressed my original complaint. Let's say this proposal proceeds. I write this:
function map(iterator, fn) {
  return {
    next() {
      return fn(iterator.next());
    },
    nextLast() {
      return fn(iterator.nextLast());
    }
  }
}

How can I tell if map(iter).nextLast() is going to be safe? I kind of just have to run it and see if it causes an iterator.nextLast is not defined error.
To avoid this problem I'd need to write map as:
function map(iterator, fn) {
  const next = () => {
    return fn(iterator.next());
  };

  return iter.nextLast ? { next, nextLast } : { next };
}

This rules out using generators to implement iterator helpers, so for starters you've made pretty much all current iterator code unsafe.

You don’t need any iterator protocol changes to support [a, ...rest, b] = - you just need to exhaust the iterator, and have cached the last N results

That’s very confusing to me; any use of … should exhaust the iterator, since it’s explicitly saying “grab everything available”

Not necessary, do you remember we introduce [a, ...] to not exhaust the iterator in the pattern matching proposal?

I just can't get over taking what seems to be a relatively niche use and fundamentally altering the definition of what an iterator is to support it! It seems to me like you've allowed the highest level concerns to drive the lowest level concerns.
You say that it should be possible to write const [first, ...rest, last] = iter and your solution is for all iterator implementations to be rewritten to support it. I just can't imagine that happening.

@Jack-Works thats a fair point :-P any use of it with a variable, then. How else would you fill it with the proper values?
@conartist6 not sure who is “your” here - are you talking about the proposal or about my claim that it should be achievable without changing iterators?

I should note that I'm not unbiased (though I hope my arguments are logical). But yeah, I have my own version of this proposal: https://es.discourse.group/t/array-prototype-reversed-map-set/556

Sorry, to clarify I meant "you" as "the authors of this proposal" except where I tagged Jordan. I am aware that a buffering solution is possible, and in fact I've implemented that solution as part of iterTools.slice(start, -end).

@conartist6
map should be roughly like:
function map(upstream, fn) {
  let iter = { __proto__: Iterator.prototype }
  if (upstream.next) iter.next = () => fn(upstream.next())
  if (upstream.nextLast) iter.nextLast = () => fn(upstream.nextLast())
}

Of coz this code is very naive (not passing the args of next, no throw/return, etc.), and not follow the built-in conventions (use unbound prototype methods and internal slots, not bound functions). Actually iterator transformations are hard even with generators:
function *map(upstream, fn) {
  for (let v of upstream) yield fn(v)
}

Such code will invoke @@iterator so it's actually iterable helper, not iterator transformation. And it also not pass the protocol (though as iterable helper, it may be ok.)

This rules out using generators to implement iterator helpers, so for starters you've made pretty much all current iterator code unsafe.

No. All current iterators still work, they just don't support nextLast so they don't support let [..., last] = currentIter.
About generator, I also hope we could allow people write deiter via generator syntax. But even without generator, at least most built-in iterators and iterator helpers could support double-ended, so still have enough benefit.
Even in current situation, you still could write deiter via generator:
class IntRange {
  constructor(start, end) {
    if (!Number.isSafeInteger(start)) throw new TypeError()
    if (!Number.isSafeInteger(end)) throw new TypeError()
    this.start = start
    this.end = end
  }
  @doubleEnded *[Symbol.iterator]() {
    let {start, end} = this
    let method = yield
    while (start < end) {
      method = method == "nextLast"
        ? yield --end
        : yield start++
    }
  }
}

The doubleEnded decorator:
function doubleEnded(g) {
	const {next} = g.prototype
	g.prototype.start = function () {
		if (this.started) return
		this.started = true
		Reflect.apply(next, this, [])
	}
	g.prototype.next = function (v) {
		this.start()
		return Reflect.apply(next, this, ['next'])
	}
	g.prototype.nextLast = function () {
		this.start()
		return Reflect.apply(next, this, ['nextLast'])
	}
}

const [first, ...rest, last] = iter and your solution is for all iterator implementations to be rewritten to support it.

See https://github.com/tc39/proposal-deiter/blob/main/why-deiter.md . It's better to open a separate issue to discuss the design choice.

Implementing that behavior correctly will be the responsibility of everyone who implements a deiterator.

Only if they want to support double-ended semantic. If not (for example, stream are normally one-way), they don't need to care about deiter. And in such cases, let [..., last] = stream will throw and should throw (this is why buffered solution is bad).

If we say that everyone who writes an iterator is also writing part of the internal implementation of destructuring, then we must also assume that some of those implementations will be incorrect. Sometimes the author will forget to stop the forward iterator when it hits the back cursor, and since this is javascript someone will be relying on the nonsense behavior and it will never be possible to remove, and this would become one of those language features that we just tell people not to use if they value their sanity...

Double-ended is not easy, but not as hard as you described. next/nextLast is just shift/pop, so if somebody can write shift/pop correctly, they can write next/nextLast correctly.
The really hard part is iterator transformation, and it's already hard even without double-ended semantics, different user-land iterator transformations libraries have many subtle semantic differences. This is why we should have a standardardized built-in iterator helpers. I don't think average js programmers should do it themselves, so I would agree to tell people do not write "iterator transformation" themselves. For library authors, it's their duty to solve relative hard problem or there is no need to use library. 😅

@hax the "why-deiter" doesn't talk about a method C, which is "support all iterables, but cache yielded results until the iterator is exhausted".

@ljharb that would be sound to implement, but it doesn't offer any way to do things like get the entries of a Map in reverse insertion order.

@conartist6 sure, but the solution to that is the same as "but the default iterator doesn't provide just keys, just values, or just entries" - make a new method that produces the iterator you want, like .reverseKeys() or something - or even .keys(true). There's no reason that allowing rest syntax in a non-final position requires an additional iterator protocol or changes to the iterator protocol.

I'd be strongly in favor of the combination of keysReverse and [first, ...rest, last] without constant-time support for [first, ..., last].

@hax I disagree with you that it would be reasonable for tools to define different methods on their outputs depending on their inputs. That is something I always explicitly try to avoid. It makes code harder to read, it makes types harder to write, it makes it harder for engines to execute code efficiently (by introducing polymorphism), and it tends to move the root causes of any problems far away from the place where they show up.

a method C, which is "support all iterables, but cache yielded results until the iterator is exhausted".

@ljharb I don't see any difference between "Mechanism A: Based on Array" with "method C".

I'd be strongly in favor of the combination of keysReverse and [first, ...rest, last] without constant-time support for [first, ..., last].

@conartist6 What's the precise semantic of "the combination of keysReverse and [first, ..., last]" ? Is that constant-time? I suppose you mean it is O(1) space, but O(n) time. If that, it sounds like half-optimization and over-engineering. As my experiences, people either don't care about perf (so they are ok about Mechanism A) or care about both space and time.

@hax because it would never be based on arrays, because it's iterable destructuring - so it should work for all iterables, using Lists, and only reify to an array as the final step.

That is something I always explicitly try to avoid for these reasons:

@conartist6 All these reasons apply to all similar things which have subtype/supertype, for example readonly collections.

It makes code harder to read
It complicates debugging

Actually this is why type system are useful.

It makes types harder to write

We write types not because it's easy to write, (many js idioms require very complex type, very hard to write, actually compare to many "type gymnastics", typing deiter is "easy",) but because it could help us to maintain the code and help others to use our code.

It makes it harder for engines to execute code efficiently by introducing polymorphism.

We need engine people to estimate the cost, but as I understand, introducing deiter won't harm to engine efficiency. On the contrary, buffer-based mechanisms add burden to the engine to optimize the builtins (if people use double-ended destructuring broadly, engines will eventually be pushed to optimize them) and eventually engines would have to implement deiter-like things, but that will become builtins-only magic, and like many magics today, if userland code involves, u suddenly lost the magic and got perf cliff.

@ljharb  It works for all iterables. I'm sorry if "based on array" sound different, but here "based on array" only mean the semantic is close to the traditional array-based operations (get rest, and splice the last items).
Of coz the implementation could (and should) use List or something else and only reify to an array if (rest is) needed.

You're saying that there all these ways that we can deal with the burden of supporting this pattern. I'm saying I haven't yet seen any evidence of a use case important enough to be worth the extra complexity added to the language and the ecosystem.

@conartist6 In general, I think if we want to support double-ended destructuring, the best solution is deiter, buffered solution have the issue of perf, and likely to get builtin-only optimization which cause the worse ecosystem issue. I've explained that in the why-iter doc. And note if we adopt buffered solution it make deiter never possible in the language. Even userland implementation could cause similar ecosystem issue if widely used.
I hope we can discuss more about the consequence of different possible mechanisms of double-ended destructuring, if u like. But maybe it should in a separate issue.

Even the example I've been using isn't really right. I keep writing out const [first, ...rest, last] = iterable but those names aren't quite representative of what's going on. last would more aptly be named lastOrUndefined because if you really want to know the last item in the collection you need to consider the possibility that you should instead be looking at the first item in the collection.
Your "why deiter" document doesn't really explain what all this is useful for, it just assumes that you want to do the things it allows you to do!

Not only last, first could also undefined. The only important thing is the double-ended destructuring always fill first first.

Your "why deiter" document doesn't really explain what all this is useful for

I think I already said that, it explained "why deiter" (is the best solution to support double-ended destructuring and why buffered solution is not good, and there is no other possible solution as I understand.)
I'm ok if anybody think the doc is not correct and we can discuss it (just like we do here) but saying "it just assumes that you want to do the things it allows you to do" is not very helpful.

from https://github.com/tc39/proposal-iterator-helpers/issues/123#issuecomment-1175657079 by @michaelficarra

I could imagine wanting a "find last element which passes some predicate" method that operates on every element from the front, avoiding the need to store the iterated elements, but we couldn't possibly call that findLast since that has different behaviour (due to possible side effects in the passed callback).

I find this comment also need to consider, findLast/takeLast/dropLast/reduceRight, etc. all such helpers can only have those names if based on nextLast() semantic, or the names are theoretically "wrong", though in practice it may be not a big issue (I'm not sure).

I think I already said that, it explained "why deiter" (is the best solution to support double-ended destructuring and why buffered solution is not good, and there is no other possible solution as I understand.)

You talk about solutions, but you do not explain what real problems they solve.
I understand wanting to be able to write reduceRight or findLast, but these are fundamentally the same as reduce(reverseIter) and find(reverseIter).
I also still don't see the purpose of meet-in-the-middle cursors. They make it possible to write const [first, ..., last] = iterable, but I just don't see what real problem is solved by being able to write that!

@conartist6 If you ask why add const [first, ..., last] syntax, I think the readme already have the clear motivation and further materials in Prior Art, Previous/Old discussion sections.
To be clear, if the committee think such syntax is not useful, the proposal will not advance. "Why deiter" only discuss the possible solutions to support that syntax.

Deiter VS. Reverse iterator
Reverse Iterator could be used to support findLast things, but it also require you implement reverse iterators for all iterables you want to use findLast. And map, filter etc. should also deal with reverse iterators to keep it chainable. So it doesn't have much differences with deiter.
The real main differences between reverse iterator and deiter are: Reverse iterator require you write two iterators, need to maintain the iteration algorithm correctness in two place, deiter only need you write one iterator.

About "meet-in-the-middle" complexity
Deiter does not necessarily based on "meet-in-the-middle cursors", though "meet-in-the-middle cursors"  is a common pattern for deiter/deque.
It seems you claim that it's too complex to most programmers. I already respond that in previous comment, and there is one more thing, if it's a common pattern, then it's easily to have a common helpers to deal with the complexity. For example, you only need write the deiter for IntRange  once, all index-based collection can use that to implement deiter very easily.

As iterator helpers proposal decide to not pass the protocol, we have to switch to nextLast().

Reverse Iterator could be used to support findLast things, but it also require you implement reverse iterators for all iterables you want to use findLast.

Yes. Your solution also requires iterables to create new reverse iteration logic in order for it to be possible to use findLast.

And map, filter etc. should also deal with reverse iterators to keep it chainable. So it doesn't have much differences with deiter.
I disagree wholeheartedly. Only deiter requires a new definition of map that is specifically for reversed values. If "values in reverse order" is just a normal forwards iterator, then the normal map operation over forwards iterators already works great and is completely chainable.

The real main differences between reverse iterator and deiter are: Reverse iterator require you write two iterators, need to maintain the iteration algorithm correctness in two place, deiter only need you write one iterator.

It's funny, you and I see this exactly opposite. You say that technically a deiter as defined by this proposal is is "one iterator" which must be simpler than two iterators. I disagree completely. You haven't eliminated the need to write the second iterator, you've just ensured that the logic for both iterators has to share state and be intertwined.

@conartist6

Your solution also requires iterables to create new reverse iteration logic in order for it to be possible to use findLast.

Double-ended iterators do not need seperate reverse iteration logic (just call nextLast() until done). So iterables could have only one double-ended iteration logic, and double-ended iterable is always both iterable and reverse iterable.

If "values in reverse order" is just a normal forwards iterator, then the normal map operation over forwards iterators already works great and is completely chainable.

Consider x have both @@iterator and @@reverseIterator, Iterator.from(x).map(f1).findLast(f2) still doesn't work, unless Iterator.from and map helpers could also provide @@reverseIterator (which invoke x[@@reverseIterator]).
Of coz u could write x[@@reverseIterator].map(f1).find(f2), but it force the author move the reverse step to the most upstream and also reverse transformations, and in many cases it's not possible (can't access the upstream) or at least very inconvenient.

a deiter as defined by this proposal is is "one iterator" which must be simpler than two iterators.

I didn't say one deiter must be simpler than two iterators.
Deiter could be a little bit complex, especially in the most simple case, "meet-in-the-middle" could be a marked logic. But if it's a simple case, this won't add too much complexity. You already see some example codes in my previous comments, and hope u could measure the complexity of such code in objective manner. In the complex case, for example, writing a deiter for tree traversal, the complexity mainly from the data structure, so "meet-in-the-middle" won't be a big deal. The total complexity of deiter and two iterator might be similar, but with deiter you get many other benefit, like maintaining iteration logic in one place not two, and supporting let [a, ..., b] = iterable which is the most important motivation of this proposal.

You haven't eliminated the need to write the second iterator, you've just ensured that the logic for both iterators has to share state and be intertwined.

I don't object anyone think a double-ended iterator as two interwined iterators, if it could help them to understand. Just like double-headed eagle might be have the source of two eagles:

The double-headed eagle originated in the ancient Near East. It was probably a Hittite symbol, to be more exact. The concept of dual eagles also existed in ancient Greece; Zeus (Jupiter) was said to let two eagles fly from the east and west ends of the world and they would eventually meet at Delphi, proving it as the center of the world. -- quoted from https://www.quora.com/What-is-the-original-meaning-of-the-symbol-double-headed-eagle-How-did-it-appear-as-a-symbol-in-the-Byzantine-Empire

We both want two types of iterator. You want single and double ended. I want forwards and backwards. Does that make me more Greek or Hittite?


Expand usage of 'spendable != balance' alert

There is now an alert shown when a tx does not transmit to the effect of
"The spendable balance may be lower because some bitcoin is tied up with your current transactions'
This check needs to be extended to two other cases:

At start up (there may be a tx that hasn't been sent just yet or other cases).
User does a repair wallet and there is an unconfirmed tx. The change for this unconfirmed tx is not spendable (it could be fake) and hence the spendable balance is lower.

Note that there is now more checking on the primary send screen for this, using MainController#initiateDelayedTransactionStatusCheck
The two use cases in the OP still need looking at though


ttps:///api/data/v9.1/importjobs(00000000-0000-0000-0000-000000000006)

importjobs(00000000-0000-0000-0000-000000000006) is this the correct way of giving the Guid for tracking the deployment Progress.
https://<dynamic app url>/api/data/v9.1/importjobs(5092c4e7-7098-43ab-bd55-d8dcbb8b5f03).the Postman responded with coudnt get any response.

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

ID: eecc2503-eee7-8779-2445-d6cd6968a0bd
Version Independent ID: 532be787-8be9-c9b5-37a2-88841c5b8118
Content: Microsoft Flow Web API - Microsoft Flow
Content Source: flow-docs/web-api.md
GitHub Login: @stepsic-microsoft-com

@MSFTMan Can you pls look at this issue.

@dpakgithub82 Thanks for using Microsoft Flow. This is the correct way. Please let us know if you are still seeing a problem.

@dpakgithub82 We haven't heard back from you so we are closing this issue. Please let us know if you need any other assistance.


MongoDB Image Doesn't Build on GitHub Workflow

While the image can be build locally, it does not remotely - https://github.com/QubitPi/jupiter/actions/runs/2577006826

 MongoDB Image Doesn't Build on GitHub Workflow


Specify MvcOptions.ReturnHttpNotAcceptable for 406

@rahulpnath thanks again for your help.
@guardrex  you too.

@rahulpnath thanks again for your help.
@guardrex  you too.


I/O inside the eventloop

Hallo,
@Krocko told me about warnings in Homeassistant 0.109.0 beta.
Logger: homeassistant.util.async_
Source: util/async_.py:120
First occurred: 23:24:20 (270 occurrences)
Last logged: 23:33:37

Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/__init__.py, line 222: info = self.connection.call_action("DeviceInfo:1", "GetInfo")
Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 622: f"WLANConfiguration:{self._network_num}", "GetInfo"
Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 347: self.fritzbox_tools.connection.call_action("X_AVM-DE_OnTel:1", "GetDeflections")["NewDeflectionList"]
Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/binary_sensor.py, line 66: self._is_on = status.is_connected
Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/binary_sensor.py, line 75: self._attributes[attr] = getattr(status, attr)

Looks like, its now necessary to replace all call_action calls and everything related to IO by something different.
I don't have the time at the moment. Could you take a look into it @mammuth?

I've got a bit time over the weekend, maybe it will be enough to fix it.

This error also appears:
Logger: homeassistant.helpers.translation
Source: helpers/translation.py:206
First occurred: 9:08:56 (40 occurrences)
Last logged: 10:57:02

fritzbox_tools: the '.translations' directory has been moved, the new name is 'translations', starting with Home Assistant 0.111 your translations will no longer load if you do not move/rename this

Getting somewhere around 1000 log entries an hour on the 109 beta so a fix would be appreciated :)

Maybe this is useful?
https://developers.home-assistant.io/docs/asyncio_working_with_async/

I have the same behaviour
2020-04-26 17:32:39 WARNING (MainThread) [homeassistant.util.async_] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/binary_sensor.py, line 75: self.attributes[attr] = getattr(status, attr)
2020-04-26 17:32:45 WARNING (MainThread) [homeassistant.util.async] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 626: f"WLANConfiguration:{self.network_num}", "GetInfo"
2020-04-26 17:32:46 WARNING (MainThread) [homeassistant.util.async] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 626: f"WLANConfiguration:{self.network_num}", "GetInfo"
2020-04-26 17:32:46 WARNING (MainThread) [homeassistant.util.async] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 349: self.fritzbox_tools.connection.call_action("X_AVM-DE_OnTel:1", "GetDeflections")["NewDeflectionList"]
2020-04-26 17:32:47 WARNING (MainThread) [homeassistant.util.async_] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 213: NewPortMappingIndex=self.idx,
2020-04-26 17:32:48 WARNING (MainThread) [homeassistant.util.async] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 213: NewPortMappingIndex=self.idx,
2020-04-26 17:33:16 WARNING (MainThread) [homeassistant.util.async] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 626: f"WLANConfiguration:{self.network_num}", "GetInfo"
2020-04-26 17:33:17 WARNING (MainThread) [homeassistant.util.async] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 349: self.fritzbox_tools.connection.call_action("X_AVM-DE_OnTel:1", "GetDeflections")["NewDeflectionList"]
2020-04-26 17:33:18 WARNING (MainThread) [homeassistant.util.async_] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 213: NewPortMappingIndex=self._idx,

upgraded to 1.8.1 and the problem is still occurring. Is there anything i need to do to resolve this problem, or info I can provide to help?
2020-04-26 22:57:17 WARNING (MainThread) [homeassistant.util.async_] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/binary_sensor.py, line 75: self._attributes[attr] = getattr(status, attr) 2020-04-26 22:57:18 WARNING (MainThread) [homeassistant.util.async_] Detected I/O inside the event loop. This is causing stability issues. Please report issue to the custom component author for fritzbox_tools doing I/O at custom_components/fritzbox_tools/switch.py, line 626: f"WLANConfiguration:{self._network_num}", "GetInfo"

Install version 1.9.0. ;-)

Ahh Good point! 1.8.1 is the latest showing in HACs for me and I wrongly assumed that was the fixed version!

Ahh Good point! 1.8.1 is the latest showing in HACs for me and I wrongly assumed that was the fixed version!

I release 1.9.0 as a preview release, those are not showing up in HACS unless you enable it on the detail page of the integration on HACS 😉 (actually I just wanted to test this out 😆)
I now bumped it to be a normal release.


adding new errors

Checklist

[ ] I have performed a self-review of my code
[ ] I have reached out to another developer to review my code
[ ] New and existing unit tests pass locally with my changes
[ ] All Lint and CI checks are passing

KHO-101


Add Close() on NATS connection to fix problem of messages not being delivered

Adding a Close() on NATS connection fixes the problem of messages not being delivered sometimes, when properly closing the connection a Sleep() is not needed in the PostProductEvent function.

I just approved it. We can change variable names in a separate PR, as it is a different issue anyway. #56


Implement uninstall cluster operation in functest

I splitted the uninstall operation into its own pr based on feedback on #189.
This basically implements what's currently in cluster-clean script, so uninstall can be called from functional tests. We will also need this for cluster upgrade functional tests.
I also switched to using controller-runtime client while deleting ceph and noobaa crs as compared to the other pr.

/test red-hat-storage-ocs-ci-e2e-aws

/test ocs-operator-e2e-aws

@sacharya oh, and one other comment.  can we get a unit test that verifies at least two conditions?

finalizer isn't removed if storagecluster is being deleted and noobaa still exists (and that noobaa is deleted)
finalizer is removed once noobaa (and whatever else we watch for there) is gone.

@davidvossel Thanks for the great feedback. Learnt quite a few things ;)

@davidvossel Thanks for the review. Learnt quite a few things there ;) Could you take a look again? Working on the unit tests.  Also, need to look more into the watch behavior for pvc that is not owned by Storagecluster. And see if I can filter by namespace and labels.

/retest

/retest

/test ocs-operator-e2e-aws

/test ocs-operator-e2e-aws


chore: add fail-closed aggregator whitelist

PoC to add a fail-closed aggregator whitelist to the longtail aggregator for safety.
Currently rugged by CORs allow origin response haeders from the gitlab URL.

Closing, I without using a CORS proxy we'll have to find another way to implement this.


No value in Filter Dimension

No value appears in the Filter "Schadstoffe" of the Dataset "MFM-U Luftdaten Jahresmittel NOx"

Open test.visualize and navigate in German
search MFM-U, include Draft
Select the data set "MFM-U Luftdaten Jahresmittel NOx"
Create a bar chart visualization
Next -> the filter of  dimension "Luftschadstoffe" is empty, while in the middle it's written "Messstation: Camignolo, Luftschadstoff: NOx".

Environment (please complete the following information):
Visualize environment : v3.2.7 [https://github.com/visualize-admin/visualization-tool/commit/ce02c26680448b1b7c4f4e8ca1b171484ae9120e]
Browser and version : Edge 97.0.1072.55 (64 bits)

Hi Veronique, I am looking into the issue, the first thing I see is that in the log I have a message "WARNING: Dimension https://environment.ld.admin.ch/foen/UBD010702/station has dataType 'langString'. Filtering won't work.". It is not very clear to me yet, I will continue to look into it, but maybe this has something to do with the cube itself.

I see that we have specific code to log a warning for this specific type of dimension.
https://github.com/visualize-admin/visualization-tool/commit/619ec5f
@luggen Do you have more information on why this was added ? What are rdf:langString ? Should the cube be modified to work ?

I removed the language for the Stations and Parameter dimensions, in the Cube UBD10703 MFM-U Luft Russ. It works in test Visualize (choose Version 2).
I left UBD10702 MFM-U Luft NOx as it was, for bug tracking.

Thanks Veronique from reporting this issue. I have several remarks

From the point of view of visualize.admin, any dataset that used those rdf:langString could not be used I think since we have never been able (from what I see in the code) to use filtering on this kind of dimension
Considering the display of values in the dropdown, I was able to make it work, but this is not the same story for the observations, that use another query.
Thus, I would re-label this issue from “bug” to “enhancement” because at the moment even though rdf:langString works in the cube creator, it is not supported in visualize yet and we would need to implement this in a future sprint if we choose that supporting cubes with rdf:langString columns is important

You can see now that the dropdown values are loaded on test.visualize.admin for the "UBD10702 MFM-U Luft NOx" dataset.

OK. Thanks for the research.
So as long as we enter the String type, without specifying a language in the CC it's ok, right?


Find/Replace window doesn't open in procedure/function source window after being opened it in SQL Editor

System information:

Operating system (distribution) and version: Windows Server 2016 Datacenter 64-bit
DBeaver version: <IP_ADDRESS>007051953
Additional extensions

Connection specification:

Database name and version: PostgreSQL 11 on Aurora RDS
Driver name: PostgreSQL JDBC Driver
Do you use tunnels or proxies (SSH, SOCKS, etc)? No

Describe the problem you're observing:
Find/Replace window doesn't open in procedure/function source window after being opened it in SQL Editor
Steps to reproduce, if exist:

open a procedure/function source
open a new/existing SQL editor
press CTRL+F to open Find/Replace window and close it
switch to procedure/function source and press CTRL+F again to see the issue

Workaround
Click on the procedure/function tab name and press CTRL+F again

thanks for the bug report

Duplicate of #8927 (and also hard to reproduce)

Fixed in #9191


Replace printf() impl with tinyprintf

See: https://github.com/cjlano/tinyprintf
The benefit would be better placeholders and likely less bugs.

Fixed by https://github.com/willdurand/willOS/pull/10, I ended up using https://github.com/mpaland/printf.


Create a rule to flag prop types consumed from .graphql files

We have this best practice documented here, https://github.com/Shopify/web-foundation/blob/master/Best practices/GraphQL/README.md#organizing-graphql-documents
We should make it harder to break this practice by introducing a lint rule

GraphQL files are the private responsibility of a single component. Components should not reach into another component to grab its GraphQL query for any reason. This is usually done to gain access to individual types from the query when declaring a subcomponent’s prop types. Instead of doing this, you should declare a "dumb" version of the types your component expects, and rely on TypeScript to verify that the parent is passing in the right data:

// bad
import {ComponentQueryData} from '../Parent/graphql/ComponentQuery.graphql';

interface Props {
  products: ComponentQueryData.ProductsEdgesNode[];
}

// good
interface Product {
  id: string;
  title: string;
}

interface Props {
  products: Product[];
}

I transferred this issue but I would like to know if it's still relevant.

I would say it's still relevant.


set headers in request

how may I set Authorization header on the request?

write your own fetch function and bind it like :fetch="fetch"


can _.bindAll accept an array of function names

I wrote this Stackoverflow issue for this common (imo) Underscore + Backbone pattern.
http://stackoverflow.com/questions/27697299/passing-an-array-of-names-to-bindall-arguments-list-has-wrong-type/
The best answer was to do this:
_.bindAll.apply(_, [this].concat(_.values(this.events)));

Would be much more readable if it could be written like this:
_.bindAll(_.values(this.events));

Many of the Underscore functions accept both a string or an array of strings, why not this one?

I'm a little confused. The values from this.events are already auto-bound by delegateEvents to your view. In general and with only a few common exceptions, I feel bindAll is an anti-pattern. Personally I prefer to bind at the point of passing to a callback, assigning a context arg, or where absolutely necessary binding in initialize.
This does add consistency with the rest of these type methods though, so I'm fine with including it.

delegateEvents re-adds the event functions to the view's DOM elements, but it does not bind the event function to the view. Even after calling delegateEvents (or initializing the view), the this keyword still references the event object and not the view object. Calling _.bindAll causes this to be the view object rather than the event object.

That simply isn't true. The method is bound to the view instance within delegateEvents.
You can try it for yourself:
var View = Backbone.View.extend({
  events: {
    'click': 'showThis'
  },
  showThis: function() {
    console.log(this); // the view instance
  }
});

var view = new View;
view.$el.trigger('click');
view.showThis();

You are correct. Not sure how I got the wrong impression with that.
We do use _.bindAll to bind view methods that get used as callbacks for ajax callbacks, event bus handlers and animation callbacks. I did not know that the event handlers were already proxied.

And all those methods you either know ahead of time (in which case you can call bindAll as normal) or can bind in place (as with the animation callbacks), right?

We can. _.bindAll in this case helps us centralize all the proxies in a view. This improves readability and makes troubleshooting easier.
Having _.bindAll accept an array increases the ways it can be used. In my original example there was fancy footwork needed to pull the names out of an array. We store function names in arrays to centralize a particular group of common handlers. This is true of event handlers, ajax callbacks, animation handlers, and backbone event bus handlers, all of which need proxied.
Also, creating a function which outputs the names of the functions to be bound requires the same fancy footwork to actually pass into _.bindAll since functions can return an array of strings, but not multiple strings.

I created a pull request: https://github.com/jashkenas/underscore/pull/2005


Install Fails with Error: unknown shorthand flag: 'e' in -encodedCommand

📜 Description
Installation fails with error
👟 Reproduction steps
helm install devtron devtron/devtron-operator --namespace devtroncd --set installer.modules={cicd}

results in failed install with error:
unknown shorthand flag: 'e' in -encodedCommand
👍 Expected behavior
devtron to install
👎 Actual Behavior
install fails
☸ Kubernetes version
Client Version: v1.25.4
Kustomize Version: v4.5.7
Server Version: v1.25.4
Cloud provider
N/A
🌍 Browser
Chrome
🧱 Your Environment
Windows 11
✅ Proposed Solution
The issue seems to be related to --set installer.modules={cicd} would be good to have something mentioned in docs or have this to be the default value so we don't need to set it.
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find any similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

AB#3513

Hi @ak99372,
Can you please specify your helm cli version? Also, where is the K8s cluster hosted on which you're trying to install Devtron on?

Hi @prakarsh-dt,
I updated the original post to include additional information. Also I tried installing it under WSL and the install went through so this narrows down the issue to Windows OS environment.


Add Controller::for_stream + Controller::watches_stream

This adds a stream interface analogue for Controller::new, that allows the user to create the root watcher and reflector, outside, and pass in the reader + flattened stream. This is for #1180 as a building block for stream sharing #1080.
In a similar vein, we also add Controller::watches_stream as an analogue for Controller::watches. That name should be less controversial given we have Controller::owns_stream.
Naming
For now, have named it along the lines of Controller::for and highlighted the terminology (noting that Controller::For is the controller-runtime equivalent).
However, there may be some better alternatives. Previously suggested:

Controller::from_stream - original plan, but that was before we needed to pass in the reader - so not a clean From
Controller::new_stream - awkward, suggests we are creating a new stream?
Controller::new_from_stream - very long, and leads to the obscene ::new_from_stream_with
Controller::new_with - taken by the dynamic variant
Controller::new_via - also awkward in combination with ::new_via_with

Feel like realistically it's between Controller::for_stream and Controller::from_stream.

The owns-stream unstable flagged is moved to unstable-runtime-stream-share, which now also contains this new method.
Consequences
When using unstable-runtime, we can actually use metadata_watcher with all Controller input interfaces.
Tested on a controller running several controller loops on a large cluster with thousands of pods and saw a >2x memory drop (449MB -> 210MB from a smaller core controller reflector passed in), and significant bandwidth reduction as well (230kB/s -> 30kB/s TX, 20kB/s -> 13kB/s RX but that's partially from using predicates).
Stream Sharing
Currently this interface does not work with WatchStreamExt::stream_subscribe because of the lack of Arc<K> in our interfaces. I want to change this long term, but this also involves adding Arc on everything internal to Controller, but I think that's OK. These new interfaces are unstable, and streams are otherwise constructed internally and could be arc'd up therein.
We already Arc-wrap before calling out to reconcile and error_policy so it would be nice to just have watcher (or a method in WatchStreamExt do this. Leaving this for a separate PR though.

This is working good enough for an unstable inclusion imo, but can benefit from a look-over.
It will not work for stream sharing yet because we need consensus on whether to Arc up literally every stream interface, but this at the very least allows configuring streams outside Controller and use filters or metadata_watcher with controllers.
Pinging @Dav1dde @danrspencer as interested parties.

I think for_stream is good, since it requires multiple arguments, it's also not a 'clean' from anymore.

trigger_owners can be implemented as this now, I think:
/// Enqueues any owners of type `KOwner` for reconciliation
pub fn trigger_owners<KOwner, S>(
    stream: S,
    owner_type: KOwner::DynamicType,
    child_type: <S::Ok as Resource>::DynamicType,
) -> impl Stream<Item = Result<ReconcileRequest<KOwner>, S::Error>>
where
    S: TryStream,
    S::Ok: Resource,
    <S::Ok as Resource>::DynamicType: Clone,
    KOwner: Resource,
    KOwner::DynamicType: Clone,
{
    let mapper = move |obj: S::Ok| {
        let meta = obj.meta().clone();
        let ns = meta.namespace;
        let owner_type = owner_type.clone();
        meta.owner_references
            .into_iter()
            .flatten()
            .filter_map(move |owner| ObjectRef::from_owner_ref(ns.as_deref(), &owner, owner_type.clone()))
    };
    trigger_others(stream, mapper, child_type)
}

That's great. Worked immediately.

Alright windows is green here after sync despite it consistently crashing in the other PR :upside_down_face:
Will merge this at lunch and prepare a release.


Only create overlay disk once.

If the overlay disk image is overwritten every time we start the router the running-configuration is lost for the CSR and the router defaults to console output over vga instead of serial.
I think this is the correct fix for @jabelk problem in issue #160
Tested with xrv and csr.

Yupp, we discussed this separately and I agree this makes sense. Merging.


Update line annotation diagram to describe new element structure

Removes the wrong line label element diagram because not updated to new structure.

The line: The following diagram is showing the element properties about a 'line' annotation: and the inner label:
Should now be: The following diagram is showing the element properties about a 'line' annotation:
Can be found at line number 80

Yeah, forgot to remove it.


Undefined variable

No matter what I do, I can't get the pdf to render using Gotenberg.
The PDF only ever renders with
Failed to render HTML. Error: Undefined variable $username
My template

Hello {{ $username }}

Default variables
{
  "username": "username_missing"
}

cURL
curl --request POST \
  --url http://localhost:8888/api/v1/document-templates/9d4186c0-4bd0-4732-8fb0-2944132d31b1/pdfs \
  --header 'content-type: application/json' \
  --data '{
  "variables": {
    "username": "sam.n",
  }
}'

docker log
docking-1    | {"message":"Undefined variable $username","context":{"view":{"view":"/var/www/html/storage/framework/views/8d5b3624fbd57ccbbace3317aac77a67.blade.php","data":[]},"exception":{"class":"Spatie\\LaravelIgnition\\Exceptions\\ViewException","message":"Undefined variable $username","code":0,"file":"/var/www/html/storage/framework/views/8d5b3624fbd57ccbbace3317aac77a67.blade.php:1","previous":{"class":"ErrorException","message":"Undefined variable $username","code":0,"file":"/var/www/html/storage/framework/views/464daea1acbb9d2710318291b7aff0fb.php:1"}}},"level":400,"level_name":"ERROR","channel":"production","datetime":"2024-10-16T03:07:49.538753+00:00","extra":{}}
gotenberg-1  | {"level":"info","ts":1729048069.5986624,"logger":"api","msg":"request handled","trace":"736acea2-312e-4c0f-ac86-89ae30600cb9","remote_ip":"<IP_ADDRESS>","host":"gotenberg:3000","uri":"/forms/chromium/convert/html","method":"POST","path":"/forms/chromium/convert/html","referer":"","user_agent":"GuzzleHttp/7","status":200,"latency":53202208,"latency_human":"53.202208ms","bytes_in":267,"bytes_out":20134}

Running with docker-compose.yml
services:
  docking:
    image: "ghcr.io/shipsaas/docking:latest"
    env_file: .env
    volumes:
      - ./docking.sqlite:/var/www/html/docking.sqlite
      - app_storage:/var/www/html/storage/app
    links:
      - gotenberg
    ports:
      - '8888:80'

  gotenberg:
    image: gotenberg/gotenberg:8

volumes:
  app_storage:

it works for me, you have to fix your post request (no comma after "sam.n")
curl --request POST \
  --url http://localhost:8888/api/v1/document-templates/9d4186c0-4bd0-4732-8fb0-2944132d31b1/pdfs \
  --header 'content-type: application/json' \
  --data '{
  "variables": {
    "username": "sam.n"
  }
}'

Will check
On Mon, Oct 21, 2024, 7:35 PM thomas-parodi @.***>
wrote:

it works for me, you have to fix your post request (no comma after "sam.n")
curl --request POST
--url http://localhost:8888/api/v1/document-templates/9d4186c0-4bd0-4732-8fb0-2944132d31b1/pdfs
--header 'content-type: application/json'
--data '{  "variables": {    "username": "sam.n"  }}'
—
Reply to this email directly, view it on GitHub
https://github.com/shipsaas/docking/issues/36#issuecomment-2427329091,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYLFYUB44TMMRCMKMLCOPLTZ4U3NZAVCNFSM6AAAAABQAOWSLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRXGMZDSMBZGE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

to fix your trouble check this solution click
maybe this will solve your problem.


Fix for Incompatible file structure returned by GCSArtifactRepository (#172)

Ensures that the GCSArtifactRepository returns the same file structure as the LocalArtifactRepository. This fixes (#172)

@smurching Can you help review this?

@aarondav yep looking now - @jakeret if you have a screenshot of the UI working with this PR that'd be awesome to help speed validating it

Sure. Here we go:

The build seems to break because of another issue not related to this PR

Codecov Report

Merging #173 into master will decrease coverage by 1.28%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #173      +/-   ##
==========================================
- Coverage    51.6%   50.32%   -1.29%
==========================================
  Files          93       93
  Lines        4676     4680       +4
==========================================
- Hits         2413     2355      -58
- Misses       2263     2325      +62

Impacted Files
Coverage Δ

mlflow/store/artifact_repo.py
90.55% <100%> (+0.78%)
:arrow_up:

mlflow/projects/databricks.py
0% <0%> (-78.27%)
:arrow_down:

mlflow/projects/pollable_run.py
76.78% <0%> (-10.72%)
:arrow_down:

mlflow/projects/__init__.py
91.73% <0%> (-2.48%)
:arrow_down:

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 54ddd84...7a9a82d. Read the comment docs.


Trim html

Trim HTML to minimise JSON size and only the bare necessities

Added makeContent function to trim HTML
Added setting for trim_html, default to false

Nice Job! npm package version  update to v1.0.3