cargo fmt --all is slow in a workspace project

Problem
cargo fmt --all runs unexpectedly slow in a medium-sized workspace project.
Steps

Run a GitHub workflow that runs cargo fmt --all on the repository.
Check execution time.

This run shows rustfmt and/or cargo pausing for more than 20 s before producing any output in verbose mode. Seen with timestamps in the raw log:
2020-06-08T17:05:32.3268959Z [command]/usr/share/rust/.cargo/bin/cargo fmt --all --verbose -- --check --verbose
2020-06-08T17:05:55.8733086Z [bench (2018)] "/home/runner/work/chain-libs/chain-libs/btree/benches/benchmark.rs"

Notes
Output of cargo version:
cargo 1.44.0 (05d080faa 2020-05-06)
Output of rustfmt --version
rustfmt 1.4.14-stable (e417356 2020-04-21)
Virtual environment information from GitHub workflow:
Operating System
Ubuntu
18.04.4
LTS
Virtual Environment
Environment: ubuntu-18.04
Version: 20200518.1
Included Software: https://github.com/actions/virtual-environments/blob/ubuntu18/20200518.1/images/linux/Ubuntu1804-README.md

Originally filed as https://github.com/rust-lang/cargo/issues/8345.

Closing as the problem was tracked down to a cargo issue after all.

This is because rustfmt uses cargo-metadata to find the root file of each project.
By default, rustfmt uses the offline mode of cargo-metadata and falls back to the online mode when it fails. I assume the slowdown you observed is caused by the connection delay; when running cargo fmt --all, we need the cargo index file to be present.

As noted by @ehuss in https://github.com/rust-lang/cargo/issues/8345#issuecomment-641469796:

Sorry, I should have specified in my comment. The issue is here where cargo-fmt calls cargo metadata for every package, twice. It should only call it once for the entire workspace. I was going to make some recommendations over on the rustfmt tracker.

@mzabaluev - does your project have non-workspace member local/path-based dependencies that you also want to format? Running cargo fmt (without the --all) in the root of a workspace will format all the crates in a workspace by default. The --all flag isn't necessary in most situations.
From the cargo fmt help text:
--all                          Format all packages, and also their local path-based dependencies

FYI the multiple cargo metadata calls rustfmt is making is due to https://github.com/rust-lang/cargo/issues/7483 :smile:

@calebcartwright Thanks for the tip! One of our larger projects does use path-based dependencies pulled in by a git submodule, but these can be format-checked in a CI workflow of that submodule's repository.

Great! In that case I'd recommend just running cargo fmt and dropping the --all flag so you won't have to worry about the registry index at all

@calebcartwright I can help rework the logic for the --all case if you'd like. I don't see that it is necessary to re-fetch the metadata for each package, so it should be able to do it just once.  I'm not too familiar with rustfmt development, but I can try to make a PR.

@ehuss - sure! The --all use case is a bit of a pain, especially with the need to maintain the behavior when cargo fmt is executed from subdirectories within the workspace, so any improvements there would certainly be appreciated.
Additionally, it would also be really helpful for rustfmt if we can get a solution/alternative to rust-lang/cargo#7483 so that we can always use --no-deps while still being able to locate the paths for the non-workspace member local/path based dependencies that also get formatted with --all

Ran into this today as well, and was confused both why cargo fmt --all took 20 s while cargo fmt took 1.3 s, and why in our workspace the appeared to work identically.
This was on Windows (though through Git Bash) in a workspace of 28 crates.
$ time cargo fmt --all

real    0m20.996s
user    0m0.000s
sys     0m0.000s

$ time cargo fmt

real    0m1.298s
user    0m0.000s
sys     0m0.016s

All of our crates are in our root Cargo.toml, so I guess don't need --all. But for other cargo commands we use --workspace (which used to be called --all) to indicate that we want to operate over all the crates in the workspace.

I think the main issue here is the disconnect between what the --all flag means and when it's actually needed with cargo fmt vs. what folks, understandbly but often incorrectly, assume based on what --all meant previously with other cargo subcommands. (Refs https://github.com/rust-lang/rustfmt/issues/3911)
Background
There's only a few use cases I recall where the --all flag with cargo fmt is currently helpful/meaningful:

Running cargo fmt in a subdirectory of an explicit workspace where you want to run formatting commands against the entire workspace/all the explicit workspace members (all members are formatted by default when running from the root of an explicit workspace)
Running cargo fmt in the root directory of an implicit workspace where you want to run formatting commands against all implicit workspace members
Running cargo fmt against a given package which has one more local/path based dependencies where you want to run the formatting commands against the current package and that local/path based package (as well as any local/path based deps that package may have, recursively).

