Lint againt non semver-open dependencies

EDIT: the issue now has mentoring instructions. Note that to implement this, we'll need to add additional API to semver crate as well!
Cargo more-or-less enforces contract on crate authors that version 1.x+n.u can always be used instead of 1.x.v. That means that any semver requirement, except for ^x.y.z, does not make sense. Moreover, exotic version requirements may version resolution significantly more complicated.
So we should lint against any sevmer requirement other than  x, x.y or x.y.z.
Specifically,

^x.y.z is not necessary, because ^ is default
~ violates versioning contract. As a consequence Cargo will generally refuse to compile a project with two tilde dependencies with same major version.
>, >= do not make sense, because major version upgrade, by contract, can break anything.
= is in the wrong place, lockfiles should be used to pin dependencies.
<, <= again, version pining belongs to the lockfile.
*  we already forbid. It actually makes sense for suerp-quick local development though!

The interesting not clear-cut use-case is version striding (compatibility with several major versions). For example, serde = ">= 2, < 4" means that you are source-compatible with both serde 2 and serde 3. However, looks like the proper solution here is for the upstream crate to do dtolnay's trick? That is, serde 2 should depend on serde 3, and reexport it's APIs.
There are several design decisions on how to actually implement it:

We can warn on cargo publish enforcing this for crate.io crates, or we can warn on parsing Cargo.toml, enforcing this for anyone.

We can add an opt-out mechanism. For example, we might make you to write a reason if you use non-standard requirement: foo = { version = "~9.2", reason = "this crate has weird rustc compatibility policy" }.

Finally, the most radical option, what if we flatly deprecate all forms of version specification, except for x, x.y, x.y.z? That way, we won't need to document and explain various forms of version requirements at all.

I personally am leaning towards the last option, because it makes the overall system radically simpler for the user, but I am curious if there are some real use-cases for exotic version requirements?

@rust-lang/cargo: this is the issue for the idea we've discussed at all hands and on the last meeting.

Thanks for opening an issue for this @matklad! I think the general idea here is a good one to basically raise awareness about the dangers of overly restrictive version requirements, but I do think we need to tread carefully as well. These sorts of version requirements are often useful in a pinch in some situations and can act as a form of relief rather than constantly feeling like Cargo is slapping you on the wrist.
I think this came up as well when publishing to crates.io awhile back as well. We considered rejecting any publishes with a version requirement that has an overly restrictive upper bound (aka in the middle of a semver range) and ended up only disallowing * dependencies.
I'd also want to make sure that the warning story here is something more sophisticated than "warn every time we see these version requirements", although I'm not sure how we'd best do that...

I think the most important time to enforce this is on publish, right? You don't want your libraries with overly restrictive requirements causing you problems, but you might want to use = in your end project for several good reasons, as Alex notes.
We could, as sort of the most moderate thing, not upload something with non-open requirements unless you pass an additional flag (similar to --allow-dirty). That way we are "linting" you when you upload, but not totally stopping you the way we do with *.

Agree with @withoutboats that that would a nice conservative first step, which actually will get us 90% of the most aggressive solution anyway.
We've also talked several times before about various publish-time checks (like filling fields in Cargo.toml, having basic docs, etc), so perhaps it's time to introduce some general CLI for such checks? Like
$ cargo publish
   ...
   ...
warning: license, repository and documentation fields of Cargo.toml are not filled
warning: `clap = "~2.10"` is an overly restrictive dependency, consider `clap = "2.10"` instead

return with `--suppress-preflight-checks` to proceed with publication

If that sounds great, I'll be happy to write some mentoring instructions!

At least starting out with warnings on publish sounds great to me!

it would probably be useful to be able to run these checks independently of publishing, such as in CI. cargo preflight-checks (or doctor/audit etc).

@dwijnand If I'm not mistaken this exists as cargo publish --dry-run

oh yeah.. easy :) 👍

Mentoring instructions:
We already implement similar functionality for warning about missing Cargo.toml fields, this happens here:
https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_package.rs#L39-L41
To add checks for versions, the steps are:

Add --non-standard-requirements flag here, to be able to suppress the warning (name is subject to bike-shedding).
Actually check for versions here. To get the list of declared dependencies, use pkg.manifest().dependencies(). The version_req field of a dependency is a semver::VersionReq which needs to be checked. Looks like the semver crate does not expose API to inspect the precise form of version requirement, so first such an API needs to be implemented. Perhaps just a VersionReq::is_semver_open method should be added? Semver crate source is here
Add a test. A similar one can be found here

I will try this.

@csmoe how is it going? Do you need any help?
Another special case came up in #5275: Cargo treats 0.x.0 versions like x.0.0. That is, 0.1.0 and 0.2.0 are treated semver-incompatible. So, if we see something like >= 0.5.0, < 0.6.0, we can suggest that this is just 0.5.0. Note that implementing this would be tricky, because it'll require exposing all of the semver internals (unless we add some kind of fn simplify(&self) -> Option<VersionReq> method to semver), so it should be handled separately from the main work here.

I'm not a fan of warning against ~ and = dependencies.
In my gmp-mpfr-sys crate, I recommend using ~ dependencies when a dependent crate uses some C implementation details. No breaking public Rust API changes will happen between 1.1 and 1.2, but the internal implementation details may change. If a crate uses the bundled underlying C libraries directly, it should use "~1.1", not "1.1", as between 1.1 and 1.2 the version of the C libraries can change, and some C implementation details can change between 1.1 and 1.2. This allows crates that need to poke into the C libraries to get bug fixes by using "~1.1" instead of say "=1.1.3".
FFI also makes it difficult to use the semver trick, as different versions can have different incompatible C libraries. I don't think it's reasonable to expect a solution that merges two incompatible versions of the same C library. In such a case, it would be very useful to be able to make a dependent crate compatible with two different major versions of the -sys crate.
I also have a use case for an = dependency, where I used a non-documented implementation detail of a crate. To be specific, I wanted to test some serde special cases in my rug crate, and the easiest way I found was to use bincode version 1.0.0 and its undocumented non-public SliceReader. Since it is undocumented, and can only be used because of some implementation details, it can be removed in 1.0.1. This is a dev dependency of a library, so Cargo.lock is not in git and the easiest way for me to solve my problem was through setting my dev-dependency as bincode = "=1.0.0". So at least for dev dependencies, which will not hurt dependent crates but which are not solved with Cargo.lock, I think = dependencies should be allowed.

Thanks a lot for the input @tspiteri !
I definitely agree we shouldn't emit any warnings for dev dependencies, as they don't affect the resolution for reverse-dependeices.
I think that we should make exception for the -sys crates as well.
The underlying reason why we want to discourage ~ dependencies is that they can lead to genuinely unsatisfiable dependencies. If one crate depends on foo = "~1.0.0", and another on foo = "~1.1.0", Cargo would just refuse to compile a project which includes both of them, because duplicated minor versions are forbidden. In contrast, if all deps are ^, then Cargo can always produce a valid resolution by duplicating major versions, if needed (which is allowed), and picking the latest minor for each major version.
However, the -sys crates already make it possible to create unsatisfiable dependencies, because of the links key: you can't have two crates with the same links, and so you can't duplicate major versions of the -sys crate.
The question is, how do we exclude -sys crates from linting? If you have a dependency specification like foo-sys = "~1.2.0", you can't reliably decide if foo is a sys-crate or not. In fact, the question is ill-formed: some versions of foo might include links key, and others might not.
Could we use a heuristic "if dependency name ends in -sys, don't warn about weird semver requirements"? This sounds extremely hacky, but this is for the warning only.

About the hacky heuristic to detect FFI crates: if the warnings are issued by cargo publish, maybe that command can check whether the dependency has a links key in the version used during the verification stage. It is still a heuristic, but seems to me to be a bit less hacky than depending on the name ending in -sys.

Late input and FWIW: I've been using version bounds like this frequently:
failure    = ">=0.1.0, <2"
fern       =  ">=0.5.5, <2"
futures    = ">=0.1.20, <0.2"

I check in Cargo.lock files so I have some additional control. Advantages of this from my perspective:

I can't seem to remember all the rules of the numerous other operator choices, particular for MAJOR version = 0 vs MAJOR >= 1, without constantly consulting the cargo guide.  The use of explicit ranges is more clear.
Many crates are hopefully going to be stabilizing with a MAJOR version >= 1 eventually. I want to know about these, incl. via CI, and I expect these MAJOR version bumps (counter intuitive from a semver perspective) to be less breaking than a typical MINOR bump.

So I'm personally hoping I'm not going to run afoul of the proposed warnings for doing something that has at least a certain rationale, IMO.
Also this warning proposal seems to not consider the unfortunate reality that semver has some gray areas (see ongoing rust semver debates in various places) and otherwise well maintained crates break others all the time on MINOR releases.  Crate authors need, from time to time, to indicate a maximum dependency bound, like futures < 0.2.  Would they benefit from or appreciate a warning when doing that?

@dekellum a dependency constraint of "0.1" is equivalent to ">= 0.1.0, < 0.2.0", so crate authors are already indicating a maximum dependency bound.

Its not clear from the proposal that "0.1" wouldn't garner a warning. In any case I personally prefer the expanded notation for use is the Cargo.toml.  Also there is the potential if unfortunate scenario of needing something like ">= 0.2.1, <= 0.2.7".   I wouldn't expect crate authors to write that without good reason (e.g. 0.2.8 breaks something).

"0.1" will not garner a warning; it is the form we are guiding people towards with that warning.

@matklad, said:

I am curious if there are some real use-cases for exotic version requirements?

I think I have the above mentioned use cases. To give another concrete example:
Lets say crate foo has ongoing "3.3.x" releases targeting rust 2018 edition, but releases a "4.0.0" to use new features in rust 2019.  Meanwhile the dependent crate bar has CI on all of these versions and its 1.3.24 release has CI showing its compatible with all of the above, so it specifies its foo dependency as:
foo = ">= 3.3.17, <5"

Does the author of bar want to see a constant warning about this?

