Implement shared type aliases from another bridge module

This is still a WIP but the core of this is working now. Two main things to do:

Figure out how to handle both bridges trying to emit the Vec/Box functions, and how to make usage in UniquePtr/CxxVector work if the remote bridge doesn't use the shared type in that way
Clean up TODOs about adding ui tests

My other PR (#298) will also need to rebased on this or vice versa. The first 4 commits here are duplicated between them.
Fixes #297

It seems like in order to resolve the first issue I mention above - so that the monomorphized functions for Vec/Box/UniquePtr/CxxVector can be both generated when needed and also not have duplicate definitions - I'm going to need to make the name of those symbols somehow unique within a crate.
If I could somehow get the module path within the crate then I could include that in the function names, but I'm not sure how I'd get that short of the user specifying the crate root when calling cxxbridge and then calculating it from the path of the file being processed. On the proc_macro side it doesn't seem possible at all...there's the unstable proc_macro::Span::source_file() but then I don't have the crate root.
Any other ideas? The linkage attribute (https://github.com/rust-lang/rust/issues/29603) seems like it's not going anywhere anytime soon or making them weak symbols would work.

Actually, it needs to not just be unique within the crate but globally, so module path won't help.
The only other option I can think of is to unconditionally expand the Vec/Box/UniquePtr/CxxVector functions for all shared types in the module where they're declared (and never on the alias side). That's pretty brute force but not sure how else to resolve this without weak linkage.

For Vec/etc impls, I would prefer if only the "real" module of a type (the one that the others re-export from) were able to define those. That means something like a new attribute or other syntax to request inclusion of particular impls even when they don't appear in that module's ffi function signatures. For instance we could do:
mod ffi {
    struct C {...}

    impl Vec<C> {}  // allowed as long as your module defines C
}

The only other option I can think of is to unconditionally expand the Vec/Box/UniquePtr/CxxVector functions for all shared types in the module where they're declared

I don't want this because it doesn't work once we get to map bindings (std::unordered_map etc). Doing an impl for every possible pair of two types would be unreasonable, so we would at least need another solution for the map case, and once there is another solution anyway I think there isn't a reason to do this Vec etc.

Ok, that suggestion makes sense, and good point about map. One downside is that it means that authors of cxx type libraries need to anticipate which wrapper types clients will want to use, but that seems workable.
Would you be fine with not expanding Box/Vec for aliases (as is already done for UniquePtr/CxxVector) in this PR and then addressing in a later PR? That still leaves users with an equivalent workaround; they can simply define an unused function in the main module.

@sbrocket I've been working in a similar area, and I hadn't realized till now. Oops.
See:
#325 which also adds an ExternType::Kind, albeit for a slightly different purpose (which probably doesn't conflict except textually)
#329 which implements the impl UniquePtrTarget<T> syntax discussed above.
How close are you to landing this? If it's a matter of days, I'll rebase on top of your branch.

I can finish it over today and tomorrow. I was waiting for a response from dtolnay@ to my question above, but if you’ve got it implemented then that makes the question moot.

OK cool. I am unlikely to get back to mine till next week so there's no urgency. But I will eventually plan to rebase on yours if you think it will land soon.

OK, this should be good to go now.


🚀 - Add the missing currency codes

Description
ISO 4217 contains many currency codes that are not listed in the enum: https://github.com/taiga-family/taiga-ui/blob/main/projects/addon-commerce/enums/currency-code.ts
Already, we are lacking the following currencies: 048, 203, 348, 498, 792, 951, 985

Can I work on this issue? Shall I add all the country currency codes to TuiCurrencyCode or necessary ones?

@ragul1697 Sure. We just need to extend all currency related constants with missing currencies.

I'd like to extend the currency list also.

@F3KTOR you can go ahead with the PR, thank you!


Front-end bug on school overview page

School overview page not working, JS error in console:
Uncaught ReferenceError: colors is not defined

:+1: thanks!


Revert "KAFKA-16154: Broker returns offset for LATEST_TIERED_TIMESTAM…

 The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@cmccabe If you have time, this should be the revert of commit https://github.com/apache/kafka/commit/55a6d30ccbe971f4d2e99aeb3b1a773ffe5792a2 on the 3.8 branch.
A generated revert was not possible as there were merge conflicts.

Build failure contained:

14:54:56  hudson.remoting.Channel$OrderlyShutdown: Command Close created at ...

I triggered another build

Build failed with an exception on "streams:upgrade-system-tests-34:test". Rerunning the build

@jlprat : The PR now has conflicts after https://github.com/apache/kafka/pull/16478. Could you rebase? Thanks.

@junrao Rebased
@jolshan I would highly appreciate your review for "marking IBP_3_8_V0 as latest production". There are couple of changes I needed to do to make the tests pass.

Something seems wrong after rebasing. Build hangs and the job gets terminated.
Apparently ReplicationQuotasTest > shouldBootstrapTwoBrokersWithLeaderThrottle(String) > "shouldBootstrapTwoBrokersWithLeaderThrottle(String).quorum=kraft" never terminates.

Since this PR also marks MV 3.8-IV0 as the latest production, it would be useful to update the description of the PR accordingly.

I see a few comments here mentioning my name. Just overall,

3.8-IV0 in the 3.8 branch needs to be correct and completely in line with trunk

3.9-IV0 and 3.9-IV1 in the 3.8 branch can be whatever (it doesn't matter, since they are not usable / stable in 3.8)

As you've probably noticed, the tests which use @ClusterTest often need to be manually updated when the latest MV changes. I do think this is a problem (with @ClusterTest). I don't have any quick solution right now other than doing the edits. This isn't an issue with the tests using TestKit directly, since they can just set MetadataVersion.latestTesting. Maybe we need to rethink the @ClusterTest stuff.

Thanks for the review @junrao. Feedback is now applied

Failing tests shouldn't be related to the changes (all tests passed locally)

Merged! Thanks for the reviews!


i18n for cookie-consent

It looks like the cookie-consent module cannot use i18n. It uses cookies.content and cookies.button without going through translations.
Is it possible to work this around? It would be quite useful (if not mandatory) for multilingual sites.
Many thanks!

This can be easily fixed as indicated here or even simpler (without moving the keys into params.toml): https://github.com/gethugothemes/hugo-modules/commit/3627f00b636edbde24c9fd3c2d5340fa9c6dbadd.
I can't make a pull request because I have a lot of other changes that are unlikely to be accepted.

Hey @bfredo123, it's actually support multilingual. follow the steps
params.toml
[cookies]
enable = true
expire_days = 60

languages.toml
# for english
[en.params.cookies]
content = "This site uses cookies."
button = "I Accept"

# for french
[fr.params.cookies]
content = "Ce site utilise des cookies"
button = "J'accepte"

hope it will help. thanks


Update csi-snapshotter from v1.2.1 to v1.2.2

Update csi-snapshotter from v1.2.1 to v1.2.2
See https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v1.2.2
See https://github.com/kubernetes-csi/external-snapshotter/blob/v1.2.2/CHANGELOG-1.2.md

same changes need to be done in 2 places
https://github.com/ceph/ceph-csi/blob/master/scripts/minikube.sh#L121
https://github.com/ceph/ceph-csi/blob/master/charts/ceph-csi-rbd/values.yaml#L213

Updated.

@hswong3i please squash the commits

@hswong3i please squash the commits

Done

Shouldn't we change the v1.13 deployment manifests as well for this? v1.2.2 csi-snapshotter calls out minimum kubernetes version as 1.13, so this should be feasible. I do understand there is a different PR #764 is working towards removing 1.13, but till then keeping 1.13 in sync with 1.14+ would be preferable.
Also, @hswong3i request that the PR description/commit message remove the template strings, that are inadvertently copied. (everything below "Is there anything that requires special attention" in the message)

Done

@hswong3i can you please update commit message based on #773

@hswong3i can you please update commit message based on #773

Done

Rebased

@humblec PTAL

Rebased


Improve documentation of data structures

There should be a better way to understand the objects that are going to be returned than reading
https://github.com/chris48s/stage-left/blob/master/stage_left/types.py

covered in https://chris-shaw.dev/stage-left/reference.html#module-stage_left.types


Support for Windows (untested)

Currently denoliver is only tested and supported on OSX.
Would be nice to have it run on Windows 10 as well. I don't imagine it requiring too much work

I'm currently working on this.

@korki43 Fantastic! Thanks


Double definitions in search space

I get problems, that were solved when I replaced this if with an elif. I only understand the code on a very surface level, though. Not sure this is the right fix for these problems. It seems like 2 things happen: i) you assign to the same node twice (imputer) ii) the one-hot encoder is not supported for non-categorical features.
https://github.com/releaunifreiburg/WellTunedSimpleNets/blob/be5b3f3ccd3a5000b5108c19dc65c05357428fbc/utilities.py#L304

after my fix, I get this problem, though:
ValueError: Unknown hyperparameter for node SimpleImputer. Expected update hyperparameter to be in ['numerical_strategy'], but got categorical_strategy for some datasets.

As discussed in person, the reason for the check is that otherwise trying to update the hyperparameter for the node when there is a lack of categorical or numerical hyperparameters would throw an error from the library.


Mac Build version 2.2.9

With version, V 2.2.8 the source code for Mac, took a build.

First external resource files were not available.
Copied it from old versions, which we were using earlier.
Then, Arduino Nano /Uno is showing an upload error - timeout

Any advice, please

I will find and fix this soon.

Duplicate of #31

It's a strange problem, I will do a test on the mac system.

I am sure that this problem is no longer in the v2.3.0 version.


New enhanced Frontend Design (Using pure HTML CSS JS)

Design the updated frontend for the API so that it's more unique and descriptive  and make sure it's responsive too.

Hey i would like to work on this issue @Zack-Dx

@Panth1823 sure just whatever u do make a new folder named panth-frontend and then commit it.


Add new workflow to require API review.

This PR adds a new workflow that blocks PRs with the "Status-NeedsAPIReview" label, to prevent accidentally merging PRs that have not yet gone through review.

I added the API review label to test things out quickly, and it looks like it correctly blocked this PR. Note that the new workflow only blocks PRs against master so that new APIs can be incrementally developed on feature branches.

@cgranade is there a formal page yet that explains the API review process that we could link here?

The task for API review failed in this case, but it's still possible to merge. Is this intended?


[ ] There are no more than a few commits to merge.
[ ] There are no more than a few lines of code to review.

Code style

[x] Maximum line length does not require scrolling in Github
[x] FMT and ScalaStyle and ScalaFix are good

Testing

[x] Unit tests for the added/modified code
[x] Overall unit test coverage good
[x] Unit tests are passing

Dependencies

[ ] The plugin is added to itself
[ ] The latest version is added to itself
[x] New dependencies do not have vulnerabilities

Security

[x] There is no known vulnerability being added to this project
[ ] Everything on this list is checked

Coverage decreased (-2.2%) to 54.379% when pulling df43d2677c7a213275b6a7755e45eab769c0aa28 on lbenkel/fix_json_debug into 2452ded43b98637f0f21d625731553bfc1d8e0eb on master.


CI workflow update, integrate expo-app into repo

Description
This PR further integrates the @rnx-kit/expo-app into the repo tooling. During this integration, I factored out the ios and android builds, moving them into @rnx-kit/scripts commands we can use from our dev terminals (they used to be exclusive to CI). I then made CI use these new commands.
I also refactored our CI logic to reuse YML code wherever possible. And I added caching for cocoapods.
Credit to @tido64 and his RNTA repo, from which I stole a lot of this logic :wink:

Test plan
Verify new commands manually, including error conditions.
Verify CI updates by reviewing logs and observing success results.

I think this is ready to go now. I've verified that the caches are all unique and are working. We have pod-caching and compiler-caching and now yarn-caching through node-setup. Plus expo-app is now using some of the rnx-kit scripts and commands.

The changes on this PR won't show as fully passed because some of the names changed. The new-name checks are passing. Once approved, I'll submit this PR and update branch protections to use the new names.


Update actions to keep permissions

Fixes #11286
Signed-off-by: Julien Pivotto<EMAIL_ADDRESS>

Tested & it works


Module compiled with Swift 5.0.1 cannot be imported by the Swift 5.1 compiler

Unable to import AudioKit into an Xcode 11 project when using the vendored_frameworks in CocoaPods.
Xcode 11 gives the following error:
Module compiled with Swift 5.0.1 cannot be imported by the Swift 5.1 compiler: /Users/<snipped>/Pods/AudioKit/iOS/AudioKit.framework/Modules/AudioKit.swiftmodule/x86_64.swiftmodule

I assume the supplied framework needs to be rebuilt using the Xcode 11 GM?
Xcode Version: Xcode 11 (11A419c)

Correct. As a temporary workaround I'd remove the static Frameworks and just drop in the AudioKit for iOS xcodeproj into your project (make sure to set it as a dependency / "link with binaries" in your app)

It's weird that I've had no issues linking with the 4.8 pod in Xcode 11 GM. In any case, we should probably push out 4.8.1 built with Xcode 11 at some point soon...

Oh yeah, might be different when working with the Pods.. In that case xcode-select -s /Applications/Xcode.app may do the trick (in case you run multiple Xcode versions @DaveWoodCom )

I don't think it really matters because the root of this issue is our pod uses pre-built binaries (still on Xcode 10 at this point). The Swift ABI was supposed to be stable finally so in theory you'd think they would link with any subsequent version of Xcode, but it was definitely broken during the beta period.

Yes, this is just because of the pre-built binaries built with Xcode 10.
Swift ABI stability only applies to run-time, doesn't apply to compile time. See the blog post about it here: https://swift.org/blog/abi-stability-and-more/#module-stability

@aure @DaveWoodCom Do you know what the timeline is for issuing a release that fixes this issue?  This will probably become a bigger issue next week, once Xcode 11 rolls out as the final public version.

As soon as possible!

Would be great to know if anyone has a workaround for Cocoapods users in the meantime. We have a non-AudioKit iOS 13 bug that we are blocked from working on at the moment since we can't compile on Xcode 13.

Man, we have our hands full just with Xcode11, never mind 13. ;)