I suspect that the majority of instances where folks are using the --all flag with cargo fmt falls into those first two buckets, while the third is relatively more of an edge case.
cargo fmt currently leverages the cargo metadata command in order to discover the workspace information which is then used to construct the corresponding rustfmt commands; cargo fmt does not directly parse Cargo.toml files.
Accordingly, in order to support the second (and third) use case, cargo fmt --all runs cargo metadata without the --no-deps flag (due to https://github.com/rust-lang/cargo/issues/7483) to ensure that the cargo metadata output contains the information that cargo fmt needs in order to properly locate and format those implicit workspace members/path-based dependencies.
AIUI, running cargo metadata without the --no-deps flag results in the registry index hit that is presumably the cause of the increased run time folks are seeing which is probably rather apparent in CI-type environments.
Next Steps
We've tried updating the help text for the --all flag though that certainly hasn't solved the disconnect, and I believe we probably need to take additional action to try to ameliorate the confusion.
Perhaps some non-mutually exlusive actions we could consider:

Create/augment cargo fmt documentation to try to provide better guidance on when --all is required vs. when it should likely be avoided.
Find a way to support formatting implicit workspaces without the index implications and associated perf hit

Stick with cargo metadata and work on addressing https://github.com/rust-lang/cargo/issues/7483
Find an alternative to cargo metadata to get workspace information (parse Cargo.toml files directly, etc.)

Change behavior of existing cargo fmt flags and/or add new flags (this would almost certainly result in a breaking change that'd require a major version bump). For example, we could add a --workspace or even --explicit-workspace) flag that would support the first use case (explicit workspaces) and use --all, or even rename/replace it with --implicit-workspace to support the second and third use case

(Actually, even if there are no breaking changes, it'd be nice to rename this flag and add a deprecated alias for it, maybe even hiding that from the help text in the future).

@calebcartwright Since it looks like https://github.com/rust-lang/cargo/pull/8994 is probably going in the right direction, maybe it'd make sense to start up a draft PR here that uses it when available so we can maybe even fix this on the next beta (which I think is Dec 31st). What do you think? If you're busy I can try to find some spare cycles to write it up, though you know the code better than I do.

so we can maybe even fix this on the next beta (which I think is Dec 31st)

Won't commit to any target timeframe just yet, especially given the holidays, but yes will try to get this out soon once possible to proceed. Unfortunately due the various non-rustup channels through which rustfmt is distributed and can be used there will be a bit of extra complexity to handle working with older versions of cargo that may not the newer changes.
I'm also not sure if the cargo_metadata crate will need to first be updated as well before we can start taking advantage of https://github.com/rust-lang/cargo/pull/8994

Yeah, I think we'll probably have to track whether we see a local dependency (source == null) but not a manifest_path, and in that case fall back to the current way of doing things. It's not pretty, but I agree we can't drop support for older cargos.
I'll take a look at adding support to cargo_metadata 👍

There's a promising new upstream PR here that might unblock this: https://github.com/rust-lang/cargo/pull/9024

https://github.com/rust-lang/cargo/pull/8994 was merged, and will land (if all goes according to plan) in 1.51. The change to cargo_metadata is in https://github.com/oli-obk/cargo_metadata/pull/149.

https://github.com/rust-lang/cargo/pull/8994 was merged, and will land (if all goes according to plan) in 1.51. The change to cargo_metadata is in https://github.com/oli-obk/cargo_metadata/pull/149.

https://github.com/oli-obk/cargo_metadata/pull/149 has been merged @calebcartwright, so I think we now have all we need to start working on an implementation in fmt!

https://github.com/oli-obk/cargo_metadata/pull/149 has been merged @calebcartwright, so I think we now have all we need to start working on an implementation in fmt!

@calebcartwright I believe the updated cargo_metadata is now also released 🎉

Thanks @jonhoo, planning on looking at it this week

@calebcartwright Gentle bump on this — have you had a time to think more about this vs #4722?

@calebcartwright Gentle bump on this — have you had a time to think more about this vs #4722?

@jonhoo  - stretched rather thin and having to juggle 20 different things. This is on the top of my list for whenever I get a chance to actually work on some rustfmt development, but right now my limited rustfmt bandwidth is preoccupied with other general support and maintenance activities.
I also want to stress that there is no either/or here. We're definitely going to make this change, and there's a good chance we'll probably go forward with #4722 as well.
However, really important to note that #4722 would only be at play with explicit workspaces, but if you have an explicit workspace you do not need to use --all anyway (unless you just really want to format you want to format your entire workspace from within subdirectories). If you've not set up an explicit workspace, but instead have just structured your project with relative path depdencies between your packages (e.g. like Clippy or RLS), then you do need --all and #4722 has 0 impact on that use case.

The resolution for this will be in the next release. Purely anecdotal data points on my slow machine so treat them as such, but suffice to say that folks using --all should notice some marked performance improvements. I'm observing execution time going from multiple minutes down to 1-2 seconds in an uncached/clean environment, and from 30 seconds down to that same 1-2 seconds in a cached/dev laptop type env.


Investigating compatibility with macOS Ventura

I can't say I really know what I'm doing, but when I opened the project
it mentioned that there were a number of things that were out of date.
So I'm fixing them and trying to compile them again.
I understand that the warnings I dismissed when I did this mentioned that these
changes may not be reversible and I acknowledge I'm still learning how to work
with Xcode projects.
My ultimate goal here is to have compatibility for versions supported previous to
Ventura and also macOS going forward.
I'll be using this PR to work through those learning so any line comments or
direct comments are very much appreciated.
This should hopefully address issues found in #252

So it seems like it's working again! I'm not sure what I did but I will say that I did follow the Troubleshooting section in the README and then restarted my computer. After a couple of days it started working again! So I'm closing this. Thanks @akitchen


Feat: update mutate tests

This PR updates mutate test to create 10 mutation policies for load testing.
✗ ./start.sh tests/kyverno-mutate.js 1 1
Running tests/kyverno-mutate.js...
installing 10 mutate policies
Policies data has been written to /tmp/policies.json file
clusterpolicy.kyverno.io/policy-0 created
clusterpolicy.kyverno.io/policy-2 created
clusterpolicy.kyverno.io/policy-7 created
clusterpolicy.kyverno.io/policy-6 created
clusterpolicy.kyverno.io/policy-5 created
clusterpolicy.kyverno.io/policy-9 created
clusterpolicy.kyverno.io/policy-8 created
clusterpolicy.kyverno.io/policy-3 created
clusterpolicy.kyverno.io/policy-1 created
clusterpolicy.kyverno.io/policy-4 created
clusterpolicy.kyverno.io/policy-0 condition met
clusterpolicy.kyverno.io/policy-1 condition met
clusterpolicy.kyverno.io/policy-2 condition met
clusterpolicy.kyverno.io/policy-3 condition met
clusterpolicy.kyverno.io/policy-4 condition met
clusterpolicy.kyverno.io/policy-5 condition met
clusterpolicy.kyverno.io/policy-6 condition met
clusterpolicy.kyverno.io/policy-7 condition met
clusterpolicy.kyverno.io/policy-8 condition met
clusterpolicy.kyverno.io/policy-9 condition met
Deploying namespace...
namespace/load-tests created
Deploying RBAC...
serviceaccount/load-test created
clusterrolebinding.rbac.authorization.k8s.io/load-test created
secret/load-test-token created
Creating configmap...
configmap/load-test created
Deploying k6 job...
job.batch/load-test created
Waiting for the job to finish...
job.batch/load-test condition met
Getting job exit code...
Job exit code: 0
Extracting logs and summary...
Clean up job and configmap...
job.batch "load-test" deleted
configmap "load-test" deleted
clusterrolebinding.rbac.authorization.k8s.io "load-test" deleted
Clean up...
namespace "load-tests" deleted
cleaning up 10 mutate policies
clusterpolicy.kyverno.io "policy-0" deleted
clusterpolicy.kyverno.io "policy-2" deleted
clusterpolicy.kyverno.io "policy-7" deleted
clusterpolicy.kyverno.io "policy-6" deleted
clusterpolicy.kyverno.io "policy-5" deleted
clusterpolicy.kyverno.io "policy-9" deleted
clusterpolicy.kyverno.io "policy-8" deleted
clusterpolicy.kyverno.io "policy-3" deleted
clusterpolicy.kyverno.io "policy-1" deleted
clusterpolicy.kyverno.io "policy-4" deleted

Instead if hardcoding the number of policies we can use env vars. I would also argue against hard-coding the name of the test in the start script. The original way I did it using setup is the best way I believe. It's controlled by k6 and reports the creation status in the final report.


[Tooling] Prompts that return data don't display correctly in Dev UI

When using a model that returns DataPart instead of text, the prompt playground doesn't display anything:

@mbleigh do you have a quick example (or model) we should look at?

Try literally any JSON-mode output in Gemini now. Now that Gemini natively supports JSON mode, the returned parts are [{data: {...}] instead of e.g. [{text: "```json\n{...}\n```"]

I see.... right under my nose. :) I had no idea. Thanks!


Regression on kf push behavior

In attempting to push an app (not using the gke-plugin) I was not able to push. Here is a simple example.
hev@Adams-MacBook-Pro-2 logspinner (master *%)$ kf push logspinner --container-registry $KF_REGISTRY
2019/05/15 09:52:50 Error accessing gcr.io/<PROJECT_ID>/src-logspinner-155793556937478100010467595470431939847:latest, falling back on a clean slate: MANIFEST_UNKNOWN: Failed to fetch "latest" from request "/v2/<PROJECT_ID/src-logspinner-155793556937478100010467595470431939847/manifests/latest".
Error: Error computing delta layer: lstat : no such file or directory
Error computing delta layer: lstat : no such file or directory

Can you post the git SHA that kf was built from?

Tested originally with 32504b57


Add support to passthrough platform health probes

Reference #474.
kube-inject extract both liveness and readiness ports and passes it along to the sidecar proxy.
Other non-functional refactoring changes:

move proxy content to top-level and use it whenever appropriate
clean up main function to reuse existing structs in the flags
introduce ServiceAccounts interface in addition to ServiceDiscovery to keep auth functionality isolated
rename ControllerConfig to ControllerOptions to be consistent with other code

Jenkins job manager/presubmit passed

Jenkins job manager/presubmit passed

Ok, I can drop this PR and split it into two if that makes it easier.


Diagnostic and actions handlers are missing

Do you plan to support those handlers in the near future or are they out of scope?

I am trying to do it myself, but I'm pretty newb with plugins in general, how can I source my luafile and overwrite handlers to test it?

The issue is that Neovim LSP does have a function to retrieve all diagnostics (vim.lsp.diagnostic.get()) but we cannot redefine the handler for that function. This is because that handler is used to display the warnings/erros next to the code so we don't want to mess with that.
So this means we have to create our own command which would call vim.lsp.diagnostic.get() and process the results. It shouldn't be complicated, I'll do it this week or the next.
About code_action I don't really see the point of using FZF in that case. There is no location to jump to, there is just a list from which to select an action. It's quicker to type 2 to select action 2 than to use FZF I'd say. So it's not a priority but maybe I'll add a command after the one for the diagnostics.

Regarding diagnostic, Yeah, I think we could be fine by just providing a EX command that we can use in our remaps instead of using handlers.
Regarding actions, well, to me it happens to have also 10 actions to select from, and FZF can be helpful to filter quickly, and in general to have an unique "popup" system.

I'm working on both right now in branch dev you can try it out.
Diagnostics works fine, I've added a :LspDiagnostics command.
I haven't tested code actions yet because my LSP servers don't support them. Can you suggest me a LSP server which have some code actions I can try?

TSServer has a lot of actions.
Tomorrow morning I'll try your branch.

Almost perfect.
One side note, if there are no actions, I would print a message.

I've merged dev into main, now the plugin supports diagnostics and code actions.


Merge changes required by AGL

Sane defaults to make arbitrary board build successfully

Review Score: 11/11


Speed Question

Hi!! Thanks for sharing your codes.
I have seen your result in your paper about bi-seg. I tried to reproduce the result of bi-seg, however I only got 71%IOU（single scale）, have you successfully got 74% IOU results on that? May be he use ms test.
what is your advantages compared with bi-seg? More Light (Less memory cost)?

There are two problems:

I test your model with 1024 * 2048 as input images. However I only got  9 fps on single 1080TI.
I use the code like the following
start = time.time()
out = model(img)
torch.cuda.synchronize()
print('Speed: {} fps.'.format(1.0/(time.time()-start)))
In your paper, ICnet only 16 fps which is not consistent with his paper. (30 fps)
I don't why. The gap between K80 and 1080TI is such large ??

Hi , @wutianyiRosun
Did you use this line ?
torch.cuda.synchronize() for speed test?

@lxtGH @wutianyiRosun
I have a problem:
Pytorch DwConv's implement is not good,it's very slow. The CGNet'paper result is based on Pytorch?

@wutianyiRosun If you didn't use the line of code, your speed reported in your paper is wrong.
@yyfyan What speed results you get ?

I got the same result as you, a single 1080Ti got about 9 FPS. @lxtGH
And if I didn't use torch.cuda.synchronize()
The FPS will increase to ~70Fps, this code is necessary.

@Reagan1311 Yes, GPU and CPU must synchronize (CPU must wait until the end of GPU forwarding )

10FPS only! I test it on 1080Ti.
I suggest that you change your arxive paper.

I met the same question. I hope I can get an answer. Thank you.

@meteorshowers, @LinZhuoChen  We will update in the next few days.


Add json schema validation for source data at the interface level

Should close #42.

@CodyCBakerPhD
This is ready. Three things:

Some of the typing was missing. There were some things marked as value: float = None where I had to mark them as optional because the JSON schema would fail to validate. I am surprised that Pydantic missed that. This adds to the point that you made before that both have different strengths, maybe?
I created a way to clarify which source arguments are used to initialize an extractor in the extractor interfaces. The problem is that we pass everything to the super init where it is validated but sometimes we modify the arguments names within the interface and the JSON validation fails. I think it is better to have this explicit anyway (explicit is better than implicit).
Some of the typing was infraspecific, for example in the MockRecording the typing for durations was tuple(int) but apparently it needs to be tuple(int, ...) to indicate there is more than one.

Some of the typing was missing. There were some things marked as value: float = None where I had to mark them as optional because the JSON schema would fail to validate. I am surprised that Pydantic missed that. This adds to the point that you made before that both have different strengths, maybe?

I too am surprised by this, but maybe not so much - docval in HDMF behaves similarly, where you don't need to indicate None is a possible value to be passed to an argument even if that is exactly its default value. I think Pydantic does not consider the typing vs. default a fundamental incompatability since the validation call only checks if the user specified (not default) input matches annotation type. If user specifies same as default value, I also don't know what would happen but suppose it would ignore

I created a way to clarify which source arguments are used to initialize an extractor in the extractor interfaces. The problem is that we pass everything to the super init where it is validated but sometimes we modify the arguments names within the interface and the JSON validation fails. I think it is better to have this explicit anyway (explicit is better than implicit).

Nice - yeah that has always proved a subtle pain point, since we do utilize additional kwargs in the interface __init__ that are not a part of the extractor kwargs, usually to perform 'extra' metadata or neo related operations

Some of the typing was infraspecific, for example in the MockRecording the typing for durations was tuple(int) but apparently it needs to be tuple(int, ...) to indicate there is more than one.

Good catches - accurate validation must rely on accurate annotations, which have only ever been used so far as a form of developer communication

Just beware, this (like the Pydantic one before it) could potentially break custom conversion pipelines using latest/dev NeuroConv by requiring them to use accurate annotations on all interface __init__

Just beware, this (like the Pydantic one before it) could potentially break custom conversion pipelines using latest/dev NeuroConv by requiring them to use accurate annotations on all interface __init__

This is a very important point.
Just to be clear:  if they were using NWBConverter before this PR should not change things, right? Validation was already done there:
https://github.com/catalystneuro/neuroconv/blob/f28410598cfbf830dd7f25ff774c5cf6553273f9/src/neuroconv/nwbconverter.py#L45-L85

Just to be clear: if they were using NWBConverter before this PR should not change things, right? Validation was already done there:

I suppose that's true, but I've been guilty myself of using ConverterPipes sometimes
What is mildly annoying now is that JSON validation occurs in both NWBConverter initialization and individual interface initialization, but overall benefit is probably worth it in the end

What is mildly annoying now is that JSON validation occurs in both NWBConverter initialization and individual interface initialization, but overall benefit is probably worth it in the end

Agree with it, I would think long term on how to avoid the overlap.


Adds support for transferring env state to/from client

Description
Currently Visdom handles serialization with save, but this means that log files end up in a different place to the rest of the project. This PR adds a set_window_data function that, together with the existing get_window_data, can be used to serialize data on the client.
It also fixes get_window_data/close by changing win=None to win='all', as _send assumes None means 'create a new window' and helpfully fills in win=None with a random string.
How Has This Been Tested?
I've manually checked it works for setting the data of environments that don't currently exist on the server. It doesn't yet work for updating environments that already exist - what's the right way to trigger a reload on all the clients?
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[ ] For JavaScript changes, I have re-generated the minified JavaScript code.

In theory this is a breaking change, as win='all' would mean windows can no longer be named 'all'. It works here, but I think the need for this is exposing that we've outgrown the setup for _send and should likely be abstracting the sending functionality for send types that are intentionally trying to target all windows.
As far as being able to force reloads on the frontends, you can use the globally defined function broadcast_envs(self) from any handler.

Good point about it being a messy API. I've changed it to passing create=False to _send to indicate that win=None means 'broadcast'. Made for a smaller modification than splitting the _send function in two.


Switch to CodeCov for coverage tracking

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@2a50093). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #161   +/-   ##
=========================================
  Coverage          ?   92.43%
=========================================
  Files             ?       23
  Lines             ?      238
  Branches          ?        0
=========================================
  Hits              ?      220
  Misses            ?       18
  Partials          ?        0

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 2a50093...22015bf. Read the comment docs.


plutus-tx: convert the prelude functions to use unfoldings rather than TH

Seems to be going okay so far, but I had to mess with the playground a bit.
I'll move on to plutus-wallet-api next.

Eek, that doesn't happen locally, that shouldn't be possible :scream:

Ugh, it's only on darwin, of course.

That was an enormous pain. I had to come up with two different workarounds for Haddock and doctests, but I have managed to get both of them working, and I think the workarounds are relatively stable.

Sorry, keep changing my mind here. I think we should merge this soonish as it has the build-related changes. I'll keep doing further changes to the object-level code in follow up PRs.
Will merge in a bit pending comments.


Replace "self" with "player" on the set player's speed output

more like adding target input and having "player" as default?

fixed on last commit


AccessDenied when opening task as worker

I set up per instructions and invited a worker. The worker can login but gets a red error message when opening the task prompting them to reload the page.
Appears to receive a 403 when creating a signed URL to the resource: https://s3.ap-southeast-2.amazonaws.com/multipagepdfa2i-multipagepdfa2i1be8d0a8-1w7g66m5qd0wi/wip/... with AccessDenied message.
The pngs do get created, but it looks like there is insufficient privileges to create signed urls.

Hello @bakersemail! Sorry for the slow reply! Are you still experiencing this issue? If so, could you provide the specific text the red error message has - without including any person information including account numbers, etc.


Credit data source

https://github.com/LrLamonier/dead-by-api

App now just pulls description from the wiki itself.


Use setPrototypeOf for inheritance on any browser with support

ES6 class static inheritance requires the use of Object.setPrototypeOf. In #2375 I tried multiple ways to work around this because setPrototypeOf caries performance warnings, but all of the things I tried ended up breaking my code in non-trivial ways.
Both Babel and Traceur use setPrototypeOf.
This is becoming a larger issue by the day as more and more code begins to fully take advantage of ES6 style inheritance. I cannot find any real data on the performance hit or if it perhaps it only performs worse when changing a prototype after instantiation.
If this is not acceptable inside Google than we may need to add a flag that opts Google projects out of this, but externally we need to make this change.
Polymer requires this (the code breaks without it).

With things as they are inheritance of static methods in compiled code is not correct by the ES6 spec, but  is consistent in old and new browsers.
With this change compiled code behavior will no longer be consistent. Newer browsers will get correct ES6 static method inheritance, while older ones continue with the broken behavior.
I want to do this, but I want to make sure users are warned of this inconsistency appropriately.
I believe we already have checks for stuff like this and treat it as an error in at least some cases.
class A {
  static foo() {}
}

class B extends A {
}

B.foo();

According to
MDN
setPrototypeOf wasn't standardized until ES6, but has been available at least IE11.
Our polyfill for it works if __proto__ is available, which may get a few more browsers,
but still no IE < 11.
@MatrixFrog has some definite opinions on this, so I'm assigning it to him for further discussion.

Correct - this only works back through IE11. Babel uses __proto__ as a fallback, but it really doesn't appreciably increase support (you get a few old versions of Opera I believe).
Here's the Polymer code that doesn't work without this:
/**
 * Called by `ElementClass.finalize()`. Ensures this `klass` and
 * *all superclasses* are finalized by traversing the prototype chain
 * and calling `klass.finalize()`.
 * @param {HTMLElement} klass
 * @private
 */
function finalizeClassAndSuper(klass) {
  let proto = klass.prototype;
  let superCtor = Object.getPrototypeOf(proto).constructor;
  if (superCtor.prototype instanceof PolymerElement) {
    superCtor.finalize();
  }
  finalizeClass(klass);
}

It's perfectly valid code.

I'd continue to find work arounds except that EVERY other transpiler uses setPrototypeOf.

Oh also, as in #2375 if you extend code from another transpiler, the properties won't be enumerable and copying the descriptors fails.

We already polyfill setPrototypeOf using __proto__ so if we just call setPrototypeOf then we're already getting that little bit of extra support. I'm happy to use setPrototypeOf as long as we have some fallback that works on browsers that don't have it (or __proto__) which means we might need to add a flag to control which way the transpilation is done. Which is not great but seems to be necessary as a short term solution until we have ES6 output.

How about this?
Add an argument to the $jscomp.inherits() method to indicate whether it should do setPrototypeOf or copying. The compiler will use this argument to disable the ES6-compatible behavior when the output mode is ES3 and enable it otherwise.

Do we gain anything with the flag? setPrototypeOf should provide better support - not less. It doesn't change the semantics of hasOwnProperty. Other than performance this should be a straight up win.
If it's for performance, then sure - this makes sense.

The point of my suggestion is to ensure that folks who are building with ES3 output get consistent behavior across browsers and do not have their code start crashing on older browsers without any warning from us.
Everyone else will benefit from the new setPrototypeOf goodness.
We might also add a warning when compiling such cases to ES3.

@brad4d @MatrixFrog I've added a parameter to then inherits function to specify whether the languageOut is ES5 or higher. That was a bit trickier than I expected - quite a few places depend on the number of arguments in the inherits function.

@ChadKillingsworth
Sorry I didn't see your reply.
Here's an scenario to explain why we need this hidden behind a flag.
Project Fooey:

Adopted ES6 classes a year ago and is very happy with them.
Must run on browsers back as far as IE9, but fortunately not earlier, so they specify --language_out=ES5. This allows them to rely on the existence of e.g. Array.prototype.some even though we don't have a polyfill for that. Also they can use getters and setters, which we cannot transpile to ES3.
Is not relying on the "full" ES6 behavior for inheritance of static methods, because of course we don't support it. However, they work with what we have and their code works the same on all browsers.

Now, suppose we fix things so we support ES6 behavior in browsers where we can, but fall back when we can't. No problems at first for Project Fooey (probably), because they wrote their code assuming the old behavior which is still pretty much the same.
Then someone on Project Fooey (or worse on some team that writes a code library Fooey uses), starts writing code that depends on the full ES6 static inheritance working. This is very likely to happen. Not everything gets tested on the older browsers.
Suddenly Project Fooey sees mysterious breakages on the older browsers, and they have no idea why.
Finding the cause could take a very long time and prove very difficult to fix.

As discussed, I added a compiler option to control whether setPrototypeOf is used for inheritance. It is on by default. You'll need to add an internal flag to disable it.

Rebased and updated to account for the transpilation refactoring by @MatrixFrog.

Rebased again

FYI there will be merge conflicts with #2415 on tests. So which ever is merged first the other PR will need updated.

I've imported this and resolved conflicts in the imported version.
It causes one of our internal tests to fail.
I'm looking into that.

Fixed that test & realized more needed to be done to make sure internal default is to have this option off for now. Added a CommandLineRunner flag that defaults to on, because the option itself needs to default to off to make sure our tests run in the expected mode.
Running first line of submission tests now, with the "test all the things" run to happen if that passes.

Any reason this can't be done with an @define rather than a whole separate flag?  It looks like the only change is in the runtime library.

@shicks Is there a way to default an @define inside Google? We want the default externally to be to use setPrototypeOf.

Just had further discussion on this with @concavelenz and @shicks
@ChadKillingsworth I think you'll be happy to hear that the consensus now is we should go with your original intention of just using setPrototypeOf() if possible and doing the property copy loop if not.
The problem described in this comment remains.
https://github.com/google/closure-compiler/pull/2419#issuecomment-297865487
However, our justification for allowing this is that teams that do not test on older browsers must assume their code does not work there.
We do need to make an implementation change to this PR, though.
It's problematic to use methods in $jscomp.inherits() that are possibly polyfilled themselves,
so we need to have a $jscomp.setPrototypeOf() method that returns true for success and false for failure.
I've filed issue #2529 for that.

I have this work done and compiler tests passing, but I want to test it locally before I push it up (since the runtime tests can't be executed externally).

This works on my project - but it needs tested on a project with older browsers (and of course the runtime tests).

imported
looking over the change with @shicks

tests look mostly good so far
just a small change needed to the function type signature of $jscomp.setPrototypeOf. It needs to allow null for the prototype argument.
Also added some suppression comments to eliminate compiler warnings for the 'use ...'; statement strings.
I won't bother pushing these changes back to this PR's branch unless there turns out to be more to do before we submit internally.

Found a few more things to fix, but nothing big.
Continuing internal review.

Working on an internal change to just define $jscomp.setPrototypeOf, then another to do this PR.
I've sent the first of those for review.

Definition of $jscomp.setPrototypeOf is trying to submit now.
I keep hitting type errors with one test or another when different options are enabled, but I think this will do it.

Still trying to submit $jscom.setPrototypeOf change. Delayed due to internal system issue unrelated to the change itself.
Final change is in review, and I hope to submit it immediately afterwards.

Submit of final change is processing now.

Fix submitted & should be in today's github push.


Documentation Isn't Building Completely

The readthedocs site isn't building all of the documentation (specifically, the API reference). I think the autodoc extension needs to be enabled.

Agreed, I have to jump into the RTD chatroom to request it. I'll do that ASAP.

Looks like this fixed itself! If only more bugs did that.

Looks like the API reference is building now, but without the models module. @bryanveloso Think you could take a look?

/home/docs/sites/readthedocs.org/checkouts/readthedocs.org/user_builds/django-imagekit/checkouts/latest/docs/apireference.rst:8: WARNING: autodoc can't import/find module 'imagekit.models', it reported error: "Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.", please check your spelling and sys.path
/home/docs/sites/readthedocs.org/checkouts/readthedocs.org/user_builds/django-imagekit/checkouts/latest/docs/apireference.rst:22: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/docs/sites/readthedocs.org/checkouts/readthedocs.org/user_builds/django-imagekit/checkouts/latest/docs/index.rst:10: WARNING: autodoc can't import/find module 'imagekit.management.commands.ikflush', it reported error: "Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.", please check your spelling and sys.path
/home/docs/sites/readthedocs.org/checkouts/readthedocs.org/user_builds/django-imagekit/checkouts/latest/docs/_themes/README.rst:: WARNING: document isn't included in any toctree
WARNING: html_static_path entry '/home/docs/sites/readthedocs.org/checkouts/readthedocs.org/user_builds/django-imagekit/checkouts/latest/docs/_static' does not exist

These are the errors that I've been getting with regards to the missing modules. I think that's still a bug with RTD, but I'll do some more digging.


[QUESTION] Logging to Application Insights

Description
I'm trying to send logs for my app to Azure Application Insights. I've tried following steps from this article: https://github.com/microsoft/ApplicationInsights-Python
Namely the section called "Basic logging configuration (second option)". I've setup the logger, added my instrumentation key, but I don't see anything going to Application Insights, or to the logs of my container. This could be unrelated to FastAPI, but I'm not sure. Here's a snippet of my code
from fastapi import FastAPI
import logging
from applicationinsights.logging import enable, LoggingHandler
from features import FeaturesRequest
from XGB_New_Cust_80_Feature import predict_output_new_customer
from XGB_Rep_Cust_80_Feature import predict_output_repeat_customer

app = FastAPI(openapi_prefix="/risk-model")

instrumentation_key = '<my instrumentation key>'
try:
    with open("/keyvault/ApplicationInsights__InstrumentationKey", "r")as f:
        instrumentation_key = f.read()
except IOError:
    pass

enable(instrumentation_key)

handler = LoggingHandler(instrumentation_key)

logging.basicConfig(handlers=[ handler ], format='%(levelname)s: %(message)s', level=logging.DEBUG)
logger = logging.getLogger("main")

@app.post("/risk-predictions/new-customers")
async def new_customer_risk_prediction(features: FeaturesRequest):
    logger.info(features)
    prediction = predict_output_new_customer(features)

    return {
        "prediction": prediction[0][0],
        "model": prediction[1]
    }

@app.post("/risk-predictions/existing-customers")
async def existing_customer_risk_prediction(features: FeaturesRequest):
    logger.info(features)
    prediction = predict_output_repeat_customer(features)

    return {
        "prediction": prediction[0][0],
        "model": prediction[1]
    }

Additional context
Add any other context or screenshots about the feature request here.

Thanks for the help here @victoraugustolls! 🍰🚀
And thanks @bwoods89 for reporting back and closing the issue. 🎉

For anyone who might drop by. I've created fastapi middleware that can be added for opencencus tracer
import logging

from fastapi import Request
from opencensus.trace import (
    attributes_helper,
    execution_context,
    print_exporter,
    samplers,
)
from opencensus.trace import span as span_module
from opencensus.trace import tracer as tracer_module
from opencensus.trace import utils
from opencensus.trace.propagation import trace_context_http_header_format
from starlette.types import ASGIApp

HTTP_HOST = attributes_helper.COMMON_ATTRIBUTES["HTTP_HOST"]
HTTP_METHOD = attributes_helper.COMMON_ATTRIBUTES["HTTP_METHOD"]
HTTP_PATH = attributes_helper.COMMON_ATTRIBUTES["HTTP_PATH"]
HTTP_ROUTE = attributes_helper.COMMON_ATTRIBUTES["HTTP_ROUTE"]
HTTP_URL = attributes_helper.COMMON_ATTRIBUTES["HTTP_URL"]
HTTP_STATUS_CODE = attributes_helper.COMMON_ATTRIBUTES["HTTP_STATUS_CODE"]

module_logger = logging.getLogger(__name__)

class TracerMiddleware:
    def __init__(
        self,
        app: ASGIApp,
        excludelist_paths=None,
        excludelist_hostnames=None,
        sampler=None,
        exporter=None,
        propagator=None,
    ) -> None:
        self.app = app
        self.excludelist_paths = excludelist_paths
        self.excludelist_hostnames = excludelist_hostnames
        self.sampler = sampler or samplers.AlwaysOnSampler()
        self.exporter = exporter or print_exporter.PrintExporter()
        self.propagator = (
            propagator or trace_context_http_header_format.TraceContextPropagator()
        )

    async def __call__(self, request: Request, call_next):

        # Do not trace if the url is in the exclude list
        if utils.disable_tracing_url(str(request.url), self.excludelist_paths):
            return await call_next(request)

        try:
            span_context = self.propagator.from_headers(request.headers)

            tracer = tracer_module.Tracer(
                span_context=span_context,
                sampler=self.sampler,
                exporter=self.exporter,
                propagator=self.propagator,
            )
        except Exception:  # pragma: NO COVER
            module_logger.error("Failed to trace request", exc_info=True)
            return await call_next(request)

        try:
            span = tracer.start_span()
            span.span_kind = span_module.SpanKind.SERVER
            span.name = "[{}]{}".format(request.method, request.url)
            tracer.add_attribute_to_current_span(HTTP_HOST, request.url.hostname)
            tracer.add_attribute_to_current_span(HTTP_METHOD, request.method)
            tracer.add_attribute_to_current_span(HTTP_PATH, request.url.path)
            tracer.add_attribute_to_current_span(HTTP_URL, str(request.url))
            execution_context.set_opencensus_attr(
                "excludelist_hostnames", self.excludelist_hostnames
            )
        except Exception:  # pragma: NO COVER
            module_logger.error("Failed to trace request", exc_info=True)

        response = await call_next(request)
        try:
            tracer.add_attribute_to_current_span(HTTP_STATUS_CODE, response.status_code)
        except Exception:  # pragma: NO COVER
            module_logger.error("Failed to trace response", exc_info=True)
        finally:
            tracer.end_span()
            return response

It is heavily inspired by the flask middleware.
You can add the middleware by
app.middleware("http")(TracerMiddleware(app))


PSResourceRepository: Add property Reasons

Pull Request (PR) description

PSResourceRepository

The resource now supports the read-only property Reasons that the
compliance part (audit via Azure Policy) of Azure AutoManage Machine
Configuration uses.

This Pull Request (PR) fixes the following issues
None.
Task list

[x] Added an entry to the change log under the Unreleased section of the
file CHANGELOG.md. Entry should say what was changed and how that
affects users (if applicable), and reference the issue being resolved
(if applicable).
[ ] Resource documentation added/updated in README.md.
[ ] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[x] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[x] Unit tests added/updated. See DSC Community Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Community Testing Guidelines.
[x] New/changed code adheres to DSC Community Style Guidelines.

This change is

@nickgw if you have time, it would be great if you could help to review this one. 🙂

So there is an issue using the property Reasons using type [Reason]. Reproduced by @nyanhp, configuration script fail to parse when two modules (psm1 files) contain the class Reason. Same happens for MOF-based resources.

@nyanhp created a repository that shows the issue with both class-based resources and MOF-based resources.

Closing this PR until there is a solution for this, but most likely not gonna be a fix for WMF5.x.

Seems there is a fix for this, will update this PR.

This PR should be changed according to https://github.com/dsccommunity/DscResource.Base/issues/4. It should also wait for PR #405 is merged so we don't need to do the same modification in this module as being done in DscResource.Base.

@PlagueHO this one is now ready for review. The module DscResource.Base got a fix that was released as v1.1 to support this change.
I will fix the resources over at SqlServerDsc the same way.

@PlagueHO this good to continue reviw and merge if everything looks good. I couldn't find an easy way to return a hashtable for the property Reason to avoid the need for a unique class in each module, but couldn't find a way, so I reverted to using a uniqe class instead (CMReason, and in SqlServerDsc it will be called SqlReason). The important part is that the object that is returned have the correct properties. I also added an integration test to verify the property Reason by using Invoke-DscResource that calls the method Get().


--bind command clears when capturing output in variable

Category

[X] fzf binary
[ ] fzf-tmux script
[ ] Key bindings
[ ] Completion
[ ] Vim
[ ] Neovim
[ ] Etc.

OS

[X] Linux
[ ] Mac OS X
[ ] Windows
[ ] Windows Subsystem for Linux
[ ] Etc.

Shell

[X] bash
[ ] zsh
[ ] fish

Issue
If I want to capture the output of an fzf command (or pipe it to a next command), --bind commands that print things (using less) do not seem to work (I can only see the terminal flashing).
It seems like it is launching less, but then exiting it for some reason
Example function
Here is an example of things going wrong.
What I basically want to achieve is a git commit browser like you show on your wiki page, but it should also output the commit hash, so that I could use it in the following way: git commit --fixup=$(gcb)
gcb()
{
    local commit

    commit=$(git log --graph --date=relative --abbrev-commit --color=always --pretty=tformat:'%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%an %ad)%Creset' | \
        fzf --height=95% --ansi --no-sort --reverse --tiebreak=index \
        --bind=ctrl-s:toggle-sort \
        --bind "ctrl-g:execute:(echo {} | grep -o '[a-f0-9]\\{7\\}' | xargs -I % sh -c 'git show --color=always % 1>&2 | less -R')" \
        --bind "ctrl-f:execute:(echo {} | grep -o '[a-f0-9]\\{7\\}' | xargs -I % sh -c 'git show --color=always --name-status -r % 1>&2 | less -R')" \
    ) || return

    commit=${commit:2}
    echo ${commit%% *}
}

Note that inside the --bind commands, I needed to pipe the output from stdout to stderr (1>&2), because otherwise it would all be caught in the output commit variable.

Version: fzf 0.18.0
 fzf --bind "enter:execute(less {})" executes less somehow silently when it inside a command substitution $() but it still works with process substitution <()
Maybe someone can clarify it for us!?
You may get expected behaviour and your commit by this approach instead:
mapfile -t out < <(..fzf..)
[ -n "$out" ] && ..echo.."

though I don't know how to catch exit code of <() properly.

Instead of 1>&2 I saw Junegunn once did in an example by redirect to /dev/tty. So something like this would work for you:
--bind "ctrl-g:execute:(git show --color=always $(grep -m1 -o '[a-f0-9]\{7,40\}' <<< {} | head -1 ) | less -R > /dev/tty)" \

Maybe someone could give a clue why output execute() of fzf inside $() or <() flickered and disappeared?
Note:

better matching from at least 7 to 40 for SHA1 because 7 still ambiguous in big project
-m1 stop at first matching line and |head -1 so you don't get multiple results in case committer mentions about another commits in the first commit line

better matching from at least 7 to 40 for SHA1 because 7 still ambiguous in big project
-m1 stop at first matching line and |head -1 so you don't get multiple results in case committer mentions about another commits in the first commit line

This seems nice, and I will probably use it. Thanks!

why not use --expect or --bind your git commit --fixup to a key, it's more convenient without much typing or getting error by abort

The reason for this, is so that the command can be used for more than just git commit --fixup.
By having a command that returns a commit, you can use it for fixup, rebasing, ...
Anything that takes a git commit hash can work with this log browser so this increases its potential.


Expand datasource entity in explorer based on some conditions

Fixes #932

I see a problem in this @Nikhil-Nandagopal as when a DB integrations is not correct, it will show errors when requesting the structure
https://www.loom.com/share/81c5273b6d524b9681b577671e93c3ff

I see a problem in this @Nikhil-Nandagopal as when a DB integrations is not correct, it will show errors when requesting the structure
https://www.loom.com/share/81c5273b6d524b9681b577671e93c3ff

@hetunandu we've decided we'll fail silently with a message under the data source that we were unable to retrieve the structure


W2V Smartbin Solution

Hi!
Thank you for your interest in our program! The Robonomics team has started reviewing the proposal, stay tuned.

Hi @Fingerling42
We corrected the proposal. Thank you for your patience

Hi @Geri-X
We discussed your project and the team liked the idea of plastic recycling tokenization. As we understand, you want to assemble one smart bin prototype, and in principle, you already have all the schemes for this. But my colleagues had questions about the budget and about the details of the planned work.
Mainly, we give grants for research projects (often teams from universities) or projects doing proof-of-concept. The assembly and testing of smart bin with blockchainization fits into this. But in your budget, 30% of the grant is allocated for marketing, and the team does not understand the scope of tasks and the expected results that are supposed to be obtained for it. For example, do you want to showcase your prototype somewhere (maybe malls, exhibitions, universities)? Or maybe you want to participate in some PR events, conferences? All this is worth describing in “Expected results”, and also disclosed in “Project Schedule”. Also, the items “Software for recycling center” and “Blockchain integration” also lack additional detail about the planned tasks, at least approximately, for example, an architectural diagram of software components.
Unfortunately, the main problem is that due to internal changes in our project last month, we were forced to suspend the grant program, at least until the end of the summer. Considering that the proposal needs to be improved and that we would not like to lose contact with your project, we can proceed as follows. If at the beginning of September 2022, the grant is still relevant to you, we can return to reviewing your proposal again.
Please let me know what you think about this.
Best,
Ivan

Hi @Fingerling42
Thank you for your interest! I'm sure that together we can make our world a cleaner place.
As for our smart-bin solution, we have an opportunity to partner with a large supermarket vendor in Ukraine. Marketing costs can be discussed separately.
Our concept of a tokenized recyclable materials exchange was interested in Oracle. At the meeting with them I told about your interest in a hardware solution.
Based on current events in Ukraine, I think the optimistic release date for the container will be October-November due to situation.
And of course we will be glad to work with you in the future.


My Mac can't upgrade to the latest operating system, so I can't use XCode to experience Swift5.9, but I want to experience Swift5.9 in VSCode, what should I do without changing the configuration of XCode

Is your feature request related to a problem? Please describe.
My Mac can't upgrade to the latest operating system, so I can't use XCode to experience Swift5.9, but I want to experience Swift5.9 in VSCode, what should I do without changing the configuration of XCode
Describe the solution you'd like
My Mac can't upgrade to the latest operating system, so I can't use XCode to experience Swift5.9, but I want to experience Swift5.9 in VSCode, what should I do without changing the configuration of XCode
Describe alternatives you've considered
My Mac can't upgrade to the latest operating system, so I can't use XCode to experience Swift5.9, but I want to experience Swift5.9 in VSCode, what should I do without changing the configuration of XCode

You can utilize VSCode’s Dev Container feature as documented here: https://github.com/swift-server/vscode-swift/blob/main/docs/remote-dev.md
It uses Docker to run Swift on Linux (in a lightweight VM). IIRC there’s no reliable way to run a Swift macOS toolchain on an unsupported OS version.

@adam-fowler Maybe we can change the file name from remote-dev to dev-container? It doesn’t contain anything about remote development now.

@leiyutinghua Another way is to try the official toolchain release from Swift.org. It supports a wider (but not arbitrary) range of macOS version than Xcode.
After installing the toolchain, you can change the plugin settings inside VSCode to point Swift executable to the one provided by the installed toolchain. If your macOS is compatible, everything should work as expected.

@adam-fowler Maybe we can change the file name from remote-dev to dev-container? It doesn’t contain anything about remote development now.

Want to do a PR?

If your macOS is compatible, everything should work as expected.

I think the version of XCTest for 5.9 is only available as bundled with Xcode and 5.8 XCTest is not compatible with 5.9.

As mentioned above https://github.com/swift-server/vscode-swift/issues/622#issuecomment-1764148370 dev containers are the best way to experience a different version of swift on MacOS


Set item selected on initialization

Hi ! How can I set the selected Item when the Carousel is initialized ?
thanks ! :)

Nevermind :p


Upgrading Ubuntu 17.04 to 17.10 Breaks Script

Using the latest version of the script it isn't possible to run due to missing packages. In addition, the upgrade breaks the existing installation.

I see what the problem is and will get a patch done as soon as possible, certainly within 24 hours.

Awesome, thanks! Definitely appreciate the quick fix since I have two broken seedboxes atm. :(

seem to have found another issue with compiling, you may not be impacted if you already have rtorrent installed.
Run:
sudo rtsetup develop
Then run rtinst and see if this resolves your issues.

Still receiving this when accessing ruTorrent:
[20.10.2017 11:15:44] WebUI started.
[20.10.2017 11:15:44] Bad response from server: (502 [error,getplugins]) Bad Gateway

ok run rtsetup develop again to get the latest changes, and then run rtinst again and should now be working

We're back up and running, excellent. :D

changes have been implemented into rtinst 1.5.2
run 'rtsetup release' to install the latest version


Is this package still maintained?

 Many open issues that are not particularly new with no reply from the author/maintainers.

Yes, it is. So sorry for not being responsive on the issues lately. Last commit on master was 9 months ago, but we're working on a new release. Things should start changing by next week.

Glad to heart that. Keep up the awesome work! ⭐


[Feature Request]: Add Light Mode/Dark Mode to the web page.

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
The current website is in complete dark mode, i wish to add a toggle button to change modes between light and dark mode. this will provide a nice UI touch to the website. the button will be place d at the top right corner of the webpage.
Thank You.
Use Case
This feature provides a nice UI touch to the web page allowing the user to switch between light and dark modes effeciently.
Benefits
No response
Add ScreenShots

The button is going get added at the top right corner of this
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

Please assign this issue to me under gssoc'24. Also add the labels level and gssoc

You can start working on it.

Please add the labels gssoc and level.
Thank you


chore: use singular naming convention for SwapErrorType

Current dependencies on/for this PR:

main

PR #1156   👈

This comment was auto-generated by Graphite.


Problems overriding twig file systemloader (twig 2.0)

I just had the issue, that I had twig 2.0 in my vendors (still have to figure out why), and tried to install the theme bundle.
That resulted in following warning:

PHP Warning:  Declaration of Liip\ThemeBundle\Twig\Loader\FilesystemLoader::findTemplate($template) should be compatible with Twig_Loader_Filesystem::findTemplate($name, $throw = true) in /srv/www/bestfewo.de/vendor/liip/theme-bundle/Twig/Loader/FilesystemLoader.php on line 10

Turns out the filesystem loader has a second parameter in twig 2.0, but isn't implemented in the overriding class.

I just had the issue, that I had twig 2.0 in my vendors (still have to figure out why) [...]

Symfony does work with Twig 1.x and 2.x. Thus, it does not have version constraints excluding any of these versions. However, due to the minimum-stability settings in your composer.json file being set to stable (which is the default in the Symfony Standard Edition) you would never have end up with Twig 2.x when running composer update until a few days ago when Twig 2.0 was released. Now Composer will install stable releases of Twig 2.x if you do not explicitly depend on Twig 1.x.
I have opened #162 to make the FilesystemLoader compatible with Twig 2.x. Could you please check if the suggested patch solves your issue?

Thanks for the insight, I already suspected something in that direction, but wasn't able to confirm my suspicion.
The patch seems to solve the issue, thank you very much.


Fix link in international_languages.md

Type of change

Documentation update

Description
This patch fixes a link in internal_languages.md.
The link should refer to the original English page like the other links.
Additional details
Related issues

@Mergifyio backport release-2.3

@ale-linux Thank you for your approval. I think this patch should be backported to release-2.3. (It seems that I don't have permissions to do that.)
Also, this also might be backported to release-2.2. But, in release-2.2, {BRANCH_DOC} is hardcoded. So, if it needs to be applied to 2.2, a new patch will need to be created. Should I do that?

@Mergifyio backport release-2.3

@satota2 yes please! :+1:

@ale-linux Thank you for your comments. I submitted a new patch for release-2.2 (https://github.com/hyperledger/fabric/pull/2512).


Permits for users

Lets say we have agents that can be accesed for a group of users (for example  an agent that handles sensitivo information of a company),then most probably a system of permits is needed for the users.

Interesting!
So if I understand, you would like for example to restrict an Agent to a specific group of users?

Yes, because that agent for example is connected to sensitive data of the company (balance sheet, or projects being done or agreements with clienta, as example)
El 21-10-2023 6:11 a. m., Kevin Piacentini @.***> escribió:
Interesting!
So if I understand, you would like for example to restrict an Agent to a specific group of users?
—
Reply to this email directly, view it on GitHubhttps://github.com/agentlabs-inc/agentlabs/issues/45#issuecomment-1773727326, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEM47ODWDBXA2WGAAJ44R5DYAOGVDAVCNFSM6AAAAAA6J673SCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZTG4ZDOMZSGY.
You are receiving this because you authored the thread.Message ID: @.***>

It makes sense. I cannot garantee when it will ship, but it's definitely something we'll consider.
Thank you much for your suggestions 🙏

Just adding some more information here.
In the next release, we'll allow you to authenticate users directly from the SDK.
It will work as follow:
agent.requestLogin({ text: 'Please login to access this agent' })

And this will send a rich component into the chat to ask the user to authenticate (see screenshot).

We can imagine the same king of control for groups.
You could add a user to a group.
Then from the SDK you would just do something as follows:
project.onUserMessage(() => {
  if (user.group === 'some-group') {
     agentA.send('Agent A is available')
   }

   if (user.group === 'some-other-group') {
      agentB.send('You have access to this VIP agent')
   }
});

Would this make sense to you?

To be honest, I'm not expert in coding! Because meanwhile I ve think in other option, which is to have a separated database for that agent, not maybe the best way but it might work.
El 21-10-2023 8:47 a. m., Kevin Piacentini @.***> escribió:
Just adding some more information here.
In the next release, we'll allow you to authenticate users directly from the SDK.
It will work as follow:
agent.requestLogin({ text: 'Please login to access this agent' })
And this will send a rich component into the chat to ask the user to authenticate (see screenshot).
[Screenshot 2023-10-21 at 13 44 48]https://user-images.githubusercontent.com/15961122/277106072-bcbe00d5-88a6-4e5d-bde6-8d5277ef9aa3.png
We can imagine the same king of control for groups.
You could add a user to a group.
Then from the SDK you would just do something as follows:
project.onUserMessage(() => {
if (user.group === 'some-group') {
agentA.send('Agent A is available')
}
if (user.group === 'some-other-group') {
agentB.send('You have access to this VIP agent')
}
});
Would this make sense to you?
—
Reply to this email directly, view it on GitHubhttps://github.com/agentlabs-inc/agentlabs/issues/45#issuecomment-1773766749, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEM47OEL6NTWYZMB3SKXNP3YAOY53AVCNFSM6AAAAAA6J673SCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZTG43DMNZUHE.
You are receiving this because you authored the thread.Message ID: @.***>


Purpose of this tool

I'm really curious: What should I do with with GeoJSON tiles?
Am I right, that geojson-tile-server is reading in a big geojson and serving small geojson extracts? Not PNGs?

Yes, you are correct. The server loads a big geojson, and cuts it into pieces (leaving out some details at the lower zoom levels). The client is then able to retrieve only the parts it needs. For example, I've used it for a HoloLens map app (WorldExplorer, also on github), which is basically a smartphone and not very powerful, so it would only load the tiles that were needed to render the map.


Enable 330 unit tests for nightly

Enable 330 unit tests for nightly, since the issue in the comment has been fixed.
There still are 4 failing tests now, and filed separate issues for them.
Signed-off-by: Firestarman<EMAIL_ADDRESS>

build

build


simple example running failed: opal_shmem_base_select failed

This is the simple example what I run and get a return information:
> python hiq_test.py
[dechin-PC:21830] mca_base_component_repository_open: unable to open mca_patcher_overwrite: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_patcher_overwrite.so: undefined symbol: mca_patcher_base_patch_t_class (ignored)
[dechin-PC:21830] mca_base_component_repository_open: unable to open mca_shmem_mmap: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_shmem_mmap.so: undefined symbol: opal_show_help (ignored)
[dechin-PC:21830] mca_base_component_repository_open: unable to open mca_shmem_posix: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_shmem_posix.so: undefined symbol: opal_shmem_base_framework (ignored)
[dechin-PC:21830] mca_base_component_repository_open: unable to open mca_shmem_sysv: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_shmem_sysv.so: undefined symbol: opal_show_help (ignored)
--------------------------------------------------------------------------
It looks like opal_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during opal_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  opal_shmem_base_select failed
  --> Returned value -1 instead of OPAL_SUCCESS
--------------------------------------------------------------------------
--------------------------------------------------------------------------
It looks like orte_init failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems.  This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):

  opal_init failed
  --> Returned value Error (-1) instead of ORTE_SUCCESS
--------------------------------------------------------------------------
--------------------------------------------------------------------------
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort.  There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems.  This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):

  ompi_mpi_init: ompi_rte_init failed
  --> Returned "Error" (-1) instead of "Success" (0)
--------------------------------------------------------------------------
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***    and potentially your MPI job)
[dechin-PC:21830] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!

After change the mpi4py into libmpi.so, this simple example seems can run correctly. But for many other examples will still raise an error:

python teleport_mpi.py
[dechin-PC:27209] mca_base_component_repository_open: unable to open mca_sec_basic: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_sec_basic.so: undefined symbol: opal_sec_base_framework (ignored)
[dechin-PC:27209] *** Process received signal ***
[dechin-PC:27209] Signal: Floating point exception (8)
[dechin-PC:27209] Signal code: Integer divide-by-zero (1)
[dechin-PC:27209] Failing at address: 0x7f178782418c
[dechin-PC:27209] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f179f18f0c0]
[dechin-PC:27209] [ 1] /usr/local/openmpi/lib/libopen-pal.so.40(opal_hash_table_get_value_ptr+0x5c)[0x7f178782418c]
[dechin-PC:27209] [ 2] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_component_find+0x2d8)[0x7f178784f0c8]
[dechin-PC:27209] [ 3] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_components_register+0x2a)[0x7f178785a96a]
[dechin-PC:27209] [ 4] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_register+0x204)[0x7f178785adf4]
[dechin-PC:27209] [ 5] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_open+0x11)[0x7f178785ae51]
[dechin-PC:27209] [ 6] /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_ess_singleton.so(orte_ess_singleton_component_query+0x6e)[0x7f17869e11ee]
[dechin-PC:27209] [ 7] /lib/x86_64-linux-gnu/libopen-pal.so.20(mca_base_select+0xd7)[0x7f17898e2077]
[dechin-PC:27209] [ 8] /lib/x86_64-linux-gnu/libopen-rte.so.20(orte_ess_base_select+0x4d)[0x7f1789b90b6d]
[dechin-PC:27209] [ 9] /lib/x86_64-linux-gnu/libopen-rte.so.20(orte_init+0x204)[0x7f1789b62a74]
[dechin-PC:27209] [10] /lib/x86_64-linux-gnu/libmpi.so.20(ompi_mpi_init+0x30b)[0x7f178af10c4b]
[dechin-PC:27209] [11] /lib/x86_64-linux-gnu/libmpi.so.20(PMPI_Init_thread+0x79)[0x7f178af33179]
[dechin-PC:27209] [12] /lib/x86_64-linux-gnu/libboost_mpi.so.1.62.0(_ZN5boost3mpi11environmentC1ENS0_9threading5levelEb+0x42)[0x7f178acbb012]
[dechin-PC:27209] [13] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(_ZN12SimulatorMPIC1EN5boost3mpi12communicatorEmmm+0x35)[0x7f178b416265]
[dechin-PC:27209] [14] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(_ZN12SimulatorMPIC1Emmm+0x34)[0x7f178b417ae4]
[dechin-PC:27209] [15] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(+0x2ae1f)[0x7f178b401e1f]
[dechin-PC:27209] [16] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(+0x227be)[0x7f178b3f97be]
[dechin-PC:27209] [17] python(_PyMethodDef_RawFastCallDict+0x267)[0x562ffe084987]
[dechin-PC:27209] [18] python(_PyCFunction_FastCallDict+0x21)[0x562ffe084ae1]
[dechin-PC:27209] [19] python(_PyObject_Call_Prepend+0x63)[0x562ffe076c43]
[dechin-PC:27209] [20] python(PyObject_Call+0x6e)[0x562ffe06b95e]
[dechin-PC:27209] [21] python(+0xa23b1)[0x562ffdfea3b1]
[dechin-PC:27209] [22] python(_PyObject_FastCallKeywords+0x128)[0x562ffe0c19b8]
[dechin-PC:27209] [23] python(_PyEval_EvalFrameDefault+0x4bf6)[0x562ffe11d026]
[dechin-PC:27209] [24] python(_PyEval_EvalCodeWithName+0x2f9)[0x562ffe05e4f9]
[dechin-PC:27209] [25] python(_PyFunction_FastCallDict+0x400)[0x562ffe05f800]
[dechin-PC:27209] [26] python(_PyObject_Call_Prepend+0x63)[0x562ffe076c43]
[dechin-PC:27209] [27] python(+0x1710aa)[0x562ffe0b90aa]
[dechin-PC:27209] [28] python(_PyObject_FastCallKeywords+0x128)[0x562ffe0c19b8]
[dechin-PC:27209] [29] python(_PyEval_EvalFrameDefault+0x56ac)[0x562ffe11dadc]
[dechin-PC:27209] *** End of error message ***
浮点数例外

