Manifest file

Our current code signs / serializes folders using a custom hash built using sha256. It works well but has 3 disadvantages:

We need to update rekor hash support (very small change for rekord zo)
AI frameworks that need to verify a subset of files (e.g., a tf file in a hugging face repo) won't be able to take advantage of existing signatures.
When small files change, it's expensive to re-hash the entire model https://github.com/google/model-transparency/issues/83

A workaround is to create and sign a dedicated "manifest" file that lists all files within a directory with their corresponding hash (similar to SHA256SM output), rather than the output of the folder serialization. With our current code, however, this creates 2 files: the manifest and a signature (on the manifest), which is bad UX-wise, especially for single-file models.
What we want is a single file. I think a solution to this problem is to use DSEE envelope (supported by Sigstore and widely used by tools like cosign). DSSE lets us define a payload which is stored in the envelope, along the signature. This payload is the content of our manifest. We can use intoto / json as a format since it's widely adopted.
sigstore-python added support for signing intoto statements in their main branch (yet to be released), so I think we can use that. All we need is define our own predicate and its format, something like:
{
   "_type": "https://in-toto.io/Statement/v1",
   "predicateType": "https://github.com/openssf/model-signing/manifest/v1"
   "predicate": []{
       {
           "path": "path/to/file1",
            "digest": {
               "sha256-p1": "...",
            }
           "bla": "...",
       },
       {
           "path": "path/to/file2",
            "digest": {
               "sha256-p1": "...",
            }
       }
   }
}

I've tested the signing part and it works. Next we need verification, blocked on https://github.com/sigstore/sigstore-python/issues/628

note to myself. https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md Set of software artifacts that the attestation applies to. Each element represents a single software artifact. Each element MUST have digest set.
We'll need to use a dummy value for subject, since the model is the artifact. Note that we cannot list each file in the subject header because 1) the hash is unknown to rekor and 2) the files MUST be an exact match

Btw regarding your question in #83 :

If users version their models, they'd only need to sign when the model actually changes.. which means they need to re-sign large files and cannot use the per-file hash anyway... Wdut?

We can get a blob id from git which is basically a SHA1 that lets you know if the file has changed in a given revision. We also have a git diff endpoint to check changes between two revisions. Not sure we'd need an extra tool to create tags as all our endpoints should be accessible and usable with https://github.com/huggingface/huggingface_hub

Also cc @graniet

a git hook
Do you mean a pre-commit hook? I'm not sure people will have their git repos checked out, afaik people upload files via huggingface_hub which abstracts the whole git logic by creating commits via our REST API.

I guess we could think of integrating directly in huggingface_hub, cc @wauplin for visibility

Integrating with huggingface_hub seems right a strong approach to me

Right that's definitely something that could work (and I'm happy to discuss it more if anyone is interested).
However!  After reading the initial description of this issue I'm pretty sure this can be accomplished with the existing in-toto statement type.

AI frameworks that need to verify a subset of files (e.g., a tf file in a hugging face repo) won't be able to take advantage of existing signatures.

I think this can be supported easily and without any changes using the 'name' field as described here.
AI model verifiers would check that the filename that changed matches the name field and corresponding digests in the attestation and could ignore the subjects that don't apply.  In this way I don't think you'd need a separate manifest (but perhaps I'm missing something).
Either way, I think this is definitely a use case that https://github.com/in-toto/attestation wants to support, so if it's missing anything let's chat about it?  CC @marcelamelara, @pxp928, @mikhailswift.

I think @SantiagoTorres was also suggesting to use in-toto

AI frameworks that need to verify a subset of files (e.g., a tf file in a hugging face repo) won't be able to take advantage of existing signatures.

I think this can be supported easily and without any changes using the 'name' field as described here.

nope, that does not work. If you do that each file will be represented as an individual artifact. We don't want arbitrary tools to miss verifying some of the files. The way it needs to be interpreted for verification (for this specific case) is that the caller needs to give us a list of files that may be present. Say, PyTorch has config files, a list of model_*.bin, etc. The caller must give us this list, otherwise an attacker can remove files. Imagine if the config file is removed and it says to run the pickle.Unload() in a sandbox: an attacker would bypass signature verification entirely.
So we should not list artifacts in the subject, because the verification does not match the semantics of intoto attestation, ie that each subject is an independent artifact. That will lead to vulnerabilities so we should avoid that.

@TomHennen mentioned we could put the manifest content in the subject's resource descriptor's content field.

Although this technically works, I don't think it's a good approach either. This approach effectively adds an intoto layer that provides no benefits. Instead of being able to access the manifest content as dsse.payload, we need to access it by going thru another layer dsse.subject.content. Adding the intoto layer does not help interoperability either, because the verification logic is entirely dependent on interpreting the manifest content, so existing tools that support intoto won't be able to make sense of the content. At this point, imo it's actually better to use dsse with a non-itoto statement.
One approach that could work is waiving the requirement of having a subject in the intoto attestation based on the predicateType. Would this be possible or would it go against the intoto framework?

This doesn't sound like something that's specific to ML models but could occur in many other SW ecosystems.
I'm not sure I entirely understand the workflow though.  Is there anyplace I can learn more?

This doesn't sound like something that's specific to ML models but could occur in many other SW ecosystems.

I'm not sure. In the sense that we want to support both "full repository signing" (to start with) and "AI framework signing" that require verifying a subset of the files signed for the "full repository signing". An example of this is Huggingface repository, where users sign all files under the repo. The repo often contains the same model in different formats. You can use Keras or PyTorch or another framework to load a model (using a subset of files; once we have integrated verification in these framework APIs) or you verify signature for the entire repo  before loading it.
However, for full repository signing, this is not ML specific, ie anyone who wants to sign a folder will need to verify all the files. What's specific to ML is the size of these files (several 100 GB), so it's kinda specific to ML still in this sense.

Is there anyplace I can find out more about what you're looking for?  Any existing design docs?
It sounds like the idea is "We have a lot of files with different paths and digests. Sometimes we want to check all of them, and sometimes we want to check a subset of them."  Is there more to it than that?

It sounds like the idea is "We have a lot of files with different paths and digests. Sometimes we want to check all of them, and sometimes we want to check a subset of them." Is there more to it than that?

I think that's pretty much all there is to it, with specific use cases I mentioned above. Let me know if you have further questions.

So it sounds like it's totally possible to represent a model in the in-toto Statement 'subject' field.
Is the issue that the in-toto Statement rules are perceived as too restrictive and don't allow for all/subset use case?  If so, can you say more about what that perceived limitation is?  Something in https://github.com/in-toto/attestation/blob/main/docs/validation.md ?

Chatted with Tom right now, and it seems in-toto can be used to model all of our scenarios. I'll do a deeper dig and add a comment with how things could work, at which point we can switch to in-toto, if it turns out there are no other blockers.

So it sounds like it's totally possible to represent a model in the in-toto Statement 'subject' field.

Constraining ourselves to subject fields is not ideal imo. It basically adds technical debt early in the project, because the subject field is not flexible. If we ever want to evolve the format, we need to use annotations for that.
I also want to stress that putting things in subject means that each subject is considered an artifact, and can be verified independently of each other as per the intoto specs. That means other tools following intoto specs (cosign) would verify the attestation in an unsafe way, it they would pass verification if they are given the wrong subset of files to verify. Looking forward to the design.

Jumping into the discussion after following along so far.
@laurentsimon based one your latest comment what you really want to get out of a manifest predicate is to be able to make a claim a long the lines of "this is the expected set of files for model X". Is that a reasonable interpretation of your use case?
If so, could your use case be addressed by something like an existing BOM format? I also know that C2PA has the notion of manifests, is that something you've looked into as a possible predicate? I'm mostly trying to avoid us reinventing the wheel when it comes to developing predicates.
I completely agree that the in-toto Statement subject not designed to represent claims about artifacts. That said, what would the subject for this manifest predicate be? The model as a logical artifact still needs to be identified. What representation of the model would be used, would a reference to the hosting repo of the model files be sufficient?

tools following intoto specs (cosign) would verify the attestation in an unsafe way, ie they would pass verification if they are given the wrong subset of files to verify.

To confirm my understanding here, your concern is that an attacker could omit legitimate files that are needed for a model to operate correctly? Wouldn't a manifest predicate be susceptible to the same problem?

Hi all, dropping by. I spnt a little bit thinking about it before I jumped. My understanding is that this is "manageable" using a combination of ITE-4 + a custom hasher (as per the spec). For example:
"subject": {"name": "inline+aipredicate://", "sha256sum": "whatever"}

Where whatever can be any specified way to "hash" such a predicate. If we wanted to be cute about it, we could use a MHT of the file directory. Even cuter, it could follow the git tree object structure to avoid reinventing the wheel.
I'm not fully sure going through a fully qualified SBOM is a reasonable way to go, given that thy are in quite a flux, and I blieeve here we are trying to focus on `flow integrity rather than down-the-line transparency.

I completely agree that the in-toto Statement subject is not designed to represent claims about artifacts. That said, what would the subject for this manifest predicate be? The model as a logical artifact still needs to be identified. What representation of the model would be used, would a reference to the hosting repo of the model files be sufficient?

I'm not enrirely sure I understand this part, you could certainly have a predicate that says "this was reviewed by a legal team" or "the dataset used is considered un-biased".  Am I missing something here?

@laurentsimon based on your latest comment, what you really want to get out of a manifest predicate is to be able to make a claim a long the lines of "this is the expected set of files for model X". Is that a reasonable interpretation of your use case?

Yes. For the first use case where we sign all files in a huggingface repo, this is correct. We want to treat all files "together".

If so, could your use case be addressed by something like an existing BOM format? I also know that C2PA has the notion of manifests, is that something you've looked into as a possible predicate? I'm mostly trying to avoid us reinventing the wheel when it comes to developing predicates.

We have not. Thanks for the idea. We can explore these for inspiration.

To confirm my understanding here, your concern is that an attacker could omit legitimate files that are needed for a model to operate correctly?

Correct

I completely agree that the in-toto Statement subject is not designed to represent claims about artifacts. That said, what would the subject for this manifest predicate be?

