Backend / plugin system remove_duplicates raises AttributeError on discovering duplicates

What happened:
In one of my CI runs somehow the entrypoints ended up being defined twice. Then, I discovered that the function remove_duplicates which weeds out duplicate entrypoints were not updated.
What you expected to happen:
No bugs in remove_duplicates function
Minimal Complete Verifiable Example:
# Put your MCVE code here
from xarray.backends.plugins import remove_duplicates
from importlib.metadata import entry_points

eps = entry_points().get('xarray.backends', ())

remove_duplicates(eps)
remove_duplicates(eps + eps)

<ipython-input-12-22df5e55614a>:1: DeprecationWarning: EntryPoints list interface is deprecated. Cast to list if needed.
  remove_duplicates(eps + eps)
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-12-22df5e55614a> in <module>
----> 1 remove_duplicates(eps + eps)

~/.pyenv/versions/3.9.7/envs/pymech/lib/python3.9/site-packages/xarray/backends/plugins.py in remove_duplicates(entrypoints)
     27         matches_len = len(matches)
     28         if matches_len > 1:
---> 29             selected_module_name = matches[0].module_name
     30             all_module_names = [e.module_name for e in matches]
     31             warnings.warn(

AttributeError: 'EntryPoint' object has no attribute 'module_name'

Anything else we need to know?:
Following v0.20.0 the entrypoints were discovered using importlib.metadata / importlib_metadata, but it was broken for 3rd party backeds. In v0.20.1 after #5931 the backend detection was fixed, but remains to be thoroughly tested #5934. This bug might be rare, compared to #5930, so I would recommend having some tests in place before making the next release.

In [16]: from importlib_metadata import entry_points

In [17]: entry_points().get('xarray.backends', ())
<ipython-input-17-5f3ea0df5c10>:1: DeprecationWarning: SelectableGroups dict interface is deprecated. Use select.
  entry_points().get('xarray.backends', ())
Out[17]:
[EntryPoint(name='rasterio', value='rioxarray.xarray_plugin:RasterioBackend', group='xarray.backends'),
 EntryPoint(name='pymech', value='pymech.dataset:PymechXarrayBackend', group='xarray.backends')]

In [18]: entry_points().select(group='xarray.backends')
Out[18]:
[EntryPoint(name='rasterio', value='rioxarray.xarray_plugin:RasterioBackend', group='xarray.backends'),
 EntryPoint(name='pymech', value='pymech.dataset:PymechXarrayBackend', group='xarray.backends')]

I'm getting a similar issue with xarray=0.20.1 when installing rioxarray and rasterio, looks like #5931 didn't fully fix things?

 As there is possibly a bug in remove_duplicates, another issue is hidden deeper.
https://github.com/pydata/xarray/blob/e0deb9cf0a5cd5c9e3db033fd13f075added9c1e/xarray/backends/plugins.py#L100-L103
Here entry_points is called and for some reason it returns the xarray.backends twice (but only if invoked via pytest). This can be followed down to importlib/metadata.py distributions() which finds the package under test twice. This is as far as I could get.
Any help very much appreciated.

@kmuehlbauer

Add a breakpoint() below line 102 and print out entrypoints. Step into build_engines follow it using the debugger.
Can you also try this suggestion https://github.com/pydata/xarray/issues/5944#issuecomment-962414054

To use the select method, the following should be changed:

Swap the imports so that newer importlib_metadata is imported first:
https://github.com/pydata/xarray/blob/e0deb9cf0a5cd5c9e3db033fd13f075added9c1e/xarray/backends/plugins.py#L8-L12
Require importlib_metadata for Python < 3.10
https://github.com/pydata/xarray/blob/e0deb9cf0a5cd5c9e3db033fd13f075added9c1e/setup.cfg#L81

@weiji14 I've solved my issue by invoking pytest with --import-mode="append" outside the package directory.

When a fix is added for this, feel free to ping me to test the fix on rioxarray.

@snowman2 Do you get the same error when running the testsuite for rioxarray with xarray 0.20.1?
My question would be, why are those duplicates there in the first place.

I see the same issue reported here: https://github.com/pydata/xarray/issues/5944#issuecomment-962958896
See: https://github.com/corteva/rioxarray/runs/4128446687

@snowman2 #5959 should fix the AttributeError: 'EntryPoint' object has no attribute 'module_name'.

OK, here are my findings.
There are tests for this in https://github.com/pydata/xarray/blob/main/xarray/tests/test_plugins.py, but they are still using pkg_resources. Because of that, the tests did not capture this issue although we have tests for it.
While fixing the AttributeError the tests finally failed (it was using pkg_resources nomenclature).
With latest #5959 everything should be in place now.


Prevent propagation of failures to SharedRepeatableAction parent scope

Deemed this unnecessary, as all the places where SharedRepeatableAction are used, its parent scope is a SupervisorJob. So, this PR just adds unnecessary complexity without providing any real value.


chore: change exntesion id for 2022

Updated extension id for proper value. And clear extension description.

@michelkaporin yesterday (before our solution with versions) I renamed namespace to Snyk.VisualStudio.Extension.Shared. If it's good idea we could merge it to main branch. Also if we want to use this namespace maybe I also need to add Shared folder to \Snyk\VisualStudio\Extension\?

@aldanchenko Yes, please ensure rule "folders equal namespaces".


Added hint regarding sourcing vimrc via autocmds

I just added this because there might be other users facing this particular problem and I thought a hint present on the README of this project might be nice!

Thanks.


[FLINK-33958] Fix IntervalJoin restore test flakiness

What is the purpose of the change
Fix flakiness of restore tests for IntervalJoin node
Verifying this change
This change added tests and can be verified as follows:

Added restore tests for IntervalJoin node which verifies the generated compiled plan with the saved compiled plan.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

@bvarghese1 Could you please explain how does this improve the test reliability?

@bvarghese1 Could you please explain how does this improve the test reliability?
Previously the input was:

        Row.of(7, 3, "2020-04-15 08:00:16"),
        Row.of(11, 7, "2020-04-15 08:00:11"),
        Row.of(13, 10, "2020-04-15 08:00:13")

This would make the processing unreliable depending on when the watermark is processed. If its not timely then events like Row.of(11, 7, "2020-04-15 08:00:11") gets processed otherwise they get discarded due to being late. To fix this I changed the order of the input to make it a bit more reliable for tests.


[RFC] Formally supporting some suite of "-O*" type flags

Motivation
In the process of trying to land #18474 I ran into a number of correctness issues related to LLVM backends where the only saving grace was having a reference that gave correct numerics to compare against. I often found myself hacking in adjustments to the LLVM optimization level for comparison, or string parsing on dispatch names for finer grain control over various pipelines.
Moving forward we still have a fairly large suite of models with correctness issues across multiple backends: https://github.com/nod-ai/e2eshark-reports/blob/main/2024-11-07/ci_reports_onnx/rocm/combined-reports/summary.md + https://github.com/nod-ai/e2eshark-reports/blob/main/2024-11-07/ci_reports_onnx/llvm-cpu/combined-reports/summary.md
We need to find a way to be much better about numerics if we want consistent users of the compiler. Focusing on a few of the models that we care about for only the most optimized paths is not going to help get us there.
Currently we have a set of flags scattered throughout the code base that control various optimizations, most of which are leftover from when the underlying feature was under development. To name a few:

--iree-opt-aggressively-propagate-transposes
--iree-opt-outer-dim-concat
--iree-opt-data-tiling
--iree-opt-numeric-precision-reduction
--iree-dispatch-creation-enable-aggressive-fusion
--iree-scheduling-optimize-bindings
--iree-llvmcpu-disable-distribution
--iree-llvmcpu-disable-vector-peeling
--iree-codegen-llvmgpu-use-vector-distribution
--iree-codegen-llvmgpu-use-igemm

99% of this issue is focused at codegen (as that's where 99%+ of the numerics issues come from) but other phases (e.g. DispatchCreation) also includes a large space of optimization choices.
Proposal
What I'm proposing is:

Limit the proliferation of "developer flags." This includes being clearer about the naming when it is for enabling an in-progress feature that is intended to be turned on by default (i.e. -test- or -experimental- naming prefixes). I don't know what the opinion of llvm::cl::hidden is, but that is another option to avoid exposing every new/developer flag to the user. This cleanup will help with formalizing the compiler's APIs for controlling optimizations.
Expose [codegen] backend optimization level flags (mainly for LLVM based backends, I don't think there is any equivalent in SPIR-V) as compiler options (not floating flags)
Add support for true -O0 codegen pipelines that prioritize correctness and can handle any input + expose flags to enable them (perhaps a shared flag)
Add a mechanism to control codegen "opt" levels per dispatch
Do a coarse grouping of compiler flags that we can enable/disable all at once (similar to clang -O___). I don't know if our compiler is suited for global optimization levels, so this may make more sense per compilation phase.

I am not an expert in API design, this is just my intuition for the kind of reorganization that I think could help us make progress on the swath of correctness issues we have. Also there have been a number of improvements to the pass rate of the model suite listed above recently, and I believe almost all of those have been from frontend improvements that are papering over correctness issues that are still there.

Has been on the TODO list for awhile, would be nice to have.
In a multi-stage compiler we will always need a way to control each area (input/frontend level with asserts/etc, global tensor optimization, fusion, host codegen (stream/hal/vm/etc), device codegen) so having per-stage opt flags is the baseline. For most purposes like you're working through here you a global flag across all stages will only help the first step of a binary search ("does literally anything in the compiler change anything anywhere") - useful, but rarer in workflows. The more we can scope things the more effective the binary search is ("does anything in codegen change behavior yes/no, does anything in global opt change behavior yes/no" etc).
I'd like to see any top-level transformation pipeline have an opt flag and the compiler frontend propagate them consistently: --iree-stream-opt= --iree-hal-opt= --iree-flow-opt= --iree-codegen-llvmgpu-opt= etc (named after the pipeline names, like --iree-hal-transformation-ipeline -> -opt). Then we can have an --iree-opt= that sets those all. If those compiler driver flags just set the transform options for each pipeline we can still create reproducers and such that include the opt level. So concretely something like IREE::Stream::TransformOptions would have an Option<OptimizationLevel> option, the default options could be set based on --iree-stream-opt=, and the compiler driver would pass in its --iree-opt flag if that was set. A shared OptimizationLevel only really works at those high-level pipelines (as you may want finer down below) but that's ok - if a user wants to still pass --iree-llvmcpu-disable-distribution they can (though naming wise we should never include disable/enable in a flag name - a boolean flag true denotes enabled and false denotes disabled, and --foo-disable=true is weird).

For most purposes like you're working through here a global flag across all stages will only help the first step of a binary search ("does literally anything in the compiler change anything anywhere") - useful, but rarer in workflows. The more we can also scope things the more effective the binary search is ("does anything in codegen change behavior yes/no, does anything in global opt change behavior yes/no" etc).

Yes, this binary search is exactly what I want us to be able to start doing. Today we have two main issues

Our compiler is essentially -O3 by default always
Even if you wanted to binary search through the flags that are there, there's no organization that makes it possible for anyone outside of a developer to do (and honestly I don't think there are even any developers of IREE that could accurately navigate all of the flags we have)

--iree-stream-opt= --iree-hal-opt= --iree-flow-opt= --iree-codegen-llvmgpu-opt= etc (named after the pipeline names, like --iree-hal-transformation-ipeline -> -opt). Then we can have an --iree-opt= that sets those all.

This sounds perfect to me. We can start by getting some of this structure in place and then figure out what each phase means in isolation (per the people who work on each one).

--iree-codegen-llvmgpu-opt=

Currently AFAICT top level compiler options are inaccessible to codegen directly, only to the target backends, so I was assuming we'd make LLVM[G|C]PUPopulateTranslationPassPipeline take the OptimizationLevel and then we get --iree-llvmcpu-codegen-opt=/--iree-rocm-codegen-opt=/--iree-cuda-codegen-opt=. That might clash with LLVM opt levels though and I'd want to have separate control over what our codegen does and what LLVM does. Maybe those could be --iree-*-llvm-opt.

(though naming wise we should never include disable/enable in a flag name - a boolean flag true denotes enabled and false denotes disabled, and --foo-disable=true is weird).

I wasn't really going to go after naming, but makes sense. I am not in the mood right now to go rename all of the flags though :P.

THis would be great! Though I think everyone always just wants to use -O1000

But without being tongue in cheek, lets start with -O1. I think it is more to manage some features that are ready on some backend but not on other backends for the dispatch region formation stuff. I keep one flag there (--iree-dispatch-creation-enable-aggressive-fusion=true).  Do we need any of the RoCM flags? There are developer flags that can allow going down "conservative" compilation. But if these are flags that are just developer flags they dont qualify to be part of optimization flags. Basically anything you add to a list of "optimization level controlled flags" is a long-term feature support. If these flags dont fall into it, then they are purely developer flags.


WIP simplifying windows

simplifying windows builds on appveyor to just use miniconda python for numpy

Coverage decreased (-0.05%) to 96.972% when pulling b08f91aaf84cb313e514aec714588d44f0266c82 on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.03%) to 96.992% when pulling 38bc193dabf648b7202d6ec35da501a87e3b782f on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling c736197b9ec67b5000f4355be4973b66167e84ed on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling 4a6da1267d27bc5d7815a5b7b21bb695a0afbee7 on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling 76a75b1d4d9cb5f8032f69d7043e52d41b3b26ff on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling c5fe520eab1dcf24112e6b5f01326d4cdedde7ce on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling d8c0fc4b6eb4ebd3df05d5f2d1fc49e27631c77a on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling 33708a3a675c4904a21bdc2c2ffcc1cd75b978da on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling a2673608ccd23eddae4218d15fb790f12cee7b70 on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling ee07ec734272badbbf88da04f9e7412b84c88144 on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage decreased (-0.05%) to 96.972% when pulling 674f4928eb20533b724c30b64dd5e841ac43d4b1 on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage increased (+0.002%) to 97.024% when pulling 391fe9378261667bea0d2304888f52077d795742 on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

Coverage increased (+0.002%) to 97.024% when pulling f9d9a54fd39f3d1fa18952eed772b34a56d61348 on simplify_windows_builds into 09bdeba64e84ce9bc54c39be6ddec2b3be71e8f8 on master.

ended up deciding not do this and merge in code from conda-spiceypy into here, still weighing options


UAR-1594 add temp logging for debugging

JIRA link
https://companieshouse.atlassian.net/browse/UAR-1594
Change description
Added some additional logging statements to make it clear if private BO data could not be retrieved for some reason.
Fixed indentation in test file.
Work checklist

[ ] Tests added where applicable
[ ] UI changes meet accessibility criteria

Merge instructions
We are committed to keeping commit history clean, consistent and linear.  A BREAKING CHANGE can be part of commits of any type,
types other than fix: and feat: are allowed, for example build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others,
footers other than BREAKING CHANGE: <description> may be provided.

Some additional logging within the mapIndividualBOPrivateData() function might be helpful too. What do you think? It's in the psc.to.beneficial.owner.type.mapper.ts file and called when mapping the address.

I've already added logging to this function.


fix containers/image progress

Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>

waiting to fix https://github.com/containers/image/pull/102#pullrequestreview-1550771 and re-vendor again


App defaults should not use "dataflow"

Both file-source and file-sink have default values using "dataflow" as directories

This issue was moved to spring-cloud-stream-app-starters/app-starters-release#5


Update FC028 to detect bad platform_family usage as well

Signed-off-by: Tim Smith<EMAIL_ADDRESS>

Ping @coderanger


make filtering correct for Vento on the plugins page

https://lume.land/plugins/?status=all&template_engine=on
I think Vento is now installed by default. This fix will make this clear on the Plugins page.

Good catch. Thank you!


Remove fresco install

By including fresco in the pip install this results in the following non-related library being installed:
https://pypi.org/project/fresco/
... also, as a side note ... have you considered making your library pip installable (without needing to clone the repo?) ... and if you have, it might be worth changing the name of your package so as not to clash with pre-existing packages.

Yes, this with also a typo. We are updating the readme to describe both manual installation and installation via pypi.


Remove duplicate code

in_channel was set twice
test_lst was loaded in cmd_eval but it's not needed

Thx for  the PEP8 corrections 😍


Multisig test of credential revocation.

This PR includes multisig test of credential revocation and several fixes to revocation to make it work.

Great! Will this also make it into development branch?


Update signal to 1.10.0

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

In the future, please avoid checkpoint-only changes,

Hm, sorry. I had noticed that Signal 1.10.0 was released and that the cask still appeared to be at version 1.9.0, so I ran cask-repair --cask-version 1.10.0 signal and this PR was the outcome of that.
To be honest, I don't even know what those checkpoints are about. Could you let me know where I could read about them and/or what I should have done differently? I couldn't find any information on those checkpoints in the contribution guide.

Docs.
They’re an internal value for figuring out when something has been updated, but they’e not yet in use.


Causing bootloop after installed August version

I have tested many versions, only august version causes bootloop
LineageOS 18.1 (clover)

Same

Same

What rom and device are you using

crDroid 7.9 Beyond1lte

Was experimenting by adding hardware related audio config as an attempt to fix hotword for some users. Will revert asap. Thanks for reporting.


Allows users to shade/relocate dependencies

Shading dependencies is one of the major problems when it comes to developing something with multiple transitive dependencies.
When it comes to different versions it is best to start shading and using the most fitting version of the dependency for the convenience of the project.
Everytime I try to use something from the org.apache namespace with spigot or forge I run into issues with dependencies and it is only possible to fix this by shading dependencies. I find it to be very annoying having to use old versions of the apache libraries just because I cannot relocate.

If you would like to explain to me how that is possible, that would be great :D


Update README.md

Fixes enum
Base Branch
Make sure you're currently pointing to the next release base branch. For example:
branch: feature/5.1.0
If you're unsure, check the latest tag, it'll be a semantic version higher than that.
SwiftLint
Ensure SwiftLint hasn't reported any issues. Code styles must be adhered to.
README
Does the README need updating? Ensure anything relevant is updated there as well.

I did this myself too... perhaps o forgot to merge :-) thanks.
Sent with GitHawk

