Seeing a Segfault

This library is generating a segfault for me when I do this  - HTTP.get(s3_object_public_url).body.to_s
This is on our Heroku workers, they keep crashing with Segfault. Please see details below.
Its starts with the following error -
2019-11-14T21:40:44.777135+00:00 app[worker_a.2]: pid=4 tid=grp4a8ox4 WARN: HTTP::ConnectionError: couldn't read response headers
2019-11-14T21:40:44.777281+00:00 app[worker_a.2]: pid=4 tid=grp4a8ox4 WARN: /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/connection.rb:104:in `read_headers!'
2019-11-14T21:40:44.777285+00:00 app[worker_a.2]: /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/client.rb:75:in `perform'
2019-11-14T21:40:44.777287+00:00 app[worker_a.2]: /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/client.rb:31:in `request'
2019-11-14T21:40:44.777289+00:00 app[worker_a.2]: /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/chainable.rb:75:in `request'
2019-11-14T21:40:44.777291+00:00 app[worker_a.2]: /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/chainable.rb:20:in `get'

Versions -

gem 'http', '4.2.0'
gem 'rails', '6.0.1'
ruby '2.6.5'
Deployed on Heroku

Segfault -
2019-11-15T03:04:25.870353+00:00 app[worker_a.17]: -- Control frame information -----------------------------------------------
2019-11-15T03:04:25.870365+00:00 app[worker_a.17]: c:0047 p:---- s:0249 e:000248 CFUNC  :http_parser_execute
2019-11-15T03:04:25.870382+00:00 app[worker_a.17]: c:0046 p:0025 s:0241 e:000240 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-parser-1.2.1/lib/http-parser/parser.rb:222
2019-11-15T03:04:25.870386+00:00 app[worker_a.17]: c:0045 p:0011 s:0235 e:000234 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/response/parser.rb:29
2019-11-15T03:04:25.870390+00:00 app[worker_a.17]: c:0044 p:0057 s:0230 e:000229 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/connection.rb:217
2019-11-15T03:04:25.870393+00:00 app[worker_a.17]: c:0043 p:0039 s:0223 e:000222 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/connection.rb:92
2019-11-15T03:04:25.870395+00:00 app[worker_a.17]: c:0042 p:0090 s:0216 e:000215 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.2.0/lib/http/response/body.rb:51

Seems like a potential memory safety issue? /cc @ixti

@tarcieri Might be.
@kapso Which heroku build-pack are you using? I want to try to reproduce it.

heroku/ruby - this is the default build pack for rails/ruby apps
The stack is Heroku-18 which is Ubuntu 18.04, you can read more here - https://devcenter.heroku.com/articles/heroku-18-stack

@kapso Please provide Gemfile.lock (don't forget to filter out any sensitive info).

@ixti here you go - https://gist.github.com/kapso/e8c6df153bf96d32876710fd426e8b4d

Thank you. I will take a look as soon as possible.

Curious, if there's a fix coming for this? We are ready to push code to production and switched to RestClient in the interim. But obviously would prefer HTTP.

@ixti Checking again, if there's a fix for this?

@kapso if possible, can you come up with a reproduction of this bug or capture it in gdb and get a C stack frame level backtrace?

Sorry, got really busy days lately and was not able to reproduce the error so far, so yeah, any help in reproducing it or analysing why it fails - will help significantly.

Hey @ixti, unfortunately, I can't replicate that. I remember we were running a massive batch process with reading millions of S3 objects (in background Sidekiq jobs) which was causing the issue. Let me check with the team if we can run it again, though I doubt it since its an expensive process : )
No need to apologize, thanks a lot for your work 👍

We're running into occasional segfaults as well at seemingly the same spot. We can't reproduce, but it appears to happen once every 10,000+ client.request(verb, uri, opts) calls.
I'm 99% sure this started happening after upgrading from 4.1.1 to 4.4.1. (http_parser dependency went from 0.6.0 -> 1.2.1 at the same time)
We just reverted back to 4.1.1. I'll report if it happens again after reverting.
Logs:
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/http-parser-1.2.1/lib/http-parser/parser.rb:222: [BUG] Segmentation fault at 0x00007f2804fa3000
Oct 1 10:06:46 app[worker] info ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux]
Oct 1 10:06:46 app[worker] info
Oct 1 10:06:46 app[worker] info -- Control frame information -----------------------------------------------
Oct 1 10:06:46 app[worker] info c:0016 p:---- s:0086 e:000085 CFUNC  :http_parser_execute
Oct 1 10:06:46 app[worker] info c:0015 p:0025 s:0078 e:000077 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-parser-1.2.1/lib/http-parser/parser.rb:222
Oct 1 10:06:46 app[worker] info c:0014 p:0011 s:0072 e:000071 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/response/parser.rb:29
Oct 1 10:06:46 app[worker] info c:0013 p:0057 s:0067 e:000066 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/connection.rb:217
Oct 1 10:06:46 app[worker] info c:0012 p:0017 s:0060 e:000059 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/connection.rb:103
Oct 1 10:06:46 app[worker] info c:0011 p:0073 s:0055 e:000054 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/client.rb:75
Oct 1 10:06:46 app[worker] info c:0010 p:0034 s:0048 e:000047 METHOD /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/client.rb:31
Oct 1 10:06:46 app[worker] info c:0009 p:0017 s:0039 e:000038 METHOD /app/app/services/http_client.rb:8
Oct 1 10:06:46 app[worker] info c:0008 p:0009 s:0032 e:000031 BLOCK  /app/app/services/http_client.rb:106
Oct 1 10:06:46 app[worker] info c:0007 p:0005 s:0028 e:000027 BLOCK  /app/vendor/bundle/ruby/2.6.0/gems/connection_pool-2.2.3/lib/connection_pool.rb:63 [FINISH]
Oct 1 10:06:46 app[worker] info c:0006 p:---- s:0025 e:000024 CFUNC  :handle_interrupt
Oct 1 10:06:46 app[worker] info c:0005 p:0031 s:0020 e:000019 BLOCK  /app/vendor/bundle/ruby/2.6.0/gems/connection_pool-2.2.3/lib/connection_pool.rb:62 [FINISH]
Oct 1 10:06:46 app[worker] info c:0004 p:---- s:0016 e:000015 CFUNC  :handle_interrupt
Oct 1 10:06:46 app[worker] info c:0003 p:0026 s:0011 e:000010 METHOD /app/vendor/bundle/ruby/2.6.0/gems/connection_pool-2.2.3/lib/connection_pool.rb:59
Oct 1 10:06:46 app[worker] info c:0002 p:0008 s:0006 e:000005 BLOCK  /app/app/services/http_client.rb:105 [FINISH]
Oct 1 10:06:46 app[worker] info c:0001 p:---- s:0003 e:000002 (none) [FINISH]
Oct 1 10:06:46 app[worker] info
Oct 1 10:06:46 app[worker] info -- Ruby level backtrace information ----------------------------------------
Oct 1 10:06:46 app[worker] info /app/app/services/http_client.rb:105:in `block (2 levels) in REDACTED'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/connection_pool-2.2.3/lib/connection_pool.rb:59:in `with'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/connection_pool-2.2.3/lib/connection_pool.rb:59:in `handle_interrupt'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/connection_pool-2.2.3/lib/connection_pool.rb:62:in `block in with'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/connection_pool-2.2.3/lib/connection_pool.rb:62:in `handle_interrupt'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/connection_pool-2.2.3/lib/connection_pool.rb:63:in `block (2 levels) in with'
Oct 1 10:06:46 app[worker] info /app/app/services/http_client.rb:106:in `block (3 levels) in REDACTED'
Oct 1 10:06:46 app[worker] info /app/app/services/http_client.rb:8:in `execute!'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/client.rb:31:in `request'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/client.rb:75:in `perform'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/connection.rb:103:in `read_headers!'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/connection.rb:217:in `read_more'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/http-4.4.1/lib/http/response/parser.rb:29:in `add'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/http-parser-1.2.1/lib/http-parser/parser.rb:222:in `parse'
Oct 1 10:06:46 app[worker] info /app/vendor/bundle/ruby/2.6.0/gems/http-parser-1.2.1/lib/http-parser/parser.rb:222:in `http_parser_execute'
Oct 1 10:06:46 app[worker] info
Oct 1 10:06:46 app[worker] info -- Machine register context ------------------------------------------------
Oct 1 10:06:46 app[worker] info  RIP: 0x00007f2804fa3000 RBP: 0x00007f27e52cca40 RSP: 0x00007f27e52cc988
Oct 1 10:06:46 app[worker] info  RAX: 0x00007f27edd9c720 RBX: 0x00007f27d0c47ff5 RCX: 0x00007f27f3f20220
Oct 1 10:06:46 app[worker] info  RDX: 0x0000000000000004 RDI: 0x00007f27e0f927b0 RSI: 0x00007f27d0c47ff1
Oct 1 10:06:46 app[worker] info   R8: 0x00007f27f3f203cb  R9: 0x00007f27e0f927b0 R10: 0x00007f27f3f203d3
Oct 1 10:06:46 app[worker] info  R11: 0x000000000000002c R12: 0x00007f27d0c48554 R13: 0x00007f27f3f1f7b0
Oct 1 10:06:46 app[worker] info  R14: 0x00007f27d0c47ff6 R15: 0x0000000000000016 EFL: 0x0000000000010202
Oct 1 10:06:46 app[worker] info
Oct 1 10:06:46 app[worker] info -- C level backtrace information -------------------------------------------
Oct 1 10:06:46 app[worker] info /app/vendor/ruby-2.6.6/bin/../lib/libruby.so.2.6(rb_vm_bugreport+0x769) [0x7f2804bea259] vm_dump.c:715
Oct 1 10:06:46 app[worker] info /app/vendor/ruby-2.6.6/bin/../lib/libruby.so.2.6(rb_bug_context+0xe7) [0x7f2804a2c177] error.c:609
Oct 1 10:06:46 app[worker] info /app/vendor/ruby-2.6.6/bin/../lib/libruby.so.2.6(sigsegv+0x42) [0x7f2804b51422] signal.c:998
Oct 1 10:06:46 app[worker] info /lib/x86_64-linux-gnu/libc.so.6(0x7f28045bcfd0) [0x7f28045bcfd0]
Oct 1 10:06:46 app[worker] info [0x7f2804fa3000]

Thanks for the great gem.

Can't reproduce this issue, and in the meantime we have migrated to a completely different native extension for HTTP parsing (llhttp)


Add Results Tab to README

Display output from GENIE analysis in Results Tab

@korikuzma Would I pull from main in my terminal or in the pull request? I don't see an option to pull from main here.

@korikuzma Would I pull from main in my terminal or in the pull request? I don't see an option to pull from main here.

You need to resolve the conflicts

