Should we mark evidence extension as critical?

The current definition of evidence extension is:
https://github.com/CCC-Attestation/interoperable-ra-tls/blob/6f0a3615de83cff4a276dfa2ac2e70e77caa69ec/docs/Interoperable-RA-TLS-cert-edvidence-formats.md?plain=1#L7-L10
And, accroding to TCG DICE specification draft, the criticality flag of evidence extension should be marked critical.
However, in practice, some TLS libraries may not have a suitable api to handle a custom extension of the critical attribute. For example, openssl does not provide a way to get the custom extension that causes the X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION error.
So maybe we can mark the extension as non-critical, for now.
Any comments are welcome.

I second what @KB5201314 wrote.
The mbedtls library used by Gramine also has the limitation of "fail on unrecognized critical cert extension": https://github.com/Mbed-TLS/mbedtls/blob/ab1f3c153a90d6943c174613b715d19dfddfc83a/library/x509_crt.c#L847-L851
The rationale for this can be read here: https://github.com/Mbed-TLS/mbedtls/blob/development/docs/3.0-migration-guide.md#remove-the-config-option-mbedtls_x509_allow_unsupported_critical_extension

My thoughts are:

From a long term, this extension should be marked as "critical", because finally this extension would be supported by various mainstream tls libraries. And this extension can reflect the device identity of peer TEE so a future browser as tls client must verify this extension for security purpose (and thus show a new icon in the URL bar similar to HTTPS icon).
From a short term, this extension should be marked as "non-critical" as a suggestion documented in practical interoperablera-tls spec.
In addition, for the caller of mbedtls, such as gramine, I suggest gramine should specifically implement the callback for this extension from a long term, because no matter how this extension is marked, gramine's code doesn't need to be modified again. @dimakuv @KB5201314

Agree that if TLS libraries (like openssl or mbedtls) do not support extracting critical extensions, then we will have to mark the quote extension to non-critical for now.
But semantically this extension should be critical, a verifier that can't process the quote should fail.
For reference, openenclave implements RA-TLS on both openssl and mbedtls. As implemented in oe_verify_attestation_certificate(), as part of cert verification, it calls oe_cert_find_extension() to extract the quote extension and verifies the quote. There are separate openssl and mbedtls implementations of oe_cert_find_extension(). Will these implementations fail if the quote extension is marked critical?

There are separate openssl and mbedtls implementations of oe_cert_find_extension(). Will these implementations fail if the quote extension is marked critical?

I didn't look deeply how they are implemented in OE, but in general yes -- OpenSSL and mbedTLS first call their own "parse and verify" logic on the certificate, and only afterwards they call custom verification callbacks.
Well, it should be easy to check how OE behaves on unknown critical extensions. Maybe one of the OE devs can do such an experiment?

I didn't look deeply how they are implemented in OE, but in general yes -- OpenSSL and mbedTLS first call their own "parse and verify" logic on the certificate, and only afterwards they call custom verification callbacks.

@dimakuv Agree with your assessment. Let's put a note in the design document that the criticality flag of this extension will be cleared.

As commented in PR #11, @KB5201314 @dimakuv please let us know when you have a chance to investigate the options discussed there. The best is to be able to keep the criticality flag set.

@DemiMarie Thanks, I didn't know this callback exists.
I will experiment with mbedtls_x509_crt_parse_der_with_ext_cb() and will report on my results here.

@DemiMarie @shnwc I don't think the mbedtls_x509_crt_parse_der_with_ext_cb() callback helps us.
See my explanation in this freshly opened GitHub issue: https://github.com/Mbed-TLS/mbedtls/issues/7182

@dimakuv is it possible to turn of Mbed TLS’s own certificate verification and do everything manually?  I had to make this change in rustls to make it suitable for use with libp2p-quic.


Updated autorest

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Storage.Files.Shares


Feature/website

Added website slicing

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Eugene Lokotkov seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Enhancement/refine coveralls settings

reduced codecover checks to main packages core, format, filter and router

Coverage decreased (-30.2%) to 4.235% when pulling 26b46cfc9417d0c9bcb06e13a590145d08f36814 on enhancement/refine_coveralls_settings into 1e2ea95b65e23471d4013b5bbd6405ef6066ada1 on master.

Coverage increased (+26.3%) to 60.714% when pulling 7e22884d8cc01a73bdcbd16367a22317e46495b7 on enhancement/refine_coveralls_settings into 1e2ea95b65e23471d4013b5bbd6405ef6066ada1 on master.

Coverage increased (+26.3%) to 60.714% when pulling 980f619198f7105b730abca37d363592358a4c85 on enhancement/refine_coveralls_settings into 1e2ea95b65e23471d4013b5bbd6405ef6066ada1 on master.


Push authorization not request (iOS)

Expected Behaviour
iOS alert to request push authorization
Actual Behaviour
permission for notifications not asked.
No registrationId generated
In iPhone settings -> my app page  there isn't push option
Reproduce Scenario (including but not limited to)
Steps to Reproduce
I'm using the sample code from this plugin page
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
iOS 9.3
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
Cordova CLI version and cordova platform version
cordova --version          5.3.3
cordova platform version ios 3.9.2

Plugin version
phonegap-plugin-push 1.6.1 "PushPlugin"
Sample Push Data Payload
N A
Sample Code that illustrates the problem
The sample code from plugin page
Logs taken while reproducing problem
I saw that i have this problem only with iOS 9.3 infant i tried this on iOS 9.2.1 and its work fine! I already read this https://github.com/phonegap/phonegap-plugin-push/issues/752 but i don't understand if the problem is the same and how to resolve.
Thanks to all!

@lucasabba version 1.6.1 of the plugin does not support cordova-ios 3.9.2. You'll have to upgrade to cordova-ios 4.0.0 or later.
https://github.com/phonegap/phonegap-plugin-push/blob/master/plugin.xml#L26

Closing, assume fixed. Re-open if you still have the problem.

Update:
cordova --version 6.1.1
cordova platform version iOS 4.1.1
phonegap-plugin-push 1.6.1 "PushPlugin"
Same problem descripted in first post
Thanks to all

@lucasabba do you have the certificates that match your bundle ID installed?

Yes, certificates is valid and match my bundle id. On iOS 9.2.X it's all ok

@lucasabba I don't know what to tell you as I can't reproduce this. I'd try:
cordova plugin rm phonegap-plugin-push
cordova platform rm ios
cordova platform add<EMAIL_ADDRESS>cordova plugin add phonegap-plugin-push --variable SENDER_ID=XXXXXXXX

@lucasabba any luck getting this resolved?

Same problem...

PhoneGap (iOS / Android / Windows)
cli-6.1.0 (4.1.0 / 5.1.1 / 4.3.1)

Only fails when build thought phonegap remote build, when I make a local build it works properly
Any ideas?

Closing, inactivity. Please comment/re-open if you have more details.


Feature Request: Elements with Aria roles should have all required attributes

https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_aria_03

Sounds good!


Update installation.rst added FFmpeg install

Hi Team Manim
Added ffmpeg install in docs
Hi, I am Rudransh Bharwdaj a developer. When I was making some project I face many problem while installing ffmpeg and I realized that many other developers are also facing this issue so I added how to install ffmpeg for windows, macos, and linux.
If there is any correction please tell me i will solve it .
Thank you
Excited for SoME3

Try to solve this as fast as possible because people are making videos for SoME3 using manim and we have to insure that they will not face any issue and documentation will complete and maintained .
Thanks (again for reading this)

Please reply

.....

broooo pls rply??

thats baad

pls tell is there is any issue or it is ready to merge??

@3b1b is there is any issue related to this request pls reply sir ??

@3b1b @charliepark @shalunov pls review and merge it


Added GuiMsgBoxScroll

This new gui message box is using the component ScrollableContainer to display a text message, instead of TextComponent, used in GuiMsgBox.
That allows to display text with an automatique scrolling.
This new gui will be used to display the updates changelog message.

really cool


Version occasionally reverting to initial versions

It appears that when we are using Manifest.fromConfig(), our search for the latest release version can return invalid results.

We grab the latest X commits on the target branch
We look for a merged release pull request
We fallback to latest GitHub releases that have a SHA matching a recent commit
We fallback to latest GitHub tags that have a SHA matching a recent commit

If step 1 fails (GraphQL), then we have an empty commit set, so step 2, 3, and 4 all fail. Thus release-please assumes we've never created releases before and propose a new release with the initial default version.
Example: https://github.com/googleapis/java-storage/pull/1564 (look at the initial proposed PR).

If step 1 fails, we probably want to error out in this case.

This happened to https://github.com/googleapis/java-notification/pull/643


Home Manager unable to rebuild when the vesktop package is enabled.

Firstly, thank you for the awesome project. Have been looking for something like this for a while.
Anyway. I might be misunderstanding the documentation, but using my attached config home manager is unable to rebuild the system. Commenting out the vesktop package fixes the problem.
{ pkgs, config, ... }:
{
  programs.nixcord = {
    enable = true;  # enable Nixcord. Also installs discord package
    vesktop.enable = true;
    config = {
      frameless = true; # set some Vencord options
      transparent = true;
      plugins = {
        anonymiseFileNames = {
	 enable = true;
	 anonymiseByDefault = true;
	};
	fakeNitro.enable = true;
	callTimer.enable = true;
	clearURLs.enable = true;
	disableCallIdle.enable = true;
	fixCodeblockGap.enable = true;
	fixYoutubeEmbeds.enable = true;
	gameActivityToggle.enable = true;
	gifPaste.enable = true;
	iLoveSpam.enable = true;
	messageLogger.enable = true;
	moreKaomoji.enable = true;
        noScreensharePreview.enable = true;
        platformIndicators.enable = true;
	previewMessage.enable = true;
	reverseImageSearch.enable = true;
	searchReply.enable = true;
	summaries.enable = true;
	sendTimestamps.enable = true;
	shikiCodeblocks.enable = true;
	showConnections.enable = true;
	showHiddenChannels.enable = true;
	showHiddenThings.enable = true;
        spotifyCrack.enable = true;
	translate.enable = true;
        userVoiceShow.enable = true;
	vcNarrator.enable = true;
	voiceMessages.enable = true;
	youtubeAdblock.enable = true;
      };
    };
    extraConfig = {
    };
  };
}