Another use case for “exotic” version dependencies: crates that must be updated in lockstep.
For instance, a x-derive crate that generates code that relies on an undocumented API of crate x. The best way to handle this currently without having to make a breaking release on each breaking change to said undocumented API appears to be setting x-derive to depend on =1.2.3 of crate x, and hope that the user doesn't specify =-based versions to both x and x-derive (in which case x would end up duplicated and everything would break).
So I think there are legitimate use cases for using non-standard version requirements. That said, warning against them by default completely does make sense (for the above-mentioned problem of having dependencies that must be updated in lockstep, for instance -- though that'd likely be best solved by https://github.com/rust-lang/cargo/issues/5920).

As a practical example of your x-derive case, We recently saw some breakage with the failure 0.1.2 release (rust-lang-nursery/failure#234) where failure has a dependency on failure_derive written as "0.1.2" (meaning ">=0.1.2, < 0.2").  Both crates 0.1.2 version were released simultaneously but failure_derive 0.1.2 will not compile with failure 0.1.1.  Cargo should IMO, be able to handle failure_derive specifying a more restrictive back-depdendency, e.g. ">= 0.1.2, < 0.2" for failure but currently cargo errors out because it views it as a dependency cycle.
2¢: I think this is a misfeature, as cargo should be (heuristically?) solving the graph with preference to single versions, effectively merging broad to narrow dependency ranges, and not being bothered by cycles.

@dekellum ">= 0.1.2, < 0.2" is the same as "~0.1.2".

The human error rate for parsing and interpreting /[~^=]?M[.m[.p]?]?/ is unacceptable high, isn't it? Thus I actually prefer the ">= 0.1.2, < 0.2" (or ">= 0.1.2, < 0.2.0") syntax in Cargo.toml (warnings be damned!),  which per the  manual (I'm tired of consulting) is the same as "^0.1.2", same as "0.1.2". I believe for this specific range, "~0.1.2" is yet another synonym.

Actually the tilde syntax is extra confusing as it differs from the rubygems I'm used to, and has another weird caveat that no mortal could possibly remember:

If you specify a major, minor, and patch version or only a major and minor version, only patch-level changes are allowed.

cargo cult™

@joshtriplett apparently didn't mean "~0.1.2" (human typo) and of course this lint doesn't want to keep the tilde operator either, so in that limited sense we agree. :-)

What is the status of this issue?

I need to wait on https://github.com/steveklabnik/semver/issues/191 before I can proceed.

@hbina I've been outside of Cargo dev for quite a while, so I am not sure what's the status here, but:

IIRC, there were some nice examples where you indeed do want to use = and ~ dependencies. So, while it's still true that plain foo = "x.y.z" deps are right most of the time, and that often people use ~, = and ^ sigils for no good reason, we somehow need to figure out how to avoid false-positives, and that seems hard.
I think one of the big motivations here was that ~ deps sometimes just make dep resolution slow, but @Eh2406 did a number of improvements to dep resolution since than, which might alleviate the problem.

I have fixed all known (to me) real world slow cases in the resolver. There are still synthetic ones (#6258) but there pretty pathological. I don't remember a specific fix for ~, so if I missed a problem let me know. In general if anyone is seeing more than say 1sec in the resolver please file a bug.
TLDR, don't need to make design decisions on resolution being slow.

Once #12115 is stabilized, we can add cargo lints with user control over them which would be a big help for when there are valid reasons for doing this (generally should be crate's depending on their proc macro and bins)

FYI there is some nuance to this.  See #12323 for more details


Could I use branch "MGPUDev"?

I tried to checkout this branch, and run the example/convnet/mnist-small.yaml. But there are even indentation errors in the file:
WARNING:neon.util.persist:deserializing object from:  mnist-small.yaml
2015-06-26 11:26:21,774 WARNING:neon - setting log level to: 20
Traceback (most recent call last):
File "/home/zxx/Install/python2.7.9/bin/neon", line 6, in
exec(compile(open(file).read(), file, 'exec'))
File "/home/zxx/neon_dev/bin/neon", line 236, in
experiment, result, status = main()
File "/home/zxx/neon_dev/bin/neon", line 198, in main
device_id=args.device_id)
File "/home/zxx/neon_dev/neon/backends/init.py", line 98, in gen_backend
from neon.backends.cc2 import GPU
File "/home/zxx/neon_dev/neon/backends/cc2.py", line 1367
def update_fc_bias(self, err, out):
^
IndentationError: unindent does not match any outer indentation level
Does that indicate the master is the only stable branch we could use?

This is an experimental branch whose github version doesn't work yet. The
working one is Maxwell only and will be merged in to the next release of
neon.
On Thursday, June 25, 2015, Keren Zhou<EMAIL_ADDRESS>wrote:

I tried to checkout this branch, and run the
example/convnet/mnist-small.yaml. But there are even indentation errors in
the file:
WARNING:neon.util.persist:deserializing object from: mnist-small.yaml
2015-06-26 11:26:21,774 WARNING:neon - setting log level to: 20
Traceback (most recent call last):
File "/home/zxx/Install/python2.7.9/bin/neon", line 6, in
exec(compile(open(file).read(), file, 'exec'))
File "/home/zxx/neon_dev/bin/neon", line 236, in
experiment, result, status = main()
File "/home/zxx/neon_dev/bin/neon", line 198, in main
device_id=args.device_id)
File "/home/zxx/neon_dev/neon/backends/init.py", line 98, in gen_backend
from neon.backends.cc2 import GPU
File "/home/zxx/neon_dev/neon/backends/cc2.py", line 1367
def update_fc_bias(self, err, out):
^
IndentationError: unindent does not match any outer indentation level
Does that indicate the master is the only stable branch we could use?
—
Reply to this email directly or view it on GitHub
https://github.com/NervanaSystems/neon/issues/53.


Marked as harmful app

Downloaded through edge chromium and after downloading it marked as a harmful app and deleted it. Look into that if you can rest is working great.

Windows 10 v2004

I have reported it safe too

Marking it safe might help. But sadly there is nothing else I can do about this.
The only way I could fix is to digitally sign the file with a signature Defender and other AVs would accept. It that would cost a lot of time and money so isn't worth it for a free project.
Also, releasing it as an app on the Windows Store might help. But it is very unlikely (probably impossible) for an app like this to be accepted into the store without removing some major peices of functionality.

Yeah, got it, Thanks for the app


Updating build package C# scripts.

Triggered build from that PR: https://grpc-testing.appspot.com/view/Artifacts/job/gRPC_build_artifacts/1500/

There was a failure, triggered a rebuild here: https://grpc-testing.appspot.com/view/Artifacts/job/gRPC_build_artifacts/1503/

Updated packages should hopefully happen in https://grpc-testing.appspot.com/view/Artifacts/job/gRPC_build_packages/1480/

LGTM.
Thanks for the help here! It looks like the CSharp packages include the recent updates now.

Yay :-)


Add Python coverage

As a starting point this PR adds collecting the coverage for the Python code.
TODO

[x] Create page at codecov.io
[x] add badge in README.rst

:books: Documentation preview :books:: https://metatensor--381.org.readthedocs.build/en/381/

Coverage seems to be around  75.19%. If this is only for the Python code seems a bit too low. If this is for the the whole codebase seems a but too high since Python is only roughly 50 % of the code.

Coverage seems to be around 75.19%

I get 73%,  maybe this is because I dont run the GPU tests. But also have parts in the report that I don't understand. For example the _dispatch.zeros_like should be covered for numpy arrays

Can we add into developers doc how to combine the reports locally and make an html report? I needed to do
tox
coverage combine ./python/metatensor-operations/.coverage ./python/metatensor-core/.coverage ./python/metatensor-torch/.coverage
coverage html
firefox htmlcov/index.html

I think we can add some files to ignore for example metatensor/torch/documentation.py or we do dummy tests that execute it, not sure.