@korikuzma Can I resolve the conflicts using the web editor? This is what I see in the web editor:
<<<<<<< patient-graph
Results

Variant normalization allows patient data from AACR Project GENIE to be matched to normalized variants in the CIViC, MOA, and ClinVar knowledgebases.
Running Notebooks in Visual Studio Code (VS Code)
VS Code is a lightweight source code editor for Windows, Linux, and macOS.

Download VS Code here
Open a notebook and click Select Kernel at the top right. Select the option where the path is venv/3.11/bin/python. See here for more information on managing Jupyter Kernels in VS Code.
Run the notebooks

Analysis with macOS Environments
These notebooks were run using these macOS specs:

Model Year
CPU Architecture
Total RAM
Hard drive capacity

2019
2.6 GHz 6-Core Intel Core i7
32 GB
1 TB

2021
M1 Pro
32 GB
1 TB

main

I think this is my first time resolving a merge conflict so I wasn't sure where I would move the results section to?

@jarbesfeld ask @wesleygoar
Docs on resolving conflict in GH: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github

Am I being asked a question or just doing a review? @jarbesfeld

@wesleygoar I think review. I think I fixed the merge conflict

@jarbesfeld was asking "I wasn't sure where I would move the results section to?" @wesleygoar

@korikuzma I think this is probably a simple question, but after resolving merging conflicts, how would I pull in the latest changes to my local branch? I tried git pull on my patient-graph branch, and got, where the README was unchanged:
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> patient-graph

@jarbesfeld asked "I wasn't sure where I would move the results section to?" @wesleygoar

@jarbesfeld you can either keep results where it is or move it all the way to the top section and say something like, "After running these notebooks users will be able to create figures such as this that demonstrate the results of this analysis."

@jarbesfeld if you move to top put it in this section.

@korikuzma I think this is probably a simple question, but after resolving merging conflicts, how would I pull in the latest changes to my local branch? I tried git pull on my patient-graph branch, and got, where the README was unchanged: Please specify which branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> patient-graph

@jarbesfeld did you try running any of those prompts?

 @jarbesfeld if you move to top put it in this section.

@wesleygoar I think this is a good "hook"

@korikuzma I tried running the first command, but I was unsure what would go in . I know  would be patient graph.
@wesleygoar I can move results to the top

@jarbesfeld or @korikuzma can you please add this statement above the line 7. The result comes sharply out of the blue without any context.
"After running these notebooks, users will be able to create figures such as this that demonstrate the results of this analysis."


Fire user events

I'm proposing this as a solution to https://github.com/AsterNET/AsterNET/issues/24 and https://github.com/AsterNET/AsterNET/issues/96 where user event don't get fired.

Thanks for the quick reply.
This change becomes more readable when you review the file or in a split view
Basically there are 2 TryGetValue calls to the registered handlers. The first one declares the out currentEvent and it attempts to find it by name. If handler doesn't exist, currentEvent is null. In that case, the second call to TryGetValue attempts to find handler for UserEvent if that doesn't find a handler, we don't go into the if block.
However, if any of two succeed, then the value of currentEvent is always a handler. Let me see if I can make it more readable tomorrow.
P.S. My attempt to fix this with as least changes as possible made it unreadable. Apology for that. We are already using it and it is working for sure.

This change becomes more readable when you review the file or in a split view

You are right, I didn't see it was an out there and that the first if was removed.
I should just avoid reviewing code on my code during lunch breaks.
I have no way of testing this, but looking at it you definitely made it neat.

You are right, I didn't see it was an out there and that the first if was removed. I should just avoid reviewing code on my phone during lunch breaks.

No worries, I guess it comes with maintaining open source projects.

TL;DR
Without this commit, I couldn't get user event handlers to get fired while normal asterisk event handlers got fired as expected.
With this commit, asterisk event handlers and user event handlers get fired without any errors (in Diagnostics log).
What happened:
I'm trying to get a custom event CustomQueueEvent to get fired when asterisk emit it.
I followed the explanation of UserEvent here and got to the following:
var conn = new ManagerConnection("ip", "user", "pass");
// Where asterisk event is UserEvent: CustomQueue
conn.RegisterUserEventClass(typeof(CustomQueueEvent));
conn.DeviceStateChanged += (sender, e) => handler.HandleEvent(e);
conn.UserEvents += (sender, e) => handler.HandleUserEvent(e);
conn.Login();

DeviceStateChanged gets fired as expected. The only way to get the CustomQueueEvent is to set conn.FireAllEvents = true and then handle conn.UnhandledEvent += (_, e) => {...} (as one of the issues in my comment suggests as work around).
I used the master branch of the lib in my application and debugged it. It turned out that event.Name.GetHashCode() as resolution to event handlers in internalEventHandler, forgets that custom events have a different naming convention.
This PR checks that different naming convention as well. I've been running with this commit for 2 days and see no issue. If anything get's reported and I miss it, please mention me and I'll give my best to fix it.


False positive on library akka-stream-kafka_2.12-0.19.jar

False positive on library com.typesafe.akka:akka-stream-kafka_2.12:0.19 - reported as cpe:/a:akka:akka:0.19
<dependency>
    <groupId>com.typesafe.akka</groupId>
    <artifactId>akka-stream-kafka_2.12</artifactId>
    <version>0.19</version>
</dependency>

Akka defines several separate modules, which don't follow the numbering scheme of Akka proper. Another is com.typesafe.akka:akka-persistence-cassandra:0.83. There are others but they don't seem to share the same group, so they probably won't be false positives.

These specific FP have been patched - but like similar libraries with a ton of related dependencies a better strategy needs to be implemented...


Other exceptions in the standard library

Some modules in the Python standard library have their own exceptions, such as decimal or turtle. After the basic exceptions are included, it might make sense to include such exceptions as these modules might be used by beginners.  In particular, the turtle module would like benefit from having translations.
Please add your own examples from the standard library as a comment to this issue.

I just wanted to let you know that I intended to achieve similar goals in my Thonny IDE:

Currently the results can be considered proof-of-concept. I believe it makes sense to gather community efforts around a more general library (like friendly-traceback or pyta), which could be used by many tools.
Here are my efforts so far:

https://files.realpython.com/media/Screenshot_2018-10-20_<IP_ADDRESS>f3845020f38.png
https://github.com/thonny/thonny/issues/458
https://github.com/thonny/thonny/issues/344
https://github.com/thonny/thonny/blob/master/thonny/plugins/stdlib_error_helpers.py

Are you familiar with PyTA project?

Thank you very much: I did not know that something like this was already included in Thonny. Parts of my plans included looking at the possibility of including friendly-tracebacks in Thonny - I understood it supported a plugin architecture and thought this to be the way to possibly include friendly-tracebacks, but I never looked closely.
I was not aware of PyTA - I will definitely need to look at what they are doing in more details.
I (obviously!) completely agree with your comment about focusing on a more generic library that could be used in many environments.  This is why I started from the ground up with something that worked using a simple REPL, hoping that it would be used eventually by Thonny, Mu, etc.
While I have absolutely no personal need to go  beyond providing explanations in English, I am determined to make something that is designed from the start with internationalization in mind, with all explanations available in as many human languages as possible.
Thank you very much for this additional information.
= = =
Is there anything that I need to be aware that might prevent friendly-tracebacks from being usable in Thonny? Did you happen to see anything in the existing code that could be problematic and would need to be adjusted?

Here are some points to consider.
Number of possible causes.
I looked at analyze_syntax.py. If I understood correctly, it only proposes one possible cause of the error (the most likely). This doesn't prevent it from being usable in Thonny, but Thonny's assistant is able to list more causes allowing user to expand any of them to get more details. Thonny's implementation assigns weights for causes and may skip displaying lower weight causes if there exists a cause with big enough weight.
Verbosity
I like the idea of different verbosities. Thonny basically uses two levels of verbosity: initially only heading is displayed for each possible cause, but user can expand it to see detailed information.
Structure of the help content
For maximum flexibility, Thonny would like to receive the help content in structured form. Currently the GUI part gets something like this as input:
{
    'intro' : 'General explanation of the error message itself',
    'possible_causes' : [
        {
            'title' : 'eg. Did you misspell the variable?',
            'text' : 'longer text, may contain several paragraphs',
            'weight' : 3 // how likely this cause is
        },
        {
            ...
        }
    ]
}

I've created a simple reStructuredText renderer, so Thonny could make use of some simple formatting inside the longer explanation field. Some simple XHTML (eg. with <code>, <b>, etc. would be fine as well).

I was not aware of PyTA - I will definitely need to look at what they are doing in more details.

It looks like at the moment they only do static code analysis, ie. their goal is complementary to friendly-traceback's.

BTW, have you considered applying for PSF support for this work? See http://pyfound.blogspot.com/2019/04/update-on-python-in-education-proposal.html

Yes, I am aware of the potential support from the PSF. I submitted https://github.com/aroberge/avantpy/blob/master/psf/idea.md during the "request for idea phase". Soon after, I decided to actually put together all the little bits of code I had done related to AvantPy and push the project further.  After a while, I realized that what is now Friendly-tracebacks should probably be carved out and become a project of its own (to be used later by AvantPy). I do plan to submit something to the PSF - but I am not planning to request any funding for myself.

Regarding the structure of the help content and weight to likely errors: this is something I will have to think carefully about. I definitely do see the value in having something like this...  I am worried however about having something heavily predicated on using "nice/powerful" formatting tools: friendly traceback is currently usable from a standard REPL as can be seen here: https://aroberge.github.io/friendly-traceback/docs/html/design.html#verbosity   In this type of setting, where all the information is displayed all at once, with no "+" to click to expand, I think it would be counterproductive to present a "wall of text" with many different possible cause offered - hence the idea of trying to offer a single most likely cause for the error.
One goal I have for Friendly-traceback is to have it designed as a way for students to learn to decipher normal Python tracebacks and not be scared by them. For this to work, I could be wrong but I think it is important to retain some of the "look and feel" of normal Python tracebacks.
However, I am well aware that I am basing my design decisions on "gut feelings" with no feedback from actual students whereas Thonny has certainly benefited greatly from such feedback.

Hello folks! It's great to see this conversation happening... I love this sort of thing unfolding.
My 2c... ;-)
I'm -1 on formatting and +1 on working as plain text via stdout because this gives maximum flexibility and many tools can then benefit from all the work being done.
I like the idea of suggesting a single most likely error (thus avoiding a wall of text), but I also like the idea of a more nuanced "but it could also be..." approach. I'm not sure what the best way to bring these two approaches together... perhaps there could be a URL at the end of the traceback pointing at more detailed docs for the specific problem? Such more-detailed-docs in and of themselves would be a really useful resource, and if we can get the community on board to help write them, we're almost at a StackOverflow-ish modus-operandi. I believe it's important that folks learn the all-knowing-solitary-genius stereotype of a computer programmer is fake: experienced developers need to look things up all the time (and we'd be helping learners realise this). [NB this is a raw thought requiring refinement].
I love the idea of things looking like Python's own tracebacks. The feedback I've had from teachers about Mu suggests that they like the "it's like the real thing, but simpler/friendlier" approach since it acts as a stepping stone to the eventual goal of Python fluency. Being able to decypher tracebacks is definitely a skill to be learned and one my own teaching experience often bumps up against -- many of the teachers I've worked with admit that they only see something like:

...when presented with a traceback. Furthermore, they also admit they don't want to appear as if they don't know what they're doing when put in a situation where a kid is asking, "my code broke, what should I do now?". The friendly-tracebacks approach is, I believe, a really useful pedagogical tool for both teachers and learners. (As in, the answer to the kid's question is probably, "I don't know, but let's look at what the traceback says...").
As always, the usual caveats about raw thoughts needing refinement apply. All feedback, constructive critique and ideas most welcome too.
Once again, it feels great to see this sort of conversation happening..!

I've updated the design document (https://aroberge.github.io/friendly-traceback/docs/html/design.html) to incorporate some ideas mentioned here. I'll likely need to revisit this document again soon to incorporate more feedback - including some received previously on what Exceptions should be covered, etc.
Regarding the formatted vs plain text: I think that both can be accommodated. Just like it is currently possible to change the output from sys.stderr used by default to some other custom stream, it might be doable to have the information processed internally in some "structured form" and output, by default, as simple nearly unformatted text as it is currently done. However, some other program could replace the "plain text formatter" by its own.
That being said, I think I need to focus on the short term on adding more cases covered by Friendly traceback so that it could be useful enough to be used by test groups that would provide feedback.  That's what I was planning to do today, but the information provided on Thonny (and PyTA) was too good to ignore.

:+1: :smile:

First, I definitely agree that stdout is useful medium for presenting such information and I see how it brings along different requirements compared to GUI tools. I was just hoping that the ability to get all possible causes from a lower level API wouldn't complicate the library design too much. This way the GUI-s and CLI-s can present different amount of information. I also agree that presenting single most likely cause in CLI may be the best option (unless two causes are equally probable).
About the structuredness of the help text -- it is not a strong requirement for Thonny. Separate title and body would be convenient, but I don't mind showing the first line of the text initially and rest of the text when the user clicks "+"-mark. Also the formatting markup -- nice to have from Thonny's perspective (and easy to strip in CLI context) but not too important.
About the weights of the causes -- these may be useful even when only single cause is shown to the user. For example, in case of a NameError, the relative likelihood of a misspelling and a missing import can change depending whether the bad name looks like another name in the code or is defined in a widely used module. In other words dynamically calculated weights may give better results than statically ordering possible causes.
I agree that the tool should not hide the real life from the user (although sometimes I'd rather try to change the real life instead of offering help for coping with it). That's why I left the real tracebacks intact in Thonny and presented error interpretation in a separate part of the screen. I'm not sure whether this helps or hinders user's ability and motivation for learning to decypher tracebacks ... Anyway, I think we should not confuse two topics here -- understanding tracebacks in general and being able to see possible causes in the specific error condition. Thonny's Assistant is only (or mostly) concerned with the latter and I'd say the latter is the hard part.

Another thing to consider -- who are the users we are targetting? "Beginners" is definitely too broad...

Is Python their first programming language?
Do they want to or have to learn programming?

My teaching experience comes from university setting and MOOC-s, where people usually want to learn programming and understand the underlying principles, even if it is very hard for them. They wouldn't mind reading through different possible causes for the error and they would find pride in getting rid of the training wheels. At the same time, year by year I see more people who agree to learn programming only as long as it is easy. They are usually more loud than the people who accept hard work :) Therefore I'm worrying about oversimplifying things to please this group.

@aivarannamaa +1 on teasing out the meaning of "beginner".
For Mu it's definitely more a case of Python as a first (text based) programming language for folks who both want and (sometimes) have to learn (such as kids in UK schools).
I completely agree with you about oversimplification. This is why Mu attempts to ape "the real thing" in two ways: it's simple to facilitate accessibility to learning but without hiding the fact that, you know, coding requires effort and can be hard. :-) Programming isn't easy... we'd be doing learners a disservice if we're hiding this fact. I speak about this in my PyCon talk from last year's education summit, the URL of which I don't have right now.... (easy to Google though).

@aivarannamaa Please see issue #10
I have implemented a simple dict-based structure for traceback information. This is simply based on what existed previously in friendly-traceback, which means identifying a unique cause for a given exception unlike what is done in Thonny. In theory, it should be possible to extend the information obtained from a traceback and go beyond what I am currently doing.

For UnboundLocalError this structure seems sufficient. I'm still not sure whether bringing out single possible cause is sufficient in all cases.
Anyway, it's probably too early to expect final data structures and API-s -- we'll see it more clearly when more exception explainers get implemented.

It occurred to me that even UnboundLocalError may be caused by different mistakes. Let's consider this program:
def sum_numbers(numbers):
    totalSum = 0 # note the spelling!

    for x in numbers:
        total_sum += x

    return total_sum

total_sum = sum_numbers([1,2,3])
print(total_sum)

Suggestion about adding a global to the program probably just confuses the learner.
Even if we could always correctly predict the correct suggestion, it may be useful to present more options so that the user is forced nudged to think about their specific situation and what they want to achieve.

@aivarannamaa I am torn:
On the one hand, I most definitely see the value of presenting more options and have users think about their specific situation, as you suggest and as is done in Thonny. On the other hand, if the options presented are not leading to the right solution [1] , I think this might confuse the users, most of whom would have difficulty "thinking outside of the box" and only consider the suggestions offered since they most often would be "right".
Perhaps, the way to go forward is as follows: friendly-traceback attempts to identify as many possible cause as it can, like Thonny does, with a relevance factor.  In the default mode (e.g. in an REPL), it only suggest the most likely cause of error. However, programs like Thonny that can present the information in better ways could use the full information available from friendly-traceback. So, the idea of considering more than one cause is definitely worth thinking about. However, for now, I think I will focus trying to include as many examples as possible with looking at only including the "most likely cause". Once I have included at least all the examples that can be dealt with by Thonny, I might be in a better position to see how I could incorporate multiple causes in a useful way.
Side note: I put the documentation in a separate repository and have significantly changed the design document, including some information about Thonny, and updated the site just a few minutes ago: https://aroberge.github.io/friendly-traceback-docs/docs/html/design.html
[1] For example, I would never have thought of the example you gave and would definitely not have included it as a choice.

Perhaps, the way to go forward is as follows: friendly-traceback attempts to identify as many possible cause as it can, like Thonny does, with a relevance factor. In the default mode (e.g. in an REPL), it only suggest the most likely cause of error. However, programs like Thonny that can present the information in better ways could use the full information available from friendly-traceback.

Sounds good!

Greetings!
Forgive my putting in my own two cents - I am hoping that a bit of "gut-level" feedback from someone who doesn't necessarily eat, drink, sleep, and breathe programming / Python programming might be useful.
First, though not a professional programmer, I do have at least some familiarity with programming.
Second, my real "hot button" is the user interface and how effectively a software package interacts with its users.  During a long and winding career as a Software QA maven, usability and the UI were my main emphasis.
Assuming that the target audience for something like this is either rank beginners, or people like me, who - though not raw recruits - may not be God level programmers in the language in question.
Based on these criteria - providing the best, most relevant and effective information possible - my vote goes to the "Thonny Assistant" presentation.

It leaves the original error messages intact.
It provides a contextual analysis of what the problem might be, and what might have caused it.
It provides a range of possibilities based on the error message(s) shown.
I like this much better than a simple "do this!" and hope it works.

It's my own humble opinion that a presentation like this provides the maximum amount of useful information in the smallest amount of space and would be the most effective way of guiding the student.
What say ye?
Jim "JR"

@jharris1993 I agree with you. The issue you are commenting about was created at the very beginning of this project - which, in spite of a fair bit of progress, is still in its enfancy. Since then, a fair bit has happend and now Thonny can make use of friendly-traceback; see https://aroberge.github.io/friendly-traceback-docs/docs/html/thonny.html if you have not seen it already.
Friendly-traceback is intended to be a "low level, UI agnostic" diagnostic tool that provide information (available in many human languages) which can be used by editors such as Thonny and Mu.

Closing this issue as the discussion has ended many months ago.
Individual items discussed here can be reopened as separate issues whenever needed.


Fix DefaultDecomposer.dataSmResp() and SMPPServerSession.processDataSm()

DefaultDecomposer.dataSmResp() should always read message_id (mandatory for data_sm_resp) and optional_parameters. Not just when command_status is 0.
SMPPServerSession.processDataSm() should catch and throw ProcessRequestException to preserve original errorCode.

Thanks for the PR!


community: add ProjectGutenbergRetriever

Description: This PR adds a user-friendly abstraction for the ProjectGutenbergRetriever class. The PR covers the implementation, notebook and tests.

Issue: N/A

Dependencies:

requests: Used for making HTTP requests to Project Gutenberg.

Twitter handle: N/A

@ovuruska I am going to close this PR, please free to re-open if you'd like to propose a client for project-gutenberg

Alright @eyurtsev . Thanks for noticing


added some API entities

hello
I'm using ruby-2.4 and rails 5.0.1, but I could not use your newest version of gem
because 'json' 1.8.1 is not capability with ruby-2.4.
I have just added some API entities and updated dependency.

Could use the update as well, need compatibility with newer versions of ruby and rails.


Use local_inner_macros to remove the need to import 'sel_impl' when importing 'sel'

Fixes #69. As far as I can tell the weird __objc__* macros are needed as the rewrite to $crate:: happens for all crates and there is no opt-out.

I need to read up more on the macro changes, but... I'm really surprised that the proper solution is to redefine all of the std macros in every crate!?

This is if you want to remain compatible with old versions. You can just objc::sel_impl! inside the macros and it'll work but only as of when that's stable.
Note I'm not 100% here but it seems to be what others are doing.

(saw the link in the other issue) I think the idea is that this will only be required transitively - since you can update rust minor versions without breakage using 2015 edition, hopefully everyone will update and the $crate:: solution will be usable in the end.

Thank you for your work here and helping me understand the macro changes! :)
At this point my plan is just to publish a version 0.3 of this crate which drops support for Rust 2015. I've merged #76 which switched the macros to use the $crate prefix, and in 39a6d52 the sel_impl! macro is actually removed entirely. So I believe this change is no longer necessary and I'll close out this PR.

This is still an issue. When exporting a macro that calls send_msg!, the compiler fails to find the sel! macro unless the old style #[macro_use] extern crate objc is used.