There would be no subject. In effect we don't even need to wrap the manifest into an intoto statement. We'd simply use DSSE with this manifest schema inside. The semantics would be different from the intoto model. The hack I was eluding to in the issue description was to either use an empty subject or a dummy hash value, none of which are particularly appealing :/

The model as a logical artifact still needs to be identified. What representation of the model would be used, would a reference to the hosting repo of the model files be sufficient?

The manifest effectively contains the list of files that comprise the model, so the manifest is the representation of the model.

Wouldn't a manifest predicate be susceptible to the same problem?

It depends how we define the semantics for this manifest schema. If the schema lists all files and the verification semantics say that the exact same files listed in the manifest MUST match for verification to succeed, then we don't have this problem. (Here I'm assuming we don't use intoto at all. If we do use intoto, we still have this problem I think).

Hi all, dropping by. I spnt a little bit thinking about it before I jumped. My understanding is that this is "manageable" using a combination of ITE-4 + a custom hasher (as per the spec). For example:

"subject": {"name": "inline+aipredicate://", "sha256sum": "whatever"}

What would you hash in this case? If we hash the predicate, we have to canonicalize the JSON predicate, which we should avoid.

Where whatever can be any specified way to "hash" such a predicate. If we wanted to be cute about it, we could use a MHT of the file directory. Even cuter, it could follow the git tree object structure to avoid reinventing the wheel.

If we hash the directory to identify the model, why use a manifest that lists the files? We'd end up hashing twice: for the manifest and for the model identification. We're trying to avoid serializing the directory because we want to support fast re-hashing, eg when a README file changes. Serializing the directory is whet the current implementation of this repo does, and we've decided (with feedback from folks at huggingface) that it's not the right approach.

I want to stress that putting things in subject means that each subject is considered an artifact, and can be verified independently of each other as per the intoto specs. That means other tools following intoto specs (cosign) would verify the attestation in an unsafe way, ie they would pass verification if they are given the wrong subset of files to verify. This problem is due to semantic differences, and unless the into specs change it can't be fixed iiuc.

So, I think the root of the semantic problem boils down to "Reject if matchedSubjects is empty" and what you need is more flexibility?
To me it seems like one thing that might be tripping us up is that policy is getting mixed up with how we make statements about things?
Is it correctly to say that,  if we ignore the opinionated validation model, it is possible to express all the files in a model in an in-toto statement and to express the properties of that model in the predicate?
Could this be resolved by relaxing the validation model, and giving verifiers (and policy owners) more freedom to say "all files must be verified and present" (among other things)?

Please use Statement and do not invent some new format here.

I want to stress that putting things in subject means that each subject is considered an artifact, and can be verified independently of each other as per the intoto specs. That means other tools following intoto specs (cosign) would verify the attestation in an unsafe way, ie they would pass verification if they are given the wrong subset of files to verify. This problem is due to semantic differences, and unless the into specs change it can't be fixed iiuc.

This is completely false. You are misreading the specification.

The following pseudocode shows how to verify and extract metadata about a single artifact from a single attestation
TODO: Explain how to process multiple artifacts and/or multiple attestations.

It is unspecified how to verify a collection of artifacts because that will be dependent on each use case. In this particular case, the verifier should simply check all files. It would be crazy to allow a collection of files {A, B, C} if any match. I can't imagine a scenario where that would be acceptable.

It is unspecified how to verify a collection of artifacts because that will be dependent on each use case. In this particular case, the verifier should simply check all files. It would be crazy to allow a collection of files {A, B, C} if any match. I can't imagine a scenario where that would be acceptable.

Here's what the specs say:
there exists at least one (alg, value) in s.digest where:
alg is in acceptableDigestAlgorithms AND
hash(alg, artifactToVerify) == hexDecode(value)

Can you please address the various concerns we highlighted in the previous comments?

Can you enumerate those concerns? The only one I can find is the misconception that we are discussing now.

Here's what the specs say:
there exists at least one (alg, value) in s.digest where:
   - alg is in acceptableDigestAlgorithms AND
   - hash(alg, artifactToVerify) == hexDecode(value)

Right, that is what you do for each artifact. Again, I'll quote:

The following pseudocode shows how to verify and extract metadata about a single artifact from a single attestation

Perhaps you are confused about matchedSubjects being a list rather than a scalar? This is because a single artifact can match multiple subject entries. For example, a single artifact could match both A and B because they list two different hash algorithms:
"subject": [
    {"digest": {"sha256": "abcd1234"}, "name": "A"},
    {"digest": {"sha512": "98765432"}, "name": "B"}
]

or you could have a subject that contains file copies with identical hashes:
"subject": [
    {"digest": {"sha256": "abcd1234"}, "name": "A"},
    {"digest": {"sha256": "abcd1234"}, "name": "copy-of-A"}
]

We should update the spec to avoid this confusion, but to be clear, nothing in the spec says how to verify a collection of artifacts. It's unspecified.

Let's use a concrete example: TensorFlow SavedModel. Suppose the attestation were this:
"subject": [
    {"digest": {"sha256": "aaaa"}, "name": "assets/foo"},
    {"digest": {"sha256": "bbbb"}, "name": "variables/variables.data-00000-of-00002"},
    {"digest": {"sha256": "cccc"}, "name": "variables/variables.data-00001-of-00002"},
    {"digest": {"sha256": "dddd"}, "name": "variables/variables.index"},
    {"digest": {"sha256": "eeee"}, "name": "saved_model.pb"}
]

If you want to use the logic that all of the file must match, with no renames, additions, or deletions, then you'd do something like this:
def verify_all(artifactsToVerify: Struct[name, digest], attestation, *args):
  # Verify that all of the files on disk have a corresponding entry in the subject.
  for a in artifactsToVerify:
    matchedSubjects, ... = verify_single(a.digest, *args)
    if a.name not in [s.name for s in matchedSubjects]:
      error
  # Verify that there are no missing files.
  for s in attestation.statement.subject:
    if s.name not in [a.name for a in artifactsToVerify]:
      error

Now if you want to be less strict, you'd need to figure out what policy you want to apply. Do you allow renames? Added files? Removed files? That's all OK - it's up to the verifier logic.
For example:
aaaa  assets/name-other-than-foo
6666  assets/another-file
bbbb  variables/variables.data-00000-of-00002
cccc  variables/variables.data-00001-of-00002
eeee  saved_model.pb

Note that assets/foo was renamed assets/name-other-than-foo, assets/another-file was added, and variables/variables.index was deleted.

Thanks @MarkLodato . That is the crux of the problem.

We should update the spec to avoid this confusion, but to be clear, nothing in the spec says how to verify a collection of artifacts. It's unspecified.

That would be nice, yes.
What's confusing me is  https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md Set of software artifacts that the attestation applies to. Each element represents a single software artifact.
In our case, each file is not a software artifact. A model artifact is a set of files. Where can I find the definition of an artifact?

Another problem in the previous comments is https://github.com/sigstore/model-transparency/issues/111#issuecomment-2014643774, ie early technical debt / hard to evolve a format if we try to pack information in subjects. This information, given that we consider a mode artifact a collection of files, should really be inside the predicate, imo

Another problem is https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md Set of software artifacts that the attestation applies to. Each element represents a single software artifact.
In our case, each file is not a software artifact. The model artifact is the set of files.

That's just a terminology nitpick. Our definition of "artifact" is "an immutable blob of data". You could represent an ML model as either a collection of artifacts (one per file) or as a single artifact (one hash over all the files). Either way works.

Another problem in the previous comments is #111 (comment), ie early technical debt / hard to evolve a format if we try to pack information in subjects. This information, given that we consider a model the artiact, should really be inside the predicate, imo. Otherwise we need to split "global" info in predicate and file info in the subjects.

What specifically do you want to put in there?

Another problem is https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md Set of software artifacts that the attestation applies to. Each element represents a single software artifact.
In our case, each file is not a software artifact. The model artifact is the set of files.

That's just a terminology nitpick. Our definition of "artifact" is "an immutable blob of data". You could represent an ML model as either a collection of artifacts (one per file) or as a single artifact (one hash over all the files). Either way works.

If that works it's fine. I would encourage updating the terminology, because I did not see this defined. All the use cases I've seen in intoto involve the subject being an independent artifact.
Other intoto maintainers on the thread, can you confirm that the predicateType dictates how to verify the subject list?

Another problem in the previous comments is #111 (comment), ie early technical debt / hard to evolve a format if we try to pack information in subjects. This information, given that we consider a model the artiact, should really be inside the predicate, imo. Otherwise we need to split "global" info in predicate and file info in the subjects.

What specifically do you want to put in there?

You can't know the unknown, and we have to plan for it. But to give an example, we don't really need the intoto Statement to make things work. We don't need an additional intoto wrap / level of indirection. Instead, we can use:
DSSE:
{
  "payload": "...",
  "payloadType": "model/signing",
  "signatures": [...]
}

And manifest:
{
 // Some global fields
 "version": x,
 "some-other-property":
 // Some files fields
 // the files in this model.
 "files": [
    {
      "path":
      // Any field we want, no tied to the ResourceDescriptor
      "whatever_we_want":
    }
  ]
}

That's the simple alternative to using an intoto statement for our specific use case. That's the solution other ecosystems use (Java, npm). What properties do we gain from intoto compared to the flexibility this example gives us?
Again, I'm not again using intoto (I created this issue in the first place mentioning it!). We're only trying to gather pros and cons for each approach to help in the final decision.
One argument in favor of intoto for this use case is that it may simplify upgrading tooling to support SLSA provenance (since provenance uses intoto format).

Other intoto maintainers on the thread, can you confirm that the predicateType dictates how to verify the subject list?

I'm not sure it's even up to the predicateType?  We have existing use cases where it's the user (or the tooling they're using) that would know best what to do.  E.g. it might be a matter of policy.

There is another reason why we tried to stay away from using the subject field of intoto (which I had forgotten). The hash used to hash is not one of the standard, and adding a new hash to Sigstore / rekor is some work. We don't want to have to bug Sigstore every time someone might want their own hash, or when they tweak one of the parameters of the hash (e.g., the shard size). That was a strong motivation in favor of the manifest

What are the advantages of using intoto in this use case?