Thank you in advance

Can you post the error code you are getting?
It is likely the settings.json file for Vesktop already exists and is causing a collision.

It is likely the settings.json file for Vesktop already exists and is causing a collision.
That seems to have done the trick.

I was getting the following error:
warning: Git tree '/etc/nixos' is dirty
building the system configuration...
warning: Git tree '/etc/nixos' is dirty
activating the configuration...
setting up /etc...
reloading user units for cary...
restarting sysinit-reactivation.target
restarting the following units: home-manager-cary.service
Failed to restart home-manager-cary.service
the following new units were started: libvirtd.service, run-credentials-systemd\x2dtmpfiles\x2dresetup.service.mount, sysinit-reactivation.target, systemd-tmpfiles-resetup.service
warning: the following units failed: home-manager-cary.service
× home-manager-cary.service - Home Manager environment for cary
     Loaded: loaded (/etc/systemd/system/home-manager-cary.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sat 2024-09-14 02:21:24 CEST; 272ms ago
   Duration: 32min 29.996s
 Invocation: b2d6375c81a243fcb331d06a087d4047
    Process: 5048 ExecStart=/nix/store/hh1d3nhigpky6d6shbnpxmhv4385fhgs-hm-setup-env /nix/store/gvw9pzvnl8n9f3xvfw6civc79hqnjw79-home-manager-generation (code=exited, status=1/FAILURE)
   Main PID: 5048 (code=exited, status=1/FAILURE)
         IP: 0B in, 0B out
   Mem peak: 5.7M
        CPU: 118ms

Sep 14 02:21:24 nixos hm-activate-cary[5224]: Please do one of the following:
Sep 14 02:21:24 nixos hm-activate-cary[5224]: - Move or remove the above files and try again.
Sep 14 02:21:24 nixos hm-activate-cary[5224]: - In standalone mode, use 'home-manager switch -b backup' to back up
Sep 14 02:21:24 nixos hm-activate-cary[5224]:   files automatically.
Sep 14 02:21:24 nixos hm-activate-cary[5224]: - When used as a NixOS or nix-darwin module, set
Sep 14 02:21:24 nixos hm-activate-cary[5224]:     'home-manager.backupFileExtension'
Sep 14 02:21:24 nixos hm-activate-cary[5224]:   to, for example, 'backup' and rebuild.
Sep 14 02:21:24 nixos systemd[1]: home-manager-cary.service: Main process exited, code=exited, status=1/FAILURE
Sep 14 02:21:24 nixos systemd[1]: home-manager-cary.service: Failed with result 'exit-code'.
Sep 14 02:21:24 nixos systemd[1]: Failed to start Home Manager environment for cary.
warning: error(s) occurred while switching to the new configuration

Thank you for the help!

It is likely the settings.json file for Vesktop already exists and is causing a collision.

That seems to have done the trick.
I was getting the following error:
warning: Git tree '/etc/nixos' is dirty
building the system configuration...
warning: Git tree '/etc/nixos' is dirty
activating the configuration...
setting up /etc...
reloading user units for cary...
restarting sysinit-reactivation.target
restarting the following units: home-manager-cary.service
Failed to restart home-manager-cary.service
the following new units were started: libvirtd.service, run-credentials-systemd\x2dtmpfiles\x2dresetup.service.mount, sysinit-reactivation.target, systemd-tmpfiles-resetup.service
warning: the following units failed: home-manager-cary.service
× home-manager-cary.service - Home Manager environment for cary
     Loaded: loaded (/etc/systemd/system/home-manager-cary.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sat 2024-09-14 02:21:24 CEST; 272ms ago
   Duration: 32min 29.996s
 Invocation: b2d6375c81a243fcb331d06a087d4047
    Process: 5048 ExecStart=/nix/store/hh1d3nhigpky6d6shbnpxmhv4385fhgs-hm-setup-env /nix/store/gvw9pzvnl8n9f3xvfw6civc79hqnjw79-home-manager-generation (code=exited, status=1/FAILURE)
   Main PID: 5048 (code=exited, status=1/FAILURE)
         IP: 0B in, 0B out
   Mem peak: 5.7M
        CPU: 118ms

Sep 14 02:21:24 nixos hm-activate-cary[5224]: Please do one of the following:
Sep 14 02:21:24 nixos hm-activate-cary[5224]: - Move or remove the above files and try again.
Sep 14 02:21:24 nixos hm-activate-cary[5224]: - In standalone mode, use 'home-manager switch -b backup' to back up
Sep 14 02:21:24 nixos hm-activate-cary[5224]:   files automatically.
Sep 14 02:21:24 nixos hm-activate-cary[5224]: - When used as a NixOS or nix-darwin module, set
Sep 14 02:21:24 nixos hm-activate-cary[5224]:     'home-manager.backupFileExtension'
Sep 14 02:21:24 nixos hm-activate-cary[5224]:   to, for example, 'backup' and rebuild.
Sep 14 02:21:24 nixos systemd[1]: home-manager-cary.service: Main process exited, code=exited, status=1/FAILURE
Sep 14 02:21:24 nixos systemd[1]: home-manager-cary.service: Failed with result 'exit-code'.
Sep 14 02:21:24 nixos systemd[1]: Failed to start Home Manager environment for cary.
warning: error(s) occurred while switching to the new configuration

Thank you for the help!

Can you send the output of journalctl -xeu home-manager-cary.service?


to use stdint.h macros which declares SIZE_MAX

‘SIZE_MAX’ was not declared in when compiling with OPT ?= -g2 in Makefile,
Compiling on Linux with g++ -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS should fix this issue on the older compilers
__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are a workaround to allow C++ programs to use stdint.h macros specified in the C99 standard that aren't in the C++ standard.

I signed it!


🐛 BUG: Image resizing is not supported by wrangler2 dev

What version of Wrangler are you using?
0.0.17
What operating system are you using?
Mac
Describe the Bug
Any requests for a resized image passes through to the source image (returns "content-type: image/whatever").
This is easily seen when requesting format='json'...
Is this due to wrangler2 using miniflare under the hood? I'm accustomed to this behaviour in local dev with miniflare, and have  a "canary fetch" to a known-good image early in my debug handler to remind me of this situation...
I'm expecting that when I run wrangler2 dev, live image resizing will occur, as it does with wrangler1 dev
(BTW, my wrangler.toml for the env under test points to an enterprise enabled domain with image-resizing activated)
I couldn't find any mention of "image" in the project, 2.0 milestone, or issues - hth!
Regards, ptim

Is this using "sites" functionality? If so, I believe the problem is that in Wrangler2, for dev we intercept requests for assets and serve them locally rather than asking the Edge for them. This is an optimization to save having to upload all assets every time the code changes and we update the Worker.

@petebacondarwin We still use the edge for Sites, uploads and all, so I don't think that's the issue here.
@ptim we don't use miniflare by default, unless you've triggered local mode via --local or the L hotkey (in which case, I don't think we honour the resizing options, but I could be wrong).
This issue may need some investigation. Could you make a sample reproduction repo to help? Thank you!

Here we go: https://github.com/ptim/wrangler2-repro-534

...unless you've triggered local mode via --local or the L hotkey (in which case, I don't think we honour the resizing options, but I could be wrong).

Nope, confident I haven't done either 👍
BTW - unrelated feedback:

although wrangler.toml has workers_dev = false, hitting B opened up https://wrangler2-repro-534.my-org-com.workers.dev/ - not sure if that's expected - I don't really use that functionality
in my work repo, the keys no longer work (eg have to ctrl+c to quit wrangler2). Seemed to work fine in this toy repo, though. Using iterm2 on mac 11.6.2

HTH!

BTW, as a related FR, I'd love to receive warning (maybe a response header?) if image resizing is not enabled - this had me super confused for a while :)
#barrier-to-entry

The latest beta has better support for zoned workers, feel free to give that a spin and let us know if it worked? We'll have a look at the image cache issue in a bit.

@ptim - I just upgraded my account to do image resizing and ran your reproduction (https://workers.bacondarwin.com/wrangler2-repro-534?url=https%3A%2F%2Fi.imgur.com%2FtuJY33L.png).
I could not get it to fail in wrangler dev. I see the same result for the URL above and for http://localhost:8787/?url=https://i.imgur.com/tuJY33L.png in wrangler dev.
Can you please check with the latest alpha?

This was probably fixed in https://github.com/cloudflare/wrangler2/issues/544, since wrangler dev now uses domain entitlements correctly.

Can you please check with the latest alpha?

Thanks - this is working for me now!

Great! Glad you are unblocked. Thanks @threepointone for the fix.


Remove NSObject inheritance from all protocols.

Currently each protocol in HubFramework looks like this:
@protocol HUBImageLoader <NSObject>
- (void)foo;
@end

IMO we can remove inheritance from NSObject in each protocol as far as we don't use any NSObject methods (here is a discussion about this if you want to read more). What does it give us?

Our code will be more swifty.
While writing in Swift we don't need to inherit from NSObject.
Less code in our codebase 😉

What do you think about this?

I'm all for it if it doesn't have any side effects! @rastersize what do you think?

AFAIK there are really only two side effects. The first is that we can’t use @optional to mark methods as optional in protocol. Fortunately we don’t do that 😊 Secondly we’d technically not know if our objects respond to a bunch of methods we might need, such as -isEqual:.
But it would be great to get rid of the conformance. Something for 2.1 I’d say. The tasks we need to complete to get to this state are at least:

Audit every place where we assume an object is of type NSObject.

There are a few places where we type things as NSObject<Something>. This is probably not always true at the moment anyhow and will likely not be true afterwards.

Make sure anything that needs, e.g., -isEqual: continues to conform to NSObject or something similar.
Add linter making sure we don’t introduce new protocols conforming to NSObject.
Add linter making sure we don’t introduce @optional in a protocol.
Remove conformance of NSObject from our protocols.

All in all, I’m in favor of this proposal.

Ok, let's consider this proposal passed! 👍 @krris want to proceed with the implementation?

@JohnSundell I would love to.

What about using http://oclint.org/ as a linter? 👍  or 👎  ?

I'm not opposed to trying OCLint out. Seems to be widely used as well. @rastersize, @8W9aG, @cerihughes, any opinions?

@krris @JohnSundell The problem we’ve encountered with linters so far is the pain of getting them configured for our code style. But if we can get that to work I’m all for linting.

@krris I have not looked to much into OCLint myself, how does it compare to the clang linter (ClangFormat)?

Do we need to use it to lint for code style though (even though it would be super nice of course) - but maybe a first step is just to get it to lint for NSObject conformance + optional methods? Question is, do we even need a full blown linter for that? Simply string searching source files should do, right?

I think if you can get it working it sounds like a good idea, I tried to get it working 2 years and failed but maybe it's evolved now

@rastersize It's hard to compare them for me. I've never used any of them. I saw only that we use OCLint in ios-client.

I took a quick 🔪 at this a few days ago. Main issue is that we need to check if objects conform to protocols (-conformsToProtocol:. Which is a method from the NSObject protocol so we cannot send the message unless conforming. Thinking about a way of working around this.

Hi @rastersize and co, I was intrigued by the discussion on this issue and played a little with an idea for solving the conformsToProtocol problem. Please see the above PR.

#265 has been merged, there’s no longer any need to inherit from NSObject for Swift code 🐦🎉


ng build --prod --aot fail

Hi Team,
I am getting below issue while running "ng build --prod --aot"
ERROR in ./src/main.ts
Module not found: Error: Can't resolve './app/app.module.ngfactory' in '/Users/B0096396/sonu/LMS/LMS_FrontEnd/src'
PFB version details
_                      _                 ____ _     ___

/ \   _ __   __ _ _   | | __ _ _ __     / | |   | |
/ △ \ | ' \ / _ | | | | |/ _ | '|   | |   | |    | |
/ ___ | | | | (| | || | | (| | |      | || | | |
//   __| ||_, |_,||_,||       _|||
|___/
Angular CLI: 1.6.8
Node: 8.9.4
OS: darwin x64
Angular: 5.2.10
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router
@angular/cli: 1.6.8
@angular-devkit/build-optimizer: 0.0.42
@angular-devkit/core: 0.0.29
@angular-devkit/schematics: 0.0.52
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.8
@schematics/angular: 0.1.17
typescript: 2.5.3
webpack: 3.10.0

Hello, could you provide minimal reproduction so that we can investigate it?

hi @alexzuza
I noticed that with latest ng-cli (1.7.4) as well in my project.
you can fork my project https://github.com/orizens/echoes-player and run ng build --prod

Hi, @orizens. I have successfully built your project (master branch).

@alexzuza
build process is fine, however, if you try to run npm run start:prod(that - assuming you run ng server --prod, no need to pass in youtube keys) - the resulting localhost:4200 appears to be broken.

I'm sorry, but we can't reproduce the problem following the instructions you provided.
Remember that we have a large number of issues to resolve, and have only a limited amount of time to reproduce your issue.
Short, explicit instructions make it much more likely we'll be able to reproduce the problem so we can fix it.
If the problem persists, please open a new issue following our submission guidelines.
A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.


ERROR: Parent node is busy setting up children, add_child() failed. Consider using add_child.call_deferred(child) instead.

Hello!
I'm making a game at Godot that plays with first-person Parkour mechanics and somehow, shortly after I messed with the resolution settings of my project, this bug started showing up in my project both in the console and in Debugger.
The biggest problem with this bug is that it doesn't allow me to open my Project Settings. Every time I try, the engine crashes.
I first reported it on the Godot Facebook group, but nobody found the problem. Some users pointed out the possibility of some plugin causing this problem, but the only plugin I'm using is a Kanban plugin that I've had since the beginning of the project it didn't give problems before and the problem doesn't go away after I delete it.
I haven't found other people with the same problem, only this case (https://github.com/godotengine/godot/issues/73765) in which the same bug happens in a different way and by triggering an option that is not activated in my project.
I am convinced that this is some structural bug in the engine because the more I spindle my project and all my scripts, the less I find reasons for it to happen, considering that it appears every time the game is started.
Anyway, I'm sending here the code from my Main Scene, my project.godot and my global script, which are nothing big, just basic scripts to set the game menu (after all, the bug appears as soon as the engine starts, before any scene is started).
project.godot:
; Engine configuration file.
; It's best edited using the editor UI and not directly,
; since the parameters that go here are not all obvious.
;
; Format:
;   [section] ; section goes between []
;   param=value ; assign values to parameters

config_version=5

[application]

config/name="FPSTest"
run/main_scene="res://main_game_root.tscn"
config/features=PackedStringArray("4.0", "Forward Plus")
config/icon="res://icon.svg"

[autoload]

Global="*res://Global.gd"

[display]

window/size/resizable=false
window/stretch/mode="canvas_items"

[editor_plugins]

enabled=PackedStringArray("res://addons/kanban_tasks/plugin.cfg")

[input]

ui_accept={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":0,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":32,"physical_keycode":0,"key_label":0,"unicode":32,"echo":false,"script":null)
]
}
ui_select={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":4194325,"key_label":0,"unicode":0,"echo":false,"script":null)
]
}
ui_focus_next={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":4194326,"key_label":0,"unicode":0,"echo":false,"script":null)
]
}
ui_left={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":0,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":4194319,"physical_keycode":0,"key_label":0,"unicode":4194319,"echo":false,"script":null)
, Object(InputEventJoypadButton,"resource_local_to_scene":false,"resource_name":"","device":0,"button_index":13,"pressure":0.0,"pressed":false,"script":null)
, Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":65,"key_label":0,"unicode":97,"echo":false,"script":null)
]
}
ui_right={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":0,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":4194321,"physical_keycode":0,"key_label":0,"unicode":4194321,"echo":false,"script":null)
, Object(InputEventJoypadButton,"resource_local_to_scene":false,"resource_name":"","device":0,"button_index":14,"pressure":0.0,"pressed":false,"script":null)
, Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":68,"key_label":0,"unicode":100,"echo":false,"script":null)
]
}
ui_up={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":0,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":4194320,"physical_keycode":0,"key_label":0,"unicode":4194320,"echo":false,"script":null)
, Object(InputEventJoypadButton,"resource_local_to_scene":false,"resource_name":"","device":0,"button_index":11,"pressure":0.0,"pressed":false,"script":null)
, Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":87,"key_label":0,"unicode":119,"echo":false,"script":null)
]
}
ui_down={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":0,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":4194322,"physical_keycode":0,"key_label":0,"unicode":4194322,"echo":false,"script":null)
, Object(InputEventJoypadButton,"resource_local_to_scene":false,"resource_name":"","device":0,"button_index":12,"pressure":0.0,"pressed":false,"script":null)
, Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":83,"key_label":0,"unicode":115,"echo":false,"script":null)
]
}
Dash={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":67,"key_label":0,"unicode":99,"echo":false,"script":null)
]
}
Jump={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":32,"key_label":0,"unicode":32,"echo":false,"script":null)
]
}
Pause={
"deadzone": 0.5,
"events": [Object(InputEventKey,"resource_local_to_scene":false,"resource_name":"","device":-1,"window_id":0,"alt_pressed":false,"shift_pressed":false,"ctrl_pressed":false,"meta_pressed":false,"pressed":false,"keycode":0,"physical_keycode":4194305,"key_label":0,"unicode":0,"echo":false,"script":null)
]
}