At least this simple example works, thank god.

After a restart, this problem appears everywhere.

python hiq_test.py
[dechin-PC:10227] mca_base_component_repository_open: unable to open mca_sec_basic: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_sec_basic.so: undefined symbol: opal_sec_base_framework (ignored)
[dechin-PC:10227] *** Process received signal ***
[dechin-PC:10227] Signal: Floating point exception (8)
[dechin-PC:10227] Signal code: Integer divide-by-zero (1)
[dechin-PC:10227] Failing at address: 0x7ff8bcca918c
[dechin-PC:10227] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7ff8d46140c0]
[dechin-PC:10227] [ 1] /usr/local/openmpi/lib/libopen-pal.so.40(opal_hash_table_get_value_ptr+0x5c)[0x7ff8bcca918c]
[dechin-PC:10227] [ 2] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_component_find+0x2d8)[0x7ff8bccd40c8]
[dechin-PC:10227] [ 3] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_components_register+0x2a)[0x7ff8bccdf96a]
[dechin-PC:10227] [ 4] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_register+0x204)[0x7ff8bccdfdf4]
[dechin-PC:10227] [ 5] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_open+0x11)[0x7ff8bccdfe51]
[dechin-PC:10227] [ 6] /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_ess_singleton.so(orte_ess_singleton_component_query+0x6e)[0x7ff8bbe661ee]
[dechin-PC:10227] [ 7] /lib/x86_64-linux-gnu/libopen-pal.so.20(mca_base_select+0xd7)[0x7ff8bf1a1077]
[dechin-PC:10227] [ 8] /lib/x86_64-linux-gnu/libopen-rte.so.20(orte_ess_base_select+0x4d)[0x7ff8bf44fb6d]
[dechin-PC:10227] [ 9] /lib/x86_64-linux-gnu/libopen-rte.so.20(orte_init+0x204)[0x7ff8bf421a74]
[dechin-PC:10227] [10] /lib/x86_64-linux-gnu/libmpi.so.20(ompi_mpi_init+0x30b)[0x7ff8c0c25c4b]
[dechin-PC:10227] [11] /lib/x86_64-linux-gnu/libmpi.so.20(PMPI_Init_thread+0x79)[0x7ff8c0c48179]
[dechin-PC:10227] [12] /lib/x86_64-linux-gnu/libboost_mpi.so.1.62.0(_ZN5boost3mpi11environmentC1ENS0_9threading5levelEb+0x42)[0x7ff8c09d0012]
[dechin-PC:10227] [13] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(_ZN12SimulatorMPIC1EN5boost3mpi12communicatorEmmm+0x35)[0x7ff8c114e265]
[dechin-PC:10227] [14] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(_ZN12SimulatorMPIC1Emmm+0x34)[0x7ff8c114fae4]
[dechin-PC:10227] [15] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(+0x2ae1f)[0x7ff8c1139e1f]
[dechin-PC:10227] [16] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(+0x227be)[0x7ff8c11317be]
[dechin-PC:10227] [17] python(_PyMethodDef_RawFastCallDict+0x267)[0x55642788a987]
[dechin-PC:10227] [18] python(_PyCFunction_FastCallDict+0x21)[0x55642788aae1]
[dechin-PC:10227] [19] python(_PyObject_Call_Prepend+0x63)[0x55642787cc43]
[dechin-PC:10227] [20] python(PyObject_Call+0x6e)[0x55642787195e]
[dechin-PC:10227] [21] python(+0xa23b1)[0x5564277f03b1]
[dechin-PC:10227] [22] python(_PyObject_FastCallKeywords+0x128)[0x5564278c79b8]
[dechin-PC:10227] [23] python(_PyEval_EvalFrameDefault+0x4bf6)[0x556427923026]
[dechin-PC:10227] [24] python(_PyEval_EvalCodeWithName+0x2f9)[0x5564278644f9]
[dechin-PC:10227] [25] python(_PyFunction_FastCallDict+0x400)[0x556427865800]
[dechin-PC:10227] [26] python(_PyObject_Call_Prepend+0x63)[0x55642787cc43]
[dechin-PC:10227] [27] python(+0x1710aa)[0x5564278bf0aa]
[dechin-PC:10227] [28] python(_PyObject_FastCallKeywords+0x128)[0x5564278c79b8]
[dechin-PC:10227] [29] python(_PyEval_EvalFrameDefault+0x56ac)[0x556427923adc]
[dechin-PC:10227] *** End of error message ***
浮点数例外