I realise this is just a README update, but sticking with the contributing.md doc, can you just update this to point to release/5.1.0 then I'll merge.


[UnitTests] Build unittests with the same compiler used to build the runtime library to ensure calling conventions match.

The tests were building with /usr/bin/clang++ which didn't support SWIFT_CC(swift). This caused a calling convention mismatch between caller and callee for Refcounting.cpp's destroyTestObject function. That caused it to receive junk as its parameter and fail.
Fixes SR-7638 (rdar://problem/40114415).
This works but I'm not too happy with the copy/paste job from stdlib/CMakeLists.txt. My CMake-fu is weak. If any CMake wizards out there have a better way to do this, I'd love to improve it.

@swift-ci please test

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - e6a05258628969c7f55aec2028b7f5786984a557

Build failed
Swift Test OS X Platform
Git Sha - e6a05258628969c7f55aec2028b7f5786984a557

This appears to have broken our asan bots, so I'm reverting temporarily.


Dockerize

This PR does a couple things:

Sets up a basic Dockerfile. As we discussed, it isn't quite right (conda env yaml still needs work, tests aren't totally passing) but I think it's a good first crack.
Set up the "database" insert script. I made the executive decision that it'll be easier if our database is just parquet files in a reasonable directory structure on S3. That way any post-processing with Spark should be dead simple. This is still missing read/wrangle/insert of metadata on the run (not just the sample) but that would require shifting to (in my order of preference) a config file we can save as a table (preferably I think?), switching to json, or just tossing the existing yaml into S3.

It would be great to get thoughts/revisions/sign off on both.

First questions of undoubtedly many:
This Dockerfile currently lets you successfully build a successfully image?
For me it fails when attempting to run the pipeline as it can't make the fastp env when running snakefile2.  The base snakemake image seems to have been recently updated, so that might be the issue.
Do all the test pass for you when you run pytest not in the docker image?  The lineage unit test was failing for me.  I figured out the fix for it, but want to see if things are behaving the same for both of us.

