How does the base64 chosen here compare to atob/btoa?

Those use https://infra.spec.whatwg.org/#forgiving-base64 . The decode there is different than RFC in that it defines error handling.
Note that forgiving base64 decode is used by browsers for all their base64 needs, e.g. data: URLs, Blobs.
IMO it would be bad to mismatch browsers.

As far as I can tell the only differences in forgiving-base64 are that it allows you to omit padding and to have non-zero bits in 2 or 4 "overflow" bits. I think we likely want to have a mode which supports such non-canonical input, but I'm very reluctant to make it the default: it is very common for security issues to arise from users assuming that parsers are strict about checking padding when in fact they are forgiving. I prefer to be strict by default and to be looser only as an opt-in.

Hmm. I'd be against shipping anything as the default which doesn't match the web platform default, i.e. which can't decode base64 data: URLs.

All other things being equal, I do think securer defaults are good.
My feelings here are that the alignment with forgiving base64 as used on the web is an empirical question: how often would a user encounter a base64 payload that requires a forgiving decoder? Any history around why such a forgiving decoder was needed in the first place? Was it a historical artifact of the web at the time, and we've largely moved on, or are such sloppy payloads still widespread?

I don't know; that'd be an interesting use counter to add. If we did so and changed the web defaults across browsers then yeah, that'd be one path.

I'd be against shipping anything as the default which doesn't match the web platform default

Why? Is there a specific confusion you are worried about which would be caused by various web platform APIs being slightly more forgiving in what they accepts than the default for this API?

how often would a user encounter a base64 payload that requires a forgiving decoder?

It's pretty rare. As far as I am aware every major programming language includes the padding by default, as do, for example, the canvas toDataURL methods in Chrome, Safari, and Firefox. It is after all required by the RFC. And I am not aware of any way that you can end up with the extra bytes being nonzero other than a.) an actively malicious producer or b.) leaking memory.

Why? Is there a specific confusion you are worried about which would be caused by various web platform APIs being slightly more forgiving in what they accepts than the default for this API?

Yes. I think it's bad if web developers who want to implement the same semantics as browsers (pretty common) need to reimplement the base64 decoder from scratch. Or worse, they try the language built-in one, and only after some painful experience realize that it doesn't match what they want.
I also think its bad if atob and ArrayBuffer.fromBase64() give different results.

As a concrete example, I think it'd be bad if packages such as https://github.com/jsdom/data-urls or similar were not able to use this language feature.

I think it's bad if web developers who want to implement the same semantics as browsers (pretty common, e.g. parsing data: URLs) need to reimplement the base64 decoder from scratch.

That's a strong argument for supporting the same semantics as used by the web platform, which I definitely agree with, but not (that I can tell) an argument for making it the default. If you try to use the strict default and it doesn't work for you, the error message could easily say "if you want to skip validation of padding, pass { padding: false }" or something to that effect, so I don't expect it to be very painful if encountered - and as mentioned above, I don't expect it to be encountered very often except with malicious input, which is precisely the input you want to reject.

I also think its bad if atob and ArrayBuffer.fromBase64() give different results.

Well, atob gives a string, not a buffer, so they definitely are going to give different results. Other than that, the only difference would be that atob would accept some things that fromBase64 would reject by default. That seems like it is not so severe a problem to me, unless there is some specific confusion you are worried about.

Chiming in with a real world example: AMP has a weird protobuf which we encode into some URLs, and for some reason, the Java printer for this protobuf omits the padding characters. I have investigated, but have no idea why this happens.

Incidentally, here's two cryptographers at Google who were surprised by the non-strictness of many implementations of base64 decoding and speculated that it had probably lead to vulnerabilities: @SchmiegSophie and @FiloSottile.
I am pretty well convinced that we should default to the stricter thing, and have opt-in looseness for use cases such as jsdom's and AMP's which need it.

Can we have it an option for web browsers to switch the default (like in Annex B or something)? I think eeb platform consistency is important and I'd rather not expose a second base64 decoder on the web, but if at least we kept the default the same in this API as on the rest of the web platform I would be able to stop from objecting to the proposal.

I would like to understand your reasoning better before commenting on that option. I didn't understand your above answer; as I said, it seemed like an argument for making the looser, less secure behavior available, but not making it the default, and I still don't understand why you want that enough to override the security concerns pointed out by cryptographers at your own employer.

Web platform consistency is important. Having different ways of performing base64 decoding exposed on the web platform is suboptimal, and making developers have to read the docs before they get consistency is IMO a nonstarter.
/cc @annevk as he has worked quite hard to get the web platform on the same page here in its various base64 APIs, and I imagine Mozilla might have similar concerns about exposing (much less making the default) one which does not match the rest of the web platform.

I agree that consistency is valuable, but this would hardly be the first time that a modern version of a legacy API took the opportunity to simultaneously choose stricter defaults. Most developers won't see a difference, and the ones who do - that is, those who actually do end up being given incorrectly padded input - should be thinking about whether they actually want to accept such inputs.

Chiming in with a real world example: AMP has a weird protobuf which we encode into some URLs, and for some reason, the Java printer for this protobuf omits the padding characters. I have investigated, but have no idea why this happens.

@jridgewell Has this been fixed since then (to use a different Java printer or something), or there's still ongoing dependence on loose decoders? How does the rest of the stack deal with the looseness?

@domenic I disagree that lack of consistency here is a hard blocker. It's a goal, other things being equal, we should shoot for. In this proposal, the other thing here is security, which is not equal, so the crux to me remains the claim from @bakkot that "most developers won't see a difference". If that turns out to be true, the stricter default seems strictly better.
I find the tweets pretty convincing evidence of the badness of the footgun. It seems totally reasonable to assume that byte-equality of base64 input implies byte-equality of the output, and its not being so is pretty bad?
That said, having a host-configurable default is a compromise I can live with, but for a proposed language facility, it seems like a good opportunity to nudge future uses away from the non-bijective footgun. Ideally, if we can get away with it the right thing here seems to be to change the default for HTML to be the bijective one as well. While we can retrofit options bags or something to atob, how to do that for data: URLs and the like isn't clear to me. Where in the HTML spec is forgiving-base64 decode invoked for data URLs? The only direct invocation I see in the HTML spec is in atob, and the data: URL RFC doesn't talk about which decoding algorithm to use.
Finally, there's been one anecdote from AMP that there's a weird protobuf they've run into. I would like to hear some more.

I ran some tests to see what the non-browser ecosystem is doing. Given the input string "SQ" (non-padded):

Node Buffer.from("SQ", "base64"): accepts it without complaint, giving back the right bytes

Deno standard library: returns the right bytes

js-base64: Base64.isValid() returns true and its decode(), atob(), and toUint8Array() functions return the right strings/bytes.

I think the JavaScript ecosystem is pretty uniform here as to what base64 means to them, and TC39 should not try to use its position to change what's accepted practice and defaults.

If that turns out to be true, the stricter default seems strictly better.

I don't agree with that. I don't think stricter is better here. Accepting input that the rest of the JS ecosystem accepts is a good thing and we should require it. It's a tradeoff between, IMO, needless compliance to standards that people are not following anyway, versus alignment with the ecosystem. I think theoretical purity should be lower on the priority of constituencies here, versus developers getting a uniform environment.

It seems totally reasonable to assume that byte-equality of base64 input implies byte-equality of the output, and its not being so is pretty bad?

I don't think that's a reasonable assumption, since so many implementations (including the web platform itself) it doesn't hold.

Where in the HTML spec is forgiving-base64 decode invoked for data URLs?

See https://fetch.spec.whatwg.org/#data-urls

I think theoretical purity should be lower on the priority of constituencies here, versus developers getting a uniform environment.

It's not my reading that anyone is arguing for theoretical purity here. My reading of @bakkot's argument on the priority of constituencies is serving the end user by having a new API that's less prone to misuse insecurely (though you disagree here).

I don't think that's a reasonable assumption, since so many implementations (including the web platform itself) it doesn't hold.

My takeaway is different. Because both expecting a binary encoding to be bijective is reasonable and the reality is that it doesn't hold in JS implementations, I'm inclined to think that the sloppiness is rare in practice.

I would expect the byte string returned from btoa to exactly match a byte string created from the result of ArrayBuffer.fromBase64() for all input values. (so forgiving base64 decode, with an option to enable it).
Also ArrayBuffer.fromBase64("SG", { padding: true }) == ArrayBuffer.fromBase64("SG") being the true, with ArrayBuffer.fromBase64("SG", { padding: false }) being the opt out is in violation of web platform design prinicples, so I would strongly oppose against this particular API. Omitting a value in an options bag should result in it being considered falsy. The argument should be switched to disablePadding (with the boolean value inverted), if the default continues to be padding: true.

I think the JavaScript ecosystem is pretty uniform here as to what base64 means to them

The JS ecosystem is not uniform. The base64-js package, which is substantially more commonly used than js-base64 package you link, does check padding length.

I think theoretical purity should be lower on the priority of constituencies here

As Shu says, this argument has nothing to do with theoretical purity, only about security of applications, which affects users directly.

Answering @syg's question:

Has this been fixed since then (to use a different Java printer or something), or there's still ongoing dependence on loose decoders?

Nope, still present. We're using Google's standard Java base64 encoder, but we're not calling omitPadding(), so I don't know why it's happening. Could be present everywhere in google3 for all I know.

How does the rest of the stack deal with the looseness?

The parser we use works just fine without padding. absl's unescape has special handling for padding chars, falling into a slow path. Omitting the padding actually makes the parser faster. 🤷♂

A number of comments have alleged that one of the options is better for security than the other, but without presenting any good evidence so far. An observation was made that the relaxed decoding is not bijective. That's true but I'm not sure what the point is because the strict decoding is not bijective either.
Is there any evidence? The only one I've seen so far is that security problems tend to arise when there are two or more subtly different ways of parsing adopted by an ecosystem, so it's usually best to stick to the dominant one.

the strict decoding is not bijective either

Isn't it? If you considering the domain to be the space of all non-erroring strings and the codomain to be the space of all byte sequences, I'm pretty sure strict decoding is one-to-one, and it's obviously onto. (By "strict" I mean decoding which validates padding both for the = bytes and for the possible extra bits in the last characters, and which errors when passed a string containing characters outside the alphabet.)
The RFC talks about "canonical encoding", which certainly sounds like "the decoder is one-to-one" to me.

Is there any evidence?

Well, I linked a couple of comments from cryptographers; I'm not sure what other evidence you're looking for.
In my experience it is very common for people to write code which assumes that base64 is canonical: for example, they compare base64 strings. And it's quite easy to run into a scenario where this assumption, if it does not hold, breaks your security. (As a concrete example of how this could happen, imagine an application which keeps a list of the base64 encodings of revoked keys in and checks membership of user-supplied keys in this list by string equality.) I have a much harder time coming up with an example of a plausible program where rejecting incorrectly-padded inputs leads to a security vulnerability.

