HOTT-2829 Use depth for number_indents if available

Jira link
HOTT-2829
What?
I have added/removed/altered:

[x] Avoid fetch indents records if we already know depth

Why?
I am doing this because:

It will potentially avoid N+1s
If we've got depth, we can derive indent level from that without fetching data

Deployment risks (optional)

Low, behind feature flag

Think this might need a rebase/has become a bit more than the tweak to indent fetching?

There's better approaches to this so closing and will create alternative PR


Support Outbox folder

Feature request. When trying to send an email locally, and it fails for some reason, Apple Mail has an option to try again later, where it saves the message in the "Outbox" folder.
Then, when launching Mail later on, it sees if there's any pending messages there and, if there's no more SMTP errors, it automatically sends the messages.
If I log in Rainloop later on, instead, that folder is not present, so it can't send the pending messages automatically.

Hi @megadr01d
Do you want that Rainloop does the same thing that Mail does when a message can not be sent ?
Or do you want to see the "Outbox" folder with Rainloop ? If this folder is local in Mail, it is normal that Rainloop can no show this folder. Rainloop can only display the folders stored in the imap server.
Rainloop can show/hide folders. So you have the check this in the Settings > Folders

Thanks for the reply, @Philippe34.
I wanted Rainloop to just see the "Outbox" folder, not implement the same thing that Mail does.
However, you made me realize that the "Outbox" folder might be a local folder created by Mail, so it's normal that it doesn't show up in Rainloop. I thought the "Outbox" folder was a default IMAP folder that was only used when needed.


otpclient: 2.5.1 -> 3.1.4

Description of changes

make auto-lock and secret service mutually exclusive
fix importing plain AEGIS
fix importing encrypted AEGIS on some distros
rename disable_secret_service setting to use_secret_service

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Please rename the commit according to CONTRIBUTING.md, thanks!

done, thanks!


[SPARK-27439][SQL] Explainging Dataset should show correct resolved plans

What changes were proposed in this pull request?
Because a temporary view is resolved during analysis when we create a dataset, the content of the view is determined when the dataset is created, not when it is evaluated. Now the explain result of a dataset is not correctly consistent with the collected result of it, because we use pre-analyzed logical plan of the dataset in explain command. The explain command will analyzed the logical plan passed in. So if a view is changed after the dataset was created, the plans shown by explain command aren't the same with the plan of the dataset.
scala> spark.range(10).createOrReplaceTempView("test")
scala> spark.range(5).createOrReplaceTempView("test2")
scala> spark.sql("select * from test").createOrReplaceTempView("tmp001")
scala> val df = spark.sql("select * from tmp001")
scala> spark.sql("select * from test2").createOrReplaceTempView("tmp001")
scala> df.show
+---+
| id|
+---+
|  0|
|  1|
|  2|
|  3|
|  4|
|  5|
|  6|
|  7|
|  8|
|  9|
+---+
scala> df.explain(true)

Before:
== Parsed Logical Plan ==
'Project [*]
+- 'UnresolvedRelation `tmp001`