Yes -- it does let me build and run the image. That seems like it could be the source of the problem, but I think it's more likely you're not pulling the latest image (assuming you're using the pre-built image on Docker Hub not trying to build yourself from the Dockerfile.
And, no the tests weren't all passing but I didn't look to hard into figuring out the issue.

I was building from the Dockerfile.  Do you have a link where I could get the pre-built image?

Can you give docker pull zsusswein/SHED:latest a try?

I have everything working on my end now.  The exception being insert_to_db.py, which fails b/c I don't have the keys.  It looks like you've got it set to pull the keys from the os env.  I think it might be better, especially for a public docker image, to have the keys inputted via stdin.
All the tests now pass in a newly built docker image.  I had to change back conda channel priority to false to allow snake make to properly build all the envs it needs.  I think a better solution would be what I did with the docker image I built for databricks, and just have the docker image have all the tools the pipeline needs so snakemake doesn't have to handle building any of its own envs.  What are your thoughts on that?
As far as the env you have conda making for the current image, I see some things are necessary for insert_to_db.py and assume others are for other tasks you have planned?
Regarding the single snakemake file, there are/were some shortcoming of snakemake (which might have been fixed in newer version) that led me to make the 3 files.  I can look into this again, but before doing much with the pipeline, I think we need to figure out the best strategy for parallel processing.  That conversation might merit a zoom.  But if you already have something in mind I can just start working at getting the pipeline compatible.
Do you want me to just push the updates I have to get things working?
Let me know if I missed anything.

Ok going in order:

I checked with our devs and they say that, under the assumption we're running this through AWS, it'll be most secure to expose the keys via env vars. We can just set them from the AWS control panel. I hear you though that we should triple check this before deploying.
Awesome, thank you! I'd say please do here whatever it was you did for that image. I didn't go back to your image to pull in all your tricks, but I should have.
I don't think I meant to put anything in the conda env yaml that wasn't being used. I basically just went into the image, manually installed everything the pipeline was using, and then copied that env to a file. It's super janky, but the only way I could get something with versions because the image is linux and I'm on a Mac.
Sorry, I didn't mean to include that file. It was a WIP from the first time I was trying to get things working. I'll remove it.
Please do!

Only other thing is that I'd love your thoughts on is: what should go in a "run metadata file". I assume we want everything in the yaml plus probably freya version? Do you know an easy way to pull that out of the existing pipeline? Anything else I'm not thinking of maybe (SHED pipeline version/SHA hash)?

I've pushed some changes to the files for pytesting and to get the pipeline to work without updating curl from what the snakemake docker image has.
I'm uploading the image I built and that works for me (to the extent it can w/o the aws keys).  It should be shared with you.  I'd like to see if you can load and run it before I push any changes to the Dockerfile and such.
The snakefiles would benefit from some optimization towards whatever parallelism is to be used.  Those changes probably would need to be tested when it is being run on Spark though.
Run meta probably should have versions of every primary component used.  That info should be easy to pull and/or just have a file with that info updated as we go.  As far as freyja, the lineage data it updates during the run is pulled from http://hgdownload.soe.ucsc.edu/goldenPath/wuhCor1/UShER_SARS-CoV-2/ and https://github.com/outbreak-info/outbreak.info/tree/master/web/src/assets/genomics . I think the simplest solution for those is just have a timestamp entry for when the freyja update is run that anyone can then use to check back to what version of those data were used.  There should also probably be start:end timestamps for the pipeline in general.  Having checksums would add to peoples confidence in the pipeline's results as they are being propagated, though I usually see them on a per file basis.  I think that would be everything someone would need to reproduce/verify the results.

Some more info on the docker image.  It ran the pipeline in the building and should be ready to run insert_to_db.py, though you'd need to put the keys into the evn for it to work.

@rkassa everything should be here!

Hey @degregory -- working on this a little more. Can you clear up something for me:
Do you know how freyja pulls the data? Does it do a fresh pull from those two sources each time it's run, does it download the data at install, or is there a freyja version update each time the lineage data change? I'm trying to think through how to best record this info (and whether it's worth recording the actual lineages available to freyja at the point in time). I feel like it might be too much work, but not sure how hard it is.

It comes with a version of the lineage data when it is installed/downloaded.  To update it requires running and update command.  That is a step in snakefile3 that is run dependent on the enable/disable setting in the yaml.   It wouldn't be difficult to just copy the files it used, but I don't know how much value that would add.

Ok @degregory -- good news & bad news.
Good: I have a basic working version of the pipeline run metadata set up. Take a quick look at it for me?
Bad: Trying to build the image throws:
Creating conda environment envs/fastp.yaml...
#16 1447.8 Downloading and installing remote packages.
#16 1451.3 CreateCondaEnvironmentException:
#16 1451.3 Could not create conda environment from /tmp/repo/envs/fastp.yaml:
#16 1451.3 Command:
#16 1451.3 mamba env create --quiet --file "/tmp/repo/.snakemake/conda/f0e199262dec33bd36733a39da24c31a_.yaml" --prefix "/tmp/repo/.snakemake/conda/f0e199262dec33bd36733a39da24c31a_"
#16 1451.3 Output:
#16 1451.3 Encountered problems while solving:
#16 1451.3   - package fastp-0.23.2-hd36eab0_1 requires libdeflate >=1.9,<1.10.0a0, but none of the providers can be installed

I'm guessing this is because something somewhere was updated and now conda is angry about it, but I'm not sure. If you're stumped too, I'll dig into it some more on my own. But I wanted to check if you had any ideas first.

Did the image I shared work for  you?  I wanted to make sure it did before I pushed the changes that should resolve that error.  I'll look over the other changes sometime today or tomorrow.

I pushed some changes to the dockerfile.  They are what worked for me before.  I don't know if they'd still work, b/c testing them with the updated config.yaml bricked my linux subsystem.  I also made some changes to the insert_to_db.py so it will work w/o the keys, for it to output the various metadata locally, and I also made some changes to the summarized lineage gathering regex.  The output I was getting was a bit off.
While working to timestamp the freyja updating, I discovered that the recent snakemakes error when they try to do the freyja update.  It looks like the freyja developers are working on a fix for it, but at the moment, if we try to use the update command it won't work.  There are some possible work arounds that'll I'll try once I have my subsystem functional again.

Back up and running.  To get the docker image to build, I also had to comment out the yaml install.  I think for the pip install we'd need pyyaml, which is already present from the snakemake image.

Just tried to docker load the image you shared. It throws a Error processing tar file(exit status 1): write /tmp/repo/sratoolkit.3.0.0-ubuntu64/bin/test-sra.3.0.0: no space left on device. A little odd because I gave 250 GB of space available.
I'm pulling now and going try to build the image with your new changes.

Ok built with the changes you pushed. Everything builds and runs but I'm getting about half the tests failing:
(snakemake) root@3b50dc299b1f:/tmp/repo# pytest
============================= test session starts ==============================
platform linux -- Python 3.10.6, pytest-7.2.0, pluggy-1.0.0
rootdir: /tmp/repo
collected 11 items

tests/test_aggregate.py .                                                [  9%]
tests/test_consensus.py .                                                [ 18%]
tests/test_download_sra.py .                                             [ 27%]
tests/test_full.py .                                                     [ 36%]
tests/test_get_fastqs.py .                                               [ 45%]
tests/test_lineages.py F                                                 [ 54%]
tests/test_mapping.py F                                                  [ 63%]
tests/test_primer_trim.py F                                              [ 72%]
tests/test_quality_check.py F                                            [ 81%]
tests/test_sam2bam.py F                                                  [ 90%]
tests/test_vc.py F                                                       [100%]

=================================== FAILURES ===================================

I've pushed the latest build so you can take a look. If you want, I'm happy to merge this PR as is and we can deal with whatever the issue is with these in another branch/PR.

I pulled the new image and all the pytests work for me.  So troubleshooting what's going on will probably be rather time consuming.  I'm fine with punting on it for now.

Ok looking through the errors a bit more, it seems like it's coming from an issue writing to disk -- doesn't seem real to me. Agreed on punting.

@degregory -- you're the reviewer. When you get the chance, can you approve and merge the PR?

Approved.  Still needs Robel's.  It looks like the .pre-comit-config.yaml needs to be pushed for the pull.  Have you updated it any on your end, or can the one from DAGdev be copied over?


certain image names in duffle.json produce spurious images in bundle

The following duffle.json:
{
    "name": "imagebug",
    "version": "1",
    "schemaVersion": "v1.0.0-WD",
    "invocationImages": {
        "cnab": {
            "name": "cnab",
            "builder": "docker",
            "configuration": {
                "registry": "imagebug"
            }
        }
    },
    "images": {
        "x.y": {
            "image": "docker.io/cloudfoundry/cnb@sha256:93e2707b756ed9544ecccab6884424e4990e2b3ec08f0435b8249499b51b2354",
            "digest": "sha256:93e2707b756ed9544ecccab6884424e4990e2b3ec08f0435b8249499b51b2354"
        }
    }
}

when input to duffle build, produces an invalid images section of bundle.json:
{
  "description": "",
  "images": {
    "x": {
      "description": "",
      "image": "",
      "imageType": ""
    }
  },
  "invocationImages": [
    {
      "image": "imagebug/imagebug-cnab:32ff5be1120468ffcb5c37226c5348276b9de209",
      "imageType": "docker"
    }
  ],
  "name": "imagebug",
  "schemaVersion": "v1.0.0-WD",
  "version": "1.0.0"
}

This seems superficially like https://github.com/deislabs/duffle/issues/658, which was apparently fixed.
Possible clue
Change x.y to x in duffle.json and the correct bundle is produced:
{
  "description": "",
  "images": {
    "x": {
      "description": "",
      "image": "docker.io/cloudfoundry/cnb@sha256:93e2707b756ed9544ecccab6884424e4990e2b3ec08f0435b8249499b51b2354",
      "imageType": ""
    }
  },
  "invocationImages": [
    {
      "image": "imagebug/imagebug-cnab:32ff5be1120468ffcb5c37226c5348276b9de209",
      "imageType": "docker"
    }
  ],
  "name": "imagebug",
  "schemaVersion": "v1.0.0-WD",
  "version": "1.0.0"
}

Steps to reproduce (at least on macOS)

Grab duffle from https://github.com/deislabs/duffle/releases/tag/0.2.0-beta.3 and add it to your path
Download and unzip build.zip
cd into the unpacked archive and into the build subdirectory
issue duffle build . -o outbundle.json
observe the images section of outbundle.json

This appears to be a side-effect, or probably a feature, of https://github.com/spf13/viper (and the underlying https://github.com/mitchellh/mapstructure).

Note that https://github.com/deislabs/duffle/issues/752 changed duffle so that it is intended to take only duffle.json as input (no TOML or YAML thank you), so we are free to switch from viper to standard JSON parsing.

I vote for removing viper now that we don't need multiple file formats anymore in duffle. We can just go back to using encoding/json.


Permute ACPERMS integer operand's bits

As discussed on the mailing list (here, here, and here) and as part of https://github.com/riscv/riscv-cheri/issues/294 and https://github.com/riscv/riscv-cheri/issues/324, we should permute the current bit pattern used by ACPERM (https://github.com/riscv/riscv-cheri/blob/main/src/img/acperm_bit_field.edn) to leave the bottom-most bits available for extensions.
In RISC-V, an arbitrary value for the least significant four bits of an otherwise all-1s XLEN-length word, n in 0xF...Fn, can be synthesized with a single compressed instruction.  That is, these bits are somewhat more precious than the others.
In more detail, presently, ACPERM's bit pattern's least significant bits are C, R, W, and X.  Experience (between big-CHERI and CHERIoT) suggests that C, R, and X are relatively rarely modified, while W and non-base-specification permissions (load-global, load-mutable) are more often changed as part of exchanging data and structures across trust boundaries.
Therefore, it would be nice for C, R, and X to be moved up to higher bits in the ACPERM bit pattern, with their prior locations left reserved for further extensions (such as the as-yet hypothetical Zcheriot).

@nwf-msr : Which instruction(s) do you have in mind for producing the arbitrary 4-bit value you mentioned here? I am guessing is c.andi, but that has a 6-bit immediate out of which bit 5 is the sign (i.e. 5 useful bits).

In RISC-V, an arbitrary value for the least significant four bits of an otherwise all-1s XLEN-length word

We currently have these architectural permissions defined:

Bit 0: C
Bit 1: W
Bit 2: R
Bit 3: X
Bit 4: ASR
Bit 5: LM
Bit 6 to XLEN-1: Reserved

How about something like this instead? (I am assuming that LM and ASR do not change very often either)

Bit 0: Reserved
Bit 1: Reserved
Bit 2: Reserved
Bit 3: W
Bit 4: LM
Bit 5: C
Bit 6: ASR
Bit 7: X
Bit 8: R
Bit 9 to XLEN-1: Reserved

@nwf-msr : Which instruction(s) do you have in mind for producing the arbitrary 4-bit value you mentioned here? I am guessing is c.andi, but that has a 6-bit immediate out of which bit 5 is the sign (i.e. 5 useful bits).

Oh, indeed, I just can't count.  Even better. :)

How about something like this instead? (I am assuming that LM and ASR do not change very often
either)

ASR changes roughly never, yes.

Bit 0: Reserved
Bit 1: Reserved
Bit 2: Reserved
Bit 3: W
Bit 4: LM
Bit 5: C
Bit 6: ASR
Bit 7: X
Bit 8: R
Bit 9 to XLEN-1: Reserved

I think that's a perfectly sensible order and, FWIW, is pretty close to the CHERIoT one.

CHERIoT defined our bottom five bits as, up to spelling, SL LM W LG GL; the three of SL, LG, and GL don't exist in Zcheri, but would slot nicely into those three reserved bits.  I don't see any reason to prefer CHERIoT's current order over, say, a LM W SL LG GL order that'd be compatible with your proposal above.

The upper bits of CHERIoT's ACPERM operand equivalent were U0 SE US X ASR C R.  U0, SE, and US also don't exist in Zcheri.  Again, I don't see any huge significance to the difference between CHERIoT's current order and your proposed R X ASR C, since andi has a 12-bit immediate, so all those are within reach anyway.

@davidchisnall might recall something I'm overlookng, tho'.

@nwf-msr : Thanks for the info. I will prepare a PR.
@jonwoodruff also pointed out that we would ideally put the software-defined permissions within the 12 LSBs because these are often (perhaps in the allocator? I cannot remember exactly were!), so I will shift those around as well.

I agree that it makes sense to keep the user perms within the 12-bit immediate so that allocators/the kernel can check for them using one instruction less. Not a huge performance improvement, but probably worth doing anyway. The only awkward thing we might need to consider is that the user-perms are "variable length" so any new permissions might need to end up quite high up unless we say "uperm 0/1 go at the low offset, later user-perms start at 32 (since they are rv64 only).
It would be worth checking if the allocator/kernel check any bits in addition to the user bits.


Pre-requisites

Clarification for #31.
To prevent frustration for Windows/Mac OS users, I moved the compatibility section to the top and added apt install requirements.

Move the compatibility section to the top.
Explicitly mention that Windows and Mac OS are not supported
Mention apt install
Added Debian as a tested environment

Released with v1.11. Thanks for your contribution


Added a new GET function

Added a new GET function in the comments controller that retrieves all messages of a specific discussion based on the DiscussionID. I also implemented the necessary functions in the DAL and BLL

hi,
I didn’t understand the instruction to update the documentation to Hebrew, as it is already written in Hebrew. Should I change it to English or remove it? It's not clear.
thanks

sori ,
This is a mistake.
Change the documentation to English language.
good luck

I made the changes.

Have a great rest of your day.


Ray was unable to bind to the remote server's port (on Siteground)

Describe the bug
When I try to connect to any Siteground server using ssh key
"Ray was unable to bind to the remote server's port.
Is the port in use or is someone else using ray on this server?"
But I can connect correctly through terminal on mac.
I have seen https://github.com/spatie/ray/issues/685 and https://unix.stackexchange.com/questions/427189/how-to-cleanup-ssh-reverse-tunnel-socket-after-connection-closed
but I don't have permission to do this thinks on a siteground server.
Versions
Ray version (you can see this in "About Ray"): 2.4.0
To Reproduce
Steps to reproduce the behavior:

add a siteground server
insert the data in the form (the same that I use in the terminal where is working)
try to connect to the server
See error

Expected behavior
It should connect to server.
Desktop (please complete the following information):

OS: macOS
Version 12.6

Additional context
I haven't had any problems with other servers, only with those of Siteground

I do have the same issue with other hosters as well, not just siteground.
I think this could be related to some kind of version incompatibilites.
The servers I tested run on

OpenSSH v.8.9p1
OpenSSL 3.0.2


rustPackages.clippy: init at rust-1.36.0

Motivation for this change
This packages rust-clippy at the version specified by the git submodule at:
https://github.com/rust-lang/rust/tree/1.36.0/src/tools
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build rustPackages.clippy

Currently debugging:
cargo clippy -- -D clippy::all

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/nix/store/69hb0j56ds87l8xmijm0cg2ngdkc73dm-clippy-1.36.0/bin/clippy-driver /nix/store/yly9ihpxm0w19p4hdmkx6nrpja18kj7h-rustc-1.36.0/bin/rustc - --crate-name ___ --print=file-names -W rust-2018-idioms -D warnings --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (signal: 6, SIGABRT: process abort signal)
--- stderr
dyld: Library not loaded: @rpath/librustc_driver-ec53b32ba44677b6.dylib
  Referenced from: /nix/store/69hb0j56ds87l8xmijm0cg2ngdkc73dm-clippy-1.36.0/bin/clippy-driver
  Reason: image not found

I fixed the @rpath/librustc_driver-ec53b32ba44677b6.dylib issue by depending on rustc.

Could we build rustfmt in the same way (i.e. from the rustc source tarball)?

Could we build rustfmt in the same way (i.e. from the rustc source tarball)?

I suspect so.

I fixed the @rpath/librustc_driver-ec53b32ba44677b6.dylib issue by depending on rustc.

Somehow this error came back in a local build so don't merge yet.

Could we build rustfmt in the same way (i.e. from the rustc source tarball)?

I suspect so.

I actually quite like the idea to build it from the rust tarball since clippy is closely linked to rustc and this way we can ensure it will be in sync.

I fixed the @rpath/librustc_driver-ec53b32ba44677b6.dylib issue by depending on rustc.

Somehow this error came back in a local build so don't merge yet.

The following fixed the problem:
  preFixup = stdenv.lib.optionalString stdenv.isDarwin ''
    install_name_tool -add_rpath "${rustc}/lib" $out/bin/clippy-driver
  '';

And clippy works on my project. This is now ready for review.

@GrahamcOfBorg build rustPackages.clippy


Download latest episode only

I want to download the latest news clip from radio (https://radio.nrk.no/serie/dagsnytt/).
Is that possible to achieve? A “download latest”-parameter?

Fixed in #51


feat: support refresh testing explorer tree data

Types

[x] 🎉 New Features

Background or solution

PS: loading 效果没处理，收到后保留展开状态没处理
Changelog
支持测试资源管理器的树形结构的数据更新

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Codecov Report

Merging #321 (a7cd909) into main (a78c9a2) will increase coverage by 0.01%.
The diff coverage is 0.00%.

:exclamation: Current head a7cd909 differs from pull request most recent head d7c8ce1. Consider uploading reports for the commit d7c8ce1 to get more accurate results

@@            Coverage Diff             @@
##             main     #321      +/-   ##
==========================================
+ Coverage   59.31%   59.32%   +0.01%
==========================================
  Files        1182     1182
  Lines       72717    72719       +2
  Branches    15068    15068
==========================================
+ Hits        43129    43140      +11
+ Misses      26961    26955       -6
+ Partials     2627     2624       -3

Impacted Files
Coverage Δ

...ponents/src/recycle-tree/basic/tree-node.define.ts
8.16% <0.00%> (-0.35%)
:arrow_down:

...ackages/components/src/recycle-tree/basic/types.ts
100.00% <ø> (ø)

...ages/file-service/src/node/file-service-watcher.ts
70.05% <0.00%> (-1.13%)
:arrow_down:

...erences/src/browser/preference-settings.service.ts
79.86% <0.00%> (+0.69%)
:arrow_up:

...kages/theme/src/browser/workbench.theme.service.ts
71.21% <0.00%> (+0.89%)
:arrow_up:

packages/monaco/src/browser/schema-registry.ts
71.11% <0.00%> (+2.22%)
:arrow_up:

packages/core-common/src/node/port.ts
46.96% <0.00%> (+3.03%)
:arrow_up:

packages/file-service/src/browser/watcher.ts
100.00% <0.00%> (+4.34%)
:arrow_up:

...es/src/browser/userstorage/user-storage.service.ts
62.92% <0.00%> (+5.61%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a78c9a2...d7c8ce1. Read the comment docs.


Update README.md

It's important to uncheck the main branch only checkbox so you can use a gh-pages branch as outlined in the setting up GitHub pages section of this lab.

The gh-pages branch should be created by the enable github workflow.


[ExpertView] layout

status bar switch
50% column layout
expert view slides in from the right, use transition time and function consistent with the rest of the application
full screen
tabs (again)
when expert view takes 50% width - reflow the main layout (tabs and components have different paddings etc see here)

additional points:
resizable: no

a lot of this was done before while working on layout, so this is done together with #45


Release: Version v0.5.6 RC

:package: :rocket:

Builds ready [d3aa7e3]builds: chrome, firefox, opera
bundle viz: background, ui, portal-inpage, portal-contentscript, ui-libs, bg-libs, phishing-detect
dep viz: background
all artifacts


Leaving a comment to announcement post makes an empty comment

Describe the bug
I tried commenting on an announcement post from DevHub Community page and my comment is displayed as empty on near.org feed:

https://near.org/near/widget/ProfilePage?accountId=hot-ideas.community.devhub.near
It gets displayed on near.social just fine:
https://near.org/mob.near/widget/ProfilePage?accountId=hot-ideas.community.devhub.near
To Reproduce

Go to DevHub community with an announcement
Leave a comment to any of the announcements
See the empty comment

Expected behavior
The comment should be displayed normally.

It seems to me that when leaving a comment, you need to reload the page to actually see it. Happened both times for the comments here:
https://near.org/near/widget/ProfilePage?accountId=webassemblymusic.community.devhub.near&transactionHashes=FebHf1H1CAGhjWAmthkNRN5YGXgKpkNdcGjxaAqfwjuv

@petersalomonsen I was refreshing the page and even went to the profile feed (gateway native Profile Page), and the comment was empty up until maybe 10 minutes later.

@petersalomonsen I was refreshing the page and even went to the profile feed (gateway native Profile Page), and the comment was empty up until maybe 10 minutes later.

@frol For me, just one refresh was needed, I did not have to wait. The 10 minute delay you experienced, and that I also observed on your particular post, must have been a glitch then.
But still, refreshing should not be needed either, and seems reproducible, so I could look into that particular issue.

I think it is a bug on the indexing side, there is nothing we can do about it, so I’m closing this issue


Top 5 ide for java development

This issue solves #3575 . I have listed top 5 ide for java development and which helps others decide the IDE for their choice

Hii , you have added a new branch in the repo
Instead you should add all your content to our Backend_with_java domain branch and inside that make all changes to the desired folders
your content is good so thumbs up for that
please fork the repo again and make all changes in above specified path

I ll do that right now

https://github.com/girlscript/winter-of-contributing/pull/4053
here goes the new pull request .
hope have done it the right way this time


Allow collections to have a parm for options

Most of the items allow for a options hash, for example, text as in
users: collection('table tr', {
    firstName: text('td', { at: 0 }),
    lastName: text('td', { at: 1 })
  })

The options hash is providing the { at: 1}.  I had a set of divs inside a td and collection does not provide an options hash. The code I wrote was
rows: collection('.clinical-order-dispense table tbody tr', {
    dispenseDateTime: text('td', {at: 0}),
    serialNumber: text('td', {at: 1}),
    drugInformation: {
      scope: "td:nth-child(3)",
      drug: text('div', {at: 0}),
      lot: text('div', {at: 1}),
      expiration: text('div', {at: 2}),
      segment: text('div', {at: 3})
    },
    dispenseEye: text('td', {at: 3}),
    dispenseOverride: text('td', {at: 4})
  })

seems weird I can use { at: 2 } where needed except had to resort to td:nth-child(3)
If collection allowed for the option hash, I assume I could have written
rows: collection('.clinical-order-dispense table tbody tr', {
    dispenseDateTime: text('td', {at: 0}),
    serialNumber: text('td', {at: 1}),
    drugInformation: collection('td', { at: 2}, {
      drug: text('div', {at: 0}),
      lot: text('div', {at: 1}),
      expiration: text('div', {at: 2}),
      segment: text('div', {at: 3})
    },
    dispenseEye: text('td', {at: 3}),
    dispenseOverride: text('td', {at: 4})
  })

Hey, thank you for opening the ticket!
I think this is more related to components query API rather than collection API.
For instance, let's assume the following markup:

1

2

3

Here we have the same issue, so in order to reference children divs, we have to use nth-child:
{
  scope: '.MyComponent',
  column1: {
    scope: 'div:nth-child(1)'
  },
  column2: {
    scope: 'div:nth-child(2)'
  },
  column3: {
    scope: 'div:nth-child(3)'
  }
}

cause we don't have at api at component definition level. So if we really want to address this issue of anonymous positional elements selector, we should probably consider adding of at option to the component definition.
TBH, I'm not sure if we really have to improve positional query APIs(at), cause it can easily lead to fragile tests, for example when you just swap your columns, but everything keeps working properly from the functional point of view.
It might be not applicable for each project, but in order to avoid this issue, in my projects, I usually mark each column with it's own class or data-test attribute to avoid the need for selecting by position, so we have smth like:
{{#let "MyComponent" as |scope|}}

1

2

3

{{/let}}

const scope = .MyComponent';
{
  scope,
  column1: {
    scope: `${scope}-c1`
  },
  column2: {
    scope: `${scope}-c2`
  },
  column3: {
    scope: `${scope}-c3`
  }
}

which leads to a more stable page object, because we rely on semantic rather than position. Would it work for you? Is at still feels like a missing part in the component definition?

Yea I can definitively see that the drug information is not really a collection, but was the closest I saw. I in fact did use a component with the at encoded as a nth-child and having AT at the component level would have been more correct.    Assigning each inner div its own class would have removed the ATs on the 4 divs and Im fine with going that way.
The real crux of the matter is the at on the drugInformation, I suggested collection because thats were you are already teaching at, but agree an at on the component definition may be more accurate

I see what you mean, and I thiknk you are right. It seems a good idea to unify query API.
Though adding the second collection argument for query configuration may feel natural comparing to the rest of props like text(".class", { at: 1 }) it has its drawbacks, what if the collection item component does also have some query configuration?
  drugInformation: collection('td', {
    at: 2,
    resetScope: false
  }, {
    resetScope: true,
    text: text('div', { at: 1 })
  });

should resetScope be merged and who wins? That can be agreed, but still feels harder to reason about than we want it to be.
If talking about adding the at support at the definition, alongside the scope, testContainer and resetScope, I'd say it would pollute the definition and increase a risk(slight though) to collide with the user defined properties.
I believe a good approach could be to support scope as a query object, like described here.
With that we can easily achieve an aligned API, so you example would be possible to express, like:
  rows: collection('.clinical-order-dispense table tbody tr', {
    dispenseDateTime: text({
     selector: 'td',
     at: 0
    }),
    serialNumber: text({
      selector: 'td',
      at: 1
    }),
    drugInformation: {
      scope: {
        selector: "td:nth-child(3)",
        at: 2
      },
      drug: text({
        selector: 'div',
        at: 0
      }),
      // ...
    }
  })

What you have at the bottom is what I would have expected. You did combine selector and options, which makes scope work really well and the change to text() to combine them does make then all look and act the same. But the change to text() and other actions will be a large lift for everyone to upgrade.  I would hope you would plan on supporting text(string, options), and the new text(options) for a gradual migration.

Should this issue be closed and another open to actually implement the changes to at?

yes, I think we can close it, cause sounds like it's possible to lookup component by at within a collection.
And it'd be nice to figure out at inconsistent behavior, you've mentioned above, in a dedicated bug ticket.


Documentation

A basic documentation would be nice, as it's really hard to understand.

Hey any updates on this?


Material_TEST.py fails on debian buster amd64, arm64

Environment

OS Version: debian Buster amd64, arm64
Source or binary build? debbuilds for 6.11.0 failed to build

https://build.osrfoundation.org/job/ign-math6-debbuilder/1382/console
https://build.osrfoundation.org/job/ign-math6-debbuilder/1391/console

Description

Expected behavior: tests pass
Actual behavior: Material_TEST.py failed

======================================================================
ERROR: test_init (__main__.TestMaterial)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jenkins/workspace/ign-math6-debbuilder/build/ignition-math-6.11.0/src/python_pybind11/test/Material_TEST.py", line 34, in test_init
    for i in range(ignition.math.MaterialType.UNKNOWN_MATERIAL):
TypeError: 'ignition.math.MaterialType' object cannot be interpreted as an integer

----------------------------------------------------------------------

Steps to reproduce

Rebuild the following jobs:

https://build.osrfoundation.org/job/ign-math6-debbuilder/1382
https://build.osrfoundation.org/job/ign-math6-debbuilder/1391

Output

note that armhf works fine, this is just a problem with amd64 and arm64

Buster will be EOL this same month so my proposal here is to remove the buster directory unless the problem is present in other arches.

ok, we can just ignore the buster failures and delete the folder


Mu4e not found

What did you expect to happen?
I want to run mu4e since I have the module enabled.
What actually happened?
no such file or directory, mu4e
Additional details:
config
Steps to reproduce:

Enable mu4e in ~/.doom.d/init.el
Run bin/doom sync
Launch emacs and M-x =mu4e

System information:

emacs   version    27.0.50
        features   NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS JSON PDUMPER LCMS2 GMP
        build      Nov 26, 2019
        buildopts  (--prefix=/opt/local --without-dbus --without-gconf --without-libotf --without-m17n-flt --without-gpm --with-gnutls --with-xml2 --with-modules --infodir /opt/local/share/info/emacs --with-json --without-harfbuzz --with-ns --with-lcms2 'CFLAGS=-pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64' 'CPPFLAGS=-I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk' 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-no_pie -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64')
        windowsys  ns
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop, origin/develop, origin/HEAD 4b20c7206 2020-03-13 17:34:44 -0400
        dir        ~/.doom.d/
system  type       darwin
        config     x86_64-apple-darwin19.0.0
        shell      /opt/local/bin/zsh
        uname      Darwin 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan  9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64
        path       (~/.nix-profile/bin ~/.cargo/bin ~/.sdkman/candidates/sbt/current/bin ~/.config/yarn/bin/bin /Applications/MacPorts/Emacs.app/Contents/MacOS ~/.config/yarn/bin/bin/bin/bin ~/.config/yarn/bin/bin/bin /opt/pkg/bin /opt/local/bin /opt/local/sbin ~/.zplug/bin /opt/local/bin /opt/local/sbin ~/.cargo/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /Library/TeX/texbin /usr/local/MacGPG2/bin /opt/pkg/sbin /opt/pkg/bin /usr/local/texlive/2017/bin/x86_64-linux/ ~/.local/bin ~/go/bin /usr/local/plan9/bin /Applications/MacPorts/Emacs.app/Contents/MacOS/libexec/)
config  envfile    envvar-file
        elc-files  36
        modules    (:completion (company +icons) (ivy +icons) :ui doom doom-dashboard doom-quit hl-todo hydra indent-guides modeline nav-flash ophints (popup +defaults) pretty-code tabs treemacs unicode vc-gutter vi-tilde-fringe window-select workspaces :editor (evil +everywhere) file-templates fold lispy multiple-cursors parinfer snippets word-wrap :emacs (dired +icons) electric vc :checkers syntax spell grammar :tools debugger direnv docker editorconfig (eval +overlay) lookup (lsp +peek) macos magit make pdf rgb :lang cc clojure data emacs-lisp (go +lsp) (haskell +dante) (javascript +lsp) (latex +latexmk +cdlatex) markdown nix (org +dragndrop +brain +hugo +pandoc +pomodoro +present) rust sh web :email mu4e notmuch :app calendar irc :config (default +bindings +smartparens))
        packages   ((writefreely) (mu4e-alert))
        unpin      (n/a)
        elpa       (n/a)

See https://github.com/hlissner/doom-emacs/blob/develop/modules/email/mu4e/README.org
You need to install mu manually. Mu contains mu4e.

I installed mu from macports but I'll see if installing it from homebrew fixes it

Worked! Thanks!


Remove unnecessary file

file : https://github.com/the-moonLight0/Hactober-fest-2021/blob/c4b9b93f7fe941dcc26754766590c2f3fde23fdf/java_codes/Main.java

@the-moonLight0  assign this to me

@the-moonLight0 Looks like this issue is still open.
Would like to contribute to this one.


Persist Paused Process

Hi,
I am interested to take a challenge persisting the Process to DB. What's the best approach that should I take?

Persisting in JSON
Persisting in Binary using Gob
Others

Also mentioned in:

https://github.com/nitram509/lib-bpmn-engine/issues/32#issuecomment-1235500250

And what is the storage preferences?
I can do the persistence in Redis / SQLite for starter, later can be MySQL / Postgres, etc
Thank you.

Hi,
thanks, for having some discussion upfront and for your engagement to implement this.
When it comes to storage, I would like to remind ourselves about the architecture guidelines, as mentioned here https://nitram509.github.io/lib-bpmn-engine/
Here are some thoughts, on that

storage will not be handled by lib-bpmn-engine
just persistence is offered (as in marshaling and un-marshaling)
preferably, some human readable and simple format is used, like JSON

binary would be an option to optimize for marshaling size ... but I consider that not important at this point; since JSON can easily be compressed (ZIP) as well
no pretty printing - just straight, single-line JSON

there should be an option for lib users, to "plug in" their own marshallers - and JSON is per default available

this is similar as with the exporters

an example code snippet should document how to use it
there should be some meta-data, like version information be marshaled as well == that would help in future library upgrades/changes

Does this make sense?

closed, due to inactivity.


allow chrome options to be passed at runtime

Expected behavior
Should be able to pass chrome flags via taiko args, or as env variables.  This is to ensure that the same script can be run on docker/local machine.
Actual behavior
The options need to be in code. Example:
await openBrowser({args:['--no-sandbox', '--disable-setuid-sandbox']});

This prevents the script to be run in multiple environments.
Versions
Paste `node` and `taiko` versions here.

node v10.10.0
taiko v0.2.0

This does not work for
$ env TAIKO_BROWSER_ARGS=--window-size=1024,768 npx taiko --observe sample.js

sample.js
const { openBrowser, closeBrowser } = require('taiko');
(async () => {
    try {
        await openBrowser();
        screenshot()
    } catch (error) {
        console.error(error);
    } finally {
        await closeBrowser();
    }
})();

Possibly because we split using commas. There are a few options like these that have command in them.


[TASK] Bar Chart - Axis

Description
Create component for axis that can be used in multiple charts such as bar and line charts within AI Core
Existing
Reference
Tasks
Necessary features include:

[x] Show/hide each axis
[x] Add axis titles, show/hide axis titles
[x] Edit label font size
[x] Show tick marks
[x] Rotate axis values (by a degree amount)

Working on adding proper comments for the component files.


Feature_Request: Styling of the membership page and checkout page

Is your feature request related to a problem? Please describe.
The membership page looks very plain and does not match the website. The checkout page is not dynamic and is same even if we choose any package.
Describe the solution you'd like
Adding navbar, changing the background and changing the package price from dollar to rupees. The checkout page should be more dynamic and change according to the package the users select. Also styling of the checkout page to make it more user friendly.
Describe alternatives you've considered

Demo Video/Screenshot (Mandatory )

Are you contributing under any open-source program ?
Yes, GSSOC'24

@Archiesachin you are assigned.

@Archiesachin you are assigned.

Okay, will start working on it.


chatGPT models stuck at Thinking...

Started from ~ 2023-02-06 22:00 GMT. I cannot use these chatGPT models in VSCode. Other models from the dropdown list were fine. ChatGPT models got stuck at 'Thinking...'. I tested the web interface from chat.openai.com simultaneously, and the latter was working.
(I use the openAI API key for authentication in VSCode)

Did the API key method stop working? I'm getting the same thing now.

Which model are you using, what do you see in your settings.json? "chatgpt.gpt3.model": "text-davinci-003" is the default for the API Key method and it should work fine.

I am using the 'Pre-release ChatGPT' model.
On Thu, Feb 9, 2023 at 8:40 AM Ali Gençay @.***> wrote:

Which model are you using, what do you see in your settings.json? "chatgpt.gpt3.model":
"text-davinci-003" is the default for the API Key method and it should
work fine.
—
Reply to this email directly, view it on GitHub
https://github.com/gencay/vscode-chatgpt/issues/111#issuecomment-1424208162,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGYC3PQZOXWFRWPOBA5VB3LWWTXWPANCNFSM6AAAAAAUVQF7A4
.
You are receiving this because you commented.Message ID:
@.***>

So can we no longer use the Pre-release Research model via API Key? The Davini-003 model seems incapable of even basic coding tasks. Before I had no issue with the pre-release model.

Correct, it is removed by OpenAI since it was only a leaked model not an official one. You could use Browser Autologin method with "text-davinci-002-render".

Thanks for the info. Will a new model likely be added? or not until the official API becomes available?
Great work on the extension. Keep it up. Thank you

As I hear newly released models, I will enable them. If the extension doesn't have a model that you wish to use at any point, you could try it out by setting the model in your settings.json. It will show a warning message but still you should be able to try out until it becomes a supported model in the extension.

Would the text-chat-davinci-002-20230126 model work if I set it manually in the settings? Supposedly that is a new leaked model that works with the API.
Also, how exactly do I edit the settings.json file to add a new model? I'm not super familiar with using VS Code.

@cnaples79 it was a leaked model but it is now taken down by OpenAI. Currently, I don't know of a leaked model. This is how you update the settings.json with your preferred model (If you face 404/400 errors it means that the model doesn't exist):
Open settings.json file and add the following line with your preferred model name:
"chatgpt.gpt3.model": "_your_new_model_name_to_test_"

It'd show a warning if the model doesn't exist in the extension's pre-defined model names but it will still allow you to experiment with it.

Ah, I see. Unfortunately it looks like OpenAI is really starting to crack down on using the API...
Thank you for the information. And I appreciate all the work you do on the extension. It is a great help. Keep it up!


Fix documentation

Change use-east-1 to us-east-1.

Coverage: 93.702%. Remained the same when pulling 74e94e5ee0eace694ef72bcd3832408db42270d6 on brandonin:fix-documentation into 19c348503a3e6442c45548975f079c83751bdb01 on medplum:main.


No provider for: @jupyter-lsp/jupyterlab-lsp:ILSPAdapterManager

Hi, facing a weird issue with importing an instance of ILSPAdapterManager in our extension. I have tried with LSP versions 4.2.0 and 3.10.2, both.
Steps:

importing: import {ILSPAdapterManager} from '@jupyter-lsp/jupyterlab-lsp';
Putting it in requires and then in activate function of the extension and then using it:

const extensions = [{
  id: '<redacted>',
  requires: [ILSPAdapterManager],
  activate: async (app, adapterManager) => {
      adapterManager.registerAdapterType(...)
  }

It fails saying: index.es6.js:2289 Error: No provider for: @jupyter-lsp/jupyterlab-lsp:ILSPAdapterManager., similarly in the setup for 3.x version of LSP, it fails with: No provider for: @krassowski/jupyterlab-lsp:ILSPAdapterManager.
On putting a breakpoint there, I can see that a corresponding entry is present for these Tokens:

I am assuming the token its asking for and the token present are different "instances" even though the "name" of the tokens is the same. Any ideas?
....
One more thing is, I was able to get it working in a specific setup (by chance) with pip install jupyterlab-lsp==3.10.2 and having a dependency of lsp extension 4.2.0 in my project. Basically jupyterlab extension version was 4.2.0, but the python version was 3.10.2. In this specific combination using import {ILSPAdapterManager} from '@jupyter-lsp/jupyterlab-lsp, the extension comes up! But that leads to double instances of the extension, hence this is not a clean solution.

For the JS version you may want to try something like:
{
"sharedPackages": {
   "@jupyter-lsp/jupyterlab-lsp": {
     "bundled": false,
     "singleton": true,
     "strictVersion": true
   }
 }
}

in your package.json. See: https://jupyterlab.readthedocs.io/en/stable/extension/extension_dev.html#deduplication-of-dependencies

Another thing to try if the above does not help: can you require ILSPExtension token? If so, this could be a bug in other tokens having mismatching IDs vs plugins that provide them.

I added that shared packages, didn't help. Also, the other tokens like ILSPExtension, etc. are also not found.
As a hack, tried setting the instance to a global variable in adapter_manager.ts inside activate function:
      let wam = new WidgetAdapterManager(shell);
      console.log("Inside LSP. Setting the adatper manager");
      console.log(wam)
      window.lspAdapterManager = wam;
      return wam;

Then in my extension reading it using window.lspAdapterManager. Both the instances are same..

The registeration (adapterManager.registerAdapterType) also goes through but the extension doesn't come up! :(

The way I am installing is the extension from local is:

Inside both the python packages jupyter_lsp and jupyterlab_lsp, i am doing pip install .
Under packages/jupyterlab-lsp, I have done a yarn link and linked it to my swb extension.

---Ideally the above steps should have installed the extension, but the changes were not coming in the application's node_modules, so the 3rd step---

Did jupyter labextension install .

Do you think these steps might lead to any duplication of the extension installed and the token which is in my extension vs which is getting registered are different? 🤔

Put debugger points and was able to understand that the issue is that it sets the language server here (the Private.setLanguageServerManager in connection_manager.ts):
(notice the file location)

Whereas the Private.getLanguageServerManager() is called here (inside my extension's node_modules):

Because of the mismatch of these file locations, its not able to get the language server manager when its invoked. How to install the extension and also use it as a dependency in my local extension without this separation of concerns 🤔

As you correctly notice you extension ships a copy of jupyterlab-lsp but it should not. As previously mentioned, configuring sharedPackages within jupyterlab stanza of package.json should ensure that webpack resolves it correctly. I know that you already tried that, but seeing my comment now it may have not been obvious that it needs to go within the jupyterlab stanza. Can you give it another go?

As for the installation, I do not see why you would use yarn link, unless you are forking this extension. Normally it would be just adding it to the dependencies. On jupyter labextension install - are you using it to install your own extension, or jupyterlab-lsp? I would say it should never be used except for deployment of source extensions. For development of your own extension jupyter labextension develop is appropriate. For dependencies, these should not be explicitly installed but handled by the package manager of choice (jlpm/yarn/npm) and configured in package.json for webpack to de-duplicate. If you had indeed forked jupyterlab-lsp locally for some reason, installing a second copy via pip would indeed lead to two different copies.
This is about as much as I can help without more detailed info or reproducer.

You should not need to do that. While they are not exported from index.ts, these are themselves all exported symbols, so you should be able to access them from lib:
import {WidgetAdapterManager} from '@jupyter-lsp/jupyterlab-lsp/lib/adapter_manager';

This is of course not ideal, which is why it was reworked for JupyterLab 4/jupyterlab-lsp 5.0.
Does this help?

I tried that only initially, but it was leading to same issue of file duplication. The two locations:
<EMAIL_ADDRESS><EMAIL_ADDRESS>
The Private.setLanguageServerManager() was getting called in connection-manager.js and the getter is called in connection-manager.ts.
Putting the exports solved this issue. But the issue was solved for a specific environment of python version 3.10 and other version 4.2.0 (which I cloned in my local and made these export changes on top of and linked to my swb extension).
If I use just one of the versions, then I am unable to bypass the issue of No provider for: @jupyter-lsp/jupyterlab-lsp:ILSPAdapterManager, which brings us to the starting of this issue thread 😄.
P.S. can we export these in the Open source version of 4.x? I can raise the PR and you can help releasing a corresponding version, then I won't have to make a local copy and export these statements.

Feel welcome to open a PR.
Regarding ILSPAdapterManager/de-duplication:

ensure sharedPackages setting gets picked up from your package.json; you can test it by putting a dependency on fake version of @jupyter-lsp/jupyterlab-lsp in dependencies, say ^100.0 and enabling strictVersion.

Great! I was able to resolve the issue :) Basically I was doing an additional pip install of jupyterlab-lsp. But still had to export the classes.
Raised this PR: https://github.com/jupyter-lsp/jupyterlab-lsp/pull/980. Would require your help in merging it and releasing a version we can use.
Also, can we change the configuration settings (like Automatic hover) while deploying?
Thanks.

Hi, I guess the PR got missed. Would need your help in getting this merged :) - https://github.com/jupyter-lsp/jupyterlab-lsp/pull/980

Checking back, did https://github.com/jupyter-lsp/jupyterlab-lsp/pull/980 fix the issue for you @skbitsp?

Closing as resolved, feel welcome to open any follow-up issues.


Node tests setup

Adding in Node testing

@jeffmaher @LynnHerrick9 Our tests are officially working! I tested it with both passing and failing tests and it's working as expected so I think we are good to merge this in once you both look it over and approve. Thanks team!


VO doesn't read the "select turn variable" label

Similar in the look up or down screen, VO doesn't read the second label


Proposal: Do expression and async do expression

This is an experimental PR to support ECMAScript proposal do expression.
Proposal: Do expression and Async do expression
Spec: Do expression and Async do expression
PR preview Playground
Known problems / TODOs:

[ ] Completion type analysis should be based on control flow analysis.
[ ] There're many false positives on the Not all code paths return a value check.
[ ] break or continue inside the for head doesn't lead to a type error (there is no spec yet, only a memo so I don't know how to implement this.)
[ ] The following code will report type error:

function f(param: number) {
    const double = do {
        if (param === 0) return null;
        param * param;
    }
    return double
}

Type evaluation rule of the do expression:
I made a change to the checker of typescript. Here are the new evaluation rules:

Every statement might return void or Type as a type checking result. If it returns void, it is treated as not contribute to the type of the statement.

New type evaluation rules
New Expressions

DoExpression: type of its containing block statement. if there is none, fallback to voidType.

Statements
Statement:

BlockStatement: type is last type of it's inner statement.
VariableStatement: SyntaxError
EmptyStatement: Does not contribute. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation
ExpressionStatement: type of it's containing expression
IfStatement: union type of all branches. if there is no else block, it will treated as voidType
BreakableStatement:

IterationStatement: SyntaxError

SwitchStatement: union type of all clauses

ContinueStatement: never
BreakStatement: never
ReturnStatement: never
WithStatement: any
LabelledStatement: type of it's inner statement
ThrowStatement: never
TryStatement: union type of try clause and catch clause. finally clause is ignored.
DebuggerStatement: Does not contribute. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation

Extra checks
A var declaration cannot be used within a do expression unless the target is ESNext
function a() {
    (do {
        var x = 1;
        x;
    });
    x; // 1
}

Not all code paths return a value
Requires noImplicitReturns to be true

Inlay hints
Show all "exit points" of the do expression to make it easier to identify.

I need to make a new thing called checkStatement that will return a Type

I need to make a new thing called checkStatement that will return a Type

A very naive type-level behavior is done

A very naive type-level behavior is done

Cool!
Let me (us) know if you want to make a tarball package and a playground.

Cool!
Let me (us) know if you want to make a tarball package and a playground.

@Kingwl hi most of the semantics is done(except downlevel compiling), can you create a playground for this?

@Kingwl hi most of the semantics is done(except downlevel compiling), can you create a playground for this?

oh wait here is CI error

oh wait here is CI error

@typescript-bot pack this.

@typescript-bot pack this.

@typescript-bot pack this

@typescript-bot pack this

Known problem: transpile will crash if there is else if in the do-expr. will fix later.

Known problem: transpile will crash if there is else if in the do-expr. will fix later.

@Kingwl hi I fix lots of bugs plz make a new pack thanks!

@Kingwl hi I fix lots of bugs plz make a new pack thanks!

@typescript-bot pack this

@typescript-bot pack this

Looking through the spec, () => do { 1 } should be allowed and is currently an error (ex). The babel implementation allows it (ex)
The do expression is added to PrimaryExpression syntax in the spec, looking at the definition of arrow function we can get to  a Primary expression without adding any tokens:
Full Path
https://tc39.es/ecma262/#sec-arrow-function-definitions
https://tc39.es/ecma262/#prod-ExpressionBody
https://tc39.es/ecma262/#prod-ConciseBody
https://tc39.es/ecma262/#prod-AssignmentExpression
https://tc39.es/ecma262/#prod-ConditionalExpression
https://tc39.es/ecma262/#prod-ShortCircuitExpression
https://tc39.es/ecma262/#prod-LogicalORExpression
https://tc39.es/ecma262/#prod-CoalesceExpression
https://tc39.es/ecma262/#prod-BitwiseORExpression
https://tc39.es/ecma262/#prod-EqualityExpression
https://tc39.es/ecma262/#prod-RelationalExpression
https://tc39.es/ecma262/#prod-ShiftExpression
https://tc39.es/ecma262/#prod-AdditiveExpression
https://tc39.es/ecma262/#prod-MultiplicativeExpression
https://tc39.es/ecma262/#prod-ExponentiationExpression
https://tc39.es/ecma262/#prod-UnaryExpression
https://tc39.es/ecma262/#prod-UpdateExpression
https://tc39.es/ecma262/#prod-LeftHandSideExpression
https://tc39.es/ecma262/#prod-NewExpression
https://tc39.es/ecma262/#prod-MemberExpression
https://tc39.es/ecma262/#prod-PrimaryExpression

Looking through the spec, () => do { 1 } should be allowed and is currently an error (ex). The babel implementation allows it (ex)
The do expression is added to PrimaryExpression syntax in the spec, looking at the definition of arrow function we can get to  a Primary expression without adding any tokens:
Full Path
https://tc39.es/ecma262/#sec-arrow-function-definitions
https://tc39.es/ecma262/#prod-ExpressionBody
https://tc39.es/ecma262/#prod-ConciseBody
https://tc39.es/ecma262/#prod-AssignmentExpression
https://tc39.es/ecma262/#prod-ConditionalExpression
https://tc39.es/ecma262/#prod-ShortCircuitExpression
https://tc39.es/ecma262/#prod-LogicalORExpression
https://tc39.es/ecma262/#prod-CoalesceExpression
https://tc39.es/ecma262/#prod-BitwiseORExpression
https://tc39.es/ecma262/#prod-EqualityExpression
https://tc39.es/ecma262/#prod-RelationalExpression
https://tc39.es/ecma262/#prod-ShiftExpression
https://tc39.es/ecma262/#prod-AdditiveExpression
https://tc39.es/ecma262/#prod-MultiplicativeExpression
https://tc39.es/ecma262/#prod-ExponentiationExpression
https://tc39.es/ecma262/#prod-UnaryExpression
https://tc39.es/ecma262/#prod-UpdateExpression
https://tc39.es/ecma262/#prod-LeftHandSideExpression
https://tc39.es/ecma262/#prod-NewExpression
https://tc39.es/ecma262/#prod-MemberExpression
https://tc39.es/ecma262/#prod-PrimaryExpression

Thanks for your report! I will checkout it later.

Thanks for your report! I will checkout it later.

Just wondering because of this, is Typescript accepting PRs for ES proposals that haven't been added yet?

Just wondering because of this, is Typescript accepting PRs for ES proposals that haven't been added yet?

is Typescript accepting PRs for ES proposals that haven't been added yet?

Nope.

is Typescript accepting PRs for ES proposals that haven't been added yet?

Nope.

And the PR will definitely not be approved until it's stage 3.

And the PR will definitely not be approved until it's stage 3.

No it's must be stage 3 to be accepted. This is just a playground.
Another thing to mention is, do expression proposal is considering to remove the limitation of not able to return continue or break in the do block. So I will not touch those features these days.
I may add async do expressions to this PR later because they are slightly related.

No it's must be stage 3 to be accepted. This is just a playground.
Another thing to mention is, do expression proposal is considering to remove the limitation of not able to return continue or break in the do block. So I will not touch those features these days.
I may add async do expressions to this PR later because they are slightly related.

@Kingwl hi I've just added support for async do expression can you create a new playground?

Sure.
@typescript-bot pack this.

Recently do expression has changed their semantics to allow break, continue, and return across the do expression boundary and it becomes very tricky to compile those expressions. See https://github.com/bakkot/do-expressions-v2/issues/9 for details. I'll consider how to compile this correctly so the emit in those cases are currently invalid.

I'd like to ask for some advice from the TypeScript team (I don't know who I should ping, maybe @rbuckton? 👀) about how to implement this.
It is possible to transform do expression into the form of (expr, expr2, expr3) if the inner statements met some special requirements. But that need to track and rename variable names in the transformation stage. Consider the following code:
const x = do {
    function y() { return x }
    let x = 1
    y
}

Can be transformed into
let _a, _b
const x = ((_a = function y() { return _a }), (_b = 1), _a)

But in this transform, I need to track the lexical usage of x and y and replace them with the temp variable. Should I implement this optimization? The full rule of the optimized output is documented here.
If the TypeScript team thought it's worthy to implement this for an inline output, how should I do the usage analysis during the transform stage? If it is not worthy please tell me and I'm not going to code this part.

And another question, which way is preferred?

(The benefit of yield way is I can convert return-in-do into a problem yield-in-do that already solved.)

@Kingwl hi, can you pack this? I fixed some bugs. break continue and return across the boundary are still in progress. Thanks!

Sure.
@typescript-bot pack this.

Some progress on control flow changes within do expression. (Note I temporarily disabled the transform of do expression because it does not work well with the control flow transform).

A bit more progress, supports break/continue in iteration statements (not labeled statement or switch)

I have rewritten the transformer to support break/continue/return. The new transformation is new and incomplete but it might handle the most common cases. Note the following items is known not handled correctly:

var hoist across the block
return in the function parameter initializer
break/continue in the non-body position of a loop.
switch

@Kingwl hi, can you pack this? Thanks.

Sure.

@Kingwl hi can you pack this thanks!

@typescript-bot pack this.

Oops, seems I cannot trigger ts bot anymore.
@orta mighty give you some help.

@typescript-bot pack this.

Updates:

Transform: fix return inside parameter of a function
Transform: fix var declared variable hoisting
Transform: support break through switch statement
Transform: fix in class fields
LSP: support inlay hint for all exit points of the do expression

@orta Hi can you let the bot pack this?

Got some problems with break analysis...

close for now. I'll re-open and rebase this once the proposal gets advanced.


feat(io): compat async stream for futures

The type AsyncStream is exacted from cyper-core. It provides a stream with futures io impls to provide convenience.

What happened to the test

It always occurs if you haven't run the test in GitHub action for a long time, but a rerun would usually fix it. I don't understand the reason.


Change unnecessary t.Error

What this PR does / why we need it:
Inside the retry loop, before we hit the max retry limit, we shouldn't use t.Error() to indicate a test failure.
An example here: https://k8s-gubernator.appspot.com/build/istio-prow/pull/istio_istio/950/e2e-cluster_wide-auth/56/
W1002 20:31:34.171] I1002 20:31:34.170548    2659 demo_test.go:370] Success! Version migration acts as expected, old version hit 49, new version hit 50
W1002 20:31:34.171] I1002 20:31:34.170580    2659 commonUtils.go:82] Running command kubectl delete -n istio-system -f /tmp/demo_test175913297/route-rule-reviews-50-v3.yaml
W1002 20:31:34.620] I1002 20:31:34.619802    2659 commonUtils.go:86] Command output:
W1002 20:31:34.620]  routerule "reviews-default" deleted
W1002 20:31:34.620] , err: <nil>
W1002 20:31:34.621] I1002 20:31:34.619829    2659 demo_test.go:248] Waiting for rule to be cleaned up...
I1002 20:32:04.622] --- FAIL: TestVersionMigration (77.75s)
I1002 20:32:04.622] 	demo_test.go:350: unexpected response status 503

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