In my experience the code cov report comment in the PR is not so useful, because it reports only one time and then never updates. Then it just becomes annoying (see for example here https://github.com/osscar-org/scicode-widgets/pull/28). One can disable it by adding such a file https://github.com/Luthaf/rascaline/blob/master/.codecov.yml with comment: off.
Would add more or less the same file with target 70% so we pass it
coverage:
  status:
    project:
      default:
        target: 70%
    patch: off

comment: off

Also we probably want to ignore parts of the code

Can we add into developers doc how to combine the reports locally and make an html report? I needed to do

Adding an info for the devs is a good idea. I will add this. BTW. I had to change something in the tox config because the notorch operations file was overwritten by the torch one. Now coverage is at ~87 %.

I think we can add some files to ignore for example metatensor/torch/documentation.py or we do dummy tests that execute it, not sure.

Besides this file what would you ignore. I think metatensor/torch/documentation.py will be hit if you run the torch tests.

In my experience the code cov report comment in the PR is not so useful, because it reports only one time and then never updates. Then it just becomes annoying (see for example here https://github.com/osscar-org/scicode-widgets/pull/28). One can disable it by adding such a file https://github.com/Luthaf/rascaline/blob/master/.codecov.yml with comment: off.
Would add more or less the same file with target 70% so we pass it

I agree! I already added such a file. Let me know if this is what you thought.

I think metatensor/torch/documentation.py will be hit if you run the torch tests

no, this is only imported by sphinx, so it should be ignored for the coverage.
https://github.com/lab-cosmo/metatensor/blob/3e1a3d8f640441d24580795f8b329f9348166aec/python/metatensor-torch/metatensor/torch/__init__.py#L19-L21

From https://app.codecov.io/gh/lab-cosmo/metatensor/commit/2ed6c500f0048e4ad8ab01d9663820f7efc05b1f/tree/python, it looks like metatensor-core is where we are missing the most tests. In particular for functions in the io module, and testing for error conditions.

From https://app.codecov.io/gh/lab-cosmo/metatensor/commit/2ed6c500f0048e4ad8ab01d9663820f7efc05b1f/tree/python, it looks like metatensor-core is where we are missing the most tests. In particular for functions in the io module, and testing for error conditions.

I assume this is a statement and not suggesting that something is wrong with the coverage, right?

EDIT: there is also no coverage for metatensor-torch, even though we are collecting it

Hmm, might be that this is due to the append... With the seperated files we had 87 % while with --cov-append we dropped to  79 %. I have no real idea why.

I think metatensor/torch/documentation.py will be hit if you run the torch tests

no, this is only imported by sphinx, so it should be ignored for the coverage.
https://github.com/lab-cosmo/metatensor/blob/3e1a3d8f640441d24580795f8b329f9348166aec/python/metatensor-torch/metatensor/torch/__init__.py#L19-L21

Okay I will add this file to ignore in the .codecov.yml

I assume this is a statement and not suggesting that something is wrong with the coverage, right?

yes, this was me looking as what tests we need to add

Seems like stacking the reports does not really work. I changed the order of the jobs in the CI and now the torch stuff is there, but the coverage for the other parts of the code dropped. Maybe we have to combine the reports with coverage by ourselves.

Maybe the operations are a bit problematic to merge because of the import trick? If the combine works then I am okay with the combine. Maybe we can do also a tox environment that does the coverage, then one can change the default posarg to html to get an html report instead of xml, but this is just an idea.

Thanks for the suggesting @agoscinski. I am now using coverage combine while setting [path] lists variables to map our different envs. Locally I got some reasonable and structured results. The coverage is around 90%.
Lets see what coverage.io is doing...

Reports look good I would say 🙃
https://app.codecov.io/gh/lab-cosmo/metatensor/commit/735a07058d138eedb33d7d8a78d85c238b3aaece/tree/python


RPC Function object response schema seems randomly inconsistent

REF: https://stackoverflow.com/q/48793114/1571426
When calling a REST function that returns JSON and requesting the object return schema, sometimes (randomly it seems) the result is wrapped in an object that has the function name as the only key. This makes parsing the result a bit tiresome, e.g.:
With a DB function:
    CREATE OR REPLACE FUNCTION api.conf_test(param TEXT)
    RETURNS JSON AS $$
    BEGIN
        RETURN JSON_BUILD_OBJECT('auth', param, 'perm', param);
    END;
    $$
    LANGUAGE plpgsql STABLE;
    GRANT EXECUTE ON FUNCTION api.conf_test(TEXT) TO anon, rest_user_max;

And a REST call:
    return ajax({
        url: 'https://' + site.domain + '/api/v1/rpc/conf_test',
        type: 'POST',
        data: JSON.stringify({param: user.id}),
        headers: {
            'Accept': 'application/vnd.pgrst.object+json',
            'Content-Type': 'application/json'
        }
    }).then(function(result) {
        if (result.data.conf_test === undefined) {
            site.jwts = result.data;
        } else {
            site.jwts = result.data.conf_test;
        }
    }).catch(function(e) {
        site.jwts = null;
        throw e;
    });

Sometimes the response is:
    {"auth" : "12213", "perm" : "12213"}

And other times it is:
    {"conf_test" : {"auth" : "12213", "perm" : "12213"}}

I have seen it change from one format to the other all by itself on a given server. Anyone know why this is happening?  I am using v<IP_ADDRESS> (the binary release) and PostgreSQL 9.6.6
Note - the REST request does not have the Authorization header, as in real life it is a request to get the two JWTs (auth and perm).   Not sure this matters, just that the PostgreSQL role is "anon" in this case.

The function response shape depends on the database structure cached by PostgREST(we detect if the function is scalar to return it unwrapped), my guess is that you see the {"conf_test": { "auth": ..} when you create the function after PostgREST was started, and you see {"auth": ..} when you restart PostgREST or create the function then start it.
Maybe you can give it a try to see if that's the apparent randomness you're seeing.

Actually I had tried restarting posgrest to see if it would get fixed but it did not. Also tried restarting postgres.   One time in particular the change from the expected {"auth":...} to the (broken in my opinion) {"conf_test":...} happened before my eyes many days after the api schema was built and the server had been restarted many times. In this instance it was working fine for days from one browser, then from another browser (different PC) it wasseen to be broken (mere minutes after I last verified it from the first browser), so then I rechecked it from the first PC and it was broken there suddenly as well.

I believe now that this likely has something to do with postgrest's internal caching of the api which only gets updated when postgrest is started, assuming that things could break randomly minutes or hours after schema changes are made. However it is unclear exactly what changes require a restart -- changes to the api schema obviously, but what about changes to dependent tables, functions, sequences that are not in the api schema?  Also, how long does it take to refresh the cache and is the api still accessible during the rebuilding?


Request plexWatch Support

Built in support for plexWatch would be awesome! plexWatch let's you see exactly what's being used by your friends plex is shared with:
https://github.com/ljunkie/plexWatch

You might wanna include some info about what you info you want from plexwatch. Atleast i didnt get it. Its possible to see what your friends are watching in in the plex module already.

I would like to see the sorting of the library like XBMC and the direct link from the media-details to the Plex detail-page! (I don't think this needs PlexWatch to be honest)

https://code.google.com/p/plex-api/wiki/PlexWebAPIOverview See advanced filtering

You can already see what users are playing and in the current dev branch it is possible to se what payer they are using. https://github.com/tester22/HTPC-Manager/commits/plex-queue
Adding plexwatch might be to much...

@tester22 while your at it you should change how the getthumb works, atm it will always transcode images via plex. That reduces image quality.

@hellowlol yes. Like all other integrations the images displayed to the user are transcoded. I have been using the plex transcoder in favor of using the built in transcoder since it is much faster and no external dependencies. I don't think it would be better to transcode internally.

I'd say is marginally faster, the biggest overhead is the http calls. While it's not visible on a low res screen the images has a lesser quality resulting in ugly images on high res screens. Also the opacity parameter is missing from the URL modal text is very hard to read.
In my fork we check if pil is installed if not we fall back to transcode. I also fixed the play command to you can push videos to iPhones etc.

@hellowlol Will have a look and can push to your version. I have rewritten all play commands in my latest version to use the same approach as Plex Media Served does.

The stuff about the images isn't merged yet but I plan to do that today and revert the stuff regarding dupes and make that a optional.


not found - try nvm ls-remote to browse available versions. - netlify

Operating system and version:
replit newst
nvm debug output: cant use any nvm command because i'm using netfly

nvm ls output:

3:45:16 PM: Attempting node version 'v12.22.6
' from .nvmrc
3:45:17 PM: Version 'v12.22.6
' not found - try nvm ls-remote to browse available versions.
3:45:17 PM: Failed to install node version 'v12.22.6
'
3:45:17 PM: Build was terminated: Build script returned non-zero exit code: 1
3:45:17 PM: Creating deploy upload records
3:45:17 PM: Failing build: Failed to build site
3:45:17 PM: Failed during stage 'building site': Build script returned n

How did you install nvm?

idk netfly
What steps did you perform?
What happened?
What did you expect to happen?
Is there anything in any of your profile files that modifies the PATH?

nop

If you are having installation issues, or getting "N/A", what does curl -I --compressed -v https://nodejs.org/dist/ print out?

on replit it return this
```sh
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to nodejs.org (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=*.nodejs.org
*  start date: Oct 21 00:00:00 2019 GMT
*  expire date: Jan 18 23:59:59 2022 GMT
*  subjectAltName: host "nodejs.org" matched cert's "nodejs.org"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5649513dbee0)
> HEAD /dist/ HTTP/1.1
> Host: nodejs.org
> User-Agent: curl/7.52.1
> Accept: */*
> Accept-Encoding: deflate, gzip
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
HTTP/2 200
< date: Fri, 24 Sep 2021 19:05:35 GMT
date: Fri, 24 Sep 2021 19:05:35 GMT
< content-type: text/html
content-type: text/html
< last-modified: Fri, 24 Sep 2021 16:50:06 GMT
last-modified: Fri, 24 Sep 2021 16:50:06 GMT
< cache-control: max-age=14400
cache-control: max-age=14400
< cf-cache-status: HIT
cf-cache-status: HIT
< age: 7735
age: 7735
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< vary: Accept-Encoding
vary: Accept-Encoding
< server: cloudflare
server: cloudflare
< cf-ray: 693e48fa1ecc2c95-ORD
cf-ray: 693e48fa1ecc2c95-ORD
< content-encoding: gzip
content-encoding: gzip
<

Curl_http_done: called premature == 0
Connection #0 to host nodejs.org left intact

</details>
all my code its on here
https://github.com/mrredo-and-josetrindade1/scratch-for-discord

I don't know what netfly is, but I'm not sure why you're filing this here - it seems like you're not using nvm at all?

Reading the OP again, it seems like a transient issue with nodejs.org, but either way since you're using netlify, you should be filing it with them.


Link WASM example to overview page and improve crud app

[ ] Add image for stripe app.

@bharatkashyap I have added Stripe app to the examples overview page, can you add the screenshot for it? I don't have the token.

@bharatkashyap I have added Stripe app to the examples overview page, can you add the screenshot for it? I don't have the token.

I think we can add a README.md (similar to the other apps) to the Stripe example. test it out, polish the experience - and then add it to the examples page.


Mistake on steps

On steps for gentx on step 4 (cp ${HOME}/testnets/turing-3/genesis.json ${HOME}/.sentinel-hubd/config/)  but (I think) the correct is:
cp ${HOME}/testnets-1/turing-3/genesis.json ${HOME}/.sentinel-hubd/config/

And same for the step 8 I think the correct is:
cp ${HOME}/.sentinel-hubd/config/gentx/gentx-*.json ${HOME}/testnets-1/turing-3/gentx/

The path actually depends on the forked repository name.
I feel, we should mention the output folder name for the git clone.

ohh, I see sorry!!


Code Review

Smashing Magazine Clone

Complete layout of smashing magazine webpage
Put the styling gray scale heap map
We highlight the important parts of the page with a darker color

👋 Hi @mcervantes71 and @gabrie-lhilarion,
You both did a nice job on this project. Your Pull Request has a good title and descriptive summary. You made good use of images and adequate use of semantic HTML elements. The elements and images are well aligned and positioned. In all, your project view looks very appealing even without colors. Good Job!👍💯🌟
However, there are a couple of things I will want you to fix before you can get approval for this project.
So, just hang in there, you are just a step away from completing this project.

CHANGES REQUIRED ♻

[ ] Your linters has a couple of errors. Make sure that your project passes all linter checks.

[ ] Also ensure that your HTML markup are properly validated with no errors or warnings. Check your code with this validator - HTML Validator and kindly fix all error/warning issues.

[ ]  Your README file looks okay but it should be improved and made more professional by seeing the highlighted areas in the screenshot below.
First, replace the dummy content with a proper description of your project and the features you implemented in the project.
Second, the installation process does not look intuitive enough. Keep in mind that users with no technical background can also make use of your repo. So, ensure your installation processes are detailed like adding a terminal command on how to clone the project, how to cd into the repo and open it on the browser.

The following requirements are considered OPTIONAL and so, are NOT mandatory but I will encourage you to take a moment to look into it as it will be helpful to you in this project and future ones.
NOTE: Requirements NOT marked as OPTIONAL are mandatory!

-[optional] In future projects, you should always give your feature branch a descriptive name that shortly describes the project, e.g. smashing_teardown, instead of 'feature_branch' like you have it.

After implementing the MANDATORY changes highlighted above, request for another review by submitting a Code Review Form.

Should you have any questions or need any help, please feel free to reach out to me on Slack with the username (@adaorachi).
Happy Coding and Good-luck on it. ☺
MaryAnn Chukwuka

Changes required ♻
Hello team 🌟
Great work on this project, but you need to fix the issues below before moving on ⬇

[ ] As the last TSE required: "...Second, the installation process does not look intuitive enough. Keep in mind that users with no technical background can also make use of your repo. So, ensure your installation processes are detailed like adding a terminal command on how to clone the project, how to cd into the repo and open it on the browser." Consider Fix this on your '.readme' file.

[OPTIONAL]

[ ] Make sure that basic CSS bad practices are not used (article for support ) (screenshot from Pathwright) no repeating of the same rule

After making the required changes please submit a new code review request
Good luck! 🍀 You are almost there! 💪
SofiBretz.

Add descriptive installation process 😃

Pull request currently under review by Michgolden Ukeje (TSE).
Kindly exercise patience 👋


Fix #390

Simply try/catch to suppress console errors on tooltip disposal

@tim-rue Thank you for taking the time to create this PR. Your small efforts make a big difference.

@tim-rue Instead of catching each and every tooltip exception, will prevent this issue. If we have more tooltips, then every refresh will impact the page performance. I'll give a permanent fix for this.


Set default FIWARE Service Path to '/' in rm command

Proposed changes
This PR sets default FIWARE Service Path to / on NGSIv2 in rm command.
Types of changes
What types of changes does your code introduce to the project: Put an x in the boxes that apply

[ ] Bugfix (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)
[ ] Update only documentation, not any source code.

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of
them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before
merging your code.

[X] I have read the CONTRIBUTING doc
[X] I have signed the CLA
[X] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Further comments
N/A

Coverage remained the same at 100.0% when pulling 6f0229dd249ab317746d59fa756c90137d8f4388 on fisuda:improve/rm_cmd into 218f993182e99015aacf1df731d79fa68fc644af on lets-fiware:main.


Want to use Databunch in Featurewiz

Hi Alex:
Thanks for your excellent AutoML repo! I was looking at your project and found that your DataBunch module was very quickly able to create hundreds of additional features on train and test. I am likely to re-use that module in the new "featurewiz" library I have created. I would be citing your MIT license and credit your Guithub (of course). Just FYI.
Please take a look at the featurewiz library here:
https://github.com/AutoViML/featurewiz
Once again, thank you for sharing your knowledge with everyone.
Ram

closed.


feat: add support for Size2 and Size 1 options

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.08%) to 91.683%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
2840

Relevant Lines:
3055

💛  - Coveralls


No MAUI option in Visual Studio 2022 Community 17.5.5 Installer

I am trying to install VS2022 for MAUI development. The MAUI option shown on this page doesn't appear in the Desktop and Mobile section of the Installer options. The version is 17.5.5.
[Enter feedback here]

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

ID: 7607155a-9a56-d752-c5ac-c3aeb6b128bc
Version Independent ID: 9a62d421-d009-30b3-843e-a92bfc21c061
Content: Install Visual Studio 2022 to develop cross-platform apps using .NET MAUI - .NET MAUI
Content Source: docs/get-started/installation.md
Product: dotnet-mobile
Technology: dotnet-maui
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @meir-toptal
I had this exact same issue when I upgraded to VS 17.5.5 last week - the project templates vanished. A repair (from the installer) fixed it for me.


PP-4472 Fix user access bug

We discovered that in some cases it is possible for a logged in user to
view and modify data from other services. This PR fixes the bug.
The basic cause of the bug is that for urls that contain the service id
we were not correctly checking whether the user had access to that url.
fd93aa2d has a failing test describing the bug and the main fix.
881e48dd ensures that we won't repeat this mistake in future by ensuring
that all controllers use a service id that we have ensured is valid for
current user.
This probably needs unit tests around the resolve service middleware,
but I think the high level test is enough to show the bug is fixed. I will
do further tests in a separate PR, which will better demonstrate what
resolve_service is supposed to do.

Nice one Dom!


TypeError: Unsupported type <type 'numpy.ndarray'>

how to fix this error
here more details
https://stackoverflow.com/questions/58786923/typeerror-unsupported-type-type-numpy-ndarray

Detections needs to be a cupy array to
detections = np.array(net.forward())

@emcastillo, thank you so much for your help.
I got another error:
Traceback (most recent call last):
  File "/home/redhwan/learn1.py", line 33, in <module>
    label = "{}: {:.2f}%".format('person', confidence * 100)
ValueError: Unknown format code 'f' for object of type 'str'

it's work if mak comment out for these lines:
label = "{}: {:.2f}%".format('person', confidence * 100)
cv2.putText(frame, label, (startX, y), cv2.FONT_HERSHEY_SIMPLEX, 0.5, [0, 0, 255], 2)

Your confidence variable is a string instead of a float

it is fine now. thank you sooo much @emcastillo


Retention system doesn't clean up attachment files

When the retention system archives an Attachment, it will create a corresponding ArchivedAttachment row and delete the Attachment. Then, when eventually the archive is cleaned out, such ArchivedAttachment objects will be deleted. The problem with this is that this leaves behind orphaned files - since only the database rows are deleted, but the uploaded files that those reference, don't get cleaned up.
A relatively simple solution could be to have manage.py archive_messages (which is the tool for doing scheduled archiving and clean up of the archive) scan for uploaded files that are no longer referenced by either Attachment or ArchivedAttachment tables and delete them. This has two cases:

[ ] Local files upload backend - which should be the easier one
[ ] S3 upload backend - where we'd need to figure out some good way of iterating through uploaded files to detect the orphanes ones

This is a duplicate of #17348.


Use Sidekiq.logger when Sidekiq::Logging is unavailable

Issue # (if available)
Resolves #94
Sidekiq 6.0 has deprecated usage of Sidekiq::Logger. Sidekiq::Logger is an internal module which applications should not be using. Instead applications should be using Sidekiq.logger, as is documented here: https://github.com/mperham/sidekiq/wiki/Logging#api-changes
Description of changes
This PR attempts to stay backwards compatible by keeping the existing behaviour when Sidekiq::Logging still exists and use Sidekiq.logger when Sidekiq::Logging doesn't exist (which should be the case for Sidekiq 6.0+).
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

That build appears to have solved the startup issue -- but I ran into a new one.  When I ran Sidekiq 6.0, during a job, it generated that following error:
NoMethodError: undefined method `with_context' for #SemanticLogger::Logger:0x00007fa0ec653030
I'm looking into why now...

I opened an issue on sidekiq: https://github.com/mperham/sidekiq/issues/4239

I saw that Sidekiq 6.0.1 was released with the changes that @bobvanderlinden proposed. Can we get this PR ready/merged any time soon? :)

Nice. Yes, the current state of the PR should be working for Sidekiq 6.0.1. It might also be simplified to:
Sidekiq.logger = SemanticLogger[:Sidekiq] if defined?(Sidekiq)

As @mperham mentioned Sidekiq.logger is available in Sidekiq for quite some time. It was apparently added back in 2012: https://github.com/mperham/sidekiq/blob/8c9f960a687d234cdee3396117484bc3c92f3219/lib/sidekiq.rb#L94-L96
Shall I just remove all traces of Sidekiq::Logging.logger in this PR?

sounds good to me @bobvanderlinden ! Do you have merge rights on this project though? or I guess we'll have to wait for @reidmorrison, right?
Happy to test this PR when you're ready :) thanks again for your patience and coordinating this whole thing 💯

Alright, changed the PR to always use Sidekiq.logger.
@reidmorrison could you do a review?

@bobvanderlinden I tested this PR with sidekiq 5.2.7 as well as sidekiq 6.0.1 and it seems to work well 👍
+1 for integrating context into the logs. I currently use a custom middleware for it, but I think it would be much easier for lots of people if this works out of the box! 👍 🥇

also, and sorry, I don't want to hijack this thread (maybe I'm also doing something wrong?), but I seem to get a couple of fairly "useless" log entries for sidekiq that I can't fully understand or get rid of...
specifically, I can see an empty "sidekiq start" log, followed by another start with a bit more info (job name, JID)... and same goes for the "sidekiq done" log.
sample initial log entries
2019-10-03 10:26:46.553831 INFO name=Sidekiq message=start payload=null tags= named_tags= duration= process_info=153:processor exception=
2019-10-03 10:26:46.564567 INFO name=Sidekiq message=start payload=null tags=[TasksLauncher JID-fe5bd736c7a45019eebac9c4] named_tags= duration= process_info=153:processor exception=

... here there are some logs from the worker itself if it logs anything ...
then at the end
2019-10-03 10:26:47.202250 INFO name=Sidekiq message=done: 0.638 sec payload=null tags=[TasksLauncher JID-fe5bd736c7a45019eebac9c4] named_tags= duration= process_info=153:processor exception=
2019-10-03 10:26:47.202440 INFO name=Sidekiq message=done payload=null tags= named_tags= duration= process_info=153:processor exception=

Perhaps related to my middleware?

Maybe that's related to measure and log lines? I'm not sure, but would I consider it a separate issue.

Yes, you're right. It's definitely unrelated. Hope we can merge this in, and then I can try to play around with this middleware again. Or maybe if the project is ok with it, adding the sidekiq context would remove the need for this middleware entirely.

@reidmorrison see https://github.com/rocketjob/rails_semantic_logger/pull/95#issuecomment-537836013

As @mperham mentioned Sidekiq.logger is available in Sidekiq for quite some time. It was apparently added back in 2012: https://github.com/mperham/sidekiq/blob/8c9f960a687d234cdee3396117484bc3c92f3219/lib/sidekiq.rb#L94-L96

I personally tested it with Sidekiq 5.2.7 and 6.0.1 and both worked.

The first commit of this PR keeps compatibility. See https://github.com/rocketjob/rails_semantic_logger/pull/95/commits/91466a5706d6a97af14ab64577e0f31199166989
The second commit removes compatibility for Sidekiq < 1.2.1. That's for versions more than 7 years old.
The maintainer of Sidekiq (@mperham) suggested to use Sidekiq.logger without relying on the internal logger (Sidekiq::Logger.logger).
Should I add a fallback for using the internal logger again?

I don't think this project should support backwards compatibility for > 7 years, nor use internal methods, especially if public ones are available and exposed. +1 for merging this as-is.


Added new features.

Hi, sorry, I've not yet gotten to this (burst pipes and wedding planning...) but rest assured will be taking a look. Thanks for contributing, and for your patience!

TravisCI build was a bit of a red flag but indeed this doesn't seem to compile:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project sonar-typescript-plugin: Compilation failure: Compilation failure:
[ERROR] c:\Projects\SonarTsPlugin\src\main\java\com\pablissimo\sonar\TsLintExecutorImpl.java:[19,2] error: cannot find symbol
[ERROR] symbol:   class Command
[ERROR] location: class TsLintExecutorImpl
[ERROR] c:\Projects\SonarTsPlugin\src\main\java\com\pablissimo\sonar\TsLintExecutorImpl.java:[19,20] error: cannot find symbol
[ERROR] symbol:   variable Command
[ERROR] location: class TsLintExecutorImpl
[ERROR] c:\Projects\SonarTsPlugin\src\main\java\com\pablissimo\sonar\TsLintExecutorImpl.java:[49,2] error: cannot find symbol
[ERROR] symbol:   class CommandExecutor
[ERROR] location: class TsLintExecutorImpl
[ERROR] c:\Projects\SonarTsPlugin\src\main\java\com\pablissimo\sonar\TsLintExecutorImpl.java:[49,29] error: cannot find symbol

Closing old PR


Signature help suppresses arity error in editor

Bug Report

🔎 Search Terms

signature help missing errors
🕗 Version & Regression Information
Saw this for the first time a few months ago, but could be older.
⏯ Playground Link

Playground link with relevant code
💻 Code
declare function f(x: string, y: number): any;

// 1. Put cursor inside call parens
// 2. Request signature help with cmd+shift+space
// 3. Type a quote mark
// 4. Observed behavior: no squigglies
f()

🙁 Actual behavior
No error after following instructions, until making another edit elsewhere / with signature help closed
🙂 Expected behavior
Arity error on the call

I'm pretty sure we have an incremental parser bug. If I move atomically (with pasting) from
fun('a', 3, 3, 'a', 3)

to
fun('a', 3, 3, 'a', 3, 3)

then the error is always presented.
If I insert the comma, then the argument, with delays, then it's a reliable repro that the error doesn't appear. More tellingingly, atomic edits from that point forward don't present an error unless I remove the line and put it back again

Could be, but I’m pretty sure signature help is also related somehow. I have automatic signature help turned off in my editor but frequently invoke it manually. By default, signature help appears when you type a comma, so that creates another difference vs. pasting. But in my editor, I can’t repro without invoking signature help.

Fairly certain it's not related to incremental parsing. If you dismiss signature help and start typing, errors show up again.
signatureHelpPoisoningTypeCheckerCache.webm
Here's my theory from #52369:

What are the mechanics here that're making this happen? If you're using VS Code, that initial , will start a signature help session. Every subsequent character will likey be used as a retrigger for signature help prior to requesting diagnostics. And so signature help (which I recall is checked in a specific way to handle overloads that differ slightly in arity) keeps getting requested for a specific expression before the rest of the type-checker gets to walk over it to report errors.
I believe that because signature help gets checked in a special way, it is likely poisoning the type-checker state we use for reporting errors as well.

This might be the same problem as the one that I'm trying to fix here. The problem recognized there is only relevant for one of the issues but we were discussing with @andrewbranch that the problem is likely to be much broader. I'm investigating the related issues to learn more about the scope so I can repurpose that PR to fix those kinds of issues holistically.

After all, this feels a little bit different from the other case - the other case is strongly related to inference blocking and this doesn't look anything like that (so far).
I've managed to create a test file for this:
///<reference path="fourslash.ts"/>
// @strict: true
////
//// declare function f(x: string, y: number): any;
////
//// /*1*/f(/*2*/)/*3*/

goTo.marker("2");
verify.signatureHelp({
    triggerReason: {
        kind: "invoked"
    }
})
edit.insert(`"`)
edit.insert(`"`)
verify.signatureHelp({
    triggerReason: {
        kind: "retrigger"
    }
})
verify.not.codeFixAvailable() // trigger typecheck
verify.errorExistsBetweenMarkers("1", "3");

If we remove the second verify.signatureHelp call then this test passes. For some reason, the code fix-related thing after the signature help doesn't end up checking the file or doesn't end up reporting this error. I'm gonna continue investigating this some time later.

I don't think this is related - the problem can already be observed in builds from before this PR has been merged<EMAIL_ADDRESS>playground.
I identified a similar regression here to be caused by https://github.com/microsoft/TypeScript/pull/36747 . We can also confirm that this issue here doesn't happen in a build from before this PR<EMAIL_ADDRESS>playground) and that is happens in a build after that has landed<EMAIL_ADDRESS>playground)


[BUG] [BE] quote uni/eline add - if buyer info structure is not provided, response should have seller information

although buyerContactInformation is not provided, such as relatedContactInformation is not included in request body:
"relatedContactInformation": [
{ "number": "111 222 333", "emailAddress"<EMAIL_ADDRESS>"role": "buyerContactInformation", "postalAddress": null, "organization": "MEF", "name": "Joe Buyer", "numberExtension": null }
],
But seller information should also be in the response part.
In amartus response, it has seller info in response even though buyer info is not provided in request.

pay load //
curl --location 'https://api.consoleconnect.com/Sonata/staging/mefApi/sonata/quoteManagement/v8/quote'
--header 'Content-Type: application/json'
--header 'Cookie: plb=7f8597cbdd145f9e'
--data-raw '{
"buyerRequestedQuoteLevel": "firm",
"instantSyncQuote": true,
"quoteItem": [
{
"requestedQuoteItemTerm": {
"name": "UNI Item Term",
"duration": {
"amount": 1,
"units": "calendarMonths"
},
"endOfTermAction": "roll",
"rollInterval": {
"amount": 1,
"units": "calendarMonths"
}
},
        "product": {
            "place": [
                {
                    "role": "INSTALL_LOCATION",
                    "id": "6356792a4806220015488631",
                    "@type": "GeographicAddressRef"
                }
            ],
            "productConfiguration": {
                "@type": "UNI",
                "bandwidth": 1000,
                "bandwidthUnit": "MBPS",
                 "name" : "test-qc01",
                "paymentType" : "invoice"
            },
            "productOffering": {
                "id": "UNI"

            }
        },
        "action": "add",
        "id": "UNI"
    }
]

}'

tested with pass
if buyer info not given, still get seller info in response body:
{
"id": "04f3c0b7-6609-43c0-ae6f-4b90db175d41",
"buyerRequestedQuoteLevel": "firm",
"relatedContactInformation": [
{
"number": "N/A",
"emailAddress"<EMAIL_ADDRESS>"role": "sellerContactInformation",
"name": "kraken"
}
],


Child replication issue when ReplicationTarget is changed on parent

Child entities with the Replicate component are not replicated along with parent when a new client is added to the parent's ReplicationTarget component

Hm normally it should work.
Is this your situation?

spawning P1 with child C1, both have Replicate
you update the ReplicationTarget on P1 to add a new client
The ReplicationTarget is updated on C1 but C1 is still not replicated to the new client?

I have P1 with ReplicationTarget { target: NetworkTarget::Only(...) } and C1 with NetworkTarget::All
When i add more clients to P1, C1 is unchanged but should still replicate to the new clients that are added to P1, right?

And you have replicate_hierarchy: True?
I feel like if you add more clients to P1, then C1 will get the same ReplicationTarget and P1 and will also get replicated to the new client; but maybe there's a bug, it would require more testing

Yes, replicate_hierarchy is set to true. It works fine if the client is added to P1's network targets when the component is added. It only fails when P1's network targets is updated.
Also,

and P1 and will also get replicated to the new client

P1 is replicated to the new client, but C1 is not.


fine tune preserve logins

Task/Issue URL: https://app.asana.com/0/392891325557410/1164380708432526
Tech Design URL: https://app.asana.com/0/392891325557410/1164681539353129
CC:
Description:
Adds setting to detect logins and if on, prompt user to fireproof website and includes refactor to pull user script and message handling in to their own classes.
General expectations are

that false positives (ie detecting a login when there isn't one) is such that there should be very few (or ideally none).
false positives while failing to attempt a genuine login are acceptable.
false negatives (not detecting a login when there is one) will have increased, but this is OK as the user can still use the Fireproof option in the menu.
if a site does not use cookies exclusively then fireproofing may not work

This functionality is only available for iOS 13.
Steps to test this PR:
Regression testing:

Ensure tracker blocking still works as expected
Ensure when debugging that debugging scripts still work as expected
Ensure DocumentUserScript only injected on iOS < 13
Ensure FindInPage still works

Functionality testing:

Enable login detection (Settings > Fireproof Websites > Toggle)

Start logging in to sites - user should be prompted to fireproof

Check that selecting to Fireproof adds site to the list and that the user remains logged in after using the fire button

Disable login detection and remove any fireproofed sites.

Log in to the sites that were detected previously.

Check the user is not prompted to Fireproof the site.

Ensure when changing toggle state that tabs are reloaded with correct user script configuration.

Ensure setting only available on iOS 13.

Ensure pixel fired when changing login detection state toggle.

Device Testing:

[x] iPhone SE
[x] iPhone 8
[x] iPhone X
[x] iPad

OS Testing:

[x] iOS 10
[x] iOS 11
[x] iOS 12
[x] iOS 13

Internal references:
Software Engineering Expectations
Technical Design Template

Thanks @bwaresiak !


Mouse without Borders will not recognize key

Microsoft PowerToys version
0.76.2
Installation method
PowerToys auto-update
Running as admin
None
Area(s) with issue?
Mouse Without Borders
Steps to reproduce
Came in today, Mouse without Borders was blank, tried to setup and always get a key mismatch issue. Tried resetting  from both machines, same issue. Tried the upgrade from .73 to .76 and rebooted both computers, still does not work.

✔ Expected Behavior
to be able to use the the program like before
❌ Actual Behavior
unable to sync to share keyboard and mouse
Other Software
No response

Only difference known is that 2023-12 Cumulative Update for Windows 11 Version 23H2 for x64-based Systems (KB5033375) installed on the one computer over the weekend.


Handle better ISIS cubes that mishandle no-data

Sometimes ISIS cubes don't handle no-data values properly, with the result that some pixels are assigned a valid value of -340282346638529993179660072199368212480.000, or something like that.
ASP's stereo and mapproject choke on this. Worse, mapproject is able to create equally large pixels but with opposite sign somehow when it does interpolation, and after this a holy mess results.
The easiest fix for mapproject is to be able to mask out not just a given value, but any values less than or equal to a value, when it is invoked with --nodata-value. So create_mask should be replaced with create_mask_less_or_equal. This should hopefully not result in large positive values either. The stereo command already works that way.
Of course, the user still needs to pass an appropriate --nodata-value, which should be not the one declared in the .cub file, which is the smallest float, which allows monstrosities as in the first paragraph to squeak though, but something somewhat larger than that.
An ideal fix would go further. Such scenarios should be detected automatically and quietly fixed rather than the user having to specify a correct nodata cutoff.
I ran into this with the Mimas cub file N1644778567 but likely can be easy to test with any data. I recall I ran into this a while ago as well, so the issue could be more general than that.

An example file would be useful.
The trick is that while GeoTIFFs allow for only a single --nodata-value, ISIS cubes can have many, typically 5 (Null, LRS, LIS, HRS, HIS).  Basically, for each 'pixel type' of ISIS cube, there are different valid numerical ranges, and values above or below that valid range are 'special' pixels, essentially there are whole ranges of "--nodata-value".
These values are defined here: https://github.com/USGS-Astrogeology/ISIS3/blob/dev/isis/src/base/objs/SpecialPixel/SpecialPixel.h
Perhaps the first test would be to run the ISIS program stats and see if the particular file has multiple 'special pixels.'  If so, you can try and "collapse" these all to a single value.  You might be able to do it with fewer steps, but you can use stretch to first convert the non-Null special pixels to some actual, but unlikely 'real' pixel value, then use specpix to convert those values to NULL.  After this two-step, you should have an ISIS cube that stats should only show Valid and Null pixel values, but no LIS, LRS, HIS, or HRS pixels.  Now a process (like our mapproject) which can only deal with a single no-data value should work as expected.

This issue hasn't occurred since.


fix: Ensure resource exists so that destroy command works properly

Description
Ensure that ressource exist before referencing it so that destroy command works properly
Motivation and Context

Fixes https://github.com/terraform-aws-modules/terraform-aws-autoscaling/issues/215
Breaking Changes

No breaking change
How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects

[x] I have executed pre-commit run -a on my pull request

This is a provider related issue and not a module issue:

https://github.com/hashicorp/terraform/pull/32207
https://github.com/hashicorp/terraform/pull/32208


Are you going to publish an update to work on ios 12?

Code running but no action.

@YuEmEf thank you for reporting the issue, please update to 1.0.3


Not available for Windows Phone 8.1 ?

Hello,
It seems FFImage control is not available anymore for wpa81 since version 2.2.14.
Is it normal ?
Could not find any information about it.

@NicolasR Could you write more details? It should work, it was only depreciated in favour of  MvxCachedImageView / MvxSvgCachedImageView
https://github.com/luberda-molinet/FFImageLoading/blob/master/source/FFImageLoading.Windows/FFImage.cs

@daniel-luberda Steps to reproduce:

Create a new uap8.1 project (Blank App on Universal Windows 8.1).
Add nuGet package Xamarin.FFImageLoading version > 2.2.13.

You can't use FFImageLoading or MvxCachedImageView because they don't exist on assembly.
Maybe an inclusion error on compilation ?

Maybe an inclusion error on compilation ?

I don't think so, as the same dll is used on both WinRT and UWP (PCL Profile32). Any clues?

@daniel-luberda I decompiled dll, I can't find FFImageLoading or MvxCachedImageView inside.

Look at nuspec file, exact same dll is used for both platforms:
        <!--Windows UWP-->
		<file src="FFImageLoading.Windows\bin\Release\FFImageLoading.Platform.dll" target="lib\uap10.0\FFImageLoading.Platform.dll" />
		<file src="FFImageLoading.Windows\bin\Release\FFImageLoading.Platform.xml" target="lib\uap10.0\FFImageLoading.Platform.xml" />
		<file src="FFImageLoading.Windows\bin\Release\FFImageLoading.Platform.pdb" target="lib\uap10.0\FFImageLoading.Platform.pdb" />
        <file src="FFImageLoading.Windows\bin\Release\FFImageLoading.dll" target="lib\uap10.0\FFImageLoading.dll" />
        <file src="FFImageLoading.Windows\bin\Release\FFImageLoading.xml" target="lib\uap10.0\FFImageLoading.xml" />
        <file src="FFImageLoading.Windows\bin\Release\FFImageLoading.pdb" target="lib\uap10.0\FFImageLoading.pdb" />

        <!--Windows RT-->
		<file src="FFImageLoading.Windows\bin\Release\FFImageLoading.Platform.dll" target="lib\win81+wpa81\FFImageLoading.Platform.dll" />
		<file src="FFImageLoading.Windows\bin\Release\FFImageLoading.Platform.xml" target="lib\win81+wpa81\FFImageLoading.Platform.xml" />
		<file src="FFImageLoading.Windows\bin\Release\FFImageLoading.Platform.pdb" target="lib\win81+wpa81\FFImageLoading.Platform.pdb" />
        <file src="FFImageLoading.Windows\bin\Release\FFImageLoading.dll" target="lib\win81+wpa81\FFImageLoading.dll" />
        <file src="FFImageLoading.Windows\bin\Release\FFImageLoading.xml" target="lib\win81+wpa81\FFImageLoading.xml" />
        <file src="FFImageLoading.Windows\bin\Release\FFImageLoading.pdb" target="lib\win81+wpa81\FFImageLoading.pdb" />

Is your project a net standard project?

What do you mean by .net standard ? It's a Windows Phone 8.1 project no UWP (I have a project with UWP too but don't have this problem on it).
This is what I get by decompiling dll version 2.2.20:

I will try to compile sources directly.

Somehow, VS is not picking FFImageLoading.Platform.dll file. Is your project compatible with PCL Profile32?

Somehow, VS is not picking correct FFImageLoading.Platform.dll file. Is your project compatible with PCL Profile32? It must be nuspec issue

How to check that my project is compatible PCL Profile 32 ? I don't know what that mean.
I tried to compile sources but failed. There seems to be Visual Studio 2015 and 2017 in same solution ? How is this possible ?
I did more tests: by creation Universal Windows 8.1 project, nuget uses portable-net45+win8+wpa81+wp8 library.
According to nuspec:
<!--Core PCL-->
<file src="FFImageLoading.Common\bin\Release\FFImageLoading.dll" target="lib\portable-net45+win8+wpa81+wp8\FFImageLoading.dll" />
<file src="FFImageLoading.Common\bin\Release\FFImageLoading.xml" target="lib\portable-net45+win8+wpa81+wp8\FFImageLoading.xml" />
<file src="FFImageLoading.Common\bin\Release\FFImageLoading.pdb" target="lib\portable-net45+win8+wpa81+wp8\FFImageLoading.pdb" />
<file src="FFImageLoading.Mock\bin\Release\FFImageLoading.Platform.dll" target="lib\portable-net45+win8+wpa81+wp8\FFImageLoading.Platform.dll" />
<file src="FFImageLoading.Mock\bin\Release\FFImageLoading.Platform.xml" target="lib\portable-net45+win8+wpa81+wp8\FFImageLoading.Platform.xml" />

Could you test newest <IP_ADDRESS>0 prerelease nuget and confirm if it's fixed?

Juste installed and it seems to have worked. Now it's using target "wpa81".
Thank you !


Use Map instead of Object

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#Objects_and_maps_compared
There's a lot of locations in the codebase where we use an object where a map is more appropriate.

I made an attempt but got ReferenceError: Map is not defined in node 0.10.0. My guess it's a relatively new thing? @tiffon

Well, 0.10 is over four years old[0], pretty rough constraint. Definitely
closes a lot of doors, using Map being one of them.
In that case, a few of my suggestions may have missed the Mark.
0: https://en.m.wikipedia.org/wiki/Node.js#Releases
On Aug 21, 2017 5:40 PM, "Won Jun Jang"<EMAIL_ADDRESS>wrote:

I made an attempt but got ReferenceError: Map is not defined in node
0.10.0. My guess it's a relatively new thing? @tiffon
https://github.com/tiffon
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uber/jaeger-client-node/issues/148#issuecomment-323860416,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACMpUV426CuQaXcMTFV2dAtvnm6FnMwHks5saflSgaJpZM4O9nOO
.

we cannot break 0.10 compat at this time There may exist some polyfills for Map.

There is the babel polyfill https://babeljs.io/docs/usage/polyfill/, which
includes core-js
https://github.com/zloirock/core-js#ecmascript-6-collections (with
collections, support), but it comes with a word of warning:
This will emulate a full ES2015+ environment and is intended to be used in
an application rather than a library/tool.
On Mon, Aug 21, 2017 at 10:27 PM, Yuri Shkuro<EMAIL_ADDRESS>wrote:

we cannot break 0.10 compat at this time There may exist some polyfills
for Map.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uber/jaeger-client-node/issues/148#issuecomment-323901549,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACMpUWP834EYbZxzn_QPeLjXEgezE9-mks5sajyFgaJpZM4O9nOO
.


Flakify nix build

Adds a flake.nix file.
Checklist

[x] Flake build with nix build .#cardano-wallet succeeds.
[x] (optional) Legacy build with nix-build -A cardano-wallet works
[x] Release build with nix-build release.nix -A cardano-wallet-linux64 works.
[x] Cabal build inside nix develop works.
[x] Stack build inside nix develop works.
[x] Direnv config uses flake.
[x] Flake is built in a Hydra jobset. All jobs pass in this jobset and there are no evaluation errors. => https://hydra.iohk.io/jobset/Cardano/cardano-wallet-flake
[x] PR opened on ci-ops to update Hydra jobsets for cardano-wallet master branch, bors staging/trying, and PRs, so that they build with nix flakes. => https://github.com/input-output-hk/ci-ops/pull/85
[x] Development environment (nix develop) is cached on Hydra - for Linux at least.
[x] Release build is cached on Hydra.
[x] Nix closure size of cardano-wallet derivation has not increased due to unnecessary added dependencies.
[x] Documentation (docs directory, nix code comments, etc) has been updated to use nix flake commands instead of nix-build/nix-shell.
[x] Instructions for bumping nix dependencies have been updated to use nix flake commands.
[x] Buildkite and GitHub actions CI passes.

Issue number
ADP-983

I tried nix develop on this branch and it seems to be building quite a few haskell library dependencies.
But really it should just be getting cached builds from Hydra, right?

Unfortunately I think native flake is downloading inputs dependencies using a different mechanism (builtins.fetchGit or builtins.fetchTarball I believe) than what our flake-compat is using (pkgs.fetchzip), in order to work in restricted mode.
This in turn modify derivation inputs and requires some rebuild... :(
I guess this should be solved with native flake support in hydra and/or allowing required third-party repo in restricted mode.

We would need caching from Hydra. The result of this should be cached at least, right?
nix-build -A cardano-wallet

bors r+

bors r+


Speech T5 on XPU on Intel Arc GPU 770 taking 8 seconds and for CPU it takes 3 seconds ??

I am using from older post from : issues of ipex-llm for  TTS [text to speech]
I have 2 issues:
a) it takes 8 seconds for TTS on XPU than on CPU [3 sec] why ?
b) When i run the code below , every time , it converts to int4, why can't it does once and save it local, i tried as well, it fails :
2024-05-06 23:56:05,898 - INFO - intel_extension_for_pytorch auto imported
2024-05-06 23:56:05,898 - INFO - Converting the current model to sym_int4 format.....
conda create -n speecht5-test python=3.9
conda activate speecht5-test
pip install --pre --upgrade bigdl-llm[xpu] -f https://developer.intel.com/ipex-whl-stable-xpu
pip install datasets soundfile
Runtime Configuration: following here
Code:
import torch
from transformers import SpeechT5Processor, SpeechT5HifiGan, SpeechT5ForTextToSpeech
from datasets import load_dataset
import soundfile as sf
import time