@bakkot: I'm basing my point on what you wrote earlier in this thread:

"As far as I can tell the only differences in forgiving-base64 are that it allows you to omit padding and to have non-zero bits in 2 or 4 "overflow" bits."

There are two possible sources of differences:

padding and overflow bits
whitespace

Either one can result in non-bijective mappings.

Apologies for the confusion. In addition to ignoring incorrect padding, forgiving-base64 also strips all whitespace by default. I would prefer to reject any characters outside of the alphabet by default, and have a way to opt in to ignoring whitespace.

As I understand it browser code bases have a lot of base64[url] libraries in them and I do not think anyone has done the work of auditing all of them. (I mainly noticed when working on data: URLs that they shared logic with atob/btoa.) E.g., https://w3c.github.io/push-api/ uses base64url and I'm not sure to what extent that has been tested with regards to padding. It would be interesting to see a more thorough analysis.

https://w3c.github.io/push-api/ uses base64url and I'm not sure to what extent that has been tested with regards to padding

Thanks for the example. The Push spec defers to RFC7515, which specifies encoding is to be done "using the URL- and filename-safe character set [...] with all trailing '=' characters omitted (as permitted by Section 3.2) and without the inclusion of any line breaks, whitespace, or other additional characters."
And indeed I observe that Chrome and Firefox both enforce the absence of any padding or whitespace in the applicationServerKey. (Blink also has a test to that effect.)
Although, somewhat horrifyingly, both Chrome and Firefox accept strings which have non-zero bits in the last character, possibly because RFC7515 makes no mention of how to handle that case (it may simply not have occurred to them - they were presumably aiming for a canonical encoding, since they require the absence of whitespace, so I imagine they would have required the extra bits be zero if they'd been aware of that possibility).

I also observe that Crypto accepts JWK-formatted keys, which are defined in the above-mentioned RFC7515, and which therefore also enforce the absence of whitespace or padding. And WebAuthn (like CSP) is phrased as comparing the output of running a specific encoder to the user-provided value, which means it is strict about everything.

To summarize, among the examples discussed so far:

atob: base64, permits both presence and absence of =, extra bits, and whitespace
data: uri: as above
Push: base64url, requires absence of =, agnostic on extra bits, requires absence of whitespace
Crypto: as above
CSP: mixed base64/base64url, requires presence of =, requires absence of extra bits, requires absence of whitespace
WebAuthn: base64url, requires presence of =, requires absence of extra bits, requires absence of whitespace

I'd definitely be interested in any other examples. There does not seem to be any kind of consistency at the moment, though; the claim that "forgiving base64 decode is used by browsers for all their base64 needs" seems false.

Is it false? What you have written above makes me think that for CSP they could use the same decoder as the equality check only involves the encoder. And everything else seems to be base64url, which can indeed be different. It would be nice if they could all be the same base64url though.

I suppose it's false only if you regard base64-with-urlsafe-alphabet to be a kind of base64, but I think most people would. I do, at any rate.

What you have written above makes me think that for CSP they could use the same decoder as the equality check only involves the encoder.

It's phrased in terms of the encoder, but it could just has easily have been phrased in terms of performing a strict decoding - that is, where currently it says roughly "take the input, hash it, and apply base64 encoding to the result; take the provided string and replace - with + and _ with /; accept iff the two strings are identical", it could easily have said (and is probably best understood to mean) "take the input and hash it; take the provided string, replace - with + and _ with /, and apply strict base64-decoding to the result (rejecting on failure); accept iff the two byte sequences are identical".

I'm looking at this from the perspective of what the minimal abstraction would be that satisfies all these callers.
It seems to me that if removal of whitespace and = code points was a pre-processing step done by forgiving base64, it and base64url needs could share the remaining algorithm. (Assuming we continue to use the encoder for WebAuthn and CSP and I don't really see why we wouldn't.) I guess I'd lean towards exposing that through an API (and requiring those that want to match data: URLs and atob/btoa to implement the pre-processing step).

It seems to me that if removal of whitespace and = code points was a pre-processing step done by forgiving base64, it and base64url needs could share the remaining algorithm.

I'd prefer to phrase the "removal of valid = padding, if present" part as "addition of = as necessary to have valid padding", at which point it is the decoding this proposal currently defaults to (i.e., the canonical base64 decoding).
(Except for the question of whether to reject excess non-zero bits in the last characters, though again that could be understood as forgiving-base64 performing normalization of those bits before invoking this API.)

Well, the fact that ignoring bits is also done for base64url makes me think it's across all callers, no?

It's not done for CSP or WebAuthn.
(It's also just a perverse thing to do; I'm confident it could be changed across the web platform without breaking anything. There is no reasonable way to end up with extra bits without either leaking memory or malicious input. So that is a difference which no one would notice except if it caused them to reject malicious input which they'd previously been accepting.)

Given the way CSP and WebAuthn are defined that's not observable, right?

As a user, what I see is that if I have a script containing just console.log('hi'), and I have a CSP with script-src 'sha256-1ohZFo3B9w3UOFBbfx6JSomkpkME90iPs1r/qXzvX7Y=', then my script will load, but if I change the trailing Y to a Z (thus setting an extra non-zero bit in the last character), then my script will not load.
(Per spec and Firefox; Chrome does not correctly implement the spec.)
So as a user it certainly seems observable.

If that's done by encoding console.log('hi') and then comparing, how would you notice as it only affects the decoder? (If Chrome in fact decodes the script-src line and then compares, that would be even more evidence that the decoders all have that behavior.)

As a user, I neither know nor care whether the specification happens to be phrased as "base64-encode the script's sha and compare to the provided string" or "strict base64-decode the provided string and compare to the script's sha".
What matters is that the behavior I actually observe is that this is a place where I am providing a base64-encoded string, and if I provide a string which has extra non-zero bits then it will not work. As such, it would be consistent with that behavior for the decoding API in this proposal to likewise reject base64-encoded strings which have extra non-zero bits.

I looked into this further, WebKit essentially has these decoding modes in terms of code paths being used:

Default, ignore padding
Default, enforce padding
Default, enforce padding and ignore whitespace (forgiving base64)
URL (ignores padding)

Notably none of these enforce "Canonical Encoding" of the RFC and for base64url it doesn't enforce padding either.
Two thoughts so far:

I'm not convinced it's worth adding novel code paths just for JavaScript.
I would be open to investigating whether more of these can be strict (though forgiving base64 has to remain as-is of course).

(For encoding there are exactly two modes, Default and URL, those are hopefully less controversial.)

Ugh. Well, this is certainly a messy state of affairs.
I am, I guess, ok with having the default behavior for the decoder be to not enforce anything about padding and to strip whitespace. In principle this has weird and somewhat subtle security implications in some applications, so I'd really like to default to only allowing canonical encodings, but the fact that nothing else enforces canonicity does have weight.

@annevk

Default, enforce padding and ignore whitespace (forgiving base64)

forgiving base64 does not enforce padding (either the excess bits or the presence of =), so I'm confused by this.

Yeah, that was sloppy wording on my part.

This conversation has mostly focused on padding, but there's also a possible whitespace consideration: https://github.com/tc39/proposal-arraybuffer-base64/pull/27#discussion_r1375304050
I find it strange that the WHATWG definition of ASCII whitespace excludes U+000B VERTICAL TABULATION, but it does, and that would now affect ECMAScript. Accepting AA\u000C== while rejecting AA\u000B== presumably doesn't matter much, but is still worth explicit recognition.

Right now my plan is for the default to exactly match atob, with a strict: true option which would enforce canonical encodings.
I don't think there's much reason to accept the weirder kinds of whitespace. I don't think anyone will literally ever run into the lack of U+000B support, so I'd prefer to stick with matching atob.

Ended up slightly different from above, so to summarize:

the default behavior exactly matches forgiving-base64 (though the algorithm is written differently so it can be shared)
if you specify lastChunkHandling: 'strict', then padding must be included, and the padding bits must be 0, but whitespace is still ignored (so to enforce canonical encodings you must enforce absence of whitespace yourself)


environment.yml cleanup

this looks stale, and cannot be merged right away - can probably be closed.


UG update

To add;
Images of each command being run.

Codecov Report
Base: 70.26% // Head: 70.26% // No change to project coverage :thumbsup:

Coverage data is based on head (e5bd37d) compared to base (d6349ed).
Patch coverage: 50.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #102   +/-   ##
=========================================
  Coverage     70.26%   70.26%
  Complexity      539      539
=========================================
  Files            92       92
  Lines          1732     1732
  Branches        183      183
=========================================
  Hits           1217     1217
  Misses          446      446
  Partials         69       69

Impacted Files
Coverage Δ

...va/seedu/address/logic/commands/CreateCommand.java
93.75% <ø> (ø)

...edu/address/logic/commands/DescriptionCommand.java
100.00% <ø> (ø)

.../seedu/address/logic/parser/AddressBookParser.java
81.81% <ø> (ø)

src/main/java/seedu/address/ui/PersonProfile.java
0.00% <0.00%> (ø)

...eedu/address/logic/parser/CreateCommandParser.java
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


round/floor/trunc etc functions for decimals on n digit

Hi Teo,
Have a look and let me know if you need any changes (syntax, structure, etc).

Super happy to merge this, Taso, thanks a ton! 🙏 🎉


global: js dep upgrade + optional url persistency

upgraded all JS dependencies to latest
added eslint
user can now disable URL Query String persistence

I need to add more tests, but I would like to have your feedback in the meanwhile.


Factory methods should be registered as %newobject in SWIG interface

see http://www.swig.org/Doc3.0/Customization.html 12.2 Object ownership and %newobject

@karlnapf maybe @shubham808 could take a go on this. this is a blocker for 6.2.0

sure :) I am looking into it

ah yes very good point. @shubham808 put it on your todo list. But dont do it this week pls, there is too many other things that need attention first. This can count as a "meta example patch" so just do it instead of porting an example next week or so

this is not needed anymore since shared_ptr...


List of WebAPI limitations in 9.x ?

Quote:
"The Web API allows you to do all the same operations as the organization service but presents them in an RESTful style."
Quote 2:
"The Common Data Service for Apps Web API provides complete parity with the capabilities of the organization service."
This still doesn't appear to be true in 9.1, however, there also doesn't appear to be an up-to-date list of these limitations.
(There is a link to a list of limitations for CRM 2016, but that's a link to the legacy 8.x docs)
In particular, the RetrieveAuditDetails Function is available via the WebApi, but it only exposed the AuditDetail complex type, and not the AttributeAuditDetail type, which would include the NewValue and OldValue properties required to access the actual Pre-/Post-Values of the record.
Is this a known limitation? When will it be fixed?
Thanks and warm regards!

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

ID: 227fd50c-3385-52c1-a57d-08dca61d36c4
Version Independent ID: 3d616dde-59fa-4ab0-14e0-0ddbf972fe64
Content: Use the Common Data Service for Apps Web API (Common Data Service for Apps) - PowerApps
Content Source: powerapps-docs/developer/common-data-service/webapi/overview.md
Service: crm-online
GitHub Login: @brandonsimons
Microsoft Alias: jdaly

@DanielBruckhaus Do you mean there is no AttributeAuditDetail ComplexType and if the feature team has a plan on introducing it ?

Is it fixed?
I would like to get "new" and "old value" through  API.
I'm using PowerBI to pull the the data  quering the data from  https://******/api/data/v9.1/

I assume this has still not been fixed? This is causing me massive headaches in having to keep my audit monitoring and archiving azure functions as V1 functions as they have to continue use the CRM SDK rather than the Web API. Every other azure function I have has been migrated to V3 functions and uses the CRM Web API.

@DanielBruckhaus
Thanks for your feedback. We are closing this issue because we are either unable to find relevant information or reproduce this. If you're still experiencing the issue described here, please reopen or create a new issue.


September Topics

https://voidstarsec.com/blog/replicant-part-1

https://github.com/ElementsProject/lightning/releases/tag/v0.12.0

https://bitcoinmagazine.com/technical/scaling-problem-for-lightning-labs-taro

https://github.com/Xekyo/blockbuilding

https://github.com/bitcoin/bitcoin/pull/25355

https://sfbitcoindevs.org/socratic-29/

List of recent research papers. Could probably use this to source topics
https://twitter.com/ryanthegentry/status/1564992862479126529?s=21&t=r1yk093ISgcCV0BmIgyMMw

https://eprint.iacr.org/2022/1104

https://twitter.com/roasbeef/status/1565066924458795008

Carl dong leaving chaincode and taking break from core contribution https://twitter.com/carl_dong/status/1565108387842560000

Credible Confessions https://github.com/DavidVorick/CredibleConfessions

Analysis of a weird block
https://twitter.com/akakush0/status/1567554622742560768?s=46&t=7tjy4mUmJJ03nPovFnEX4g

Some good ones on here:
http://chibitdevs.org/2022-09-08-Socratic-Seminar-34
maybe mesh networks/making bitcoin network unstoppable?

Samurai Wallet Stonewall p2p dos attack CVE: https://www.cve.org/CVERecord?id=CVE-2022-35913
Includes original report from July: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020914.html

Contracting primitives working group: https://github.com/ariard/bitcoin-contracting-primitives-wg
mailing list post announcement: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020912.html

https://github.com/bitcoin-stark/khepri

https://twitter.com/n1ckler/status/1569709006154874880

https://github.com/lightningdevkit/rust-lightning/pull/1706

https://river.com/learn/what-is-taro-in-bitcoin/

https://btc.usespiral.com/

Silicon Salon 2 was held today & summaries will be published tomorrow.
https://siliconsalon.info/


Tokenomics implementation

Updated the implementation to comply with the new spec

Had to skip a few of the check in test_omnipool_amm. I feel like they are not important, but let me know. Also did not get the two-part token-lrna-token swap mechanic to work, and I think it needs more math. But overall I believe everything works that needs to.

I think we also need changes in tests/test_amm.py? At least it appears to be broken for me due to missing 'L'...

@jepidoptera in addition to the changes in my comments in my review you will also want to make the fix for the spec issue you noticed in the actual implementation... I only fixed it in the spec.

@jepidoptera in addition to the changes in my comments in my review you will also want to make the fix for the spec issue you noticed in the actual implementation... I only fixed it in the spec.

actually double-check this... but the implementation already looks correct to me?


Ensure no parameter is passed to 'done' function

Since nodejs 9.0.0, fs.writeFile seems to throw an undefined parameter as error instead of no parameter in the call back. It leads to an error 'done is not a function'
Now working with node 10.0.0

@sapegin  Any chance on getting this merged and a new release please?

I can give you push rights to the repo and an npm package, if you want to make a new release. I haven't touched Grunt and icon fonts for many years ;-/

Yes, that's a solution !


ocamlformat: 0.8 → 0.11.0

Motivation for this change
Compatibility with OCaml 4.07.
Things done

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

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

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

Notify maintainers
cc @Zimmi48

@GrahamcOfBorg eval


Alpha channel in Blender BSDF mapped to Albedo texture

Now that tools are available to merge texture channels together to minimise the number of samplers in the Simple PBR shader, it is planned to add the Alpha channel in blender bsdf material into the output Albedo alpha channel.
This will produce more consistent alpha sync results without the need for render script changes.

This has been completed. Works well.


[Bug] safety rules on disk storage write is not atomic

We observe empty safety_rules.toml file in one of the cluster and result in a crash loop, the current theory is the node shutdown in the middle of a write and result in this invalid empty file.

Resolved in #2078
will close this task once landed


Correction for raw affiliation AMAP, Univ. Montpellier, IRD, CNRS, CIRAD, INRAE, Montpellier, France

Correction needed for raw affiliation AMAP, Univ. Montpellier, IRD, CNRS, CIRAD, INRAE, Montpellier, France
raw_affiliation_name: AMAP, Univ. Montpellier, IRD, CNRS, CIRAD, INRAE, Montpellier, France
new_rors: 03rnk6m14;02feahw73;05q3vnk25;003vg9w96;05kpkpg04;051escj72;020nks034
previous_rors: 03rnk6m14;02feahw73;05q3vnk25;003vg9w96;05kpkpg04;051escj72
works_examples: W4403360967
contact: e6bae625ebdf2e6209fed1e8e433e578:990e143146d3f3f501dd4e27ad8f51e82802 @ inrae.fr

This issue was accepted and ingested by the OpenAlex team on 2024-11-18. The new affiliations should be visible within the next 7 days.


bme280 sample does not compile

Describe the bug
The https://docs.zephyrproject.org/latest/samples/sensor/bme280/README.html build instructions do not build. The recommended board (nrf52840_pca10056) doesn't have that sensor in its DTS, so the reason why is clear, but all in-tree samples should compile.
I am unable to find a board in tree which does have this sensor in its DTS.
It's not clear to me whether or how mainline CI is building this sample. It seems like the fixture restriction is bypassing it:
sanitycheck -vv -T samples/sensor/bme280/ -p nrf52840_pca10056
...
DEBUG   - nrf52840_pca10056         samples/sensor/bme280/sample.sensor.bme280         SKIPPED: No hardware support
DEBUG   - nrf52840_pca10056         samples/sensor/bme280/sample.sensor.bme280.spi     SKIPPED: No hardware support

To Reproduce
Steps to reproduce the behavior:

cd zephyr
west build -b nrf52840_pca10056 samples/sensor/bme280
observe build error

In file included from /home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c:24:0:
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.h:114:2: error: #error "BME280 device type not specified"
 #error "BME280 device type not specified"
  ^~~~~
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c: In function 'bme280_init':
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c:370:22: warning: unused variable 'data' [-Wunused-variable]
  struct bme280_data *data = dev->driver_data;
                      ^~~~
In file included from ../include/drivers/sensor.h:23:0,
                 from /home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c:11:
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c: At top level:
/home/mbolivar/zp/zephyr/drivers/sensor/bme280/bme280.c:398:29: error: 'DT_INST_0_BOSCH_BME280_LABEL' undeclared here (not in a function); did you mean 'DT_INST_0_SOC_NV_FLASH_LABEL'?
 DEVICE_AND_API_INIT(bme280, DT_INST_0_BOSCH_BME280_LABEL, bme280_init, &bme280_data,
                             ^
../include/device.h:106:11: note: in definition of macro 'DEVICE_AND_API_INIT'
   .name = drv_name, .init = (init_fn),     \
           ^~~~~~~~

Expected behavior
Following build instructions for built-in samples should not result in compile errors.
Environment (please complete the following information):

Commit SHA or Version used: today's master (b96477dd69)

is this really a high prio bug?

is this really a high prio bug?

Well, a non-building sample in the tree was something we decided we want fixed before the release (doesn't really matter what the priority is, but setting high forces it to be done). This was at least the consensus in yesterday's release meeting.

doesn't really matter what the priority is, but setting high forces it to be done

This is bad, high priority bugs should really be reserved to bugs that are more critical than a sample that does not build due to some missing overlay...


Add eve2test script

eve2test is a script to convert eve.json into test.yaml file. This
currently implements the functionality of creating the "checks" block
in test.yaml from a given eve.json. You can add other configuration
in the file thus created.
Usage
$ python eve2test.py -h
usage: eve2test [-h] [--eventtype-only] [--allow-events [ALLOW_EVENTS]]
                <path-to-eve> <output-path>

Convert eve.json to test.yaml

positional arguments:
  <path-to-eve>         Path to eve.json
  <output-path>         Path to the folder where generated test.yaml should be
                        put

optional arguments:
  -h, --help            show this help message and exit
  --eventtype-only      Create filter blocks based on count of event types only
  --allow-events [ALLOW_EVENTS]
                        Create filter blocks for the specified events

This is a nice idea

Followed up in #162


Much type-safer swift .localize implementation

Does not crash if string is not localized.

Thanks Roman! Good call.
p.s. Travis is failing because of a homebrew issue. I'll commit the workaround in a second.


Add dither info and gal coordinates to db

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

23 of 26 (88.46%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.007%) to 84.607%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

mirar/pipelines/winter/load_winter_image.py
6
9
66.67%

Totals

Change from base Build<PHONE_NUMBER>:
0.007%

Covered Lines:
11158

Relevant Lines:
13188

💛  - Coveralls


Cant Use DefaultScope with sequelize.literal

Versions

sequelize: 5.8.5
sequelize-typescript: 1.0.0-alpha.9
typescript: 3.4.5

I'm submitting a ...

[x] bug report
[ ] feature request
Actual behavior:
calling .findAll + default scope with a custom attribute defined with a literal.
Expected behavior:
Steps to reproduce:
This code producess
@Table({tableName: 'brocca'})
    @DefaultScope({
      attributes: [
        [sequelize.literal('meow'), 'aaa'],
      ],
    })
    class Brocca extends Model<Brocca> {

    }
    const bit = new Sequelize({dialect: 'postgres'});
    bit.addModels([Brocca]);
    await Brocca.findAll();

Stacktrace:
TypeError: attr[0].includes is not a function
    at attributes.map.attr (node_modules/sequelize/lib/dialects/abstract/query-generator.js:1383:29)
    at Array.map (<anonymous>)
    at PostgresQueryGenerator.escapeAttributes (node_modules/sequelize/lib/dialects/abstract/query-generator.js:1368:37)
    at PostgresQueryGenerator.selectQuery (node_modules/sequelize/lib/dialects/abstract/query-generator.js:1134:28)
    at QueryInterface.select (node_modules/sequelize/lib/query-interface.js:1120:27)
    at Promise.try.then.then.then (node_modules/sequelize/lib/model.js:1744:34)
    at tryCatcher (node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (node_modules/bluebird/js/release/promise.js:694:18)
    at _drainQueueStep (node_modules/bluebird/js/release/async.js:138:12)
    at _drainQueue (node_modules/bluebird/js/release/async.js:131:9)
    at Async._drainQueues (node_modules/bluebird/js/release/async.js:147:5)
    at Immediate.Async.drainQueues [as _onImmediate] (node_modules/bluebird/js/release/async.js:17:14)

Related code:
...

Hey @RobinBuschmann
Apparently the same codebase works if using plain "sequelize" code. Here a snippet showing sequel-typescript vs sequelize code.
import * as sequelize from 'sequelize';
import { Sequelize as SSequelize } from 'sequelize';
import { DefaultScope, Model, Sequelize, Table } from 'sequelize-typescript';

describe('test', () => {
  it('test', async () => {
    // console.log('a');
    @Table({ tableName: 'brocca' })
    @DefaultScope({
      attributes: [[sequelize.literal('meow'), 'aaa']],
    })
    class Brocca extends Model<Brocca> {}
    const bit = new Sequelize({ dialect: 'postgres', logging: true });
    bit.addModels([Brocca]);
    await Brocca.findAll();

  });
  it('test2', async () => {
    class Brocca extends Model {}
    const s = new SSequelize('test', 'test', 'password', {dialect: 'postgres', logging: true});
    Brocca.init({}, {
      defaultScope: {
        attributes: [[sequelize.literal('meow'), 'aaa']],
      },
      sequelize: s,
      tableName: 'brocca',
    });
    console.log('hey');
    await Brocca.findAll();
  });
});

Hey @vekexasia, thanks for reporting. But this is fixed with the latest pre-major release<EMAIL_ADDRESS>Passing objects to @Scopes and @DefaultScope is deprecated there - Use it like so instead:
    @DefaultScope(() => ({ // <-- lambda
      attributes: [[sequelize.literal('meow'), 'aaa']],
    }))

Hope this helps!

@vekexasia Does my suggestion solve your issue? Can we close this now?

yes sorry :)


Remove non-existant import

Description
This issue exists on master, but would break any build that is trying to verify against release 2, and thus this small fix needs to make it into this release to allow for verification of the future release 3 to work.
It was fixed on master at https://github.com/celo-org/celo-monorepo/pull/5945

hey @nambrot is there a reason not to merge commits on master through fdf4f4a (includes the fix in #5945)? Will the release not be merged into master eventually, or is there just a plan to have one massive merge request later on? Fine in either case and can approve this, but wanted to clarify. Thanks!

hey @nambrot is there a reason not to merge commits on master through fdf4f4a (includes the fix in #5945)? Will the release not be merged into master eventually, or is there just a plan to have one massive merge request later on? Fine in either case and can approve this, but wanted to clarify. Thanks!

Hi @eelanagaraj thanks for your question.
This PR is against the release branch for Release 2 of the Celo Core Contracts. It will culminate in a commit that will get deployed on the public testnets and mainnet. For that reason, master is no longer relevant for this branch (as that would require another audit).
However, a future release 3 will then compare against release 2 and for the verification tooling to work, the released commit will need to be able to build, thus we need to duplicate the fix on this branch (even though this branch will get merged into master).
Does that answer your question?

Hi @eelanagaraj thanks for your question.
This PR is against the release branch for Release 2 of the Celo Core Contracts. It will culminate in a commit that will get deployed on the public testnets and mainnet. For that reason, master is no longer relevant for this branch (as that would require another audit).
However, a future release 3 will then compare against release 2 and for the verification tooling to work, the released commit will need to be able to build, thus we need to duplicate the fix on this branch (even though this branch will get merged into master).
Does that answer your question?

thanks for the response, makes sense!

thanks for the response, makes sense!

Merging this into #6402 so that the CI checks can pass together

Merging this into #6402 so that the CI checks can pass together


installing the application

Hello,
I'm new in github and developing code but in my company we are very interested in 3D printing and now I'm investigating about new 3D formats. I would like to use the lib3mf but I don't know much about compiling source code. Could you please explain the steps to make the application run in windows or linux?
Thank you very much in advance.
Best regards,
Ignacio.

On windows, you can go to ...\Project\Lib3MF folder and use the Visual Studio solution Lib3MF.sln to build 3MF library files Lib3MF.* or Lib3MFC.* based on the chosen flavours (COM like interface or C like DLL interface). On Linux, you can go in ...\Project\Lib3MFGCC and use the Makfile to generate lib3MF.so.

Hello Parviz, thanks for your quick response. In fact I tried to run makefile in ubuntu 12.04.4, but didn't work.
Regards,

I can not attach any file here!
I can provide you with a Makefile that should work on Ubuntu if you give me your email address.
Parviz

Dear Ignacio,
can you post the error messages?
Best,
Alexander

Hello!
Parviz, my address is<EMAIL_ADDRESS>and after supressing some blanks in the Makefile file, the first errors are
Makefile_v1: 21: Makefile_v1: -I../../Include: not found
Makefile_v1: 22: Makefile_v1: -std=c++11: not found
Makefile_v1: 23: Makefile_v1: -Wall: not found
Makefile_v1: 33: Makefile_v1: -I../../Include: not found
Makefile_v1: 34: Makefile_v1: -O2: not found
Makefile_v1: 35: Makefile_v1: -O2: not found
Makefile_v1: 40: Makefile_v1: -s: not found
Makefile_v1: 44: Makefile_v1: clean_release:: not found
Makefile_v1: 45: Makefile_v1: OBJ_RELEASE: not found
Makefile_v1: 45: Makefile_v1: OUT_RELEASE: not found
Makefile_v1: 47: Makefile_v1: OBJDIR_RELEASE: not found
I have a low knowledge of linux. Maybe these error are basics...
Thank you very much.
Best regards,
Ignacio.

Hi Ignacio
Attached the updated Makefile for Linux.
Let us know if any issues.
Thanks
Parviz
From: IgnacioCollantes<EMAIL_ADDRESS>Sent: Thursday, October 22, 2015 9:23 AM
To: 3MFConsortium/lib3mf
Cc: Parviz Rushenas
Subject: Re: [lib3mf] installing the application (#3)
Hello!
Parviz, my address is ignacio.collantes<EMAIL_ADDRESS>and after supressing some blanks in the Makefile file, the first errors are
Makefile_v1: 21: Makefile_v1: -I../../Include: not found
Makefile_v1: 22: Makefile_v1: -std=c++11: not found
Makefile_v1: 23: Makefile_v1: -Wall: not found
Makefile_v1: 33: Makefile_v1: -I../../Include: not found
Makefile_v1: 34: Makefile_v1: -O2: not found
Makefile_v1: 35: Makefile_v1: -O2: not found
Makefile_v1: 40: Makefile_v1: -s: not found
Makefile_v1: 44: Makefile_v1: clean_release:: not found
Makefile_v1: 45: Makefile_v1: OBJ_RELEASE: not found
Makefile_v1: 45: Makefile_v1: OUT_RELEASE: not found
Makefile_v1: 47: Makefile_v1: OBJDIR_RELEASE: not found
I have a low knowledge of linux. Maybe these error are basics...
Thank you very much.
Best regards,
Ignacio.
—
Reply to this email directly or view it on GitHubhttps://github.com/3MFConsortium/lib3mf/issues/3#issuecomment-150222161.

sorry Parviz, I can't see the attached file... :)

It was attached to the email!
I re-send it again directly to you.
Parviz
From: IgnacioCollantes<EMAIL_ADDRESS>Sent: Thursday, October 22, 2015 9:50 AM
To: 3MFConsortium/lib3mf
Cc: Parviz Rushenas
Subject: Re: [lib3mf] installing the application (#3)
sorry Parviz, I can't see the attached file... :)
—
Reply to this email directly or view it on GitHubhttps://github.com/3MFConsortium/lib3mf/issues/3#issuecomment-150228703.

hi all,
I want to install the same on windows 7
i am not able to build the project from VS2012
it giving syntactical errors on all the lines where "CModelWriterNode() = delete;" such kind of syntax is used.
i am new to 3MF.
Please help me ASAP.
Thank you. :)

@sharayumane The .sln and .vcxproj files in Project/Lib3MF folder have been created with Visual Studio 2013, so it is safe to assume, you need VS2013 or later to build the library.
FYI, CModelWriterNode() = delete; is correct C++11 syntax, but you need Visual C++ from VS2013 or later.

I tried in VS 2015
still giving same error
Will you please tell now what's the issue?

@sharayumane  I have successfully built the current master branch of lib3mf with VS2013 Update 4 and VS2015 Update 2. I suggest you to double check that you are building with one of those IDEs using the provided Lib3MF.sln.


DataStream-api-package-guidance

closed #1729

According to the pom package, the data can be displayed normally in my cluster.

This can run in the cluster, but it can't debug it in idea. It will report that gauva 18 can't be found. How to solve it?

@GOODBOY008 @Jiabao-Sun @ruanhang1993 PTAL

@lvyanquan Can you help me see if there is any problem with the basic pom example? I can easily modify the version.

This may be duplicated with this doc Usage for DataStream API. Not sure whether we should add a new page for maven package.

This may be duplicated with this doc Usage for DataStream API. Not sure whether we should add a new page for maven package.

cc @leonardBang @ruanhang1993 @GOODBOY008 @Jiabao-Sun

This may be duplicated with this doc Usage for DataStream API. Not sure whether we should add a new page for maven package.

@lvyanquan  This PR aims to telling users how to package a DS project which used flink cdc connectors, like flink shaded guava and mysql driver, these dependenc,ies are different in each flink cdc version. The link you posted just a DS quickstart for each cdc connector DS API, it's not enough to build DS application using flink cdc connectors。

@gtk96 Maye we can link the guidance to [Usage for DataStream API](https://ververica.github.io/flink-cdc-connectors/master/content/about.html#usage-for-datastream-api） section of each cdc connectors

@gtk96 Maye we can link the guidance to [Usage for DataStream API](https://ververica.github.io/flink-cdc-connectors/master/content/about.html#usage-for-datastream-api） section of each cdc connectors

We have so many connectors that I can't verify them one by one.😫


Display Unlighthouse reports

[x] CI action for site scanning after deployment to the stage
[x] A site's page for receiving and viewing these reports

requested changes. Also there is missing team review, and there is no attached issue and project to PR
https://github.com/ita-social-projects/ZeroWaste/pull/996#pullrequestreview-2471415447


Error loading syntax file ST4, Debian 11 "Bullseye"

Getting the following error while sublime text opens and tries to load the syntax highlighting plugin support:
Error loading syntax file "Packages/Ruby Slim/Syntaxes/Ruby Slim.tmLanguage":
Error in regex: target of repeat operator is invalid in regex (?<!\\)(#).$$?

And this is the full output of the console related to that:
Error loading scope:source.erb: Unable to find syntax file for scope "source.erb" in Packages/Ruby Slim/Syntaxes/Ruby Slim.tmLanguage
Error loading scope:source.less: Unable to find syntax file for scope "source.less" in Packages/Ruby Slim/Syntaxes/Ruby Slim.tmLanguage
error: Error loading syntax file "Packages/Ruby Slim/Syntaxes/Ruby Slim.tmLanguage": Error in regex: target of repeat operator is invalid in regex (?<!\\)(#).*$$?

Let me know if I can help with some debugging information or something.

I am experiencing the same issue(I am on macOS)
I did some research and it looks like there are problems with the coffee part here https://github.com/slim-template/ruby-slim.tmbundle/blob/master/Syntaxes/Ruby Slim.tmLanguage#L97-L119
As a workaround the syntax file can be overriden (the path should be Packages/Ruby Slim/Syntaxes/Ruby Slim.tmLanguage) and the section between lines 97 and 119 should be commented out.
Most likely it will break highlighting of CoffeeScript within slim files, but it is better than nothing.

@timfjord Hey, thanks for the tip! I actually disabled/removed coffeescript language support package and now the slim syntax files are highlighted properly so I guess it does have something to do with the combination of Coffee and Slim 🤷🏻

I played a bit with Coffee and Slim and it looks like the issue is in the [Better CoffeeScript](https://github.com/aponxi/sublime-better-coffeescript plugin) plugin(I bet you use this plugin on your machine).
In particular there are issues with parsing Coffee comment. Slim is complaining because it embeds the Coffee syntax.
I was able to fix it by reinstalling the Better CoffeeScript plugin. So after I reinstalled it the workaround is no longer needed

timfjord

Interesting! I will try it tomorrow. I'm trying as much as I can to migrate our CoffeeScript code to ECMA to be honest because coffee is not something I enjoy, the language, not the drink 😁


Slackware Build Updated to 1.2

Hi
I just wanted to let you know that I've just submitted goaccess 1.2 to slackbuilds.org. It will probably be week before it's approved.
The current link is here:
https://slackbuilds.org/repository/14.2/system/goaccess/
And this will remain the same when 1.2 is up.
Cheers.

This is great :) Thanks submitting and sharing this! Looks like it's up already in 14.2.


[Broker] Ledge creation timeout

Ledger creation always timeout, continued for several hours . But from bookkeeper's log, there were no errors.
2022-02-16 11:22:23.111 [BookKeeperClientWorker-OrderedExecutor-37-0] INFO  org.apache.bookkeeper.mledger.impl.ManagedLedgerImpl - [public/data-channel/persistent/xxx-partition-48] Ledger creation was initiated 120440 ms ago but it never completed and creation timeout task didn't kick in as well. Force to fail the create ledger operation.
2022-02-16 11:22:23.111 [BookKeeperClientWorker-OrderedExecutor-37-0] ERROR org.apache.bookkeeper.mledger.impl.ManagedLedgerImpl - [public/data-channel/persistent/xxx-partition-48] Error creating ledger rc=-23 Bookie operation timeout

Looks like zookeeper issues? or some dead lock in the broker? It's better to capture a broker thread dump.

It may be fixed by  #13744


Transfer this repository to ScottPlot organization

I am strongly considering transferring this repository from my user account (https://github.com/swharden) to the ScottPlot organization account (https://github.com/ScottPlot). I plan to make this change on Janurary 9, 2021.
According to GitHub Documentation, transferring a repository:

If the transferred repository has any forks, then those forks will remain associated with the repository after the transfer is complete.
All links to the previous repository location are automatically redirected to the new location.

When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL.
However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL. You can do this by using git remote on the command line: git remote set-url origin new_url

Altogether this transfer should be relatively simple, and old URLs will automatically redirect to new ones.. but I wanted to leave this issue up for the next few weeks in case anyone had any comments about it.

The transfer has been made, and it seemed to go smoothly 👍

The transfer has been made, and it seemed to go smoothly 👍


Remove the DESCRIPTION label from the issue template

Since we removed the screenshot section in #43 and #46, we only have the description label in our issue templates for features and documentation.
Now that we've done that, the description label is redundant and unnecessary.
It'd be cleaner to remove it.

@ykdojo Could you please point me to where the issue template is? Can't seem to find it.

It is okay. I have found it.

@ykdojo I worked on this issue, and changes were merged with this PR #52. I didn't know I have to wait for a PR to be merged before I can push changes for a second PR. It is the last commit of that PR.

@Jonyango it's all good. We have #58 now though.

Maybe there's no way to do it? If so, I'll just close this issue.

is this still open?

@Preet-Sojitra yes it is

So what should I write in place of Description ?
I guess something should be written in place of it right or if I remove it without replacing it, it won't break?

Right, that's the thing - it'll probably break if we simply remove it.
It's totally unnecessary, though.
Ideally, there is a way to remove the header without affecting everything else, but I just wasn't sure there is.

Closing this as body is required and cannot be empty in issue templates.


Ruby: rtx install ruby fails

Describe the bug
Background: Trying to replace asdf with rtx on my M1 Mac running macOS 13.4.
Unlike the other core plugins I've tried (python, go) when I run rtx use -g<EMAIL_ADDRESS>I get this warning, which fails installation:
❯ RTX_DEBUG=1 rtx use -g<EMAIL_ADDRESS>[DEBUG] rtx::config: Files: ~/.config/rtx/config.toml
Installed Plugins: go, ruby
[DEBUG] rtx::cli: rtx use -g<EMAIL_ADDRESS>[DEBUG] rtx::cmd: $ /Users/alec/.local/share/rtx/plugins/ruby/bin/list-all
[WARN] rtx::toolset::tool_version_list: failed to resolve tool version: Failed listing remote versions for plugin ruby: error running list-all: exited with code 1
Downloading ruby-build...
[DEBUG] rtx::cmd: $ /Users/alec/.local/share/rtx/plugins/ruby/bin/list-all
[WARN] rtx::toolset::tool_version_list: failed to resolve tool version: Failed listing remote versions for plugin ruby: error running list-all: exited with code 1
Downloading ruby-build...
[WARN] rtx::toolset::tool_version_list: failed to resolve tool version: Failed listing remote versions for plugin ruby: error running list-all: exited with code 1
Downloading ruby-build...

Other commands that use a Ruby version like rtx ls-remote ruby also fail with the same error.
To Reproduce
Steps to reproduce the behavior.

Install rtx
Run any core Ruby plugin command e.g. rtx install ruby@latest

Expected behavior
I would expect the core Ruby plugin to work like the others and install Ruby.
rtx doctor output
[WARN] rtx::toolset::tool_version_list: failed to resolve tool version: Failed listing remote versions for plugin ruby: error running list-all: exited with code 1
Downloading ruby-build...
rtx version:
  1.34.1 macos-arm64 (unknown 2023-07-14)

build:
  Target: aarch64-apple-darwin
  Features: BREW
  Built: Fri, 14 Jul 2023 19:05:56 +0000
  Rust Version: rustc 1.70.0 (90c541806 2023-05-31) (built from a source tarball)
  Profile: release

shell:
  /opt/homebrew/bin/zsh
  zsh 5.9 (arm-apple-darwin21.3.0)

rtx environment variables:
  RTX_SHELL=zsh

settings:
  {"always_keep_download": "false", "always_keep_install": "false", "asdf_compat": "false", "disable_default_shorthands": "false", "disable_tools": "[]", "experimental": "false", "jobs": "4", "legacy_version_file": "true", "legacy_version_file_disable_tools": "[]", "log_level": "INFO", "missing_runtime_behavior": "warn", "plugin_autoupdate_last_check_duration": "10080", "raw": "false", "trusted_config_paths": "[]", "verbose": "false"}

config files:
  /Users/alec/.config/rtx/config.toml

plugins:
  go       https://github.com/rtx-plugins/rtx-golang.git#23c62dd
  node     (core)
  python   (core)
  ruby     https://github.com/rtx-plugins/rtx-ruby.git#203001f

toolset:
  go@latest, python@latest, <EMAIL_ADDRESS>
No problems found

Additional context
It's worth noting that for each language I removed the old asdf plugin before running rtx core plugin install commands like rtx use -g<EMAIL_ADDRESS>and I have not run any rtx plugins install commands, yet rtx doctor still indicates that I'm using the non-core version of go and ruby. This may be expected but thought I would highlight this:
plugins:
  go       https://github.com/rtx-plugins/rtx-golang.git#23c62dd
  node     (core)
  python   (core)
  ruby     https://github.com/rtx-plugins/rtx-ruby.git#203001f

you are not actually using the core plugin, for that you need to enable experimental mode with rtx settings set experimental true

Thanks, that solved my issue!


Could you also provide an instruction for ARM template?

Could you also provide an instruction for ARM template to set up disk encryption for Azure Virtual Machine Scale Sets?

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

ID: 268e2a87-ffab-440a-dcb4-1d15c89d9d55
Version Independent ID: e9c8b2f2-5689-3b64-3cb6-92039005ee31
Content: Encrypt disks for Azure scale sets with Azure PowerShell
Content Source: articles/virtual-machine-scale-sets/virtual-machine-scale-sets-encrypt-disks-ps.md
Service: virtual-machine-scale-sets
GitHub Login: @cynthn
Microsoft Alias: cynthn

@hukun01 thanks for the update! Glad to hear you got it resolved :)


[FEATURE REQ] Enable/disable azure-spring-boot auto configurations based on properties

Is your feature request related to a problem? Please describe.
There is currently no flexibility in when the *AutoConfiguration classes in azure-spring-boot are applied. In some scenarios it is feasible to disable certain *AutConfiguration classes. This would provide flexibility in configuring different Spring context, especially in tests.
Describe the solution you'd like
Support enabling/disabling of *AutoConfiguration classes in azure-spring-boot using properties. For example: azure.storage.enabled or azure.cosmos.enabled.
Describe alternatives you've considered
None.
Additional context
None.

@rvvaeke Thanks for your advice, we have added it to our backlog and will discuss about it. We will inform you if there is any updates.

This has been merged to the feature/azure-spring-cloud-4.0 branch. https://github.com/Azure/azure-sdk-for-java/pull/23849

Closing this issue now, please check https://github.com/Azure/azure-sdk-for-java/issues/24260 for the release of our next major version.


Wrong link in readme and incomplete information

Description

The link of Community Welcome Guide is redirecting to repository overview and  information to repository overview and joining slack link information is incomplete as other readme's

Expected Behavior

Link of Community Welcome Guide should redirect to https://layer5.io/community/newcomers and proper information of repository overview and how to join slack should be implemented.

For reference : https://github.com/meshery/meshery/blob/master/README.md

Enviroment:

OS: Mac Linux Windows
Browser: Chrome Safari Firefox
Version:
Device: Desktop Mobile

Contributor Guides and Handbook
The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

📚 See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

I want to work on this.

Hey @leecalcote can you assign it to me so that I can raise my pr


Bulk Selected Pages - Deselects When Expanding File/Record in Left Pane

Describe the bug in current situation
When selecting page to bulk select in the left (navigation) pane, if you click a file name to expand a file, while you already have pages bulk selected, it clears you bulk selects. This can cause a lot of frustration for users.
Link bug to the User Story
Impact of this bug
Describe the impact, i.e. what the impact is, and number of users impacted.
Low
Chance of Occurring (high/medium/low/very low)
High
Pre Conditions: which Env, any pre-requesites or assumptions to execute steps?
Test Marshal
Steps to Reproduce
Steps to reproduce the behavior:

Bulk select several pages under a file/record

Private Zenhub Image

Click on another file/record name to expand the file. See error where it deselects your previous bulk selections

Private Zenhub Image
Private Zenhub Image
Actual/ observed behaviour/ results
Bulk selections are cleared when expanding and collapsing a file in left pane.
Expected behaviour
A clear and concise description of what you expected to happen. Use the gherking language.
GIVEN a user has bulk selected pages (using Ctrl + left click or Shift + left click)
WHEN the user clicks on a file/record name in the left (navigation) pane to expand or collapse the file
THEN the bulk selections are are retained
AND bulk selections are only 'cleared' when the user left clicks on a page number
Private Zenhub Image
Screenshots/ Visual Reference/ Source
If applicable, add screenshots to help explain your problem. You an use screengrab.

@m-prodan @liseandtea @lmullane @JHarrietha-AOT - ticket for bug raised in pilot user discussion today.

Works really nicely now - you can expand and recollapse files without having lost your ctrl selections - should address user feedback well.
Tests various flags without issue. Did observe some unexpected behavior when trying the withheld in full flag, will likely create another ticket regarding that but nothing showstopping.


jumplist: prefer the app execution alias in %LOCALAPPDATA%

By setting the jumplist entries to launch WindowsTerminal.exe out of
the package root, we've inadvertently made WindowsTerminalDev emit jump
list entries that launch the unpackaged version of Terminal.
We can fix this by copying the code from the shell extension that
determines which version of the executable to launch -- wt, wtd or
WindowsTerminal -- depending on the context under which it was invoked.
Fixes #7554
References
I should like to deduplicate this code with the shell extension, but I'd rather
this be fixed than beautiful.
PR Checklist

[x] Closes #7554
[x] CLA signed. If not, go over here and sign the CLA
[x] Tested (manually)
[ ] Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
[ ] Schema updated.

Validation Steps Performed
Installed WTD as WindowsTerminalDev, launched it via jumplist. Ran unpackaged, launched via jumplist. Installed WTD as Microsoft.WindowsTerminal (release, stable), launched via jumplist.

@Sidneys1 may be happy to see this ;P

@msftbot merge this in 1 minutes


Add mainnet date

Codecov Report
Patch and project coverage have no change.

Comparison is base (e7ac16f) 71.89% compared to head (d20f4b4) 71.89%.

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

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #727   +/-   ##
=======================================
  Coverage   71.89%   71.89%
=======================================
  Files         570      570
  Lines       31570    31570
=======================================
  Hits        22696    22696
  Misses       8874     8874

Flag
Coverage Δ

unittests
71.89% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Test failure: ClientNearCacheTest/BasicClientReplicatedMapNearCacheTest.whenCacheIsFull_thenPutOnSameKeyShouldUpdateValue_withUpdateOnNearCacheAdapter/0

We sometimes see the test ClientNearCacheTest/BasicClientReplicatedMapNearCacheTest.whenCacheIsFull_thenPutOnSameKeyShouldUpdateValue_withUpdateOnNearCacheAdapter/0 fail at nightly builds. The logs are:
/home/jenkins/jenkins/workspace/cpp-centos7-nightly-32-SHARED-Release/hazelcast/test/src/replicatedmap/nearcache/BasicClientReplicatedMapNearCacheTest.cpp:153
Value of: actual
  Actual: 1
Expected: expected
Which is: 2
Near Cache hits should be 2, but were 0 (NearCacheStatsImpl{ownedEntryCount=500, ownedEntryMemoryCost=1000, creationTime=1543356963756, hits=1, misses=1002, ratio=0.1, evictions=0, expirations=0, invalidations=2, invalidationRequests=0, lastPersistenceTime=0, persistenceCount=0, lastPersistenceDuration=0, lastPersistenceWrittenBytes=0, lastPersistenceKeyCount=0, lastPersistenceFailure=''})

/home/jenkins/jenkins/workspace/cpp-centos7-nightly-32-SHARED-Release/hazelcast/test/src/replicatedmap/nearcache/BasicClientReplicatedMapNearCacheTest.cpp:153
Value of: actual
  Actual: 1002
Expected: expected
Which is: 1001
Near Cache misses should be 1001, but were 0 (NearCacheStatsImpl{ownedEntryCount=500, ownedEntryMemoryCost=1000, creationTime=1543356963756, hits=1, misses=1002, ratio=0.1, evictions=0, expirations=0, invalidations=2, invalidationRequests=0, lastPersistenceTime=0, persistenceCount=0, lastPersistenceDuration=0, lastPersistenceWrittenBytes=0, lastPersistenceKeyCount=0, lastPersistenceFailure=''})

and details:
01:16:03 Members [2]  {
01:16:03 	Member[localhost]:5702 - 3aea0568-b73c-46af-8d36-feab13390a9c
01:16:03 	Member[localhost]:5701 - c4ed08f2-a0af-4161-a004-b147697893ff
01:16:03 }
01:16:03
01:16:03 27/11/2018 22:16:03.756 INFO: [0xe55fcb40] hz.client_294[dev] [3.10.2-SNAPSHOT] LifecycleService::LifecycleEvent CLIENT_CONNECTED
01:16:03 Nov 27, 2018 10:16:03 PM com.hazelcast.client.impl.protocol.task.AuthenticationMessageTask
01:16:03 INFO: [localhost]:5702 [dev] [3.11] Received auth from Connection[id=15, /<IP_ADDRESS>:5702->/<IP_ADDRESS>:53610, endpoint=null, alive=true, type=CPP_CLIENT], successfully authenticated, principal: ClientPrincipal{uuid='821a43ab-9bce-4779-a79c-a9ecaf72f068', ownerUuid='c4ed08f2-a0af-4161-a004-b147697893ff'}, owner connection: false, client version: 3.10.2-SNAPSHOT
01:16:03 27/11/2018 22:16:03.757 INFO: [0xe65feb40] hz.client_294[dev] [3.10.2-SNAPSHOT] Authenticated with server Address[localhost:5702], server version:3.11 Local address: Address[<IP_ADDRESS>:53610]
01:16:04 /home/jenkins/jenkins/workspace/cpp-centos7-nightly-32-SHARED-Release/hazelcast/test/src/replicatedmap/nearcache/BasicClientReplicatedMapNearCacheTest.cpp:153: Failure
01:16:04 Value of: actual
01:16:04   Actual: 1
01:16:04 Expected: expected
01:16:04 Which is: 2
01:16:04 Near Cache hits should be 2, but were 0 (NearCacheStatsImpl{ownedEntryCount=500, ownedEntryMemoryCost=1000, creationTime=1543356963756, hits=1, misses=1002, ratio=0.1, evictions=0, expirations=0, invalidations=2, invalidationRequests=0, lastPersistenceTime=0, persistenceCount=0, lastPersistenceDuration=0, lastPersistenceWrittenBytes=0, lastPersistenceKeyCount=0, lastPersistenceFailure=''})
01:16:04 /home/jenkins/jenkins/workspace/cpp-centos7-nightly-32-SHARED-Release/hazelcast/test/src/replicatedmap/nearcache/BasicClientReplicatedMapNearCacheTest.cpp:153: Failure
01:16:04 Value of: actual
01:16:04   Actual: 1002
01:16:04 Expected: expected
01:16:04 Which is: 1001
01:16:04 Near Cache misses should be 1001, but were 0 (NearCacheStatsImpl{ownedEntryCount=500, ownedEntryMemoryCost=1000, creationTime=1543356963756, hits=1, misses=1002, ratio=0.1, evictions=0, expirations=0, invalidations=2, invalidationRequests=0, lastPersistenceTime=0, persistenceCount=0, lastPersistenceDuration=0, lastPersistenceWrittenBytes=0, lastPersistenceKeyCount=0, lastPersistenceFailure=''})
01:16:04 27/11/2018 22:16:03.982 INFO: [0xf69d17c0] hz.client_293[dev] [3.10.2-SNAPSHOT] LifecycleService::LifecycleEvent SHUTTING_DOWN
01:16:04 27/11/2018 22:16:03.982 INFO: [0xf69d17c0] hz.client_293[dev] [3.10.2-SNAPSHOT] Removed connection to endpoint: Address[localhost:5701], connection: ClientConnection{alive=0, connectionId=1, remoteEndpoint=Address[localhost:5701], lastReadTime=2018-11-27 22:16:03.981000, closedTime=2018-11-27 22:16:03.982000, connected server version=3.11}
01:16:04 27/11/2018 22:16:03.982 INFO: [0xf69d17c0] hz.client_293[dev] [3.10.2-SNAPSHOT] Removed connection to endpoint: Address[localhost:5702], connection: ClientConnection{alive=0, connectionId=2, remoteEndpoint=Address[localhost:5702], lastReadTime=2018-11-27 22:16:00.552000, closedTime=2018-11-27 22:16:03.982000, connected server version=3.11}
01:16:04 Nov 27, 2018 10:16:04 PM com.hazelcast.nio.tcp.TcpIpConnection
01:16:04 INFO: [localhost]:5701 [dev] [3.11] Connection[id=14, /<IP_ADDRESS>:5701->/<IP_ADDRESS>:42642, endpoint=[<IP_ADDRESS>]:42642, alive=false, type=CPP_CLIENT] closed. Reason: Connection closed by the other side
01:16:04 java.io.EOFException: Remote socket closed!
01:16:04 	at com.hazelcast.internal.networking.nio.NioInboundPipeline.process(NioInboundPipeline.java:116)
01:16:04 	at com.hazelcast.internal.networking.nio.NioThread.processSelectionKey(NioThread.java:368)
01:16:04 	at com.hazelcast.internal.networking.nio.NioThread.processSelectionKeys(NioThread.java:353)
01:16:04 	at com.hazelcast.internal.networking.nio.NioThread.selectLoop(NioThread.java:279)
01:16:04 	at com.hazelcast.internal.networking.nio.NioThread.run(NioThread.java:234)
01:16:04
01:16:04 Nov 27, 2018 10:16:04 PM com.hazelcast.client.impl.ClientEndpointManager
01:16:04 INFO: [localhost]:5701 [dev] [3.11] Destroying ClientEndpoint{connection=Connection[id=14, /<IP_ADDRESS>:5701->/<IP_ADDRESS>:42642, endpoint=[<IP_ADDRESS>]:42642, alive=false, type=CPP_CLIENT], principal='ClientPrincipal{uuid='dcd04d22-7776-4c9e-8837-b9cff06f8202', ownerUuid='c4ed08f2-a0af-4161-a004-b147697893ff'}, ownerConnection=true, authenticated=true, clientVersion=3.10.2-SNAPSHOT, creationTime=1543356960196, latest statistics=null}
01:16:04 Nov 27, 2018 10:16:04 PM com.hazelcast.nio.tcp.TcpIpConnection
01:16:04 INFO: [localhost]:5702 [dev] [3.11] Connection[id=14, /<IP_ADDRESS>:5702->/<IP_ADDRESS>:53582, endpoint=[<IP_ADDRESS>]:53582, alive=false, type=CPP_CLIENT] closed. Reason: Connection closed by the other side
01:16:04 java.io.EOFException: Remote socket closed!
01:16:04 	at com.hazelcast.internal.networking.nio.NioInboundPipeline.process(NioInboundPipeline.java:116)
01:16:04 	at com.hazelcast.internal.networking.nio.NioThread.processSelectionKey(NioThread.java:368)
01:16:04 	at com.hazelcast.internal.networking.nio.NioThread.processSelectionKeys(NioThread.java:353)
01:16:04 	at com.hazelcast.internal.networking.nio.NioThread.selectLoop(NioThread.java:279)
01:16:04 	at com.hazelcast.internal.networking.nio.NioThread.run(NioThread.java:234)
01:16:04
01:16:04 Nov 27, 2018 10:16:04 PM com.hazelcast.client.impl.ClientEndpointManager
01:16:04 INFO: [localhost]:5702 [dev] [3.11] Destroying ClientEndpoint{connection=Connection[id=14, /<IP_ADDRESS>:5702->/<IP_ADDRESS>:53582, endpoint=[<IP_ADDRESS>]:53582, alive=false, type=CPP_CLIENT], principal='ClientPrincipal{uuid='dcd04d22-7776-4c9e-8837-b9cff06f8202', ownerUuid='c4ed08f2-a0af-4161-a004-b147697893ff'}, ownerConnection=false, authenticated=true, clientVersion=3.10.2-SNAPSHOT, creationTime=1543356960398, latest statistics=null}
01:16:05 27/11/2018 22:16:05.584 INFO: [0xf69d17c0] hz.client_293[dev] [3.10.2-SNAPSHOT] LifecycleService::LifecycleEvent SHUTDOWN
01:16:05 27/11/2018 22:16:05.585 INFO: [0xf69d17c0] hz.client_294[dev] [3.10.2-SNAPSHOT] LifecycleService::LifecycleEvent SHUTTING_DOWN
01:16:05 27/11/2018 22:16:05.585 INFO: [0xf69d17c0] hz.client_294[dev] [3.10.2-SNAPSHOT] Removed connection to endpoint: Address[localhost:5701], connection: ClientConnection{alive=0, connectionId=1, remoteEndpoint=Address[localhost:5701], lastReadTime=2018-11-27 22:16:03.981000, closedTime=2018-11-27 22:16:05.585000, connected server version=3.11}
01:16:05 27/11/2018 22:16:05.585 INFO: [0xf69d17c0] hz.client_294[dev] [3.10.2-SNAPSHOT] Removed connection to endpoint: Address[localhost:5702], connection: ClientConnection{alive=0, connectionId=2, remoteEndpoint=Address[localhost:5702], lastReadTime=2018-11-27 22:16:03.978000, closedTime=2018-11-27 22:16:05.585000, connected server version=3.11}
01:16:05 Nov 27, 2018 10:16:05 PM com.hazelcast.nio.tcp.TcpIpConnection
01:16:05 INFO: [localhost]:5701 [dev] [3.11] Connection[id=15, /<IP_ADDRESS>:5701->/<IP_ADDRESS>:42674, endpoint=[<IP_ADDRESS>]:42674, alive=false, type=CPP_CLIENT] closed. Reason: Connection closed by the other side
01:16:05 java.io.EOFException: Remote socket closed!
01:16:05 	at com.hazelcast.internal.networking.nio.NioInboundPipeline.process(NioInboundPipeline.java:116)
01:16:05 	at com.hazelcast.internal.networking.nio.NioThread.processSelectionKey(NioThread.java:368)
01:16:05 	at com.hazelcast.internal.networking.nio.NioThread.processSelectionKeys(NioThread.java:353)
01:16:05 	at com.hazelcast.internal.networking.nio.NioThread.selectLoop(NioThread.java:279)
01:16:05 	at com.hazelcast.internal.networking.nio.NioThread.run(NioThread.java:234)
01:16:05
01:16:05 Nov 27, 2018 10:16:05 PM com.hazelcast.client.impl.ClientEndpointManager
01:16:05 INFO: [localhost]:5701 [dev] [3.11] Destroying ClientEndpoint{connection=Connection[id=15, /<IP_ADDRESS>:5701->/<IP_ADDRESS>:42674, endpoint=[<IP_ADDRESS>]:42674, alive=false, type=CPP_CLIENT], principal='ClientPrincipal{uuid='821a43ab-9bce-4779-a79c-a9ecaf72f068', ownerUuid='c4ed08f2-a0af-4161-a004-b147697893ff'}, ownerConnection=true, authenticated=true, clientVersion=3.10.2-SNAPSHOT, creationTime=1543356963555, latest statistics=null}
01:16:05 Nov 27, 2018 10:16:05 PM com.hazelcast.nio.tcp.TcpIpConnection
01:16:05 INFO: [localhost]:5702 [dev] [3.11] Connection[id=15, /<IP_ADDRESS>:5702->/<IP_ADDRESS>:53610, endpoint=[<IP_ADDRESS>]:53610, alive=false, type=CPP_CLIENT] closed. Reason: Connection closed by the other side
01:16:05 java.io.EOFException: Remote socket closed!
01:16:05 	at com.hazelcast.internal.networking.nio.NioInboundPipeline.process(NioInboundPipeline.java:116)
01:16:05 	at com.hazelcast.internal.networking.nio.NioThread.processSelectionKey(NioThread.java:368)
01:16:05 	at com.hazelcast.internal.networking.nio.NioThread.processSelectionKeys(NioThread.java:353)
01:16:05 	at com.hazelcast.internal.networking.nio.NioThread.selectLoop(NioThread.java:279)
01:16:05 	at com.hazelcast.internal.networking.nio.NioThread.run(NioThread.java:234)
01:16:05
01:16:05 Nov 27, 2018 10:16:05 PM com.hazelcast.client.impl.ClientEndpointManager
01:16:05 INFO: [localhost]:5702 [dev] [3.11] Destroying ClientEndpoint{connection=Connection[id=15, /<IP_ADDRESS>:5702->/<IP_ADDRESS>:53610, endpoint=[<IP_ADDRESS>]:53610, alive=false, type=CPP_CLIENT], principal='ClientPrincipal{uuid='821a43ab-9bce-4779-a79c-a9ecaf72f068', ownerUuid='c4ed08f2-a0af-4161-a004-b147697893ff'}, ownerConnection=false, authenticated=true, clientVersion=3.10.2-SNAPSHOT, creationTime=1543356963757, latest statistics=null}
01:16:07 27/11/2018 22:16:07.188 INFO: [0xf69d17c0] hz.client_294[dev] [3.10.2-SNAPSHOT] LifecycleService::LifecycleEvent SHUTDOWN
01:16:07 [  FAILED  ] ClientNearCacheTest/BasicClientReplicatedMapNearCacheTest.whenCacheIsFull_thenPutOnSameKeyShouldUpdateValue_withUpdateOnNearCacheAdapter/0, where GetParam() = 0 (6994 ms)

Closing after PR https://github.com/hazelcast/hazelcast-cpp-client/pull/482  Will reopen if the test fails again.


Sound and picture out of sync

Bug report
Your Environment

Netflix add-on version: v1.18.4+matrix.1
Operating system version/name: Open Source Media Center 2021.12-1, Kodi 19.3
Device model:  Vero 4K+

Used Operating system:

[ ] Android
[ ] iOS
[ ] Linux
[ ] OSX
[x] Raspberry-Pi
[ ] Windows

Describe the bug

About a week ago Netflix plugin on Vero 4K+ started to behave odd, sound was quicker than video.
Expected behavior

Play sound and picture in sync.
Actual behavior

Steps to reproduce the behavior

Start Kodi
Play anything on Netflix

Possible fix

According to discussion the problem is new Widevine and http2 protocol. I disabled http2 and problem is gone.
Other users use older version of Widevine with better luck.
< network >
< disablehttp2 > true < /disablehttp2 >
< /network >
Debug log

The debug log can be found here:

My log is here https://paste.osmc.tv/yemajicile
2022-02-25 12:58:58.893 T:2714     INFO : Log level changed to "TRACE"
But there`s nothing there
Additional context or screenshots (if appropriate)
Other information

Screenshots

disable http2 it is not a good thing to do and netflix servers works with http2, the regular http its only a fallback nowadays
it is know that last versions of widevine have problems on ARM devices
the last stable version seems to be 4.10.2252.0
you can read on #1321 to have some help to revert back
but this is nothing that this addon can solve

Widevine 4.10.2252 works fine. Thanks

I'm getting the same issue on Raspberry Pi but no problem at desktop 😅

Same problem here on raspberry Pi with LibreELEC. Was working fine until a week ago.


Whether the converted value field cannot be ignored

I use the `cmp.Transformer `method to perform special processing on some values, but I find that the fields under this type cannot be ignored after transformation? How can I use it to make it effective?

@dsnet Could you help me look at this problem?


Remove non-project-related items from gitignore

IDE-specific and OS-specific files should be in global gitignores.
The project gitignore should be for files created by the project.
See discussion on https://github.com/mattermost/mattermost-plugin-starter-template/pull/98

Thanks for the PR! I'm not sure about removing these files from the .gitignore since I don't think we can expect everyone to have their global .gitignore set up correctly. I worry that will cause us to have people accidentally committing those files when they don't have their ignore set up and they git add . on their entire repository without paying attention.
I'll queue this up for our weekly developer meeting to discuss since some people on the team think this is the right way to go though. If you're interested in joining, the meeting is open to the public. It's at 8:30 AM PST/11:30 AM EST tomorrow, and you can join in from the ~dev-meeting channel on our community server at https://community.mattermost.com.

Well, I think a gitignore can never substitute for code review in terms of adding unwanted files. Conversely, it's not realistic to cover every kind of editor / IDE / tool / OS-specific temp file in a gitignore in open-source projects IMO.
Anyway, up to you guys - I created the PR here as requested by @hanzei. :)

Closing this following developer decision to keep project-specific files in .gitignore.

Thanks again for the PR! Sorry that there was a bit of a communication breakdown there getting the information back to you, so thanks for following up as well.


[4.0.beta9] "INSTALL_PARSE_FAILED_NO_CERTIFICATES" error when stream-installing APKs on Android with standard build

Godot version
4.0.beta9
System information
Windows 10
Issue description
When I perform stream-install (direct deploy on debug-usb Android device) I get this error:
Installing to device (please wait...): Samsung SM-G935F
  editor/export/editor_export_platform.h:164 - Run: Could not install to device: adb: failed to install C:/Users/andre/AppData/Local/Godot/tmpexport.1671531696.apk: Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES: Failed to collect certificates from /data/app/vmdl579386029.tmp/base.apk: Attempt to get length of null array]
  Performing Streamed Install

Apparently fixed when ticking Use custom build in the export menu, but it wasn't necessary in Godot 3.5.1 (same project).
This issue was already present in beta6, 7 and 8.
Steps to reproduce

Create a blank project with a basic scene
Install Android templates from the Project menu
Create an Android build from Project > Export (don't set anything)
Connect your debug-enabled Android device
Click on the Android icon in the upper-right corner of the editor

Minimal reproduction project
Not necessary

i think now it's called "gradle build"

Duplicate of https://github.com/godotengine/godot/issues/58192, should be resolved by https://github.com/godotengine/godot/pull/67668


rework arguments passed to events

I want to transform some properties of objects you receive from the server like session_id to have a different name instead (sessionID in this case).
This is something for v2.

The way I'm doing this currently is writing functions that transform the data (located in transforms.ts).
Current progress:

[x] User
[x] Message
[ ] NickChangeInfo
[ ] SysMessage
[ ] TagAdd?


Add missing move events

Address: #151

@pedrokohler I had to run lint, please review and merge.

@igoroctaviano I am not authorized to merge the PR.


Action pack variants not working as expected.

The variant is not being rendered when using action pack variants for mobile layouts.
Spree::BaseController.class_eval do
  before_action :detect_browser

    def detect_browser
      case request.user_agent
        when /iPad/i
          request.variant = :tablet
        when /iPhone/i
          request.variant = :phone
        when /Android/i && /mobile/i
          request.variant = :phone
        when /Android/i
          request.variant = :tablet
        when /Windows Phone/i
          request.variant = :phone
        else
          request.variant = :desktop
      end
    end
end

Is there something I am missing?  It seems to work for the homepage, but other pages it tosses the variant out and uses the standard template file.

Please close, user error. For anyone who is facing the same issue make sure that in the admin section of Spree that you are not setting the direct path ie: spree/home/index

.html.erb

Otherwise the render function will only look for that file and not care about your variants.


Settings: Add User-Interactive Auth for adding email and msidsn to user's account

fixes vector-im/riot-ios#2744
requires https://github.com/matrix-org/matrix-ios-sdk/pull/737

In case of not supported authentication:

New "Not supported" modal:


--exclude/--exclude-pattern can't be used at the same time as --include

When passing --include, all --exclude/--exclude-pattern parameters are ignored and file matching only considers if a file is in any of the include paths or not.
The following seems like a pretty valid usecase that would be nice if it was supported:
coveralls --include src --exclude src/not-this-file.c --exclude-pattern '.*useless.*'

@dsvensson Thanks for reporting this.
This bug should be fixed in e9dceb8829dc8bf5bbb05313a4be24a7e9485523.

I see that I was vague in my bug report. The committed fix is inclusive.
The following:
--include src/foo
--include src/bar
--exclude-pattern '.*useless.*'
--exclude src/foo/hey.c

Will happily include 'src/baz/*' files as well, while I see the parameters as all constraining:
intersection(
    intersection($universe,
        union(match(src/foo), match(src/bar))
    ),
    complement(
        union(match(.*useless.*), match(src/foo/hey.c))
    )
)

Which would match files in src/foo, and src/bar, and from that match, prune everything that matches .useless. and src/foo/hey.c.


Indestructible walls are not actually indestructible

It's possible to chip away walls by firing large amounts of fireworks at them.
Demo setup: https://i.imgur.com/um8XZ5S.png
A cloner wrapped in dust with a small ignition fire besides it at the bottom and another cloner with fireworks wrapped around it at the top.
The bottom cloner creates an infinite fire, and shoots the firework particles into the wall above. These fireworks somehow destroy parts of the "indestructible" wall, until they made their way through it.
The setup in action: https://gfycat.com/EnchantedShowyLacewing
I'm guessing this is not intended, but a fun effect nonetheless.

cool find! I'm going to keep this open for now but not high priority to fix because I kind of like it

not going to fix this, I think it's good


Nonintuitive default value for 'packageFile'

The default value for the 'packageFile' parameter is in my opinion nonintuitive, especially when using the custom packaging type ('liberty-assembly'). I would have expected a file ${project.build.directory}/${project.build.finalName}.zip.
Also, when not using the custom packaging type I would argue that creating the assembly file (the zip) within the folder structure that is being packaged could create issues. Especially if the execution is run a second time as it could then include the assembly from the first execution.

This has been delivered to the 2.0-SNAPSHOT release


Source code not available (yet ;))

See https://github.com/timb-machine/nhsx-contact-tracing-app/blob/4ebf6d97b7d53a37c75700a6058216e5869a0508/advocacy/hmg-briefing/ncsc/NHS-app-security-paper V0.1.pdf, page 2.

bing https://github.com/nhsx/COVID-19-app-Android-BETA

See https://github.com/timb-machine/nhsx-contact-tracing-app/blob/7c04e5edac7f696e728dba3d782f48a8f3dcaa9d/advocacy/nhsx-briefing/1258453749691027465. Code and documentation added as submodules.


Fix GDScript parser sometimes crashing when issuing warning for unreachable pattern

Fix parser crashing when trying to issue a warning for an "unreachable pattern" of a match branch with no pattern (this can happen when the pattern has a parse error).
Fixes #62409

This seems to prevent the specific issue (and probably good to merge). But the underlying cause of the issue is a bit horrifying. The parser is very greedy when parsing match statements. When the repro instructions in the issue are followed, the parser tries to parse line 140 (var category := ...) (which is supposed to be outside the outer match) as a bind pattern for the outer match, which is why has_wildcard_without_continue is true, and the crash happens when trying to parse some other line below as yet another branch...
How to even fix this? All the DEDENTs get consumed by the failed multi-line parse_expression, so there's no way for parse_match to know about them...

Isn't this more so hiding the problem then specifically correcting? Are we sure this problem won't crop up in other places?

Isn't this more so hiding the underlying reason for problem then specifically correcting it? Are we sure this issue won't crop up in other places?

Well, I believe there are actually two issues:

The one that this PR solves, which can be easily reproduced with this code:

var test = "hello"
match test:
	_: # have_wildcard_without_continue will be true for next branch
		print("Anything")
	: # No pattern for this branch

The underlying "greedy parser" problem, for which the crash is fixed by this PR (at least in the two linked cases, but maybe in some cases there are other crashes), but which is not really solved here

The underlying "greedy parser" problem

Yeah and that's what I was thinking, I don't know about any of the maintainers, but I'd personally feel safer to at least note down this greedy parser problem in another issue as well, unless it already is noted down but I can't seem to find anything about that. This is a horrifying issue as cdemirer said and it means that there might be other places where this can crop up when semantically it makes no sense.

I think the "greedy parser" may not be that much of a problem.

The parser should never crash for any input.
When the parser skips some chunk of tokens as a result of a Parser Error, the calling function "sees" a different source code than what the user intended. It still shouldn't crash, since the user could technically have written that code in the first place.
The most (2) can cause is many (meaningless) errors being generated like a chain reaction. Running unexpected script logic is not a problem because it won't compile/run until all errors are dealt with anyway.
The positive side is that it helps find "defects" in the parser by triggering crashes, as in this case. As @MinusKube's repro shows, the crash could be triggered even with "valid" code.

(3) is where the "continue parsing anyway" approach has a trade-off. In most cases, it helps notifying the user of multiple "actual" mistakes in the code at once, instead of finding and showing them one-by-one.

Something to be fair about, its fine for the parser to be greedy in places where it makes sense, my concern is mostly where the parser shouldn't be greedy in places it doesn't like mistaking a statement for an expression, or in the example above trying to parse an empty pattern as though it were valid, in this specific case it should be entirely capable for the parser to recognize that the semantics are wrong without crashing and try to move outside the section perhaps, especially when the crash is only incidental thanks to a warning, even in failing later this is a problem because the root of issue is still rather hidden. The standard should be to fail early and to fail predictably, preferably as said in a manner that doesn't crash the system, in which case the parser could perhaps skip over the unknowns until the point it knows something that could be valid. If we crash early, it won't in the least take any debugger forensics to figure out the exact reason for the problem.

Crashing should never happen and in many cases the solution is really checking for empty stuff before accessing. I've been thinking of ways to mitigate this, such as having empty nodes instead of nullptr for instance. But this as discussion for elsewhere.
Regarding the parser being "greedy", that's not much of an issue because it's only problematic when the script is invalid. The idea is that it needs to keep going so it can catch more errors instead of first reporting the first error it found. It might cascade into nonsensical errors, but that's less of a concern. I'm not saying it's perfect, but it's a system that can be improved, it doesn't need to be removed.
Feel free to open a discussion about this subject if any of you want to.

Thanks!


add toggle-small-left icon

ReferenceError: primordials is not defined is that just because I'm on a branch or something I need to look into before I can merge?

It could be because you're on a fork, but it's failing in the Sass step so I doubt it... you don't get this locally?

Sounds good re new icon for wcag 2.1.
Regarding the error, I think using node 11 (such as here https://github.com/BrightspaceUI/icons/blob/wcag21/.travis.yml#L2) will get you past this.