Lol oops.

Version 4.9 was just pushed out, including a pod built with Xcode 11 GM 2.

Hi
did any one found a fix (workaround) for this ?

Did you update your Podfile to 4.9?

@aboelbisher, the mistake that I made, was having Xcode's command line tools pointing to the Xcode 10.3 version, instead of Xcode 11. After updating its path with sudo xcode-select -switch /Applications/Xcode.app, I was finally able to pod update to AudioKit 4.9. Prior to that change, I was only able to install AudioKit 4.7.1, which isn't compatible with Xcode 11 (hence the "Module compiled with Swift 5.0.1 cannot be imported by the Swift 5.1 compiler" error).
Don't forget to run pod update. Please let us know if this helps.

@DaveWoodCom I was facing the same issue for that I have updated my local copy of Swift as well you can do that in XCode's Preferences under Location ->

Ah, nice shortcut, @DaveWoodCom!

Could we have a 4.8 (.1) build compatible with XCode 11?

You can make one if you want.

Just tried compiling version 4.9.1 ( via CocoaPods ) in Xcode 11 Beta 2 with the following result:

Module compiled with Swift 5.1 cannot be imported by the Swift 5.1.1 compiler

It seems to work when using a different Swift toolchain but that breaks all my other libraries..

Anyone have an update for this? I've tried using the latest release of AudioKit and also tried implementing it via Cocoa pods, nothing works for me. Xcode Version 11.2 (11B52)