processor = SpeechT5Processor.from_pretrained("microsoft/speecht5_tts")
model = SpeechT5ForTextToSpeech.from_pretrained("microsoft/speecht5_tts")
vocoder = SpeechT5HifiGan.from_pretrained("microsoft/speecht5_hifigan")

from bigdl.llm import optimize_model
model = optimize_model(model, modules_to_not_convert=["speech_decoder_postnet.feat_out",
                                                      "speech_decoder_postnet.prob_out"])
model = model.to('xpu')
vocoder = vocoder.to('xpu')

text = "Alright, listen up. Tyres are still a bit cold, but they're getting there. Keep the pace steady and focus on getting them up to temp. We need those pressures closer to 30 psi, so keep an eye on that. Once the tyres are ready, we'll be good to go.
inputs = processor(text=text, return_tensors="pt").to('xpu')

# load xvector containing speaker's voice characteristics from a dataset
embeddings_dataset = load_dataset("Matthijs/cmu-arctic-xvectors",
                                  split="validation")
speaker_embeddings = torch.tensor(embeddings_dataset[7306]["xvector"]).unsqueeze(0).to('xpu')

with torch.inference_mode():
  # wamrup
  st = time.perf_counter()
  speech = model.generate_speech(inputs["input_ids"], speaker_embeddings, vocoder=vocoder)
  print(f'Warmup time: {time.perf_counter() - st}')

  st1 = time.perf_counter()
  speech = model.generate_speech(inputs["input_ids"], speaker_embeddings, vocoder=vocoder)
  torch.xpu.synchronize()
  st2 = time.perf_counter()
  print(f"Inference time: {st2-st1}")

