Cannot open backgrounds/wall.jpg

sddm-greeter is throwing the following error
file:///usr/share/sddm/themes/catppuccin-frappe/Main.qml:18:3: QML Image: Cannot open: file:///usr/share/sddm/themes/catppuccin-frappe/backgrounds/wall.jpg

Is there supposed to be a default wall.jpg in backgrounds?

There was previously going to be a default, but I decided against it due to licencing. However that does not mean that one cannot be placed there, by PR or a user.


Testing OwnedStorage trait, growable AllocVec

For my needs it's pretty important to support a heap Vec that can reallocate, as well as being able to support either inline or allocated Vecs depending on what features are enabled. I put together this set of changes to test a few updates. I see you've created an issue recently which suggests adding a new GrowableVec type; that could also be supported under this general scheme, leaving AllocVec as constant capacity.
Here, the OwnedStorage trait allows for new, with_capacity, Clone, Default, and From to be supported for multiple storage types, including custom storage types that might be implemented externally. An interesting example would be a zeroizing buffer, which would have better characteristics than a Zeroizing<Vec<T>> (from the zeroize crate) because that type is not able to account for copies made during reallocations.
In order to support new for AllocVec it needs to either define a minimum capacity or behave like the standard Vec and start with no allocation, I chose the second option here. The realloc code would probably need significant work in order to optimize it and handle corner cases.

Hi! Thanks for tackling this, that'll be a huge help.
Some remarks:

try_grow probably shouldn't mutate self, but return a Result<Self> instead. This way, it's the client data structures' responsibility to copy data over. There, we know how much storage is currently being used, so we don't have to potentially copy uninitialized memory, and we may also want to not copy over some data depending on the context that triggered the reallocation, e.g. in Vec::replace_range.
It's important to me that even on AllocStorage, reallocation remain optional. Please, either introduce a new type, or add a generic parameter const GROWABLE: bool. Thinking about it now, I would actually favor the latter, as I think that could later be expanded to be a more configurable reallocation policy (e.g. multiply capacity by a different factor on each reallocation, set an optional maximum capacity...), which would be cool.
You can't rely on realloc to do the copying for you. It may work for Vec, but it'll break the invariants of most other types.
The OwnedStorage trait is the right idea in general, but I don't think it needs the new method when Default exists, which InlineStorage can also implement.

To be clear, I don't expect you to do the method-specific copy optimizations, the copying strategy in data structures other than Vec (that's the one you're interested in, right?), or the reallocation policy thing. I'll gladly do those myself (eventually...), if you don't want to do it. I'm happy you want to contribute at all, and I just want you to know where I'm going with this.
Also, it's fine you used rustfmt, but the formatting changes make it kind of annoying to find the semantic changes to review. It's on me for not doing this sooner, but I'll quickly run it myself on the whole code base. If you don't mind starting over from that commit, that would be very nice of you, but I fully understand if you don't want to do that.

Awesome, I'll rebase to fix the conflicts due to the formatting. Rust analyzer is also having a hissy fit about some of the syntax, I think it might be the <T, const N: usize, O=Default> pattern which seems to be 1.59+.
For the try_grow implementation I agree that it would be better to return a new Storage instance, it would also be more conducive to things like a generic zeroizing wrapper around a storage type because it only needs to add a Drop implementation. And that doesn't break the invariants outlined in the comments. One thing I'm not sure about is whether the size of the Result would cause issues when called for a large Inline storage type, although I suppose an extra const trait property could be used to avoid that call if it is an issue.
Replacing owned_new with Default makes sense. It seems like AllocVec would only implement Default when it is Growable.

Actually, it doesn't look like Default can be supported for InlineStorage without making it a newtype, because it's not supported for MaybeUninit. But it might make sense to move that functionality to a DefaultStorage trait for example.

Ah, true. I think it's fine to just make it a newtype though. Seems better than introducing another new trait.

I have it implemented using an additional trait at the moment. The nice part about that is that the initializer can be const, although due to other limitations Vec::new cannot yet be const for supported Storage types.

I think I'm done with potential updates for now, so I can mark this as ready for review or you can merge in what you like manually. It looks like as of Rust 1.61 the Vec::new() method could be made const, as trait bounds other than Sized were stabilized for const methods (as long as you aren't calling any trait methods). buffer_too_large_for_index_type being const would depend on the const_type_name feature being stabilized, or the Capacity trait could have a const name property. It's also possible to drop the DefaultStorage trait and implement Default for the InlineStorage but I think that would make a const initializer impossible.
I've added a try_with_capacity to avoid panics in Vec-owning structs that don't necessarily know what storage backend they will be using and want to provide a fallible constructor. I think in addition to the From implementations for slices and arrays, it might be useful to have matching TryFrom implementations?

I've also added an initial implementation of the zeroizing storage wrapper I was talking about: https://github.com/andrewwhitehead/coca-zero

Hiya, any thoughts on this PR?


AVPlayback: Refactor can play to deal with path extension

Before this PR AVFoundationPlayback was accepting any valid NSURL as a source.

👍


select primary color

how to change primary color based on color chooser dialog widget?

Color chooser dialog is currently only for secondary color. I will add one new dialog for primary color on next Release.


Dictionary with keys that are not strings (ints, floats, vectors, etc) are loaded incorrectly

When a dictionary has keys that are not of type String, the keys are loaded inconsistently. It's difficult to explain the bugged case, so please see the example stripped down project below.
To reproduce:

Open the project below on 4.2.1.stable
Enter play mode, press the save button, then load.
When pressing load, it prints the returned dictionary that was loaded. The printed result should be: { 10: "hello!", 20.5: "bye", true: "test", (1, 1): true }
Now exit play mode then re-enter it. Press the load button without first saving (this should of course work, because we saved earlier!)
BUG: When loading this time, the printed output is actually { "true": "test", "10": "hello!", "20.5": "bye", "(1, 1)": true }. Note the extra "" around the keys; the keys of the dictionary that were previously read as int/float/bool/vector2 are now being read as Strings. If you now press save again, every time you load the dictionary keys will be the correct type until you exit and re-enter play mode again.

So basically, if you save then load, the keys of a dictionary are of different types to if you load without saving. All the code is in test.gd, I would expect that every time you load, the keys of the dictionary are the correct type (int / float / bool / whatever rather than strings)
Save Load Bug Repro.zip
This bug is causing me some major save / load headaches, would be very helpful if this could be fixed!

Hello! This is related to this Issue submitted on the Godot 3 version, probably the same thing is up. Feel free to give it a read.
One alternative I can recommend for the time being, is converting all your keys to string when accessing the dictionary. (Then you'd do dict[str(my_key)] = my_value, and you'd need to type-cast the value when accessing it too. I know it's not convenient, but this is what came to my mind off the bat while I don't get around to implementing type safety.
https://github.com/AdamKormos/SaveMadeEasyG3/issues/1

I can understand that it's tough to figure out the type of the data to load, but why would it be different in the case of saving then loading vs just loading? The save file that is being loaded has the same data inside in either case, but I'm getting different types for the keys of the dictionaries. Sometimes it gives the type I expect, and sometimes not. But thanks, converting keys to strings makes sense

Because when you save, you add a value to the dictionary run-time, and because of that, your type is known since you pass it a certain type of variable, not text.
When you save to the file however, the file is going to contain text, no matter what you do. Therefore, when you load it back, you're gonna get only text. But I'll try a fairly easy-to-add method shortly to see if that fixes parsing and type-casting.

Does it work for you if you replace the get_var method entirely with this?
func get_var(key_path : String, default = null): 	key_path = _sanitize_key_path(key_path) 	var var_at_path = _get_variable_at_path(key_path) 	if var_at_path != null: 		if var_at_path is String: 			return str_to_var(var_at_path) 		else: 			return var_at_path 	else: 		return default

Nope it doesn't, I don't see any difference

Damn. Alrighty, I'll work something out sometime, but in the meanwhile, you can do the manual typecasting, I hope. :)

I've just looked into this again. It seems to me, the keys are the only ones that do not get type-checked automatically.
I added a new method called typecast_dictionary_keys. Godot seems to have some weird gimmicks regarding type conversion, but now your issue seems to be solved on my end. Dropping the modified project zip here, feel free to check it yourself and validate if this approach helps out. :)
Save Load Bug Repro.zip


Web compatibility issue with Magic360

We have had the item method on Arrays in Firefox Nightly for about two or three days and just found our first web compatibility issue with the Magic 360 library: https://www.magictoolbox.com/magic360/examples/
https://bugzilla.mozilla.org/show_bug.cgi?id=1668342

Given that it's a paid library, is there any chance evangelism would be effective here?

It's unfortunate the web doesn't typically offer any kind of brand checks to identify elements/collections :-/ seems like it'd avoid this class of problem.

There is another issue with flickr.com: https://bugzilla.mozilla.org/show_bug.cgi?id=1669867

Given that it's a paid library, is there any chance evangelism would be effective here?

Fixing the library is good. It is useful to understand how widespread it is and if it relies on a local install or not. Because fixing the library might not fix the websites.


Create marun.txt

There are more then one mail domain for Marmara University, marun.edu.tr is one of them.

@xOrfe I am sorry, the domain marun.edu.tr is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).


Extend the max message size, from default to 10mb.

gRPC has a max message size of 4mb by default.
Extend that to avoid some of the larger update messages causing:
ResourceExhausted desc = grpc: received message larger than max (4944783 vs. 4194304)

+yuhaoh-he for a review :)


Adjust video libraries ownership

As discussed by email. In the Red Hat packages we actually do the same. Thanks!

Thanks a lot! Looks good!

As expected things are fixed now with this change! Thanks!


Live reload in dev mode fails when multiple files are symlinks to the same path.

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
When multiple files within the same project are symlinks to an identical path, dev live no longer works.
Steps to Reproduce

Create a new project.
Create a new file.
Create 2 symlinks to the original file.
Open Atom in developer mode.