@coreyackland Works for me, possible that you have a cached copy of AudioKit somewhere. Its really weird that an old version of AUdioKit would work. Which one? how old? like v2? :)

Ok so downloading directly from the website, AudioKit ver 4.9 is pulled (which is where I was having issues). Downloading from https://github.com/audiokit/AudioKit/releases, with version 4.9.2 works.

Oh thank you, I forgot to update the web site. Fixed now.


kconfig: Remove redundant 'default n' properties

Some more were added since the cleanup pass in June 2018. See e.g.
commit 2d50da70a1 ("drivers: ipm: Kconfig: Remove redundant 'default n'
properties") for a motivation. It also avoids people wondering whether
or not they need to put in 'default n', and thinking it might make a difference.

Codecov Report

Merging #13807 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #13807   +/-   ##
=======================================
  Coverage   52.26%   52.26%
=======================================
  Files         307      307
  Lines       45410    45410
  Branches    10504    10504
=======================================
  Hits        23734    23734
  Misses      16887    16887
  Partials     4789     4789

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 cd65ed8...bbdade0. Read the comment docs.


Proposal of fix to a typo in blog post a day in the life data science student miracl…

Hello team,
I would like to propose a fix to a typo from this blog post.
The sentence:
'There are so many courses that cater to your needs and meets you at your skill level.'
Could be replaced with:
'There are so many courses that cater to your needs and meet you at your skill level.'
In order to maintain singular/plural agreement.
Let's get it.

Merged!!!


"python": "^2.7" should be defined in "engines" field of node-gyp/package.json

This would be helpful to know during the install phase of node-gyp. Is there any reason not to fo this?

The only issue that might arise is that node-gyp is a dep of npm and if it fails, AFAIR it will propagate to fail npm. For most users that's an unneeded fails.

@refack I admit this is not specifically a node-gyp concern. I guess the question is how are we intended to communicate these kinds of requirements?
For example, if you don't know that python is required when you install node-gyp - you only learn so when trying (and failing) to actually use node-gyp. Which, I think it might be better to at least emit a warning on the install phase.

Which, I think it might be better to at least emit a warning on the install phase.

That's a nice idea. If you have the time to submit a PR to hook script: {install}, that would be much appreciated.


pullout quotes?

consider it ... and think about the best data structure for this (new model, field with a delimiter?)

nah sry


Typo mistake in Intellisense configuration

Issue Type: Bug
There is an option in Vsintellicode > Modify > Editor: Suggest Selection that has a typo mistake: it's written AutomaticallyOverrOde instead of AutomaticallyOverrIde.

Extension version: 1.1.5
VS Code version: Code - Insiders 1.33.0-insider (b5f5db349f211f5045e7dad6fd1672010d2d00de, 2019-03-28T10:44:04.956Z)
OS version: Linux x64 4.15.0-46-generic

System Info

Item
Value

CPUs
Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz (4 x 1705)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwaresurface_synchronization: enabled_onvideo_decode: unavailable_offwebgl: enabledwebgl2: enabled

Load (avg)
2, 1, 0

Memory (System)
3.68GB (0.10GB free)

Process Argv
--unity-launch

Screen Reader
no

VM
0%

The value automaticallyOverrodeDefaultValue is intended to indicate that IntelliCode has already done this in the past. IntelliCode automatically overrode the default value for you previously. It's not really a user-selectable value on it's own, but it's more of a state keeping mechanism to help troubleshoot why the editor.suggestSelection value might have changed.
enabled means you are allowing IntelliCode to change editor.suggestSelection on your behalf, but it hasn't done anything yet.
disabled means you are not allowing IntelliCode to change editor.suggestSelection. automaticallyOverrideDefaultValuemeans that you had set it toenabledat some point in the past, and IntelliCode acted on that and changed the value ofeditor.suggestSelectionfor you to a value that works better with IntelliCode.choseToUpdateConfigurationmeans that you had it set toenabledat some point in the past, and IntelliCode prompted you to change the value ofeditor.suggestSelection`, and you chose to change it via the prompt.
The last two settings both indicate that editor.suggestSelection was changed due to IntelliCode, but they differentiate automatically changing the value from you being prompted and confirming to change the value. There are different scenarios where each one would happen, which can be seen in more detail at https://github.com/MicrosoftDocs/intellicode/issues/53#issuecomment-470332077.
If you have any suggestions for making the descriptions clearer, please let us know.

Ohh sorry... I didn't notice that this was a kind of "status" feedback and not an option... It makes sense now.
Thank you so much for your explanation. One more time, sorry my misunderstanding,


Password Signup calls are behaving wrong when magic-link-account already exists

Bug report
Describe the bug
Password Signup calls to the API are not failing, even though a user with this email already exists. The API instead creates a new "fake" user, returns it and attempts to be successful. But a new user is actually never created when checking the dashboard. Also, they are not able to signin with the password afterwards. They also don't get a verification email. So basically, it creates a dead user but with the same email.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:

In Dashboard: Enable new signups, enable email provider, enable signup confirmations required.
User Creates account with magic link by JS method .signInWithOtp(). An account gets created. A confirmation email gets send. Everything fine.
User wants to sign in with password too. So user might use the register method at the next time they want to sign in. Or they just accidently forgot that they are already signed in with magic link and try to register again with same email.
The Supabase API actually returns a fully new "fake" user object with the same email but with a new user id. This should be unwanted behaviour, since you cannot create multiple users with the same id. This newly created "fake" user does not pop up in the supabase dashboard and also the confirmation email never gets sent. So the user will still never be able to sign up with a password with that email. But the signup request is returning with HTTP 200 and a new "fake" user object, assuming that supabase somehow created a new user, which it didn't.

Expected behavior
I expect that the signup call will fail, since a user is already signuped with this email. Just like it fails when trying to sign up a user with password that already is created and has a password.
System information

OS: macOS
Version of @supabase/supabase-js: 2.1.0
Version of Node.js: e.g. 16.18.1

To temporarly resolve this, I suppose I could do the signup call on a server and before doing that, checking via the admin api
await supabase.auth.admin.listUsers() that a user with this email is already existing, and then throwing an error manually before attempting to signup.

I found this comment that this behaviour is intentional:
https://github.com/supabase/supabase/discussions/1282#discussioncomment-1673737
I understand why, but maybe it would be great if this behaviour would be documented somewhere, or could be turn off.

See also https://github.com/supabase/supabase-js/issues/296


Remove first timestamp from genereated AutoMod queue messages

Pull request checklist:

[x] CHANGELOG.md was updated, if applicable

Description
Remove timestamp from AutoMod, for style purposes and because on Twitch it doesn't show it either. The only thing where the timestamp should show is from the message itself.
Same things is with the "low-trust-users" messages.

Could you provide a before and after screenshot?

Could you provide a before and after screenshot?

Sure.
Before:

After:

Preferably at some point, we could reduce the gap between the modmail message and the users message that would have been sent in the chat.
@pajlada do you have more of these "builder.emplace" "Elements" or is it based of a template from Qt on something, couldn't find that. So that I could look into more stuff for the UI.

@pajlada do you have more of these "builder.emplace" "Elements" or is it based of a template from Qt on something, couldn't find that. So that I could look into more stuff for the UI.

https://github.com/Chatterino/chatterino2/blob/master/src/messages/MessageBuilder.hpp#L65-L75 That's where we've defined the emplace function that you used just now - all it does is add a Message Element to the Message Builder.
It's a semi-common pattern we follow where we have builders

I thought that we had added the timestamps on reward message to be consistent with automod

I thought that we had added the timestamps on reward message to be consistent with automod

Possibly - we will want to review other "message headers" and see about removing the timestamp of those too I think

Thanks for your contribution! As a first-time contributor, you can now add yourself to the contributors list that's shown inside the application.
To do so, open a new PR where you modify the resources/contributors.txt file and add yourself to the list. Make sure to read the comments at a top for instructions.


question about label_map

Hi, @dbolya , thanks for your nice work.
I read your section Custom Dataset in readme and label_map field in config.py, but I'm still not sure about how to organize Class name and label_map. Do you mean if we set 'class_names':  (apple_1, pear_2, peach_3) then we can set 'label_map': None ?
Could you please provide a simple sample?
Thanks
Julien

That's right, so if class_names is ("apple", "pear", "peach"), then apple should be id 1 in your aannotations and peach id 3. Then unless you indexed the classes in your dataset differently, you can leave label map as none. That's only used if you didn't index your IDs sequentially starting from 1.

OK, Thanks.


Boostrap Server BootstrapFailureCause enum: v2 contains less codes comparing to v1

Hi guys,
I'm upgrading Bootstrap Server with Leshan dependency from 1.3.1 to 2.0.0.-M4. I realized that in the new library version the BootstrapFailureCause enum contains fewer error codes:

in v1 there were also: WRITE_ACL_FAILED, WRITE_SERVER_FAILED, WRITE_SECURITY_FAILED and DELETE_FAILED
in v2 there is just REQUEST_FAILED instead of above

Can you please explain why this change was done? Does REQUEST_FAILED mean that some of the WRITE or DELETE bootstrap operations just failed (without more details on which exactly object failure occurred)?
Many thanks,
Gerard

This change was done because we do a refactoring where BootstrapHandler is now more agnostic about request it sends.
This allow to handle all kind of request (like the new discover or read request).
(More details about this could be found here : https://github.com/eclipse/leshan/pull/1027)

Does REQUEST_FAILED mean that some of the WRITE or DELETE bootstrap operations just failed (without more details on which exactly object failure occurred)?

This means that the bootstrap session failed and so be stopped. The reason is that 1 request failed. Here you can not know which request failed.
But there is now a BootstrapSessionListener which should be now more appropriate to watch bootstrap session lifecycle.

Great. Thank you for the hint. I'll go with BootstrapSessionListener.


The Archive module name is a too common name

Hi,
I arrived to this project, because chromedriver-helper gem uses it. However I can not use any of the gems in the project because the Archive module name collides with a project name what I can not change.
Wouldn't it be a good idea to use a bit more specific module name in this gem?

That kind of change would be a massive compatibility break.  It would also require that the chromedriver-helper gem be updated to use the new name before you would even be able to benefit from the change.
Given that this is the first such request for this project after all these years of existence, there will need to be more evidence that the current name is indeed an issue for a wider array of consumers or potential consumers before this request is considered further.  What is the project that you cannot change, and why can't you change it?

Closing for lack of a response.


Option to reveal steps one at a time

At the moment, "show steps" reveals all the steps at once. Some question authors would like to reveal hints one at a time - they might start with vague hints, and get more detailed.
There should be a per-part (per-question?) option to make steps reveal one at a time. The steps penalty would be per step revealed, and the button the students click would say "show steps" for the first, and then "show next step".

A further enhancement: a choose-your-own-adventure mode for steps. You might want to give a list of options to choose from. Picking one option might make the others unavailable, or they could still be allowed.
This would allow students to identify more accurately where they're having trouble, and would also allow the creation of questions which allow multiple solution methods.
Options for parts with steps:

Show steps:

all at once (the current behaviour)
individually (one button per step)

Steps penalty (only when showing all steps at once)
Only allow one subsequent step? (only shown when more than one step is marked "show after this one". If ticked, picking one of these steps makes the other ones unavailable)

Options for steps:

Penalty for revealing this step (only when steps are revealed individually)
This step is available:

always (the current behaviour)
after [other step] is shown


Prevent server hangs on unconsumed streams.

While the HTTP spec does support sending a response before the request is finished and this behavior is followed by node http and curl, every browser and at least one popular load balancer (GCP) don't support this.
This means that if the server responds before the request stream has finished, the response body will be dropped:

If, on the other hand, the server waits before for the request to finish (by dumping the incoming data), the client is able to receive the response:

The reason this effects apollo-upload-client differently than other upload solutions is twofold:

While I prefer the approach of apollo-upload-server, most other drop-in file upload middleware waits for all uploads to finish before handing off the request to downstream middleware. This makes it simple, as downstream middleware doesn't have to worry about consuming the entire stream.
The downstream middleware is always going to be a graphql server, and resolvers are unaware of Uploads from other graphql branches (you could hack around this, but it would undo all the ergonomic benefits of apollo-upload-server).

Here's my (very typical) use case:

Try to upload a large file (or use a slow/throttled connection on a smaller file).
Before processing the upload, the graphql resolver checks to see that the user is logged in and throws an error:if (!session) {
  throw new Error("You must be logged in to save an image.");
}

Unfortunately, this is a bit challenging to test, as this is a race: if the upload is fully buffered by node http before the response is sent (small file, local network) then everything works correctly; if it isn't (most real-world cases) then it will fail.
So far I've implemented this in the koa middleware (since that's what I'm using), and will add this to express when I get a chance. I'll also add some tests, but I wanted to drop this off here before somebody else descends the rabbit hole trying to diagnose this.

Fixes #45, fixes #77, and fixes #83: Correctly handles stream errors.
Fixes #78: Correctly waits for the request to finish before responding on node >=8.
Fixes #64: Allow ignoring of an upload without blocking subsequent uploads.

OK, I've added tests for the koa middleware. The problem with doing this in express is that we're going to need to export 2 different middlewares:

before graphql (add the uploads)
after graphql (wait to send response)

OK, so the failing tests appear to happen on master using the node v10 and v6. This is good to know, as I was planning to upgrade from v9 shortly! I'm going to look into this as well.

OK, so it looks like #80 fixes master on node v10, so I'm going to go ahead and pull that one into this branch as well.

I've just fixed a bug with the tests in master branch (https://github.com/jaydenseric/apollo-upload-server/commit/528216f56186307481c070e2853cc39893fe8b18), might want to rebase.

@mike-marcacci really appreciate your help 👏
I'm on the Apollo slack (and I can see you're on there too), so feel free to chat about any of this stuff, either publicly in the #uploads channel or via DM. My timezone is Melbourne, Australia.

OK, well, as an update, I wasn't able to get any success with http2, but my real world use case is complex (reverse proxies, etc) so I thought I should go back to first principles. I created a test to try against the browsers on my laptop:
https://gist.github.com/mike-marcacci/5c7f435d51240feb8a871ab348a00dfd
And I can't seem to reproduce the issue on http, https or http2, so I've got to keep digging. I'll post back when I find something.

OK, so after a ton of investigation, I've learned a lot :) I created a set of tests to demonstrate node's HTTP behavior under a variety of scenarios, and read the relevant source for http, streams, koa, and busboy.
It turns out that my premise here was wrong, although my solution (accidentally) may be correct. It turns out that node does wait for an HTTP request to finish before sending the HTTP response. This is true on HTTP-1.1, HTTP-1.1 over TLS, and HTTP-2, as shown here. By default,  if req has no consumers when data is sent to res, node will send its contents to the void before responding. If however, a consumer exists, node will wait indefinitely.
The symptom that I was seeing was actually a due to this "hanging" in my app's particular context: My app sits behind a proxy which was dropping the idle connection (this behavior was consistent across node-http, haproxy, and GCP's HTTP load balancer).
The solution, though, is the same: apollo-upload-server MUST prevent hanging, because it's impossible to downstream. Take this example, where $photo is an upload:
query {
  me: {
    id
    friends (whoLookLike: $photo) {
      id
      name
    }
  }
}

The resolver for me might throw an error like "You are not logged in!" or encounter an error when querying the database. In these cases, the resolver for friends is never called and never has an opportunity to continue the upload stream!
This will result in no response making it back to the client (either hanging forever, or getting killed by a proxy). There are a couple ways to fix this:
Solution 1
The simplest thing to unpipe busboy and resume the request after resolvers have finished:
// ...
  await next()

  ctx.req.unpipe(parser)
  ctx.req.resume()
  parser.destroy()
// ...

This has the advantage of being the fastest, since we won't be decoding unused files. However, it does mean that resolvers who do use an upload can't return early and expect to receive the rest of its contents. This is already handled quite nicely with the FileStreamDisconnectUploadError.
Solution 2
This is basically what I implemented here. We simply make sure to .resume() every upload that isn't actively flowing. This means that the entire request will be decoded, but the caveat from Solution 1 doesn't apply.

One other scenario that I have to test... it seems possible to me that the following query is unsolvable with the current implementation:
query {
  me: {
    id
    friends (whoLookLike: $photo1) {
      id
      name
    }
  }
  searchPeople(whoLookLike: $photo2) {
    id
    name
  }
}

Assuming that $photo1 is never accessed... will the promise for $photo2 ever resolve? I don't think ever will, and will end in a forever hanging request. Again, I need to test this.

OK, so I added a test for my theory on possible infinite hanging... and I was sadly correct. Do note, though, that this bug is bypassed if the entirety of $photo1 exists in the same TCP packet as $photo2.
I'll work on a fix for this, and incorporate it into this PR, if you don't mind (rather than create another PR, as these issues are related).

Alright! And it's fixed :)
Instead of passing busboy's FileStream directly to the graphql body, I created an intermediary UploadStream that allows busboy to continue parsing the request uninterrupted. This means:

Streams will parse faster, since $photo2 doesn't have to wait for the resolver of $photo1 to finish.
The request will never get stuck in a perpetual await because some resolver was never reached.
An upload-handling resolver doesn't have to worry about consuming a stream it doesn't care about (ie, it can just return early)
We actually eliminate a potential memory and file descriptor leak from unclosed idle connections and all their resources.

I'm going to go ahead and close #80, as its changes are merged in here, and some of the strategy has changed.
Please let me know if you have any concerns!
Cheers,
Mike

Well, there’s more to this... I’ll dump another big realization and change shortly.

So, I went to test all these changes in my real-world project, and encountered some issues:

The tested behavior changes when a file is larger than the stream highWaterMark.
Node actually behaves slightly (but importantly) differently from what I described above, and its behavior changes significantly depending on whether the HTTP connection is set as close vs keep-alive.

Bufferring To Files
First to address the issue of highWaterMark being exceeded. My tests for the solution described here used a file that could fit entirely into the memory buffer of the UploadStream I created. However, when using real (large) files, node streams (correctly) detected the backpressure from this unconsumed duplex stream and paused everything upstream (including the HTTP request), which brought back our indefinite wait.
So instead, I wrote fs-capacitor, which acts like a duplex stream that buffers to the filesystem (instead of memory) and importantly doesn't propagate backpressure upstream. This means that it can consume the entire upload without interruption, even if it is unconsumed. This will have some performance cost, as it's using the filesystem where it previously used RAM, but this is a worthy compromise for correctness and avoiding indefinite hangs. Also, with the previlance of SSDs the performance difference is quite small, and given the fact that unix streams (including the incoming TCP connection) buffer to the filesystem, this probably won't be a bottleneck.
Node & HTTP
My previous revalations weren't entirely correct (and honestly, I bet neither are these... but they're based on tests so hopefully they're a bit closer to reality!).
It turns out that whenever res.end() is called, req emits a close event, which is indistinguishable (to my tests at least) from an early close by the client.
At this time, if the HTTP connection is close (which was the default downstream mode of all the proxies I tested), the connection will be closed even though the request is incomplete.
On the other hand, if the HTTP connection is keep-alive (which can be forced by setting the header, like ctx.set('Connection', 'keep-alive')) the request data will continue to flow after res.end() is called.
One solution is simply to force keep-alive, which is simpler than waiting to send res.end(). But this has 2 problems which I haven't yet solved (and probably won't have time to, since I've been in this rabbit hole far too long already):

I can't distinguish between an early close initiated by the client (I never see the abort event fire, even when I think it should) and one initiated by res.end()
Not all clients (or proxies) support keep-alive. While it's likely that the vast majority do, common setups such as node-http-proxy require additional configuration to support this. In this situation, all in-progress uploads get terminated, and the response never makes it to the client.

The second solution is to wait for the parser to finish. This is the route I've taken, but it requires a change to the API since it's not enough for processRequest to resolve the just the body.

I wrote fs-capacitor specifically for apollo-upload-server and tested it quite extensively in that context, but realized it belongs in its own package. I haven't added tests or docs for it yet, since I'm super behind on not-rabbit-hole work ;-) But I'll add them when I have time.

Wow! Love the depth 🙌
It's a public holiday long weekend here in Australia (Queen's birthday), so I hope to immerse in your findings early this week.

OK, this is finally ready.

fix #45, #77, fix #83 - correctly handles stream errors
fix #78 - correctly waits for the request to finish before responding on node >=8
fix #64 - allow ignoring of an upload without blocking subsequent uploads

To Do

[x] describe changes in changelog.md
[x] update docs in readme.md
[x] test in real-world use case
[ ] review by @jaydenseric
[ ] merge into master
[ ] bump "minor" version
[ ] publish to NPM

I need this 👀

HURRAY! @jaydenseric when to expect this to be tagged on npm?

@terion-name I have a few minor things to sneak in, then publish hopefully within the next day. The new version will likely be a semver major, due to the raised min Node.js version. If you use a recent Node.js version it should be a painless upgrade.

@mike-marcacci do you know what might be causing these errors? https://travis-ci.org/jaydenseric/apollo-upload-server/jobs/402915414#L2165

I’m going to assume you’re referring to the “Parse Error” in the logs (Travis line links are apparently messed up on mobile). I don’t know off the top of my head, but I suspect those are a case where we’re testing an aborted request, and we propagate our custom events while busboy emits a parse error. I’m not sure how those would get in the logs, but I assume there’s something special going on with Tap. I’ll loot at these tomorrow.

when are you gonna release this?

@ForsakenHarmony @jaydenseric you're in luck, I've got some time here today :) we didn't have as great cell coverage in our last locations as we had expected. Stay tuned!

Published in v6.0.0-alpha.1 🎉

seems like you published it as a normal release on npm not alpha/beta, just as a heads up

Thanks for the heads-up @ForsakenHarmony. You're right: it looks like @jaydenseric will need to update npm's "latest" tag to point back at 5.0.0.

Thats deliberate actually; v6.0.0-alpha.1 is more stable than v5.0.0 and everyone who can (given the few breaking changes) is advised to update.

Aah I see. Good strategy!

On Jul 23, 2018, at 19:42, Jayden Seric<EMAIL_ADDRESS>wrote:
Thats deliberate actually; v6.0.0-alpha.1 is more stable than v5.0.0 and everyone who can (given the few breaking changes) is advised to update.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


[Feat]: Remove the Span StatusCode=OK requirement to follow OTel Trace spec

🚀 What's the Problem?
Telemetry from instrumented applications is only included in the OpenLit UI if the related span StatusCode is OK. When using the OpenLit library, that's not a problem since that is done as part of the instrumentation. However, when integrating other libraries/applications, it becomes a problem if they follow the OTel Trace specification and keep the StatusCode unset in successful scenarios.
💡 Your Dream Solution
It would be great if the span StatusCode=OK requirement could be removed, perhaps converting that into a filter to exclude spans with an explicit StatusCode=ERROR. The OpenTelemetry Trace Specification (spec) includes the following about the status:

Generally, Instrumentation Libraries SHOULD NOT set the status code to Ok, unless explicitly configured to do so. Instrumentation Libraries SHOULD leave the status code as Unset unless there is an error, as described above.
Application developers and Operators may set the status code to Ok.

Furthermore, the OTel semantic conventions includes the following about the status of HTTP interactions:

Span Status MUST be left unset if HTTP status code was in the 1xx, 2xx or 3xx ranges, unless there was another error (e.g., network error receiving the response body; or 3xx codes with max redirects exceeded), in which case status MUST be set to Error.

📖 Additional Context
I really like OpenLit, congratulations on such a great library and thanks for following the OpenTelemetry path. It makes it possible to integrate even more systems with OpenLit. I'm currently working on integrating Java applications with OpenLit, and thanks to the OpenTelemetry adoption is more approachable. The main challenge I'm experiencing is about the unset span status code instead of OK, which is why I raised this issue.

@patcher9 Thanks for the quick reply. I'd be happy to contribute a PR!

I can update the default filter in https://github.com/openlit/openlit/blob/main/src/client/src/helpers/platform.ts#L228 so that if a StatusCode is specified, that will be used. If not, it would include all spans where StatusCode is not ERROR (basically, including both OK and UNSET statuses).
How about the instrumentation? Do you want me to remove the places where the spans are set to OK status?

Yes, it does, thank you! How should the flag for the span status be provided by users? Via the openlit.init() method?

Perfect, thanks. I started working on it.

@patcher9 thanks! I've been away on a conference and didn't have much time to complete the PR, but now I'm back and I'll continue to work on it. I plan to submit a draft PR in the next few days for some early review.

@ThomasVitale I have addressed the client traces for the condition for status ok only, but if you feel that it should be addressed from the python sdk as well, feel free to re-open this issue. Thanks

@AmanAgarwal041 thank you so much for handling the status code change!
I've been struggling with the Python SDK update to make the status code configurable. It's been a while since I worked with Python, so it took me a bit of time to navigate the source code and didn't manage to meet the timeline I initially expected, sorry about that. I'm fine with not having that change, though, so it's ok for me to keep this issue closed.


navigator['app'].exipApp() is not woring in Ionic 4

Bug Report
Ionic version:
Ionic:

   ionic (Ionic CLI)             : 4.11.0
   Ionic Framework               : @ionic/angular 4.1.1
   @angular-devkit/build-angular : 0.13.5
   @angular-devkit/schematics    : 7.2.4
   @angular/cli                  : 7.3.5
   @ionic/angular-toolkit        : 1.4.0

Cordova:

   cordova (Cordova CLI) : 9.0.0
   Cordova Platforms     : android 8.0.0
   Cordova Plugins       : cordova-plugin-ionic-keyboard 2.1.3, cordova-plugin-ionic-webview 3.1.2, (an
d 7 other plugins)

System:

   NodeJS : v10.15.3
   npm    : 6.4.1
   OS     : Windows 7

Current behavior:
I try to use navigator['app'].exipApp() to exit app,but nothing happend
Expected behavior:
do navigator['app'].exipApp() and exit app
Steps to reproduce:

Related code:
this.platform.backButton.subscribe(() => {
    if (this.router.isActive('/home', true)) {
        if (click_times === 0) {
            this.toastService.info('click again to exit app');
            click_times++;
            setTimeout(() => {
                click_times--;
            }, 2000);
        } else {
            try {
                //expect to exit app, but first time is nothing happend, second time catch error
                navigator['app'].exipApp();
            } catch (e) {
                console.log(e);
            }
        }
    } else {
        this.goBackService.goBack();
    }
});

Other information:
I use chrome://inspect/#devices to debug apk and find that at first time do the action navigator['app'].exipApp(),it has no error ,but nothing happend.
And when I do navigator['app'].exipApp() again ,the code catch error :

TypeError: navigator.app.exipApp is not a function

Also,I try to build release apk,and it doesn't work as before

Ionic info:
TypeError: navigator.app.exipApp is not a function

Try to use .exitApp(); instead of . exipApp() :)

Hi there,
Thanks for the issue. As @bastyen noted, it should be navigator['app'].exitApp() instead of navigator['app'].exipApp().
Additionally, this is not something that Ionic manages, so I am going to close this issue. For further questions feel free to post on our forum or our slack.
Thanks for using Ionic!


Feedback is posted to wrong commit

Feedback was requested on: https://github.ugrad.cs.ubc.ca/CPSC310-2018W-T1/d0_w8j0b/commit/a66dce8464958a4788d3497acfbf4a552a90747d
But was given on: https://github.ugrad.cs.ubc.ca/CPSC310-2018W-T1/d0_w8j0b/commit/4fed933193aae684d7c921844d2ea766550f47b9

This one is confusing because the 'given on' thread also has requests so we'll never be able to sort out what exactly happened there.

Added a bunch of logging; hopefully it will help diagnosing this next time.

Fixed and deployed


.Net: Add missing FinishReason to the StreamingChatMessageContent in the Ollama connector

Motivation and Context

As other connectors are providing a FinishReason = "STOP" metadata in the last StreamingChatMessageContent message, I adjusted the GetStreamingChatMessageContentsAsync() method in the OllamaChatCompletionService to provide the expected metadata.
Description

The ChatResponseStream message from the OllamaSharp package provides a Done property, which indicates if the stream is finished. This property is used to determine when to set the metadata with FinishReason = "STOP".
Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

@RogerBarreto Sounds good, thank you very much!


When creating the custom controls to use for theming, name them these things.

For buttons, "UXLThemeButton"
For labels, "UXLThemeLabel"
For drop-down boxes, "UXLThemeComboBox"
For radio buttons, "UXLThemeRadioButton"
For checkboxes, "UXLThemeCheckBox"
For groupboxes, "UXLThemeGroupBox"
For link labels, "UXLThemeLinkLabel"
For textboxes, "UXLThemeTextBox"

For warning labels such as this one:

Name them this, "UXLThemeWarningLabel"

For information/description labels such as this one:

Name them this, "UXLThemeInfoLabel"

I'm actually just using a loop thing that applies theme colors to controls of specific types.


fewer chromosomes

Hi Zijie Jiang
Thank you so much for your help. I was able to run AutoHiC finally. However, after the run, the genome is assembled into fewer chromosomes. In my case 21 chromosomes. We should expect 28 chromosomes for this species. Also, the final HI-C plot is not very good. I have attached it for your reference. Is it possible to provide the number of chromosomes as a parameter during the run?

Thank you
Best regards
Kritika

Congratulations on the promising results obtained from whole contact heatmap. However, it should be noted that AutoHiC currently employs a vision-based approach to chromosome assignment, which may result in suboptimal recognition outcomes. This is an area of active development and improvement. With regard to the aforementioned results, it would appear that the errors have been rectified to date. It is recommended that the hic and assembly files from the chromosome directory be obtained for manual chromosome assignment. ref: Split chromosome

Hi
So will I have to manually split the chromosomes or there is another pipeline that I need to run? I was not able to find any further information on Split chromosome
Thank you

I offer my sincerest apologies. I am only responding to this matter now. Indeed, the .hic and .assembly files must be imported into Juicebox in order to assign the chromosomes. For those lacking experience, the following information may be of assistance: JBAT and chromosome boundaries methods.

Closing due to no activity for 2 weeks. Feel free to reopen if any guidance is needed.


Show concrete info with throws and similar assertions

I want to get details at least the passed expression like () => shouldThrow() because I don't know which assertion has failed from assertion messages.
        AssertionError: Missing expected exception..
            at _throws (node_modules/power-assert/build/power-assert.js:4806:5)

Thank you for the feature request.
at least the passed expression for exception test makes sense to me. It's a bit difficult with current power-assert configuration so I will try to ship with power-assert 2.0.

I see, I'll check that version.


Double click protection with data-disable

First thing first: Thank you for sharing Hotwire! I like it a lot.
Turbo partly replaces rails-ujs. This makes sense. However, together with other functionality we lose double click protection which was implemented in rails-ujs with data-disable and data-disable-with.
Are there any plans or appetite for adding this directly to Turbo? Or do you suggest to handle this with a Stimulus controller instead?
I would kind of like to see this implemented directly in Turbo so this work for people out of the box like it worked with rails-ujs which is installed in Rails by default. On the other hand I would understand if there is no appetite for adding this.

We've stopped recommending removing UJS altogether. See https://github.com/hotwired/turbo-rails/commit/9d53529bedd4de19dea8521d415f40685dfe7749 👍

I just noticed a bug regarding data-disable-with.
If I disable the submit button of a form with GET method, and the result is fetched from the cache, the button stays with the disabled text since it was cached like that.
Disabling the cache solves the issue of course.

@dhh The issue with rails-ujs is that it doesn't listen to Turbo events. So if you use turbo streams to update page content and don't replace the original Turbo frame, then the button which was previously disabled is not enabled again after a Turbo request finishes.
I see two options for improving this:

Add this directly to Turbo.
Create a new super simple UJS adapter (e.g. turbo-ujs).

Do you see any possibility of adding data-confirm directly to Turbo? If not, then the second option is probably a way to go.

If turbo could dispatch ajax:complete in addition to its other events, I think that would make life a lo simpler. A common issue we've come across while upgrading from Turbolinks is this pattern.

User submits a form.
Form submit button is disabled (thanks to data-disabled-with built in to Rails / UJs).
Form has an error that server side validation finds. Previously we'd render create.js.erb which would do something to display the error message. Now we can do the same thing using a turbo stream.
But because ajax:complete never fires, the form submit button remains disabled now.

If turbo could dispatch ajax:complete in addition to its other events, I think that would make life a lo simpler. A common issue we've come across while upgrading from Turbolinks is this pattern.

User submits a form.
Form submit button is disabled (thanks to data-disabled-with built in to Rails / UJs).
Form has an error that server side validation finds. Previously we'd render create.js.erb which would do something to display the error message. Now we can do the same thing using a turbo stream.
But because ajax:complete never fires, the form submit button remains disabled now.

I had a similar issue to @mrhead, and ended up using a stimulus controller based on the one in the hotwired demo.
Controller from the demo: https://github.com/hotwired/hotwire-rails-demo-chat/blob/main/app/assets/javascripts/controllers/reset_form_controller.js
How it's used: https://github.com/hotwired/hotwire-rails-demo-chat/blob/main/app/views/messages/new.html.erb#L5
My full controller ended up looking like this:
import { Controller } from "stimulus"

export default class extends Controller {
  reset() {
    this.element.reset()  // reset form contents
    this.element.querySelectorAll("input[type=submit]").forEach(button => button.disabled = false) // reset data-disable-with
  }
}

I had a similar issue to @mrhead, and ended up using a stimulus controller based on the one in the hotwired demo.
Controller from the demo: https://github.com/hotwired/hotwire-rails-demo-chat/blob/main/app/assets/javascripts/controllers/reset_form_controller.js
How it's used: https://github.com/hotwired/hotwire-rails-demo-chat/blob/main/app/views/messages/new.html.erb#L5
My full controller ended up looking like this:
import { Controller } from "stimulus"

export default class extends Controller {
  reset() {
    this.element.reset()  // reset form contents
    this.element.querySelectorAll("input[type=submit]").forEach(button => button.disabled = false) // reset data-disable-with
  }
}

Here's one for links:
//click_controller.js

import { Controller } from "stimulus"

export default class extends Controller {

	butNotTwice() {
		let linkHref = this.element.href

		setTimeout(() => {
			this.disableLink()
			this.waitThenReEnable(linkHref)
		}, 50)
	}

	//private

	disableLink(){
		this.element.href = "javascript:void(0)"
	}

	waitThenReEnable(linkHref){
		setTimeout(() => {
			if (this.element) this.element.href = linkHref;
		}, 3000)
	}

}

Then in erb:
<%= link_to( " A great product", "products/#{product.id}", data: {controller: "click", action: "click#butNotTwice"})

The cleanest way is to hook register event listeners of the turbo submit event:
import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  connect() {
    this.element.addEventListener("turbo:submit-start", this.toggleDisabledOnFields)
  }

  disconnect() {
    this.element.removeEventListener("turbo:submit-start", this.toggleDisabledOnFields)
  }

  toggleDisabledOnFields({ target }) {
    for (const field of target.elements) field.disabled = !field.disabled
  }
}

And then set data: { controller: "disable" } on your form.


Add CDN with storage account example

Create a CDN profile, a CDN endpoint with a storage account as origin

I have a strange bahevior on this one.
This variable is not translated as is but copied two times in the main.json template:
var storageAccountHostName = replace(replace(reference(storageAccountName).primaryEndpoints.blob, 'https://', ''), '/', '')

Codecov Report

Merging #1030 (cf788a5) into main (a0a38b2) will increase coverage by 0.47%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1030      +/-   ##
==========================================
+ Coverage   94.26%   94.73%   +0.47%
==========================================
  Files         328      324       -4
  Lines       15810    15659     -151
  Branches       12        0      -12
==========================================
- Hits        14903    14835      -68
+ Misses        907      824      -83

Flag
Coverage Δ

dotnet
94.73% <ø> (-0.09%)
:arrow_down:

typescript
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...cep.Core.UnitTests/FileSystem/FileResolverTests.cs
79.31% <0.00%> (-20.69%)
:arrow_down:

.../Bicep.Core.UnitTests/Assertions/BaselineHelper.cs
63.63% <0.00%> (-15.91%)
:arrow_down:

src/Bicep.Core/FileSystem/PathHelper.cs
96.15% <0.00%> (-3.85%)
:arrow_down:

src/Bicep.Core.UnitTests/Utils/CompilerFlags.cs
33.33% <0.00%> (ø)

...Bicep.Core.UnitTests/FileSystem/PathHelperTests.cs
100.00% <0.00%> (ø)

src/vscode-bicep/src/language/client.ts

src/vscode-bicep/src/utils/logger.ts

src/vscode-bicep/src/extension.ts

src/vscode-bicep/src/utils/telemetry.ts

Typo corrected. Another 'properties' missing there:

Does this example work without the endpoint taking a dependency on the profile?


navigator remove unnecessary FW and MC cruise parameters

Rebased into https://github.com/PX4/Firmware/pull/7099.


[tool_crash] ProcessException: Failed to find "D:\flutter\bin\cache\dart-sdk\bin\dartaotruntime.exe" in the search path. Command: D:\flutter\bin\cache\dart-sdk\bin\dartaotruntime.exe, OS error code: 0

Command
flutter --no-color run --machine --track-widget-creation --device-id=emulator-5554 --start-paused --dart-define=flutter.inspector.structuredErrors=true lib\main.dart

Steps to Reproduce

...
...
...

Logs
ProcessException: Failed to find "D:\flutter\bin\cache\dart-sdk\bin\dartaotruntime.exe" in the search path. Command: D:\flutter\bin\cache\dart-sdk\bin\dartaotruntime.exe, OS error code: 0
#0      LocalProcessManager.start (package:process/src/interface/local_process_manager.dart:56:7)
#1      ErrorHandlingProcessManager.start.<anonymous closure> (package:flutter_tools/src/base/error_handling_io.dart:686:24)
#2      _run (package:flutter_tools/src/base/error_handling_io.dart:556:20)
#3      ErrorHandlingProcessManager.start (package:flutter_tools/src/base/error_handling_io.dart:685:12)
#4      DefaultResidentCompiler._compile (package:flutter_tools/src/compile.dart:874:37)
#5      DefaultResidentCompiler._recompile (package:flutter_tools/src/compile.dart:734:14)
#6      _RecompileRequest._run (package:flutter_tools/src/compile.dart:420:16)
#7      _CompilationRequest.run (package:flutter_tools/src/compile.dart:394:30)
#8      DefaultResidentCompiler._handleCompilationRequest (package:flutter_tools/src/compile.dart:780:23)
#9      _rootRunUnary (dart:async/zone.dart:1407:47)
#10     _CustomZone.runUnary (dart:async/zone.dart:1308:19)
#11     _CustomZone.runUnaryGuarded (dart:async/zone.dart:1217:7)
#12     _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:339:11)
#13     _DelayedData.perform (dart:async/stream_impl.dart:515:14)
#14     _PendingEvents.handleNext (dart:async/stream_impl.dart:620:11)
#15     _PendingEvents.schedule.<anonymous closure> (dart:async/stream_impl.dart:591:7)
#16     _rootRun (dart:async/zone.dart:1391:47)
#17     _CustomZone.run (dart:async/zone.dart:1301:19)
#18     _CustomZone.runGuarded (dart:async/zone.dart:1209:7)
#19     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:1249:23)
#20     _rootRun (dart:async/zone.dart:1399:13)
#21     _CustomZone.run (dart:async/zone.dart:1301:19)
#22     _CustomZone.runGuarded (dart:async/zone.dart:1209:7)
#23     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:1249:23)
#24     _microtaskLoop (dart:async/schedule_microtask.dart:40:21)

[✓] Flutter (Channel stable, 3.19.4, on Microsoft Windows [Version 10.0.19045.4046], locale en-US)
    • Flutter version 3.19.4 on channel stable at D:\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 68bfaea224 (8 days ago), 2024-03-20 15:36:31 -0700
    • Engine revision a5c24f538d
    • Dart version 3.3.2
    • DevTools version 2.31.1

[✓] Windows Version (Installed version of Windows is version 10 or higher)

[!] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at C:\Users\Dell\AppData\Local\Android\sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 17.0.9+0--11185874)
    ! Some Android licenses not accepted. To resolve this, run: flutter doctor --android-licenses

[✓] Chrome - develop for the web
    • Chrome at C:\Users\Dell\AppData\Local\Google\Chrome\Application\chrome.exe

[!] Visual Studio - develop Windows apps (Visual Studio Community 2019 16.11.23)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.11.33214.272
    ✗ Visual Studio is missing necessary components. Please re-run the Visual Studio installer for the "Desktop development with C++" workload, and include these components:
        MSVC v142 - VS 2019 C++ x64/x86 build tools
         - If there are multiple build tool versions available, install the latest
        C++ CMake tools for Windows
        Windows 10 SDK

[✓] Android Studio (version 2023.2)
    • Android Studio at C:\Program Files\Android\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.9+0--11185874)

[✓] VS Code (version 1.87.2)
    • VS Code at C:\Users\Dell\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.84.0

[✓] Connected device (4 available)
    • sdk gphone x86 (mobile) • emulator-5554 • android-x86    • Android 11 (API 30) (emulator)
    • Windows (desktop)       • windows       • windows-x64    • Microsoft Windows [Version 10.0.19045.4046]
    • Chrome (web)            • chrome        • web-javascript • Google Chrome 123.0.6312.59
    • Edge (web)              • edge          • web-javascript • Microsoft Edge 122.0.2365.92

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

! Doctor found issues in 2 categories.

Flutter Application Metadata
Type: app
Version: 1.0.0+1
Material: true
Android X: false
Module: false
Plugin: false
Android package: null
iOS bundle identifier: null
Creation channel: stable
Creation framework version: 68bfaea224880b488c617afe30ab12091ea8fa4e

Closing this as a duplicate of https://github.com/flutter/flutter/issues/143391


Refactor codebase to async/await - m365 spo app commands

Closes #5011

Merged manually, thanks for all the good work 👏


Set up test distribution for QuickFeedbackLinux

After a lot of trials and errors, we can run test distribution on QuickFeedbackLinux. The plan is to run QuickFeedbackLinux on 20~25 machines, 100~150 test-distribution-agents cluster.
There will be only one build for Quick Java14 Openjdk Linux afterwards so we can avoid unnecessary TeamCity jobs in build queue. Currently it can finish in 13~15 minutes: https://ge.gradle.org/scans/performance?list.offset=0&list.size=50&list.sortColumn=startTime&list.sortOrder=desc&search.buildToolType=gradle&search.buildToolType=maven&search.relativeStartTime=P7D&search.tags=LOCAL&search.timeZoneId=Asia/Shanghai&search.username=tcagent1
Note that the feedback time can be further improved once https://github.com/gradle/dotcom/issues/6270 is resolved.
The release branch also needs to be updated after this is merged to master.

@bot-gradle test SC

OK, I've already triggered SanityCheck build for you.


Examples in introduction are not runnable

E.g. missing action_type=.

Thanks @itamarst
This looks great. I tried both examples and piped the output through eliot-tree.
I think it might be nice to provide download links to make it even easier to run the examples. Up to you.
Please merge.


Flip variables values

Check this issue in postcss-rtl repo.
The value of the variables is not flipped, for example:
:root {
  --padding: 1rem 1rem 1.5rem 1.5rem;
}

.my-class {
  padding: var(--padding);
}

Is compiled to:
:root {
  --padding: 1rem 1rem 1.5rem 1.5rem;
}

.my-class {
  padding: var(--padding);
}

Curious, a colleague requested exactly the same recently :)
In my opinion, this should be implemented in RTLCSS, so I submitted a pull request. I'll update this issue once that pull request gets accepted.

Hi @fabercancio,
A new version of RTLCSS has released (3.2.0), so I've added a new option to cover your use case.
You can use version 3.3.4 of postcss-rtlcss which already supports this option.
Regards!

Thank you @elchininet!


Elastic 6.4.3 is available

@sivasamyk Please, release a compatible version. Thanks!

Here you go! - https://github.com/sivasamyk/logtrail/releases/download/v0.1.30/logtrail-6.4.3-0.1.30.zip


Redux Generator is omitting the complex type information (such as repatch)

this action
abstract class TopStateAction extends ReduxActions {
ActionDispatcher<Repatch<TopState, TopStateBuilder>> repatchDispatcher;
TopStateAction._();
factory TopStateAction() => new _$TopStateAction();
}
is converted to
class _$TopStateAction extends TopStateAction{
factory $TopStateAction() => new $TopStateAction.();
$TopStateAction.() : super.();
final ActionDispatcher< **null**<TopState,TopStateBuilder> > repatchDispatcher = new ActionDispatcher<**null**<TopState,TopStateBuilder>>('TopStateAction-repatchDispatcher');

@override
void setDispatcher(Dispatcher dispatcher) {
  repatchDispatcher.setDispatcher(dispatcher);
}

}
the type in actiondispather in the generated part file should not be null instead the Repatch
I tested in Dart 2.0 in Dev channel.

That's really weird, especially since it generated the generic types of the repatch correctly.
I don't have a whole lot of ideas unfortunately...
I tried generating this test file from the repatch repo with dart 2.0.0-dev.20.0 and 1.24.3 and it worked just fine...
I tested with:
built_redux: 7.3.5
build_runnder: 0.6.0+1
build: 0.11.1
What versions do you have in your pubspec.lock for those dependencies?

I build a test file and it is same
build_runner: 0.7.5+1
build: 0.11.2
built_redux: 7.3.5
Dart VM version: 2.0.0-dev.19.0 (Fri Jan 19 08:01:12 2018 +0100) on "macos_x64"

Alright, well I'm not quite sure. I have not tried build_runner 0.7.x yet, so I am curious, what does your build script look like? Are your trying to use pub run build_runner build?
Also, what versions do you have pinned for source_gen and analyzer? My best bet to try and reproduce is to get to all of the same dependencies as you.
For what its worth it might be worth staying with build_runner 0.6.x until there is more support for 0.7.x from built_value. Looks like david morgan is working on a pr here: https://github.com/google/built_value.dart/pull/342
I will make a PR to built_redux to follow the same patterns shortly after his gets merged.

Closing as this is stale and I cannot reproduce