sf.write("speech_bigdl_llm.wav", speech.to('cpu').numpy(), samplerate=16000)

Saving Local folder, But it didn't worked ., got error:
# Check if the optimized model is already saved on disk
optimized_model_path= "speecht5_tts_optimized"
if os.path.exists(optimized_model_path):
    # Load the optimized model directly
    model= SpeechT5ForTextToSpeech.from_pretrained(optimized_model_path, ignore_mismatched_sizes=True)
else:
    # Load and optimize the model, then save it
    model= SpeechT5ForTextToSpeech.from_pretrained("microsoft/speecht5_tts")
    #from bigdl.llm import optimize_model
    model= optimize_model(model, modules_to_not_convert=["speech_decoder_postnet.feat_out",
                                                          "speech_decoder_postnet.prob_out"])
    # Save the optimized model to disk
    model.save_pretrained(optimized_model_path)

Error while using saving code:
warn(
2024-05-07 00:11:10,686 - INFO - intel_extension_for_pytorch auto imported
Traceback (most recent call last):
File "/home/spandey2/tts/speechT5.py", line 20, in <module>
model= SpeechT5ForTextToSpeech.from_pretrained(optimized_model_path)
File "/home/spandey2/miniconda3/envs/speecht5-test/lib/python3.9/site-packages/transformers/modeling_utils.py", line 2903, in from_pretrained
) = cls._load_pretrained_model(
File "/home/spandey2/miniconda3/envs/speecht5-test/lib/python3.9/site-packages/transformers/modeling_utils.py", line 3310, in _load_pretrained_model
raise RuntimeError(f"Error(s) in loading state_dict for {model.class.name}:\n\t{error_msg}")
RuntimeError: Error(s) in loading state_dict for SpeechT5ForTextToSpeech:
size mismatch for speecht5.encoder.wrapped_encoder.layers.0.attention.k_proj.weight: copying a param with shape torch.Size([313344]) from checkpoint, the shape in current model is torch.Size([768, 768]).
size mismatch for speecht5.encoder.wrapped_encoder.layers.0.attention.v_proj.weight: copying a param with shape torch.Size([313344]) from checkpoint, the shape in current model is torch.Size([768, 768]).
size mismatch for speecht5.encoder.wrapped_encoder.layers.0.attention.q_proj.weight: copying a param with shape torch.Size([313344]) from checkpoint, the shape in current model is torch.Size([768, 768]).
size mismatch for speecht5.encoder.wrapped_encoder.layers.0.attention.out_proj.weight: copying a param with shape torch.Size([313344]) from checkpoint, the shape in current model is torch.Size([768, 768]).
size mismatch for speecht5.encoder.wrapped_encoder.layers.0.feed_forward.intermediate_dense.weight: copying a param with shape torch.Size([1253376]) from checkpoint, the shape in current model is torch.Size([3072, 768]).

Seems related to this issue. https://github.com/intel/intel-extension-for-pytorch/issues/317
@gc-fu Can we solve this issue in conda env?

Hi @shailesh837, we are working on reproducing your issue.

We have reproduced the saving model issue and working on solving it.

For your second issue, please modify your code to save/load optimized model as below:
# Save the model
# Load and optimize the model, then save it
model= SpeechT5ForTextToSpeech.from_pretrained("microsoft/speecht5_tts")
from ipex_llm import optimize_model
model= optimize_model(model, modules_to_not_convert=["speech_decoder_postnet.feat_out",
                                                     "speech_decoder_postnet.prob_out"])
# Save the optimized model to disk
optimized_model_path= "speecht5_tts_optimized"
model.save_low_bit(optimized_model_path)

Then load the optimized model as below:
from ipex_llm.optimize import load_low_bit
model = SpeechT5ForTextToSpeech.from_pretrained("microsoft/speecht5_tts")
model= load_low_bit(model, optimized_model_path)


"New login" security emails are incorrectly sent when users create an organization

Apparently, when you create a new organization with /new, we email you the "new login" emails.  Easy to confirm using /emails in development.
The cause is apparently that because for realm creation we call redirect_and_log_into_subdomain, attaching a property to the UserProfile object isn't an effective way to pass data to the code that sends the emails.
We should probably just replace that hack with a check for the first 1 minute after a user's account is created (using user_profile.date_joined).

(1) The expected behavior is that registering a new account should not result in a "new login" email notification; the user's already going to get an email about their account being created.
(2) Current master has a hack of adding the .just_registered property to the user Python object to attempt to prevent the emails, and checking that in zerver/signals.py.
(3) Right, so I think we just get rid of the just_registered check and instead prevent the emails in a way that actually works :)