When reporting running problems please show command line that you run and complete source code of the example.
For correct functioning SimulatorMPI backend requires at least 5 qubits allocated and 2 MPI processes.

When reporting running problems please show command line that you run and complete source code of the example.
For correct functioning SimulatorMPI backend requires at least 5 qubits allocated and 2 MPI processes.

Is that requirement documented somewhere? If not I think it would be good to mention that somewhere in case others run into some issues.

I have reviewed A simple example of programming HiQ in Python and can say that it is wrong. SimulatorMPI must not be used in such way. Corrected example is
from projectq.ops import H, Measure
from hiq.projectq.backends import SimulatorMPI
from hiq.projectq.cengines import GreedyScheduler, HiQMainEngine

from mpi4py import MPI

# Create main engine to compile the code to machine instructions(required)
eng = HiQMainEngine(SimulatorMPI(gate_fusion=True, num_local_qubits=20), engine_list=[GreedyScheduler()])

# Use the method provided by the main engine to allocate quantum register
qr = eng.allocate_qureg(5)
q1 = qr[0]

# Apply the Hadamard gate to the qubit so that it generates a superposition of 0 and 1 states
H | q1

# Measure the qubit with a basis spanned by {|0>, |1>}
Measure | q1

# Call the main engine to execute
eng.flush()