So that you don't have to roll your own format and tooling. It's the advantage of any standard. Since there are no extra fields that you anticipate needing, and there is a way to add them should you ever need them, I strongly recommend using the in-toto Statement here. It does everything you need.

What are the advantages of using intoto in this use case?

So that you don't have to roll your own format and tooling. It's the advantage of any standard. Since there are no extra fields that you anticipate needing, and there is a way to add them should you ever need them, I strongly recommend using the in-toto Statement here. It does everything you need.

The problem is that there is no tooling that supports what we're trying to achieve. In fact tooling out there won't understand our predicate and will probably screw up verification.

Our definition of "artifact" is "an immutable blob of data". You could represent an ML model as either a collection of artifacts (one per file) or as a single artifact (one hash over all the files). Either way works.

Seconded. The in-toto attestation spec does not dictate that the subject artifact(s) MUST be executable code. It's meant to be quite generic and apply to any immutable blob of data (e.g., files, binaries, packages, even other attestations).

Perhaps you are confused about matchedSubjects being a list rather than a scalar? This is because a single artifact can match multiple subject entries. We should update the spec to avoid this confusion.

We'd definitely like to edit the spec to address the concerns here. So we're clear on what to change: Are you looking for more explicit language on validation based on subject artifacts, more clarity around the subject field in a Statement? Both?

That's just a terminology nitpick.

I'm not sure it is. Take the example of SLSA provenance. If users were to set subject entry per model file, how would an end-user know they need to verify all of them? The description of the verification only says that statement’s subject matches the digest of the artifact in question. There seems to be an implicit assumption that an artifact is "self-contained". Do you envisage creating different predicates for SLSA provenance?

We'd definitely like to edit the spec to address the concerns here. So we're clear on what to change: Are you looking for more explicit language on validation based on subject artifacts, more clarity around the subject field in a Statement? Both?

I suppose giving concrete examples for different use cases, in particular the one that requires all subjects to match. How about taking moving this discussion to a tracking issue on intoto repo?

That's just a terminology nitpick.

I'm not sure it is. Take the example of SLSA provenance. If users were to set subject entry per model file, how would an end-user know they need to verify all of them? The description of the verification only says that statement’s subject matches the digest of the artifact in question. There seems to be an implicit assumption that an artifact is "self-contained". Do you envisage creating different predicates for SLSA provenance?

To give a concrete example. Say we have recipients RSet and ROneOf. RSet needs to verify a set of files. ROneOf only has a use case with single-file artifacts. An attacker gives ROneOf a file with a provenance intended for RSet. ROneOf accepts it, because it's unaware that verification requires set verification. I think that's an attack we want to protect against, correct?

We'd definitely like to edit the spec to address the concerns here. So we're clear on what to change: Are you looking for more explicit language on validation based on subject artifacts, more clarity around the subject field in a Statement? Both?

I suppose giving concrete examples for different use cases, in particular the one that requires all subjects to match. Is it dictated by the predicate type (my question) or the policy (the verification mentions a "policy engine" and @TomHennen also mentioned that)? Could you give an example for SLSA as an example? Maybe also provide some real code would help too. How about taking this discussion to a tracking issue on intoto repo?
Note: I've not looked at whether existing tooling like cosign outputs matchedSubjects or the entire intoto statement as-is.

To add context. The manifest we created in this issue can be signed and added to a Sigstore bundle using messageSignature. This works just fine. There is a UX drawback zo: we need 2 files: the manifest and the signature. For single-file models, we decided that was not acceptable. So what we're after is a way to attach the signature to the manifest in a single file, and that's exactly what DSSE gives us.

Have we made a final decision on the format of this manifest file? It appears we're settling on a DSSE envelope consisting of intoto statements. However, I've also seen reference to leveraging the sigstore-python signing APIs, which in the case of sign_dsse() returns a Sigstore Bundle that contains the cert, DSSE envelop content, and the HashedRekor entry data. That seems to suggest that the Sigstore Bundle would be the content of the manifest file i.e. the way it currently works in this repo right now where model.sig contains the Sigstore Bundle.

We agreed on using sigstore bundle as the "wire format". The "manifest" refers to the DSSE payload, which is inside the sigstore bundle.


Return BigDecimal values with better math contexts.

This is a port of #584. On that PR, Tom said:

Since we weren't explicitly setting the MathContext, it was using
the default. However, by default, BigDecimal won't round the input,
so it looked OK. However, any operations performed with this number
as the receiver of the method would've truncated the
result. Probably unexpectedly. Ugh... Scala's BigDecimal is such a
mess.

This replaces https://github.com/non/spire/pull/584.

Codecov Report

Merging #698 into master will increase coverage by 0.17%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #698      +/-   ##
==========================================
+ Coverage   49.18%   49.36%   +0.17%
==========================================
  Files         175      175
  Lines       11252    11252
  Branches     1546     1582      +36
==========================================
+ Hits         5534     5554      +20
+ Misses       5718     5698      -20

Impacted Files
Coverage Δ

core/src/main/scala/spire/math/Algebraic.scala
67.96% <100%> (+1.64%)
:arrow_up:

...ore/src/main/scala/spire/math/interval/Bound.scala
50.39% <0%> (-6.3%)
:arrow_down:

core/src/main/scala/spire/math/Rational.scala
96.28% <0%> (+0.24%)
:arrow_up:

extras/src/main/scala/spire/math/FixedPoint.scala
35.51% <0%> (+0.54%)
:arrow_up:

core/src/main/scala/spire/math/Natural.scala
58.46% <0%> (+0.92%)
:arrow_up:

core/src/main/scala/spire/math/Interval.scala
70.3% <0%> (+2.53%)
:arrow_up:

...ala/spire/math/poly/BigDecimalRootRefinement.scala
86.09% <0%> (+3.31%)
:arrow_up:

Continue to review full report at Codecov.

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

LGTM


Fetches greeting from /data url

Try to merge master into your pr:

git checkout master, git pull, to update your master to make sure the remote changes in github are now locally copied over to your local master branch
git checkout fetch, git merge master to merge master into your branch
pit push, to push the fresh state up to your remote repo on Github( so this pr now will only contains itself commits without other pr's commits, that is good to review now)

i ran the commands without changing anything in the files, and the terminal says: Everything up-to-date

i ran the commands without changing anything in the files, and the terminal says: Everything up-to-date

git fetch to make sure your local repo reflects the latest status for all remote branches

The walk through wanted a hard coded response for the first interaction of introducing the comments feature. This is mainly what this PR focuses on, but newer versions of the files are  updated to get and show user input. Therefore, I dont think i need to merge this file to master,  but the walkthrough wanted me to make a pull request for it


fix and simplify rotation

Closes #59

i'm running yarn check-all which doesn't seem to be linting the code correctly since the ci is failing i'm i missing something?

I'm running yarn check-all and it reformats your code:

Maybe you don't have C++ linter installed - what's the output of yarn check-all for you?

What exactly does this fix? What is the error? I see no difference in the code rather than the removal of the custom rotation type, which I don't like.
If we upgrade libyuv and libyuv's Rotation enum changes, our code breaks without a compilation error because the values might've been shifted.
Better to be explicit in such places, there's a reason I wrote that switch statement for.

Closing in favor of #61. Being explicit makes sense for future changes. Trust me, learned lots of those things in VisionCamera.

What exactly does this fix? What is the error? I see no difference in the code rather than the removal of the custom rotation type, which I don't like.
If we upgrade libyuv and libyuv's Rotation enum changes, our code breaks without a compilation error because the values might've been shifted.
Better to be explicit in such places, there's a reason I wrote that switch statement for.

Well, in my opinion, we're thinking ahead of ourselves and anticipating a problem that may not even exist. The libyuv submodule is tied to a specific commit, so it won't suddenly update and break the code on its own. The enum rotation you created, which resolves to something like this, is really confusing in this specific scenario:
{
Rotation0 = 0,
Rotation90 = 1,
Rotation180 = 2,
Rotation270 = 3,
};"
Let me know if you'd like me to make any further changes!


Add Humanoid high-level class

It's quite long time I talk with people working in different projects about having a single shared entrypoint to use in order to compute common quantities used for software development for humanoid robots. It could either be C++ or Python, maybe the latter would be quicker to prototype, but I think this resource would be very useful also from C++.
Last year, in a project which is still private, I started something similar and I'm pretty sure that many of us have similar functionalities scattered in a dozen of repository. I attach in the details below my script, @dic-iit/dynamic-interaction-control if you have similar classes please link them here so that we can at least assess the minimum amount of functionalities that could be interesting to the whole group.
I'd like to start with an initial brainstorming regarding the desired feature, feel free to update this comment if you have the rights to do it, otherwise I'll try to keep the list updated:

xy position of the center of pressure for a single foot with multiple contact points (@diegoferigo, script below)
pure 3D force of the center of pressure for a single foot with multiple contact points (@diegoferigo, script below)
list of 2D points that form the support polygon, valid both in single and double support (@diegoferigo, script below)
centroid 2D coordinates of the support polygon (@diegoferigo, script below)
[...]

Additional ideas:

DCM resources
Capture Point

humanoid.py
This class requires a scenario.core.Model but, to remain aligned with BLF structure, it could use a KinDynComputations object instead.
# Copyright (C) 2020 Istituto Italiano di Tecnologia (IIT). All rights reserved.
# This software may be modified and distributed under the terms of the
# GNU Lesser General Public License v2.1 or any later version.

import numpy as np
from shapely.geometry import Polygon
from scenario import core as scenario_core
from typing import List, NamedTuple, Optional
from gym_pushrecovery.utils import conversions

class Point2D(NamedTuple):
    """
    A 2D point in space.
    """

    x: float = 0
    y: float = 0

class Humanoid:
    """
    Relay class of a :py:class::`~scenario_bindings.Model` providing methods useful for
    humanoid robots.
    Note:
        This class assumes contact with flat terrain.
    Args:
        model: The model to wrap.
    """

    def __init__(self, model: scenario_core.Model):

        if not model.valid():
            raise ValueError("The model is not valid")

        self.model = model

    def get_foot_center_of_pressure(self,
                                    foot_link_name: str,
                                    normal: np.ndarray = np.array([0, 0, 1.0]),
                                    other_scoped_link: str = "ground_plane::link",
                                    cop_force_threshold: float = 1E-5) \
            -> Optional[Point2D]:
        """
        Get the local center of pressure of a foot.
        Args:
            foot_link_name: The name of the foot link.
            normal: The normal of the foothold plane.
            other_scoped_link: The name of the other body in contact.
                The default value is the ground plane.
            cop_force_threshold: Threshold on the normal force to skip the active contact.
        Returns:
            The 2D world coordinates of the center of pressure if the foot is in contact,
            None otherwise.
        """

        force_mag = self.get_foot_center_of_pressure_force(
            foot_link_name=foot_link_name,
            normal=normal,
            other_scoped_link=other_scoped_link)

        if force_mag <= cop_force_threshold:
            return None

        # Get the contact wrench
        wrench = self.model.get_link(foot_link_name).contact_wrench()
        force, torque = np.split(np.array(wrench), 2)

        # Compute the CoP wrt the link frame
        torque_x, torque_y, _ = torque
        l_cop = np.array([-torque_y, torque_x, 0]) / force_mag

        # Convert the CoP in homogeneous coordinates
        l_cop_hom = np.concatenate((l_cop, [1]))

        # Return it wrt the world frame
        foot = self.model.get_link(foot_link_name)
        W_H_L = conversions.Transform.from_position_and_quaternion(
            position=np.array(foot.position()), quaternion=np.array(foot.orientation()))
        w_cop = W_H_L @ l_cop_hom

        return Point2D(x=w_cop[0], y=w_cop[1])

    def get_foot_center_of_pressure_force(self,
                                          foot_link_name: str,
                                          normal: np.ndarray = np.array([0, 0, 1.0]),
                                          other_scoped_link: str = "ground_plane::link") \
            -> float:
        """
        Get the normal force at the center of pressure.
        Args:
            foot_link_name: The name of the foot link.
            normal: The normal of the foothold plane.
            other_scoped_link: The name of the other body in contact.
                The default value is the ground plane.
        Returns:
            The force along the normal axis with origin at the center of pressure.
        """

        foot = self.model.get_link(foot_link_name)

        contact = self._extract_contact_with_body(link=foot,
                                                  other_scoped_link=other_scoped_link)

        if contact is None:
            return 0.0

        wrench = self.model.get_link(foot_link_name).contact_wrench()
        force, torque = np.split(np.array(wrench), 2)

        force_mag = force.dot(normal)
        return float(force_mag)

    def get_support_polygon(self,
                            support_links: List[str],
                            ground_link: str = "ground_plane::link") \
            -> List[Point2D]:
        """
        Get the vertices of the support polygon of the humanoid.
        Args:
            support_links: The links of the humanoid to consider for calculating the
                support polygon.
            ground_link: The scoped name of the other link considered as terrain.
                It defaults with the ground plane link.
        Returns:
            A list of 2D points of the coordinates of the polygon vertices if there are
            enough contacts, an empty list otherwise.
            The points are ordered counterclockwise and they represent a ring
            (the first point is also the last).
        """

        contact_points: List[Point2D] = list([])

        for link_name in support_links:

            contact = self._extract_contact_with_body(link=self.model.get_link(link_name),
                                                      other_scoped_link=ground_link)

            if contact is not None:

                for point in contact.points:
                    contact_points.append(Point2D(x=point.position[0],
                                                  y=point.position[1]))

        if len(contact_points) >= 3:

            polygon = Polygon(contact_points)
            convex_hull_vertices = polygon.convex_hull.exterior.coords

            return [Point2D._make(p[0:2]) for p in list(convex_hull_vertices)]

        return []

    def get_support_polygon_centroid(self,
                                     support_links: List[str],
                                     ground_link: str = "ground_plane::link",
                                     ) -> Optional[Point2D]:
        """
        Get the centroid of the support polygon.
        Note:
            In simulated models the centroid is calculated from the contact points
            provided by the physics engine.
        Args:
            support_links: The links of the humanoid to consider for calculating the
                support polygon.
            ground_link: The scoped name of the other link considered as terrain.
                It defaults with the ground plane link.
        Returns:
            The 2D point of the coordinate of the support polygon centroid if there are
            enough contacts, ``None`` otherwise.
        """

        convex_hull_vertices = self.get_support_polygon(support_links=support_links,
                                                        ground_link=ground_link)

        if len(convex_hull_vertices) == 0:
            return None

        centroid_coordinates = Polygon(convex_hull_vertices).centroid.coords[0]
        return Point2D._make(centroid_coordinates)

    # ===============
    # Private methods
    # ===============

    @staticmethod
    def _extract_contact_with_body(link: scenario_core.Link,
                                   other_scoped_link: str) \
            -> Optional[scenario_core.Contact]:
        """
        Given a model link and the scoped name of another link part of the simulation,
        get the contact between them.
        The other link name should be scoped, e.g. ``<model_name>::<link_name>``.
        Args:
            link: The link belonging the model.
            other_scoped_link: The scoped name of the other link in contact.
        Returns:
            The contact if it exists, ``None`` otherwise.
        """

        if not link.in_contact():
            return None

        for contact in link.contacts():

            if contact.body_b == other_scoped_link:

                assert contact.body_a == link.name(scoped=True)
                return contact

        return None

I see the advantage of such high-level class. On the other hand, the devil is in the details, and I think that (given his high potential for large adoption), this has to be discussed properly.
For example, I think that the methods should clearly indicate when they need to communicate to the robot or not. Just to give some examples of possible confusion:

the computation of the Cop

which wrench does it use? Does it need to communicate with the robot?
in which reference frame it is defined?

setting a desired CoM

does it involve some heavy computations?
does it command the robot immediately?

In addition, the definition of this class may potentially limit future applications. For example, we could give the centroid of the support polygon, but what if the feet are not coplanar? In that case, it is not well defined. Hence, I am afraid to train the users to use these kinds of methods without knowing what is actually happening.
From my point of view, rather than a superclass, I prefer having the possibility to construct an architecture by connecting simple elements of which I know the limits and the applicability.

Without entering in the details of what @S-Dafarra wrote, just a naming bikeshedding: I would avoid having a class named Humanoid, but I would try to capture more the actual class of application, so either Biped<something>  if it is indeed limited to something with two legs, or Legged<somethng>  if it apply to any legged system. Furthermore, if the class has some assumption (non-point contacts, flat terrain) I would reflect that in the name.

@S-Dafarra yes I totally agree with you. This is a design issue and is meant to trigger the discussion on points similar to those you raised.

I think that the methods should clearly indicate when they need to communicate to the robot or not.

Going more in details on your comment, I'd envision this class to be agnostic from the robot source. My Python implementation is based on scenario.core.Model that currently is only implemented for Ignition Gazebo, but I have a draft for a YARP robot. Similarly, a BLF class could work independently from the robot implementation working an object that implements the interfaces in the RobotInterface folder.

In addition, the definition of this class may potentially limit future applications. For example, we could give the centroid of the support polygon, but what if the feet are not coplanar? In that case, it is not well defined. Hence, I am afraid to train the users to use these kinds of methods without knowing what is actually happening.

Sure, the provided features and limitations must be clearly documented. Though, right now I see a massive duplication for these functionalities, and starting collecting the most common, even if not complete, it's a starting point.

From my point of view, rather than a superclass, I prefer having the possibility to construct an architecture by connecting simple elements of which I know the limits and the applicability.

I like having a unique entrypoint with all the features that could be unified, think about how people use KinDynComputations and how useful it is having a similar superclass for all the features that can be unified. This being said, maybe not all the features could go under the same hat, in this case we can create subclasses that inherit and specialize.

just a naming bikeshedding [...]

Totally open to any clearer naming proposal :wink:

Going more in details on your comment, I'd envision this class to be agnostic from the robot source

In my opinion, it is important to keep it clear from the code when the communication is happening. This is very important when working with the real platform so that you understand if you are working with "fresh" data or not. Just to reason a little bit more on the resulting code structure. For example, imagine a series of calls like:
humanoid.computeSomething()
humanoid.getThis()
humanoid.computeSomethingElse()
humanoid.setThat()
humanoid.getThose()

From a code like this it is hard to understand when things are read from the robot, computed or commanded to the robot.
I kinda like more the pattern used in game engines
beginScene()
doSomething()
endScene()

beginScene() is where things are initialized, then you do something, and when you call endScene() all the modifications take effect, and the scene is rendered on the window. This is because the drawing part is expensive and you want to control when this is done.
KinDynComputations has a similar pattern. You set the model, allocating memory. Then you set the robot state, after which you can retrieve all the quantities you need. In this case, when the computation is done is a little hidden (for example it updates the kinematics the first time you require a transform), but you know that you have to first set the robot state because that's the only way to specify the joint values.
Hence, my hint would be to define the methods such that it becomes clear that the communication with the robot has to be instantiated, or that you are about to send some commands. Just documenting things is often not enough.

In my opinion, it is important to keep it clear from the code when the communication is happening. This is very important when working with the real platform so that you understand if you are working with "fresh" data or not.

Definitely, two possibilities are either using an approach similar to KinDynKinematics::setRobotState (since the state is well defined) or a more generic <NewHumanoidClass>::update() that uses a configurable callback --that can be a closure binding a simulator in a complex example-- :
// 1. Set explicitly the state
auto obj1 = NewHumanoidClass();
obj1.setState(var1, var2, var3);

// 2. Use a callback
auto cb = [&]() -> NewHumanoidClassState { /*...*/ };

auto obj2 = NewHumanoidClass();
obj2.setUpdateCallback(cb)

// This could be downcasted to the interface after this point
obj2.update()

Just to list two of the first examples that come in my mind.

I kinda like more the pattern used in game engines: [...]

Honestly, I do not really like any approach that require to open and close explicitly a computation block because it is a dangerous pattern that gives too much responsibility to the caller (beyond making error checking / behavioral mistakes checks more difficult). It is also against all the recent push of the language towards RAII-like implementations. Maybe there are drawbacks I'm not seeing right now, but the callback seems a good trade off. It also allows having different states for different implementations, if needed. Then, the ::update method could be generic and part of the interface.
Edit: thinking more about it, moving IO logic (actually, just input) to the callback could even avoid the pattern interface + multiple implementations. Then, the NewHumanoidClass could just work on a struct with plain data.

This update pattern seems very similar to the advance method we have in Advanceable. If you don't want to use the pattern interface + multiple implementations, a possibility could be to create an advanceable implementation that accepts std::functions in the constructor.
Notice that some parts, like the yarp sensor bridge implementation, are already inheriting from Advanceable (thus it has already the advance method https://github.com/dic-iit/bipedal-locomotion-framework/blob/master/src/RobotInterface/YarpImplementation/include/BipedalLocomotion/RobotInterface/YarpSensorBridge.h#L115).
This goes in the direction of the block-like infrastructure on which @GiulioRomualdi was already experimenting. That infrastructure also allows running different parts at different rates for example (see https://github.com/dic-iit/bipedal-locomotion-framework/blob/master/src/System/include/BipedalLocomotion/System/AdvanceableRunner.h).

This update pattern seems very similar to the advance method we have in Advanceable. If you don't want to use the pattern interface + multiple implementations, a possibility could be to create an advanceable implementation that accepts std::functions in the constructor.

This is a brilliant observation @S-Dafarra, I didn't think this way initially, but the existing design of blf definitely shaped unconsciously my proposal :smile:
In any case, this discussion is a broad brainstorming that I wanted to trigger since I'm seeing code duplicating quite fast. I'm not planning to work on this is the near future. Though, let's keep this discussion in mind and try to keep it updated.


Use local TF backend by default

Is your feature request related to a problem? Please describe.

If I am using the CLI, I may not want to keep TF state in a S3 bucket.
Describe the solution you'd like

By default, the CLI will use a TF local state file for the backend configuration.
Describe alternatives you've considered

Additional context

See related issue #15

Closing as duplicate of #18 (more or less)

Should the remote (S3) behavior be preserved? Should there be an optional flag or something (eg., "--use-s3-backend") that when set would use the existing behavior but the default will simply be the local backend?

The plan we discussed was to not create any kind of TF backend for you, but to allow the end-user to configure their own backend in dce.yml
eg, something like:
terraform:
  backend:
    type: s3
    bucket: my-state-bucket
    key: terraform.tfstate

Should the remote (S3) behavior be preserved

Also note that the s3 backend never actually worked -- it would create a new backend and tfstate file with every call to dce system deploy.

The plan we discussed was to not create any kind of TF backend for you, but to allow the end-user to configure their own backend in dce.yml
eg, something like:
terraform:
  backend:
    type: s3
    bucket: my-state-bucket
    key: terraform.tfstate

OK. I re-opened #15 to handle the second part of this problem. This issue is specifically addressing not creating any kind of TF backend for you.

Using a local terraform backend is currently now the default behavior for the dce system deploy command, and technically the only supported behavior until #54 is pushed out (which is my next priority). The backend file is created in ~/.dce/.cache/module/main.tf.


go/ast: CommentMap mishandles loose, trailing file comments

go version devel +812b34efae Mon Sep 4 00:07:33 2017 +0000 linux/amd64
Construct a comment map for:
package p

func f() {
        return
}

// loose trailing comment

The loose trailing comment is associated in the CommentMap with the
return statement inside f. It should probably be associated with f
instead, and the NewCommentMap docs updated with new rules.
Live proof: https://play.golang.org/p/XCktcSxYl8

CC @griesemer

I also see that there even is a test that includes this:
"50: *ast.Ident":      "the very last comment\n",

In that case, the trailing comment in the file is attached to an ast.Ident. I don't see a TODO nor any open issue about this, so I'm wondering if this is actually on purpose.
Another option would be to attach it to the whole ast.File. Either sounds better than the current behavior. The docs don't seem to cover this case.

Closed by mistake in one of @josharian's private repos, I assume.

A couple of other weird cases:
https://play.golang.org/p/d46URuVRTJ
https://play.golang.org/p/d79_UMvkzS

Closed by mistake in one of @josharian's private repos, I assume.

Indeed. FWIW, here's the diff I used, which fixed it the way I wanted it fixed for my private purposes. I haven't thought about whether it is an appropriate fix for the go/ast package.
diff --git a/astutil/commentmap.go b/astutil/commentmap.go
index c6f0d62..7c8170f 100644
--- a/astutil/commentmap.go
+++ b/astutil/commentmap.go
@@ -206,7 +206,8 @@ func NewCommentMap(fset *token.FileSet, node ast.Node, comments []*ast.CommentGr
 			switch {
 			case pg != nil &&
 				(pgend.Line == r.pos.Line ||
-					pgend.Line+1 == r.pos.Line && r.end.Line+1 < qpos.Line):
+					pgend.Line+1 == r.pos.Line && r.end.Line+1 < qpos.Line ||
+					q == nil):
 				// 1) comment starts on same line as previous node group ends, or
 				// 2) comment starts on the line immediately after the
 				//    previous node group and there is an empty line before
diff --git a/astutil/commentmap_test.go b/astutil/commentmap_test.go
index 3df0e65..a645032 100644
--- a/astutil/commentmap_test.go
+++ b/astutil/commentmap_test.go
@@ -92,9 +92,9 @@ var res = map[string]string{
 	"31: *ast.ExprStmt":   " associated with s1\nalso associated with s1\n",
 	"37: *ast.ExprStmt":   "associated with s2\nalso associated with s2\nline comment for s2\n",
 	"45: *ast.FuncDecl":   "associated with f2\nf2\n",
+	"48: *ast.FuncDecl":   "the very last comment\n",
 	"49: *ast.AssignStmt": "addition\n",
 	"49: *ast.BasicLit":   " 1\n",
-	"50: *ast.Ident":      "the very last comment\n",
 }


Add a curriculum given as a metro map.

"Finally, a wrap up with a useful curriculum via metro map come in handy for every aspiring data scientist. ''  Add this line, it will be helpful.

This is a really fun (and useful) resource! I wish I could include every suggestion. Thank you for your suggestion!


openBox/openLazyBox can potentially open a Box twice

Steps to Reproduce
Call openBox or openLazyBox twice in succession with the same arguments. The result will be two different instances (checked by "hashCode").
This causes issues when writing to the database since notifications about changes are tied to a each instance. To obtain new data, one needs to close and open again.
To solve this, I am using https://pub.dev/packages/synchronized
But I believe this should be handled by the library, as I personally, just to understand where the issue lays, spent a few days of "WTF is happening".
Code sample
The following example is simplified, to accent the problem
final instance1 = Hive.openBox('test');
final instance2 = Hive.openBox('test');

// instance1.hashCode != instance2.hashCode

My solution
final lock = Lock();

final instance1 = lock.synchronized(() async => await Hive.openBox('test'));
final instance2 = lock.synchronized(() async => await Hive.openBox('test'));

// instance1.hashCode == instance2.hashCode

Version

Platform: iOS, Android
Flutter version: Channel stable, v1.17.3, on Mac OS X 10.15.4 19E287, locale en-US
Hive version: v1.4.1+1

openBox is a Future, which means that the compiler will move to the next line before the result of the variable, until the end of the Future, instance1 and instance2 are two different Futures objects. When the result arrives, they will be pointed to the same reference in memory.
I think you don't need an external package for this, you just need to do this:
final instance1 = await Hive.openBox('test');
final instance2 = await Hive.openBox('test');
// instance1.hashCode == instance2.hashCode
Thus, I believe that using await there is no possibility to open the box twice.

There is, I am actually awaiting the Future - I mentioned this is very simplified

And I still believe, it should be prevented on the library level, open a box twice, since it leads to very unpredictable behavior.

Well, I guess you didn't quite understand what I meant, so I'll try to explain it better.
Currently in Dart we have 2 types of variables, asynchronous, and synchronous (this will change, the "late" variables will be added).
When you create a variable, it is always a "new" instance.
class Foo{}

final a = Foo();
final b = Foo();

print(a==b); // false

When you declare a "Future", you are calling the factory of the Future class, and this will always return a new instance.
If you have 150 instances of Futures, they are all different, but when you call await, all instances that are called with await can receive a global instance.
import 'dart:async';

void main() {
  final a = asyncFunction();
  final b = asyncFunction2();
  print(a==b);
  //Console: false
}

String global = 'global';

Future<String> asyncFunction() {
  return Future.value(global);
}

Future<String> asyncFunction2() {
  return Future.value(global);
}

When you declare an instance of a Future, the dart creates an instance of a Future, so that you can get the promised value with an await / then. The delivered object is not the object you are waiting for, it is just a factory, so you can get the instance, function or variable you want with an await/then.
import 'dart:async';

void main() async {
  final a = await asyncFunction();
  final b = await asyncFunction2();
  print(a==b);
  //Console: true
}

String global = 'global';

Future<String> asyncFunction() {
  return Future.value(global);
}

Future<String> asyncFunction2() {
  return Future.value(global);
}

Despite always creating a different instance of Future, the created object will always be the same instance when called with an await/then
import 'dart:async';

void main() async {
  final a = asyncFunction();
  final b = asyncFunction2();
  print(a==b);
  // false

  final c = await a;
  final d = await b;

  print(c ==d);
  // true
}

String global = 'global';

Future<String> asyncFunction() {
  return Future.value(global);
}

Future<String> asyncFunction2() {
  return Future.value(global);
}

So, you are not opening two boxes, you will only open the first, the second will give you the same object as the first. This is standard dart behavior, and the box will only open once on the hive, as hive checks if there is an open box.
I know that at first glance, it seems that everything is being opened twice (as in example 2), but with example 3 I believe it has become clear that this does not happen.

But it is actually opened twice, I have a working (well broken) example - where I can get two boxes to open and notifications of changes not being delivered. Explain me than, how is that possible?

awaiting open(Lazy)Box es works as expected.

awaiting open(Lazy)Box es works as expected.

Awaiting works as expected, the problem is when you don't await them like so (in the synchronous matter), which can easily happen, when you call "openBox" from different parts of the app.
Then, you can easily get two different instances.
I will try to give you a test scenario which fails.

awaiting open(Lazy)Box es works as expected.

Awaiting works as expected, the problem is when you don't await them like so (in the synchronous matter), which can easily happen, when you call "openBox" from different parts of the app.
Then, you can easily get two different instances.
I will try to give you a test scenario which fails.

But you have to await openBox :D that's why it's async function btw. I think this is not a issue. This issue may occur on dart internal functions too (eg: file read / write functions).

awaiting open(Lazy)Box es works as expected.

Awaiting works as expected, the problem is when you don't await them like so (in the synchronous matter), which can easily happen, when you call "openBox" from different parts of the app.
Then, you can easily get two different instances.
I will try to give you a test scenario which fails.

But you have to await openBox anyway :D that's why it's async function btw. I think this is not a issue. This issue may occur on dart internal functions too (eg: file read / write functions).

 I would appreciate if you tried and instead were open-minded and thought about the problem, instead of fast "bullshit" replies. It's just useless for the open-source community and discourages people like me to contribute and help.
I understand my explanations are not perfect, but, well it's not easy to explain complex problems in a few sentences/short samples of code.
With that out of way -
No, I think you don't understand. I do "await" the opening of box, that's not the problem. I don't await two of them synchronously, in one file one after another.
The problem is that having two separate "classes", which both open the same box inside, using them from separate parts of the app. If by chance, you call the "openBox" function at the same time - awaiting results - Dart doesn't guarantee that they will happen one after another and this library doesn't handle this either.
Here is a reproduction example: https://github.com/filipproch/hive_bug_synchronization_reproduction
Run it and you will get multiple instances of "Box" (in my case for example)
box[817852974]
box[96392022]
box[718610807]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]

awaiting open(Lazy)Box es works as expected.

Awaiting works as expected, the problem is when you don't await them like so (in the synchronous matter), which can easily happen, when you call "openBox" from different parts of the app.
Then, you can easily get two different instances.
I will try to give you a test scenario which fails.

But you have to await openBox anyway :D that's why it's async function btw. I think this is not a issue. This issue may occur on dart internal functions too (eg: file read / write functions).

 I would appreciate if you tried and instead were open-minded and thought about the problem, instead of fast "bullshit" replies. It's just useless for the open-source community and discourages people like me to contribute and help.
I understand my explanations are not perfect, but, well it's not easy to explain complex problems in a few sentences/short samples of code.
With that out of way -
No, I think you don't understand. I do "await" the opening of box, that's not the problem. I don't await two of them synchronously, in one file one after another.
The problem is that having two separate "classes", which both open the same box inside, using them from separate parts of the app. If by chance, you call the "openBox" function at the same time - awaiting results - Dart doesn't guarantee that they will happen one after another and this library doesn't handle this either.
Here is a reproduction example: https://github.com/filipproch/hive_bug_synchronization_reproduction
Run it and you will get multiple instances of "Box" (in my case for example)
box[817852974]
box[96392022]
box[718610807]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]
box[383865212]

Thanks, I understand. Maybe I could cache openBox requests too. I will think about how to fix that issue. Sorry for misunderstanding ):


Adds missing coil TPV-Alloy in version 2.5

I think Tungstensteel Coils are renamed to "TPV-Alloy" some time. I am playing version 2.5.

Good but this would break multismelter https://github.com/OrderedSet86/gtnh-flow/blob/master/src/gtnh/overclocks.py#L186-L187
I will fix that and then merge


How to get latest 32-BIT version?

Hello, I'm looking for a way to update to or install the latest 32-bit version of Atom, since there is a Python lintier that doesn't work with my current version: 1.0.11.
If I need to uninstall my current version, can someone please tell me how to do that as well?
System (uname -a): Linux AcerNotebook 3.2.0-109-generic-pae #150-Ubuntu SMP Fri Aug 12 18:59:00 UTC 2016 i686 i686 i386 GNU/Linux
Please don't mark this as closed when you post a solution in case that solution doesn't work for me.
Thank you in advance!

Releases can either be downloaded from https://atom.io/ or https://github.com/atom/atom/releases.
Also, we're trying to control the amount of Issues that we have to triage and track. For general questions, the Atom message board is where you'll probably be able to find answers faster.  If you're still having issues after trying both of those methods, please create a new topic on Discuss instead.


chore: add Apache 2.0 reference to documentation

Please add a reference to the Apache 2.0 license to the starting point to each of your documentation (for example Arc42, User Guide, Admin Guide) according to this TRG.

@ds-ext-kmassalski provided the link to the PR for approval

Hi @ds-ext-kmassalski! Yes it looks good, you can open a PR for the eclipse repo too.

Hi @ds-jhartmann! Thanks, closing this now.


Xcode Asset validation failed

I've been trying to add an app to the Apple Store via Xcode and have been met with varying errors. I also tried upping the FBSDK version to 15 (in the node module) which eliminated dozens of  validation failures, but 3 still remained (two of which are "does not support the minimum OS Version specified in the Info.plist").
The only change I could make that made a difference was when I changed the "platform :ios," to '12.0' in the Podfile, and when I run "pod install --repo-update --verbose", I am met with "The platform of the target App (iOS 12.0) may not be compatible with CapacitorCommunityFacebookLogin (4.0.0-1) which has a minimum requirement of iOS 13.0." (plus a dozen other plugins with a similar message).
Just seeing if there is anything obvious I am missing or can do.
I am using:
Ionic: 6.20.1
Capacitor: 4.0.0
Xcode: 14.0
capacitor-community/facebook-login: ^4.0.0-1
These are the errors when I submit the archive through Xcode when leaving the FBSDKCoreKit/FBSDKLoginKit version at 14 in the CapacitorCommunityFacebookLogin.podspec file:
Invalid MinimumOSVersion. Apps that only support 64-bit devices must specify a deployment target of 8.0 or later. MinimumOSVersion in 'App.app/Frameworks/FBSDKCoreKit_Basics.framework' is ''. (ID: cb85ab94-2060-4566-9124-362727d484c5)

Asset validation failed
Invalid MinimumOSVersion. Apps that only support 64-bit devices must specify a deployment target of 8.0 or later. MinimumOSVersion in 'App.app/Frameworks/FBSDKLoginKit.framework' is ''. (ID: bc9295bd-ee16-4fb3-bdc8-e530ef8f7c22)

Asset validation failed
Invalid CFBundleSupportedPlatforms value. The CFBundleSupportedPlatforms key in the Info.plist file in “Payload/App.app/Frameworks/FBAEMKit.framework” bundle contains an invalid value, [iPhoneSimulator]. Consider removing the CFBundleSupportedPlatforms key from the Info.plist file. If this bundle is part of a third-party framework, consider contacting the developer of the framework for an update to address this issue. (ID: 2ad60437-0790-4a8a-913e-5f6cdf0cb96a)

Asset validation failed
Invalid CFBundleSupportedPlatforms value. The CFBundleSupportedPlatforms key in the Info.plist file in “Payload/App.app/Frameworks/FBSDKCoreKit.framework” bundle contains an invalid value, [iPhoneSimulator]. Consider removing the CFBundleSupportedPlatforms key from the Info.plist file. If this bundle is part of a third-party framework, consider contacting the developer of the framework for an update to address this issue. (ID: 4ede0d96-fddd-4b46-9fb2-6b5d42c14618)

Asset validation failed
Invalid bundle structure. The “App.app/Frameworks/FBSDKLoginKit.framework/Versions/A/FBSDKLoginKit” binary file is not permitted. Your app cannot contain standalone executables or libraries, other than a valid CFBundleExecutable of supported bundles. For details, visit: https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle (ID: 5cc0bcf1-b259-4f0f-9497-579269a9540a)

Asset validation failed
Invalid bundle structure. The “App.app/Frameworks/FBSDKCoreKit_Basics.framework/Versions/A/FBSDKCoreKit_Basics” binary file is not permitted. Your app cannot contain standalone executables or libraries, other than a valid CFBundleExecutable of supported bundles. For details, visit: https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle (ID: 84d2547b-d92b-4aad-b217-12b354641ccb)

Asset validation failed
Missing Info.plist value. A value for the key 'MinimumOSVersion' in bundle App.app/Frameworks/FBSDKCoreKit_Basics.framework is required. (ID: 12a2a88d-b195-443f-99ea-46f3c52e6128)

Asset validation failed
Missing Info.plist value. A value for the key 'MinimumOSVersion' in bundle App.app/Frameworks/FBSDKLoginKit.framework is required. (ID: 8480cbf6-145a-491c-9db6-8ef43b767550)

Asset validation failed
The binary is invalid. The encryption info in the LC_ENCRYPTION_INFO load command is either missing or invalid, or the binary is already encrypted. This binary does not seem to have been built with Apple's linker. (ID: bf633012-3d57-46e9-a8d1-f1bce5e74a45)

Asset validation failed
Invalid Bundle. The bundle App.app/Frameworks/FBAEMKit.framework does not support the minimum OS Version specified in the Info.plist. (ID: 26ebc373-94a6-40ea-952c-09f9590f08f0)

Asset validation failed
Invalid Bundle. The bundle App.app/Frameworks/FBSDKCoreKit.framework does not support the minimum OS Version specified in the Info.plist. (ID: ccf17bdd-7b47-40d0-915e-9f309b2ef9e6)

Asset validation failed
Invalid Bundle. The bundle App.app/Frameworks/FBSDKCoreKit_Basics.framework does not support the minimum OS Version specified in the Info.plist. (ID: 7b0abfae-29f1-463b-ad3f-3f5604dcb4ef)

Asset validation failed
Invalid Bundle. The bundle App.app/Frameworks/FBSDKLoginKit.framework does not support the minimum OS Version specified in the Info.plist. (ID: ba6893d9-d37a-4350-bf7a-53085e7d66e6)````

**

> These are the errors when I submit the archive through Xcode when changing the FBSDKCoreKit/FBSDKLoginKit version at 15 in the CapacitorCommunityFacebookLogin.podspec file:

**

Asset validation failed
The binary is invalid. The encryption info in the LC_ENCRYPTION_INFO load command is either missing or invalid, or the binary is already encrypted. This binary does not seem to have been built with Apple's linker. (ID: ae98a230-5b15-49c1-be7c-b7933a397ed8)

Asset validation failed
Invalid Bundle. The bundle App.app/Frameworks/FBSDKCoreKit_Basics.framework does not support the minimum OS Version specified in the Info.plist. (ID: 89a02f4a-5d7f-4dc5-b17c-1a712ddabf86)

Asset validation failed
Invalid Bundle. The bundle App.app/Frameworks/FBSDKLoginKit.framework does not support the minimum OS Version specified in the Info.plist. (ID: fd7e79d9-f881-4072-b468-de21eee47b33)

platform :ios, '13.0'
use_frameworks!
my podfile works fine using ios 13.0
and then
pod 'CapacitorCommunityFacebookLogin', :path => '../../node_modules/@capacitor-community/facebook-login'

@ciccilleju Yeah, I am defaulted to the above configuration in the Podfile, I just tried 12 in the Podfile because changing the version anywhere else seemed to make no difference and that FBSDK 15 supports ios 12 and FBSDK supports ios 11. And, if I run vtool --show on the ios-arm64 binary in the Pods directory (when using FBSDK 15) it was showing: (I believe)
Load command 9       cmd LC_VERSION_MIN_IPHONEOS       version 12.0
Interesting about rolling back, I'll try that.

@ciccilleju Thank you very much! Rolling back worked.


[BUG] Issue when switching -Connection on Get-PnPList, Get-PnPWeb, ...

Reporting an Issue or Missing Feature
Issue
Expected behavior
I expect the following use of two connections to work:
$con1 = Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/one" -Tenant "contoso.onmicrosoft.com" -ClientId $clientId -Thumbprint $thumbprint -ReturnConnection:$true
Get-PnPList -Connection $con1

$con2 = Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/two" -Tenant "vollert.onmicrosoft.com" -ClientId $clientId -Thumbprint $thumbprint -ReturnConnection:$true
Get-PnPList -Connection $con2

Actual behavior
The first retrieval succeeds. The second fails with error:
Get-PnPList:
Line |
   5 |  Get-PnPList -Connection $con2
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | The remote server returned an error: (404) Not Found.

Note that this does not happen with any two different sites. I suppose the structure must be different so that certain IDs differ. This is based on my assumption that a context from the first connection is being re-used although it mustn't.
Note 2: It does work when using the same site URL for both connections.
Steps to reproduce behavior
Run the above code with the stated nightly PnP PowerShell.
What is the version of the Cmdlet module you are running?
1.10.55 nightly
Which operating system/environment are you running PnP PowerShell on?

[x] Windows
[ ] Linux
[ ] MacOS
[ ] Azure Cloud Shell
[ ] Azure Functions
[ ] Other : please specify

Notes
Could it be that the PnPWebRetrievalsCmdlet is holding on to a cached context?
GetList used CurrentWeb:
https://github.com/pnp/powershell/blob/c022f19d5cb0fa78a576a75aae21b4af376031a2/src/Commands/Lists/GetList.cs#L39
PnPWebRetrievalsCmdlet serves a cached currentWeb:
https://github.com/pnp/powershell/blob/c022f19d5cb0fa78a576a75aae21b4af376031a2/src/Commands/Base/PnPWebRetrievalsCmdlet.cs#L28
Same behavior for Get-PnPWeb by the way (404), don't know why though. Might be other cached contexts in play.
fyi @KoenZomers

I am dumb. The site does not exist anymore. Sorry.

(The cached web might still pose a problem, though?)


#832 Restructure HSL statement parsers

Description
The default HSL is strictly bound to a specific syntax and set of language features, having all logic in a single class responsible for parsing tokens (See hartshorn-hsl/Parser.java).
These changes separates statement parsers into dedicated partial parsers, so they can be enabled/disabled on demand. Additionally, this makes it easier to add additional statement parsers manually.
As expressions are recursively parsed, this is still implemented as a single parser. Though this has also been updated to be more easily replaceable.
Fixes #832
Type of change

[x] New feature (non-breaking change that does affect the code)
[x] Refactor (code changes that do not affect the behavior of the code)

How Has This Been Tested?

[x] Unit testing

Checklist:

[x] I have performed a self-review of my own code
[x] I have added tests that prove it is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Related issue number is linked in pull request title

Risk accepted.

Dependency check fails due to a transitive dependency on Apache BCEL with CVE-2022-42920. This is present through annotation-tools-3.27.0 which in turn is present through Checker Framework 3.27.0.
While we keep the CF annotations through org.checkerframework:checker-qual:3.27.0, we do not use the implementation of CF3.27.0 at runtime, as we only use it for compile-time constraint validation (nullable validation). This PR was both manually and automatically checked to not introduce further risks, and is therefore accepted.


Command for Playing a Sound

Add command to play sound on the device in case you have lost it in a place close to you.
Idea is from discussion https://github.com/tranquvis/SimpleSmsRemote/issues/45 .

What would be the advantage of sending an SMS over just calling the phone? The existing audio module allows to adjust the ringtone volume to maximum.

A command to lock/unlock the volume level would be very useful

@intika What do you mean with locking/unlocking?


ci: Update to Ubuntu 22.04

Updating the stack hopefully will yield better diagnostics.

Closing because I opened this PR from the wrong (private) account and it needs some more work anyway.


Adjust camera position based on canvas size

Camera currently changes Z position based on size of trajectory. It should also adjust to the canvas size, so it consistently scales no matter how the user sizes the browser window, or different devices with different portrait or landscape views.

Fixed with most recent update


HSEARCH-3433 Upgrade to Hibernate ORM 5.4.0.Final

https://hibernate.atlassian.net//browse/HSEARCH-3433

Pull Request Test Coverage Report for Build 1

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 87.096%

Totals

Change from base Build 103:
0.0%

Covered Lines:
12723

Relevant Lines:
14608

💛  - Coveralls


[Debugger] Ensure all probes have a version property

Motivation
All probes sent via Remote Config should have a root version property. For some reason, one was not present in our mocked probe configs located in tests/debugger/probes. I'm not sure why this hasn't resulted in system test errors previously since the diagnostics schema expects that a version is reported. However, without this, at least the Node.js tracer, would set version: undefined in the object before it was serialized to JSON, which would completely remove the version property from the JSON output.
Maybe they other tracers fall back to 0 if there's no version property in the probe config?
Changes
Hardcode all mocked probe configs to contain version: 0.
Workflow

⚠ Create your PR as draft ⚠
Work on you PR until the CI passes (if something not related to your task is failing, you can ignore it)
Mark it as ready for review

Test logic is modified? -> Get a review from RFC owner. We're working on refining the codeowners file quickly.
Framework is modified, or non obvious usage of it -> get a review from R&P team

:rocket: Once your PR is reviewed, you can merge it!
🛟 #apm-shared-testing 🛟
Reviewer checklist

[ ] If PR title starts with [<language>], double-check that only <language> is impacted by the change
[ ] No system-tests internal is modified. Otherwise, I have the approval from R&P team
[ ] CI is green, or failing jobs are not related to this change (and you are 100% sure about this statement)
[ ] A docker base image is modified?

[ ] the relevant build-XXX-image label is present

[ ] A scenario is added (or removed)?

[ ] Get a review from R&P team

This PR seems reasonable since it only adds a field to the input (which I believe Ruby implementation will ignore), but I will test locally before adding my checkmark.

What's the reason we don't want to update the json at the source?

What's the reason we don't want to update the json at the source?
Single responsibility - updates are handled in one place, ensuring clarity.
Less changes.

But maybe it's just a matter of code taste, so it's up to you to decide.
Wanted to make sure that you're aware of this option, too.

@shurivich I think it makes a lot of sense to have a way to dynamically update the JSON to suite the language being instrumented and other non-fixed properties - exactly like you've done in tests/debugger/utils.py - otherwise we'd end up with a lot of duplication 👍
However, the version property is currently static - just like the id property - and doesn't depend on the tracer (this isn't the version of the tracer, but the "probe version" and is tightly connected to the id).
So if you don't mind, I'll just leave it as is - at least for now. I think that makes it easier to understand the schema when just viewing the JSON file. Anyways, we can always refactor it if we want to make to the probe version dynamic ☺