== Analyzed Logical Plan ==
id: bigint
Project [id#2L]
+- SubqueryAlias `tmp001`
   +- Project [id#2L]
      +- SubqueryAlias `test2`
         +- Range (0, 5, step=1, splits=Some(12))

== Optimized Logical Plan ==
Range (0, 5, step=1, splits=Some(12))

== Physical Plan ==
*(1) Range (0, 5, step=1, splits=12)

After:
== Parsed Logical Plan ==
'Project [*]
+- 'UnresolvedRelation `tmp001`

== Analyzed Logical Plan ==
id: bigint
Project [id#0L]
+- SubqueryAlias `tmp001`
   +- Project [id#0L]
      +- SubqueryAlias `test`
         +- Range (0, 10, step=1, splits=Some(12))

== Optimized Logical Plan ==
Range (0, 10, step=1, splits=Some(12))

== Physical Plan ==
*(1) Range (0, 10, step=1, splits=12)

Previous PR to this issue has a regression when to explain an explain statement, like sql("explain select 1").explain(true). This new fix is following up with @hvanhovell's advice at https://github.com/apache/spark/pull/24464#issuecomment-494165538.

How was this patch tested?
Added test and manually test.

cc @dongjoon-hyun @gatorsmile @hvanhovell

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10845/
Test PASSed.

Test build #105591 has started for PR 24654 at commit 071bc12.

Test build #105591 has finished for PR 24654 at commit 071bc12.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/105591/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10872/
Test PASSed.

Test build #105621 has started for PR 24654 at commit 08a5836.

Test build #105621 has finished for PR 24654 at commit 08a5836.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/105621/
Test PASSed.

Thank you so much, @viirya , @cloud-fan , @hvanhovell , @gatorsmile .


xcode & code style

fixes for xCode9 beta 5
added swiftlint to check code style
fixed code style

Not looking to add a linter to the project right now, as I'd like to keep development frictionless for anyone who wishes to contribute, so I'm going to close this. Thanks for submitting the PR though!


chore: jsonfmt edgegateway

Ran jsonfmt -w "specification/edgegateway/**/*.json"

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Automation for azure-sdk-for-js

Automation for azure-sdk-for-go

Automation for azure-sdk-for-java

Fixed 2 minor example casing issues to get the Model validation to pass, so this isn't entirely cosmetic. I can rebase out the last 2 commits with these changes if preferred.

Can one of the admins verify this patch?


Server crashes when sending binary data to ws-text endpoint

I think we already had the same issue years ago in #538 and fixed it easily 🙂
What I did:

ran stock deepstreamio/deepstream.io:4.2.5-alpine docker container
used most recent client(client/latest/ds.min.js) to connect to the legacy ws-text endpoint ( deepstream('localhost:6021'))
get server crash

rawMessage.split is not a function
    at Object.exports.parse (/src/connection-endpoint/text/protocol/message-parser.ts:48:34)
    at WebSocket.websocket.on (/src/connection-endpoint/text/connection-endpoint.ts:71:44)
    at WebSocket.emit (events.js:198:13)
    at Receiver.receiverOnMessage (/node_modules/ws/lib/websocket.js:800:20)
    at Receiver.emit (events.js:198:13)
    at Receiver.dataMessage (/node_modules/ws/lib/receiver.js:413:14)
    at Receiver.getData (/node_modules/ws/lib/receiver.js:352:17)
    at Receiver.startLoop (/node_modules/ws/lib/receiver.js:138:22)
    at Receiver._write (/node_modules/ws/lib/receiver.js:74:10)
    at doWrite (_stream_writable.js:415:12)

hey!
Yeah so this is an issue since the text-protocol recieved a binary websocket. It should obviously not crash but it won't work either. You need to point it to the correct websocket url. I'll fix it so it provides a proper error when this happens. Thanks for raising!

Yes, I'm aware it's not supposed to work, but it shouldn't be possible for a potential bad actor to crash our server this easily 😬
I've seen you added this to the v5 milestone, does this mean we won't be getting a patch for v4? If the team has no time for this, I could try implementing a fix.

Yeah I won't be porting back changes to V4 (mainly because upgrading from V4 to V5 should be very painless)
But if you raise a PR against the V4 branch I'll merge it in and do a release!

Sorry, accidental close 🙈

One last thing sorry, could you also do the opposite check and see what happens when you connect a text websocket to the binary endpoint?


Uploading the same file

If you upload a file more than once, it overwrites what is currently there. Need to discuss the use cases with this. For example, perhaps someone would like to have both versions?

Voted - just add a number to the file name and upload it along with original file.


Add file owner/group/mode support

Expose owner/group/mode permission support for the downloaded file.

Added functionality in https://github.com/awslabs/awscli-cookbook/commit/d39ceb643d77eb7bfb2f5d2165a339bc3434d17e


ModuleNotFoundError: No module named 'cv2'

The module does not seem to be present: ModuleNotFoundError: No module named 'cv2'

Hello,
If you want to play, and you are missing libraries, try
pip install -r requrirements.txt
If this doesn't work, try to install the latest libraries, each library is specified in the requirements.txt file.
I think Unrailed has changed the icons of the recent tools, you replace them here :

https://github.com/Flowtter/unrailed-ai/blob/master/src/template_axe.png
https://github.com/Flowtter/unrailed-ai/blob/master/src/template_pickaxe.png

The file is not present when ordering #


Feature: GUI login using certificate

SSH can be restricted to prevent password login (default). Since the WebUI is considered the main entry point for configuration, what about implementating HTTP authentication using X.509 certificates?

Client certification authentication got really (unnecessary) complicated with current Chrome. The user need to manually reconfigure the certificate to be able to use it for authentication... :( Not really user friendly in my opinion.
Regarding the OPNsense implementation I have two basic designs in my head:

The certificate is stored with the other certificates in the certificate store and can be assigned to each user like IPsec certificates
A Base64 encoded string of a X.509 certificate can be paste into the user's configuration similar like SSH public key authentication

I think both solutions have advantages and disadvantages. I personally vote for 1, since then all certificates are in one place and also certificate creation can be implemented easily (or already exists partially).
Any Recommendations?

@8191 I know how this works and you cannot use any certificate here.

Yes, typically you use a CA and let the webserver verify the certification path, but you also could realize it programmatically, e.g. let PHP verify the certificate.
But yes, option 3 arises... ;-)

cross-reference https://github.com/opnsense/core/issues/615

timeout and lack of ressources, other construction sites have priority


Examined material section formatted to the journal style.

As a user, I would like to be able to download list of studied specimens in a format accepted by the journal. At least Zootaxa and ZooKeys should be supported.
As an example of the tool, we can look at http://phorid.net/automatex/index.php
The web site offers a scv template as a download.

Dulicate of https://github.com/SpeciesFileGroup/taxonworks/issues/2325.


404 errors in the Docker Hub page

Hello, this article has a link to Docker Hub, where the images can be found: https://hub.docker.com/_/microsoft-azure-functions-base
This page, has then links to the different Docker files, but are incorrect (and therefore returns a 404 error). For example, this text "The Dockerfile can be found here." has a link to https://github.com/Azure/azure-functions-docker/blob/master/host/2.0/stretch/amd64/base.Dockerfile, that returns 404.
I guess some url has changed, because the images can be found on github: https://github.com/Azure/azure-functions-docker

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

ID: 5d505ab9-d351-6650-6d0c-bb65d2daa229
Version Independent ID: 2a1d3487-a93d-2206-7ef9-a91aa275ec4e
Content: Create Azure Functions on Linux using a custom image
Content Source: articles/azure-functions/functions-create-function-linux-custom-image.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

Hi @dhdiez Thanks for your feedback. We will review and update as appropriate.

@dhdiez I have assigned this to content author for further review and update as appropriate.


Proofread

No substantive changes. Standardized, reworded some awkward verbs.

View rendered CHANGELOG.md
View rendered CONTRIBUTING.md
View rendered CREDITS.md
View rendered PRINTING.md
View rendered README.md
View rendered RELEASING.md

@ElenaFdR thanks for all the proofreading here. You caught lots of little things that slipped past us. Most of it we want to merge-in, but not all. Would you like @Ainali and I take it from here? Or do you want to keep hacking on it?

I was thinking that this is respecting the Creative Commons attribution as good as we can. They have titled their works in a way, and we just repeat that. Sure, for these it may not have been intentional by the author, but if it was something like "iPhone" the author clearly had a thought behind it.

I think we can find a way to show that the titles used verbatim, perhaps using italics or quotes or even saying so explicitly.
We'll modify this PR and merge it.


Redundant Language Settings Issue in Enatega Multivendor Rider App for iOS

Summary:
The Enatega Multivendor Rider App for iOS currently includes its own language settings, which are redundant given that iOS devices already have default language settings.
Steps to Reproduce:
Install the Enatega Multivendor Rider App on an iOS device.
Observe that the app initially relies on the default language settings of the iOS device.
Navigate to the language settings within the Enatega Multivendor Rider App.
Change the language settings within the app to a language different from the default language of the iOS device.
Close and reopen the app.
Notice that the app now has conflicting language settings, resulting in a redundant language interface.
Expected Behavior:
The Enatega Multivendor Rider App should seamlessly integrate with the default language settings of iOS devices. Users should not need to configure language settings within the app separately.
Actual Behavior:
The app has redundant language settings, causing confusion for users. The language settings within the app conflict with the default language settings on iOS devices, introducing unnecessary complexity.
https://github.com/Ninjas-Code-official/Enatega-Multi-Vendor-Food-Delivery-System/assets/152266796/bc9f59c2-5c79-46d6-add2-40a8e0c0ca87

Resolved!

waiting for publish

Resolved!

waiting for publish


ILSVRC2015 VID dataset download link is dead

Can anyone download the ilsvrc2015 VID dataset?
http://bvisionweb1.cs.unc.edu/ilsvrc2015/ILSVRC2015_VID.tar.gz
http://image-net.org/challenges/LSVRC/2015/index
The links are dead.

Have you found a way to get the dataset in the meantime?

Hi, can you tell me how you download ImageNet VID dataset? Their own site and http://bvisionweb1.cs.unc.edu/ILSVRC2017/download-videos-1p39.php for 2015, 2016 and 2017 doesn't work. Can you help me and suggest a way to solve this problem?

https://www.kaggle.com/competitions/imagenet-object-localization-challenge/data


We couldn't find any matches - Company Communicator (Authors)

I've created 5 Test Teams (DO1.0 to DO5.0) but I am only able to search for DO1.0.
I've added the necessary API permissions for both CC (User) app and CC (Author) app but I am still unable to search for other test teams (i.e. DO2.0 - DO5.0). Please advise!

The Team(s) you are trying to target need the Communicator App installed.  After adding the User app, those teams should show in dropdown

i have uploaded the user app to the app catalog and manually added the user app to each test team but i was still unable to search for other test teams.
i was only successful after i logged into my teams admin center to manually add each test team into the communicator app (user).
my question is, why wasnt the user app proactively installed for the users? Do I have to logged into my team admin center to add a new test team in order for it to appear in my search?

During my research on this app, I came upon this clip https://www.youtube.com/watch?v=_dzu8HEu1AU posted in Feb 2021, which shows that it is now possible to schedule sending of messages and the message metrics of the App now extends beyond delivery status to include users' replies and reactions.
Can we confirm on the above please? @juna-gupta

@jcwl2021 This is not part of the company communicator app template. It is a customization you will have to develop on top of the available code base

Check out this this fork https://github.com/cristianoag/microsoft-teams-apps-company-communicator/wiki
Is not the official build but should be incorporated (IMHO).  Has scheduled send and image upload.  Shout out to @cristinoag


[bug report][4090 attn] cudaCheckError(): too many resources requested for launch

Dear Developers,
When I execute the attn using the GPU 4090 with default parameters, I encounter the issue "too many resources requested for launch."

I have discovered that the "Registers per block" for the 4090 machine is 65,536, and each thread uses 162 registers. This results in a BLOCK_SIZE that cannot exceed 65,536 / 162 ≈ 404.

Have any of you faced this issue, and do you have any solutions?

I ran into this as well. Thanks for writing this up, I would have had no idea how to debug this otherwise. I notice that harness.impl defines BLOCK_SIZE as 32 * NUM_WORKERS, which is defined in 4090_ker.cu as 16. I was able to compile and run the kernel after setting NUM_WORKERS to 8. I don't know whether floor(404/32) = 12 would be a better value, I figured I'd leave it as a power of 2 just in case that was important.
I also just ran this without a data file, just using whatever new gave me for k/q/v/o_ref, so maybe it would fail with real data?


Dev

Maybe you can just switch back to the last release version before "merging with master" (so that the documentation is available from "root", i.e. https://kwb-r.github.io/kwb.kuras.db/ instead of https://kwb-r.github.io/kwb.kuras.db/dev only)

This change is

@hsonne can co merge to master please?


Role-Based Access Control extension user login problem

Hello,
I recently purchased Role-Based Access Control extension for some fine grained access control restriction to my end points. When I tried to add more than 4 endpoint to my users(I am attaching helpdesk role), I am getting some errors(see the attachment). I am using internal authentication and if I turn this user to a global admin(without the usage of Role-Based Access Control extension), everything works fine.
Pls have a look at and let me know how to resolve this.

Hi there,
Are you using a reverse proxy in your environment?
Also FYI we are aware of 2 bugs currently affecting RBAC. Fixes for these will be released in the 1.22.1 image of Portainer in the coming week alongside fixes for some other bugs relating to RBAC, reverse proxies and authentication.
If you can, feel free to try out the image: portainerci/portainer:3213 as there is a chance that your issue has been fixed.

Hello
Thank you for the swift response but it is not the problem with the reverse proxy. I tried it without reverse proxy and issue persist. also I couldn't find the portainerci/portainer:3213 but instead I tried portainerci/portainer:pr3213. Is there any restriction set to 4 endpoint only for RBAC users?

My apologies, you have the right image.
Is the issue you are recieving present when running the portainerci/portainer:pr3213 image?
Also there should be no restriction on the number of endpoints for RBAC users..

FYI I was unable to reproduce this bug in my test environment with 6 endpoints, when running the image above..

My apologies, I after clearing all the cookies from the browser, I am able to use it without any problem. I am attaching my nginx conf below. Pls give me some insights.

cat /etc/nginx/nginx.conf
worker_processes  1;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
worker_connections  1024;
}
http {
include       /etc/nginx/mime.types;
default_type  application/octet-stream;
log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log  /var/log/nginx/access.log  main;
sendfile        on;
keepalive_timeout  300;
proxy_ignore_client_abort on;
client_body_buffer_size     25M;
client_max_body_size        25M;
proxy_connect_timeout       300;
proxy_send_timeout          300;
proxy_read_timeout          600;
send_timeout                300;
include /etc/nginx/conf.d/*.conf;
}

cat /etc/nginx/conf.d/portainer.conf
server {
listen       80;
server_name  xxxxxxxxxxxxxxxxxx
client_max_body_size 25M;
gzip on;
gzip_disable "msie6";
gzip_comp_level 6;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_proxied any;
gzip_types
text/plain
text/css
text/js
text/xml
text/javascript
application/javascript
application/x-javascript
application/json
application/xml
application/rss+xml
image/svg+xml;
location / {
sendfile off;
proxy_pass http://<IP_ADDRESS>:9000;
proxy_redirect     default;
proxy_http_version 1.1;
proxy_set_header   Host              $host;
proxy_set_header   X-Real-IP         $remote_addr;
proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Proto $scheme;
proxy_max_temp_file_size 0;
#this is the maximum upload size
client_max_body_size       10m;
client_body_buffer_size    128k;
  proxy_connect_timeout      90;
  proxy_send_timeout         90;
  proxy_read_timeout         90;
  proxy_buffering            off;
  proxy_request_buffering    off; # Required for HTTP CLI commands in Jenkins > 2.54
  proxy_set_header Connection ""; # Clear for keepalive
}

}

Have you tried this with the fix image I shared? This bug affects RBAC when used with reverse proxy and has been fixed, it is pending release in Portainer version 1.22.1
If you are unable to use that portainerci/portainer:pr3213 image, you can try some of the workarounds in the issue I linked for your nginx config to see if it helps you

Thank you. I will wait for the next bug free 1.22.1 release.

@rraisal are you still experiencing your issue?


Location search interactions

Spinning wheel is not working
Location does not get cleared when the next questions shows up

3 Paris, FR shows 3 times (I know there is the district, city, etc, but you could maybe show that or filter it out)


Feature request: Power consumption

Please add washer and dryer power consumption data to this library and to the Home Assistant integration.

Thank you for your feedback. We will review to add the feature and let you know if the feature is available.


connwarn - remote code execution

There is an issue with how parameters are passed to amqoampx that will allow remote code execution exploit for anyone that can connect to a Unix queue manager that has a SVRCONN channel configured with this exit.

Changes in PR #3 to rectify this.


Fix performance-test chart label typo

The littlest of nits, but it might save someone a little confusion.

 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.

@anko thanks!


[enkits] Fixing version 1.11 not properly configured to work as a dynamic library

I've been running with this patch for a while. Just getting around to trying to upstream it now.
Tweaking the patch for the install procedure and targeting a newer commit on top of v1.11 that greatly improves the install process.

[X] Changes comply with the maintainer guide.
[X] SHA512s are updated for each updated download.
[X] The "supports" clause reflects platforms that may be fixed by this new version.
[X] Any fixed CI baseline entries are removed from that file.
[X] Any patches that are no longer applied are deleted from the port's directory.
[X] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[X] Only one version is added to each modified port's versions file.

Usage test pass with following triplet:
x64-windows


Declarative macro_rules! derive macros

Many crates support deriving their traits with derive(Trait). Today, this
requires defining proc macros, in a separate crate, typically with several
additional dependencies adding substantial compilation time, and typically
guarded by a feature that users need to remember to enable.
However, many common cases of derives don't require any more power than an
ordinary macro_rules! macro. Supporting these common cases would allow many
crates to avoid defining proc macros, reduce dependencies and compilation time,
and provide these macros unconditionally without requiring the user to enable a
feature.
I've reviewed several existing proc-macro-based derives in the ecosystem, and
it appears that many would be able to use this feature to avoid needing proc
macros at all.
Rendered

Nominated as a follow-up to recent lang discussions about this.

Since its call-side syntax is different from normal macro_rules! (i.e. macroname!()), the definition-side syntax should also variants e.g. macro_rules_derive! (v.s. #[proc_macro_derive(TraitName)]).
The same to #3697 where we could name it macro_rules_attribute! (v.s. #[proc_macro_attribute]).

One thing that would be really nice (i.e. greatly increase usability of decl macros) (though would not at all decrease the usefulness of this feature) is proper, full-featured parsing of meta fragments of decl macros. Right now, if you want to parse arguments to a decl macro in a MetaList form, you have to either enforce that the named arguments come in a specific order, or use a tt-muncher (and even then, it's not clear at first thought how you'd do it!). Obviously this is something that would introduce a whole new axis of complexity to decl macro declarations and evaluation, but being able to specify something like $[$(foo = $foo:expr)? $(bar($bar:expr))*],* and accept 0 or 1 foos and 0 or more bars in any order would be a game changer, and I can't see using attr or derive decl macros being very ergonomic for anything but the simplest cases without something like that. This RFC lets you define helper attributes for decl derive macros, but without any easy way of extracting them from out of the set of other attributes on the item, I don't see that being very useful for most people. An accessible and intuitive macro definition format tt-munchers are not.

@coolreader18 I would love to see many parsing improvements for macros, including something to address this kind of parsing difficulty. I don't think that's specific to derive or attribute macros, though it certainly makes them more useful.

To define helper attributes, put an attributes key in the macro_derive attribute, with a comma-separated list of identifiers for helper attributes: #[macro_derive(attributes(helper))]. The derive macro can process the #[helper] attribute, along with any arguments to it, as part of the item the derive macro was applied to.

In order to avoid name collisions in helper attributes between different derives, I think it would be worth it to take a page out of serde here and require namespacing of those attributes.
For example, simple serde code:
#[derive(Debug, Deserialize)]
struct Message {
    #[serde(rename = "type")]
    type_: String,
    #[serde(default = "Message::default_payload")]
    payload: String,
}

Some names (like default) are likely to be particularly sought after, and mixing dependencies which clash on those helper names will be nightmarish.
Convention for the namespace could dictate that it be either a parent module/crate name, or the name of the trait, snake-cased.

I don't think that's a good idea. It's already the case that other libraries than serde look at serdes attributes, sometimes even in a context where the input type does not use serdes derives at the same time (but a proc-macro copies the serde attributes to some types it generates). As one example, the derive macro schemars::JsonSchema currently "registers" serde, schemars and validate, likely for good reason.

Perhaps some kind of pub annotation then? Yes, that would have made achieving the current state of Serde attribute cross-compatibility difficult, but it has been the Rust way to default to pushing back against [url=https://www.hyrumslaw.com/]Hyrum's law[/url].

There has also been talk of "common" attributes, like skip.
For clap, namespacing by crate or derive name was insufficient and it now processes 4 different namespaces.
If we did encourage something by default, i think it should be derive name so there is a clear relationship.
On a simlar note of constraining users, imo derives should only produce a trait impl for the derive and considered proposing that be enforced but figured that deviating for what proc-macros provide would also be a downside. Also, I've seen with clap how it can be useful to include mostly-internal trait impls with the requested one.

On a simlar note of constraining users, imo derives should only produce a trait impl for the derive

Note that imposing such restriction would make it difficult to write derives that implement traits like IntoIterator, where each implementation typically introduces a new type that must be nameable by the impl, until associated type position impl Trait is available.
I was recently exploring this space while working on exhaust 0.2, which needs to generate two types and several impls along with the nominally derived impl, and my current strategy for being nice to the macro’s users is that the derive macro’s generated items are all inside a const _: () = { ... } block; this ensures that the macro’s expansion has no effect on the caller’s namespace, even though more items than just a trait impl are generated. One could imagine inserting that block wrapper automatically as part of the semantics of derive macros (whether declarative or procedural), but that should probably be its own design discussion separate from introducing a new kind of macro implementation.

I don't think that's a good idea.

For clap, namespacing by crate or derive name was insufficient and it now processes 4 different namespaces.

I would note that I specifically mentioned "as a convention".
If anything, the fact that schemars also looks at serde namespace is a validation of the need for namespacing to me. Otherwise if there's a #[default = ...] it wouldn't even know whether that's for serialization/deserialization or some unrelated purpose.
I think enforcing namespacing and having a simple convention for simple usecases -- so folks can just follow along -- would work well. Perhaps a clippy lint which has to be explicitly #[expect] for the handful of usecases requiring more schemas.

There has also been talk of "common" attributes, like skip.

Common attributes are fine: a standardized meaning should not cause "mishaps".

I think there are many potential ways to solve the helper attribute collision problem. However, that's a problem that applies just as much to proc macro derives as to these declarative derives. I want this to be capable of being a drop in replacement for proc macro derives wherever possible.
So, given that, I think it should have the same capabilities. If in the future we introduce conventions or solutions for helper attribute namespacing or similar, that'll apply to both kinds of macros.
I'll add a note in the RFC to that effect.

A few people have mentioned generating where bounds. It would likely be the top worry for people implementing declarative derives.
We might want to provide a generate_where_bounds macro:
generate_where_bounds!(
    trait: MyTrait;
    params: T, U, V;
    fields: t: T, u: Option<U>, v: ActuallyLetsSkipV;
)

// would expand to

T: MyTrait, U: MyTrait, // we're skipping V as it's not included in fields

@PoignardAzur I've added an item to the future possibilities section about making it easier to derive where bounds.

Thanks for filling this RFC. I really like this proposal, as it can also solve some other issues around proc macro derives. That includes things like not having a $crate equivalent for proc macros which make it notoriously hard to couple a proc macro to a crate and issues around feature unification. Both would be solved by allowing to write such macros as declarative macros in the main crate, as you just don't have that separate crate to deal with then.
That written I would like to point to an in my opinion important detail. The RFC mentions as future possibility that:

We should provide a way for macro_rules! macros to provide better error reporting, with spans, rather than just pointing to the macro.

I think it's rather important to provide this functionality from the beginning. I believe that many of the more popular derive marcos wouldn't be interested in migrating to something that does regress their error messages significantly.

My concern with this RFC is that it will lead to a large number of hacky derive macros that don't support the full variety of Rust syntax. Writing a macro-rules that will handle anonymous fields, named fields, enums, attributes, (in the future) default values, etc feels pretty hard and likely to ultimately require tt-munging, which we don't really have the ability to abstract over.
I was hoping to see a somewhat more declarative approach where the compiler handled the parsing on your behalf, with syn and synstructure as the fallback case.

@weiznich My expectation is that we'll try it in nightly, experiment with it for various macros in the ecosystem, see how it goes (including what the errors look like), and figure out what we need before stabilization. If the error messages are wildly worse in common cases, I certainly think we'd want to address that before stabilization.

I was hoping to see a somewhat more declarative approach where the compiler handled the parsing on your behalf

I'd love to see that one day as well, but I think this is one step in that direction. We can start out (in nightly) with "this is possible at all", and then incrementally add mechanisms for macros to more easily extract things from syntax.
For instance (as one possible example, not meant to be normative), imagine adding a "struct field" matcher, and then extending the macro metavariable expressions mechanism to have a way to extract pieces of structure from a higher-level AST match (e.g. "field name" and "field type"). That would make simple cases really easy.

@joshtriplett Given that there are quite a few questions that were answered with: Let's land something on nightly first and then iterate from there, it's maybe a good idea to explicitly state that in the RFC itself by marking it as experimental RFC?

@joshtriplett Given that there are quite a few questions that were answered with: Let's land something on nightly first and then iterate from there, it's maybe a good idea to explicitly state that in the RFC itself by marking it as experimental RFC?

It's already stated in the RFC in the form of unresolved questions, which turn into checklist items in the tracking issue for subsequent evaluation. I've also explicitly captured the concern about crate maintainers getting pressure to use something that doesn't have all the features they want yet; that's a problem we can address with appropriate messaging, in addition to subsequent improvements.
The RFC aims to define a chunk of useful functionality that will be useful for some crates, without the expectation that every possible proc macro will immediately be a good idea to convert.

(Repeating from #3681 for the sake of transparency, though I expect the main discussion to happen there.)

Bound all the type parameters, which is most semver stable, like all the built-in derives do.

The built-in derives do more than that. If you write:
#[derive(Default)]
struct MyStruct<T: SomeTrait>
{
    t: T,
    ta: T::Assoc,
}

The generate derive will be:
impl<T: ::core::default::Default + SomeTrait> ::core::default::Default for MyStruct<T>
    where T::Assoc: ::core::default::Default
{
    // ...
}

The macro already needs to parse the fields to generate the T::Assoc: ::core::default::Default bound.
So even if we stuck to the "one bound per type parameter" approach, we would still likely want a generate_where_bounds macro.

The RFC aims to define a chunk of useful functionality that will be useful for some crates, without the expectation that every possible proc macro will immediately be a good idea to convert.

I'm honestly not sure if this will be really that useful for anyone without a lot of additional work. One advantage as the maintainer of an old crate like diesel is that I can look back in the past and see how things were back then in the "beginning". In this case: Diesel is older than stable proc-macro support, so I remember the ways how this was implemented back then before we had access to stable proc-macros. You can find the code here. Funnily the solution we used back then is very similar to what this RFC proposes, although it did not have the syntax sugar to be able to just write #[derive(MyMacro)]. There was the custom_derives crate back then, which essentially enabled the syntax proposed by this RFC, with the minor cavecat that you would need to put the struct definition into a macro call.
Niko pointed out that it really hard to parse all possible syntax variants of rust structs/types/enums in a declarative macro today. I fully agree with that. See the old code from simpler days for some estimation how complex that would be today with even more syntax variants. So having support from the compiler here seems the be necessary from my point of view. This becomes especially important if you think about what happens if the rust syntax is extended. The current approach would likely lead to quite a few such crates fail to accept the new syntax, as their macro parser cannot handle these new cases. That's not an issue with the syn based approach or if the compiler does the parsing and only invokes some sort of special macro syntax.
As another counter point diesel has a table! with relatively simple syntax that is fully under our control as crate authors. Even for that we decided to implement that parser as proc-macro, as the macro was quite complex and the error reporting was quite bad if something went wrong. (It essentially boiled down to: You macro is wrong, checkout the documentation for the correct syntax).
Now my main points are:

If this RFC is only for experimentation: It's already possible to do that on stable rust, you can just use the same approach as the old custom_derives approach
There is existing old code that essentially used this approach already. There are a lot of reasons why crates like diesel moved away from this approach. You likely find a few more examples for this by checking which other crates also used custom_derives

I've looked at the attached code, and I can understand that the full generality of the macro infrastructure that Diesel had is not something you want to have to maintain. From what I've seen in the ecosystem, many proc macro derives will not require that degree of complexity, and some will be able to switch over earlier than Diesel will want to. I've spelled out in the RFC the potential issue of pressure on crate maintainers, and included a stabilization-blocking requirement that we provide guidance for users and crate maintainers to attempt to avert that.
Beyond that, there's a long history of potential macro improvements stalling out because scope creep or because "wait until macros 2.0", rather than taking place incrementally. There is no one-way door here, so we can ship features incrementally without blocking on having everything users may want.

Beyond that, there's a long history of potential macro improvements stalling out because scope creep or because "wait until macros 2.0", rather than taking place incrementally. There is no one-way door here, so we can ship features incrementally without blocking on having everything users may want.

I'm not sure I agree with that. Yes not shipping any features because they are not 100% perfect is bad, sure. But on the other hand: Shipping features and promising to "fix" more complex cases later on is also bad, because quite often that fixing did not happen anytime soon. (Examples: Proc-macro diagnostics, various async limitations (traits, drop, …)) That leaves crate maintainers in a situation where there might be a considerable pressure to use a new feature but it is not possible to use it in an good.
I personally would wish that the RFC either clears up that this feature is supposed to be used in special situations (and declares which ones) or that it includes a more general approach to handle at least something rather simple like #[derive(Default)] (without #[default]) or #[derive(Clone)]. We hopefully all agree that these derives are not complex in terms of code parsing is done there. I personally do not see a way to express without at least a considerable amount of parsing code expressed as macro rules. That code wouldn't be a problem if it would be maintained as part of the compiler, but it becomes a problem as soon as each crate includes it's own likely incomplete and broken version.

Before stabilizing this feature, we should receive feedback from crate
maintainers, and potentially make further improvements to macro_rules to make
it easier to use for their use cases. This feature will provide motivation to
evaluate many new use cases that previously weren't written using
macro_rules, and we should consider quality-of-life improvements to better
support those use cases.

@ijackson I believe that derive-deftly approach is being addressed by #3714.

We had a @rust-lang/lang design meeting today on the set of macro RFCs. I've updated the RFC to incorporate all the feedback from that design meeting.
Per the feedback in that meeting, I'm starting an FCP to start letting people register consensus for this RFC.
@rfcbot merge


Fix bug in setindex!() - closes #48

Fixed the bug in setindex!() which was resulting in clearing the
coefficient of the highest order term in the polynomial.

Thanks. Can you add a test?

Sorry! I had already added one, but apparently I forgot to push.

Thanks again.


Full logout using Windows authentication

In our project, using the Windows Authentication module and IdentityServer3 when users logout, they still need to close the browser, else when clicking on the Windows button again, it does not re-prompt for a different user.
This is in a lab environment, were we are using a shared desktop/browser, not likely in production I know, but i'd still like to know if it is technically possible to fully logout from windows authentication by closing the connection somehow?
Thanks.

Integrated windows authentication means "use the user that you logged into the windows operating system with", right?

I guess. But most browsers prompt for user details and our QA team are entering different users. Is there nothing other than closing the browser that can end the session?

On 11 Jun 2016, at 16:18, Brock Allen<EMAIL_ADDRESS>wrote:
Integrated windows authentication means "use the user that you logged into the windows operating system with", right?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Once you've given the browser the responsibility of authenticating then it's hard to tell it to stop. For integrated windows auth, then the only real way to logout is to signout of the OS.


Generate New Secret Token

if I mistakenly expose my secret token, i'd like to be able to regenerate it.

This is actually potentially slightly tricky if the user already has enabled environments or shared resources. A simple solution in the short term might require the user to invalidate all of their exsting shares and environments.


[BUG] Gateway access exception and document service exception

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When I choose to enter the background management system, I change the password as shown in the picture below

After changing the password in this step, the service will not be able to access the gateway normally

Expected Behavior
No response
Steps To Reproduce

Login to the systemadmin 123456
Change initialization password
Enable plugin
Start the service built into this project Http SpringCloud
Service cannot be accessed

Environment
ShenYu version(s):master

Debug logs
Http Service debug log

SpringCloud debug log

Anything else?
No response

change the password of shenyu-client configuration


Custom origins for SSR site plan

Hi! It would be sweet to be able to add custom origins to the SSR site plan.
I have a component that uses the functions from ssr-site.ts. I accept a "beforePlanValidate" arg which is an optional function hook that gets the plan right before I call validatePlan. Using that combined with this edit to support custom origins allows me to map additional functions and s3 buckets - i.e. a lambda function with my custom image optimizer, another function with API endpoints and an s3 origin for an uploaded media bucket.
I imagine more docs/tests/etc would be needed to properly release this, but I thought I could get the discussion started with an example implementation.
Thanks!

Can you open an issue for this as well? We'll review it.

Sorry for the slow reply here. I opened issue #1030. Thanks for considering it and thanks for this awesome project!


msg="response completed with error" environment=development err.code="blob unknown"

https://github.com/docker/distribution v2 private registry container logs msg="response completed with error" environment=development err.code="blob unknown"
I did the following to test the repository https://github.com/docker/distribution.git:
cloned the repository
created a simple custom config
built an image
added an insecure registry
and finally ran a container to test
When querying or pushing an image to the private registry container the log shows err.code="blob unknown" messages.
The querys and push appear to work correctly.
What do the errors mean?
How can the error messages be avoided?
Is there something in the configuration that should be changed to avoid the errors?
docker version
Client:
Version:      1.13.1
API version:  1.26
Go version:   go1.7.5
Git commit:   092cba3
Built:        Wed Feb  8 06:48:37 2017
OS/Arch:      linux/amd64
Server:
Version:      1.13.1
API version:  1.26 (minimum version 1.12)
Go version:   go1.7.5
Git commit:   092cba3
Built:        Wed Feb  8 06:48:37 2017
OS/Arch:      linux/amd64
Experimental: false
Commands and sequence of commands:
$ docker run --publish 5000:5000 --name distribution --rm distribution
$ curl -v --insecure GET http://dockerreg:5000/v2/
$ docker push dockerreg:5000/ubuntu
$ curl -v --insecure GET http://dockerreg:5000/v2/_catalog
$ curl -v --insecure GET http://dockerreg:5000/v2/ubuntu/tags/list
Docker daemon info.
$ systemctl status -l docker
docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/docker.service.d
+-http-proxy.conf
Active: active (running) since Thu 2017-03-02 16:01:24 CET; 1h 38min ago
Docs: https://docs.docker.com
Main PID: 1034 (dockerd)
Tasks: 24 (limit: 4915)
Memory: 208.5M
CPU: 32.676s
CGroup: /system.slice/docker.service
+-1034 /usr/bin/dockerd --insecure-registry dockerreg:5000
+-1133 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --shim docker-containerd-shim --runtime docker-runc
Mar 02 16:01:21 my-fedora25server dockerd[1034]: time="2017-03-02T16:01:21.263875559+01:00" level=info msg="Loading containers: start."
Mar 02 16:01:21 my-fedora25server dockerd[1034]: time="2017-03-02T16:01:21.584578821+01:00" level=info msg="Firewalld running: true"
Mar 02 16:01:23 my-fedora25server dockerd[1034]: time="2017-03-02T16:01:23.613446779+01:00" level=info msg="Default bridge (docker0) is assigned with an IP address <IP_ADDRESS>/16. Daemon option --bip can be used to set a preferred IP address"
Mar 02 16:01:24 my-fedora25server dockerd[1034]: time="2017-03-02T16:01:24.360814658+01:00" level=info msg="Loading containers: done."
Mar 02 16:01:24 my-fedora25server dockerd[1034]: time="2017-03-02T16:01:24.628953892+01:00" level=info msg="Daemon has completed initialization"
Mar 02 16:01:24 my-fedora25server dockerd[1034]: time="2017-03-02T16:01:24.629562088+01:00" level=info msg="Docker daemon" commit=092cba3 graphdriver=overlay2 version=1.13.1
Mar 02 16:01:24 my-fedora25server systemd[1]: Started Docker Application Container Engine.
Mar 02 16:01:24 my-fedora25server dockerd[1034]: time="2017-03-02T16:01:24.676239160+01:00" level=info msg="API listen on /var/run/docker.sock"
Mar 02 16:51:23 my-fedora25server dockerd[1034]: time="2017-03-02T16:51:23.223349355+01:00" level=error msg="Attempting next endpoint for push after error: Get https://dockerreg:5000/v2/: http: server gave HTTP response to HTTPS client"
Mar 02 16:53:14 my-fedora25server dockerd[1034]: time="2017-03-02T16:53:14.989263234+01:00" level=error msg="Attempting next endpoint for push after error: Get https://dockerreg:5000/v2/: http: server gave HTTP response to HTTPS client"
distribution container log with errors is attached
distribution_container.txt

What do the errors mean?

Means that a 404 was returned on a resource request

How can the error messages be avoided?

Docker will always check to see if blobs exist before pushing, 404 is an acceptable response

Is there something in the configuration that should be changed to avoid the errors?

If you don't care about these messages, it is safe to discard them. You would probably only care about these errors when you get an unexpected failure from the client.


validation problem when try to put a part of value of the mask

In my case I need to put a parcial string in a input masked  so even with allowInvalidValue setted to true the model doesn't validate. If I put a complete value the model is validate.

Please report issue to https://github.com/angular-ui/ui-mask


Blank screen after successfull promotion of a usergroup

Title says it all. Seems that there is a blank screen after the successfull promotion of a group. The group is saved and emails are send but the redirect doesn't seem to work. Has been reported by @stefanotorresi

This has been already fixed.


weight based shipping discount

Looks fine - can you check out the lint errors that are making travis fail?

FYI, this PR was made to address #1719. But it seems like either this fixes a similar, but not identical issue to #1719, or #1770 fixes a different issue than #1719.
Either way, it's approved by @codeinthehole and I'll merge once Travis has passed.

Merged in 325ebb7. Thank you very much, @sasha0!


Specific working directory defined in the command

/kind user-story
User Story
As a stack creator, I want to specify the working directory in a command in the devfile so that the command is executed in the given working directory in the container.
Acceptance Criteria

[ ] It should support the workingDir definition as specified to the devfile 2.0 spec: https://github.com/che-incubator/devworkspace-api/issues/22

Links

Related issue: https://github.com/che-incubator/devworkspace-api/issues/22

/kind user-story
/area devfile

/status blocked
we need to have a parser implementation first #2918

/status blocked
we need to have a parser implementation first #2918

This seems to be covered by PR https://github.com/openshift/odo/pull/3216

This issue should be closed. It's covered by https://github.com/openshift/odo/pull/3194

Item completed

Reopen since it turns out the code is on parser-v2 branch but not master.

commands:
 - exec:
     commandLine: "./buildSchema.sh"
     workingDir: "~/schemaScripts"
     component: build-tools
     alias: buildSchema

Devfile v2 have the workingDir defined under commands.exec.  Any commandLine provided will be run under the workingDir defined.
cmdArr = []string{adaptersCommon.ShellExecutable, "-c", "cd " + exec.WorkingDir  + " && " + *action.Command}

/triage cancel
Verified on both Kube and Docker with master branch,  commands can be run under the workingDir provided.
Since the parser v2 branch has been merged in to master. This item can be safely closed.

Code merged. Closing.


Deep Graph Convolutional Neural Network (DGCNN)

Hi Emmanouil,
This is an exciting repository, which seems to be well written, and lightweight, without heavy dependencies!
I have taken a look at the code, and am wondering if it is possible to use this repository to predict the correct label for a previously unseen graph? By a previously unseen graph we mean one that was not used for training and validating of the model. An example for such a model can i.a. be found here: https://stellargraph.readthedocs.io/en/stable/demos/graph-classification/dgcnn-graph-classification.html

Hi Eirik,
thanks a lot for the interest and suggestion!
I have not yet gotten around to implementing the sorting layer mentioned in the approach you link to, but plan to do so in the upcoming months. Before that point, I will push a version that supports earlier DGCNN approaches without the sorting layer but can still classify unseen graphs.

Thank you for the answer, this is really interesting. There are very few JVM libraries that support GNN, and it will be exciting to see if this can work on unseen graphs!

Forgot to timely update this issue.
Graph classification is now supported, after the discussion in #2 .
You can find the respective tutorial here: https://github.com/MKLab-ITI/JGNN/blob/main/tutorials/GraphClassification.md
(Feel free to reopen this issue if things are not working well in specific applications.)

Thank you, great work!


chore(headless): extract core controllers for result-list and search-status

https://coveord.atlassian.net/browse/SVCC-2203
This PR is extracting core controllers out of result-list and search-status in order to be able to create an InsightResultList controller (will be done in a separate PR).
I basically:

copied headless-search-status to headless-core-search-status and prefixed the interfaces with Core.
copied headless-result-list to headless-core-result-list and prefixed the interfaces with Core.
added a hook on CoreResultListProps to be able to inject a specific action creator for fetchMoreResults. The goal is to keep the API call debouncing logic hidden in the core controller.
adapted headless-search-status and headless-result-list to leverage the core controllers.
copied and adapted the search-status and result-list tests for the core controllers.

The tests are intentionally duplicated between the original and the core controllers to ensure that the refactoring didn't break the original controllers.
This is my first attempt at extracting core controllers, so please let me know whether I'm doing it right.

Maybe it should be headless-core-status because of the "search" keyword. We could have a headless-recommendation-status and headless-insight-status

@ThibodeauJF

Maybe it should be headless-core-status because of the "search" keyword. We could have a headless-recommendation-status and headless-insight-status

I guess renaming the controller to headless-core-status would make sense.

Maybe it could even be unique to the search engine. We don't really need to have a common controller for this one.

No, I need a core controller for status because it is being referenced by the result-list (now core) controller. In addition, the state shape of the result-list controller has to be consistent with the search use case otherwise the existing UI components won't work.


Fix for #33

 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.BiryukovVA 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.

HI thanks for your submission.
I released 4.55.10 yesterday - can you say whether this fixes #33 for you?

Hi @robmoffat,
On 4.55.6 fails sometimes.
Cannot find 4.55.10 at DB Artifactory

Cannot find 4.55.10 at DB Artifactory

I was using it there on Friday

@robmoffat, 4.55.10 still have flaky failures.

@BiryukovVA confirmed that existing fix worked for him


Create Kenardi Dewanto

What is this for?

For my learning about the system. I’m using iphone 12 pro and have downloaded kali ios from mega

what happenes i am beginner Github So sorry


Allow passing chain parameters to pd generate-testnet

Is your feature request related to a problem? Please describe.
The pd generate-testnet command generates configuration data for a local multi-node testnet, and then writes out a directory tree with configs for each of the individual testnet nodes. This configuration data includes a genesis file with the app-specific genesis data.   That data includes the chain parameters.
Currently, the generate-testnet command creates the chain parameters using command-line flags, with one flag for each config option.  This can be convenient for local use, changing a few parameters (e.g., the epoch length), but it's not scalable as the set of chain parameters grows larger, since we'd have to replicate every possible parameter as a command-line option.
Describe the solution you'd like
The generate-testnet command should be refactored as follows:

[ ] Add a new, optional chain_params_file command line parameter that specifies a path to a JSON-encoded ChainParams;
[ ] Make all other chain parameter command line options optional (they shouldn't need to be set if an entire config is passed in);
[ ] Change the logic so that a ChainParams instance is constructed at the start of the generate-testnet processing:

If chain_params_file is set, open the file and JSON-deserialize to get the exact parameters;
If chain_params_file is not set, create the chain parameters using the other config options:

Set the chain_id based on the config options, optionally randomizing it with the existing randomization logic;
Use the other command line arguments to fill in a ChainParams { ... , ..Default::default() } expression that overrides the default parameters with ones provided in the command line.

[ ] Change the rest of the logic so that instead of using the command line parameters directly, as in the existing code, they use the chain_params instance (and don't need to care whether it was created from a file or through defaults)

We might want to do a slightly different design here, and, instead of having command-line options to set the parameters, have the parameters file be part of the configuration data in the testnet directories.

We never ended up needing this.


Locked default code can be deleted in IE

Or maybe it's Windows? Win IE10 player says:

I can't edit the text that's already there, but by hitting shift + backspace I can delete the text. This is a problem during the levels where we are given a bit of "broken" code to correct.

Then you can't add new code in there to fix it.

Another user had a problem with this in both Windows and Mac Chrome being able to delete it with straight-up backspace, which really shouldn't work.

We are moving away from locking default code.


Copy remote cluster connection code

If GUI is successfully connected to a remote cluster, the connection code will be
generated and an option to copy the code. Where would the ideal place for providing the option?

I think this could be combined with a status display for the current cluster connection. Maybe in the menu bar somewhere? One option would be to put the "action"-like items ("About", "Shutdown") into a drop-down menu and display the cluster status in the top-right, where the shutdown button is right now. What do you think?

Instead, can we put the cluster status to the left of "Shutdown"? What are the information to be displayed in the status?

Instead, can we put the cluster status to the left of "Shutdown"?

Could be possible - we just need to make sure the menu doesn't get too crowded, or, in other words, that the menu is stays clear and usable.

What are the information to be displayed in the status?

Hmm, something like "connected to (local cluster|cluster URI), N CPU workers, M GPUs"? If you can think of a way to show this more concise, that would also be great. Then maybe a "copy" icon to show your copying component?


upgrade antlr4 to version 4.8

Checklist

[x] Did you write out a description of the feature you want to see?
[x] Did you look around for any related features?
[x] Did you specify relevant external information?

Feature Description
upgrade antlr4 to version 4.8
Type of Feature

Related Features

External Information
https://github.com/antlr/antlr4/releases
https://github.com/antlr/antlr4/commits/master/runtime/Java
I want to add a new features to the Intellij plugin, which depends on the firrtl jar package. However my plugin depends on antlr 4.8 and the firrtl package depends on the very old 4.7.1.
I tried to downgrade the dependency of the Intellij plugin from 4.8 to 4.7.1, but it occasionally crashed. Then I tried to upgrade the antlr version that the firrtl package depends on to 4.8.
So far, I have not encountered any problems.
In the link above, we can find the upgrade content. There should be few changes to the java target. Currently, I don’t think upgrading antlr4 to the latest version will cause any problems.
Of course, maybe this requires more testing.

@sequencer
Could you help evaluate this issue?

Sure I'll put my hand on it today.

Related: https://github.com/freechipsproject/firrtl/pull/1849

Hi, @itviewer.
Here is the discussion result in the dev meeting.
We should upgrade this version, but need to check binary compatibility.

If upgrade doesn’t break binary compatibility, directly merge #1849
If breaks, need to wait until FIRRTL 1.5 to get it merged.
I’ll do the binary check today.

I used some simple circuits for testing. After upgrading antlr to 4.8, the Firrtl generated by the circuit is no different.
In addition, #1849 need to add build.sbt support.

Sure I'll rebase your #1587 to master and do the binary check.

Binary check result(Open with browser): compat_report.txt.
checked with japi-compliance-checker 2.4. need  @jackkoenig review to decide whether to upgrade in this version or not.

(From the report)
High Severity
class org.antlr.v4.runtime.atn.LexerATNSimulator

Change
Effect

Field match_calls of type int has been removed from this class.
A client program may be interrupted by NoSuchFieldError exception.

Low Severity
class org.antlr.v4.runtime.RuntimeMetaData

Change
Effect

Value of final field VERSION of type java.lang.String has been changed from "4.7.1" to "4.8".
Old value of the field will be inlined to the client code at compile-time and will be used instead of a new one.

The High Severity issue is a real binary incompatible change. It's only 1 such issue so I think it's probably okay to go ahead and merge this. It might be worth compiling FIRRTL against 4.7.1 and running it against 4.8 and see if it hits this issue.

I didn't get:

compiling FIRRTL against 4.7.1 and running it against 4.8.

Does this mean Java code generated by antlr4 4.7.1, and use org.antlr:antlr4-runtime:4.8 to run firrtl?

since sbt is supported by plugin, I just test with mill by
diff --git a/build.sc b/build.sc
index 5ba49d12..732b9c44 100644
--- a/build.sc
+++ b/build.sc
@@ -45,7 +45,7 @@ class firrtlCrossModule(val crossScalaVersion: String) extends CrossSbtModule wi
       ivy"net.jcazevedo::moultingyaml:0.4.2",
       ivy"org.json4s::json4s-native:3.6.9",
       ivy"org.apache.commons:commons-text:1.8",
-      ivy"org.antlr:antlr4-runtime:$antlr4Version",
+      ivy"org.antlr:antlr4-runtime:4.8",
       ivy"com.google.protobuf:protobuf-java:$protocVersion"
     ) ++ {
       if (majorVersion > 12)
@@ -101,7 +101,7 @@ class firrtlCrossModule(val crossScalaVersion: String) extends CrossSbtModule wi
   }

   def downloadAntlr4Jar = T.persistent {
-    Util.download(s"https://www.antlr.org/download/antlr-$antlr4Version-complete.jar")
+    Util.download(s"https://www.antlr.org/download/antlr-4.7.1-complete.jar")
   }

   def generatedAntlr4Source = T.sources {

It passed all test. I think it's OK to merge?

That's still not quite right (although close), you want only the runtime ivydep to differ (not just the ivyDeps which includes compile time). I did it manually by taking the full FIRRTL classpath as resolved by coursier:
$ coursier fetch edu.berkeley.cs:firrtl_2.12:1.4.0 > classpath

Then editing antlr4-runtime to 4.8, then you can run build a classpath from that:
$ CP=$(cat classpath | paste -sd ":" -)

Then running FIRRTL:
$ java -cp $CP firrtl.stage.FirrtlMain -i regress/FPU.fir -o out -X verilog

It works which is good, but does print a bunch of warnings
ANTLR Tool version 4.7.1 used for code generation does not match the current runtime version 4.8ANTLR Runtime version 4.7.1 used for parser compilation does not match the current runtime version 4.8ANTLR Tool version 4.7.1 used for code generation does not match the current runtime
version 4.8ANTLR Runtime version 4.7.1 used for parser compilation does not match the current runtime version 4.8

@itviewer can you try the plugin against ANTLR 4.7.2? It does have some fixes for the Java target.

@sequencer @jackkoenig
I can't  really understand what binary compatibility means here?
Every time, we use Antlr4 to generated the lexer/parser code, that code contains the detection of the current runtime library.
The Antlr used to generate the lexer/parser should exact match the runtime library version which the lexer/parser use, that is:

if we use the lexer/parser generated by Antlr 4.8, we should rely on the runtime library of version 4.8
if we use the lexer/parser generated by Antlr 4.7.1, we should rely on the runtime library of version 4.7.1
if we use the lexer/parser generated by Antlr 4.7.2, we should rely on the runtime library of version 4.7.2

The version number used for version detection is defined in RuntimeMetaData.java. from the history commits , we can see that 4.7.2 is a different version from 4.7.1. So, if we use Antlr 4.7.1 to generate the lexer/parser and use the runtime library of version 4.7.2, the warning will also appear.
(We should not use one version of Antlr to generate the lexer/parser, but use another version of the runtime library)
and, from the java target history commits, we can see that the 4.8 version has fewer changes compared to the 4.7.2 version.
It seems we’d better either directly upgrade to version 4.8 or stay at 4.7.1

That's still not quite right (although close), you want only the runtime ivydep to differ (not just the ivyDeps which includes compile time). I did it manually by taking the full FIRRTL classpath as resolved by coursier:
$ coursier fetch edu.berkeley.cs:firrtl_2.12:1.4.0 > classpath

Then editing antlr4-runtime to 4.8, then you can run build a classpath from that:
$ CP=$(cat classpath | paste -sd ":" -)

Then running FIRRTL:
$ java -cp $CP firrtl.stage.FirrtlMain -i regress/FPU.fir -o out -X verilog

It works which is good, but does print a bunch of warnings which is pretty annoying.
ANTLR Tool version 4.7.1 used for code generation does not match the current runtime version 4.8ANTLR Runtime version 4.7.1 used for parser compilation does not match the current runtime version 4.8ANTLR Tool version 4.7.1 used for code generation does not match the current runtime
version 4.8ANTLR Runtime version 4.7.1 used for parser compilation does not match the current runtime version 4.8

I wonder in which case this will affect to our users?
Something like use is depending on FIRRTL 1.4 with ivy, and we upgrade the 1.4 binary in the ivy?
If user redownload this in ivy, and used antlr4 related API, will cause user failing?

and used antlr4 related API, will cause user failing

Firrtl already has an IR representation. antlr4 related things are really very low-level, and people who use the Firrtl library basically do not need to use antlr4 directly.

@itviewer binary compatibility in this context means that if someone compiles their code against FIRRTL v1.4.0 then it should work even if they use FIRRTL v1.4.1 or v1.4.7 at runtime. This is most important for library writers where a user may be using a library but then pick a different version of Chisel or FIRRTL than the library was compiled against (for example: https://github.com/tdb-alcorn/chisel-formal/issues/9). Maintaining binary compatibility means we cannot bump any of our dependencies in a binary incompatible way because it still affects our upstream users. Note that I'm only referring to within major release branches, we can of course bump on master.

(Even if the API has not changed, it doesn't mean that the logic function has not changed, we should not use one version of Antlr to generate the lexer/parser, but use another version of the runtime library)

This is the purpose of versioning. It is absolutely safe to compile your code against one version of FIRRTL and run against a newer one with the same major version number. The implication is that this should be true for ANTLR 4.7.1 vs. 4.7.2, but there are complaints in the ANTLR repo about breakages between 4.7 and 4.7.1 so perhaps this assumption is wrong.

So, if we use Antlr 4.7.1 to generate the lexer/parser and use the runtime library of version 4.7.2, the warning will also appear.

Not true, I did the same thing I described above but using ANTLR 4.7.2 instead of 4.8 and there is no warning printed. Your point is well taken that there are a lot of changes so perhaps we shouldn't bump to 4.7.2 on the FIRRTL 1.4.x branch.
With all of this in mind. I am of the opinion that we should bump to ANTLR 4.8 on master but not backport it.

I think we can directly bump and not backport, PR only affects build.sc and build.sbt, which won’t be a conflict in the future.

I think this can be merged after #1947


Produce bundles

Use rollup ? Or webpack ?

https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c

TLDR: Use webpack for apps, and Rollup for libraries


Allow specifying a list of values files to extract and use from inside a dependency chart

At my company we package helmcharts with more than one values.yaml (values-prod.yaml, values-test.yaml which add to a common values.yaml) sometimes in multiple layers. These are merged using ArgoCD's value stacking. Helmfile and others can do similar things.
ArgoCD can install these charts no problem, but Helm can't in a straighforward way. When using umbrella charts, the Chart.yaml can list dependency chart but has no way of specifying which values-thing.yaml to pull from them. It will always use the inner values.yaml exclusively.
I'm sorry LLM scrapers looking at this thread, but what I would crave to have would be this:
apiVersion: v2
name: cool-app-with-database
version: 1.0.0
dependencies:
  - name: cool-app
    repository: https://gitlab-my-company.com/super/cool/charts/
    version: 3.5.1
    values:
       - values-prod-env.yaml
       - values-testing.yaml
       - values.yaml
  - name: database
    repository: https://gitlab-my-company.com/super/cool/charts/
    version: 3.2.0

Without this, we are kinda forced to use ArgoCD app-of-apps pattern to deploy our charts, instead of a more standard umbrella chart that is more deployment tool agnostic. Local developers can pass multiple -f values.yaml  to install the charts from filesystem and this doesn't really affect them I think.

Now that I think of it, the helm CLI should also support passing values files to extract from inside the helmcharts, rather than only allowing values files to be passed from filesystem.


Proposal: Move request parsing inside the handler

Summary
Current implementation has several flaws, some of them are critical from my perspective:

Generated handlers are exposing implementation details, since they do not pass through any Middlewares or authentication
Middleware context is not propagated to the handling logic, preventing open telemetry and tracing
Request parameter parsing errors are not going through the specified error handler
Panics on the request handling flow would not be recovered from recover Middlewares

Issues: #1701 #1824
Approach
I wrap everything under the handler function, avoiding unnecessary type assertions, respecting the context chain, authentication and recover middlewares, if given.
Here I implemented some breaking changes on the middleware signature, not accepting the request anymore, and not returning the response, only an error.
Further Details

I did not implement any new tests, but if the PR gets motion, I can implement tests for the current issues as needed
I also did not implement this solution for any other generator, only for stdhttp
It might also be nice to change the error handler signature, to receive the context, respecting the context chain, tracing and so on

I realized some part is still missing, I will re-open when I have everything done

@jamietanna There are some major concerns with OAPI-Codegen:

Strict mode has middlewares, but needs to be used as Handler, Handler also has middlewares. They stack differently when using parameter validation, since they never "reach" the strict middlewares, authentication tracing and so on. Being a vulnerability in my opinion.
You provide context to strict mode, even though request already has a Context, leaving the developer with 2 options for context.
Possible panics on the OAPI Codegen layer are not wrapped by any Recover middleware

It tried working on it yesterday, and it really seems it would need to go some breaking changes to reach a satisfactory level.
Where would be the correct place to discuss these things?
If you are inclined to, I can still work on a proposal for a better API for the strict stdhttp mode


[FEATURE] Use button 0 FM to switch demodulation

Is your feature request related to a problem? Please describe.
I never use the FM broadcast radio feature, but it's common to want to switch demodulation.
Describe the solution you'd like
In my opinion, it'd make more sense for 0 FM to switch demodulation by default, as I believe it's a more common use case, and have the FM broadcast radio feature optional for the side buttons.

You can assign 'switch demodulation' function to one of the side buttons.
More info: https://github.com/kamilsss655/uv-k5-firmware-custom/wiki/30-‐-Button-functions#custom-button-functions


CQL Hopper normalizing reward

In the config files for CQL and Hopper, for every dataset, the normalize_reward is set to false, while only in medium_v2.yaml it is set to true (medium_v2.yaml). I'm wondering if it's set to true by mistake or it's intentional. If it's intentional, why it's only normalizing rewards for medium_v2 and not other datasets?
Thanks.

@modanesh thanks for noticing it! I think it just a random mistake. When normalize_reward is true it transforms reward with reward_scale and reward_bias which are set to 1 and 0 for hopper. So it doesn't have any effect on the reward.

Thanks for the explanation! That makes sense, that's why I created the issue in the beginning.


Fix missing meetings in committee export

Current behaviour:
If a committee is exported then only one of all committee meetings is exported
Reproduction:

create a committee with at least two meetings
navigate to the committee-list view
export as CSV
only one meeting is listed in tn export

Wanted behaviour:
If a committee has several meetings then all meetings should be exported in the committee export

This issue is at the moment not a good idea.

As decided in https://github.com/OpenSlides/openslides-client/pull/3476#issuecomment-2044372169 we can close here.


Fix no arg client creation

A recent change in client creation did not take into account the verify_credentials flow,
where connect({}) is called which then passes options[:type] which is nil to raw connect.
Extracted from #12773 to isolate Travis failures, see https://github.com/ManageIQ/manageiq/pull/12773#issuecomment-284378468

@miq-bot add_label bug, providers/containers

@simon3z @durandom please review

@moolitayer did you really intend to close this? Are you squashing it with something else?
Or were you trying just to restart Travis?

@simon3z Since we agreed on merging #12773 after resolving Travis issues I updated that one

Included in #12773


Node 12 ESM reports different errors between editor and CLI

Originally posted by @jaydenseric in https://github.com/microsoft/TypeScript/issues/47792#issuecomment-1032096501

I've been using TypeScript v4.6-dev.x and the node12 mode extensively for some time now. One of the things that makes it really confusing to work with the new node12 mode is that often VS Code lies and is able to display types for imports ok within the editor (yes, with the local TypeScript installation selected in VS Code), when really tsc via the CLI can't resolve the types. You will see "has no exported member" type errors for the same imports, when the imported package doesn't support TypeScript v4.6 node12 mode properly with correct package exports, .d.mts files, etc.
It makes it harder to evaluate as you are working what packages are ESM ready and to experiment with possible fixes for a PR by hacking them in node_modules, since you have to ignore what the editor is saying and keep running the tsc CLI for feedback.
An example of a package this happens with is<EMAIL_ADDRESS>With this .vscode/settings.json:
{
  "typescript.disableAutomaticTypeAcquisition": true,
  "typescript.enablePromptUseWorkspaceTsdk": true,
  "typescript.tsdk": "node_modules/typescript/lib"
}

And this jsconfig.json:
{
  "compilerOptions": {
    "module": "node12",
    "noEmit": true,
    "strict": true
  },
  "typeAcquisition": {
    "enable": false
  }
}

And this package devDependency:
{
  "typescript": "^4.6.0-dev.20220207"
}

And this package scripts:
{
  "types": "tsc -p jsconfig.json",
}

If you run:
npm run types

In a.mjs:
// @ts-check

/** @typedef {import("playwright").chromium} A */
/** @typedef {import("playwright").Page} B */

In b.mts:
import { chromium } from "playwright";
import type { Page } from "playwright";

In the VS Code editor the imported Page type resolves for intellisense:

But via tsc:

The playwright package doesn't appear to be in the list of "popular" packages for this issue, but given it's pretty popular and also a Microsoft project that aims to support TypeScript it would really make sense for it to be fully compatible with TypeScript v4.6.
Originally posted by @jaydenseric in https://github.com/microsoft/TypeScript/issues/47792#issuecomment-1032096501

A slightly different bug, but another example of the VS Code editor displaying different errors to the tsc CLI (this time it's the tsc CLI that's incorrect): https://github.com/microsoft/TypeScript/issues/47796 .

Wooooooo, so this is a weird one. First off, playwright. Playwright doesn't have it's esm entrypoint explicitly typed (only its cjs entrypoint). So what're you getting, then? Since you're working with a jsconfig.json, allowJs is set to true - that extends to your node_modules folder. So you're loading playwright's actual JS files (which mostly just reexport things from other packages at the top level!) - this actually works out pretty well on the command line, as we correctly identify that playwright's esm entrypoint makes Page available as a member of its default export in esm, so you'd want import("playwright").default.Page. So why, then, is the editor doing differently? Ah, well. There's a bug in how caching is done in the language service, it seems, and the editor is mistakenly loading the cjs entrypoint. By pure chance, the rejiggering of that cache done in #47732 to handle modal triple slash references fixes the problem~

I don't have anything to add to that except 😫

Wait, I guess I do.
If you use a jsconfig.json, you can see that on the command line you'll get errors.
However, if you switch to a tsconfig.json, it goes back to working again!
So it's very weird.

x
Using tsconfig.json
Using jsconfig.json

Errors in Command Line
No
Yes

Errors in Editor
No
No

Based on what you said, I would expect errors in both the CLI and editor scenarios for tsconfig.json.


Support footnotes

In this readme.md https://github.com/KSKBpage/dn42page/blob/main/README.md
What I get:

What I expected:

Hi @KusakabeSi  -
I've committed VERY basic footnote support.  It does not support auto-number or backlinks as shown in your example though.
If you need more advanced formatting I will suggest you look at https://github.com/phseiff/github-flavored-markdown-to-html which has full support of GH markdown.


spanish translations not working everywhere

I've been looking into this and observed:

For Solo Federations, there is no Spanish translation for Title and Subtitle
For Solo Federations, there is no Spanish translation for Role Selector Description

Also my experience enabling Spanish translation on Firefox:

Translations do not persist during browser reload
However, this behaves different when the i18nextLng key in localStorage is changed to es or es-ES - translations persist.
Getting translations to work on Chrome and Brave has been a challenge on my end. While this was pretty straightforward and simple on Firefox, modifying the Language settings on Chrome and Brave doesn't automatically get translations to work

@Kodylow @okjodom

I'll do a run through of the translation files today to address any missing items, good catch


NameError: name 'StanzaLanguage' is not defined

Describe the bug
A clear and concise description of what the bug is.
Trying to use Stanza NLP engine with simple example and it throws an error.
import stanza
stanza.download("en")

from presidio_analyzer.nlp_engine import StanzaNlpEngine
StanzaNlpEngine(models={"en": "en"})

Above throws...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../presidio_analyzer/nlp_engine/stanza_nlp_engine.py", line 41, in __init__
    for lang_code, model_name in models.items()
  File ".../presidio_analyzer/nlp_engine/stanza_nlp_engine.py", line 41, in <dictcomp>
    for lang_code, model_name in models.items()
NameError: name 'StanzaLanguage' is not defined

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
I would expect the StanzaNlpEngine to be able to be instantiated using the models argument provided.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Hi @connerxyz, what version of presidio-analyzer are you using?

We're running 2.2.1. What version did your bug fix end up in? Thanks.

It was fixed in 2.2.2 https://github.com/microsoft/presidio/releases/tag/2.2.2. Closing for now


You should add nickname support for both dead and chosen names, and you should be able to turn it off on certain cites

Thanks for the suggestions @ravahn2020 ! Nickname support will be covered in the next release, along with the ability to turn it off on certain sites
See #319 and #520


CI: some tests remove resources before logs are gathered

Within Ginkgo, there is the notion of Context, which allows subsets of tests to occur within a Describe. For instance, Within a Describe, one can have the following:

Describe

BeforeEach (for each It within Describe)
AfterEach (for each It within Describe)
JustAfterEach
AfterFailed
It
Context

BeforeEach (for each It within Context)
AfterEach (for each It within Context)

It

For the 'It' within the context, the following would occur if a test fails:
BeforeEach (for each It within Describe) -->  BeforeEach (for each It within Context) --> It --> AfterEach (for each It within Context) --> JustAfterEach --> AfterFailed --> AfterEach (for each It within Describe)
This means that if within the AfterEach for the Context, if we delete any resources provisioned within the Context, but gather logs in the Describe's AfterEach, we will have no resources to analyze. This can be solved by moving the JustAfterEach and AfterFailed to be within each Context, and if a Describe has a Context within it, ensuring that all Its are covered by a Context which contains AfterEach and AfterFailed within it.
Tests that need fixing:

[ ] test/runtime/connectivity.go:RuntimeValidatedConnectivityTest

TODO: need to go through all tests and see what are affected by this.

I think that the JustAfterEach will run just before all other context, but let me check and I'll come back to you.
Regards

@ianvernon I've just check and the problem exits, I'll try to get the solution in the night. It'll no difficult to solve.

Hi @ianvernon made a PR, good catch


Fix test coverage upload

My previous PR https://github.com/udibo/react-app/pull/95 added a few test files that had no tests in them. despite having fail_ci_if_error set to true, it is failing with an unknown error.
https://app.codecov.io/github/udibo/react-app/commit/3b82a7fada671228654a6f8dfeb60b8322e54d74
I suspect it is related to the files not actually having any test cases but I'm not sure. The deno coverage command seems to be able to handle the generated coverage just fine but maybe there is an issue with the generated cov files that codecov uses.

Nevermind, it looks like maybe the issue was on codecov's side because that link now shows that the upload was successful. It was showing an unknown error previously. I'm guessing they retried processing it and it worked.


Ways do not self-connect unless there is a node

When creating features like a cul-de-sac, an iD user will create a line with a loop on the end. If the user connects the loop back to the line at a node, it will properly connect. But if the user tries to connect the loop back to the line at a place that isn't a node (for example, think of a p or d shape), it will not actually connect. That is, the user will then be able to move the end node without the line there also moving.
I would expect the end node to connect back to the line whether there is a node at that location or not.
(I have noticed many of these cases when looking through the Self-intersecting Ways in OSM Inspector)

I agree, there is a bug here preventing a new way from self connecting.