Expected behavior: Live reload on edit of either the original file, or when opened via the symlink.
Actual behavior: No live reload.

Please reopen this on the dev-live-reload package.  Thanks!

Reopened: https://github.com/atom/dev-live-reload/issues/25


Linux applications show black screen at start-up in debug mode

Steps to reproduce
Run any application (the counter example for example) in debug mode.
Expected results
No black screens and no flickering in debug mode.
Actual results
It will show a black screen at start-up and if you do some very wild scrolling it will also flicker with black.
It is present in any version >3.22.0, in 3.18.x and lower it works fine.
Code sample
Code sample
flutter create . && flutter run

Screenshots or Video

Screenshots / Video demonstration
https://github.com/flutter/flutter/assets/744771/0c24a746-a8c0-4232-be4d-c9781cf5af08

Logs
No response
Flutter Doctor output
Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, 3.23.0-0.1.pre, on Ubuntu 24.04 LTS 6.8.0-36-generic,
    locale en_US.UTF-8)
[✓] Linux toolchain - develop for Linux desktop
[✓] Android Studio (version 2023.3)

Hi @spydon, what was the behaviour prior to stable 3.22.0? When I ran the app on 3.19.6, I saw a grey screen, is that what you were expecting?

Hi @spydon, what was the behaviour prior to stable 3.22.0? When I ran the app on 3.19.6, I saw a grey screen, is that what you were expecting?
Screencast from 07-02-2024 07:17:00 AM.webm

Yes exactly, since that is the background color of the GTK window.

Thanks for the update.
Labeling this for further investigation.

flutter doctor -v
[!] Flutter (Channel stable, 3.22.2, on Ubuntu 22.04.4 LTS 6.5.0-41-generic, locale en_US.UTF-8)
    • Flutter version 3.22.2 on channel stable at /home/daniel/fvm/versions/stable
    ! Warning: `dart` on your path resolves to /home/linuxbrew/.linuxbrew/Cellar/dart/3.2.2/libexec/bin/dart, which is not inside your current Flutter SDK checkout at /home/daniel/fvm/versions/stable. Consider adding /home/daniel/fvm/versions/stable/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 761747bfc5 (4 weeks ago), 2024-06-05 22:15:13 +0200
    • Engine revision edd8546116
    • Dart version 3.4.3
    • DevTools version 2.34.3
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /home/daniel/Android/Sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /home/daniel/.local/share/JetBrains/Toolbox/apps/android-studio/jbr/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✓] Linux toolchain - develop for Linux desktop
    • Ubuntu clang version 14.0.0-1ubuntu1.1
    • cmake version 3.22.1
    • ninja version 1.10.1
    • pkg-config version 0.29.2

[✓] Android Studio (version 2023.1)
    • Android Studio at /home/daniel/.local/share/JetBrains/Toolbox/apps/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] VS Code (version 1.87.2)
    • VS Code at /usr/share/code
    • Flutter extension version 3.90.0

[✓] Connected device (2 available)
    • Linux (desktop) • linux  • linux-x64      • Ubuntu 22.04.4 LTS 6.5.0-41-generic
    • Chrome (web)    • chrome • web-javascript • Google Chrome 124.0.6367.91

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

[!] Flutter (Channel master, 3.23.0-14.0.pre.117, on Ubuntu 22.04.4 LTS 6.5.0-41-generic, locale en_US.UTF-8)
    • Flutter version 3.23.0-14.0.pre.117 on channel master at /home/daniel/fvm/versions/master
    ! Warning: `dart` on your path resolves to /home/linuxbrew/.linuxbrew/Cellar/dart/3.2.2/libexec/bin/dart, which is not inside your current Flutter SDK checkout at /home/daniel/fvm/versions/master. Consider adding /home/daniel/fvm/versions/master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision f20962672e (4 hours ago), 2024-07-02 22:59:23 -0400
    • Engine revision c5c0c54d6d
    • Dart version 3.5.0 (build 3.5.0-323.0.dev)
    • DevTools version 2.37.0
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /home/daniel/Android/Sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /home/daniel/.local/share/JetBrains/Toolbox/apps/android-studio/jbr/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✓] Linux toolchain - develop for Linux desktop
    • Ubuntu clang version 14.0.0-1ubuntu1.1
    • cmake version 3.22.1
    • ninja version 1.10.1
    • pkg-config version 0.29.2

[✓] Android Studio (version 2023.1)
    • Android Studio at /home/daniel/.local/share/JetBrains/Toolbox/apps/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] VS Code (version 1.87.2)
    • VS Code at /usr/share/code
    • Flutter extension version 3.90.0

[✓] Connected device (2 available)
    • Linux (desktop) • linux  • linux-x64      • Ubuntu 22.04.4 LTS 6.5.0-41-generic
    • Chrome (web)    • chrome • web-javascript • Google Chrome 124.0.6367.91

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

I think this might be a duplicate of https://github.com/flutter/flutter/issues/151098, so linux should be added as a platform there.

It is also happening on MacOs
https://github.com/flutter/flutter/assets/15329494/53a19dae-e532-4c6d-a385-c68e5627b726
and also in AOT mode. M series macbooks are just too fast to see it in release mode, but it is happening
https://github.com/flutter/flutter/assets/15329494/c6ccbd47-b057-46b2-b8f2-2d285bc1bc3c

Due to the rendering changes in preparation for GTK4 the background has changed to black (as set in the OpenGL code). This matches the MacOS behaviour. The background shows when the first frame is not received from Flutter in time (most visible in debug mode). The GTK background is less jarring, but it's a similar issue. It's not clear the correct way of handling this, but we have these options:

Supporting rendering the GTK background, which may not be simple anymore.
[Allowing the background color to be set] (https://github.com/flutter/flutter/issues/149920).
Allowing the app to set the splash screen.
Hiding the window until the first frame is received.

See also the similar MacOS issue.

Upon discussion with a colleague it might be that we're setting the clear color to (0,0,0,1) instead of (0,0,0,0) - I'll test this.

Hmm, no. It doesn't seem to help using a different clear color (or omitting it entirely).

An empty flutter app is expected to render a black window, but a Flutter app should not render anything until it gets its first frame from the Dart code, so there shouldn't be any black flicker if the Dart code paints something other than black.
The fix is probably to delay the creation of the window until we have pixels to draw?

What applications do require the background to be permanently black?

The simplest example of such an app is literally our simplest example:
https://github.com/flutter/flutter/blob/master/examples/layers/raw/hello_world.dart
Another would be the game I'm working on right now, which broke when we regressed this recently (that's how I noticed).

Ideally the flutter part in the background wouldn't show at all that is true, however when parts of the last layer of your window need a transparent effect, they get mixed into the black which is really looking "bad" / "ugly"

Certainly we should support transparency as well, on platforms that support it. We should expose an API to do that (e.g. on SceneBuilder, or FlutterView.render, or similar, which would then be exposed in the framework).

What applications do require the background to be permanently black?

The simplest example of such an app is literally our simplest example: https://github.com/flutter/flutter/blob/master/examples/layers/raw/hello_world.dart
Another would be the game I'm working on right now, which broke when we regressed this recently (that's how I noticed).

Ideally the flutter part in the background wouldn't show at all that is true, however when parts of the last layer of your window need a transparent effect, they get mixed into the black which is really looking "bad" / "ugly"

Certainly we should support transparency as well, on platforms that support it. We should expose an API to do that (e.g. on SceneBuilder, or FlutterView.render, or similar, which would then be exposed in the framework).

Apps using transparency on blank flutter window could wrap themself inside a light / dark material/scaffold to prevent the black window. On the other side, apps you descripe could wrap themself inside a black material / scaffold, or am I misunderstanding something here? If I am not, the not-default-to-black-window approach has the advantage currently that there is no black frame showing up when the app starts (this also happens in AOT mode, not only in debug mode like the ticket opening post describes)

The black frame showing up is a bug (it would be a white frame if we defaulted to white, or a transparent frame if we defaulted to transparent). That's a separate bug from what the default color is.
The default color is black because it's always been black and we need to be consistent across our platforms otherwise people will have a harder time porting apps between platforms.
To reiterate my point from above, an empty flutter app is expected to render a black window, but a Flutter app should not render anything until it gets its first frame from the Dart code, so there shouldn't be any black flicker if the Dart code paints something other than black. The fix is probably to delay the creation of the window until we have pixels to draw.

I think the solution to this ties in with the multi-window support. In the Linux embedder we currently create a view, which creates an engine. So the view is visible before we get the first frame. In the multi-window world we instead create an engine, which creates new views as requested by Flutter. With this architecture we can delay the view until the first frame is received.