@zulipbot claim


Test Explorer: View as List throws an error

Testing #119545

workbench.desktop.main.js:sourcemap:734 TypeError: this.addedOrRemoved is not a function
    at v.updateLeafTestState (workbench.desktop.main.js:sourcemap:1016)
    at new v (workbench.desktop.main.js:sourcemap:1016)
    at y.createItem (workbench.desktop.main.js:sourcemap:1016)
    at new b (workbench.desktop.main.js:sourcemap:1016)
    at new y (workbench.desktop.main.js:sourcemap:1016)
    at C._createInstance (workbench.desktop.main.js:sourcemap:622)
    at C.createInstance (workbench.desktop.main.js:sourcemap:622)
    at ie.updatePreferredProjection (workbench.desktop.main.js:sourcemap:2130)
    at ie.set viewMode [as viewMode] (workbench.desktop.main.js:sourcemap:2130)
    at x.runInView (workbench.desktop.main.js:sourcemap:2130)
    at x.run (workbench.desktop.main.js:sourcemap:2067)
    at handler (workbench.desktop.main.js:sourcemap:651)
    at C.invokeFunction (workbench.desktop.main.js:sourcemap:622)
    at C._tryExecuteCommand (workbench.desktop.main.js:sourcemap:1558)
    at workbench.desktop.main.js:sourcemap:1558
    at async T.run (workbench.desktop.main.js:sourcemap:171)

