noosphere-cli intermittent test failures

Windows Run
thread 'gateway_receives_a_newly_initialized_sphere_from_the_client' panicked at 'called `Result::unwrap()`
on an `Err` value: IO error: could not acquire lock on
 "C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\.tmpjw4OSJ\\.sphere/storage\\db":
Os { code: 33, kind: Uncategorized, message: "The process cannot access the file because another process
has locked a portion of the file." }', rust\noosphere-cli\tests\gateway.rs:185:77

Linux Run (test_kubo only)
 thread 'multiplayer::orb_can_render_peers_in_the_sphere_address_book' panicked at 'assertion failed:
tokio::fs::try_exists(&cli.sphere_directory().join(\"@peer2-renamed/@peer3-of-peer2/@peer4-of-peer3/@peer5/content5.txt\")).await?',
 rust/noosphere-cli/tests/cli.rs:419:9

Cannot reasonably reproduce these locally..

I've seen the second one a couple of times :+1: I think it's a race condition. There is a lot going on in that test behind the scenes, and I think it's possible to hit all the beats such that the name record for one of the five spheres hasn't updated in time (and so the tree doesn't get rendered the way we expect).

An example of #2: https://github.com/subconsciousnetwork/noosphere/actions/runs/5790891571/job/15694746564?pr=569
FWIW I think that Windows failure is a different failure (perhaps also a flake, just a different one).

A similar error to the Windows one encountered here: https://github.com/subconsciousnetwork/noosphere/actions/runs/5800428176/job/15722516958
Which, I think, could be the same as the venerable https://github.com/subconsciousnetwork/noosphere/issues/167

Moving Windows error to https://github.com/subconsciousnetwork/noosphere/issues/579, updating this for the orb CLI rendering race condition

Caught another one: https://github.com/subconsciousnetwork/noosphere/actions/runs/6162416423/job/16723833912?pr=623

linux nightly

2023-10-19T18:53:03.5931754Z ---- multiplayer::orb_can_render_peers_in_the_sphere_address_book stdout ----
2023-10-19T18:53:03.5933632Z thread 'multiplayer::orb_can_render_peers_in_the_sphere_address_book' panicked at rust/noosphere/tests/distributed_stress.rs:433:9:
2023-10-19T18:53:03.5935374Z '@peer2-renamed/@peer3-of-peer2/<EMAIL_ADDRESS>should exist


72 Days Later, SONY Releases Firmware 3.69, Time for a Damage Report.

Have they patched the h-encore exploit or is it like 3.68 and it fixes an unrelated issue?

Yes, it stays on White Screen/Crashes.
https://twitter.com/skgleba/status/1039369006820597760
I say, it will just take a few days considering Sony was a lazy f*ker and just changed some numbers in the kernel here and there.

@RadiantAnsel
I personally would prefer that theFlow would hold-off making a fix. We're about 5 months away from the Vita card production deadline of February 15th 2019. Limited Run Games has 13 more Vita games to publish and that's it, might as well wait to have a final h-encore that's compatible with a firmware that will play all physical cards from all regions (nothing coming out in Japan after February 2019 by the looks of it).


Pattern / Component - Leadspace Block & Link List - keyboard focus is not covering all four sides of the element.

Detailed description
Issue :- Visual focus is there but its not covering all four sides of the element.
Additional information
Leadspace block:

Link list :

@guilhermelMoraes can you take this one as well since you're already looking at LinkList?

@jeffchew yes, sure

@RobertaJHahn Re checked this issues, keyboard focus on elements is working as expected.


[ci skip] Fix the documentation for Worksheet#cols

A small documentation fix adding a missing quote mark and curly bracket.

Any chance I could get you to fix the is => if typo as well?

@randym I am not sure about the /is/if/ replacement. I removed the is so the sentence can be read as warn - row 1 does not have a cell at 2.
Let me know if it is good. Thanks


feat(sdk): sdk-level retry logic for Fetch and FetchMany operations

Issue being fixed or feature implemented
Some requests can fail and require retry. For transport-level errors, rs-dapi-client implements retry logic. For higher-level errors (like, stale node detected #2254 ) we can also implement a retry mechanism on Sdk level.
What was done?
Implemented retry logic in Sdk, on top of #2258
How Has This Been Tested?
Manual testing on local devnet.
Breaking Changes
None
Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
[ ] I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

[ ] I have assigned this pull request to a milestone

Summary by CodeRabbit
Release Notes

New Features

Introduced a new tokio-sleep feature to enhance the DAPI client functionality.
Added a new retry function for managing asynchronous operations with retry logic.

Improvements

Simplified error handling across various methods by utilizing the IntoInner trait, improving clarity and maintainability.
Enhanced documentation for the retries field in RequestSettings for better user understanding.

Bug Fixes

Refined error handling in multiple transaction and document-related methods to ensure more robust processing.

Chores

Updated import statements and dependencies for improved code structure and functionality across various files.

@coderabbitai review

@coderabbitai review

@coderabbitai review

@coderabbitai review


LoaderBox has a fixed size of 200

Hi @Seimodei, thank you for creating this super useful library!
I was trying to integrate <GooeyLoader2 /> with my app, and realized the the LoaderBox component within it comes with a fixed size of 200. I'm wondering if that can be a configurable prop or be inferred from the size passed to the loader?
https://github.com/Seimodei/react-loaders-kit/blob/563061fa63f7192dfb72bd79726c744d96001070/src/gooey2/GooeyLoader2.tsx#L92-L108
My use-cases is using it in a button as the XHR requests are made, an example of a case where 200px default doesn't work.
Thoughts?

Hi @oyeanuj Thanks for using the library.
The problem with trying to change the size directly on this particular loader is that because of the way it is set up, any size that isn't 200px squashes the balls and it doesn't make it look pleasant.
A possible solution you can use to get around this is to wrap the loader in a div, and apply a transform scale property to it. But any other thing makes the loader ugly, thus, defeating the whole purpose.
Try this:

<GooeyLoader2 {...props} />

Let me know if this helps.

@Seimodei Thanks for the quick response! It seems like for GooeyLoader2, its required dimensions to function without being affected is 170x20.
So, it seems like maybe that could be set as the minimums? (Right now, it is 200x200 and that height has been problematic).

@oyeanuj Thanks for testing out the dimensions. I'll try them and update the library accordingly.


feature request: add sdk methods for organization apis

Take this issue as reference https://github.com/novuhq/novu/issues/4775

@Basfar @mayorJAY

Noted

@mayorJAY Has this been taken care of?

Yes, @Basfar is working on it


Inform community about "resolutionStrategy.force 'org.objenesis:objenesis:2.6'"

https://github.com/android/nowinandroid/blob/e997459f292058ade39368f9ecbfd4ed917e55b1/app/build.gradle.kts#L140
We shouldn't have to spend hours pouring over Stack Overflow to find things like this. Document it.

If our min api is > 25 we don`t need this?

@farble1670 This code has been removed in #806. Can you close the issue?


Clean up temporary files in test suite

Describe the bug
Temporary files are created when running the test suite, and it would be nice if these files were cleaned up after running.

agreed, thanks for pointing this out! It also happens in our experiments folder. Ill assign myself (and get it to...sometime this sprint)

@kmdeck has this been fixed? I think it has...

I think so too!


Remove need to add "hotkey-allow-in" if hotkey directive is used on an  element

Say I would like to add a hotkey directly on an input element. Right now, I would have to additionally add hotkey-allow-in="input". I see room for an improvement here: the directive should check whether it is applied onto an input element and then add the hotkey-allow-in attribute automatically.
The same should be true for the other types of elements: textarea and select.

Sorry for the delay here, I'm trying to clean up old tickets. If this is still important to you, please open a PR.  Thanks!


PDBs are updateable since 1.15

See https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#misc for the changelog note

Page preview:
https://deploy-preview-16738--kubernetes-io-master-staging.netlify.com/docs/tasks/run-application/configure-pdb/

/lgtm

/approve


framework: more robustness against failing Suricata

so as to catch unhandled exception if stdout/stderr has not an ascii character
Adds a timeout of 5 minutes per test
Replaces #935

Would https://github.com/OISF/suricata-verify/pull/901 catch the error?

I do not think so.
You can test with current Suricata master branch, test ut-complete

I'm not sure I agree with classifying these as io errors.  Instead we should handle this more gracefully. I'm thinking we open the stdout and stderr log files in binary mode, so we can pass the bytes through as is.  Then decode for display purposes.
For example: https://github.com/OISF/suricata-verify/pull/937
The timeout is still a good idea though.

Problem with #937 is that it tests pass on master when I think they should fail

Please see https://github.com/OISF/suricata-verify/pull/937#issuecomment-1249897016.  I think I'm OK with validating the data as UTF-8.. But it needs to happen after writing the output to the file so we maintain the bad data in a log.

Replaced by https://github.com/OISF/suricata-verify/pull/948


Related resources: URLs of resource links

I'd like some clarification on the purpose of resource members in links to related resources.
The relevant section of the current spec states:

If a relationship is provided as a link object, it MUST contain at least one of the following:

A self member, whose value is a URL for the relationship itself (a "relationship URL"). This URL allows the client to directly manipulate the relationship. For example, it would allow a client to remove an author from an article without deleting the people resource itself.
A resource member, whose value is a related resource URL (as defined above).
...

This seems rather clear to me, but the associated example contains a surprising value for a resource URL:
// ...
{
  "type": "articles",
  "id": "1",
  "title": "Rails is Omakase",
  "links": {
    "self": "http://example.com/articles/1",
    "author": {
      "self": "http://example.com/articles/1/links/author"
      "resource": "http://example.com/articles/1/author",
      "type": "people",
      "id": "9"
    },
    "comments": {
      "resource": "http://example.com/articles/1/comments"
    }
  }
}
// ...

"http://example.com/articles/1/author" – Why is there an article-specific URL for this linked resource? If I'm understanding the spec correctly, I would expect the resource URL in this particular case to be http://example.com/people/9. (This is the URL given in the linked member of the example compound document below, which also contains the strange author URL.)
Since the relationship itself is already identified by the self member, I don't see what's to be gained by this extra indirection. It seems to merely introduce the ambiguity of making the same resource available at different URLs.
I could see this kind of URL being used for a composition-like relationship, where a resource can't exist independently of its container; however, that's obviously not the case where many articles can have the same author. So, am I missing some important point here, or is this just an unfortunate example?

Relationships are mutable. Related resource URLs (identified by resource) are immutable for the life of a resource. Related resource URLs should always return the current resource(s) in a relationship. This concept was missing in the pre-RC2 spec, but I think it's very useful.
Essentially, related resource URLs are valuable beyond the life of the request. Consider that you may not want to immediately fetch this related resource, or you want to know if it's been updated at a later time.
Now, if you do want the self link to the current related resource, it's because you want to fetch the related resource right now. In that case, simply include it along with your request for the primary resource, and you'll get the related resource (in linked) as well as its self link.

Thanks for explaining! I had somehow missed the sentence in the spec that says the same thing. Okay, now that I know where you're going with this, I can see the benefits of this approach; but still, I'm very skeptical. Here's a more elaborate write-up of my reservations.
In short, I think it:

breaks part of the HTTP layer,
potentially complicates API and client design,
seems to conflict with another part of the JSON API spec,
transfers the wrong state in the wrong representation, and
does all that for too little real value.

Relationships are mutable. Related resource URLs (identified by resource) are immutable for the life of a resource. Related resource URLs should always return the current resource(s) in a relationship.

Hmm. Isn't the point that we're doing REST via HTTP? And aren't we breaking that by invalidating the assumption that the same URL will always identify the same resource? If it doesn't, well, that's what redirect responses are for. Otherwise, I would assume that subsequent 200 OKs will refer to the same resource. Now, we're suddenly adding a layer on top, where id and type in the payload become relevant.
The application might know about this, but I'm wondering about caches along the way. What about conditional requests, ETags and last-modified times? It looks to me like they would become more difficult to use, or even outright broken for these URLs. If I can't tell from the headers which resource a last-modified time applies to, the mechanism breaks. As for ETags, the current RFC is not very specific how these should behave across different resources, but in our case the server needs to generate weak ETags that practically never match for different resources. Not sure though how much this differs from current practices, but my guess is that results will vary. All the while we're still diverging from the HTTP spec, which ties one URL to one resource.
Then, API design. It seems to be up to the individual APIs to decide on the meanings of state-changing requests for these special URLs, and whether to allow them at all. For instance, can I request a DELETE or PUT on http://example.com/article/1/author? If allowed, the client must be prepared to handle conflicts resulting from changed relationships. (Which is special, because usually you can assume you're at least dealing with the same resource.) May the heavens have mercy if these decisions vary from resource to resource: You won't be able to tell what you can do with a related resource URL without looking it up in the spec; the complexity of the API will also inform client design. Speaking of clients: A client must also never be tempted to resolve an object's URL to the one it originally requested its representation from, because if it's a related resource URL, it might not allow all possible actions.
Wait a second... From "Updating Resources":

The URL for a resource can be obtained:

from the self link in the resource object
for a data object, the original URL that was used to GET the document

This seems to apply here?
There's also the link object itself, which is a representation of the relationship. If the relationship changes, so should the representation – which it won't if there are no type and id members present, because the resource member stays the same. If there's also no self URL for the relationship – then why is there none? Because the state of the relationship is implied by the response body of the related resource? In REST terms, this conflates two different resources: the relationship and the related resource, by hiding the state change of the former in the representation of the latter. This is interconnected with the HTTP difficulties mentioned above.
To sum it up, in my opinion we gain too little convenience for too much theoretical and practical confusion in this matter. I think it's better to stick to a clean separation of concerns; the use cases you describe can still be covered:

Consider that you may not want to immediately fetch this related resource, or you want to know if it's been updated at a later time.

Want to check if a resource changed? Hit the canonical resource URL. Want to know the current state of a relationship? Relationship URL. Want to lazy-fetch a related resource? Canonical resource URL. Worried that the relationship changed? If it really matters... who's to say the relationship doesn't change right after you fetch the resource? If that's an issue, you will probably need something better than a magical URL. :) And even if you insisted, I'd argue that your need doesn't merit being elevated to the general case.
What's so bad about doing it this way that makes it worth to incur all the trouble above? Or am I chasing ghosts here? If so, I'd be terribly sorry for making you read all this. Otherwise, I'd suggest to change the spec. Ideally, the concept of immutable related resource URLs should be dropped; as an alternative, I guess they could be suggested for use in exceptional cases, with a strong word of caution as to the potential consequences, and with a fix for any problems with URL resolution.

What about conditional requests, ETags and last-modified times?

Your server can include linkage data in a link object if you want relationship values to factor into your caching scheme.

And aren't we breaking that by invalidating the assumption that the same URL will always identify the same resource?

It depends on what you mean by the "same resource". A relationship's resource URL is identifying the "same resource" in the same way that a resource collection (e.g. /articles) is. Both URLs may return different members at different times.

It seems to be up to the individual APIs to decide on the meanings of state-changing requests for these special URLs, and whether to allow them at all. For instance, can I request a DELETE or PUT on http://example.com/article/1/author?

This is not in the spec.

Or am I chasing ghosts here?

It's funny you say that, because I believe you are chasing the ghost of a concept that was formerly in the spec but is no longer for very good reasons. Namely, you seem to be asking for URLs that completely capture the member(s) of a relationship at a moment in time. This was previously handled for to-many relationships with URLs to multiple individual resources (e.g. /articles/1,2,3). Because of URL length limitations, this format breaks down for large to-many relationships. If you want to request the inclusion of such a link type in a link object, then you'll need to clear these hurdles first.
And if you want to make an argument that JSON API's definition of resource is in violation of HTTP, please reference the HTTP spec and make your case specifically.
Last but not least, please consider that relationships are maintained in a member named links for a good reason.

Namely, you seem to be asking for URLs that completely capture the member(s) of a relationship at a moment in time. This was previously handled for to-many relationships with URLs to multiple individual resources (e.g. /articles/1,2,3).

What? No! I'm glad to see these gone! But it's good you brought up to-many relationships, because it made me take a second look at my ideas for resource URLs like .../tags?filter[article]=1. I realized: to-many relationships are not only more elegantly expressed in a form like /article/1/tags, they are also not problematic. That was a bit of an embarassing oversight, because it changes the balance of good vs. bad; so, thanks for bearing with me until now.
To-one relationships are what I was overly focused on, and I still think that here, as long as related resources have an independent life and URL, permanent resource URLs make things fall apart. I'll try to make my case more carefully.
Basically, while to-many relationships will act like distinct resource collections, to-one relationship resource URLs try to behave like two different resources at once. This makes it difficult to map between resource objects and resource URLs, and can break the association between URL and resource. (More details on my reasoning and possible HTTP breakage below.)
This ambiguity leaks into the spec. The spec states that a related resource URL is:

A string, which represents a URL for the related resource(s) (a "related resource URL"). When fetched, it returns the related resource object(s) as the response's primary data.

[[Resource Relationships]][relationships]
[relationships]: https://github.com/json-api/json-api/blob/fa2b150d0cd6fc450e6e57999ca98da8ca9d6301/format/index.md#resource-relationships-
For example, http://.../article/1/author gets you a resource object that you'd like to treat as a people, because of its type and id. However:

The URL for a resource can be obtained:

from the self link in the resource object
for a data object, the original URL that was used to GET the document

[[Updating Resources]][updating-resources]
[updating-resources]: https://github.com/json-api/json-api/blob/fa2b150d0cd6fc450e6e57999ca98da8ca9d6301/format/index.md#updating-resources-
So, clients are to use the original GET URL as the resource's URL; note also that self links are optional. (What if both conflict?) You can now end up with a people object bound to a relationship-specific URL (.../article/1/author), or in other words, a people object that's not a real people object and can't be used like one. Or can it? How do I go about modifying or deleting its resource? This is now a relevant question.
As an example, imagine a user's profile info was first fetched through the resource URL of an author relationship. It is now in the application cache, keyed by type and id. Having looked at her author profile, the user realizes she needs to update her e-mail address. Given that you determine the resource URL to be .../article/1/author, how do you do that? Is that even safe?
On the other hand, the concept works for to-many relationships. This is what I previously failed to realize. Now I think it would be nice to find a way to make it work for all cases.
It looks to me like the problem could be solved by making self links mandatory for resource objects, or at least mandate that they must be included in these cases, and giving them priority over the original GET URL. It might be wise to make clear that the server should not accept change requests to the related resource URL (which, as you point out, represents a distinct resource after all).
Care should also be taken to implement this properly on the protocol level: HTTP servers should respond with temporary redirects to the proper URL, and HTTP clients should expect to receive and honor redirects (which might or might not be handled automatically and transparently in the implementation environment). This should be pointed out in the spec to create awareness. See the Github API for an example.
Instead, the spec could also recommend using the proper URL for the related resource URL in such cases. (That is, having a mutable related resource URL which will be the permanent URL of the currently related resource.)
Before creating this issue, I tried to find a prior discussion of this topic via issue search; lots of results came up, but I didn't see anything specific to this issue. If you have any relevant pointers in this regard, I'd be glad to do some reading.

Last but not least, please consider that relationships are maintained in a member named links for a good reason.

I don't know what you mean here. I'm all for having these, and keeping them together in a well-named place is a good call. The devil is in the details of creating additional entities that can't decide if they express the state of a related resource or that of a relationship.

Resource Ambiguity and HTTP
As promised, here's a more detailed explanation of why I think permanent related resource URLs that yield the representation of a related resource are inherently broken.

A relationship's resource URL is identifying the "same resource" in the same way that a resource collection (e.g. /articles) is. Both URLs may return different members at different times.

Okay, I originally thought the relationship's resource URL was meant to identify the related resource; you say it identifies a resource in its own right (as it should).
None of these interpretations is correct. In fact, the URL tries to do both simultaneously, fails out of necessity, and creates a confusing jumble of resources in the process.

I tries to identify the related resource, because it returns that resource's representation (resource object), containing its id and type.

It tries to identify a different resource, because this representation changes with the relationship, while the formerly related resource stays the same.

It fails, because it simply CANNOT identify two different resources at once. It cannot identify one resource and yield the representation of a different resource.

This is different from collections, where identity and representation are well defined. In our case, though, we end up with a URL that returns the representation of which resource we can't be exactly sure. This is bad, because it complicates and potentially breaks things.
We're concerned with APIs realized on top of HTTP. That is, they're about querying and changing the state of resources by exchanging their JSON representations through HTTP. This binds us to HTTP's idea what resources are and how they relate to URLs.
HTTP operates on the assumption that a resource is identified by a URL, and that request and response messages will transfer (or refer to) representations of said resource, together with representation metadata (the header fields). This means that URL, representation and metadata in a given message refer to the same resource. See [RFC7231] Sections 2 and 3.
In the response to the related resource URL, I need to send the headers for the correct resource. If I don't know what's the correct resource, how will I do that? For example, should I use Last-modified, ETag [RFC7232] or Expires [RFC7234] values of the person resource, or values which apply to the relationship? These headers are used for caching at various points along the message path and for conditional requests, in order to reduce traffic and server load. So now I cannot use these things? This is why I said that we break part of the HTTP layer.
If you argue that the related resource URL refers to its own special resource (the "same resource" from the quote; let's call it the relationship resource here); and the URL yields this resource's representation, which happens to temporarily coincide with the representation of the currently related resource – then you're still getting in trouble when you try to use that representation as a resource object in the JSON API spec:

Every JSON API resource object is uniquely identified by a combination of its type and id members. [...]
A resource object's type and id pair MUST refer to a single, unique resource.

So, either the resource object of the resource (that you're saying is not the related resource) spuriously self-identifies as the related resource, in which case it cannot be a valid representation of the relationship resource; or we must conclude that the relationship resource is identical to the related resource, which contradicts the original assumption.
I think HTTP redirects could be used to work around such situations. They would allow to preserve the integrity of URL, resource representation and metadata. So, the server should respond with a temporary redirect status code; and this behavior should be documented in the API spec.

@tilboerner I couldn't bring myself to read every word of what you've written here, but I'm just going to comment on the general theme:

Isn't the point that we're doing REST via HTTP? And aren't we breaking that by invalidating the assumption that the same URL will always identify the same resource?

I think you may be conflating HTTP resources with JSON API resources. They are two completely different things, so you cannot read the HTTP spec and equate the word "resource" with what you regard as "resources" in JSON API.
You are quite correct in that an HTTP resource is indeed uniquely identified by a URI, but what is revealed behind that URI does not need to correspond forever to the same JSON API resource(s). In terms of JSON API, resources are just objects that may compose an interrelated system. They may be mutated or moved around at will. There's absolutely no requirement that a given HTTP resource (URI) should always expose the same JSON API resources. Surely you don't demand that http://www.example.com/logo.png must forever serve the very same file. The situation is exactly analogous.
If this doesn't adequately address your concerns, could you perhaps condense your main points into a few paragraphs?

I think you may be conflating HTTP resources with JSON API resources. They are two completely different things

Okay. That clears up a whole lot of confusion. From reading just the JSON API spec, the two concepts seemed to be heavily interwoven, almost identical, and I assumed intent. My mistake.
My concerns:
Mostly evaporated. One is left: In to-one relationships, the spec seems to allow a client to use a related resource URL in places where it probably wants to use a resource's unique URL. Updating Resources states that "for a data object", a resource's URL can be determined as "the original URL that was used to GET the document", with unclear precedence over an optional self link.
Let's say I GET http://example.com/articles/1/author and receive:
{
    "data": {
        "type": "people",
        "id": "9",
        // ... other attributes, no "links"
    }
}

Is this a "data object" in the document? Then I may now conclude that the resource's URL is http://example.com/articles/1/author. I may even ignore a self link to do so. Now I cannot update or delete the resource, even if http://example.com/people/9 would let me. If the relationship changes, what I think is the resource URL of {"type": "people", "id": "9", ...} suddenly produces a resource object with a different type or id.
Is this observation correct? If yes, is this effect intentional? I think not, but if yes... why? Wouldn't it mean that the object from people/9 is de facto not identical to the one in the articles/1/author relationship? Queue more confusion?

One concern is new:

In terms of JSON API, resources are just objects

Does JSON API consider a resource and a resource object to be the same thing, or are they different, but related concepts? Sometimes the terms seem to be used interchangeably, and sometimes in a manner that suggests a difference. For example, the Resource Identification section seems to allow both interpretations.
Whichever it is, it would be helpful if JSON API had clearer, explicit definitions of these concepts, especially when they can be confused with those of the protocol it so heavily leans on.
Is there somewhere I can go and read up on this? Maybe I can come up with a suggestion for improvement. In the future, I'd like to avoid spamming the issue tracker out of ignorance...

Okay. That clears up a whole lot of confusion. From reading just the JSON API spec, the two concepts seemed to be heavily interwoven, almost identical, and I assumed intent.

You're not alone in this. The overlapping terminology is unfortunate, but hopefully this is soon cleared up for everybody.

In to-one relationships, the spec seems to allow a client to use a related resource URL in places where it probably wants to use a resource's unique URL. Updating Resources states that "for a data object", a resource's URL can be determined as "the original URL that was used to GET the document", with unclear precedence over an optional self link.

Good point about precedence, but my take on this is that it's up to the server to decide what it wants to expose where and communicate about URLs accordingly.

Now I cannot update or delete the resource, even if http://example.com/people/9 would let me.

Says who? A server may allow update requests to target http://example.com/articles/1/author, too.
As long as the link remains intact, the two URLs are essentially synonymous. (Of course a server might not support such nested URLs at all; it's not a requirement.)

If the relationship changes, what I think is the resource URL of {"type": "people", "id": "9", ...} suddenly produces a resource object with a different type or id

True, but again the right course of action depends on application intent and semantics.
Want to request person 9? Target /people/9. Want to request the author of article 1 even if the link now points to some other person? Target /articles/1/author.
There's no one right way to go about this; it depends on what it is you want to do.

Wouldn't it mean that the object from people/9 is de facto not identical to the one in the articles/1/author relationship?

If the association between the article and person 9 has been removed, then clearly the URLs no longer are identical. I don't see why this should be surprising or undesirable... On the contrary, it would be highly strange if /articles/1/author continued forever to point to person 9 even if the relationship gets deleted!
Of course, sometimes it might indeed make sense to use a single canonical URI everywhere, and that's perfectly fine. The spec doesn't mandate that a resource member in a link object must point to a nested URL like http://example.com/articles/1/author. An application is free to always point to http://example.com/people/9. In that way, you can sort of establish a one-to-one mapping between JSON API resources and HTTP resources even though they're not strictly the same thing.

Does JSON API consider a resource and a resource object to be the same thing, or are they different, but related concepts?

A resource object is the JSON representation of a resource. The spec defines it as follows:

"Resource objects" appear in a JSON API document to represent primary data and linked resources.

The definition is awkward because, technically, resource objects are currently used to represent relationships too. I'm trying to get the definition changed.

Resource objects" appear in a JSON API document to represent primary data and linked resources.

That definition is slightly inaccurate and should be reworded. I will review your PR @bintoro.

A resource object is the JSON representation of a resource.

Yes.

Want to request person 9? Target /people/9. Want to request the author of article 1 even if the link now points to some other person? Target /articles/1/author.

I would be careful here. General clients can't assume URL structure, which is just a recommendation.
@tilboerner The relationship URL won't be fetched unless a client wants to interact with the relationship. A client that wants the resource should instead fetch the related resource URL, which will return the related resource (the author resource, of type "person", in this case). The related resource object (a "person" in this case) will come complete with a self link which can be used to modify or delete the resource.

I would be careful here. General clients can't assume URL structure, which is just a recommendation.

Absolutely. This is not about URL structure but the fact that you have two URLs that point to the same resource at a point in time but not necessarily forever.
If I understand correctly, at the heart of @tilboerner's dissatisfaction is this:
A generic client who fetches the data at time T has seemingly no way of knowing if, at a later time U, the value it has for links.author.resource will refer to

the person associated with the article now, at time U
the person that was associated when the data was fetched, at time T
both (a permanent association).

This is because, AFAIK, a server is allowed return http://example.com/people/9 as the related URL because supporting "true" related URLs is not mandatory.
Of course, there is a solution. By requesting the related resource in a compound document the client can compare links.author.resource and linked[...].links.self. If they are equal, the client can infer that the "related URL" is in fact a canonical URL instead of being permanently tied to that relationship.
To accomplish the same thing more directly we'd have dedicated keys:
{
  "type": "articles",
  "id": "1",
  "title": "Rails is Omakase",
  "links": {
    "self": "http://example.com/articles/1",
    "author": {
      "self": "http://example.com/articles/1/links/author",
      "href-linked": "http://example.com/articles/1/author",
      "href-canonical": "http://example.com/people/9",
      "type": "people",
      "id": "9"
    }
  }
}

A server that doesn't support true related URLs would set href-linked to null.

That definition is slightly inaccurate and should be reworded. I will review your PR @bintoro.

The definition of resource object is actually not in scope for the 'resource' PR. I want to address that too but am waiting for a word on (hopefully) the ultimate solution, which is to limit the meaning of "resource object" to resources only.

@bintoro:

A generic client that fetches the data at time T has seemingly no way of knowing if, at a later time U, [what] the value it has for links.author.resource will refer to ...

Yes, in a way that's what I'm after; but I think everybody would be better off if a client never had to ask that question, because it only ever interacts with that URL in a relationship context. But as I said, I think you can design a compliant API where it won't, creating the possibility of a nasty bug. This depends on how well the API designer understands the possible interactions in the system.
I think that attributes like href-linked and href-canonical wouldn't help, because the bug would take effect after obtaining a resource object through a GET request, when the origin of the URL is not necessarily known.

As long as the link remains intact, the two URLs are essentially synonymous.

Only if I can make the same requests and get the exact same results. The spec doesn't require that. I wouldn't expect it to be true in the general case, because implementing PUT for related resource URLs generally requires additional complexity (at least on the client side) due to their changeable nature; and accepting DELETE would be madness, except under very specific circumstances.
As far as I can see, a client can end up with a resource object that "behaves" differently from others, by fetching it from a related resource URL and following the spec.

If the association between the article and person 9 has been removed, then clearly the URLs no longer are identical. I don't see why this should be surprising or undesirable...

If a client uses the relationship resource URL as a resource URL, which it is allowed to do, the knowledge of its "relationshippy", time-sensitive nature is lost. You can't know what a client implementation does with this information. For example, and I just realized this: if I understand the point of a "resource URL" correctly, the client would have all reason to assume that it can re-fetch a resource object, whole or in part, from its resource URL and use the result, without verifying type and id, to maybe follow a relationship, or to update a subset of the attributes of a local resource object. It would interact with a different resource without realizing it. This now looks worse than I'd previously thought.
@dgeb

The related resource object (a "person" in this case) will come complete with a self link which can be used to modify or delete the resource.

Not necessarily. The spec makes self links completely optional. API designers must recognize this need by themselves, as they must recognize that self links must supersede GET URLs when determining a resource's URL.
In summary, I think that, due to the openness of the spec, the concept of pemanent related resource URLs exposes the possibility of a major bug. For it to come into effect, there only need to be permanent related resource URLs and an arbitrary detail in how a client determines a resource's URL. It's a matter of opinion if the mere possibility of this constitutes an inherent flaw that makes the spec "broken", or if it is simply one of the details that API and client designers need to deal with.
The time-sensitive nature of this bug, and its dependency on an implementation detail in the client, make it hard to discover, replicate and test for, unless you're already aware it exists. I'm not sure everybody reading the spec will realise it does.  If you want to keep it in the spec in order to retain flexibility, you're pushing this responsibility on the people who design and implement specific APIs.
I'd be happiest if the spec could be changed in a way that eliminates this possibility. Alternatively, people should be made very aware that:

linkable resource objects SHOULD include a self link;
when determining resource URLs, self links SHOULD take precedence over the original GET URL.

This could be a prominent part of the recommendations dealing with relationships.

@tilboerner, I read your comment three times and barely understood a thing. I don't mean to offend, but you seem to be rambling on about some vague doomsday scenario without really articulating what exactly it is.
If a client fetches both URLs to which I referred above as href-linked and href-canonical, it knows where the "relationshippy" resource is and where the specific resource (with the known ID) is. It can perform any operation with no ambiguity at all. What more could the client possibly want?
By all means, let's get to the bottom of this, but no one will be able to address the underlying issue if you don't explain it clearly.
I think the best way forward would be for you to put together a simple step-by-step example of a client-server interaction that illustrates this "major bug" of yours. Then we'd have something concrete to discuss.

Only if I can make the same requests and get the exact same results. The spec doesn't require that. I wouldn't expect it to be true in the general case, because implementing PUT for related resource URLs generally requires additional complexity (at least on the client side) due to their changeable nature; and accepting DELETE would be madness, except under very specific circumstances.

I disagree completely. Consistent behavior across endpoints is what I would expect from a server.
Again, you say things like "additional complexity" and "pure madness" without even attempting to explain your thinking.
In my implementation (albeit just server-side), supporting all methods at every endpoint added zero complexity and didn't feel like pure madness at all. So I have no idea what you're talking about.

Sorry, I thought I'd made clear how I think a client would come to use a related resource URL for a resource URL, and I also thought that everything else would be obvious from that point, given the mutable nature of relationships. Apparently it's not, so I wonder if I'm again misunderstanding something that's very obvious to you. Anyway, here's an...
Example Scenario:
Just the first thing that comes to mind.
Adam (A) co-administrates a blog, but wants to leave for reasons that don't matter. He decides to terminate his account. He conveys his intentions to:
Olga (O), the blog's other administrator, who decides to transfer authorship of Adam's articles to herself, for the sake of this example, or for SEO reasons, or so she can receive messages sent to article authors, whatever.
Here's how it plays out:

Adam uses his client ("client A"). He sees a list of articles, at the top is one of his own:
{
  "type": "articles",
  "id": "13",
  "title": "Rails is Omakase",
  "links": {
    "self": "http://example.com/articles/13",
    "author": {
      "self": "http://example.com/articles/13/links/author",
      "href-linked": "http://example.com/articles/13/author",
      "href-canonical": "http://example.com/people/1",
      "type": "people",
      "id": "1"
    }
  }
}

Adam activates the [about the author] link of this article, because it's the closest thing that'll get him to his own profile.

Client A requests the current author and remembers the URL it used: GET http://example.com/articles/13/author.
(I know, "current author". Maybe on this blog, authors change a lot? This is just an example. All that matters is that a resource object is fetched from a related resource URL, i.e., from href-linked.)

Client A receives
{
    "data": {
        "type": "people",
        "id": "1",
        "name": "Adam",
        "admin": true,
        "links": {
            "self": "http://example.com/people/1"
        }
    }
}

Client A takes the "data object" and associates it with resource URL http://example.com/articles/13/author (it could also cache the object together with the resource URL, but I don't think this scenario needs it). self link or not, the client implementation happens to always use the GET URL in such cases.

Client A displays the people data to Adam in an editable profile.

Adam activates [Delete profile].

Client A makes sure:

that Adam really wants to do this and
whatever else it wants to make sure.

Client O changes the article/13/author relationship to {"type": "people", "id": "2", "name": "Olga", ...}.

Client A sends request to the resource URL of Adam's people object: DELETE /articles/13/author.

Server deletes Olga's account, because Adam is authorized to do so.

Client A receives 204 No Content and indicates success.

Adam deletes his login from his password manager or emigrates to Peru or does whatever he pleases, because it doesn't matter at this point.

This could have been avoided if the client had preferred the self link over the GET URL. This means that, in general, objects that can be part of relationships should always include a self link.
No?

@tilboerner Thank you, that was very explicit. From your prior comment I did get the general gist of it, but I couldn't figure out what the problem was. And I'm afraid I'm going to have to disappoint you: I still don't see what the problem is — as far as JSON API is concerned.
It seems to me you're asking JSON API to prescribe rules for application logic, and that's obviously not in its scope. I mean, it's the client's responsibility to behave in way that is in line with its objectives and intent.
In the example scenario, the client wants to delete Adam's account. Adam's account can be targeted at /people/1, and the client knows it (or at least should know, since the JSON API format provides all the necessary information). Furthermore, that's the only URL that can unequivocally be said to represent Adam's account. I believe this is not in any dispute here.
But, it turns out the client issues a DELETE to /articles/13/author, a URL that points to the author of artice 13, definitely not guaranteed to be Adam.
This is nothing but a programming error in the client. I don't know what else to say. What does this have to do with JSON API?

self link or not, the client implementation happens to always use the GET URL in such cases.

And that's a bug. Why on earth would it do that, when it's clearly not always the right thing to do?

It seems to me you're asking JSON API to prescribe rules for application logic, and that's obviously not in its scope.

Yes. I guess I was trying to say that JSON API, mainly through the permanent related resource link, makes it way too easy for people to shoot themselves in the foot. The spec is seemed to outright suggest it as the first practical thing to do. So I figured that's a problem inherent in some of the choices JSON API makes. But then, as I said two comments above, one can also consider this one of the details implementers need to deal with.
If there's an ultimate grievance, it's the former resource link, now href-linked. For to-one relationships, I find it unnecessary and too problematic; and JSON API doesn't reflect that in a way that makes me happy. ;)
Anyway, the presence (and name) of href-canonical mitigates the problem somewhat, so there's that. As for the walls of text, yeah, I know. :eyes: What can I say, I was figuring out some of JSON API's concepts and intents during this issue, so thanks for helping me with that. :)


Typo in Section <IP_ADDRESS>, pg.105, version 2023-08-15

There is a typo in the exponent of the std in the FIM for the univariate Gaussian in eq. (3.2.34), the bottom-right element of the matrix should be: 2/σ^4 rather than 2/σ^2. See [1].
Also, the determinant right after this equation should be proportional to σ^(-3) rather than σ^2. See [2].
The corrected terms in LaTex are:
[1] $2/\sigma^4$
[2] $\sqrt{\det(\mathbf{F}(\boldsymbol{\theta}))}=\frac{\sqrt{2}}{\sigma^3}$

actually I think we are both wrong.
I think it should be this (assuming 3.62 is correct)


Override default fold and rfold implementations for the iterators

fold and rfold are APIs for internal iteration, which is sometimes more efficient than external iteration (next and next_back). It is always possible to implement internal iteration in terms of external, which is what the default impl does, but this implementation need not be optimal. Flatten (which roaring uses) has more efficient fold and rfold implementations than the default. Roaring should use the implementations from Flatten rather than the default implementations.
Ideally you would implement try_fold and try_rfold as well, but they cannot be implemented until the Try trait is stabilized (https://github.com/rust-lang/rust/issues/84277).
This might apply to other default implementations overridden by Flatten as well.

Hey @oskgo 👋
Thank you for the information and proposal. It is very interesting. Would you mind doing a PR or something at some point? Or is it more like a tracking issue?


Update PMD plugin to latest 2.20.0

https://github.com/gradle/gradle/issues/11581

Updated PMD version from 2.17.0 to 2.20.0
Updated links in documentation
Updated upgrading notes

6.17.0 to 6.20.0, right?


Added action state diagram and a Makefile to build

Motivation and Context
This PR adds plantuml state diagram for action and the means to build it
What has changed
No code has been changed but a Makefile has been added
How to test?
make diagrams
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome diagrams/action-state.svg

Ensure diagrams can be viewed

I get errors when I try do make diagrams
java.io.IOException: Cannot run program "/opt/local/bin/dot": error=2, No such file or directory 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) 	at java.lang.Runtime.exec(Runtime.java:620) 	at net.sourceforge.plantuml.cucadiagram.dot.ProcessRunner$MainThread.startThreads(ProcessRunner.java:163) 	at net.sourceforge.plantuml.cucadiagram.dot.ProcessRunner$MainThread.runJob(ProcessRunner.java:123) 	at net.sourceforge.plantuml.api.TimeoutExecutor$MyThread.run(TimeoutExecutor.java:79) Caused by: java.io.IOException: error=2, No such file or directory 	at java.lang.UNIXProcess.forkAndExec(Native Method) 	at java.lang.UNIXProcess.<init>(UNIXProcess.java:247) 	at java.lang.ProcessImpl.start(ProcessImpl.java:134) 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) 	... 4 more

@tej99 ahhh I didn't realise plantuml had a dependency on graphviz ... if you do 'brew install graphviz' it should work and I'll see if I can update the Makefile to pull it down automatically

Works for me with graphviz installed. But there is more than one way of skinning this. Consider mashing an online viewer into GitHub repo, e.g. http://www.gravizo.com/#howto


On donor website login button remains "Login" even after user logged in

On donor website login button remains "Login" even after user logged in. When user clicks on the button to re-attempt it changes to correct value, that is "Logout".

@manuranga I tried this in Firefox with standard tracking protection preset as you asked and with a custom preset where third-party cookies are blocked, but I couldn't reproduce this issue. Maybe one of your browser extension or a script is causing some interference?
On a related note, I did note that the silent sign in does not work on the standard tracking protection on Firefox since the third party cookies are blocked.


feat: replace Promise.join with promise.all()

Got some code for us? Awesome 🎊!
Please include a description of your change & check your PR against this list, thanks!

[ ] There's a clear use-case for this code change, explained below
[ ] Commit message has a short title & references relevant issues
[ ] The build will pass (run yarn test:all and yarn lint)

We appreciate your contribution!
Also, if you'd be interested in writing code like this for us more regularly, we're hiring:
https://careers.ghost.org/product-engineer-node-js

Why is this change considered an improvement? The docs for Promise.join say "While .all is good for handling a dynamically sized list of uniform promises, Promise.join is much easier (and more performant) to use when you have a fixed amount of discrete promises that you want to coordinate concurrently."
Did you check to see which method performed better?
If the the goal was to use a native Promise method instead of a Bluebird method, Bluebird is still required after this change is made, so there's not much benefit there.

@markstos see #14882 🙂


GHAction for hugo site building: pub  docs@master

What this PR does / why we need it:

Special notes for your reviewer:
Release note:

Mistake


Benchmarks

Hey,
Just stumbled across this project, looks amazing. Really curious to see how it compares against other similar projects like in terms of execution performance (not parse/check):

Knetic/govaluate
google/cel-go

I will do the benchmark later. The interpreter is based on stack, like Java, it may slower than some well designed register-based instructions


Destruction gadget Atm9

Building Gadgets Version
Atm9 (not home to look at the mod version?)
Describe the bug
The destruction gadget is able to destroy players bases that are in claimed chunks on atm9
To Reproduce
Have the 2nd player claim land and have the first player use the gadget to destroy the claimed land. The 2nd player doesn't have to be a ally or on a team for the 1st player to destroy their base
Expected behavior
I expected that this tool wouldn't be allow to destroy players claimed chunks this is very detrimental for servers

I can't duplicate this bug in the latest version of the mod, so it must have been fixed by now :). Let me know if its still happening on the latest version please

This still happens.  We're using FTB Chunks and all tools bypass claims.  Versions of both mods:
FTB Chunks: 2001.2.3
Building Gadgets 2: 1.0.6

Reopened. Will investigate further.

This should be fixed in later versions :)


Add helm lint check

Add helm lint check in bin/linters.sh for ./install/kubernetes/helm/{istio,istio-remote}
Fixs #4766

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mandarjog
Assign the PR to them by writing /assign @mandarjog in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

bin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @ceshihao. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

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

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

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
10375d675bf150f3ca09eea26dbbe1f260668577
link
/test istio-pilot-e2e

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

@ceshihao: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
10375d675bf150f3ca09eea26dbbe1f260668577
link
/test istio-pilot-e2e

prow/e2e-bookInfoTests-v1alpha3.sh
10375d675bf150f3ca09eea26dbbe1f260668577
link
/test e2e-bookInfo-envoyv2-v1alpha3

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

New changes are detected. LGTM label has been removed.

@sdake
rebase on release-8.0


build improvements

Updates CI to run on Node 20 and updates Svelte to 4 (though there are no real differences)
Update rollup versions
Fix svelte accessibility warnings
Use .mjs for rollup config (required since latest version of rollup)

Base is #630, should be merged first


Use env variables for url requests

Serve wis2box-ui from WIS2BOX_URL
Make oapi collection calls to WIS2BOX_API_URL
Make only one request for station history with data older than 30 days

wis2box with
WIS2BOX_API_URL=http://localhost:8999/oapi
WIS2BOX_URL=http://localhost:8999/australia


🎉 4.0.0

ℹ About this release

Version: 4.0.0
Type: major
Last Release: 3.1.1 (6/22/2022, 5:33:03 PM) [?]
Commits to merge: 17 [?]

Build System

Native ESM support (7b86a4f)

⚡ BREAKING CHANGES

Only Support for node.js ^12.20.0 || >=14.13.1

📦 Dependencies

Update simple-git from ^3.7.1 to ^3.10.0

📦 Development Dependencies

Update eslint from ^8.16.0 to ^8.19.0
Update eslint-plugin-jsonc from ^2.3.0 to ^2.3.1

:tada: This PR is included in version 4.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Bug: Weather cells disappear when a polygon is selected.

Steps to reproduce:

Enable Weather
Enable Polygons
Click on a polygon

Expected result:
Weather cells remains visible.
Actual result:
All weather cells disappears.

Thanks for the report, though even with the detailed steps, I'm not able to reproduce myself. Some functionality was recently changed with weather cells though so there certainly could be a bug.

Could you DM me your areas.json file so I can try it and see if something odd is going on with the area?
Can you also check if there are any errors/logs server side?

I'm also unable to replicate this on latest. @AppIe314 are you still seeing this bug?

I confirmed in DM a while back that this is all set.


java.lang.ClassCastException on MvpNullObjectBasePresenter

We have an app with proguard enabled and we had problems with the casting of the MvpView, on MvpNullObjectBasePresenter:
  Class<V> viewClass = (Class<V>) view.getClass().getGenericInterfaces()[0];
  view = NoOp.of(viewClass);

The class that implements MvpView, also implements "SwipeRefreshLayout.OnRefreshListener", which resulted to the ClassCastException (seems that the first generic interface that it got was the OnRefreshListener and not the MvpView, I'm not sure though).
I've added a quick fix which attempts to cast of all the interfaces:
        Type[] types = view.getClass().getGenericInterfaces();
        for (int i = 0; i < types.length; i++) {
            Type type = types[i];
            try {
                Class<V> viewClass = (Class<V>) type;
                view = NoOp.of(viewClass);
                return;
            } catch (ClassCastException cce) {
                continue; // move on to the next interface
            }
        }

Please check if the fix is okay. TIA! :)

I see, thanks for reporting.
Thanks for the workaround. This should work. I will think about another solution this weekend, but by now I don't can think of any better solution than that.

Fixed in version 1.3. I access the generic type of  Presenter to retrieve the view class


Detect attempted synth of entangling gate with empty basis

If the optimization loop in XXDecomposer runs out of options and the supplied basis set of 2q controlled gates is empty, this implies that the unitary to synthesize is entangling, and can't be synthesized.
This PR adds a test to detect this and raise an error.
This PR replaces the (unmerged) PRs #9982 #9984 #9986
See https://github.com/Qiskit/qiskit-terra/issues/9935#issuecomment-1515500629 for a detailed discussion.
EDIT this is still not quite right although it passes all existing tests and another one added in this PR. There is another situation that we currently do not  test for that this PR also can't handle correctly. That will go in another issue.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

3 of 4 (75.0%)  changed or added relevant lines in 1 file are covered.
35 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.002%) to 85.904%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/quantum_info/synthesis/xx_decompose/decomposer.py
3
4
75.0%

Files with Coverage Reduction
New Missed Lines
%

qiskit/transpiler/passes/synthesis/unitary_synthesis.py
1
95.14%

crates/accelerate/src/sabre_swap/layer.rs
4
97.32%

crates/qasm2/src/lex.rs
6
91.65%

crates/qasm2/src/parse.rs
24
96.18%

Totals

Change from base Build<PHONE_NUMBER>:
-0.002%

Covered Lines:
71068

Relevant Lines:
82730

💛  - Coveralls

Superseded by #10008


Open to contribution ?

Hi,
I'm interested in this project. I wonder if this project is open to newcomers, and maybe if we could add a tag, and a section in the readme calling for contributors. I have never contributed to open source, so I don't really know how the things work.
I like how good rust is for tooling, and I'm tired to use mypy/pyright and I want a better type checker. I would love to see the project succeed, and If I may, contribute to it
Thank you all for your work

Hello, and thank you for considering contributing to this project.
This project is completely open source, and anyone can participate in its development, and even small PRs are welcome. However, I think it is difficult to contribute to the core parts of this project at this time for the following reasons.

This project relies heavily on a compiler (more precisely, a type checker) of the Erg programming language. Therefore, to understand the implementation of pylyzer, you also need to understand the implementation of the Erg compiler.
The documentation for this project is currently not very well written. I am thinking of improving it someday, but I don't have much time at the moment.

The documentation for the Erg project is somewhat more developed than that of pylyzer. If you would like to contribute to improving pylyzer, please consider contributing to the Erg project first.

But I will try to think about whether there are any good first issues that newcomers can tackle, such as refactoring or improving documentation.


The already slightly hacky extension loading / matching mechanism has failed because there are now key collisions because several yaml files have a function called count that takes any as the input type, but with different return types.
I had also not been keeping up with the extension changes and we weren't handling a bunch of different extension type signatures.
This whole thing probably needs a rewrite, but I'm not going to do that right now.

I'm merging this in to get things passing

The already slightly hacky extension loading / matching mechanism has failed because there are now key collisions because several yaml files have a function called count that takes any as the input type, but with different return types.

@gforsyth I think this was probably the wrong approach to take, namely including return type in the signature/lookup. According to the docs: "A YAML file may contain one or more functions by the same name. The key used in the function extension declaration to reference a function is a combination of the name of the function along with a list of the required input argument types"
imho what was missing to properly disambiguate between the functions was the file path, rather than a return type. I'm thinking of changing _extension_mapping to be a three-level dict (file name, function name, signature) and function mapping will have to be altered as a consequence to something like this (ideally more succinct than shown here):
IBIS_SUBSTRAIT_OP_MAPPING = {
    "Abs": ("https://github.com/substrait-io/substrait/blob/main/extensions/functions_arithmetic.yaml","abs"),
    "Acos": ("https://github.com/substrait-io/substrait/blob/main/extensions/functions_arithmetic.yaml", "acos"),
    ...

Hey @tokoko -- I agree completely.  This was very much meant as a temporary measure, and I think your proposal is a good one.

Another point I wanted to quickly run by you. I'm also thinking of giving up on impl lookup approach once you narrow it down to a function. The current approach misses some valid impls, while doesn't check others strictly enough, namely the first lookup assumes that all args will be of type any, but actually there are some functions which have some args of type any and other of some concrete type (for example lead). On the other simple any lookups don't check the additional constraints that any types may have (any1, any2 and so on).
In short, I'm thinking of instead adding a method to FunctionEntry class that will take in desired signature and return whether signature is valid for the entry or not. During a function "lookup", we will simply loop through all available impls of a function until at least one of them reports being valid.

I think that sounds fine to me -- some of the current issues with assigning scalar function signatures stem from differences between ibis and substrait about what the output dtype of an function should be (just a question of precision).  I imagine that can be part of the validity checks for a given entry.


Login went wrong. Please try again.

After updating saleor-platform to the new images, I connect with default user/pass on localhost anymore.

The user exists because it used to work in previous versions.
The stdout from the containers don't show anything related to this.
Steps to reproduce:
git clone https://github.com/saleor/saleor-platform.git
cd saleor-platform
docker compose build
docker compose run --rm api python3 manage.py migrate
docker compose run --rm api python3 manage.py populatedb --createsuperuser
docker compose up
navigate to localhost:9000
login with<EMAIL_ADDRESS>

I am facing same issue. graphql url not getting mapped to host

I have deployed on a VM. I have modified env ALLOWED_HOST={vm ip} Other urls works just fine. Dashboard is not working.  Request URL is still mapped to " localhost:8000/graphql "
But if access  "http://{vm_ip}:8000/graphql" , am able to get response from graphql api !

issue persists after latest update

Same here. I tried it with multiple super users and the default credentials on a VM and the host os (Ubuntu 20.04 & 22.04)

Same steps taken reproduces same result on fresh copy using Kali Linux on Raspberry Pi and also in a Kali Linux VM.  What I attempted:
$ docker-compose --rm api python3 manage.py createsuperuser
Starting saleor-platform_db_1     ... done
Starting saleor-platform_redis_1  ... done
Starting saleor-platform_jaeger_1 ... done
Creating saleor-platform_api_run  ... done
2023-07-13 15:12:25,780 WARNING saleor.core.jwt_manager RSA_PRIVATE_KEY is missing. Using temporary key for local development with DEBUG mode. [PID:1:MainThread]
Email<EMAIL_ADDRESS>Password:
Password (again):
Superuser created successfully.

$ docker-compose up

When attempting to log in using the credentials I just created, I receive the same modal, Login went wrong. Please try again.

As I'm currently planning to use some kind of open source e-commerce solution with Next.js, I just recently found out about Saleor, so I still don't exactly know how we're supposed to set the platform or the standalone Docker containers up, but as we seem to be minority, it probably won't be an issue with the platform solution or Saleor itself. 🥲
I tried to setup the platform as described in the readme on WSL as I figured it could be some kind of Django issue with allowed hosts (still figuring that out, I have absolutely no idea how Django works and ofc too busy to read Saleor docs thoroughly), and yeah, it works on localhost.   I can sign in now after ssh tunnelling, so that I can navigate to localhost:9000, rather than using the IP of the host machine.

are you people saying you can sign in to the dashboard via localhost:9000, did you do anything else besides the steps I described above?

I set it up exactly like this (on Ubuntu Windows WSL).
Saleor recommends using
docker compose down --volumes db

to remove the volumes if you have problems with migration. Ofc this will remove all data stored in the databases.
So I'm assuming you are just upgrading rather than freshly installing?

Ammending docker-compose.yml to include the VM machine's IP among the environment's ALLOWED_HOSTS rectified the issue for me.
services:
  api:
    environment:
      - JAEGER_AGENT_HOST=jaeger
      - DASHBOARD_URL=http://localhost:9000
      - ALLOWED_HOSTS=localhost,api,(vm_ip)

Did you change anything besides that in the compose file? I tested all the (possibly) relevant environment variables for many hours now and I always faced a CORS issue.

Adding the VM's IP allowed me to access the dashboard using the IP.  I also added the VM's hostname to the ALLOWED_HOSTS list and was then also able to access using the VM's FQDN.  I also repeated the process on a second machine (physical this time) with the same positive results.  But yes, that was the only line I changed in the docker-compose.yml file.

Hm, interesting. Yeah I also tried every possible configuration (at least regarding the envs), but still neither the ip nor the hostname works. I used docker compose all the time, and now I just figured to use docker-compose which kind of gives slightly different outputs. Didn't fix my problem (still get CORS errors), but I guess it's some problem with my network configuration then. 🥲

I set it up exactly like this (on Ubuntu Windows WSL). Saleor recommends using
docker compose down --volumes db

to remove the volumes if you have problems with migration. Ofc this will remove all data stored in the databases.
So I'm assuming you are just upgrading rather than freshly installing?

This did it for me! If recreating the DB solves the issue, there must be some value in some table somewhere that doesn't get updated when you update to newer docker images.


devicetree: Add DT_PROP_LAST macro

Add macro for getting the last element of an array type property.

@decsny test added.
@bjarki-andreasen changed to UTIL_DEC.


Unable to Withdraw XVG - Narration Error

Has anyone seen the below error before? It occurs when withdrawing XVG.
rpcPostJSON: result:false (message: Narration must be 24 characters or less. )
Any ideas how to fix?

Ended up being a restriction set by the XVG wallet. Modified the code appropriately.


gammastep: add missing wayland-scanner dependency

Description of changes
Fixes Wayland support for gammastep. I've only tested this as far as gammastep -m list now listing wayland.
It's worth noting that this also adds the dependency to redshift (which lacks Wayland support) and on Darwin - I'm not sure if we want to do this or if there should be some extra conditions added.
The support disappeared after 921bd99f8de553bd45be0ed298619589f2b7fee4.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

It doesn't strictly matter that it's added for redshift but ideally yeah it's only added for gammastep.


License

It seems that no license information is included in this repository or I could not find it. Is it possible to specify the code and artwork licenses of Maxit?

Sure.

Added a LICENSE file for the source.

Thanks.

I don't know where I copied the images from.

If I have some time, I can help finding out.

New Images/COPYRIGHT file.
"Maxit does not own the copyrights of the images."
Would you prefer other text?

The text is good. The images are most likely free. Just need to find some sources.

Did you locate the sources?

Silent user. Closing.


[IIIF Upload]: 2 manifests

Choose target collection
iiif-test (1411127)
List IIIF manifests to upload
https://iiif.annemarie-schwarzenbach.ch/presentation/__testing_smallform_00598.json
https://iiif.annemarie-schwarzenbach.ch/presentation/__testing_smallform_00027.json

redo test


issue with editing channeling result

When we edit channeling results (when we use Fortune point e.g.), the computed result is not good. The SL is strangely updated with the CN value if i understood.
I modified the code in dice-wfrp4e.js to avoid editing spell.data.cn.SL and keep in memory the previous data. It seems it works.
L555-585 in the current version
else // Successs - add SL to spell for further use
{
  testResults.description = game.i18n.localize("ROLL.ChannelSuccess")

  // Optional Rule: If SL in extended test is -/+0, counts as -/+1
  if (Number(SL) == 0 && game.settings.get("wfrp4e", "extendedTests"))
    SL = 1;

  // Critical Channel - miscast and set SL gained to CN
  if (testResults.roll % 11 == 0)
  {
    testResults.extra.color_green = true;
    SL = spell.data.cn.value;
    testResults.extra.criticalchannell = game.i18n.localize("ROLL.CritChannel")
    if (!testData.extra.AA)
      miscastCounter++;
  }
}

// Add SL to CN and update actor
SL = spell.data.cn.SL + Number(SL);
if (SL > spell.data.cn.value)
  SL = spell.data.cn.value;
else if ( SL < 0)
  SL = 0;

actor.updateEmbeddedEntity("OwnedItem",
{
  _id: spell._id,
  'data.cn.SL': SL
});

Thanks for this fix! Do you want to submit a PR or just have me include this in the next release?

you can include that in the next release


Update fastapi dependency pins

What does this PR do?
Fixes https://github.com/Lightning-AI/lightning/issues/17106
cc @tchaton

I think this is blocked by https://github.com/gridai/grid/pull/10087


[Star Wars Saga Edition] Critical bugfix for skills

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: <   >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: <   > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: <   > (i.e. Dungeons & Dragons, FATE)

[ ] I have followed the Character Sheets Standards when building this sheet.

[ ] I have authorization from the game's publisher to make this an official sheet on Roll20 with their name attached.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description

Character Sheet Info Roll20 Internal Use only.

@BronsonHall @NorWhal @nmbradley
In my last update, I practically made the sheet unplayable, with none of the skills working... at all. I know you typically go through all of the pull requests at the same time, but would you be willing to approve this pull request as an urgent and critical bugfix?
Thank you.

Thank you so very much!


Re validating when elements becomes visible

I have a large form (60 fields+) that has various fields toggling visible/hidden based on the values of other fields. Currently when a required field becomes visible it doesn't show as being invalid until the control gets a blur event.
I tried adding a 'key' to each input as per https://github.com/baianat/vee-validate/issues/1034 but it didn't solve the problem.
I also tried using the component's updated() method to do a validateAll() but that created an endless loop.
Finally, I can get this to work by creating a method to run validateAll() and setting various input's @change events to fire it, but it's a very manual/hacky solution. I'm sure there's a better way to do this but I can't find info on it.

If the fields have been validated before, they will be automatically validated when the component updates. But if its for the very first time it won't run.
I think you can get what you want by adding the .initial modifier on your elements that have conditional display.

That worked, thank you!


Handling () inside choices with blocks play drum, set intrument to

play drum [(1) Snare Drum] for {0.2} beats; set instrument to [(1) Piano]
( should be escaped.

Can a choice not become a literal?


Problem with encoding or accented characters

I've always had this problem with osdsh/osdctl:
$ osdctl -s 'test'
test
$ osdctl -s 'sermão'
serm
$ osdctl -s 'fácil'
f
$ osdctl -s 'ótimo'
[empty]

So the output always dies off at the accented character and nothing else after it is printed.
(Obviously, the output is displayed as on screen text, not in terminal output.)
I have a Tcl script sending text to osdctl and I can convert the text to other encodings before sending it to osdctl. But none of the encodings work. The output is exactly the same unless I convert the text to ascii, in which case osdctl displays each accented character as '?' instead of printing incomplete output.
There is no mention of encodings in either manual and a google search didn't help either.
Can you please provide some information on that? Is there any encoding that osdsh/osdctl will understand and comply with?

Hi @lucmp!
Thank you for the feedback. However, I believe you're looking for another osdctl: https://manpages.ubuntu.com/manpages/focal/man1/osdctl.1.html
This repo, openshift/osdctl is a different tool than the one you're asking about.


break on local

if it doesn't have docker compose installed first it will break
please add to the installation script.
thank you

Hey there,
RedCloud has been updated with many bugfixes, please give it a try a let me know if it solves the issue.
Cheers,

will check thanks


Minimessage::escapeTags does not work

UP for: https://github.com/KyoriPowered/adventure/issues/998

duplicate of #998


Text Escape Uses Wrong Code For Line Break (\r instead of \n)

Current behavior
Line breaks are getting encoded with \r
How to reproduce it (as minimally and precisely as possible)
Formatted JSON with line breaks, pasted into Text Encoder
Expected behavior
Line breaks should be encoded with \n.
When encoding line breaks on Windows, it should encode with either \r\n or else \n. Not with \r.
The \r is the extraneous carriage return ("r" for carriage r eturn) that MS-DOS had and carried over into Windows, whereas UNIX systems only did line break ("n" for "newline"); for JSON and web etc, Windows apps always handle \n correctly but neither UNIX nor Windows would guarantee a line break with a carriage return ("\r").
Screenshots

Workaround
Copy Output to clipboard, paste into Notepad, find and replace "\r" with "\n".
Affected platforms
Windows
Affected DevToys kind
DevToys (app with GUI)
DevToys Version
1.0.14
Relevant Assets/Logs
No response

Hi,
This issue has been resolved in DevToys 2.0, which is currently in preview: https://devtoys.app/blog/announcing-devtoys-2.0-preview
You can download it here: https://devtoys.app/download
Duplicated with #468


A way to change drag sensitivity/amount

Is there a way to change the drag sensitivity/amount? Currently, I find I have to drag slides a fair amount (30-50% of their width, average image width is 600+ px wide) for the switch to take. If I "flick" the slide a tiny amount (100ish px), the slider doesn't go to the next slide; it bounces back to the current slide. This feels like bad UX to me.
I'd like to be able to "flick" slides and have them progress to the next slide.
Possible in the current code base? Feature request?

You can increase sensitivity with a higher touchThreshold value (eg. touchThreshold: 1000 makes it very sensitive).
From slick carousel's documentation:

To advance slides, the user must swipe a length of (1/touchThreshold) * the width of the slider

After increase sensitivity with a higher touchThreshold value, there is no effects and still very sticky, why?

still happens at the date, touchThreshold has no effect whatsoever


Trail 'GeneaLabs\LaravelPivotEvents\Traits\PivotEventTrait' not found

I just upgraded to Laravel 5.8 but I get the error:
Trait 'GeneaLabs\LaravelPivotEvents\Traits\PivotEventTrait' not found {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\FatalErrorException(code: 1): Trait 'GeneaLabs\\LaravelPivot
Events\\Traits\\PivotEventTrait' not found at vendor/genealabs/laravel-model-caching/src/Traits/Cachable.php:9)

I don't specifically include the PivotEventTrait anywhere in my application, just the Cacheable trait.
Environment

PHP: 7.3
Laravel: 5.8.21
Model Caching: dev-master [0.5.5]

@jvv8 Please provide your entire stack trace. You can find it in /storage/logs/laravel.log.

   Symfony\Component\Debug\Exception\FatalErrorException  : Trait 'GeneaLabs\LaravelPivotEvents\Traits\PivotEventTrait' not found

  at /mnt/disks/home-disk/pricex.ch/vendor/genealabs/laravel-model-caching/src/Traits/Cachable.php:9
     5| trait Cachable
     6| {
     7|     use Caching;
     8|     use ModelCaching;
  >  9|     use PivotEventTrait {
    10|         ModelCaching::newBelongsToMany insteadof PivotEventTrait;
    11|     }
    12| }
    13|

@jvv8 That is not the full stack trace. Take a look at issue #255 for an example.

Oops, looks like I forgot to restart supervisor after upgrading to the latest version.

Good to hear it's working again1 :)


"nan" output when simulating "kuramoto_sivashinsky" data in "higher_dim_example.ipynb"

When simulating the "kuramoto_sivashinsky" data in the example "higher_dim_example.ipynb", the values in the resulting numpy array sim_data are diverging (nan) for timesteps larger than ~ 620.

Contents of environment .yml file in a .txt file, created via conda env export > dunc_env.yml (.yml files are not allowed here):
dunc_env.txt

Unable to reproduce the bug so far. Please open a python interpreter and post your numpy configuration here, i.e. the output of the following two commands:
import numpy
numpy.show_config()

Here the output of :
import numpy
numpy.show_config()

(with activated rc_env environment)
output:
blas_mkl_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\lib', 'C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\include']
blas_opt_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\lib', 'C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\include']
lapack_mkl_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\lib', 'C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\include']
lapack_opt_info:
    libraries = ['mkl_rt']
    library_dirs = ['C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\include', 'C:\\Program Files (x86)\\IntelSWTools\\compilers_and_libraries_2019.0.117\\windows\\mkl\\lib', 'C:/Users/Dennis/anaconda3/envs/rc_env\\Library\\include']

The backend seems fine, so that's probably not it.
One possible solution could be that your python uses 32 instead of 64 bit floats for whatever reason. Please post the output of:
import sys
sys.float_info

Besides this, your numpy installation might just be bugged. Please run:
import numpy
numpy.test("full")

and post its output here.

The output of:
import sys
sys.float_info

yields:
sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, radix=2, rounds=1)

The output of:
import numpy
numpy.test("full", verbose = 2)

yields:

After installing the package pytest in the rc_env via conda install -c anaconda pytest the numpy test could be performed by running:
import numpy
numpy.test(label='full', verbose=2)

The result of the numpy test was:

Interestingly in the first line of the output it says platform win32 -- Python 3.7.5, pytest-6.1.1, py-1.9.0, pluggy-0.13.1, hinting to a 32 bit platform.

On the other hand, if I run the python code:
import sys
is_64bits = sys.maxsize > 2**32
print(is_64bits)

it prints True, hinting at a 64 bit environment.

Furthermore the output to conda info also shows a win-64 platform.

All the code was run within the active rc_env environment. It seems like numpy "thinks" the platform is 32 bit, eventhough it is 64bit ?

In the last snipped it says the python version is 3.8.8, even though the numpy test uses 3.7.5 as we want it to be? With the conda environment active, please run a simple
python --version

Also please save the first 1000 rows of the sim data you calculated here:

via numpy.save() and send them to me as well.

python --version yields the correct version:

Apperently the python version stated within the output of the conda info command is referring to the base python version, and thus is independent of the python version in the currently active environment. See: https://stackoverflow.com/questions/56848462/what-is-the-difference-between-the-python-version-stated-in-conda-info-and-that


Bug in macOS : can't implement the embed setting globally

Since updating to the latest version of the plugin, Obsidian on my Mac can no longer render the list-embed style (even with global setting turned on in the style-settings plugin) without adding the list-embed syntax.

can you share a gif or screenshot? although i must confess, it will be difficult on my end as i don't have any mac os.


GROOVY-8589 bugfix: should not show error about missing mandatory args when --help or --version is specified

GROOVY-8589 bugfix: should not show error about missing mandatory args when --help or --version is specified
The second commit in this PR is to upgrade to picocli 3.0.1.
This allows us to remove some code since the parent command name is now automatically included in the usage help for subcommands.

See also https://github.com/remkop/picocli/releases/tag/v3.0.1 for more details.


Why is "patrol drive" removed in patrol test we cant able to get the logs which makes it difficult to debug ?

I was not able see the app logs in console when running patrol test if build fails it was just showing a message
Console output when executing patrol test:
No device specified, using the first one (4552035f)
• Building apk with entrypoint app_test.dart...
✓ Completed building apk with entrypoint app_test.dart (18.8s)
• Executing tests of apk with entrypoint app_test.dart on device 4552035f...

        FAILURE: Build failed with an exception.

        * What went wrong:
        Execution failed for task ':app:connectedDebugAndroidTest'.
        > There were failing tests. See the report at: file:///Users/kameshadadadi/Documents/GitHub/front-end/vestigas_app/build/app/reports/androidTests/connected/index.html

        * Try:
        > Run with --stacktrace option to get the stack trace.
        > Run with --info or --debug option to get more log output.
        > Run with --scan to get full insights.

        * Get more help at https://help.gradle.org

        BUILD FAILED in 1m 49s
✗ Failed to execute tests of apk with entrypoint app_test.dart on device 4552035f (Gradle test execution failed with code 1) (109.8s)
Exception: Gradle test execution failed with code 1
See the logs above to learn what happened. Also consider running with --verbose. If the logs still aren't useful, then it's a bug – please report it.
 FAIL  app_test.dart on 4552035f

To Reproduce
Steps to reproduce the behavior:

Go to write tests for app
Execute the command patrol test
See the results it wont show any logs

Can we have an extra arg like show-logs=true
So if someone need the logs he can send set this arg to true.
Device information

Device: Realme RMX1805

OS version: Android 9

Does it also both on physical and virtual devices? No

Additional information

Flutter 3.7.0 • channel stable • https://github.com/flutter/flutter.git
Framework • revision b06b8b2710 (3 weeks ago) • 2023-01-23 16:55:55 -0800
Engine • revision b24591ed32
Tools • Dart 2.19.0 • DevTools 2.20.1

patrol: ^1.0.0

patrol_cli v1.0.0

Please use flutter logs as a temporary workaround to view logs made in Dart.
We're aware of the issue and it'll be fixed.


Cannot get process details

I have managed to get the process list and RAM/CPU usage estimates. However, after clicking the process name, I get the following error message:
Error while data fetch http://localhost:5000/Process/6504/threadSizes: SyntaxError: Unexpected token < in JSON at position 0

No process info is displayed.

The reason could be one of the following:

The process is not CLR one;
The user, under which server-side is running, hasn't got necessary privileges.

Please, be sure that you are clicking on a CLR-process. Simple CLR-application could be found here. Just unzip archive and run w3wp.exe. Please, let me know, if information is shown about CLR-process.

The reason could be one of the following:

The process is not CLR one;
The user, under which server-side is running, hasn't got necessary privileges.

Please, be sure that you are clicking on a CLR-process. Simple CLR-application could be found here. Just unzip archive and run w3wp.exe. Please, let me know, if information is shown about CLR-process.

@ishatalkin Yes, I get the full process data (including stack traces) for w3wp.exe and ProcInsp.exe. On the other hand, the MOM.exe and CCC.exe processes are also listed by tasklist /m "mscor*" but fail to show anything meaningful except the same error message. The WmiPrvSE.exe shows neither the error message nor the process info.

@ishatalkin Yes, I get the full process data (including stack traces) for w3wp.exe and ProcInsp.exe. On the other hand, the MOM.exe and CCC.exe processes are also listed by tasklist /m "mscor*" but fail to show anything meaningful except the same error message. The WmiPrvSE.exe shows neither the error message nor the process info.

The other problem may be the difference between target architecture of ProcInsp and process under inspection. This is the limitation of ProcInsp.
I'll add user-friendly error message, which will describe, why information is not gathered.
Is that right that I cannot get any info for a native x86 process (compiled from C/C++ etc.)?
For such a process you can get only overall info (such as CPU and RAM usage), but you can't drill down to thread list.

The other problem may be the difference between target architecture of ProcInsp and process under inspection. This is the limitation of ProcInsp.
I'll add user-friendly error message, which will describe, why information is not gathered.
Is that right that I cannot get any info for a native x86 process (compiled from C/C++ etc.)?
For such a process you can get only overall info (such as CPU and RAM usage), but you can't drill down to thread list.

@ishatalkin Ok, thank you.

@ishatalkin Ok, thank you.

@vtereshkov , I added user friendly error messages. Please, try version 1.1.0.
For non CLR processes ProcInsp retrieves thread IDs with their status and start time. Such information as callstack or thread exception is not collected.

@vtereshkov , I added user friendly error messages. Please, try version 1.1.0.
For non CLR processes ProcInsp retrieves thread IDs with their status and start time. Such information as callstack or thread exception is not collected.


Bugfix/#493

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Details

8 of 220 (3.64%)  changed or added relevant lines in 4 files are covered.
12 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-2.3%) to 89.605%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/samples/SlowEOS/Program.cs
0
26
0.0%

src/samples/SlowEOS/SlowOnBadParseEos.cs
0
93
0.0%

src/samples/SlowEOS/SlowOnBadParseEosReducedPrecedences.cs
0
93
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/sly/parser/parser/ParseError.cs
12
12.5%

Totals

Change from base Build<PHONE_NUMBER>2:
-2.3%

Covered Lines:
6335

Relevant Lines:
7015

💛  - Coveralls


docker image workflow update

Description:
This PR makes it so dependency updates for specified Docker images in this project are updated regularly with PR containing useful information and CHANGELOG.md content.

Example Job Run for Java, NodeJS, and Splunk Fluentd Update job: https://github.com/jvoravong/splunk-otel-collector-chart/actions/runs/7107861229
Example of Java Update PR: https://github.com/jvoravong/splunk-otel-collector-chart/pull/139


[Bug]

What happened?
Shells disappear when changing dimensions, not sure whether it's when you enter a new one, or leave it.
Update: I believe the shells disappear due to the fact that all pigs stand up when I unload the chunk, causing the storage unit to lose power.
Update #2: Problem solved, by force loading the chunk, storage units do not lose power, thus the shells continue living.
The solution I suggest you add is maybe allowing more time without power before the shells die, or maybe have them chunk load themselves.
Version
sync-mc1.18-3.1
Minecraft Version
fabric-loader-0.12.12-1.18.1
Fabric API Version
fabric-api-0.45.0+1.18
Installation Source
CurseForge
Logs
Was unable to find the log for the exact time, it was in a singleplayer world but I can't find the correct one as it doesn't seem to exist. Sorry for the inconvenience.

Other Mods

**Tested without any external mods, issue does not persist.**

Mods included in test above are:

 - cloth-config-6.1.48-fabric
 - fabric-api-0.45.0+1.18
 - sync-mc1.18-3.1

 [Mods In Singleplayer world when issue occured]

**

> Chest Cavity
> Architectury
> Cloth Config
> Health Overlay
> Icarus
> Mining Dimensions Fabric
> Mod Menu
> Mostructures
> MouseTweaks
> Quartz Elevator
> REI
> Smart Recipes
> Sodium fabric [alpha build] <---- (Maybe a cause??)
> Trinkets
> WTHIT
> Xaeros Minimap, and Worldmap

**

Additional Information
No response

There's a config option that does exactly what you want - shellStorageMaxUnpoweredLifespan. You can change it manually in the config file (./config/sync.json), or via ModMenu.
Let me know, which value solves the issue, and I may set it as default one.

I'm closing this one, because this is not really an issue, it's just how things work - if a shell container loses power, its shell will die.
Treadmills are not a reliable power source, they are meant to be fun, no more, no less. Like, I would not entrust production of energy for cooling a nuclear reactor or for a life support system to a pig running on a treadmill. If you want to deal with well known vanilla mechanics like chunk loading/unloading, it's up to you, but the mod itself has nothing to do with this.
If you will find a value for the shellStorageMaxUnpoweredLifespan property, that will make things reliable, please, let me know, because I may set it as default one. Otherwise, you still have a redstone block and power sources from tech mods as an option.


Added uses statements to module-info.java

Currently, the beans validation API is failing at runtime for me when I attempt to use it with the Java Module System. The runtime complains that the beans validation module-info does not contain a "uses" clause.
To fix this, please add the following to module-info.java:
uses jakarta.validation.spi.BootstrapState;
uses jakarta.validation.spi.ConfigurationState;
uses jakarta.validation.spi.ValidationProvider;

I have tried this on my machine, and it works.
Thank you.

Resolved via #173