I'm not sure it's the same problem and I've not tested on linux, but my app is stuck in a black screen, right after startup, on some Android devices and emulators running Android API 33.
I just updated Android Studio and flutter master channel, created a new app, didn't change anything, and got the same error on an emulator running Android API 33.
Here's the debug log:
Launching lib/main.dart on sdk gphone64 x86 64 in debug mode... Running Gradle task 'assembleDebug'... Warning: SDK processing. This version only understands SDK XML versions up to 3 but an SDK XML file of version 4 was encountered. This can happen if you use versions of Android Studio and the command-line tools that were released at different times. ✓ Built build/app/outputs/flutter-apk/app-debug.apk Installing build/app/outputs/flutter-apk/app-debug.apk... I/flutter ( 4143): [IMPORTANT:flutter/shell/platform/android/android_context_vk_impeller.cc(60)] Using the Impeller rendering backend (Vulkan). E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/android/ahb_texture_source_vk.cc(133)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not allocate device memory for external image : ErrorOutOfDeviceMemory E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/swapchain/ahb/ahb_texture_pool_vk.cc(69)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create hardware buffer texture source for swapchain image of size: (1080, 2337) E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/android/ahb_texture_source_vk.cc(133)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not allocate device memory for external image : ErrorOutOfDeviceMemory E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/swapchain/ahb/ahb_texture_pool_vk.cc(69)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create hardware buffer texture source for swapchain image of size: (1080, 2337) E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/android/ahb_texture_source_vk.cc(133)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not allocate device memory for external image : ErrorOutOfDeviceMemory E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/swapchain/ahb/ahb_texture_pool_vk.cc(69)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create hardware buffer texture source for swapchain image of size: (1080, 2337) E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/android/ahb_texture_source_vk.cc(133)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not allocate device memory for external image : ErrorOutOfDeviceMemory E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/swapchain/ahb/ahb_texture_pool_vk.cc(69)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create hardware buffer texture source for swapchain image of size: (1080, 2337) Debug service listening on ws://<IP_ADDRESS>:37835/YGxMgVO70vw=/ws Syncing files to device sdk gphone64 x86 64... I/silia.aaflutter( 4143): Compiler allocated 4533KB to compile void android.view.ViewRootImpl.performTraversals() E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/swapchain/ahb/ahb_swapchain_impl_vk.cc(111)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create AHB texture source. E/flutter ( 4143): [ERROR:flutter/shell/gpu/gpu_surface_vulkan_impeller.cc(58)] No surface available. E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/swapchain/ahb/ahb_swapchain_impl_vk.cc(111)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create AHB texture source. E/flutter ( 4143): [ERROR:flutter/shell/gpu/gpu_surface_vulkan_impeller.cc(58)] No surface available. E/flutter ( 4143): [ERROR:flutter/impeller/renderer/backend/vulkan/swapchain/ahb/ahb_swapchain_impl_vk.cc(111)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create AHB texture source. E/flutter ( 4143): [ERROR:flutter/shell/gpu/gpu_surface_vulkan_impeller.cc(58)] No surface available. W/Parcel  ( 4143): Expecting binder but got null! D/ProfileInstaller( 4143): Installing profile for com.xxxxx.aaflutter
Here's the flutter doctor:
`Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, 3.26.0-1.0.pre.280, on Linux Mint 21.3 6.8.0-45-generic, locale en_US.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 35.0.0)
[✗] Chrome - develop for the web (Cannot find Chrome executable at google-chrome)
! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.
[✓] Linux toolchain - develop for Linux desktop
[✓] Android Studio (version 2024.1)
[✓] VS Code (version 1.93.1)
[✓] Connected device (1 available)
[✓] Network resources
! Doctor found issues in 1 category.`

@dpedrinha Your issue is not related, the issue I reported was specifically only on Linux.

@dpedrinha Your issue is not related, the issue I reported was specifically only on Linux.

Have you tested it on Android?

But if you didn't test it on other OSs, then it might be related. It's on top of flutter after all.

The issue was specifically in the Linux code (as can be seen in the merged PR), any potential Android issues are unrelated to this.


Dot notation for arrays not supported

In Mongo you can use dot notation both to compare object fields and array elements, but this unfortunately doesn't seem to work in sift:
  sift({'foo.0':42}, [{foo: [42]}] );

returns [], not the expected {foo: [42]}. This makes matching individual array items really hard (impossible?)

:+1:

:+1:


added api using drf

fixes #42
implemented list view and detail view for active porjects using django rest framework

Some other useful apis required:-

api/project/<project_id>/issues/
api/project/<project_id>/issue/<issue_id>
api/project/<project_id>/pulls/
api/project/<project_id>/pull/<pull_id
api/project/<project_id>/contributors/ [+10 Bonus 😋]

@ankitsangwan1999 added required apis and fixed bugs

@DuP-491 Checking


ENG-2187, ENG-2188: Redesigns header and sidebar

Description

Redesigns header and sidebar

Testing required outside of automated testing?

[x] Not Applicable

Screenshots (if appropriate):

Rollback / Rollforward Procedure

[x] Roll Forward
[ ] Roll Back

Reviewer Checklist

[ ] Description of Change
[ ] Description of outside testing if applicable.
[ ] Description of Roll Forward / Backward Procedure
[ ] Documentation updated for Change

Was there a reason to default the side nav to collapsed?
I don't think we should hide those right now, I'm not confident in our understanding of what people need and the side nav will have a full/clear picture of all of our docs and guides for now.

Was there a reason to default the side nav to collapsed?
I don't think we should hide those right now, I'm not confident in our understanding of what people need and the side nav will have a full/clear picture of all of our docs and guides for now.

:tada: This PR is included in version 1.4.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Terraform rule

adds functionality to scan terraform rule
Supports 'and' evaluations
Adds first terraform rule:  'accidental-public-storage'
Adds terraform rule unit tests
updates README to add terraform command

TODO: Docs for terraform rules

Codecov Report

Merging #94 (d1f9a5f) into main (ff3c822) will increase coverage by 5.78%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##             main      #94      +/-   ##
==========================================
+ Coverage   49.01%   54.80%   +5.78%
==========================================
  Files           9       11       +2
  Lines         304      354      +50
  Branches       39       44       +5
==========================================
+ Hits          149      194      +45
  Misses        122      122
- Partials       33       38       +5

Impacted Files
Coverage Δ

src/commands/scan/tf.ts
45.00% <45.00%> (ø)

src/rules/terraform.ts
92.85% <92.85%> (ø)

src/rules/index.ts
75.00% <100.00%> (+2.27%)
:arrow_up:

src/scanner.ts
77.77% <100.00%> (+44.44%)
:arrow_up:

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 ff3c822...d1f9a5f. Read the comment docs.


Source ops

We want to verify that user-facing source-operations on templates work.
This will:

go through list of templates
create an so-updates branch & environment for a template repo
run a user-facing update source operation
verify all is well

It does not (yet, if we want):

create a pull request
verify status/checks passed
auto-merge the PR

It's a bit messy atm, but here it is for the Directus template

For the project ID retrieval issue, since we have the psh cli installed, and it has access to the project, could we use the search feature of the --title parameter? Something like:
platform p:list --title="| ${{ matrix.template }}" --no-header --columns=ID --format=plain
which should return o3fc5w4n5iumy
This of course assumes all of our associated template psh projects all follow the Template | <templatename> format.

@gilzow I didn't try that, but I was thinking that we would run into duplicated (i.e. multiple results for Gatsby). Could just be good reason to update template project names to match template repo names Template | directus, Template | gatsby-drupal

Note: checking the activated environment is ready for the source-op
        # 4. CHECK THE ACTIVATED ENVIRONMENT
        - name: Install Poetry
          run: |
            python -m pip install poetry==1.1.11
        - name: Configure Poetry
          run: |
            python -m poetry config virtualenvs.in-project true
        - name: Cache the virtualenv
          uses: actions/cache@v2
          with:
            path: ./.venv
            key: ${{ runner.os }}-venv-${{ hashFiles('**/poetry.lock') }}
        - name: Install dependencies
          run: |
            python -m poetry install
        - name: Verify environment
          if: steps.activityresult.outputs.result == 'success'
          run: |
            PROJECT_ID=${{ steps.projectid.outputs.result }}
            URL=$(~/.platformsh/bin/platform project:curl -p $PROJECT_ID environments/$UPDATE_ENVIRONMENT | jq -r '._links."public-url".href')

            STATUS=$(URL=$URL python -m poetry run python get_status.py)
            if [ $STATUS -ne 200 ]; then
              echo "Failed."
              exit 1
            else
              echo "Passed."
            fi

Note: Running the source operation

        # 5. RUN THE OPERATION
        - name: Run source operation
          run: |
            PROJECT_ID=${{ steps.projectid.outputs.result }}
            ~/.platformsh/bin/platform source-operation:run $OPERATION_NAME -p $PROJECT_ID -e $UPDATE_ENVIRONMENT --no-wait

Note: following up on the source-operation running

        # 6. FOLLOW UP ON THE SOURCE OPERATION
        - name: Get activity ID
          id: getSOactivity
          run: |
            PROJECT_ID=${{ steps.projectid.outputs.result }}
            ACTIVITY_ID=$(~/.platformsh/bin/platform project:curl -p $PROJECT_ID environments/$UPDATE_ENVIRONMENT/activities  | jq -r '.[0].id')
            echo "::set-output name=id::$ACTIVITY_ID"
        - name: Check activity status
          id: activitySOresult
          run: |
            PROJECT_ID=${{ steps.projectid.outputs.result }}
            ACTIVITY_ID=${{ steps.getSOactivity.outputs.id }}

            ACTIVITY_STATE="in_progress"
            until [ $ACTIVITY_STATE == "complete" ];do
              sleep 10
              ACTIVITY_STATE=$(~/.platformsh/bin/platform project:curl -p $PROJECT_ID environments/$UPDATE_ENVIRONMENT/activities/$ACTIVITY_ID | jq -r '.state')
              echo "Activity state: $ACTIVITY_STATE"
            done
            ACTIVITY_RESULT=$(~/.platformsh/bin/platform project:curl -p $PROJECT_ID environments/$UPDATE_ENVIRONMENT/activities/$ACTIVITY_ID | jq -r '.result')

            echo "::set-output name=result::$ACTIVITY_RESULT"
        - name: Break on activity failure
          if: steps.activitySOresult.outputs.result != 'success'
          run: |
            exit 1

        # 7. FOLLOW UP ON THE SO COMMIT
        - name: Get Commit activity ID
          id: getCommitactivity
          run: |
            PROJECT_ID=${{ steps.projectid.outputs.result }}
            ACTIVITY_ID=$(~/.platformsh/bin/platform project:curl -p $PROJECT_ID environments/$UPDATE_ENVIRONMENT/activities  | jq -r '.[0].id')
            echo "::set-output name=id::$ACTIVITY_ID"
        - name: Check activity status
          id: activityCommitresult
          run: |
            PROJECT_ID=${{ steps.projectid.outputs.result }}
            ACTIVITY_ID=${{ steps.getCommitactivity.outputs.id }}

            ACTIVITY_STATE="in_progress"
            until [ $ACTIVITY_STATE == "complete" ];do
              sleep 10
              ACTIVITY_STATE=$(~/.platformsh/bin/platform project:curl -p $PROJECT_ID environments/$UPDATE_ENVIRONMENT/activities/$ACTIVITY_ID | jq -r '.state')
              echo "Activity state: $ACTIVITY_STATE"
            done
            ACTIVITY_RESULT=$(~/.platformsh/bin/platform project:curl -p $PROJECT_ID environments/$UPDATE_ENVIRONMENT/activities/$ACTIVITY_ID | jq -r '.result')

            echo "::set-output name=result::$ACTIVITY_RESULT"
        - name: Break on activity failure
          if: steps.activityCommitresult.outputs.result != 'success'
          run: |
            exit 1
        - name: Verify environment
          if: steps.activityCommitresult.outputs.result == 'success'
          run: |
            PROJECT_ID=${{ steps.projectid.outputs.result }}
            URL=$(~/.platformsh/bin/platform project:curl -p $PROJECT_ID environments/$UPDATE_ENVIRONMENT | jq -r '._links."public-url".href')

            STATUS=$(URL=$URL python -m poetry run python get_status.py)
            if [ $STATUS -ne 200 ]; then
              echo "Failed."
              exit 1
            else
              echo "Passed."
            fi