[physics]

common/physics_ticks_per_second=250

Main scene Script:
extends Control

@export var lastScene: String
@export var actualScene: String
@export var nextScene: String
var instanceScene

@export var loadingScene = load("res://HUD/load_screen.tscn")
var instancedLoadingScene = loadingScene.instantiate()

var gameVis
var configVis
var menuVis
var loadVis

func _ready():
	pass

func _process(_delta):
	_menuScreen()
	_pauseScreen()
	_configScreen()

	gameVis = Global.gameVis
	configVis = Global.configVis
	menuVis = Global.menuVis
	loadVis = Global.loadVis

	nextScene = Global.nextSceneToLoad

	if Global.loadIsReady == true:
		if $SubViewportContainer/SubViewport/GameLayer.get_child_count() == 0:
			instanceScene = load(nextScene).instantiate()
			$SubViewportContainer/SubViewport/GameLayer.add_child(instanceScene)
			Global.loadIsReady = false
			Global.gameVis = true
			Global.configVis = false
			Global.menuVis = false
			Global.loadVis = false
			$SubViewportContainer/SubViewport/Background.visible = false
		else:
			Global.loadIsReady = false

	if Global.isItLoading == true:
		if $SubViewportContainer/SubViewport/LoadingLayer.get_child_count() == 0:
			$SubViewportContainer/SubViewport/LoadingLayer.add_child(instancedLoadingScene)
			Global.isItLoading = false
		else:
			Global.isItLoading = false

	$SubViewportContainer/SubViewport/GameLayer.visible = gameVis
	$SubViewportContainer/SubViewport/ConfigMenuLayer.visible = configVis
	$SubViewportContainer/SubViewport/MenuLayer.visible = menuVis
	$SubViewportContainer/SubViewport/LoadingLayer.visible = loadVis

func _menuScreen():
	pass

func _pauseScreen():
	pass

func _configScreen():
	pass

func _loadingScreen():
	pass

Global Script:
extends Node

var gameVis = false
var configVis = false
var menuVis = true
var loadVis = false

var nextSceneToLoad = "res://HUD/load_screen.tscn"
var loadIsReady = false
var isItLoading = false

var pauseState = false

Plus, The error after I play the game:
Parent node is busy setting up children, `add_child()` failed. Consider using `add_child.call_deferred(child)` instead.
scene/main/window.cpp:1459 - Condition "!is_inside_tree()" is true.
Parent node is busy setting up children, `add_child()` failed. Consider using `add_child.call_deferred(child)` instead.
Parent node is busy setting up children, `add_child()` failed. Consider using `add_child.call_deferred(child)` instead.