none

@yutongz: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
f8568cbee0bcd6d0ea4bbf3f6c36ac059f96461a
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/lgtm

@yutongz: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-cluster_wide-auth.sh
8e7cb648d2d1af112e0349a838546f87675590fe
link
/test e2e-cluster_wide-auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


F8 shortcut for static code analysis does not work

Description
What steps will reproduce the problem?
Open a file with spyder and press F8.
What is the expected output? What do you see instead?
I expect that the static code analysis is executed and the result is shown in the corresponding window. Instead nothing happens.
Please provide any additional information below
spyder_pylint.pylint.Pylint.run_pylint() is not executed when F8 is pressed despite self.register_shortcut() being called in spyder_pylint.pylint.Pylint.register_plugin() on startup.
Version and main components

Spyder Version: 3.0.1
Python Version: 3.5.2+
Qt Versions: 5.6.1, PyQt5 5.7 on Ubuntu 16.10

Dependencies
pyflakes >=0.6.0 :  1.2.3 (OK)
pep8 >=0.6       :  1.7.0 (OK)
pygments >=2.0   :  2.1.3 (OK)
qtconsole >=4.2.0:  None (NOK)
nbconvert >=4.0  :  None (NOK)
pandas >=0.13.1  :  0.17.1 (OK)
numpy >=1.7      :  1.11.1rc1 (OK)
sphinx >=0.6.6   :  1.4.8 (OK)
rope >=0.9.4     :  None (NOK)
jedi >=0.8.1     :  0.9.0 (OK)
psutil >=0.3     :  4.2.0 (OK)
matplotlib >=1.0 :  1.5.2rc2 (OK)
pylint >=0.25    :  1.5.6 (OK)