Sorry, the script that computes which scenario to run failed, so this PR hasn't be tested 😢
I've reverted it, and fixed the script.
To correct this PR, you must very probably update the hash, as the content you've sent has changed, I can help you to do so.


Collected CoFest Issues

[ ] makefile uses mamba, no longer needed, need to document enabling the libmamba solver instead?
[x] "Tip: Tips" in serving gtn tutorial
[ ] nodeaddrinfo tip box for maxs. getaddrinfo': getaddrinfo: nodename nor servname provided, or not known (SocketError)
[x] add slack URL to footer like matrix channel

@hexylena

[x] lint.rb for zenodo api urls
[ ] reg cap to events + form
[ ] chapters submitted with video form
[x] add comment about translations to the user prefs page (re: convesation with @nakucher)
[ ] misconceptions FAQs

[ ] only Helena and Saskia (can) merge things
[ ] if I can't write markdown I cant contribute
[ ] high standards (a11y, etc)
[ ] it is difficult to merge things
[ ] only finalised and completed tutorials may be merged and live on the site

[ ] quickstart guide / learning path for new contributors
[ ] quarterly release testing of gitpod / conda (gha)
[x] gha on workdays only, add submission time to form
[ ] how to get merge access
[ ] reviewing tutorial (how to interpret test outputs etc)
[ ] tag Google form PRs
[ ] rename "linting" and other technical terms in GHAs to user friendly ones