compressionLevel option ignored when exporting database

OrientDB 2.1.2
Choosing different values for compressionLevel resulted in the same output file myDB.export.gz which I believe is compressed at level 9. Used the following command to export
sh /usr/orientdb/bin/console.sh "connect remote:localhost/myDB dbUser dbPassword;export database /home/z/db.exported/myDB.export -compressionLevel=0;" 1> /dev/null

Hi @Ziink by default is compressed at level 1.
http://orientdb.com/docs/2.1/Console-Command-Export.html#syntax

I was just guessing at the compression level. The main thing is that you can't get an uncompressed file if you specify compressionLevel=0

However is ignored i just tested.
I m working on the fix.
Il 22/set/2015 19:53, "Ziink"<EMAIL_ADDRESS>ha scritto:

I was just guessing at the compression level. The main thing is that you
can't get an uncompressed file if you specify compressionLevel=0
—
Reply to this email directly or view it on GitHub
https://github.com/orientechnologies/orientdb/issues/4989#issuecomment-142364268
.

@Ziink
so with -compressionLevel=0 you would like to have the plain file ?
The Daflater also supports compression level = 0 that means you will get a
.gz file without compression
http://docs.oracle.com/javase/6/docs/api/java/util/zip/Deflater.html#setLevel(int)

To me plain file makes the most sense for zero compression. I'm using rsync to synchronize the exported file to another server.


As a developer, to provide a good Chirp application, we want to add additional feature(s).

Implement more features to Chirp!
Success Criteria:

Implement one or more user features.

Inspiration:

Ranking or liking of cheeps
Tags in cheeps (for example, strings preceded by a # sign might be indexed and cheeps containing tags might be listed in a separate page)
List of trending cheeps based on likes or tags
Support of images in cheeps
"Re-cheeping", i.e., forwarding of cheeps that are send by others to own timeline and own followers.

A Search for Authors feature has been chosen, implemented and tested


feat: initialize submission from my collection artwork

This PR resolves ONYX-978
Description
This PR adds support to initializing a submission from my collection.
Note: While working on this I noticed a lot of code related to this in the global store that we can get rid of as soon as we release the feature and have a more clean global store. We can as well use it for the save & exit 🤷
https://github.com/artsy/eigen/assets/11945712/de949e3d-b0c8-47dc-9ea8-23a34a4dd32d

PR Checklist

[x] I have tested my changes on iOS and Android.
[x] I hid my changes behind a feature flag, or they don't need one.
[x] I have included screenshots or videos, or I have not changed the UI.
[x] I have added tests, or my changes don't require any.
[x] I added an app state migration, or my changes do not require one.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

initialize submission from my collection artwork in new submission flow - mounir

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

This PR contains the following changes:

Cross-platform user-facing changes (initialize submission from my collection artwork in new submission flow - mounir)

  Generated by :no_entry_sign: dangerJS against cca62c95ca47084061bcd126bc09b8a593c6675d


Minification breaks a 3rd party lib -- possible to configure UglifyJS?

Description
I reported this issue to the library maintainers and the leading theory is that it's caused by the minifier is mangling class names that are subsequently identified by their representative string.
A possible fix is to pass the mangle.except option to UglifyJS. Does CRNA expose this anywhere, and if ejection is required, how would I configure the minifier in this manner?
I tried looking for hints in the upstream project https://github.com/facebook/metro-bundler but it's not obvious that there's any way to override this flag.
Expected Behavior
N/A
Observed Behavior
N/A
Environment
N/A
Reproducible Demo
N/A. I wrote a minimal repro of the original issue here but it's not entirely relevant to this inquiry/feature request.

CRNA probably doesn't and won't support this, so I'm switching to https://github.com/callstack/haul

Probably the easiest way to make this work is to just add a npm postinstall script to modify that config for you in node_modules. The best way would be to submit a patch to metro to make it configurable


Added PnP PowerShell example to existing export all flows CLI sample

🎯 PR aim
Added script for PnP PowerShell for existing sample
✔ What was done

[X] updated readme with PnP PowerShell script
[X] updated Sample.json to add PnP PowerShell and Author

Hey @LeonArmston , thank you!! 👏😊 This should be live shortly 😊 Sorry took a while to process, btw, I reversed the author list on the sample.json file due to a small order issue, where the latest author is hidden behind the others, so updated sample authors to highlight your work. :-)


[DNM] Testing swiftpm-testing-helper tool discovery for tests on Darwin platforms

Testing some changes to https://github.com/swiftlang/swift-package-manager/pull/7766

Introduce swiftpm-testing-helper and install it into toolchain
Use SwiftSDK rootpaths to discover the tool while running tests - it would either be in .build/<config> if it's a local build or in usr/libexec/swift/pm if it's an installed toolchain.

Closed as we've cherry-picked it to my PR, #7766.


Path resolution is broken on Windows

I have checked the following:

[X] I use the newest version of bruno.
[X] I've searched existing issues and found nothing related to my issue.

Describe the bug
In some cases the filesystem paths are not evaluated correctly and this results in several issues, some reported as separate bugs. E.g. renaming requests on WSL paths (when running natively on Windows): #2269 fails, becasue the request file path is transformed to /wsl.localhost/blabla but it should be \\wsl.localhost\blabla or //wsl.localhost/blabla. Unfortunately double slashes are "normalized" to single slashes which is not correct behavior.
For the same reason the Ignored files feature does not work on wsl or network paths, in which case the path resolution results in nonsensical c:/wsl.localhost/blabla during one of the comparison operations.
It may be fixed in a case-by-case manner, e.g. as I attempted in #2421 in regards to relative certificate paths, but the problem is more general, possibly caused by a bug in a dependency (e.g. bruno is using /jinder/path 0.12.7 module from 9 years ago instead of build-in node module.
.bru file to reproduce the bug
No response
Screenshots/Live demo link
N/A

I can replicate this bug. It also affects new file creation, as the file path is also prepended with a C: when the wsl drive is a simulated network drive (\\wsl.localhost). I think this is also the reason for #2524

Some more information about this issue.
I'm using the Bruno Desktop App version 1.34.2, running on Windows and accessing a collection on my WSL with a Location of \\wsl.localhost\Ubuntu\home\beebs\workspaces\techniques\bruno-oauth\Demo-Auto-Token-Cache.
In the Bruno Desktop App gui, I can see .git listed as a folder even though it is also configured as an Ignored file as per:
{
  "version": "1",
  "name": "Demo-Auto-Token-Cache",
  "type": "collection",
  "ignore": [
    "node_modules",
    ".git"
  ],
  "presets": {
    "requestType": "http",
    "requestUrl": ""
  }
}

Actual : .git directory is shown in the Collection even though it is listed as an ignored file.
Expected : .git directory is not shown in the Collection because it is listed as an ignored file.


allow subdomains to have multiple parents

It was only for convenience that subdomains have a single parent, but nothing logically prevents them from having multiple parents, we just have to implement it. Currently it isn't even checked whether two different domains use the same subdomain as children, so it just silently replaces the _parent field with the second one, and this leads to bugs where the first domain doesn't get assigned (if the parents are the dependent ones and the children are the independents domains).
Generalize to allow an arbitrary DAG, rather than a tree, describing subdomains.

We had talked about enforcing the constraint that either exactly one, or at most one, domain is independent on any path from a source to a sink.
Suppose we enforce that it is exactly one. In the case of a tree, this makes every domain "uniquely assignable". But this is not true for an arbitrary DAG. Suppose we have two domains d1 and d2 with a shared subdomain s. They could overlap like this:
d1 -------------------------------->
d2                       ---------------------------------->
s                        ---------->

Then if we declare s is dependent and d1, d2 are independent, this obeys the constraint that there is exactly one independent domain on any source-to-sink path. However, s is not "uniquely assignable", it could be changed by assigning to either d1 or d2. Worse yet, if we assign to d1, we have to change d2 also since they overlap.
Now, maybe this is not a big deal to allow this non-unique assignability. However, we probably want to change how we represent domain sequences. In particular, going through the entire DAG each time one is updated and updating the other sequences might be hard to do efficiently.
A better approach might be to traverse the DAG once before the search and create a single long mutable string. This string won't necessarily be the sequence of any domain or strand in the system. Above, it would be the "union" d1 and d2. Then each domain would store intervals, start and end indices into this long string, and when one is updated, we just update that substring. This would then immediately reflect the changes in every other domain.
We would still have to somehow track which domains changed, so that we know which constraints need to be reevaluated.


Validate Apify proxy country

Adds validation for the selected country for Apify proxy.

@gippy That's a good point, added the check in 8c54d99.


[bugfix] navigation review and confirm

Motivación y Contexto
Anteriormente el back físico y el back de la toolbar no operaban de la misma manera.
Cómo probarlo
Desde revisa y confirma debería navegar back a grupos.

Codecov Report