It's working for me :-/

Can you give me some hints where in the code I have to trace the keypress (to see where it fails)?

I am not sure if this is a related case, or a different bug, but it seems to break in this case:

Manually paste a file path to analyze into the Static code analysis pane
Click Analyze
Click the file in the editor
Press F8

This leads to some weird state, where the file path box is blank, but the "Analyze" button is enabled. Clicking "Analyze" throws an error.
Clicking the arrow next to the file path box only shows the files analyzed with F8, but not the ones manually pasted in.

I retested spyder 3.2.6+dfsg1-2 on Ubuntu 18.04 and F8 works there as expected. So I am closing this ticket.
@danuker Your issue looks like a different problem. Please open a separate ticket.


Using borrowing On String Causes Compiler Error

Description

When using the borrowing parameter on a String in an enum initializer the compiler reports the following error:
Copy of noncopyable typed value. This is a compiler bug. Please file a bug with a small example of the bug

I've attached a code sample demonstrating this behavior in the next section. This error occurs if the scenario is on the same enum with a static function borrowing a String or a regular function.
Steps to reproduce

Compiling the following code snippet will produce the error using Swift 5.9:
public enum LineEnding: String {
    /// The default unix `\n` character
    case lineFeed = "\n"
    /// MacOS line ending `\r` character
    case carriageReturn = "\r"
    /// Windows line ending sequence `\r\n`
    case carriageReturnLineFeed = "\r\n"