A new update about this bug: IT IS HAPPENING EVEN IN NEW UNTOUCHED PROJECTS!!!!
I was so frustrated trying to delete specific things in the programming to correct this bug, but nothing was working. Then, I just started a new project empty and just created a node. Nothing more than that, and the bug happened! I don't know if it is some problem with my system specifically but I really don't know what I can do.

Since update to 4.03 stable, I am getting it as well. It is happening now; where previously, it never happened. I am calling 2 functions that instantiate objects preloaded in another script that is autoloaded.

I think I discovered what is happening, it is probably a cache conflict.
Like I said in my last post, this error was blocking me to access my project settings even when I just started a new project. I was curious about it because, in the (https://github.com/godotengine/godot/issues/73765) case, the developer was doing completely different things and ended up finding the same error.
Well, I was working on another aspect of my game and I had an error that recently stopped the engine and restarted it (I couldn't take the error because was too fast), but when I come back, I could back to access my game settings but now, my export function was not working.
So, I think "It's the same project as before, with nothing changed. What could have changed this to "move the error from one point to another"? Then I realize a thing: The cache!
Every time the cache changes, no matter what I do. The project is sometimes still the same, but these errors change place and the only thing that the GitHub Desktop accuses of change is the cache.
So, I made a try and deleted the .godot folder in my project before starting my game, and god, it works!!!!!! It's not a definitive solution but for now, I think it can save many projects from everyone who is working at Godot 4 right now and find this error.
I am not a programming engineer so I am not able to go further at this point, but I really help this discovery help the devs for when Godot 4.0.4 releases. Maybe creating a system that restarts the old cache every time the project starts? Just a suggestion.

Can you attach some minimal reproduction project?

Actually, yes, can send you the archives. Not just that but I discovered that if I delete all the cache from the engine folder, not just the project folder, the bug will be correct at all. I will send here 2 zip files, one is my old cache from my engine. I believe if you put it in your cache folder, the bug will come back.
The other one is my .godot folder from my project, so you can try it in one empty project and see this bug. I can also send you an older version of my game with the bug if necessary, but I would be more comfortable sending it to you privately because, it's not a biiiiig and complex project, but I am working on it and don't want to put it online yet.
Considering it is too big to upload here, I am sending those files at the drive in this link (it's late right now, so I am letting upload it. If you don't two zip files in the folder, wait a bit and they probably will appear): https://drive.google.com/drive/folders/1cwPocqiefEqm1nkgX1AkuQXgptmtsBds?usp=drive_link

The other one is my .godot folder from my project, so you can try it in one empty project and see this bug.

Well, I don't see this bug. Although I didn't download the 2GB file .-.
It doesn't sound like an error that would be triggered by project cache. By minimal reproduction project I meant some scene/script that exhibits the problem.

Well, I don't know what to think about it then. I'll try to list the events in order so we can try to find a pattern:
-This bug just appeared on my Godot 4.0.3 engine without any reason and stayed there even I start a new project. I turn on the engine and there it is, crashing the program when I try to access the editor or the export window.
-When I deleted the .godot folder from my project (the one that is in the link that I send you), the bud stops to block my settings but still showed on the debugger.
-When I delete the cache folder from my own Godot, the bug stops in any project and shows in the debugger.
-(a today update) After some time, the bug reappeared in the debugger without locking the settings windows, but redoing the process "corrected" it again.
As I said, I am not a programmer engineer, so I am not able to go much further as this in what could be happening. The only thing I know is that, if the cache is not what is causing the bug, at least the reason is being stored there from time to time. Maybe is a thing that is happening due to my PC configurations?
I'll put here my PC configuration so maybe someone can see if it has any relation:
-I9 12900HX
-32 GB of RAM
-GeForce RTX 3080 Ti Laptop GPU
-Notebook HP Omen
-Windows 10
Hope it helps to solve it. :/

Wait, so you are getting this error in the editor?
Can you reproduce in 4.1 dev?

I apologize for the delay in response.
Regarding the editor issue, it was occurring before but I haven't been able to replicate it after deleting the project and engine cache. Previously, the project settings, editor settings, or export windows would randomly crash, and attempting to open those windows would cause the engine to crash. However, the bug still exists in the editor, but it no longer blocks or crashes those windows.
As for the 4.1 dev, the bugs were still present even after deleting the cache. Currently, the bug appears in the Debugger when I open my project, but it doesn't block any functions even after deleting all the caches. I was considering recreating my project in Godot 4.1 Dev to see if starting from scratch would fix the issue. However, I changed my physics_tics_per_second value to accommodate a parkour mechanic, and when I switched to 4.1, my physics became completely broken and I am unsure how to properly regulate it.

I can confirm exactly everything you say about this error, the same thing just happened to me. I changed, deleted and created a new project, this error still appears. I even tried several versions of Godot 4x and the same thing happens in all of them. The physics are broken or do not work correctly. I was trying to create a pixel art platform game in the latest version of Godot: 4.1.1
I haven't tried clearing the cache yet. If anyone found a solution for this, I would appreciate reporting it here.

I apologize for the delay in response. Regarding the editor issue, it was occurring before but I haven't been able to replicate it after deleting the project and engine cache. Previously, the project settings, editor settings, or export windows would randomly crash, and attempting to open those windows would cause the engine to crash. However, the bug still exists in the editor, but it no longer blocks or crashes those windows. As for the 4.1 dev, the bugs were still present even after deleting the cache. Currently, the bug appears in the Debugger when I open my project, but it doesn't block any functions even after deleting all the caches. I was considering recreating my project in Godot 4.1 Dev to see if starting from scratch would fix the issue. However, I changed my physics_tics_per_second value to accommodate a parkour mechanic, and when I switched to 4.1, my physics became completely broken and I am unsure how to properly regulate it.

Can you confirm if you were able to solve the problem with the solution I found?

So, after all this time, I discovered something that can be interesting for all this situation.
Other similar errors occurred in my project that was given a similar conflict in my project. I discovered that Godot can crash your project if you open your project in one window and then open it again in another without closing the first one. Probably it creates some corruptive files in conflict in cache.
The easy solution I found:
-Create a new game without anything inside.
-Copy the .godot folder from it
-Delete the .godot folder from your project and paste the one you copy (delete it completely, don't overwrite it)
I don't know if it works for all situations, but for sure will solve the majority of them.

This is still an issue in 4.2.
It seems to be an editor issue, with no effects on the actual game.
Running the game straight from command line does not display the error.
I have "Save on focus loss" enabled + I switch between two editors (different projects).
It's a bit unclear when exactly the error is triggered, but focus loss would be my best bet.

I noticed that problem on Godot 3.5.2 stable

This is still an issue in 4.2. It seems to be an editor issue, with no effects on the actual game. Running the game straight from command line does not display the error.
I have "Save on focus loss" enabled + I switch between two open editors (different projects).
It's a bit unclear when exactly the error is triggered, but focus loss would be my best bet.
EDIT: disabling "Save on focus loss" seems to fix the issue

Exact. It's what worked for me 👌

Still present in 4.2.1.
MRP attached, Just focus/unfocus the Godot window and it is logged.
Error only happens when "interface/editor/save_on_focus_loss" is enabled.
test.zip

Seems like interface/editor/save_on_focus_loss is bugged in general, in any project. Unfocusing the window will cause error, because the progress dialog is not inside tree and it fails to enter tree, because it tries to do so doing notification. I tried delaying it, but you can't use call_deferred() and waiting for a process frame causes stack overflow, because EditorProgressDialog calls Main::iteration() 😬
I eventually managed to fix the error, but save_on_focus_loss is still unusable. The editor regains focus after saving scene, so you can't switch to another window at all. I think it needs some rework.
Here's a patch that fixes the error:
fix_focus_error.txt

I noticed this happens only on Windows platforms, I work on the same project on both linux(ubuntu) and a windows setup, windows exhibits this behavior, linux doesn't.
There are also more file locking errors I sometimes encounter only on windows.
Might has something to do with a lack of permissions

I noticed this happens only on Windows platforms, I work on the same project on both linux(ubuntu) and a windows setup, windows exhibits this behavior, linux doesn't. There are also more file locking errors I sometimes encounter only on windows. Might has something to do with a lack of permissions

It seems like a file locking issue

Started happening with my Godot as well in new projects with 0 changes in them.

I can also confirm this is happening in 4.2.1 when auto save on focus loss is enabled.  Once it is disabled. the error disappears.  I made numerous changes to my project trying to figure it out, only to find it's an editor bug.  I am on Windows 10.

I can confirm this issue happens even when I do not enable 'save on focus'.

I started getting this error in v4.3.dev5.official [c9c17d6ca]
Parent node is busy setting up children, `add_child()` failed. Consider using `add_child.call_deferred(child)` instead.

I do not have save on focus enabled and never had.
This error appears in editor on load and also in release build.
I have not been able to pin point at which stage this error started appearing and to which code change it relates to. I might add more info later.
It would be useful in the mean time if the error message can give more context, as what have caused it.

For me, this has been happening for the last few 4.3 dev versions. It seems to only happen once on project open, but it may have happened once or twice after that.
I'm running v4.3.dev5.mono.official [89f70e98d] right now.
Parent node is busy setting up children, `add_child()` failed. Consider using `add_child.call_deferred(child)` instead.
scene/main/window.cpp:1718 - Condition "!is_inside_tree()" is true.

I am not getting this error any more on v4.3.dev6.official [64520fe67] is it same for others ?

The issue with "Save on Focus Loss" is a duplicate of #73765 and has just been fixed (for 4.3.beta1, should still be reproducible in 4.3.dev6).
Then it sounds some users had another recent issue without "Save on Focus Loss" in 4.3.dev5, which appears to be fixed in 4.3.dev6.
So this can be closed IMO.

Actually, I'm still getting the error on 4.3.dev6.mono, every time I open a project.

Actually, I'm still getting the error on 4.3.dev6.mono, every time I open a project.

Yes it's been solved after dev6, see https://github.com/godotengine/godot/issues/77095#issuecomment-2104290472


Add commitlint

There have been several PRs merged that didn't have the proper commit format (which resulted in the package not getting deployed).  Adding commitlint will help this:
https://github.com/conventional-changelog/commitlint#getting-started

Fixed.


about heatmap

In the paper, "Here, the points in red are the ones with the top 5% largest feature norm in the point-based branch.".
I want to know if feature norm means feature vector L2 norm?(sprt(x^2+y^2+z^2....))

That's right. We were using L2 feature norm.


Additional work to support state pages

https://www.figma.com/file/MWzmEAYQC1NYZiD4BG0FlI/V2-Fast-Follows?type=design&node-id=1693-12444&mode=design&t=8GwJSiiw2MYSvZBf-0


Photonpump should send heartbeat requests to the server

If we close the connection from underneath photonpump, eg. by terminating a VPN tunnel, then the client never notices any difference.
We should periodically (suggest every 60 secs) send a heartbeat request to the server. If we fail some consecutive number of requests, we should issue a reconnection request to the connection handler.

If we implement the Connector, per #9 then we can hook this logic up in there. We'll set up some kind of dead man's switch, and write events for HeartbeatRequested, HeartbeatReceived, and HeartbeatTimeout into the queue.

something like:
error = 0
async def send_heartbeat(time=60, error=error):
    if error > 5:
         queue.put("HeartbeatError")
    try:
        await i_am_alive(url)
       queue.put("HeartbeatReceived")
    except:
        error += 1
        queue.put("HeartbeatFailed")
    await asyncio.sleep(time)


Delete comment after handling

@aurora-editor-bot please approve.

@aurora-editor-bot please approve.

@aurora-editor-bot please approve this PR

@aurora-editor-bot please approve this PR

@aurora-editor-bot please reject

@aurora-editor-bot please reject this PR

@aurora-editor-bot please reject this PR.

@aurora-editor-bot please reject this PR.

@aurora-editor-bot please accept this PR.


feat(obstacle_cruise_planner): add terminal collision checker

Description
Currently, obstacle cruise planner does not check the collision with obstacles at the end of the trajectory. In this PR, I extended the goal to enable it to check the collision even when it almost arrives at the goal.

Related links

Tests performed

Notes for reviewers

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

https://github.com/tier4/autoware_launch/pull/471

Open this PR after this PR gets approval form the reviewer.


Minor typo

Link text has "Compiled nindings" instead of "Compiled bindings" in the section snipped below.
Note
Compiled bindings can be enabled to improve data binding performance in .NET MAUI applications. For more information, see Compiled nindings.

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

ID: a8ec6047-0b7b-ca7b-f1f5-22b005fab87c
Version Independent ID: a8ec6047-0b7b-ca7b-f1f5-22b005fab87c
Content: Populate a CollectionView with Data - .NET MAUI
Content Source: docs/user-interface/controls/collectionview/populate-data.md
Product: dotnet-mobile
Technology: dotnet-maui
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Thank you for opening this issue. I'll get this fixed up.


Revert "Merge prune-cfd-stage-1 branch"

Reverts EOSIO/eos#9061
Caused issue with ship clients. state_history_plugin and abieos ship_protocol needs to be updated.
Updates needed before merge:

Change SHiP log serialization format to add compression and padding.
Change SHiP protocol to introduce get_blocks_result_v1, partial_transaction_v1, and the signed_block variant.
Update rodeos, abieos, and whatever else needs to be updated so that rodeos/eosio-tester are able to support the new SHiP protocol.

Closing in favor of: https://github.com/EOSIO/eos/pull/9069


Avoid double validation of payloads

The call to validate a schema is quite expensive:
[3] pry(#<GovukSchemas::RandomExample>)> puts Benchmark.measure { 100.times { JSON::Validator.fully_validate(@Schema, item, errors_as_objects: true) } }
  7.614167   1.532485   9.146652 ( 10.468765)

This updates the code to avoid making two calls to the validator when a
payload is generated with a block if the customised version is valid.
Before:
irb(main):010:0> puts Benchmark.measure { 100.times { GovukSchemas::RandomExample.for_schema(frontend_schema: "news_artic
le") { |schema| schema["title"] = "Custom"; schema } } }
 13.308641   3.087679  16.396320 ( 18.977005)

After:
irb(main):002:0> puts Benchmark.measure { 100.times { GovukSchemas::RandomExample.for_schema(frontend_schema: "news_artic
le") { |schema| schema["title"] = "Custom"; schema } } }
  7.654303   1.561620   9.215923 ( 10.604802)

The motivation for this was that the GOV.UK Chat test suite makes quite
heavy use of random schemas with customisations for checking supported
schemas. On a MBP with GOV.UK Docker this reduces the time of the
running the test suite from around ~55s to around ~35s.

Thanks for picking this up @yndajas 👍


FIX: docker-compose on windows

Normalize line-endings to LF in unix files.

Wait. This didn't push the unix-endings huh.


ONNX2TRT: Fix illegal instruction error caused by numpy 1.19.5.

Issue #, if available:

The issue comes from the numpy 1.19.5 will cause Illegal Instruction error on Jetson device.
https://github.com/numpy/numpy/issues/18131

Description of changes:

This hotfix is done by downgrading the numpy version to 1.19.4 for python3.6.
The changes has been tested on AWS Panorama and works well.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This looks great. Thank you Kevin


createorder not working

"#{@url}#{path}"
=> "https://api.quoine.com//orders"

it seems to be an error if duplicate slashes.

Quoinex::CreateOrderException: 401 Unauthorized

So i think  to fix the following.
https://github.com/heelhook/quoinex/blob/master/lib/quoinex/quoinex.rb#L13
url: 'https://api.quoine.com/'
new: url: 'https://api.quoine.com'

 "#{@url}#{path}"
=> "https://api.quoine.com/orders"

createorder success

Yup, I've recently fixed this.


Add support for periodically clearing the dependencies cache.

I would like to be able to clear out the dependencies cache every N days.

Your current options are:

Enable cache-cleanup so that any unused files are purged from Gradle User Home. This should include removing any dependency files that weren't referenced in the current workflow step.
Periodically enable cache-write-only so that you start the workflow with a clean Gradle User Home

Does either of these satisfy your requirements? If not, can you please explain your use case?

I don't think either of those will fit my use case.
If a specific dependency version gets quarantined (i.e. blocked at the maven repo proxy), I want the build to fail within some limited time frame ("N days") after it is quarantined.
Currently, if I understand how it works, a quarantined dependency could survive in the cache indefinitely and the build will never re-fetch it from the server.
One way of doing this would be to have the Julian Day divided by N (integer division) included as part of the cache key for dependencies, so the cache key changes every N days, even if nothing else changed.
I want the build to automatically fail on quarantined dependencies no more than N days after the deps was first quarantined, in an automated way, with no additional action needed by the developers.

Enable cache-cleanup so that any unused files are purged from Gradle User Home. This should include removing any dependency files that weren't referenced in the current workflow step.

The dependency is always used so this wouldn't cause it to be cleaned up.

Periodically enable cache-write-only so that you start the workflow with a clean Gradle User Home

After cache-write-only was disabled again, I don't think this would prevent builds from accessing an older cache from a previous build before cache-write-only was enabled .

So your goal is to verify that all of the dependencies in the build are still available in the remote repository?
Then I think the best solution would be to periodically execute a build using --refresh-dependencies. This will be the most efficient, since it will use HTTP HEAD to check if the artifact in the repository exactly matches what is in the cache, and will only re-download if it's changed. But this action WILL fail if the dependency no longer exists in the remote repository.

After cache-write-only was disabled again, I don't think this would prevent builds from accessing an older cache from a previous build before cache-write-only was enabled .

When you run a build with cache-write-only, then end result is a new cache entry that will be used by all subsequent builds. The older cache entry won't be used.

When you configure a GitHub Actions Job with cache-write-only, then end result is a new cache entry that will be used by all subsequent builds for that workflow Job. The older cache entry won't be used.

Even if the build fails it will create a new cache entry that will be used in all future jobs?

Then I think the best solution would be to periodically execute a build using --refresh-dependencies.

If any build fails because of a dependency that is no longer available, I want ALL subsequent builds to always fail for that version of the dependency.
if I run with --refresh-dependencies only on every Nth day, but nothing changes, the build may fail on the Nth day, but might start passing again on the (N+1) day when there is no --refresh-dependencies and the artifact is still in the cache.

A more general solution would probably be to put this in Gradle itself. I.e. have a org.gradle.refreshDependenciesAfterDays=N property.

I filed this: https://github.com/gradle/gradle/issues/27410

When you configure a GitHub Actions Job with cache-write-only, then end result is a new cache entry that will be used by all subsequent builds for that workflow Job. The older cache entry won't be used.

Even if the build fails it will create a new cache entry that will be used in all future jobs?

Yes, that's correct. The action will save the Gradle User Home state even if the build fails.
Any subsequent build for the same job will prefer this new cache entry. You can read more about the way cache entries are matched here.
Now that I fully understand your requirements, here are some options you could try:

Run the workflow with cache-write-only: true every N days. This will effectively run the build with a clean Gradle User Home, and all subsequent workflow runs will use the resulting Gradle User Home cache entry.
2.Run the workflow with gradle-home-cache-excludes: caches/modules-2/files-2.1 every N days. This will delete any downloaded dependencies before saving the Gradle User Home state. This won't impact the current build, but the next build will need to re-download dependencies.
Add a step to the workflow that runs every N days, that purges the ~/.gradle/modules-2/files-2.1 directory after the Gradle User Home has been restored but before Gradle is executed. This is a cross between 1 & 2: only the downloaded dependencies are removed, but they will need to be re-downloaded in the current workflow execution.

Presumably, all 3 of those options would need to happen on a build from the default branch (e.g. main ) ?

Presumably, all 3 of those options would need to happen on a build from the default branch (e.g. main ) ?

Presumably this would need to happen in every Job that can produce a cache entry, on each branch that the Job can run on. Cache entries written for a branch will take precedent over cache entries written for main, but these entries are scoped to be only visible to the branch that wrote them. By understanding the way that cache entries are matched (see here) you may be able to model a system that works for you.
I can see that this isn't trivial. If instead you want to brute-force the expiry of all cache entries every N days, you have a few options:

Delete all cache entries for the repository every N days (using the GitHub API or GitHub CLI)
As per 1), but restrict cache entry deletion to entries named dependencies-*. These are the entries that Gradle saves from caches/modules-2/files-2.1
Use the undocumented GRADLE_BUILD_ACTION_CACHE_KEY_PREFIX environment variable to provide a new cache entry prefix every N days. This will effectively expire all gradle-build-action cache entries that use an older prefix.

To avoid complicating the action, we don't plan to add support for periodically clearing the cache. Instead, we suggest that the existing GitHub APIs are used to remove cache entries periodically.


Dodecarotor cox failed to load bottom_cox mixer

I am testing a Dodecarotor cox, using pixHawk & Firmware 1.8.0.
Some details about version are as follows:
HW arch: PX4FMU_V2
HW type: V2
HW version: 0x00090008
HW revision: 0x00000000
FW git-hash: 96443b3cf3e3adaec8b2ebb6c83a19a92d40a13f
FW version: 1.8.0 0 (17301504)
During initialization,  it shows that "failed to load mixers from /etc/mixers/dodeca_bottom_cox.aux.mix".

What should I do?

Hello,
I found the reason why error happens, "ret" is -1.
https://github.com/PX4/Firmware/blob/96443b3cf3e3adaec8b2ebb6c83a19a92d40a13f/src/systemcmds/mixer/mixer.cpp#L160
But I still don't know how to get it done. Does PixHawk support Dodecarotor cox?


Stop test --doc from silently ignoring other target selecting options

Fixes #5054

r? @matklad
(rust_highfive has picked a reviewer for you, use r? to override)

@bors: r+

:pushpin: Commit ac600aed4db02167ba2775304b67a68f22c2650e has been approved by alexcrichton

:hourglass: Testing commit ac600aed4db02167ba2775304b67a68f22c2650e with merge b7ef8d5763cac1e0697a3ecb810535ade55434c2...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing b7ef8d5763cac1e0697a3ecb810535ade55434c2 to master...


Using in vanilla JS / JavaScript projects

Is it possible to use this package for vanilla js?
Even without the type annotations, TypeScripts autocomplete suggestions are a lot better than those of most other Atom packages I tried.

Even without the type annotations,

sadly not at the moment. The TypeScript compiler is really stingy about file extensions. And we've followed this convention deep within our code.
Leaving open as a wishlist :rose:

For me this is more about being able to use some of typescripts abilities without having to change the workflow of everyone on the team. For a lot of people even changing the file extension is to much as they are js purists aka don't like the idea of typescript. This way you can work along side another js dev without effecting them at all.
I wonder how Visual Studio Code has implemented the feature as they are just using the standard ts compiler.

+1 It would be great use TS features in .js files

It seems the TypeScript team agrees.  Take a look at the items tagged salsa on their issues list.  This may be coming in a future language service version, in which case I assume we'd add support for it.

:+1:

+1

:+1:

:+1:

:+

+1

Foreword: I will most likely not get to it anytime soon.
TypeScript has officially unleashed the allowJS option : http://blogs.msdn.com/b/typescript/archive/2016/01/28/announcing-typescript-1-8-beta.aspx
So about time we support it. Not marking as up for grabs as reviewing this is going to be just as much work as adding and then supporting it. The following is a list of tasks that needs to happen

[ ] allowJS in tsconfig compiler options
[ ] change the default glob based on that
[ ] change the default project creation result to at least output the key so the user can change it easily
[ ] change the activation mechanism to activate on .js files as well

My BIG concerns are:

not fighting with other packages that also work on .js files e.g. tern
slowing down atom for JS files as atom-typescript is a bit bulky (mostly because that hasn't been my focus, TS projects tend to not be as messy as JS files).

Let me sit on it :-/ I am open for other ideas.

+1

+1

+1

not fighting with other packages that also work on .js files e.g. tern

Tern's hints are OK, but the UI is awkward compared to this plugin. There's a lot of overlap. My plan as a user was to remove tern and replace with atom-typescript.
I think we could simply document that users should disable tern if they want to use atom-typescript on JavaScript files.

It is now up for grabs. Also this project needs a new hero : https://github.com/TypeStrong/atom-typescript/issues/980 :rose:


show repo sync progress while lium sync

Not showing progress on lium sync is not user friendly. display some progress to make it clear that it is not stuck but it is in progress...

https://docs.rs/indicatif/latest/indicatif/ might help with that, along with https://crates.io/crates/tracing-indicatif to integrate it with the logging work in #88

repo sync already outputs a percentage and overwrites it's line using console control characters, so all we need to do is read the std out of the process, cut out the percentage (using regex or simple string splitting) and turn that into an int as an input for indicatif.
Then integrate indacatif with the tracing system with the tracing-indicatif crate.

Now it is implemented by @4n12i so closing this as Fixed. Thank you!


Simple AVR support

This adds support for the AVR target to Swift. It is a preliminary draft PR for discussion.
@rauhul @phausler @kubamracek
Note: names like "Embedded" I created many years ago, when it was only us using this code. This would probably not make sense now, but it gives you ideas of what we have been using and is a kick off point for discussion.
(See also https://github.com/swiftlang/swift/pull/74817)

Would AVR need its own platform name or would the architecture conditional suffice? Embedded Swift is usually platform-agnostic (if we managed to compile a tiny Linux kernel for AVR, we would write Swift for this OS via #if os(Linux) && arch(avr))

Would AVR need its own platform name or would the architecture conditional suffice? Embedded Swift is usually platform-agnostic (if we managed to compile a tiny Linux kernel for AVR, we would write Swift for this OS via #if os(Linux) && arch(avr))

It should not, the standard conditionals should suffice. I think when building for these targets we will use one or more triple from the following set: avr-{unknown, apple, atmel, swift}-none-{elf, macho?}.
The vendor part will be interesting to figure out.

@rauhul @harlanhaskins ... they sound like good ideas.

Would AVR need its own platform name or would the architecture conditional suffice? Embedded Swift is usually platform-agnostic (if we managed to compile a tiny Linux kernel for AVR, we would write Swift for this OS via #if os(Linux) && arch(avr))

It should not, the standard conditionals should suffice. I think when building for these targets we will use one or more triple from the following set: avr-{unknown, apple, atmel, swift}-none-{elf, macho?}.
The vendor part will be interesting to figure out.

To be honest, when I made these changes, I was partly copying other people's PRs where they were adding architectures. All I really wanted was to be able to add -target avr ...  to the swiftc command line and have it work, i.e. still compile at least as far as bitcode, passing the target triple down to llvm.  I think the llvm back end probably pretty much ignores everything after the architecture, because it's not relevant on that architecture, you're always building bare metal.
I'd be completely happy with avr-none-none or avr-unknown-unknown as target triples. What do you guys think are the minimal changes to get that to work? I can strip out everything else.

I think all you really need is to make sure the compiler recognizes AVR as an architecture, and that AVR implies 16 bit. Then you just need to tell the embedded seam routines to build a swift standard library for 16 bit AVR, and then clients will just be able to compile for AVR, import the standard library, and manually link/search for Arduino headers

If we did want specific support for Arduino as a named platform, along with searching for those headers and writing an overlay, for example, that could be done. I suspect that should be done outside of this PR though, and I'm curious if @rauhul has more opinions on how to do that.

I think all you really need is to make sure the compiler recognizes AVR as an architecture, and that AVR implies 16 bit. Then you just need to tell the embedded seam routines to build a swift standard library for 16 bit AVR, and then clients will just be able to compile for AVR, import the standard library, and manually link/search for Arduino headers

Actually we are quite separate from the Arduino platform. Most code written for our platform doesn’t use Arduino headers or libraries at all. We frequently use avr libc which is a much older and more widely used set of libraries. But again it’s really optional. A lot of us are writing pure Swift code with our own pure Swift hardware libraries. The only thing that might be needed to build valid binaries are some custom linker scripts. But that’s only if we want to go as far as having Swift do the full link. For now I think a great first step would be just compiling object files. In fact probably just getting to the Bitcode stage would be enough. In our tooling we use Swift to compile to Bitcode and then let other tools take over from there.

I suggest we define a first goal to just accept AVR as a target CPU in the compiler and be able to start the compilation. For that we will need some parts of this PR, plus some more (hopefully trivial) changes. I think we should drop from this PR everything that's not the minimal set of changes to get there. (Or open a new PR and leave this as a reference.)
Specifically, I think we'll need:

SwiftSetIfArchBitness.cmake change from this PR
SupportedConditionalCompilationArches change in LangOptions.cp from this PR
Enabling the AVR LLVM target in standard LLVM builds for Swift in build-presets.ini (look for llvm-targets-to-build)
A lit test that compiles something trivial in -parse-stdlib mode for AVR.
Optionally, if this this ends up needing a lot more work then let's make that a separate follow PR:

Enabling the build of the embedded stdlib for AVR in stdlib/public/CMakeLists.txt + a lit test compiling in non -parse-stdlib mode

I'm a little bit guessing with build-presets.ini as it's a bit opaque to me. Feel free to tweak anything. I didn't have time to write tests yet as it's after midnight and I have to get up for work tomorrow. I'll try to pick it up again tomorrow or Thursday.

@swift-ci please smoke test

Actually, we'll also need to fix the default set of llvm-targets-to-build in utils/build_swift/build_swift/driver_arguments.py.

I'd appreciate some help/advice how to fix the broken test? https://ci.swift.org/job/swift-PR-macos-smoke-test/14213/consoleFull#-1588501433d6fdb6cb-f376-4f2e-8bce-d31c7304698b
It looks like it's not emitting the expected fixit and is instead suggesting avr as a possible fixit, which I think is not what we would like (I don't mind if swift suggests arm, or x86 or riscv or avr... so long as these more rare architectures are further down the list). Could someone suggest how I might fix this please?

I'd appreciate some help/advice how to fix the broken test? https://ci.swift.org/job/swift-PR-macos-smoke-test/14213/consoleFull#-1588501433d6fdb6cb-f376-4f2e-8bce-d31c7304698b
It looks like it's not emitting the expected fixit and is instead suggesting avr as a possible fixit, which I think is not what we would like (I don't mind if swift suggests arm, or x86 or riscv or avr... so long as these more rare architectures are further down the list). Could someone suggest how I might fix this please?

It's an interesting question, I'm not sure what architecture the fixit should suggest. It appears to suggest bad options in either case (arm or avr) and it seems like suggesting an arch based Levenshtein distance would be a much better UX.
@DougGregor do you happen to have opinions on behavior of the target conditional fixits with the addition of the AVR architecture? For reference the lit errors are below:
/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/swift/test/Parse/ConditionalCompilation/basicParseErrors.swift:90:10: error: unexpected note produced: did you mean 'avr'?
#if arch(leg) // expected-warning {{unknown architecture for build configuration 'arch'}} expected-note{{did you mean 'arm'?}} {{10-13=arm}}
         ^
/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/swift/test/Parse/ConditionalCompilation/basicParseErrors.swift:126:11: error: unexpected note produced: did you mean 'avr'?
#if !arch(tecture) && !os(ystem) && !_endian(ness)
          ^
/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/swift/test/Parse/ConditionalCompilation/basicParseErrors.swift:144:4: error: expected note not produced
// expected-note@-5 {{did you mean 'arm'?}} {{26-29=arm}}
~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/swift/test/Parse/ConditionalCompilation/basicParseErrors.swift:145:23: error: incorrect message found
// expected-note@-6 {{did you mean 'i386'?}} {{26-29=i386}}
                      ^~~~~~~~~~~~~~~~~~~~
                      did you mean 'avr'?

It's an interesting question, I'm not sure what architecture the fixit should suggest. It appears to suggest bad options in either case (arm or avr) and it seems like suggesting an arch based Levenshtein distance would be a much better UX.
@DougGregor do you happen to have opinions on behavior of the target conditional fixits with the addition of the AVR architecture? For reference the lit errors are below:

It is using Levenshtein distance. I think the test here is unfortunate and the easiest thing to fix. The edit distance between leg and arm is 3, as it is with avr, which is why we're seeing the test failure here.
I recommend updating the test to be more realistic: replace leg with arn, which has an edit distance of 1 and is therefore more robust against adding new architectures.

It's an interesting question, I'm not sure what architecture the fixit should suggest. It appears to suggest bad options in either case (arm or avr) and it seems like suggesting an arch based Levenshtein distance would be a much better UX.
@DougGregor do you happen to have opinions on behavior of the target conditional fixits with the addition of the AVR architecture? For reference the lit errors are below:

It is using Levenshtein distance. I think the test here is unfortunate and the easiest thing to fix. The edit distance between leg and arm is 3, as it is with avr, which is why we're seeing the test failure here.
I recommend updating the test to be more realistic: replace leg with arn, which has an edit distance of 1 and is therefore more robust against adding new architectures.

Serves me right for not reading the implementation before typing, thanks for the correction! I think updating the test with arn is a really good idea.

@swift-ci please smoke test

Yes. When I’m trying to avoid register tearing things like that I suppress interrupts and re-enable them after. It’s all very basic. They are very simple processors!If it’s best to remove this from the PR then I’m happy to. Whatever is best?On 3 Jul 2024, at 18:06, Rauhul Varma @.***> wrote:
@rauhul commented on this pull request.
In lib/Basic/LangOptions.cpp:

@@ -391,6 +392,10 @@ void LangOptions::setHasAtomicBitWidth(llvm::Triple triple) {
setMaxAtomicBitWidth(128);
break;

case llvm::Triple::ArchType::avr:
setMaxAtomicBitWidth(0);

if I recall correctly there are no atomic instructions, but you can mask interrupts do some ops and unmask
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Sounds like a good idea. CheersOn 3 Jul 2024, at 17:35, Doug Gregor @.***> wrote:
It's an interesting question, I'm not sure what architecture the fixit should suggest. It appears to suggest bad options in either case (arm or avr) and it seems like suggesting an arch based Levenshtein distance would be a much better UX.
@DougGregor do you happen to have opinions on behavior of the target conditional fixits with the addition of the AVR architecture? For reference the lit errors are below:
It is using Levenshtein distance. I think the test here is unfortunate and the easiest thing to fix. The edit distance between leg and arm is 3, as it is with avr, which is why we're seeing the test failure here.
I recommend updating the test to be more realistic: replace leg with arn, which has an edit distance of 1 and is therefore more robust against adding new architectures.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

It’s more of a todo.But you have to be pretty careful on AVR.  The back end handles some things for you. For example in some cases when you read or change a 16 bit register you must read and write the bytes in a specific order to avoid the possibility of tearing if interrupts are enabled.But I think you don’t normally get CAS instructions on most AVR chips, that kind of thing. I think.I wonder if llvm atomic instructions may not lower to anything meaningful.I’m happy to either remove this change and see if it causes trouble (we can always easily add it later). Or if you guys prefer I can check through the tablegen etc to get a definitive answer what atomic IR ops do?On 3 Jul 2024, at 17:43, Kuba (Brecka) Mracek @.***> wrote:
@kubamracek commented on this pull request.
In lib/Basic/LangOptions.cpp:

@@ -391,6 +392,10 @@ void LangOptions::setHasAtomicBitWidth(llvm::Triple triple) {
setMaxAtomicBitWidth(128);
break;

case llvm::Triple::ArchType::avr:
setMaxAtomicBitWidth(0);

Is this a "TODO, deal with this later" or is there really no atomics on AVR? Any details about this?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

@swift-ci please smoke test

@rauhul @kubamracek  I think I fixed the broken unit test, at least it works locally, I also added a very basic parse test that should check the architecture exists and a couple of basic features, modelled on wasm. And suggested a tiny documentation tweak. I hope this is useful.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test Linux

All tests passed do you want to review it now?

Other than the small note, this looks good to me to go in. If you don't mind, could you wait with merging until let's say Tuesday to see if there's any more review comments from others (it's a Friday after a holiday in the US)?

Oh and one more thing: Because we went back and forth on some of the changes, I'd suggest squashing the commits before merging and also expanding on the commit message to make it more clear that this isn't actually yet a meaningful AVR support, but just the first step towards it.

Sounds like a good idea. Also the squash and clarify that this is a first basic step. On 5 Jul 2024, at 22:28, Kuba (Brecka) Mracek @.***> wrote:
Other than the small note, this looks good to me to go in. If you don't mind, could you wait with merging until let's say Tuesday to see if there's any more review comments from others (it's a Friday after a holiday in the US)?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Ok. I’ll take a look. I must admit I’m not strong on cmake!On 5 Jul 2024, at 22:25, Kuba (Brecka) Mracek @.***> wrote:
@kubamracek commented on this pull request.
In cmake/modules/SwiftSetIfArchBitness.cmake:

@@ -6,7 +6,9 @@ function(set_if_arch_bitness var_name)
"" # multi-value args
${ARGN})

if("${SIA_ARCH}" STREQUAL "i386" OR

if("${SIA_ARCH}" STREQUAL "avr")

 set("${var_name}" "${SIA_CASE_16_BIT}" PARENT_SCOPE)

This probably also needs an extension on line 5, otherwise I think it's not doing anything?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

OK @kubamracek. I think I've addressed all your concerns. This seems like a good first PR now.

@swift-ci please test

Hi @kubamracek @rauhul should we tag anyone else who needs to review this? p.s. I don't think I have permission to merge it anyway, so someone else will have to do that when it's time.

Let's go ahead and merge this. Thank you @carlos4242!

🎉


Part 4 - something not right

Hi!
Just a heads up. There is passage in part 4 when talking about flake8-annotations:

Configure Flake8 to switch on the warnings generated by the plugin (TYP like type):
.flake8
[flake8]
select = ANN,B,B9,BLK,C,E,F,I,S,W

But the warning prefix for the plugin is ANN not TYP.
Congratulations and thanks again for the amazing work. Hope to read more from you in the future!

Hi @staticdev , thank you for the feedback, appreciated :)
flake8-annotations changed their prefix from TYP to ANN in version 2.0.0, due to a collision with another flake8 plugin.
You should be able to fix this by upgrading flake8-annotations. BTW, as this is a new major release, this means you cannot simply use poetry update flake8-annotations. Instead, edit pyproject.toml or use the following command
poetry add --dev<EMAIL_ADDRESS>

You are right.. is it possible to edit the article in Medium to change TYP to ANN?
Another quick question about this part 4, you mentioned adding some libraries to mypy.ini to avoid import errors. But it wasn't clear to me when should we do that. You just add it to mypy.ini any new third party dependency? Is there a rule of thumb for that?

is it possible to edit the article in Medium to change TYP to ANN?

Yes. My plan is to thoroughly update the articles once the Cookiecutter for the article series is off the ground. I can't give you a date, but it should happen within the next 1-2 months.

Another quick question about this part 4, you mentioned adding some libraries to mypy.ini to avoid import errors. But it wasn't clear to me when should we do that. You just add it to mypy.ini any new third party dependency? Is there a rule of thumb for that?

Don't add them to mypy.ini unless mypy produces a warning about missing imports. You can see what the warnings look like by removing mypy.ini and running the mypy session.

is it possible to edit the article in Medium to change TYP to ANN?

Yes. My plan is to thoroughly update the articles once the Cookiecutter for the article series is off the ground. I can't give you a date, but it should happen within the next 1-2 months.

Another quick question about this part 4, you mentioned adding some libraries to mypy.ini to avoid import errors. But it wasn't clear to me when should we do that. You just add it to mypy.ini any new third party dependency? Is there a rule of thumb for that?

Don't add them to mypy.ini unless mypy produces a warning about missing imports. You can see what the warnings look like by removing mypy.ini and running the mypy session.

I am anxious to read your next articles =)
Why not just ignoring this warning for everything??
[mypy]

ignore_missing_imports = True

the strange fact to me is that mypy considers these third-party packages as "unresolved dependencies". And you are using poetry to get all dependencies resolved.

The option name ignore_missing_imports is slightly misleading. The packages can be imported, but mypy does not find type information for them.
Resolving the dependencies with Poetry (and installing them) only ensures that the package can be imported, but not that type information is available. That's still up to the package to provide.

@cjolowicz oddly, I tried to add django and django.* to a package of mine, but it keeps giving django errors with:
[mypy]

[nox.*,django,django.*]
ignore_missing_imports = True

And the errors stop with:
[mypy]

ignore_missing_imports = True

Any hints?

Hey @staticdev
The section name needs to be prefixed by mypy-. So in your example, the section needs to look like this:
[mypy-nox.*,django,django.*]
ignore_missing_imports = True

Perfect!! That fixed it =) Thanks again.

When I first read your articles I didn't know pyproject.toml formatting, and I had some trouble with it. And 100% based on your articles I did this CLI tool to validate TOML!
I had some trouble with e2e though. I had to mock TOML files, I don't think it is a correct approach for e2e.


Carousel image for dashbaord

Need help for UX expert here to prepare nice high resolution image to display on dashboard carousel.
Currently I have simple put-up blank image with text. This will be target area. Any better suggestion are welcome!

I am available and can offer help to design a few images.

@prafullmaru Please verify these images

Images looks fine. However background color is not matching with primary theme color - #7C84EC.
Update text and let you raise pull request.

Addressed by PR - https://github.com/prafullmaru/ePanchayat/pull/27


win is no longer a TabbyWin table

Not sure the best way to describe this, but I upgraded from a old-ish version and went to start vim and digging through the source code it seems like the tabs returned by line.tabs had a method on them called wins that returned a TabbyWin that had methods like is_changed and such, but it's just the window ids. Is this expected? In the documentation it says that tab.wins() returns tabby-wins, which I thought would be the win type

Thanks for your feedback; I fixed it in the master branch.
I wonder why my LuaLS does not warn me of the type mismatch!


Update README.md

Added the Interested Party list by adding my name!

@kumarankit999 do you want to update you affiliation, then we can review and merge the PR.
Or should we close it for now.
Please join our meetings, would be great to have more people supporting the TAG's work.

The "interested parties" portion of the charter is a legacy of the original formation of the tag and should actually be removed, rather than updated.
Will file a ticket.  In the meantime, we're going to close this PR.

Thanks @jberkus to letting me know this, I will try to be in the next meeting.


Align comments in  flutter_build_preview_sdk_test.dart with build.gradle.kts usage

update comments inside flutter_build_preview_sdk_test.dart to match the usage of build.gradle.kts instead of build.gradle
those must've slipped from #157195
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[x] I followed the breaking change policy and added Data Driven Fixes where supported.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Test-exempt: Code comments only.


Validator Profile

As a user
I want to be able to see details for validators
so that I can make sophisticated decisions on delegating my atoms.
AC (profile shows):

[x] Validator Name
[x] Validator Website
[x] Validator Description (this can hold links to external ressources like an audit)
[x] atoms self-bonded
[x] atoms delegated to them
[x] commission rate
-https://github.com/cosmos/gaia/blob/proposals/spec.md#fee-pool-commission
[x] how long they have been validator
[x] max commission rate (the rate that it will never go higher than)
[x] max commission increase rate (the max amount it can increase over time)

Current state:

I assume shares equal "atoms delegated to them"? This isn't very clear to me.

@faboweb that's a good point. i'd like to see more tooltips available with small definitions / descriptions. there is a lot of vocabulary that can be overwhelming / difficult to understand.

some things missing from the screenshot include ...

max commission rate (the rate that it will never go higher than)
max commission increase rate (the max amount it can increase over time)

@rigelrozanski is it possible to display the denomination of the fee shares?

next release will include moniker for validators.
let's make sure we include this field in the UI :)

@jolesbi who sets the max commission rate and max commission increase rate? And can the validator make changes to their profile? If they can make changes--for example, fix a typo on their description or website url--what prevents them from changing their max commission rate and increase rate?

We have another Validator Profile page on the Network Monitor section of the app.

How can we reconcile the differences between the two pages?

The reason there are two Validator Profile pages is an interesting historical footnote. About three months ago, we were focused on releasing a portion of the Cosmos UI called the "Delegation Game" . Along with the UI we would release the gaia network which would have included staking functionality. The Delegation Game had limited functionality - you could not send or receive Atoms. You could only view a list of validator candidates and then delegate your Atoms to them. Fast forward to November, we still don't have the UI out yet, and gaia is only getting its staking functionality now.
From my current understanding (@mappum correct me if I'm wrong), we are no longer having a Delegation Game before mainnet release. That means we no longer need any references to Validator Candidates throughout the app. There will be validators and delegators. To be a validator, you simply need to learn how to use the CLI to submit your details to the network. You no longer need to hold atoms to be a validator. Atom holders who use Cosmos UI can choose to delegate to zero or more validators.
What does this mean for our two Validator Profile pages? Without the concept of Candidates, both of the Validator Profile pages are going to be near identical. And since the Network Monitor Validators page has no functionality other than displaying information, we should delete these pages.

woah. very interesting.
max rate and max increase rate are set by validators. they are basically the terms that a delegator would be interested in knowing. i believe that these two data points cannot be changed by any means. if a validator wants to change these terms they basically need to create a new validator profile.
my understanding is that we don’t want validators to rely too heavily on the UI but I think it would be nice for validators to be able to edit their profiles in the UI.
i’m not sure so we’ll need confirmation on this but i don’t think we doing the delegation game anymore - but validators do in fact have at least one have atom to become a validator.
re: two validator pages. we should have one that contains all the info from both.
would be good for@mappum on this.
candidates are definitely still a thing but my understanding is that they are validators who aren’t in the top 100 yet.

That's right, there still is a distinction between validators and candidates, and the validators are just the top 100 candidates with the most Atoms bonded.

re: two validator pages. we should have one that contains all the info from both. ideally, all links to the validator profile page would go to the same profile component / page.

That sounds like it makes the most sense, candidates who are not validators should just not have certain fields on their profile like Earn Rate, Voting Power, etc., but should still have a Website, etc. Probably makes sense to have a field that explicitly explains their standing ("This candidate is a validator").

@jolesbi

max rate and max increase rate are set by validators. they are basically the terms that a delegator would be interested in knowing. i believe that these two data points cannot be changed by any means. if a validator wants to change these terms they basically need to create a new validator profile, so i guess we should display these fields but they need to be disabled.

Partially correct, the validator can choose to further restrict their terms, but not the opposite. They must re-create their candidacy if they want more lax terms.

my understanding is that we don’t want validators to rely too heavily on the UI but I think it would be nice for validators to be able to edit their profiles. i would also understand why we would want this to be readonly. what do you think from a ux perspective @nylira ?

Validators do not need a UI they can use the CLI - shouldn't focus on this I don't think - more to maintain.

i’m not sure so we’ll need confirmation on this but — i don’t think we doing the delegation game anymore — but validators still need to have at least one atom to become a validator. having one atom is enough to receive tokens from delegators.

Every validator needs > 0 atoms (a fraction of an atom is okay)

candidates are definitely still a thing but my understanding is that they are validators who aren’t in the top 100 yet. also, validators / candidate validators are a dynamic thing. sometimes validators will fluctuate between being validators and being candidates based on where they rank in the list of 100. @rigelrozanski should confirm the above info.

correct

should we close this ticket?

Yeah, let's close it. When we have more issues with the profile we'll open a new one.

Does the validator profile actually show real data? If not I would either reopen this ticket, unchecking all the AC that do not show real data or create a new ticket that handle all the real data. @jolesbi @nylira

I'll make a new ticket for this. Good point @faboweb

Thx Peng


node.js compatibility

Hi,
Would you consider making this library compatible with node.js?
Happy to send a pull request if you are interested.

:+1

Hey,
Sure, you can send me a PR, I'll take a look


Improve support of case classes’ fields with default values

Fixes #635 (see description in the issue)

lgtm

This is a great change, but in case you weren't already aware: this will break backwards compatibility for classes like
case class Foo(a: Option[Int] = None)

genericJsonRecord[Foo] // no longer derives an instance - you must remove `= None`

I prefer the new derivation (most of the Option fields we had were anyways to work around this missing feature), and gladly pay the breakage price.

Thanks, I didn’t know this would break things like that.
We might be able to special case the derivation process to skip optional fields with a default value (so, only fields with a default value whose type is not Option would be handled by the derivation mechanism). But this would make the derivation process more complex at the same time, so I prefer if we don’t support optional fields with a default value (like now).


Fix bg image

The background image was not displaying on the screen so, I have
merged the two css styles.
Below you can see the updated param1.css file:

Good job.👍

Thanks.


Milkdown shortcuts conflict with built-in keybindings.

For example, Ctrl+B conflicts with "open sidebar":

Ctrl+Shift+B conflicts with "build task"

Maybe we can register keybinding commands to avoid that?

Sure, I'll optimize it.

Fixed in new version.


Is there any way to block messages from a particular user

I have integrated the mailboxer gem in our nascent app.  Now I am thinking of the inevitable abuse cases we are likely to see and wondering if there is any kind of friending or permissioning that is built into mailboxer functionality that will allow a user to decide which other users can or cannot send messages to his or her account.

hmm

I am also looking for this...

Seems like this would be done outside the Mailboxer gem through an association.

I ended up building this outside of Mailboxer. Created a table to maintain a roster of blocked sender/receiver pairs and then added a helper method i.e filtered_messages_for(participant) in Mailboxer::Conversation to retrieve messages from everyone that isn't blocked by the participant.