Merging #1066 into feature/onetap_complete will decrease coverage by <.01%.
The diff coverage is 0%.

@@                     Coverage Diff                     @@
##           feature/onetap_complete    #1066      +/-   ##
===========================================================
- Coverage                    27.72%   27.71%   -0.01%
===========================================================
  Files                          321      321
  Lines                        15089    15092       +3
  Branches                      1384     1384
===========================================================
  Hits                          4183     4183
- Misses                       10377    10380       +3
  Partials                       529      529

Impacted Files
Coverage Δ

...o/review_and_confirm/ReviewAndConfirmActivity.java
0% <0%> (ø)
:arrow_up:

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 eea3a9c...c574933. Read the comment docs.


Add mcap_vendor using fetchcontent for lz4 & zstd dependencies

Another alternative to #26 & #27. We make mcap available as a shared library, but it does not depend on lz4/zstd shared libraries.
Closes #26, closes #27
Thinking out loud: since libmcap.so now contains the lz4 & zstd symbols, does that make it impossible for another package to depend on both libmcap.so & liblz4.so?

cc @nuclearsandwich

Ping @nuclearsandwich @emersonknapp Would you two have a moment to provide your thoughts on this packaging setup, as a solution to the concerns in https://github.com/ros/rosdistro/pull/32534#issuecomment-1086286672 ?

My feedback is already on the tardy side and I haven't sunk in to provide any suggested alternatives.
Firstly, I think this is a tremendous improvement over the previous setup using conan and I really appreciate the efforts put forward to bring this package closer in convention to existing vendor packages and avoid side-loading dependencies from external systems.
Compared to other vendor packages, I think this vendor package is doing "extra work" that would normally be handled by the vendored package upstream. In particular, vendoring the zstd and lz4 static dependencies is something that I'd expect the mcap project to be doing upstream.. of course, if it's doing that upstream via conan that doesn't help us as much. I don't object to this package as is. If the maintainers wanted to push it in a direction matching other vendor packages which are very thin shims designed to make packages unavailable to ROS available as-is, then one option would be to push down some of the internal dependency vendoring to the upstream mcap package so that the only things happening in the vendor package are:

building the mcap package if it is not already available
setting any environment hooks so that packages which find_package(mcap_vendor) can then successfully find_package(mcap) and use it transparently.

For most vendor packages the eventual goal is upstreaming the library dependency so that when the vendor package is retired, rosdep keys can be updated to point to the upstream key instead of the vendor key, the find_package(mcap_vendor) line is dropped from CMakeLists.txt and everything else remains as-is.
Again, I don't consider any of the above feedback to be requesting mandatory action! I have immense gratitude for the work done to bring this package in line. To the extent I'm available I am happy to contribute further if requested. Thanks!

@nuclearsandwich thanks for the feedback. Since the upstream package is a header-only library that uses conan to pull in dependencies for static linking, I think this is as close to canonical ROS vendor packaging we'll get. If the upstream library changes in a substantive way in the future we can definitely revisit the mcap_vendor approach.

That seems entirely reasonable to me. The minimal vendor package assumes that the vendored package is a sound plain CMake package which doesn't need much more than a build configuration and maybe some installation assistance for environment variable configuration but this does more because more needs to be done and that's fine.


Chore/ddw 206 Create PR template with review checklist

This PR adds PR template with review checklist: https://github.com/input-output-hk/daedalus/blob/chore/ddw-206-create-pr-template-with-review-checklist/.github/pull_request_template.md

Thanks @DominikGuzei! We need @darko-mijic's approval for this one :)


Module Pos.Client.Txp.Util not found error while trying to build daedalus-bridge

When I run npm run start inside the folder cardano-sl\daedalus, I get the following error message:
ERROR in [1/1 ModuleNotFound] src/Daedalus/Types.purs:37:1  37  import Pos.Client.Txp.Util as CLI      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  Module Pos.Client.Txp.Util was not found.  Make sure the source file exists, and that it has been provided as an input to psc.           Src   Lib   AllWarnings   0     0     0Errors     1     0     1webpack: Failed to compile.webpack: Compiling...   430 moduleswebpack: Compiled successfully.

After looking into it a bit more, it seems like purescript-bridge is not generating corresponding PureScript data types for Pos.Client.Txp.Util.
I'm looking into how to make that happen.

In order to generate updated data types from Haskell for Purescript to use, I did the following:
- cd ~/Projects/cardano-sl
- cd wallet
- stack build
- stack exec cardano-wallet-hs2purs

I then copied everything generated under ~/Projects/cardano-sl/wallet/daedalus to ~/Projects/cardano-sl/daedalus/src/Generated


Add Manchester and New York to the Software Crafters communities

Adding an entry for the Manchester "Software Crafters North" community and New York "New York Software Craftsmanship" community.

Apologies, I would have created two separate forks for the Manchester and New York additions but I didn't consider that I'd need to delete one before I could do the next.

Thanks for adding them!


magboots, galoshes and flippers no longer butcherable

About the PR
closes #10840
Changelog

:cl:

tweak: magboots, galoshes and flippers no longer butcherable

How do i fix this failed check?

How do i fix this one failed check?

Erroneous test fail. Dw about it.


broadcast 'reconfigure' event when putConfig

Broadcast the UMF message to service which match the first part of config label. This allow matching service to have a chance to capture the config change and do reconfigure itself.

Thank you @emadum, I fixed it to use the short format

@cjus After the pull request merged, and hydra-cli apply use it. I will test and release the following plugin
https://github.com/khoinguyen/hydra-reconfigurable-plugin

@khoinguyen closing this for now.  We're rethinking how configurations should be supported in the future.


Update README.md

It's not a new dataset..it's just a new pxd number because they added one
more raw file to the list. Could you please add this workflow image and
change the folder name?
Thank you so much!
Subina
On Mon, Aug 24, 2020, 5:45 PM Björn Grüning<EMAIL_ADDRESS>wrote:

@bgruening commented on this pull request.
In proteomics/mPXD018682/README.md
https://github.com/galaxyproject/SARS-CoV-2/pull/213#discussion_r475911940
:

@@ -1,5 +1,5 @@

-title: Metaproteomics of PXD018682
+title: Metaproteomics of PXD019423
@subinamehta https://github.com/subinamehta is that a new dataset? If
so I need to change the folder name and a few other references to this page.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/galaxyproject/SARS-CoV-2/pull/213#pullrequestreview-473878534,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGP3A7I44KNYSVYDCRSGQH3SCLNN5ANCNFSM4QJ4UJ5A
.

@subinamehta I pushed a few extra commits can you check the website from the frontpage on?

Sure
On Wed, Aug 26, 2020, 12:57 PM Björn Grüning<EMAIL_ADDRESS>wrote:

@subinamehta https://github.com/subinamehta I pushed a few extra
commits can you check the website from the frontpage on?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/galaxyproject/SARS-CoV-2/pull/213#issuecomment-681002946,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGP3A7IA4ZK2EQUGITGE2VLSCU5HVANCNFSM4QJ4UJ5A
.


Functional Application

Now that it was possible to test with the full data set of packages, it seems the current design of the backend must change.
Initially on datasets of 100 packages or less, things seemed rather functional. But once within Cloud File Storage, the application was tested against the actual value of about 11,000 unique packages. At this point the backend became unreasonably slow. A request for all packages sorted and pruned would take <300 seconds, at which point the server hosting the backend, cut off the response due to assumed inoperability. This happens because the backend was trying to read each file one by one.
At this point it was obvious a file store wouldn't work, and there were hopes of moving the full JSON objects into an online Database.
This functionality was initially tested alongside full file store functionality, but even then, interacting with the DB as if it were a file system, while provided improvement, to 40 seconds reads of all packages, with cached reads about 8 ms. This still wasn't enough.
At this point it should seem obvious that huge portions of the codebase will have to be rewritten to work within a database, and abandon all file store functionality.
This goes out as an update to any that are contributing on the project, that while the efforts so far have been fantastic, one huge push is needed to get it worked to our expectations.

I have a website working with an internal sql database. Previoulsy mySql, then migrated to MariaDB.
Don't know if I can be of any help since the implementation I use is in PHP.

@Digitalone1 if you'd like to link it I'd be happy to take a look at it. Currently I've started to implement it similarly to how resources.js. You can look at database.js to see some of the functions that are there. If familiar with the syntax for Postgres feel free to add it to those functions where its missing, as I'll be adding more soon. But thats good to know you're familiar with it. Since the syntax is new to me

Never used PostgreSQL, but the queries should be in SQL languages like MariaDB, so I could do something with it.

Anyway, since we are handling with the database, could you report how the data is structured?
How many tables are stored, how data is organized, how records are indexed and so on...

@Digitalone1 currently the data is stored rather generically, but hopefully with time it will be further expanded to properly suit the data. I'll do a write up on how its stored within the repo, and ping you once its there.

Well, this is not optimal. Since you use a database, first you have to organize the tables, then the relations between them.
This helps also to speed up the reads and writes. Choosing the proper primary key for packages makes it efficient to search between them.
This has to be done otherwise also with the database you can have very high load times.

@Digitalone1 I understand the concern and am aware its not optimal. Although postgres does index jsonb datatypes, which is what its stored as. So while we will want to migrate in the future, we need to do what we can to have a functional application sooner rather than later.
But for example currently if I wanted to query every single version of every single package like so
SELECT pointer, versions FROM packages, jsonb_object_keys(data->'versions') AS versions

That currently returns 69959 rows, and takes 1.530 seconds. Which should be fast enough for our current concerns, while of course it can be faster.
But for the meantime, I finally got around to creating a quick docs of the database to help out any contributors looking at it.
The database docs are within './docs/'

That is a read of all records. It's generally fast. The problem is when you add the WHERE clause and start to select records with conditions.
Did you test it? For example selecting packages of a single user. Or a simple search by name with the ORDER BY clause to show packages with more stars.
I hope it's quite fast also in these cases.