    /// Initialize a line ending from a line string.
    /// - Parameter line: The line to use
    public init?(line: borrowing String) {
        guard let lastChar = line.last, // ❌ Copy of noncopyable typed value. This is a compiler bug. Please file a bug with a small example of the bug
              let lineEnding = LineEnding(rawValue: String(lastChar)) else { return nil }
        self = lineEnding
    }

    // These also cause the same error:
    static func makeLineEnding(_ line: borrowing String) -> LineEnding? {
         guard let lastChar = line.last, // ❌ ...
         ...
    }

    func makeLineEnding(_ line: borrowing String) -> LineEnding? {
        guard let lastChar = line.last, // ❌ ...
         ...
    }
}

Expected behavior

The initializer, static function, or member function should be able to borrow a String value to ensure the value isn't copied.

Environment

swift-driver version: 1.87.1 Apple Swift version 5.9 (swiftlang-<IP_ADDRESS>.108 clang-15<IP_ADDRESS>)
Xcode 15.0, Build version 15A240d
Target: arm64-apple-macosx13.0

Regression test added in https://github.com/apple/swift/pull/74361 .


Txt2Al fails with wrong Error message: Element RequestPage does not support property Name

This wrong error message appeared when a "CaptionML" property is set for a RequestPage.
After deleting this property, the conversion was fine.