[ ] New features --> FAQ for features --> automated webhook for features into the random screens people get instead of PhD comics
[ ] iframe for Learning pathways that refers to the list of tutorials (and links) in that learning pathway, as well as the link to the Learning pathway, and something visual (i.e. the image you currently use for learning pathway) next to it to make it look very nice. This way, when I embed learning paths in different places, they have a more visual representation than the link alone.

Feedback after setting up my local GTN instance:
The 'listen' gem will guide you to the local instance via 'http://<IP_ADDRESS>:4000/training-material/' which gives an 'unable to connect' screen. Because of that, I spent a bit too much time debugging that while the link provided in the tutorial (http://localhost:4000/training-material/) does work.
Can I add a warning in the guide or change <IP_ADDRESS> in the makefile to localhost or do you have another suggestion/comment on this?

@B0r1sD in #1540  we changed it to <IP_ADDRESS> from <IP_ADDRESS>, I feel reticent to change it back. Please feel free to add a warning or a tip in the guide of "what to do if unable to connect" and there share  trying the 127 version

New features --> FAQ for features --> automated webhook for features into the random screens people get instead of PhD comics

it'll be at https://training.galaxyproject.org/training-material/faqs/random.html, if someone else has time to add to the webhook iframe it'd be lovely.


Asana task: TOC bug fix for headers

This GitHub issue was created to track Asana task assignment:https://app.asana.com/0/1200099998847559/1205976870784519

dupcalite


Fix block root properties default hash formats (0.2)

Description:
Cherry-pick
block.mixHash, block.receiptsRoot and block.stateRoot should return hexes of 32byte formats

Update eth.ts to use 32 bytes format
Update eth.spec.ts to use 32 bytes format
Updated assertions  to use 32 bytes format

Signed-off-by: Nana-EC<EMAIL_ADDRESS>Related issue(s):
Cherry-picks #263
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Codecov Report

Merging #265 (0778dd8) into release/0.2 (33b08bd) will increase coverage by 0.05%.
The diff coverage is 100.00%.

:exclamation: Current head 0778dd8 differs from pull request most recent head 02d0c44. Consider uploading reports for the commit 02d0c44 to get more accurate results

@@               Coverage Diff               @@
##           release/0.2     #265      +/-   ##
===============================================
+ Coverage        58.35%   58.41%   +0.05%
===============================================
  Files                9        9
  Lines              742      743       +1
  Branches           111      111
===============================================
+ Hits               433      434       +1
  Misses             283      283
  Partials            26       26

Impacted Files
Coverage Δ

packages/relay/src/lib/eth.ts
58.40% <100.00%> (+0.12%)
:arrow_up:

Continue to review full report at Codecov.

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


you shouldn't use subprocess in order to install plugins

use pip as a package instead

@KOLANICH what is the right way to install packages and plugins?

@KOLANICH that is because, pip can only run in main thread, which cause a ui dead.

"Plugin > Update Software" need a better solution too. do you have some advice?

Any progress?


Correction for raw affiliation Department of Economics, LARE-efi, Montesquieu Bordeaux IV University, Av. Leon Duguit, 33608 Pessac Cedex, France

Correction needed for raw affiliation Department of Economics, LARE-efi, Montesquieu Bordeaux IV University, Av. Leon Duguit, 33608 Pessac Cedex, France
raw_affiliation_name: Department of Economics, LARE-efi, Montesquieu Bordeaux IV University, Av. Leon Duguit, 33608 Pessac Cedex, France
new_rors: 05h5wna09
previous_rors: 03pbgwk21
works_examples: W1973866175
contact: 8daeab17b58fd59508dc759f11019b15:3b348e18a4963fe14c42a3 @ free.fr

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


feat: add support for field metdata

Previously we had just extracted the extension name from the field and discarded the rest of the metadata.  Unfortunately, these fields are used to parameterize extension types.  For example:
// A fixed shape tensor extension type for tensors with shape (2, 3)
metadata: {
    "ARROW:extension:name": "arrow.fixed_shape_tensor",
    "ARROW:extension:metadata": "{\"shape\":[2,3]}",
},

This PR keeps all of the metadata information.  This also allows for a lossless transformation when users have their own custom field metadata.

Do you want to add a test in Python for the repro I wrote in https://github.com/lancedb/lance/issues/1170?

I added fixed shape tensors to the test_roundtrip_types in test_lance.py


Android Notifications Failing: Documentation Required

Expected Behaviour
Fantastic plugin. I think it needs some documentation on setting the correct Content-Security-Policy to ensure plugins are received on Android devices. I grappled for several days trying to get notifications to arrive on various Android devices (emulators and physical devices) before realising that the absence of a correct Content-Security-Policy meta tag in my index.html file was the culprit.
Using the spec provided by an on-line example (shown below) caused notifications to arrive again on Android devices:
<meta http-equiv="Content-Security-Policy" content="default-src * 'unsafe-inline'; style-src 'self' 'unsafe-inline'; media-src *" />

Platform and Version (eg. Android 5.0 or iOS 9.2.1)
Android / Lollipop and Marshmallow
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
Various
Cordova CLI version and cordova platform version
cordova #6.0.0
cordova platform version android                     #5.1.1

@nickos333 but how is this different from any other Cordova Android app?

Exactly. Cordova documentation specifies that without some kind of configuration of the whitelist plugin/mechanism, no internet connection will ever be allowed by the app's bridge.

I'm going to close this as out of scope for the plugin. Without a CSP everything fails.


Flet does not respond on the Mac

Duplicate Check

[X] I have searched the opened issues and there are no duplicates

Describe the bug
flet run on the Mac (Intel I7 macOS Sonoma): An empty window appears, the program freezes. If I stop the process in the terminal, the Flet app still has to be closed separately via the task manager. This happened after I upgraded flutter (Flutter 3.22.2 with Dart 3.4.3) and installed the latest Flet version 0.23.2. Unfortunately, downgrading did not solve the problem. flet run --web is working, but not the native app.
Code
import flet as ft
def main_test(page):
    t = ft.Text(value="Hello, Mac!")
    page.controls.append(t)
    page.update()
ft.app(target=main_test)

To reproduce
flutter upgrade
pip install flet
flet run

Expected behavior
The app should not be an empty window that you can't close.
Screenshots
No response
Operating System
macOS
Operating system details
Intel I7 macOS Sonoma
Flet version
0.23.2
Regression
I'm not sure / I don't know
Suggestions
No response
Additional details
No response

last version working is: 0.22.0

I am having the same error on my Intel Mac


DAT-15602

Impact

[X] Bug fix (non-breaking change which fixes expected existing functionality)
[ ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Publish branch-builds before build.yml runs

Description

Things to be aware of

Things to worry about

Additional Context

I could remove/delete the entire branch-build workflow file. Please let me know what others think of it.

I could remove/delete the entire branch-build workflow file. Please let me know what others think of it.

I will merge this for now and will remove the archive folder once I get a word from @jnewton03.


Add configuration for CodeLlama data preparation, fine tuning and evaluation

@dimapihtar I just reformatted the code.


feat(website): store the last edited code

Store the last edited code, just like swc and typescript's playground.

Nice feature! Thank you!


[recast] Update to 1.6.0 and use official CMakeLists

Related: https://github.com/recastnavigation/recastnavigation/issues/630

Given the GH repo and CMake config name, renaming the port to recastnavigation should be seriously considered (and making the legacy port name simply depend on the new name).

Maybe not, upstream didn't complain about this.

Given the GH repo and CMake config name, renaming the port to recastnavigation should be seriously considered (and making the legacy port name simply depend on the new name).

Maybe not, upstream didn't complain about this.

It is not about upstream. It is about users.
FTR repology has 1 package for recast (vcpkg) and 26 packages for recastnavigation.

Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.

Tested usage successfully by recastnavigation:x64-windows:
Total install time: 692 us
recastnavigation provides CMake targets:

    # this is heuristically generated, and may not be correct
    find_package(recastnavigation CONFIG REQUIRED)
    # note: 1 additional targets are not displayed.
    target_link_libraries(main PRIVATE RecastNavigation::Detour RecastNavigation::Recast RecastNavigation::DebugUtils RecastNavigation::DetourCrowd)


Making metrics chart points connect on X axis in correct order

Issue: #45
It seems that sort  operation
Object.keys(mergedMetricsByIdx).sort()

was performing sort on strings and thus mixing the order.

Codecov Report

Merging #123 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master     #123   +/-   ##
=======================================
  Coverage   50.22%   50.22%
=======================================
  Files          87       87
  Lines        4191     4191
=======================================
  Hits         2105     2105
  Misses       2086     2086

Impacted Files
Coverage Δ

mlflow/server/js/src/components/MetricView.js
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Ah, makes sense. However, the problem is that Object.keys is not guaranteed to return the keys in any particular order, is it? It seems that there's no good way to get the right order if we're using Redux this way and a run has entries with the same timestamp. We're considering recording a "step" that's an increasing integer for each version of the metric reported to handle this as well as to let users control the X axis coordinates. CC @mparkhe who's thinking about this.

BTW maybe there's also a way to make Redux just keep the original array returned in the JSON instead of expanding these by key.

I agree with @mateiz that Object.keys should not guarantee the order of the keys. That being said, the code as is is way overengineered and was designed to merge stuff by timestamp instead of by index. We could implement it in a much cleaner way by simply merging all the lists returned by the calls to getMetricsByKey(runUuid, metricKey, state) for each runUuid

Hi @cryptexis,
This is a good observation. As @mateiz mentioned, we are looking at augmenting the Metrics data model with a notion of an alternative (custom) X-axis measure (in addition to timestamp). This will enable users to optionally log metrics with an alternative X-axis measure, which when present will override the timestamp based X-axis.
If you have any thoughts on that, will be happy to get more input on that.
Thanks,
mani

FYI, I was able to fix this by rewriting a bit more of the method in #204. Try that out and let us know if it works -- if so, we should close this pull request.


create issue templates

following up with #2, let's make issue templates for people proposing topics or requesting things from the organizers

Verycool


🐛 Bug Report: docs: broken link

📜 Description
https://github.com/backstage/backstage/blob/8a6d4e617e1608e64170ba08b76211eab77caa6c/docs/overview/architecture-overview.md#L46
The link is 404.
👍 Expected behavior
.
👎 Actual Behavior with Screenshots
.
👟 Reproduction steps
.
📃 Provide the context for the Bug.
No response
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, I don't have time to work on this right now

Thanks for reporting @jjangga0214 - side effect of a reason change in the demo environment - @awanlin is on it!:)


The files don't download neither from git nor the "Data Files"

I've just installed the BeardLib-editor since I've noticed that modworkshop.net is down, therefore there was no Stealthable Counterfeit available, so I've decided to change that. Found this editor, but the files aren't available for download due to U237 breaking the game entirely. Anyone can help me with the issue?

Have been like that ever since I've installed the mod

It might have been the fault of modworkshop being down, do you have any more success now that the site is somewhat functional again?

Nah, Modworkshop is still downed. I guess until that the mod is kinda useless

MWS is now working so closing