@Digitalone1 You do have a point in decreased performance with more complex queries, heres some of the testing that I've done so far, please feel free to let me know if you see anything thats cause for concern going forward, since I'd like to get it up and then work on normalization, but if we should normalize first, then get started that's just what we have to do.
SELECT pointer FROM pointers WHERE name='teletype';

Time: 00:00:00.152
Now another example that I've currently added to the codebase. Creating an array of results, of all packages, ordered by the downloads count. Additionally its limited to 30 items, with no offset. Representing the default parameters for GET /api/packages/.
SELECT ARRAY (SELECT data FROM packages ORDER BY data->'downloads' DESC LIMIT 30 OFFSET 0);

Time: 00:00:02.064
So while not the fastest, it seems acceptable to me for functionality, especially considering that previously with no database this same exact request would take <300 seconds. Eventually timing out. But what do you think?

@Digitalone1 Also on the note of searching, since you're more familiar I was hoping to keep the use of the custom LCS implementation I made, and while I could retrieve all rows of the pointer table and use that for some relatively fine performance, I was curious how difficult or even possible would it be to implement that on the DB itself. Or do you think performance will be markedly better using included search capabilities

Two seconds does not seem so good. Take in consideration that the server may be loaded with more requests at the same time, the response might be longer.
Can you make also a search by name? Ordering also by download count.
I'll tell you what it's happening in this case. I suppose you are using a default primary key which should be something such as an integer incremented every time a new record is stored.
If you want to pick a specific package the system has to scan all the records, even if it already found that package because it does not know that the package is unique.
If you specify a key on the package name, the search will be faster because the DB creates an index on that column to access elements quite instantly (I assume it uses a sort of hash table).
So I think it's important to establish which is the relation between the packages and the other entities involved in the process.
For example, the package names must be unique? Let's make the name as primary key. The name can be duplicated, but a single user must have different package names? The pair of package name and username can be be set as primary key.
Then there's also the question about redundancy. If the package contains the user data and a user stores 10 packages, you have data repeated 10 times in the database which is a waste of space.
Packages and users are separate entities, they should be in different tables and linked by foreign keys.
If you tell me which are the entities and which relations exist between them, I can write a list of tables to store on the DB.
I will also take a look to the full package in the documentation when have time to make an idea. Anyway the first thing to take in consideration is how packages are uniquely identified.

@Digitalone1 Also on the note of searching, since you're more familiar I was hoping to keep the use of the custom LCS implementation I made, and while I could retrieve all rows of the pointer table and use that for some relatively fine performance, I was curious how difficult or even possible would it be to implement that on the DB itself. Or do you think performance will be markedly better using included search capabilities

I don't remembered that part, can you link it?

@Digitalone1 Appreciate all the information! And that is a good point about multiple requests slowing service down.
As for the keys I'm still using those UUID's generated during package creation. Since the User, nor package Name are effective keys, since the name can change, and the user can be migrated. But an interesting thing is that once a name has been used, it will always point to the same package, even when that packages name changes. Thats why I originally made the package pointer system.
In this case now there is a table with package names, and the package UUID associated. There can be several rows that point to the same UUID, since the name can change, but the previous one still points to the same package.
Then another table uses these UUIDs as the primary key. So that if you need to get a package by name you retrieve the UUID like so
SELECT pointer FROM pointers WHERE name=${name}

Now you have its primary key for the packages table. So then based off what you're saying hopefully that means for searching operations it will know the package is unique when referred to by the UUID and it won't have to scan all records?
And if you are taking a look at this, I don't have a table yet for the users, if thats something you'd be willing to take a look at as well? Since tracking what user creates a package doesn't seem as important, since the ownership of a package is determined based on the access level of that package from the user on GitHub. So really it'd be more important to establish a relationship between the users, and the packages they have stared.
Lastly sorry if I forgot to ping this to you, but heres a really short write up on the way the db is structured if it helps.
https://github.com/confused-Techie/atom-community-server-backend-JS/blob/main/docs/database.md

Since the User, nor package Name are effective keys, since the name can change, and the user can be migrated. But an interesting thing is that once a name has been used, it will always point to the same package, even when that packages name changes. Thats why I originally made the package pointer system.

The fact that they change could not be an issue. I have a username and I can change it, but will I be able to set it the same as another existing user? I hope not. The package I created can be changed, but can I have two packages with the same name? I hope not.

So that if you need to get a package by name you retrieve the UUID like so
SELECT pointer FROM pointers WHERE name=${name}

Now you have its primary key for the packages table. So then based off what you're saying hopefully that means for searching operations it will know the package is unique when referred to by the UUID and it won't have to scan all records?

Yes, you won't scan all records if the search is made by UUID, the access is quite direct.

SELECT * FROM packages WHERE pointer = ${uuid}

This query is optimized to be faster.

And if you are taking a look at this, I don't have a table yet for the users, if thats something you'd be willing to take a look at as well? Since tracking what user creates a package doesn't seem as important, since the ownership of a package is determined based on the access level of that package from the user on GitHub. So really it'd be more important to establish a relationship between the users, and the packages they have stared.

I didn't understand this part. I have to admit I didn't fully get what this server backend is managing. Isn't it for packages that can be installed in atom/pulsar as extension? If I create a package, how can I lose it's ownership? This is not even happening on Github. If I make a repository, I have it's ownership, unless I delete it.

@Digitalone1 Yeah no worries on duplicate packages or user names, since once you create a package that name is taken, really permanently, or at least thats how it was setup on the original Atom Repository. Even if you change its name, that original one you used always points to the package.
But what I was trying to say on the users. You mentioned the relation to users and the packages. I was more trying to say that the relation of creating packages is not very important. Since the backend doesn't have to store that info. Its more important for the backend to store what a user stars.
But yes the backend is managing the packages that can be installed for Atom/Pulsar. But in short what happens when you create a package here.
You query the backend with your repo saying I want to make this package. Providing the owner/repo from there the backend ensures that the name of your repo isn't taken. Then it'll use a GitHub API to find out what repos your GitHub account owns, and if you own the repo specified here then it'll start the publishing process. So thats to say we don't need to do anything on the database end to determine ownership, like having users linked to packages. And theres no endpoint that asks for the packages a user owns at all.
As for the query you made looking for a pointer that is what happens when you ask for a specific package. For example its already in use here https://github.com/confused-Techie/atom-community-server-backend-JS/blob/d22ba218d5300b12011926457a156664ec2f2552/src/database.js#L43-L46

When I have time I'll do a pseudo SQL code with CREATE TABLE.
If you say the package is not related to the user, then the current index with UUID can stay.
For performance it would be better if the package names were unique. But if they can be duplicated, the UUID index is good, no need to do like atom having the first name pointing to the package. The UUID is enough.
But since you say it's important to count the stars given by users, we still need a different table for users.
And, as far as I remember, packages can also have different versions, so we should also have a separate table listing the versions.
@confused-Techie I will give a look at the full package object anyway, but if there are other entities involved, list them here, so I won't forget.

I appreciate you taking a look at it. But yes the users do need their own table, and there should be a user object example in the docs, or within the ./data/users.json file can be a good reference. Since thats something that I'm not sure what the best methodology is for creating that table. Otherwise yeah with the packages there is the basic data that it needs, like the readme, metadata, created_at, updated_at and so on. But the important bits would be things like the star_gazers, which originally was an array of the user names of who has stared a package, plus for each user they also had a list of all packages they have starred. Hopefully this redundancy can be removed. Then like you said the versions of each package.
As for constructing the table, I'd suggest looking at the server_package_object since it contains additional data that the full package does not.

So this is a first sketch
CREATE TABLE Packages (
   ID INTEGER AUTO_INCREMENT NOT NULL,
   Name VARCHAR(256) NOT NULL,
   Description TEXT,
   Repository JSON,
   Keywords TEXT,
   Download UNSIGNED INT NOT NULL,
   PRIMARY KEY (ID)
);

CREATE TABLE PackageVersions (
   ID INTEGER AUTO_INCREMENT NOT NULL,
   PackageID INTEGER NOT NULL,
   SemVer VARCHAR(50) NOT NULL,
   Engine JSON,
   License VARCHAR(50),
   PRIMARY KEY (ID),
   FOREIGN KEY (PackageID) REFERENCES Packages(ID)
);

CREATE TABLE Dependencies (
   PackageVersionID INTEGER NOT NULL,
   PackageID INTEGER NOT NULL,
   Relation VARCHAR(256) NOT NULL
   PRIMARY KEY (PackageVersionID, PackageID),
   FOREIGN KEY (PackageVersionID) REFERENCES PackageVersions(ID)
   FOREIGN KEY (PackageID) REFERENCES Packages(ID)
);

CREATE TABLE Users (
   ID INTEGER AUTO_INCREMENT NOT NULL,
   PulsarToken VARCHAR(256) NOT NULL,
   GithubToken VARCHAR(256) NOT NULL,
   PRIMARY KEY (ID),
);

CREATE TABLE Stars (
   PackageID INTEGER NOT NULL,
   UserID INTEGER NOT NULL,
   PRIMARY KEY (PackageID, UserID),
   FOREIGN KEY (PackageID) REFERENCES Packages(ID)
   FOREIGN KEY (UserID) REFERENCES Users(ID)
);

Note that this is in MySQL/MariaBD, the syntax can be slightly different in PostgreSQL, but the concept should be identical.
The Packages table represents the entity of packages which can have one or more versions listed in the PackageVersions. Now the foreign keys are important because they ensure the integrity of the data stored into the DB.
I can't store in PackageVersions a version related to an unexisting package, which means when I fill the PackageVersions table, the PackageID has to be one of the ID present in Packages. If I try to write an ID not present in Packages, it's an error, the engine does not allow the operation.
At the same time, if I want to delete a package, I can't do it if there are one or more related versions. If there are some versions, I have to pick the ID from Packages, then go to PackageVersions and delete all records with PackageVersions.PackageID = Package.ID. At last you can delete the ID from Packages.
There are other things to implement anyway, such as the configSchema which I don't know what it means. This is incomplete, but it's done as a first reference.
@confused-Techie if you have doubts, feel free to ask. If I have time, I'll try to do a SELECT query for star count.