Thanks for the reminder @aloucks, sorry for any confusion my comment caused. The issue is fixed in master, but I have not yet published a new version. The next version is going to be 0.3, the first breaking change to objc in 3 years, so I'm taking things a little slow to make sure it puts this crate in a good position for another 3 years ;)


A couple issues with new markdown readmes for resources

As the defacto open source git repository service, the appearance of README.md files on GitHub would be a good standard to compare our new markdown rendering system.  When doing so, using a example projects https://github.com/chjj/ttystudio/blob/master/README.md and https://github.com/Yoast/wordpress-seo/blob/trunk/README.md, a couple notable differences become evident.

Code blocks are not supported in our system (see video 014-1)
Multi-level unordered lists are not supported in our system (see video 014-1)
New lines don't work the same way in our system (see video 014-2)

014.zip

Initially we wanted to implement our markdown exactly like GitHub's, but while we were searching for options, the only resources we found for GitHub's was an API (https://developer.github.com/v3/markdown/). We chose our own server side solution instead in the form of a Django package based of daringfireball's (https://daringfireball.net/projects/markdown/basics) in order to avoid making requests to a 3rd party API.
I want to point out that if we want to improve our markdown to that of GitHub's, using GitHub's API is the only way I am familiar with. I am not sure if we can deploy our own version of it, or if there's any sort of quota for using the service.
If someone knows more I'll be happy to read on.

3. New lines don't work the same way in our system (see video 014-2)

The effort to rewrite the open source product incorporated for README capability has an impractical cost/benefit return. At the least, new lines are supported, just via the special methods provided by the library. For example:
\n\n

or depending on your layout
"  \n

\n  "

Others likely supported or desired visual output possible. I think this GH Issue should be closed with no further action.

closing: stale, resolved


add VEnhancer please

VEnhancer improve the quality of CogvideoX video https://github.com/Vchitect/VEnhancer
Is it possible to add it to the Comfyui workflow ? thanks

I did make nodes for it before, haven't had time to properly test it, it works but is pretty hard to choose correct settings: https://github.com/kijai/ComfyUI-VEnhancer

Ok thanks !


MissingResponsePrototypeException thrown when using http-middleware 0.5.0 callable middleware

The changelog says

Essentially, this means you can drop this package into an application targeting either the 0.4.1 or 0.5.0 versions of http-middleware, and it will "just work".

so I updated my app to use http-middleware to 0.5.0 and get this exception with zend-stratigility 2.1.0:

Fatal error: Uncaught Zend\Stratigility\Exception\MissingResponsePrototypeException: Cannot wrap callable middleware; no Zend\Stratigility\Middleware\CallableMiddlewareWrapperFactory or Psr\Http\Message\ResponseInterface instances composed in middleware pipeline; use setCallableMiddlewareDecorator() or setResponsePrototype() on your Zend\Stratigility\MiddlewarePipe instance to provide one or the other, or decorate callable middleware manually before piping. in zend-stratigility/src/MiddlewarePipe.php on line 250

Here is a small example to reproduce the error:
<?php declare(strict_types=1);

use Interop\Http\Server\MiddlewareInterface;
use Interop\Http\Server\RequestHandlerInterface;
use Psr\Http\Message\ServerRequestInterface;
use Zend\Diactoros\Response\TextResponse;
use Zend\Diactoros\Server;
use Zend\Stratigility\MiddlewarePipe;
use Zend\Stratigility\NoopFinalHandler;

require __DIR__ . "/vendor/autoload.php";

$app = new MiddlewarePipe();

// Does NOT work, triggers an exception
$app->pipe(function (ServerRequestInterface $request, RequestHandlerInterface $handler) {
    return new TextResponse("Hello, world!");
});

// It works fine with classes though
$app->pipe(new class implements MiddlewareInterface {
    function process(ServerRequestInterface $request, RequestHandlerInterface $handler) {
        return new TextResponse("Hello, world!");
    }
});

Server::createServer($app, $_SERVER, $_GET, $_POST, $_COOKIE, $_FILES)
      ->listen(new NoopFinalHandler());

composer.json
{
    "require": {
        "http-interop/http-middleware": "0.5.0",
        "php": "^7.1",
        "psr/http-message": "^1.0",
        "zendframework/zend-diactoros": "1.6.0",
        "zendframework/zend-stratigility": "2.1.0"
    }
}

Fixed with #118, with a release in 2.1.1.


The name "azos-use-vm-web02" is above 15 char policy

You might want to expand the limit in Azure VM naming policy in order for the name "azos-use-vm-web01" to work. The current policy doesnt not validate this name as it is too long. Why not expand the naming policy to 64 char?

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

ID: 0588ab87-69d9-9641-9d96-fa46f7c71b54
Version Independent ID: e5e6a8d4-04aa-eeec-16d4-e82fb0fd9f5c
Content: Example Azure Infrastructure Walkthrough
Content Source: articles/virtual-machines/windows/infrastructure-example.md
Service: virtual-machines-windows
GitHub Login: @cynthn
Microsoft Alias: cynthn

@geirivarjerstad Thanks for your comment. We are actively investigating and will get back to you shortly.

@geirivarjerstad 15 char is the max limit for windows vms only.
For linux vms max limit is 64 characters

@geirivarjerstad is there any update

I will close this out for now. If you need additional help please let me know and we can reopen and continue.


Add support for non-root user service execution in Dockerfiles

Currently, we run all our images with root user inside a Docker container. This could lead to potential security leaks. It is best practice to avoid running containers as root.
Solution:
Add non-privileged user, e.g. streampipes to Dockerfiles.
Imported from Jira STREAMPIPES-286. Original Jira may contain additional context.
Reported by: wiener.

I worked on it in branch #SP-454.
The problem is the volume backend in the backend service. We need to adjust the read/write rights in a way that is backwards compatible and workds for both kubernetes and docker deployments.
I created a user with and withoud a UID but I am not sure which is the best way.
If you have any experience with docker non-root images and volume mapping, please let me know so that we can discuss a solution.
Here is the solution I came up with:

Create a new user and adjust the ownership in the Dockerfile
For the update, we use a script that adjusts the ownership of the folder recursively on container startup
We need to remove the asset location variable from consul


Update Cicero Triangle

Feature Request 🛍
The Accord Project triangle, which illustrates Cicero technology, is a bit out of date in regards to TemplateMark
Possible Solution

We need to update the diagram (and everywhere it is shown) to replace CiceroMark with TemplateMark
We need another triangle for documents (instances of the template) where CiceroMark will be in the bottom left corner

Hi team - I have a question about the second diagram that you've mentioned. Apologies in advance if this doesn't make sense.
As I understand it, the suggestion is that we need a second triangle for documents (instances of the template) where CiceroMark will replace TemplateMark in the bottom left corner. However, won't any instance (especially one with CiceroMark) also need TemplateMark grammar in order to parse? If that's the case, shouldn't the diagram be a bit like this:

If you wanted to make the point even more clear, we could add some diagram along these lines to clarify how a document is created:

I want to work for this issue. Will you explain me again what to do

@Arvind644 this is a complex issue that will take some research to learn the context around all of AP's technologies. The link in the original post is a good starting point.

@Michael-Grover is there any update on this?

I'm wondering if we need the CiceroMark there. It makes the diagram more complex (and I feel we may need a diagram for contracts -- instead of templates -- down the road anyway, so we may have to change it then again).
So maybe just replacing CiceroMark by TemplateMark is good enough for now?

@jeromesimeon Is this good?

LGTM @Michael-Grover !


Pre-compiled ARM binaries

As a user, I would like to be able to download aarch64 prebuilt binaries so I can run Krustlet on 64 bit ARM devices (like Raspberry Pi).
Other notes:
We may also want to have an "openssl-less" ARM binary to make it easier to just drop in on an embedded device

Is there anything specific that blocks krustlet from being used in ARM32? I'm evaluating it for usage with a STM32F429 board with 2MB Flash and 192KB RAM

Right now it is a limitation of what wasmtime and wasm3 (the runtimes we are using) can compile to. I am pretty sure they only have the instruction sets for ARM64 (when they execute wasm). @bacongobbler is that correct?

wasmtime cannot be compiled to arm32 at this time due to https://github.com/bytecodealliance/wasmtime/issues/339. wasm3 should be able to run on an ARM device as per their README:

wasm3 runs on a wide range of architectures (x86, x86_64, ARM, RISC-V, PowerPC, MIPS, Xtensa, ARC32, ...) and platforms:

The tricky part will be building a hex file where you can run Krustlet on that STM32. That will likely require a custom provider. I would recommend looking into the AVR Rust project: https://github.com/avr-rust/

It looks like AVR Rust has been merged into core, so it should be much simpler to experiment with now! https://www.avr-rust.com/#installation-rustup

Didn't understand the part about AVR-rust, isn't AVR just another kind of board such as STM32? For the latter there is already stm32-rs. About the custom provider, I was more thinking about building a runtime based on RTIC, which in turn is based on Ada Ravenscar, and it has low footprint while allowing concurrency. Then I'd like to integrate wascc o something similar, but no-std and maybe more minimal, as WASM runtime and finally krustlet

Sounds interesting. Let us know what you find out!


Plex Media Source getting wrong IP Address

I have PLEX running in a container on my UNRAID server and I have ErsatzTV running on my windows machine.
This setup has been working really well for me for the past couple of months but recently I moved and am unable to remotely use my Plex server anymore.
This isn't a problem as I usually just watch on my home network but now that I am using direct local connections to Plex, ErsatzTV has started using the container IP address on my UNRAID machine (which is not exposed to the network as I port forward the container port to the server IP).
Would love it if there was a way I could manually set up the IP address for my plex server to point to the UNRAID server with port forwarding.

ETV will test all advertised Plex addresses on startup, and shouldn't use an address where Plex can't be reached. You can either add more addresses in Plex's settings, or you can ensure that DNS rebinding works for plex.direct so they resolve internally. Plex exposes all potential internal IPs that way.


Add ability to bookmark an extension and sync the bookmarks

Add the ability to star / favorite extension and sync to vscode account.

Sync is already previewing in the Insiders build.

Sync is already previewing in the Insiders build.

star / favorite supportting, thanks

Can you please elaborate what do you mean by star / favourite?
As said we already support Sync in our insiders and can you please try that and let us know if that suffice your requirement?

Can you please elaborate what do you mean by star / favourite?
As said we already support Sync in our insiders and can you please try that and let us know if that suffice your requirement?

"star / favourite" is somewhat like that in web brower, which allow we mark and remember those extensions that we consider is useful and easily to install them in a new VS Code on new PC. We can find back and install them as long as we login our VS Code account.
Did I make it clear?
I don't think that the Sync in insiders VS Code meet this requirement, does it?

I see. you want to bookmark an extension.


bearer parameter from the Import Manifest is not used

Hello,
The "Import Manifest" tests do not seem to parse the "bearer" parameter (parameter:udsData.part:importAccessToken) when making requests.
https://github.com/inferno-framework/uds-plus-test-kit/blob/4999db590f7cee5d3595051fac8ab44cc3783c75/lib/uds_plus_test_kit/manifest_tests/read_data_test.rb#L40-L47
As a result, URLs that require authentication cannot be tested.

Hi @jwjahns, unfortunately this Inferno kit is not meant to test any of the authentication steps of the IG's workflow. Rather, it is simply meant as a structure-conformance validator for the resources. Because of this, all provided URLs must be public in order to be accessed.

This doesn't make sense to me.
A big part of the UDS+ workflow is if a submitter has a secured endpoint (which will probably be the norm), they need to send in some way of having HRSA grab their Bulk Files. I think it also could be argued that that is part of structure-conformance.
But at the end of the day, what this boils down to is - to verify that UDS+ works, hospitals are generally going to have to connect with HRSA's sandbox. If this can successfully process / request data from secured URLs, that's one fewer thing that needs to be worked out when each hospital attempts to connect to HRSA for onboarding.


Can devenv generate docker image from shell environment?

Hi, I'm using devspace to manage kubernetes app (it swaps pod with development pod from specified docker image) and was wondering if I could use devenv to generate development docker images. I thought that devenv container shell have to be generating some image, but the command doesn't work for me.

Any idea what might be going on here? And another question - could devenv support generating images directly?
Here's my devenv.nix in case u need it
{ pkgs, ... }:

{
  env.GREET = "devenv";

  packages = [ pkgs.git pkgs.hello];

  scripts.hello.exec = "echo hello from $GREET";

  enterShell = ''
    hello
  '';

  languages.nix.enable = true;
  languages.rust.enable = true;
  languages.typescript.enable = true;

}

No longer need this feature.


"Invalid or unknown key" when deploying AWS WAFv2 ACL rule

Describe what happened
Hi folks,
I'm setting up AWS WAF v2 which I previously deployed via AWS CDK.
I'm getting error:
'WebAcl' has a problem: Invalid or unknown key. Examine values at 'WebAcl.rules'.

I found out it's caused by this rule:
const cognitoRule = {
  name: 'CognitoSignInRateLimit',
  priority: 2,
  action: { ... },
  visibilityConfig: { ... },
  statement: {
    rateBasedStatement: {
      ...
      scopeDownStatement: {
        andStatement: {
          statements: [
            {..}
            {
              notStatement: {
                statements: [
                  {
                    orStatement: {
                      statements: [
                        { ... },
                        { ... }
                      ]
                    }
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }
} satisfies aws.types.input.wafv2.WebAclRule

When I change it like this:
const cognitoRule = {
  name: 'CognitoSignInRateLimit',
  priority: 2,
  action: { ... },
  visibilityConfig: { ... },
  statement: {
    rateBasedStatement: {
      ...
      scopeDownStatement: {
        andStatement: {
          statements: [
            {..}
            {
              notStatement: {
                statements: [ {} ] // 👈 Changed here
              }
            }
          ]
        }
      }
    }
  }
} satisfies aws.types.input.wafv2.WebAclRule

Then the error disappears.
Any clue? Is it some bug in Pulumi/Terraform? Because the code seems to be valid both according to TypeScript types and AWS docs.
Sample program
import * as aws from '@pulumi/aws'

const whitelist = new aws.wafv2.IpSet('Whitelist', {
  name: 'my-whitelist',
  ipAddressVersion: 'IPV4',
  scope: 'REGIONAL',
  addresses: []
})

const cognitoRule: aws.types.input.wafv2.WebAclRule = {
  name: 'CognitoSignInRateLimit',
  priority: 2,
  action: {
    block: {}
  },
  visibilityConfig: {
    sampledRequestsEnabled: true,
    cloudwatchMetricsEnabled: true,
    metricName: 'CognitoSignInRateLimit'
  },
  statement: {
    rateBasedStatement: {
      aggregateKeyType: 'IP',
      limit: 100,
      scopeDownStatement: {
        andStatement: {
          statements: [
            {
              regexMatchStatement: {
                regexString:
                  'AWSCognitoIdentityProviderService.InitiateAuth|AWSCognitoIdentityProviderService.RespondToAuthChallenge|AWSCognitoIdentityProviderService.ForgotPassword|AWSCognitoIdentityProviderService.ConfirmForgotPassword|AWSCognitoIdentityProviderService.SignUp|AWSCognitoIdentityProviderService.ConfirmSignUp|AWSCognitoIdentityProviderService.ResendConfirmationCode',
                fieldToMatch: {
                  singleHeader: { name: 'x-amz-target' }
                },
                textTransformations: [{ priority: 0, type: 'NONE' }]
              }
            },
            {
              notStatement: {
                statements: [
                  {
                    // The issue comes from this section👇
                    orStatement: {
                      statements: [
                        {
                          ipSetReferenceStatement: {
                            arn: whitelist.arn
                          }
                        },
                        {
                          byteMatchStatement: {
                            searchString: 'some-value',
                            fieldToMatch: {
                              singleHeader: {
                                name: 'some-header'
                              }
                            },
                            textTransformations: [
                              {
                                priority: 0,
                                type: 'NONE'
                              }
                            ],
                            positionalConstraint: 'EXACTLY'
                          }
                        }
                      ]
                    }
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }
}

new aws.wafv2.WebAcl('WebAcl', {
  scope: 'REGIONAL',
  name: 'my-waf',
  defaultAction: {
    allow: {}
  },
  visibilityConfig: {
    cloudwatchMetricsEnabled: true,
    metricName: 'my-waf',
    sampledRequestsEnabled: false
  },
  rules: [cognitoRule]
})

Log output
Diagnostics:
  aws:wafv2:WebAcl (WebAcl):
    error: aws:wafv2/webAcl:WebAcl resource 'WebAcl' has a problem: Invalid or unknown key. Examine values at 'WebAcl.rules'.

Affected Resource(s)
aws.wafv2.WebAcl

Output of pulumi about
CLI
Version      3.142.0
Go Version   go1.23.3
Go Compiler  gc

Plugins
KIND      NAME    VERSION
resource  aws     6.61.0
resource  aws     6.56.0
language  nodejs  unknown

Host
OS       darwin
Version  15.1.1
Arch     arm64

This project is written in nodejs: executable='/Users/xxxxx/.nvm/versions/node/v20.11.0/bin/node' version='v20.11.0'

Pulumi locates its logs in /var/folders/0c/m2l8t31d55xdhxj3cx63h62r0000gr/T/ by default
warning: Failed to get information about the Pulumi program's dependencies: could not find /Users/xxxxx/projects/package.json. Please include this in your report and run pulumi about --transitive" to get a list of used packages
warning: Could not access the backend: read ".pulumi/meta.yaml": blob (key ".pulumi/meta.yaml") (code=Unknown): NoCredentialProviders: no valid providers in chain. Deprecated.
        For verbose messaging see aws.Config.CredentialsChainVerboseErrors

Additional context
Original Slack thread: https://pulumi-community.slack.com/archives/CJ909TL6P/p1733156609936739
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Hey @FilipPyrek, thanks for the great repro! I was able to reproduce it right away.
The problem here is that WebAclRule only allows three levels of nesting. I'm sorry that this is not immediately obvious in the docs, it's currently only mentioned in the description of the ruleJson input property. You can use ruleJson as a workaround, it allows arbitrary nesting but does not have type safety.
I'll take an action to update the docs with this info and also see if we can improve the types here so that they reflect this limitation.
Additionally I'm gonna investigate if we can emit a better error message in this case. Pointing to 'WebAcl.rules' does not help in understanding the problem.

Hi @flostadler thanks for such a quick response. 🙇♂
Where the limit comes from? Pulumi? Terraform? AWS?
Because as I mentioned, it works for us well, when deployed via AWS CDK.
Also the Pulumi's TypeScript types (inputs.wafv2.WebAclRule) don's show any error when having the nested levels as I provided in the repro.
So I assume it's Terraform provider's issue?

Yes, you're right @FilipPyrek, it's a Terraform limitation that we inherit. This is also why the types do not show this limitation (which is painful, I fully agree).
Alternatively you could use the wafv2 resources from the AWS native provider: https://www.pulumi.com/registry/packages/aws-native/api-docs/wafv2. Those are modeled better than their counterparts from pulumi-aws.


GitHub pages

Accidentally closed by pulling the updates from https://github.com/ultimate-comparisons/ultimate-comparison-BASE/tree/rewrite.

https://cryptocatalog.github.io/ultimate-crypto-comparison/


Please Help me in the installation

I tried to install this package more than twice but every time i got same issue. I installed this in
"php": ">=5.6.4",
"laravel/framework": "5.3.*",
I am installing this package in a fresh project. I followed same steps as they are mentioned. Database table successfully seeded into the database. I followed these steps:
1). First created a fresh project:- composer create-project --prefer-dist laravel/laravel blog
2). Then:- composer require tcg/voyager
3). then i configured my .env file for database connection,
4). Then added these points in app/config.php file under Laravel framework service provider : TCG\Voyager\VoyagerServiceProvider::class,
Intervention\Image\ImageServiceProvider::class,
5). Then at last: php artisan voyager:install
Please Help me in Installing this pacakge.

You need visit yourdomain.com/admin to login into voyager.

@fergthh Thanks


⚠ Bofrost.de has degraded performance

In 6cec267, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1181 ms

Resolved: Bofrost.de performance has improved in 43cbca9 after 6 minutes.


Opening about hides desktop

If we show a modal content, the desktop is hidden as long as the popup is open.

Now I'm checking if there are just popups open, if yes also display the desktoppanel. If there are no screens open display desktop, if there are screens open which are not popup display the normal screen and the popup if there are any


Fix author dates

Fixing the dates shown on the author profiles to be the correct amount of days.

Change config/utils/dates.js 'specificTimeSince(date)' which is only used in the components/Author/Profile/AuthorProfileHeader.tsx file so there shouldn't be any off-target effects

See Issue #137 https://github.com/ResearchHub/issues/issues/137

Before:

After:


Fix mismatch types

Running cargo build --release --feature selfupdate will have a mismatch type error in line 225 in src/bin/juliainstaller.rs. Just a small fix.

Perhaps it's a good idea to leave the rustfmt run as a separate PR, as that is a separate decision whether this repository should use standardized formatting. Other than that, LGTM.

Thanks, I fixed this is part of https://github.com/JuliaLang/juliaup/pull/512.


Currently unable to repro using Window 10, and ADS Insiders Build v1.24.0

I can repro this in mac


feature: add kernel-memory support in cli and ctrd

Signed-off-by: Allen Sun<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
This feature add kernel-memory support in cli part and containerd part.
Actually we have add KernelMemory in swagger.yml in https://github.com/alibaba/pouch/blob/master/apis/swagger.yml#L2676. Then in the API side, this field has been supported in the struct definition of Resource.
However in the daemon side, we have not set it in the LinuxResource of runc. Then there is no way to set kernel memory for PouchContainer.
This PR tries to fix that, and this pr did:

add kernel-memory flag in cli side;
deal kernel-memory in daemon side to insert it for containerd;
add kernel-memory checking in test case and refactor memory test case to add memory checking.

Ⅱ. Does this pull request fix one issue?

fix https://github.com/alibaba/pouch/issues/2716
Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
added
Ⅳ. Describe how to verify it
none
Ⅴ. Special notes for reviews
none

@allencloud any update here?

Could we kick the ball and make this move on? I think it will influence the @ireneYang 's scenario.
@fuweid


What is the reason for computing bounding box for data producer?

Hi,
I don't understand why you compute a bounding box for the data producer. In the paper you said because "the stochastic nature of training", but in some iteration of training, it is possible that the set of output "breaks" this over-approximation, no?
Thanks

Hi @LebronX,
Thank you for your interest in our work!
During training, we try to enforce equation 3 of our paper, namely that all similar points should get mapped at most delta apart in latent space. However, due to the stochastic nature of training, this may or may not hold after training (or during any iteration of training, for that matter). Thus, once training has been completed, we use MILP to compute the smallest l-infinity bounding box that provably contains all similar points in latent space.
Cheers,
Anian

Hi,
Thanks for the prompt reply!
I see. Can I understand this is because in some sense DL2 is doing "best-effort" training?
Thanks

Yes, DL2 empirically checks for constraint violations and adjusts the loss accordingly. However, since DL2 may not find all violations, we need to compute a provable over-approximation with MILP.

I see. Thanks for the answer!


build with python and numpy support

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@versatran01: Let me know if this looks OK to you. There's an import test to see that pyopenvdb can be imported in python :).

@tetov Thanks for doing this. This looks good to me, however, I'm not sure how to test this myself. If you've verified that his works then I'm happy to merge.

@tetov Thanks for doing this. This looks good to me, however, I'm not sure how to test this myself. If you've verified that his works then I'm happy to merge.

I've tested manually and there's an import test and now also a test creating a grid from a numpy array so I'm happy with test coverage for now :).


Fix a bug in CompareAndCopy.equals(); optimize performance

The fixed bug is pinpointed in the added test.

Performance

Before:
Benchmark               (size)  Mode  Cnt      Score     Error  Units
EqualsBenchmark.equals       1  avgt    5      7.992 ±   0.184  ns/op
EqualsBenchmark.equals      10  avgt    5     11.687 ±   0.643  ns/op
EqualsBenchmark.equals    1000  avgt    5    121.730 ±  11.028  ns/op
EqualsBenchmark.equals  100000  avgt    5  10674.055 ± 290.646  ns/op

After:
Benchmark               (size)  Mode  Cnt     Score     Error  Units
EqualsBenchmark.equals       1  avgt    5     7.260 ±   0.206  ns/op
EqualsBenchmark.equals      10  avgt    5    10.057 ±   0.286  ns/op
EqualsBenchmark.equals    1000  avgt    5   106.279 ±   5.983  ns/op
EqualsBenchmark.equals  100000  avgt    5  9476.547 ± 451.854  ns/op

It proves that safepoints and int vs long-counted loops make difference, although not as dramatic as I expected.
The benchmark is checked in https://github.com/leventov/memory-jmh-benchmarks

Coverage decreased (-0.03%) to 96.598% when pulling 7d5378fd12c8decd6307f6d21861245af69b1f26 on equals-changes into bedf853f919155ff749e925e38ff4d945afe9ccf on master.

Whenever I fix bugs and add tests Coveralls says that the coverage decreased and "rejects" the PR. It's kind of funny.

Coverage decreased (-0.03%) to 96.598% when pulling 62c1b2c on equals-changes into bedf853 on master.

This is a nuisance warning and I wish I knew how to set a higher tolerance than zero!  Nonetheless, coverage is a ratio. Changing either the numerator or denominator can affect the result.  So if you replace statements that were already covered with fewer covered statements the ratio of covered / total is smaller because you are subtracting the same number from both the numerator and denominator.

Thanks for finding that bug! And for the test! "Code not tested never works!"


Interpreter shutdown

Updates P4A and our use of work manager to prevent interpreter shutdown.
Fixes #132

Going to merge this without review to keep building on top.


fix openzeppelin dependency

closing as duplicate of https://github.com/bgd-labs/aave-token-v3/pull/27


User can add to cart 0 qty product

Current behavior
User can add to cart 0 qty product (with price 0), has noification 'Product has been added to the cart!" - but in Cart 1 product appears

Expected behavior
There should be no possibility to change qty of product on 0.
Steps to reproduce the issue

Open any Catalog page
Click on any product
On product page change qty on 0
Click Add to cart
Go to Cart

Environment details
https://test.storefrontcloud.io/
Additional information
I checked that user can also fill Qty field by negative number (after that the price displayed as negative.)
Issue also on mobile.

@ibugaj I'll take care of that

Tested - Issue solved. For now even if user try to fill qty manually, then he get notification "Quantity must be above 0" - thanks for this solution :)
@patzick It will be good add it also on Cart, because when user open cart and try to change qty manually then there isn't notification "Quantity must be above 0" and user can left 0 or for example -2 in qty field (but the price works like for one product, and if user go to checkout then system will correct quantity on 1)
In Cart:

In PDP:


Change DOCKERHUB_ID to DOCKER_HUB_ID

For the sake of consistency, please change all incidences of DOCKERHUB_ID to DOCKER_HUB_ID.

Can you please assign this to me @joewxboy

This issue is close by pr #4


Using TypeScript Lookup Types results in a Parsing error

I think I've narrowed down the issue to babel-eslint.
I've built out a (reasonably) minimal example and pushed it to a repo but the crux of it is this:

React
Webpack + Babel
TypeScript
ESLint + babel-eslint + @typescript-eslint

Within App.tsx I have:
// App.tsx
// ...

interface Foo {
  bar: string;
}

type Greeting = Foo["bar"];

// ...

And when trying to build eslint gives me the following error:
ERROR in ./src/App.tsx
Module Error (from ./node_modules/eslint-loader/index.js):

/Users/jay/dev/mvce-eslint-typescript-issue/src/App.tsx
  7:21  error  Parsing error: Unexpected token, expected "]"

   5 | }
   6 |
>  7 | type Greeting = Foo["bar"];
     |                     ^
   8 |
   9 | export const App = (): ReactElement => {
  10 |   const helloWorld: Greeting = "Hello, World!";

✖ 1 problem (1 error, 0 warnings)

Removing parser: "babel-eslint" from .eslintrc.js and removing enforce: "pre" from the eslint-loader block in webpack.config.js have so far been the only ways that I've found to suppress the error.
If you have any recommendations on where else I should post this issue then please recommend away.
I'm not that confident in my conclusion that the issue is in babel-eslint but it's a start 🤷♀
Appendix
// webpack.config.js
// ...
  module: {
    rules: [
      { test: /\.tsx?$/, loader: "awesome-typescript-loader" },
      { enforce: "pre", test: /\.js$/, loader: "source-map-loader" },
      {
        enforce: "pre",
        test: /\.(js|mjs|jsx|ts|tsx)$/,
        exclude: /node_modules/,
        loader: "eslint-loader",
        options: {
          configFile: "./.eslintrc.js"
        }
      },
      {
        test: /\.(js|mjs|jsx|ts|tsx)$/,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader"
        }
      },
      {
        test: /\.html$/,
        use: [
          {
            loader: "html-loader"
          }
        ]
      }
    ]
  },
// ...

// .babelrc
{
  "presets": ["@babel/preset-env", "@babel/preset-react", "@babel/typescript"],
  "plugins": [
    "@babel/proposal-class-properties",
    "@babel/proposal-object-rest-spread"
  ]
}

// .eslintrc.js
module.exports = {
  env: {
    browser: true,
    es6: true
  },
  globals: {
    Atomics: "readonly",
    SharedArrayBuffer: "readonly"
  },
  parser: "babel-eslint",
  plugins: ["@typescript-eslint", "react"],
  parserOptions: {
    ecmaFeatures: {
      jsx: true
    },
    ecmaVersion: 2018,
    sourceType: "module"
  },
  rules: {
    "max-len": [2, { code: 120, tabWidth: 2 }]
  }
};

// tsconfig.json
{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "node",
    "target": "es6",
    "jsx": "react",
    "sourceMap": true,
    "allowSyntheticDefaultImports": true,
  },
  "include": ["./src/**/*"]
}

I've got the same issue, did you figure out a solution?

I have the same issue, any ideas how to solve it? I'm trying to switch from @typescript-eslint to babel-eslint

Babel-eslint@10 does not support Typescript. Can you change eslint parser to @typescript-eslint/parser?
// eslintrc.json
{
  "parser": "@typescript-eslint/parser"
}

Thank you for the issue. Now that @babel/eslint-parser has been released, we are making this repository read-only. If this is a change you would still like to advocate for, please reopen this in the babel/babel monorepo.


Let properties having primitive types discriminate object unions

Main goal
The ultimate goal of this PR is to allow properties having primitive types discriminate object unions, even when there are no unit/literal types involved. Some examples of this are as follows:
interface State<Type> {
  state: Type;
}

interface UserName {
  first: string;
  last?: string;
}

const nameState = {} as {
  value: string;
  state: State<string>;
} | {
  value: UserName;
  state: State<UserName>;
}

// here 'value' is considered a discriminant property
if (typeof nameState.value === "string") {
  nameState.state satisfies State<string>;
} else {
  nameState.state satisfies State<UserName>;
}

declare const arr: [string, number] | [number, string];

// here 'arr[0]' is considered a discriminant property
if (typeof arr[0] === "string") {
  arr[1] satisfies number;
} else {
  arr[1] satisfies string;
}

type ToRet<T extends { a: string } | { a: number }> =
  T extends { a: string }
    ? string
    : T extends { a: number }
      ? number
      : never

// here by narrowing on 'a' we can type this function, thanks the new capabilities from PR #56941
function aStringOrANumber<T extends { a: string } | { a: number }>(param: T): ToRet<T> {
  if (typeof param.a === "string") {
    return param.a.repeat(3);
  }
  if (typeof param.a === "number") {
    return Math.exp(param.a);
  }
  throw new Error()
}

If a property was not previously considered discriminant, it will now be treated as one when the following conditions are met:

The property must be non-uniform; specifically, at least two constituents of the union must have it with distinct types.
The property must include at least one primitive type as a possible type.

Implementation details
isDiscriminantProperty were a cached boolean in the links of transient symbols, so the first attempt consisted of just adding inside the isDiscriminantProperty function (prop.links.checkFlags & CheckFlags.HasNonUniformType) && someType(propType, t => !!(t.flags & TypeFlags.Primitive)) as a fallback.
Unfortunately, I found a couple of problems with this.
The first one is related with tests/cases/conformance/types/union/contextualTypeWithUnionTypeObjectLiteral.ts:
var objStrOrNum3: { prop: string } | { prop: number } = {
    prop: strOrNumber
};

The above assignment must fail (you can find the reason in that conformance test), but considering prop as a discriminant field changed the behaviour of TS, ultimately allowing the assignment. I ended up disabling the new discriminativeness of prop in similar situations and the simpler solution was by using a flag, which I had to take into consideration when it comes to caching the final result.
I have to say this whole thing isn't particularly clean, but that test case is 10 years old, that behaviour is literally set in stone, and I don't have the guts to change it, even though the change would be more permissive so it shouldn't be a breaking change, hopefully.
The second problem is related to #60702. Enabling the discriminativness on a particular prop makes objects that declared that property as never disappear when narrowing. TLDR TS stopped compiling itself here because of how ArrowFunction is defined: its name property has never type so it disappeared as a possible type of node after the assertion. Therefore I changed its type from : never to ?: never as suggested by Ryan, both in src/compiler/types, where the problematic ArrowFunction lies, and in tests/baselines/reference/api/typescript.d.ts.
I don’t think this last change is problematic; rather, I think a possible indirect breaking change might lie in the fact that if a property shared between objects is typed as never in one or more cases and is now considered discriminant due to this additional discriminating capability of TS, then the type containing it could end up being eliminated by TS in various circumstances. I’d like to point out that this already happens when a property is considered discriminant, as can be seen in the linked issue. Simply put, enhancing TS’s capabilities in this regard increases the cases where it can occur.

Final considerations
I really appreciate the simplicity of the additional fallback proposed in the PR, although the need to add a flag makes it a bit less clean. Perhaps a more experienced eye could remove it entirely, or realize that the fallback actually needs to be disabled in other call points of isDiscriminantProperty, even though the baseline tests didn’t highlight any other issues.
I’m really afraid of creating inconsistencies by not disabling this new behaviour wherever it is needed.
One example is discriminateContextualTypeByObjectMembers, which indirectly calls isDiscriminantProperty by discriminateContextualTypeByObjectMembers. It is stated that findMatchingDiscriminantType must be kept up-to-date with discriminateContextualTypeByObjectMembers, and  findMatchingDiscriminantType calls findDiscriminantProperties which is the one that disables the new behaviour. Should I disable it inside discriminateContextualTypeByObjectMembers too?
Lastly, I wonder if isDiscriminantWithNeverType should take into account what’s been added by this PR. I’m quite unsure about it.

@typescript-bot test it

The perf test indicates an extra error in the vscode codebase, which should be looked at.

@jakebailey Is there something I can do? Actually, I'm having an hard time trying to understand what went wrong from the perf tests' logs

Eventually the top test will come back with more stuff, but you can just clone https://github.com/microsoft/vscode and run tsc on src/tsconfig.json before and after.

Interesting.
this.alias = opts.alias ?? opts.label;

If opts.alias "fails" wrt ?? it just means that it's empty, but TS reduces the whole opts to never.

About the first two from continuedev/continue.
Given the following definitions:
export interface ToolResultChatMessage {
  role: "tool";
  content: string;
  toolCallId: string;
}

export interface UserChatMessage {
  role: "user";
  content: MessageContent;
}

export interface AssistantChatMessage {
  role: "assistant";
  content: MessageContent;
  toolCalls?: ToolCallDelta[];
}

export interface SystemChatMessage {
  role: "system";
  content: string;
}

export type ChatMessage =
  | UserChatMessage
  | AssistantChatMessage
  | SystemChatMessage
  | ToolResultChatMessage;

They do:
protected _convertMessage(message: ChatMessage) {
    if (typeof message.content === "string") {
      return message;
    }

    if (message.role === "tool") { // <-- new error here
      return null;
    }

    // ...
}

The new error is right: content is not a string only in AssistantChatMessage and UserChatMessage. There is no overlap with role "tool".

@jakebailey I've investigated the vscode issue. That's what's happening (it follows a repro):
interface ILocalizedString {
    original: string;
    value: string;
}

type Opt = ({
    label: ILocalizedString;
    alias?: string;
} | {
    label: string;
    alias: string;
})

declare const opt: Opt

if (typeof opt.label === 'string') {
    const l = opt.label;
    const a = opt.alias ?? opt.label; // new error here, opt is never
} else {
    const l = opt.label;
    const a = opt.alias ?? opt.label.original;
}

That never seems to be right. It can't happen that both the type of label is a string AND the type of opt.alias is undefined. The first refinement reduces the possibilities for the opt's type from Opt to just {  label: string; alias: string; }. OTOH if opt.alias ?? "fails" it must be the case that opt is a { label: ILocalizedString; alias?: string }, but that's actually not possible, therefore never.
That default opt.label seems to be unnecessary, or the types used are lying.

I still have to understand errors from gui/src/components/dialogs/AddDocsDialog.tsx. Actually, I cannot reproduce them yet 😒

The first one from AddDocsDialog is a direct consequence of enabling discrimination and I'd sat it's related with the overall behaviour of TS when a discriminative property has type never. It already happens as you can see here

continuedev/continue -> gui/tsconfig.json @ gui/src/components/dialogs/AddDocsDialog.tsx#L127
continuedev/continue -> gui/tsconfig.json @ gui/src/components/dialogs/AddDocsDialog.tsx#L128
continuedev/continue -> gui/tsconfig.json @ gui/src/components/dialogs/AddDocsDialog.tsx#L130
continuedev/continue -> gui/tsconfig.json @ gui/src/components/dialogs/AddDocsDialog.tsx#L135
Same as above. It's already happening with discriminating properties.

continuedev/continue -> gui/tsconfig.json @ gui/src/components/dialogs/AddDocsDialog.tsx#L184
continuedev/continue -> gui/tsconfig.json @ gui/src/components/dialogs/AddDocsDialog.tsx#L209
continuedev/continue -> gui/tsconfig.json @ gui/src/components/dialogs/AddDocsDialog.tsx#L222
continuedev/continue -> gui/tsconfig.json @ gui/src/components/dialogs/AddDocsDialog.tsx#L225
Same as above. It's already happening with discriminating properties.

@jakebailey I went through all the 19 failures and wrote notes about all of them in previous messages.
For some of them this PR is actually finding new errors, because the new discriminating capability understands new impossible situations and types them with never, or it signals them with the "no overlap" message.
In one occasion the PR discourages mutation of the result of an iterator's next call, that's good I'd say, even if it may be considered annoying.
The remaining errors from continue are caused by the behaviour of TS when it comes to discriminating properties. The playgrounds show what's already happening with error: "disc" in place of error: string, because the former is already considered discriminating. TLDR You get the same errors.

I swear I'll stop changing the title of this.

Side quest for @gabritto. Given the fact that this PR would let us use #56941 in more occasions, like the (familiar 😂) third example in the description, I'm wondering if there could be any problem as a consequence of this more narrowing.
I can't come up with a bad/problematic situation tbh, but I'm considering the possible issue.

Side quest for @gabritto. Given the fact that this PR would let us use #56941 in more occasions, like the (familiar 😂) third example in my description, I'm wondering if there could be any problem as a consequence of this more narrowing.
I can't come up with a bad/problematic situation tbh, but I'm considering the possible issue.

#56941 is still unreleased (gonna be in 5.8), and no one should be relying on that behavior yet, so it's not likely to cause regressions or anything. It's also unlikely that changing the way we do discriminant unions will present new problems for that feature.

@typescript-bot pack this

Would fix #30506 (I'm pointing to this one because it seems the first of similar issues closed as design limitations)

Great work. Hope this is merged, the use case is common when you type external apis

Follow up about the need of the considerNonUniformPrimitivePropDiscriminant flag to disable this new thing in assignments. Could we just accept the following three?
var objStrOrNum3: { prop: string } | { prop: number } = {
    prop: strOrNumber
};

var objStrOrNum6: { prop: string; anotherP: string; } | { prop: number } = {
    prop: strOrNumber,
    anotherP: str
};

var objStrOrNum8: { prop: string; anotherP: string; } | { prop: number; anotherP1: number } = {
    prop: strOrNumber,
    anotherP: str,
    anotherP1: num
};

They are all sound if you think about it. So we could remove that flag and the implementation of this PR would be cleaner and probably a little bit faster as well.

@typescript-bot test it

22 new errors just in vscode. This will be fun

compiler-explorer/compiler-explorer
if (currentLabel !== null && currentLabel.initialLine === undefined) {
    currentLabel.initialLine = ln;
}

currentLabel has type Label | null. If it is not null then currentLabel.initialLine has type number. It cannot be undefined! TS now understands this impossible situation and types currentLabel as never inside the if.

continuedev/continue
In addition to this, this, this and this. Please note they do not set strict: true and have strictNullChecks disabled.
A PackageDocsResult is defined as:
type PackageDocsResult = {
  packageInfo: ParsedPackageInfo;
} & (
  | { error:  string; details?: never }
  | { details: PackageDetailsSuccess; error?: never }
);

In AddDocsDialog they also do:
if (docsResult.error || !docsResult.details) {
  // ...
  return
}

docsResult // used after but has type 'never' here

It seems the above if makes the { details: PackageDetailsSuccess; error?: never } case disappear when checking docsResult.error. It seems just another instance of #60702. Typing properties as never, even as ?: never when strictNullChecks: false, seems to be a really bad idea.
When it comes to CompletionProvider.ts, they do:
// Temporary fix for JetBrains autocomplete bug as described in https://github.com/continuedev/continue/pull/3022
if (llm.model === undefined && llm.completionOptions?.model !== undefined) {
  llm.model = llm.completionOptions.model;
}

But llm.model has type string. It cannot be undefined! So guess who becomes never...

desktop/desktop
About app/src/ui/app.tsx:
enum DragType {
  Commit,
}

switch (currentDragElement.type) {
  case DragType.Commit:
    return (
      <CommitDragElement
        gitHubRepository={gitHubRepository}
        commit={commit}
        selectedCommits={selectedCommits}
        emoji={emoji}
        accounts={this.state.accounts}
      />
    )
  default:
    return assertNever(
      currentDragElement.type,
      `Unknown drag element type: ${currentDragElement}`
    )
}

It seems they do not need that assertNever anymore 🙄.
When it comes to app/src/ui/test-notifications/test-notifications.tsx:
TestNotificationType {
  PullRequestReview,
  PullRequestComment,
  ChecksFailed,
}

switch (selectedFlow.type) {
  case TestNotificationType.PullRequestReview: {
    // ...
    break
  }
  case TestNotificationType.PullRequestComment: {
    // ...
    break
  }
  case TestNotificationType.ChecksFailed: {
    // ...
    break
  }
  default:
    assertNever(selectedFlow.type, `Unknown flow type: ${selectedFlow}`)
}

Same thing!

ether/etherpad-lite
Nothing new! Same as here.

microsoft/vscode
In addition to this.
We have something interesting when it comes to error TS7022: 'groupEntry' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer. at src/vs/editor/standalone/common/monarch/monarchLexer.ts#L614.
This is really weird, but the point is that we are in a situation where types of identifiers are mutually dependent, I'd say because we are in a big while loop with multiple re-assignments. groupEntry depends on groupMatching, which starts null but gets reassigned multiple times. From groupEntry we get matched and action and those two will be part, directly or indirectly, of the next version of groupMatching itself:
let groupMatching: GroupMatching | null = null;

let forceEvaluation = true;
let pos = 0
let lineLength = 0

while (forceEvaluation || pos < lineLength) {
  let matches: string[] | null = null;
  let action: FuzzyAction | FuzzyAction[] | null = null;
  let rule: IRule | null = null;

  if (groupMatching) {
    const groupEntry = groupMatching.groups.shift()!; // <-- new error here

    // they depend on groupMatching
    action = groupEntry.action;
    matches = groupMatching.matches;
    rule = groupMatching.rule;
  }

  // things happens with action and matches

  if (matches.length === fn(result)) {
    groupMatching = {
      rule: rule,
      matches: matches,
      groups: []
    };
  }
}

I don't know yet how the new discriminating power could led TS declaring an error there, but it seems related to the "recursive" inferred type of groupMatching. In fact, the following type assertion solves this issue:
groupMatching = {
  rule: rule,
  matches: matches,
  groups: []
} as GroupMatching;

So it's like it gets lost for whatever reason without that type hint. How is this related with more narrowing capabilities? I don't really know.

src/vs/platform/workspaces/node/workspaces.ts#L76:
if (typeof folderStat.birthtimeMs === 'number') {
  ctime = Math.floor(folderStat.birthtimeMs);
} else {
  ctime = folderStat.birthtime.getTime(); // <-- new error here
}

We have that folderStat was already narrowed before from  Stats | undefined to  Stats. But birthtimeMs has type number, undefined is not allowed! So folderStat becomes never in that else branch.
src/vs/workbench/services/label/common/labelService.ts#L278:
if (hasMultipleRoots && !options.noPrefix) {
  const rootName = folder?.name ?? basenameOrAuthority(folder.uri); // <-- new error here
  relativeLabel = relativeLabel ? `${rootName} • ${relativeLabel}` : rootName;
}

Same story: folder was narrowed and its name property has type string so it cannot be undefined. Probably they should use || to catch the empty string case if their intention was to provide a fallback.
src/vs/workbench/services/workingCopy/common/workingCopyBackupService.ts#L515
if (typeof meta?.typeId === 'string') {
	delete meta.typeId; // <-- new error here

	if (isEmptyObject(meta)) {
		meta = undefined;
	}
}

The type of typeId is ?: undefined, so that typeof check is now considered by TS as impossible to be satisfied.

Redocly/redoc
We have:
const { type, oneOf, discriminatorProp, isCircular } = schema;
// discriminatorProp has type string

// ...

if(discriminatorProp !== undefined) {
  // ...
}

// schema is never from now on, so new errors here:
schema.fields?.length
schema.description
schema.externalDocs

discriminatorProp, that comes from destructuring schema itself has type string. It cannot be undefined! Therefore it is typed as never after that if, and so will be schema.

@gabritto hey there!
I went through all the errors, and apart from some occurrences of never here and there due to better narrowing or a constituent of a union disappearing, because of properties defined as having the type never (#60702), there was just one main relevant error.
It is the first one from microsoft/vscode that I've discussed here. TS isn't able to solve a messy circular dependency while inferring anymore, so it needs a little help now. Not sure if that's a big deal actually: the fix is easy, this type of error occurs only once among those reported and I'd say it would be quite uncommon in user-land given how you should structure your code to encounter it. Having said that, it remains relevant because it might be highlighting some hidden issue in the resolution of circularities, which I would venture to assume falls outside the scope of this PR.

In https://github.com/microsoft/TypeScript/pull/60718#issuecomment-2547863080, I don't think it's right to say that the user "doesn't need assertNever"; it seems to me that assertNever is in cases specifically because it's in dead code...

@jakebailey may I ask for another "pack this"? It would be easier to play with it. The previous one is outdated given the implementation changes. Thanks :heart:

@typescript-bot pack this


Fieldscapes converter for Croatia and Estonia

Adding data converter for the sub-sampled data of the following countries.
References :

fiboa/data#21

Croatia Field Boundaries

fiboa/data#22

Estonia Field Boundaries

fiboa/specification#28 this issue is present in the Estonia converter. But as per the earlier discussions, for the fieldscapes project the original geometries should not be changed.

Estonia is done via #94


please add colab

awesome work please add colab for test

Great suggestion! I will close this issue when I implement one recently.


Nearest neighbor interpolator

This PR adds nearest neighbor interpolator, in case where the inverse distance weighting (IDW) does not make sense any more.
To use it, add method="NN" in the Map. For example,
apt.config.Map(
    name='test_map',
    default='map_file.json',
    method='NN',
)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

19 of 45 (42.22%)  changed or added relevant lines in 2 files are covered.
23 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.7%) to 85.04%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

appletree/config.py
11
17
64.71%

appletree/interpolation.py
8
28
28.57%

Files with Coverage Reduction
New Missed Lines
%

appletree/config.py
23
83.4%

Totals

Change from base Build<PHONE_NUMBER>:
-0.7%

Covered Lines:
2359

Relevant Lines:
2774

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

20 of 44 (45.45%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.7%) to 85.04%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

appletree/config.py
12
16
75.0%

appletree/interpolation.py
8
28
28.57%

Totals

Change from base Build<PHONE_NUMBER>:
-0.7%

Covered Lines:
2359

Relevant Lines:
2774

💛  - Coveralls


Schema generation results in invalid decorators in 2.1

Versions

Rust: 1.7.1
Diesel: 2.1
Database: MySQL
Operating System MacOS

Feature Flags

diesel: ["mysql", "extras", "chrono", "r2d2"]

Problem Description
Generating the table definitions for tables with both sql_renames of reserved words and max lengths results in a schema.rs file that won't compile
What are you trying to accomplish?
generating a table with a migration like so creates an invalid table definition in schema.rs

CREATE TABLE `my_table` (
  `id` char(36) NOT NULL,
  `type` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
);

What is the expected output?
diesel::table! {
    my_table (id) {
        #[max_length = 36]
        id -> Char,
        #[sql_name = "type"]
        #[max_length = 50]
        type_ -> Varchar,
    }
}

What is the actual output?
diesel::table! {
    offsets_bill (id) {
        #[max_length = 36]
        id -> Char,
        #[sql_name = "type", max_length = 50]
        type_ -> Varchar,
    }
}

Are you seeing any additional errors?
This causes
Invalid table!syntax. Please see thetable! macro docs for more info.
Steps to reproduce

Checklist

[x] I have already looked over the issue tracker and the discussion forum for similar possible closed issues.

[x] This issue can be reproduced on Rust's stable channel. (Your issue will be
closed if this is not the case)
[x] This issue can be reproduced without requiring a third party crate

Duplicate of https://github.com/diesel-rs/diesel/pull/3681


adds ignore_http1xx and forward compat kwargs to MarathonHealthCheck

This builds on #35 to fix #34 but also adds forward compatibility for future and yet unknown arguments.

Perfect, thank you sir


IVCT-VRF-Encoding tests: improve result reporting

Attached the last part of the console output of the encoding tests against VR-Forces, now also with spatial data.
To determine what is wrong better result reporting is necessary.
IVCT-VRF-Encoding-1.txt

Added more details of names, handles and hex dump of buffer to help find the error.

Agree to wait on an IVCT version where the TC param values can be set via env variables. This makes it much more easy to run these tests.

There seems to be a misunderstanding here: no plan exists to change all the TCparam values to env variables. There was a proposal to look into having some values such as RTI host address or federation name as env variables. The other TCparam values typically vary for each badge (and maybe test case) for each SUT. To manage these values for a large number of badges, test cases and SUTs as env variables is not easy. Are there ideas how that would work?

Added current position in byte buffer where the error is detected. The position uses the Java/C++ standard where the buffer starts at position 0 (zero). Changed buffer analysis code to throw exceptions rather than use return values, since the return values were not checked in every case. Java compiler warns about not catching exceptions.


Implement Async API 3.0.0 support

Async API version 3.0.0 has been released https://www.asyncapi.com/blog/release-notes-3.0.0 with some nice changes, specifically reducing "Publish and subscribe confusion" and "Request/Reply" support.

Hey @doblinger-extron, the tooling is still in a quite raw state. I'm waiting for the bugs and issues to settle first

Hi ! at what stage is this issue? It's been a while since spec 3.0.0 was released and its features are very interesting


unknown_fields json output issue

Hello,
I find a minor issue on unknow_field json output.
Here is the code:
struct unknown_fields_member
{
std::shared_ptr<std::string> a = nullptr;
std::shared_ptr<std::string> missing = nullptr;
std::shared_ptr<std::string> end = nullptr;
std::map<glz::sv, glz::raw_json> extra;
};
template <>
struct glz::meta<unknown_fields_member>
{
using T = unknown_fields_member;
static constexpr auto value = object("a", &T::a, "missing", &T::missing, "end", &T::end);
static constexpr auto unknown_write{ &T::extra };
static constexpr auto unknown_read{ &T::extra };
};
// Use
std::string buffer = R"({"unk":"zzz", "unk2":{"sub":3,"sub2":[{"a":"b"}]},"unk3":[])";
glz::context ctx{};
glz::read < glz::opts{ .error_on_unknown_keys = false } > (obj, buffer, ctx);
// encodes output string
std::string out{};
glz::write_json(obj, out);
I can see the read works well, but the write_json output is wrong, i.e. additional "," is outputted.
The out string is:   {,"unk":"zzz","unk2":{"sub":3,"sub2":[{"a":"b"}]},"unk3":[]}
Is it a bug?  any workaround to make the output works?  Thanks!

Thank for reporting this! I'll try to address it soon.

Okay, I've been able to debug this and uncover the problem. The issue is that skip_null_members is set to true and your struct is all null pointers (null members). If you set skip_null_members = false, then it will write out these null members and solve the problem. However, I've solved the problem and will merge in a solution soon, so that you don't need to use the option  skip_null_members = false.

Fixed in #1367 merge with main. Will be included in the next release.