/duplicate https://github.com/microsoft/vscode/issues/119630


Update threat_model.py

Removed redundant import json statement and removed extra blank lines between functions

Hi @hype8912,
I have a branch open for v0.8 so have removed the redundant JSON import and made the spacing between functions more consistent. Planning to merge in a few days once I've been able to do more testing of the new features.


Carousel content disappearing on scroll

Amin runs into the issue where on scroll the Carousel's items seem to be breaking and have some rendering issue. Example coming

@vusters @amin-nas Can you add some steps to reproduce this issue?

@vinothvino42 see this example:
https://studio.ensembleui.com/app/doMwZyCqUYLHowFBRuSV/screen/leK8QLPrkmkzceOeLBzL
When you scroll to left and right, images keep flashing. Try it also on device, as it gets more messy there. E.g. when I scroll on my Android, images of devices do not match what it should be.


Lumen Sample Project

Hello,
I'm pretty new to Laravel/Lumen and even newer to this package. Does anyone have a sample project that they could share that utilizes this package with Lumen? Preferably one that incorporates some of the more advanced features of this package such as the auth (JWT Token) configuration, etc.
Thanks!

Does JWT auth package even work with Lumen? Going through their configuration it asks you to publish config, which Lumen doesn't seem to support. Anyone with prior experience here would be appreciated, trying not to waste time :)

@nickrouty , yes it works. Publisihing is a simple copy of a config file. You need to create your own jwt config fille in config folder, and have a CustomJWTAuthServiceProvider to ask for it
<?php

namespace App\Providers;

use Tymon\JWTAuth\Providers\JWTAuthServiceProvider;

/**
 * All we do here is forcing the JWTAuthServiceProvider to take
 * our custom config as the only config (force Lumen compatibility,
 * basically).
 */
class CustomJWTAuthServiceProvider extends JWTAuthServiceProvider
{
    /**
     * Boot the service provider.
     */
    public function boot()
    {
        $this->app['config']->set('jwt', require realpath(__DIR__ . '/../config/jwt.php'));

        $this->bootBindings();

        $this->commands('tymon.jwt.generate');
    }
}

Lumen is a thin App with Laravel Core that has not all the features of Laravel, so it will help you learn very well how Laravel/Lumen works. For example, publishing  feature, its a simple copy of a file

@catalinux Awesome - thanks for your help. Now I'm trying to configure it with dingo/api. The auth page seems to leave out some details for someone that is very new to the framework. For example, what file the code needs to be added to, and I'm guessing that there will be a slight difference from what it instructs since I had to create this customer provider?

I went ahead and switched over from Lumen to a fresh install of Laravel 5.1 - everything went smooth this time. I had initially switched from LV5 to Lumen, but I think there were some lingering issues with my upgrade from LV5 to LV5.1 that were causing my problems with using laravel in the first place.


stable/percona-xtradb-cluster Add tag configuration for metricsExporter container

What this PR does / why we need it:
In the percona-xtradb-cluster chart, there is no method to pin the docker image of the prom/mysqld-exporter sidecar that is run in the pod if metricsExporter.enabled is set to true.
This PR adds an optional metricsExporter.tag setting, which allows us to specify a version of the prom/mysql-exporter docker image. It defaults to nil and will fallback to the current behaviour, where no docker image tag is specified.
Special notes for your reviewer:
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @paulczar

/ok-to-test
/lgtm


Add support for custom header parameters for broker endpoints

We have a service manager that can provision/deprovision services on our cloud platform. We are extending our service manager operations to CloudFoundry with an Open Service broker.
When our service broker is registered with CF platform to make our services and plans available to end users, CF calls our broker endpoint
GET /v2/catalog
Our service broker running on our service manager expects an header parameter for authentication along with basic auth parameter. Without the extra header parameter, our endpoints are not accessible and return 401.
We are looking for a solution on how to pass custom header parameters to broker endpoints during registration, so that platform sends it to every endpoint in subsequent requests to broker.
PUT /v2/service_instances/:instance_id
PUT /v2/service_instances/:instance_id/service_bindings/:binding_id

Followed up on cf-release - closing here.


add working directory setting

closes #271

I guess it needs added to the docs, I can do that in separate PR.


Add Instructions for Manual Configuration Setup