For Stars and Dependencies I made a many to many relationship. Please take a look here.
A version (of a package) can have more packages as dependencies and a package can be a dependency of more versions (the Relation column can be for example ^0.4.1).
A user can prefer more packages (giving a star to them) and a package can have more preferences (stars from users).
For getting packages and their stars:
SELECT Packages.Name, COUNT(UserID) AS StarCount,
FROM Packages, Stars,
WHERE Packages.ID = Stars.PackageID
GROUP BY Stars.PackageID
ORDER BY StarCount DESC

I do not guarantee this works. I would have to test it (and maybe in PostgreSQL the query should be different).

@Digitalone1 Sorry for a late reply, but looking at this looks fantastic, definitely a bit more complex than what's currently setup. I really do like the idea of storing stars within their own table, instead of duplicating the data across two separate tables. And removes the concerns that were there with JSON files, about incomplete removal or addition to stars.
I'll have to see about adding this to it, and making sure everything's compatible, which it all looks rather familiar.

@confused-Techie when I have time I'll try to write the previous statements in PostgreSQL, so you could try to execute them to build the tables directly. I'm not familiar with it, I have to look at the documentation. Maybe it's similar, but I'm pretty sure some types have to be rewritten along with the syntax related to the primary/foreign keys..

@confused-Techie I made some researches. The relational model above is good, but it requires to convert our JavaScript data in DB data. For example we have to extract name, description repository data, keywords and download count to make an insert query in order store a new package.
With JSON we can pass it directly (entirely or a portion). It's more straightforward. But the good of the relational model is that it guarantees data integrity using foreign keys, which is crucial for our scopes, especially when we are dealing with package dependencies and user stars.
So my proposal is to keep the tables and their keys as they are defined above, but the rest of the data is stored ad JSON in a specific column. Or rather, in jsonb which gives some advantages.

Here are the syntax in PostgreSQL
CREATE TABLE packages (
    id SERIAL PRIMARY KEY,
    data JSONB NOT NULL
);

CREATE TABLE packageVersions (
    id SERIAL PRIMARY KEY,
    packageId SERIAL REFERENCES packages(id), /* foreign packages key */
    data JSONB NOT NULL
);

CREATE TABLE Dependencies (
    packageVersionId SERIAL REFERENCES packageVersions(id), /* foreign package versions key */,
    packageId SERIAL REFERENCES packages(id),               /* foreign packages key */,
    relation VARCHAR(32) NOT NULL,                          /*i.e. "^0.4.1"*/
    PRIMARY KEY (packageVersionId, packageId)
);

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    data JSONB NOT NULL
);

CREATE TABLE Stars (
    packageId SERIAL REFERENCES packages(id), /* foreign packages key */,
    userId SERIAL REFERENCES users(id),       /* foreign users key */,
    PRIMARY KEY (packageId, userId)
)

@confused-Techie how do you want to proceed?

This is fantastic thank you @Digitalone1. I do like the idea of pushing some of the data into the jsonb datatype, and leaving as is. Additionally looking at it now it seems that the Dependencies may not be needed since I don't see any logic that interacts with them at all. And that data is just returned as JSON for the packages. But will absolutely implement the users and Stars right away as those will be the last most needed tables. Otherwise I will need to find a way to programmatically populate the packageVersions table. But otherwise this is fantastic work

@Digitalone1 I've gone ahead and created nearly all tables based off the provided recommendations, except for leaving the packages table as is, since the data has already been migrated.
I've gone ahead and included the create_scripts in the repo.
Thanks for the recommendations, and suggestions.

Did you migrate the data?
It's good having the uuid, but you have to remove the versions object from package_object_full stored into the packages and move it inside the package_versions.
CREATE TABLE packages (
    uuid UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    data JSONB NOT NULL
);

CREATE TABLE packageVersions (
    id SERIAL PRIMARY KEY,
    packageId UUID REFERENCES packages(id), /* foreign packages key */
    data JSONB NOT NULL
);

For migration, I suppose you have all the full packages collected into an array. The script shoud be something like this
for (let package of array_of_package_object_full) {
  let versions = package.versions; /* save versions */

  delete package.versions; /* remove versions from package */

  const json_package = JSON.stringify(package);

  const uuid = await sql_storage`
    INSERT INTO packages (data)
    VALUES (${json_package})
    RETURNING uuid
  `; /* It should return the uuid of the new row */

  /* Now let's store versions */

  for (let ver in versions) {
    const json_version = JSON.stringify(version[ver]);

    await sql_storage`
      INSERT INTO package_versions (packageId,data)
      VALUES (${uuid},${json_package})
    `; /* store version object with relative foreign key */
  }
}

EDIT 2: Also I've noticed you're change from the users table to containing just the jsonb object, with the fact that as its currently implemented we only would need the atom_token, github_token and created_at values tracked, maybe we could use just that to have a fully normalized table. Additionally this may actually be helpful since auth is only with a provided token, and having it normalized could allow us to check all possible atom_tokens rather easily.

No problem, you can create the needed columns. I suppose the tokens are fixed length, so they would be CHAR(num).
Regarding created_at, postgresql tutorial suggests TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, so at row creation you wouldn't even specify a value, it's automatically set the current timestamp.
Anyway I'm a bit concerned about the data integrity because a spammer could change their name and register as a new user to leave more votes? Could that be possible? How can we identify a user uniquely even if they changes name?

Ideally when a user changes their name the normal way, the id would stay the same so they couldn't cast additional votes. But if they were to create a totally new account then there is zero logic to prevent them from casting additional votes.
One hump to that attempt of spam would be that an account is linked to GitHub, and likely will share the user name there, so that we don't need any logic to change the user name, it would just be changed on GitHub and then we need an updated token relating to that new name, since having the old name would cause current ownership logic to fail. It's not the most robust of plans, but is how it'll currently happen, since admittedly it wasn't one of my top priorities.
Beyond that we aren't doing anything to stop it, and personally I'm not sure thats within our scope to try and stop spam stars to that extent. Really I feel our priority would be to stop spam packages from entering the system, but I could be completely wrong on that.
Would you have any ideas on how we could go ahead and attempt to prevent spam stars?
Also for your comments on the created_at that does sound so much more convenient. Before you mentioned it, I did create that column with the bigint datatype, but will see about changing that to TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP since that sounds very helpful