the error message says "Name" but correct would be "CaptionML" (see issue: Element RequestPage does not support property Name)

Hi @MaKnauer, which version of the server are you using?
As I understood, the issue was supposed to be related with the use of CaptionML on request pages. I tried creating a new report with a request page containing a CaptionML and it got successfully converted into AL code and I didn't get any error from the txt2al.
Was I missing something to reproduce it?
Did you export your object using ExportToNewSyntax?
Can you try reproducing it using our latest containers?

Closing this issue due to inactivity. If you are still experiencing this problem on our latest version, please open an other issue containing the .txt file you used in the txt2al and some information on how you created the file.


🐛 Installing via pip in clean environment gives numpy error on np.float?

Environment information

mqt bench 1.1.3
python 3.11

Description
When installing and trying to use mqt.bench, the import functions throw an attribute error:
AttributeError: np.float_ was removed in the NumPy 2.0 release. Use np.float64 instead.
Referenced code:
from mqt.bench import get_benchmark
"get a benchmark circuit on algorithmic level representing the GHZ state with 5 qubits
qc_algorithmic_level = get_benchmark(benchmark_name="dj", level="alg", circuit_size=5)
"draw the circuit
print(qc_algorithmic_level.draw())
Expected behavior
Successful import
How to Reproduce

Clean Environment
pip install mqt.bench
execute reference code

Hey 👋🏻
Thanks for raising this issue. This is just another case of incompatibility with numpy 2.0.
You can work around this for now by installing any numpy version < 2.
pip install --force-reinstall "numpy<2"

I'll keep this issue open until we put a temporary upper cap on numpy in MQT Bench itself.


Bars(Volume bars/Histogram) represented offchart, not scaling properly

## Observe the volume of the last second candle in Test 7.  The blue volume bar is 571, but the visual representation estimates it to 500, on the volume offchart.

@C451  added the screen shot

Run npm run test (on existing code)
Go to DataHelper test( Test 7)
Observe the Volume value corresponding to the blue candle, and see the level it is set to in the offchart.


No smooth vertical scrolling inside of HorizontalPager

When I try scrolling the markdown content inside of a HorizontalPager, it is clear that the scrolling is not smooth and that even trying to scroll back to the top is intermittent. I know that this has to do with the "compose-markdown" because if I replace the compose-markdown with a scrollable column with lots of text, the scrolling is very smooth.

Hi @JohannRosenberg
Could you send a video showing the issue and provide more details?