This PR includes instructions for manually setting the configuration for omnictl. Currently, the merge command is not functioning on Linux machines.

/m

/m


Release v2.2.8

Holding off on the release until PR #475 is in so we can maintain the same default gRPC settings.


Fix Model and translate button no longer working

https://puu.sh/BxnKq/188aeba675.png Picture of the error I get after pressing fix model, i first tried to just reinstall cats but iv done a complete wipe of blender at this point with no change, there were no changes done as it was working the night before and when i tried this night it was just giving errors

New Update Fixed it


arrow effect with big damage can cause crash

When I use it attack player or other animals,the server went crash.
I think it is caused by arrow effect with big damage.
the item data is below:
cx:
name: cx
id: 1
haspermission: false
permission: a.default.permission
display: '&a全服&c最高攻击力&a，惩罚&c熊孩子&a必备之利器'
quality: LEGENDARY
damageMin: 99999999
damageMax: 99999999
armour: 0
type: Sword
hand: One handed
lore: ''
description: []
item: TNT
ignoreWorldGuard: false
item_data: 0
powers:
'0':
powerName: arrow
cooldown: 1
'1':
powerName: potionhit
chance: 1
duration: 9999
amplifier: 100
type: SLOW
recipechance: 6
hasRecipe: false
dropChances: {}
maxDurability: -1
forceBar: false

max valid damage is 32767, this should have a limit check. cc @RecursiveG

@phoenixlzx You are right.....诶、原来是这样。。。


feat: update helm charts version

Signed-off-by: Gaius<EMAIL_ADDRESS>
Description

Update helm charts version.

Related Issue

Motivation and Context

Screenshots (if appropriate):
Types of changes

[ ] 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 change)
[ ] Documentation Update (if none of the other choices apply)

Checklist:

[x] Code compiles correctly.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report

Merging #824 (79e5a84) into main (71ab827) will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #824      +/-   ##
==========================================
+ Coverage   41.11%   41.17%   +0.06%
==========================================
  Files         102      102
  Lines        8066     8066
==========================================
+ Hits         3316     3321       +5
+ Misses       4340     4335       -5
  Partials      410      410

Flag
Coverage Δ

unittests
41.17% <ø> (+0.06%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

client/daemon/peer/peertask_stream.go
55.35% <0.00%> (+1.52%)
:arrow_up:


The wrong balance displayed after deposit

I got 355 BUSD and deposited them into the BUSD x AUTO vault. I got mooAutoBusd tokens back. Their quantity was the same as I deposited, but on the UI I saw that the count of deposited money is less. And for now, I have more mooAutoBusd tokens, than the balance on the website. Is it expected behavior?

you got less deposited money because there is ~0.1% fee on deposit and there will be no withdrawal fee.

Closed as @roman-monk is correct. It's due to the Autofarm 0.1% deposit fee.


About decoder v4.0

Init all  weights and biases in 'decoder_beamsearch.cc '   with the same initial_value,  v3.1 and v4.0 get different output. Someone has the same problem？

We have optimize the kernel of decoder in v4.0, and hence the results may be little different.
Do the difference make sense?

We have optimize the kernel of decoder in v4.0, and hence the results may be little different.
Do the difference make sense?

I try to depoly FT v4.0 in inference sence and get wrong output. In order to slove the problem, I compare the decoder's intermediate output of V3.1 and v4.0, and find diff of  decoder_self_attn_output is obviously. I want to make sure this has an impact.
I have tried v3.1 and got wrong output too.

The format of cache are different in v3.1 and v4.0. So, if you don't convert the format of v4.0, then the differences are normal.
If you tried v3.1 and got wrong output, it means that there are some problems in your integration.

The format of cache are different in v3.1 and v4.0. So, if you don't convert the format of v4.0, then the differences are normal.
If you tried v3.1 and got wrong output, it means that there are some problems in your integration.

how to  convert the format of cache of v4.0?
Thanks for reply.

It affects many parts, including the self attention and beam search. I suggest you to try v3.1 first if you want to check some intermediate results.

Close this bug because it is inactivated. Feel free to re-open this issue if you still have any problem.


Dimension of aba_partial_dq in computeABAderivatives()

Hi, I have two questions.

By my understanding, aba-derivatives should be providing the derivatives of generalized acceleration w.r.t q, v,  and tau. Is the generalized torque vector in the following comment a typo?
https://github.com/stack-of-tasks/pinocchio/blob/5c93f4e043886ec43659a10a79701263a1e8fa18/src/algorithm/aba-derivatives.hpp#L29
I would expect the size of aba_partial_dq to be (nv, nq) since the derivative is w.r.t to joint configuration vector. I don't understand why the size of aba_partial_dq is (nv, nv) as I found in the following line:
https://github.com/stack-of-tasks/pinocchio/blob/5c93f4e043886ec43659a10a79701263a1e8fa18/src/algorithm/aba-derivatives.hxx#L346

I will appreciate for your answer :)

By my understanding, aba-derivatives should be providing the derivatives of generalized acceleration w.r.t q, v,  and tau. Is the generalized torque vector in the following comment a typo?

This is indeed a copy-pasting mistake. Sorry for that. It refers in fact to the generalized joint acceleration.

2. I would expect the size of aba_partial_dq to be (nv, nq) since the derivative is w.r.t to joint configuration vector. I don't understand why the size of aba_partial_dq is (nv, nv) as I found in the following line:

You are working on the tangent space of the configuration space. For instance, for the free-flyer, the joint configuration space is SE(3) represented by a translation and a quaternion, while the tangent space is so(3), corresponding to a Motion quantity composed of the linear and angular velocity vectors, both of dimension 3.
Is it answering your question?

Thanks for your reply. I guess dq is something like as a velocity *time, rather that a numerical difference of quaternion. That will be clear. I will close this issue soon.
And BTW, what I want to get is the analytical derivatives of accelerations w.r.t the joint configuration. In free flyer case, it should contain a submatrix of size (3,4) describing the derivatives of angular acceleration w.r.t the quaternion. Would there be an efficient way to do so?

I guess dq is something like as a velocity *time, rather that a numerical difference of quaternion. That will be clear. I will close this issue soon.

You can indeed think of it like this.


The Custom-field has moved directory from @vaadin/vaddin-custom-field to @vaadin/custom-field

The latest versions of Vaadin are now using a different directory for the path to the web components.
https://github.com/vaadin/web-components/tree/main/packages/custom-field
This used to be located here:
https://github.com/vaadin/vaadin-custom-field
notice the name change and path change. The standard Vaadin components can not be found when compiling the JS

@AndreGlauserAtWork thank you so much for reporting the bug, I have absolutely no idea how it escaped me during testing :(
expect a fixed release this week

I did a clean run of the demo app, using latest development branch of superfields... and it seems to work
I think a similar problem with paths was fixed with #439 and #449 - please look into changes related to those tickets
could you @AndreGlauserAtWork please take a look if:

you are using the correct Vaadin version (24.4.11 is the one I used)
you are using the correct superfields (0.19.2 and not 0.19.2-vaadin14) - I think this might be causing your problem?

if the problem still persists, could you please remove node_modules from your project and try again
if it still persists, I am going to need a bit more information - a minimal project that reproduces the error would be great

Hi Miki, it was the version that was incorrect. When I used 0.19.2 everything is working fine. Thanks.

Closing as it is not a bug, but just user error for taking the wrong version.
The default version number from the Vaadin Directory is for the version 14 variation, so it was obvious in hindsight that it was wrong, but an easy mistake to make.


[Question] Raw .DDS Hex Headers, Using DirectXTex With C#?

Hullo there!
For the past few days, I've been making me first foray into C# through making a program to resize modern .dds files en masse. Me initial intention was to gear it towards Fallout 4, but it's probably usable for all games, so long as ya have the right textures.
Anywho, I've hit a stump. I think texconv.exe wants me to give it the format for the output texture, as there's some blatant texture corruption (super colorful edges around transparent textures, for example) going on. Thing is, I don't know how to rip out the file format from the .dds header.
Now, I have been able to get the first & second texture dimensions (x and y respectively?), with the first being @ offset +0c and the second @ offset +10, both of them being two bytes in size. The number of mipmap levels is @ offset +1c, but that's about as much as I could discern. Ya can read in detail here: https://github.com/MajinCry/Fallout-4-Texture-Resizer/blob/master/DDS Header Info.txt
So aye, any idea what the offset is to get the .dds format, and what the values at the offset correspond to?
Now, the above is fairly hackish, but I'm resorting to viewing & copying raw bytes, as I can't for the life of me add DirectXTex as a reference to my C# project. The wiki was fairly curt in regards to integrating DirectXTex with Visual Studio, sadly.
If it's possible, would ya be able to explain it like I'm a five year old? Me version of VS is 2013, if that's of any use.
Tah in advance!

You can't reliably parse a DDS file just by seeking to fixed offsets.  You will need to understand the format and write proper parsing code to understand the various different header options that a file might contain.
You could look at the DirectXTex source code for an example of how to do this.
Alternatively, you could just call into the existing DirectXTex implementation.  This is a C++ library, not C#, so you would have to make a managed -> native wrapper for it (for instance using C++/CLI).

Details of the DDS file format are covered on MSDN. There's also a little utility you can download and build for for C++ called ddsdump which can be useful for exploring the information in a DDS file--you need the dds.h file from the DirectXTex library to build it.
Native code inerop to use DirectXTex is probably the easiest and most robust solution.

Damn, so there's not just some standard "DDS Format is @ Offset +xy"? Cor.
That DDS article o'er on Microsoft seems more like a refresher course for veterans that know this stuff, but for the completely fresh-faced infants like yours truly...It's pretty Greeky.
Same situation with allowing intractability between C++ & C# code. And aye, the documentation is not really even there; no explanations on how to actually modify existing code to use, err, native code interop. Best I could find were:
https://msdn.microsoft.com/en-us/library/ms173253.aspx
https://msdn.microsoft.com/en-us/library/ms235282.aspx
The former is written by someone that worked for Ikea's manual department, and the latter is just "Here's code" with no actual explanation. And never mind that, I couldn't even get ddsdump to compile. Add it as an existing item to the DirectXTex project, compile 'n' VS throws this ol' error:

Warning	1	warning C4627: '#include <ddraw.h>': skipped when looking for precompiled header use
Warning	2	warning C4627: '#include <dxgiformat.h>': skipped when looking for precompiled header use
Warning	3	warning C4627: '#include <d3d11.h>': skipped when looking for precompiled header use
Warning	4	warning C4627: '#include "dds.h"': skipped when looking for precompiled header use
Error	5	error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "DirectXTexP.h"' to your source?

I take it that this is awfully low level, 'n' pretty damn impossible for me 'n' my 3 days worth of c# programmin' experience. There any decent, hand-holdy tutorials kicking about, that'd get me on my way to nabbing the texture format o' an existing dds file?