# Obtain the output. Note that the result is still stored in the qubit object yet clashed into a classical bit
print("Measured: {}".format(int(q1)))

When reporting running problems please show command line that you run and complete source code of the example.
For correct functioning SimulatorMPI backend requires at least 5 qubits allocated and 2 MPI processes.

Here are my source code and I run it by using command just python hiq_test.py

from projectq.ops import H, Measure
from hiq.projectq.backends import SimulatorMPI
from hiq.projectq.cengines import GreedyScheduler, HiQMainEngine
import ctypes
ctypes.CDLL("libmpi.so",mode=ctypes.RTLD_GLOBAL)
#from mpi4py import MPI
eng = HiQMainEngine(SimulatorMPI(gate_fusion=True, num_local_qubits=20))
q1 = eng.allocate_qubit()
H | q1
Measure | q1
eng.flush()
print("Measured: {}".format(int(q1)))

And here are some messages returned:

python hiq_test.py
[dechin-PC:22463] mca_base_component_repository_open: unable to open mca_sec_basic: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_sec_basic.so: undefined symbol: opal_sec_base_framework (ignored)
[dechin-PC:22463] *** Process received signal ***
[dechin-PC:22463] Signal: Floating point exception (8)
[dechin-PC:22463] Signal code: Integer divide-by-zero (1)
[dechin-PC:22463] Failing at address: 0x7f7634d8a18c
[dechin-PC:22463] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f764c6f50c0]
[dechin-PC:22463] [ 1] /usr/local/openmpi/lib/libopen-pal.so.40(opal_hash_table_get_value_ptr+0x5c)[0x7f7634d8a18c]
[dechin-PC:22463] [ 2] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_component_find+0x2d8)[0x7f7634db50c8]
[dechin-PC:22463] [ 3] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_components_register+0x2a)[0x7f7634dc096a]
[dechin-PC:22463] [ 4] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_register+0x204)[0x7f7634dc0df4]
[dechin-PC:22463] [ 5] /usr/local/openmpi/lib/libopen-pal.so.40(mca_base_framework_open+0x11)[0x7f7634dc0e51]
[dechin-PC:22463] [ 6] /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_ess_singleton.so(orte_ess_singleton_component_query+0x6e)[0x7f7633f471ee]
[dechin-PC:22463] [ 7] /lib/x86_64-linux-gnu/libopen-pal.so.20(mca_base_select+0xd7)[0x7f7637282077]
[dechin-PC:22463] [ 8] /lib/x86_64-linux-gnu/libopen-rte.so.20(orte_ess_base_select+0x4d)[0x7f7637530b6d]
[dechin-PC:22463] [ 9] /lib/x86_64-linux-gnu/libopen-rte.so.20(orte_init+0x204)[0x7f7637502a74]
[dechin-PC:22463] [10] /lib/x86_64-linux-gnu/libmpi.so.20(ompi_mpi_init+0x30b)[0x7f7638d06c4b]
[dechin-PC:22463] [11] /lib/x86_64-linux-gnu/libmpi.so.20(PMPI_Init_thread+0x79)[0x7f7638d29179]
[dechin-PC:22463] [12] /lib/x86_64-linux-gnu/libboost_mpi.so.1.62.0(_ZN5boost3mpi11environmentC1ENS0_9threading5levelEb+0x42)[0x7f7638ab1012]
[dechin-PC:22463] [13] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(_ZN12SimulatorMPIC1EN5boost3mpi12communicatorEmmm+0x35)[0x7f763922f265]
[dechin-PC:22463] [14] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(_ZN12SimulatorMPIC1Emmm+0x34)[0x7f7639230ae4]
[dechin-PC:22463] [15] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(+0x2ae1f)[0x7f763921ae1f]
[dechin-PC:22463] [16] /home/dechin/.local/lib/python3.7/site-packages/hiq/projectq/backends/_sim/_cppsim_mpi.cpython-37m-x86_64-linux-gnu.so(+0x227be)[0x7f76392127be]
[dechin-PC:22463] [17] python(_PyMethodDef_RawFastCallDict+0x267)[0x55f6363e0987]
[dechin-PC:22463] [18] python(_PyCFunction_FastCallDict+0x21)[0x55f6363e0ae1]
[dechin-PC:22463] [19] python(_PyObject_Call_Prepend+0x63)[0x55f6363d2c43]
[dechin-PC:22463] [20] python(PyObject_Call+0x6e)[0x55f6363c795e]
[dechin-PC:22463] [21] python(+0xa23b1)[0x55f6363463b1]
[dechin-PC:22463] [22] python(_PyObject_FastCallKeywords+0x128)[0x55f63641d9b8]
[dechin-PC:22463] [23] python(_PyEval_EvalFrameDefault+0x4bf6)[0x55f636479026]
[dechin-PC:22463] [24] python(_PyEval_EvalCodeWithName+0x2f9)[0x55f6363ba4f9]
[dechin-PC:22463] [25] python(_PyFunction_FastCallDict+0x400)[0x55f6363bb800]
[dechin-PC:22463] [26] python(_PyObject_Call_Prepend+0x63)[0x55f6363d2c43]
[dechin-PC:22463] [27] python(+0x1710aa)[0x55f6364150aa]
[dechin-PC:22463] [28] python(_PyObject_FastCallKeywords+0x128)[0x55f63641d9b8]
[dechin-PC:22463] [29] python(_PyEval_EvalFrameDefault+0x56ac)[0x55f636479adc]
[dechin-PC:22463] *** End of error message ***
浮点数例外