So, my 2 cents (didn't look at the full discussion, sorry) is that we could tie an user to a group of repos, like:
users -> git_repositories and git_repositories could have for example the kind (GitHub,  Gitlab, Gitea at least) maybe URL (for self-hosted instead of cloud repos) and then we could integrate with respective git providers to have tokens (that way we won't have Auth information on our side, which is a big plus for me).
As of preventing SPAM, there are some tutorials on using SpamAssassin from other projects, so maybe we can check for packages with READMEs and other docs that have high points and alert something, so we can approve or reject them?

users -> git_repositories and git_repositories could have for example the kind (GitHub, Gitlab, Gitea at least) maybe URL (for self-hosted instead of cloud repos) and then we could integrate with respective git providers to have tokens (that way we won't have Auth information on our side, which is a big plus for me).

That sounds good. With could also use the tokens as primary key.

As of preventing SPAM, there are some tutorials on using SpamAssassin from other projects, so maybe we can check for packages with READMEs and other docs that have high points and alert something, so we can approve or reject them?

It's doable, but for the moment I suggest to focus on the database structure since it's configuration can prevent issues in the future. Then maybe we can think about additional methods to prevent spam.

@confused-Techie did you read my previous post about the data migration? Tell me if there's something wrong in the script.
Please, when you finish, update the database structure into docs/database.md.

So, my 2 cents (didn't look at the full discussion, sorry) is that we could tie an user to a group of repos, like:
users -> git_repositories and git_repositories could have for example the kind (GitHub, Gitlab, Gitea at least) maybe URL (for self-hosted instead of cloud repos) and then we could integrate with respective git providers to have tokens (that way we won't have Auth information on our side, which is a big plus for me).
As of preventing SPAM, there are some tutorials on using SpamAssassin from other projects, so maybe we can check for packages with READMEs and other docs that have high points and alert something, so we can approve or reject them?

I personally really don't want to hold any auth data. And the way its currently implemented is similar to what Atom does. You go to log in with you GitHub account, and then we just store the OAuth token locally, keeping the account tied to the GitHub account.
But use of SpamAssassin could be nice for the the package uploading aspect, which I know we have discussed before. Although may still leave the previous concern of star spam unaddressed.
Although using the OAuth token as a primary key could seem probamatic as those keys will change over time, and automatically expire after a certain time frame if I'm not mistaken. Although I'll have to double check.
But @Digitalone1 I have not done that migration as of yet, things have been busy. But the docs/database.md does need to be updated to include the new tables that have been added, which you can see the structure in scripts/database
But I do have a script in a private repo that I should be able to add your suggested changes, for the package versions

There should be some parameter which define the user uniquely.

You can change your username to another username that is not currently in use. If the username you want is not available, consider other names or unique variations.

https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/changing-your-github-username
That said, we could even set the username as primary key. The problem is, if the user changes his/her username, how can we track it to update that state into the database? Since we interact with Github to get the OAuth token, I suppose we also get something to recognize the user even if he/she changes the name.

@Digitalone1 While I may not have given that exact flow to much thought, I'd like to think its current configuration could still work. The current configuration being, a user entered on the DB during user creation, is given a proper auto incrementing index as you suggested previously, then GitHub OAuth does its thing, and all we get back from GitHub is the OAuth token. From there, we query to get the user name, and probably the user gravatar, for the website, or gravatar link that is. Then we go ahead and generate the users Pulsar Token.
The Pulsar token is all thats then exposed to the user, and any queries made that require authentication would then use the Pulsar Token, which if valid grabs the valid GitHub Token belonging to the same user, and uses it to interact with GitHub.
When the GitHub Token expires or gets revoked, trying to access GitHub API's with an expired token will fail, and Pulsar will ask to re-authenticate, but the user unique ID is still unique, and the Pulsar Token remains the same.
And if they change their name, both the Pulsar Token, GitHub Token, and Unique ID are still the same.
From my initial research it seems that this could be the way that Atom was originally doing it, since they provided a separate API token, that was different from the linked to GitHub OAuth Token.
And I'd hope that an auto-incrementing number is unique enough, or if anything we could rely on another token, since it seems near impossible that we couldn't rely on any one of those. Maybe we make sure two out of three match during user name changes or OAuth Token refreshes, or lastly against a regeneration of the Pulsar Token. Just an idea.
Otherwise if you are aware of a unique enough property for the account, that we can hopefully retrieve via GitHub I'm open to it for sure. Since setting up sign in via GitHub is something new to me, but this seems like it could work

As for the last part of your comment about getting something back to recognize them, just wanted to be clear all we get back is the OAuth token. We would have to preform other API calls if we wanted to collection something else that is truly unique.

@confused-Techie Thanks for the explanation! Now it's more clear to me how it works. So assuming that the Pulsar token should be unique to the user and it has to be set for the user in order to be registered, it could be a candidate for the primary key, the serial or a uuid seems useless.
In the behavior you explained, there's so issue about changing username, because we might allow the user to have a custom name for Pulser different than Github and he/she can change it, but the user is still identified by the Pulsar Token and his/her votes still count as one. So the "spamming issue" would be a user creating multiple users on Github to count more votes on Pulsar packages, but this is hard to reproduce because it's also an issue related to Github and I don't think they easily allow such behavior creating spamming accounts from nowhere.

@Digitalone1 it's never a good idea to have any meaningful data as primary key - I suggest keeping the UUID, it does not expose any private information, and we can use as unique identifiers anywhere
Also, I disagree about SPAM. GitHub's SPAM protection is a joke, honestly, and I hope that, in the future, we will allow people to publish packages from any git repo, so the anti-spam needs to stay on our side IMHO...

No problem, the UUID can be used as primary key and the unique constraint can be set on Pulsar Token column.

@confused-Techie I'm reading database.js. If we call checkSQLSetup at the start of every database function, why is it exported outside? We could just hide it and use it only internally.
I suppose it's invoked inside to not let the caller handle the database connection. Am I right?

@confused-Techie I'm reading database.js. If we call checkSQLSetup at the start of every database function, why is it exported outside? We could just hide it and use it only internally.
I suppose it's invoked inside to not let the caller handle the database connection. Am I right?

It was only exported when I was unsure of exactly how we would handle it, and was thinking maybe we just want to call the function during the initial startup. But yeah as it is currently, we can remove it and keep in internal to that module with no issues. But yeah its called just so that any caller doesn't have to worry about it being up, or handling its errors. But also as it is, pretty sure nobody is handling its errors.
Now that we think about it, there may be some value, in making that function a bit better at returning errors, and we then call it during server startup, since we will always need it. Maybe even the same with the usage of Google Cloud, since thats also called before each action in storage.js. Then in server.js we expand its startup to set both of those up, and fail if they do

Can you link me a documentation about postgres javascript management?
The syntax
sql_storage`
  SQL QUERY TEXT
`

is kind of new to me.

@Digitalone1 it's called "String literals" and it's a new-ish thing on Javascript - basically, allows you to "customize" how you "concatenate" strings or other things.
const sql = (strs, ...params) => [strs.join(' ? '), ...params]
sql`SELECT * FROM packages WHERE name=${'hello'} and tag=${'demo'}`

// Returns:
//[
//  'SELECT * FROM packages WHERE name= ?  and tag= ? ',
//  'hello',
//  'demo'
//]

@Digitalone1 just make sure like you'll see in the codebase currently when using them, the await is what actually executes the command, otherwise you need to use I think .execute() on the variable. But heres more info.

Considering that we have fully migrated to an SQL environment, and that there's just a few things to fix up before a full 1.0 release, I'll close this issue.


style: fix linting and formatting errors

What's New?
Formatting and linting. In the future, it will only be run on files that are not generated.
Screenshots (if appropriate):

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have manually tested my code thoroughly
[x] I have added/updated inline documentation for public facing interfaces if relevant
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing integration and unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Additional context

@ctran88 This should be ready for final review.


Status GraphQL Query

Description
Be able to query transactions by status.
Add a new status filter to the GraphQL Schema.
Legacy code from the AWS version.
Example
query {
  transactions(status: "any" | "confirmed" | "pending") {
    edges {
      node {
        id
      }
    }
  }
}

Would be a nice feature but I don't believe confirmed is the right name here since transactions are final when they are first mined. Perhaps "mined" or "included" would be better?

Perhaps "mined" or "included" would be better?

@CDDelta Yeah I'm fine with "mined".
@TheLoneRonin We should also maybe think about having the dropped transaction status, as the current gateway system has a weird caching thing where it stores dropped transactions. So maybe then an "included" and "not-included" status would make more sense 🤷🏻♂


Add OFFSET implementation

Relates to https://github.com/prestosql/presto/issues/1

Applied comments.

Merged, thanks!


added more functions

I added verify & send OTP function

Could you please update the npm package 🤧

I forgot to edit the readme, i just updated it.


SvelteUI FOUC in SSG mode

What package has an issue
@svelteuidev/core
A clear and concise description of what the bug is
In sveltekit SSG mode initial content is sent without styling, which results in FOUC or worse - if JS is disabled components will not be rendered completely.
Discord user 'Princes' narrowed this issue to Stitches library. Probably styles from Stitches are not rendered correctly in SSG mode and therefor the components are not rendered until stitches renders styles ON THE CLIENT SIDE.
Hint to solving this might be the fact that getCssText() is returning different values in SSR and SSG modes.
Sadly I'm not experienced enough to contribute to solving this issue.
In which browser(s) did the problem occur?
No response
Steps To Reproduce

Create repo with SvelteUI and any component
Disable JS in the browser (for better visibility of the issue)
Change sveltekit adapter to static adapter
npm run build && npm run preview

Do you know how to fix the issue
No
Are you willing to participate in fixing this issue and create a pull request with the fix
No
Relevant Assets
No response

Turns out setting SvelteUIProvider ssr={true} fixes it completely.

Reproduction:

Open the dev server for svelteui-core
Add ssr to the svelteuiprovider
Add this to test.svelte to enable SSG:

<script context="module">
	export const prerender = true;
</script>

Inspect the generated file in .svelte-kit/output/prerendered. It is missing a whole bunch of styles!

Further, run npx svelte-kit build && npx svelte-kit preview. There is a FOUC. After loading it once the styles are fixed. Compare the stitches style tag in the prerendered file and in the browser after loading it once, you'll notice all the stitches styles are missing.

This should be fixed in the latest version 0.8.0 with the hooks solution - https://www.svelteui.org/theming/ssr


The filter option is switched from 'Prefix' to 'Tag Query' if changing the 'List Mode' under tag query status

Storage Explorer Version: 1.23.0
Build Number: 20220219.7
Branch: rel/1.23.0
Platform/OS: Windows 10/Linux Ubuntu 20.04/MacOS Monterey 12.2.1(MacBook Air M1)
Architecture: ia32\x64
How Found: Exploratory testing
Regression From: Not a regression
Steps to Reproduce

Expand one non-ADLS Gen2 storage account -> Blob Containers.
Create a blob container.
Open the view options panel -> Select 'Tag Query' -> Click 'Apply'.
Select 'Prefix' -> Change the list mode.
Check whether the option 'Prefix' is still selected.

Expected Experience
The option 'Prefix' is selected.
Actual Experience
The option 'Tag Query' is selected.

@v-xianya we're going to consider this as by design. Since you have not entered any text in the prefix text box you have not yet left the query mode. So when you then change list mode, we update the radio button to reflect the fact you are still viewing tag query results.


Error Assertion Failed

I can get it work the first time I tried it, but after I changed the images in frames directory, it always throws this error. I tried to recompiled the injector, re-clone your repo, no luck

This error is indicating a problem with config.json file. I think i may have added a white space by accident during a commit.


Fixes #224

Coverage decreased (-0.8%) to 86.246% when pulling 2bf6c7d8ff46b35c6699d0efc2bd2f84f600bf69 on billd100:fix/age-restricted-videos-without-signature into 3e8ab2b2fa721b7d6d7d00432f3c9eb817b9f902 on nficano:master.

@nficano Please let me know what I need to do to get this PR in order.


Form deployment disappears after error

Describe the bug
After an error, the Form deploy button is not shown anymore. It is unclear when this error occurs, but the modeler is fully usable still. Only the button in the footer disappears:

Sentry Issue: CAMUNDA-MODELER-KEE
TypeError: Cannot read properties of null (reading 'getBoundingClientRect')
  at U.getStyle (/build/bundle.js:2:423718)
  at U.render (/build/bundle.js:2:424306)
  at Ti (/build/bundle.js:2:170947)
  at Pi (/build/bundle.js:2:170742)
  at None (/build/bundle.js:2:195731)
...
(10 additional frame(s) were not displayed)

Steps to reproduce
Unknown at this point, check Sentry issue for stack trace + previous user interactions
Expected behavior
The Deploy button is displayed

Environment

Version: 5.17.0
Operating System: Windows 10 amd64
Plugins:
Execution Platform: Form - Camunda 8

Additional context
Found by @GeethaParthasarathy during release testing

Unfortunately, I can't reproduce this issue. Moving to backlog until we have more users impacted.


[Program]: Write a Swift program to convert string to sentencecase

Description
Write a Swift program to convert string to sentencecase
Sentencecase is a style of writing in which the first letter of the first word is capitalized.
Input  : "hello world"
Output : "Hello world"

How to contribute

Save the solution in program/program/convert-string-to-sentencecase/ConvertStringToSentencecase.swift file

!assign