Hounsfield (bone density) measurements are incorrect in nearly all cases. Typically by a factor of 7.

Describe the Bug
When using any tool that measures hounsfield units (bone density), such as the circle, ellipse tool, etc. the hounsfield units are off by a factor of 7. It might be a race condition since we have seen situations where the measurements are correct; however, upon a refresh of the browser/study the measurement will once again be incorrect. Air/empty space in a cone beam scan should read with a hounsfield value of -1000. In actuality the value is being reported as around -7000 more than nine times in 10.
Steps to Reproduce
Use any tool such as the circle, freehand or ellipse tool that returns the bone density/hu/hounsfield measurements.
The current behavior
the value returned is roughly 7 times the actual value. So areas that should be a -1000 (such as black space/air/empty space) are being reported as minus seven thousand instead.
The expected behavior
It should return a correct HU value. The current value is extremely inaccurate.
OS
OSX Sonoma 14.1.1
Node version
unknown
Browser
Chrome 126.0.6478.62

is this related to this https://github.com/cornerstonejs/cornerstone3D/issues/1397 ?


gf/init

Description
The template project generated bygf init , it is recommended to addvendor/'to .gitignore .
Additional
No response

@swift-fs if you use go vendor, you should commit vendor folder to repository.


The use of '0x' prefix for hex values is inconsistent

It is about the JSON formats.
Sample values:
"workOrderId": "0xb152345d18e8a0f6"
"requesterId": "0x3456"
"workloadId": "68656172742d646973656173652d6576616c"
"sessionKeyIv": "88a301385631ee67a2924ea1",
etc.
It is a small thing, but easy to fix.

There are few hex string values with '0x' prefix  like workOrderId, requesterId. the TCF core hex string utilities, Intel SGX related hex strings don't have the prefix.
So, it would be appropriate to remove the prefix "0x" from the hex values with the prefix than modifying in many parts of framework code to add the prefix.
Hopefully this approach is fine.

This seems to have been qietly resolved...
:-D