deCONZ: Hue dimmers are not shown with their name but with their id

Home Assistant release with the issue:
0.81.4
Last working Home Assistant release (if known):
n/a
Operating environment (Hass.io/Docker/Windows/etc.):
Docker
Component/platform:
deCONZ
Description of problem:
deCONZ provides the lights, switches, and groups configured in the Phoscon web app. The Hue Dimming Switches do not show up with their configured name but only with their internal product name in hass.
Example:
RWL021 3 instead of Dimmer Küche
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
deconz:
  host: !secret DECONZ_HOST
  port: !secret DECONZ_PORT

Traceback (if applicable):
The data that deCONZ gives about the dimmer switch:
"5": {
    "config": {
      "battery": 100,
      "group": "1410",
      "on": true,
      "reachable": true
    },
    "ep": 2,
    "etag": "2e30cda9db138931d4cc5f7920123546",
    "manufacturername": "Philips",
    "mode": 1,
    "modelid": "RWL021",
    "name": "Dimmer Sofa",
    "state": {
      "buttonevent": null,
      "lastupdated": "none"
    },
    "swversion": "<IP_ADDRESS>46",
    "type": "ZHASwitch",
    "uniqueid": "BLA"
  },

Additional information:

I don't understand. Where does this happen?

Compare the homepage of Hass with the deCONZ settings page.

Ok. That's a light group, not a hue dimmer

Can you help me understand the difference? RWL021 is the internal name of a Hue dimming switch AFAIK. The name of the corresponding group I created is called "Abstellraum", for example.

Each remote has got a light group automatically created. You will see it in the front page of phoscon. This is usually the group you use when you want a remote to control lights directly. It is listed under groups in deconz rest api

Closing this since it is working as intended.


Term enrichment, possible bug?

Having some trouble with the term enrichment service on https://amigo.geneontology.org/amigo. Leaving all defaults as is (biological process; Homo sapiens) and entering a list of UniProtKB accessions or gene names, after submitting I get an error message:
"Error parsing request, no input specified"
Not that the specific list matters, but here's what I used:
O15287
O15350
O15527
O43543
O76064
O94782
O95243
P07992
P12956
P13010
P16104
P16455
P18074
P19447
P23025
P24522
P25490
P28340
P28715
P38398
P39748
P43246
P46736
P49917
P51587
P52701
P54132
P63146
P78527
Q01831
Q03468
Q06609
Q13216
Q13315
Q13330
Q13535
Q13620
Q13888
Q14191
Q15004
Q16531
Q49AN0
Q5FWF4
Q68E01
Q6PIW4
Q6UWZ7
Q7L7L0
Q7Z2Z1
Q86UA6
Q8IYW5
Q92466
Q92547
Q92698
Q92889
Q96AH0
Q96B01
Q96EB6
Q96K76
Q96RL1
Q96T60
Q99502
Q99504
Q9BQ15
Q9BXW9
Q9H040
Q9H9F9
Q9H9Q4
Q9NRY2
Q9NS91
Q9NWV8
Q9NX61
Q9NXR7
Q9NZJ0
Q9UBZ9
Q9ULG1
Q9Y253

@nataled Sorry that you've run into trouble here. I'm going to loop in some of the PANTHER developers, who created, run, and maintain GO's enrichment tool. (Tagging @mugitty and @dustine32.)
I'm also going to pop this over to the general GO Helpdesk tracker.
Looking at your issue, my first instinct was that the identifiers you were using were ambiguous (e.g. Q9Y253 symbol UniProtKB:Q9Y253 known identifier), but after trying a "fixed" input set, I've not been able to get any results from PANTHER--it just spins. Hopefully somebody from the PANTHER side can get a better idea of what's going on.


Permission error in the cache directory.

Hi,
Because $HOME is not writeable in my environment,
mim install mmengine

returns Permission Error.
PermissionError: [Errno 13] Permission denied: '/pjmhome/.cache'

How can I change the cache directory?
Thank you.

It was resolved by changing DEFAULT_CACHE_DIR and installing from source using pip.
https://github.com/open-mmlab/mim/blob/main/mim/utils/default.py#L54


[CRITICAL] Audio recording stuck in a loop, blocking customers from using the plugin

After deploying the plugin, the audio is stuck in a loop and doesn't get past the "estimated wait time" message. Customers are unable to make a callback or voicemail request selection.

I'm also having this issue.

Hi @bethfraser, that was actually my intuition as I've briefly looked into this. We've come up with an interim solution to get an older version of this plugin up and running for customers. I'll be curious to hear if you learn more about the TwiML + Send to Flex issue.

I was able to work around the looping issue by replacing the Hold music URL's in queue-menu.protected.js to another URL.
//gather.play(domain + '/assets/guitar_music.mp3');
gather.play('http://com.twilio.music.guitars.s3.amazonaws.com/Pitx_-_Long_Winter.mp3');

Looks like there is a problem with the Guitar music file, swapping it out worked for me too @strogzy

This has been addressed by #10 , with some amazing cleanup PR to follow from @ktalebian . 🎉


I am not able to setup in my mac M1 . I have flutter 3 version. Plzz help me. I am getting a lot of errors

                      ^

: Error: Required named parameter 'minScrollExtent' must be provided.
scroll_metrics.dart:202
return FixedScrollMetrics(
^
: Context: Found this candidate, but the arguments don't match.
scroll_metrics.dart:142
FixedScrollMetrics({
^^^^^^^^^^^^^^^^^^
: Error: The method 'toMap' isn't defined for the class 'AxisDirection'.
scroll_metrics.dart:218

'AxisDirection' is from 'package:flutter/src/painting/basic_types.dart' ('../../../sdks/flutter/packages/flutter/lib/src/painting/basic_types.dart').
basic_types.dart:1
Try correcting the name to the name of an existing method, or defining a method named 'toMap'.
'axisDirection': axisDirection.toMap(),
^^^^^
: Error: Enums can't be instantiated.
scroll_metrics.dart:229
axisDirection: AxisDirection.fromMap(map['axisDirection'] as Map<String,dynamic>),
                             ^^^^^^^

: Error: Required named parameter 'minScrollExtent' must be provided.
scroll_metrics.dart:224
return FixedScrollMetrics(
^
: Context: Found this candidate, but the arguments don't match.
scroll_metrics.dart:142
FixedScrollMetrics({

Hello @amanat-2003!
Please try with the latest Flutter 3.19.0 • channel stable • https://github.com/flutter/flutter.git.
And don't forget to run the commandsudo softwareupdate --install-rosetta --agree-to-license in your terminal according to Flutter documentation.
All works well for me.


emeritus bentheelder

I haven't had time to be suitably active in this repo like I should be as a reviewer / approver.

/retest


Make sure closed event always fires, even if stream already closed

In an effort to cope with #280 and #228 I'm watching for the closed event to be fired before taking my next action and found that sometimes the file was already closed or the stream wasn't open and thus no closed event was being fired. In these cases the closed event should fire acknowledging that the state of the stream is, in fact, closed.

This seems reasonable. I'm a bit out of pocket the rest of the month (moving from California to NYC), but I'll try to take a look on my trip :100:

Any chance this might eventually land, or is more work needed?

Howdy! Thank you for your contribution. This PR is against the<EMAIL_ADDRESS>release line. Since<EMAIL_ADDRESS>is now out we are only accepting major bug fixes. This looks like a reasonable enough bug fix to land on the 2.x branch.

I'm glad that your back 'in pocket' after your move. Would you happen to know if this is fixed in the winston@3 line?
If this will land in the 2.x line, then I'll try to resolve the conflicts.

@cjbarth it should since the entire infrastructure around Transports is now also a stream. If you see this in the 3.0.0 release line please let us know – we'd consider it a bug.


Supporting Parameter Store

What problem are you facing?

How could Official AWS Provider help solve your problem?

I'm closing this issue because not enough information was provided about what the request was.


Either $ref resolution doesn't work, or $id is ignored.

Wetzel version: Whatever it is in git right now.
OS: Windows 10
Node: 16.13.1
Given the following two schemas placed in a subdirectory named schemas:
schemas\a.json:
{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "$id": "http://example.com/schema/schema_a",
    "title": "schema a",
    "type": "object",
    "properties": {
        "something": { "type": "string" }
    }
}

schemas\b.json:
{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "$id": "http://example.com/schema/schema_b",
    "$ref": "http://example.com/schema/schema_a",
    "title": "schema b",
    "description": "schema a with an additional property",
    "type": "object",
    "properties": {
        "something_else": { "type": "string" }
    }
}

When I run:
node bin\wetzel.js -p schemas -i "[\"a.json\"]" schemas\b.json

Wetzel fails with:
Error: Unable to find $ref http://example.com/schema/schema_a
    at replaceRef (C:\...\wetzel\lib\replaceRef.js:54:19)

Why isn't it loading a.json and how do I make it find the references? Is my understanding of the -i option incorrect?
I tried hand-wavily adding -s schemas as well, but the result was the same.
Thanks!

Couple new points:

The following setup also does not work:

Change a.json's id to "$id": "http://example.com/schema/a.json"
Change b.json's id to "$id": "http://example.com/schema/b.json"
Change b.json's ref to "$ref": "http://example.com/schema/a.json"

Neither does this:

Keep a.json's id as "$id": "http://example.com/schema/schema_a"
Keep b.json's id as "$id": "http://example.com/schema/schema_b"
Change b.json's ref to "$ref": "schema_a"

The following setup does work:

Change b.json's ref to "$ref": "a.json"
The ids are irrelevant.

(Note: Neither -p nor -s are relevant here.)
In other words, the only working scenario is if the $ref is relative and matches the local filename, and the $ids are ignored.
This is very much not correct resolution behavior.
From 8.2.1 (emphasis mine):

The absolute-URI also serves as the base URI for relative URI-references in keywords within the schema resource, in accordance with RFC 3986 section 5.1.1 [RFC3986] regarding base URIs embedded in content.

And 9.1.1 echoes this:

Unless the "$id" keyword described in an earlier section is present in the root schema, this base URI SHOULD be considered the canonical URI of the schema document's root schema resource.

Also, from 9.1.2 (emphasis mine):

The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, and the URIs that identify them.
...
Implementations SHOULD be able to associate arbitrary URIs with an arbitrary schema and/or automatically associate a schema's "$id"-given URI, depending on the trust that the validator has in the schema. Such URIs and schemas can be supplied to an implementation prior to processing instances, or may be noted within a schema document as it is processed, producing associations as shown in appendix A.

Furthermore, from 9.2 (emphasis mine):

Schemas can be identified by any URI that has been given to them, including a JSON Pointer or their URI given directly by "$id". In all cases, dereferencing a "$ref" reference involves first resolving its value as a URI reference against the current base URI per RFC 3986 [RFC3986].
If the resulting URI identifies a schema within the current document, or within another schema document that has been made available to the implementation, then that schema SHOULD be used automatically.

In other words, resolution (for local files) is supposed to work like this:

If there is an $id, that's the canonical URI, otherwise the local file URI is the canonical URI. This canonical URI is also the base URI.
When $ref is encountered, if it's relative, then it is resolved to an absolute URI using the base URI.
The schema whose canonical URI is the resolved $ref URI is used, regardless of what the canonical URI actually is -- i.e. not necessarily related to the local filename.

And the implication is that the documents must be loaded first, before $ref'ed schemas are resolved (or at least, in an appropriate order, circular refs notwithstanding), so that the canonical URIs can be determined and mapped to the appropriate local files.
This means, then, that:

The original example should have worked.
Case 1 above should have worked.
Case 2 above should have worked.
Case 3 above should not have worked ("$ref": "a.json" does not identify the URI of that file, which is in fact schema_a despite the filename).

So either Wetzel is doing something wrong on the resolution end, or it's just plain ignoring $id. Not sure, but whatever it is, it's clearly not compliant.

So either Wetzel is doing something wrong on the resolution end, or it's just plain ignoring $id. Not sure, but whatever it is, it appears to be non-compliant.

It's both. As far as I know, the $id is not accessed anywhere in the codebase of wetzel at all, and even if it was, it would certainly not be used for any sort of resolution.
I cannot point my finger at "the" reason. And I agree that we could consider to make wetzel more compliant to the specification in this regard. But some aspects to keep in mind:

It's complicated.
The quoted statements like "implementations SHOULD understand ahead of time which schemas they will be using" and "Implementations SHOULD be able to associate arbitrary URIs with an arbitrary schema and/or automatically associate a schema's "$id"-given URI" would still leave me with the question: "What do 'understand' or 'associate' mean here, exactly, on the implementation level?".
Schemas are usually not published at the ID path.
The overly naive way of phrasing this is " http://example.com/schema/a.json yields a 404, so why should that work, exactly?". In order to actually work and be resolvable, each schema has to be associated with a "base URI" from where 'ref' schemas actually can be resolved. And this base URI can basically never be obtained from the $id anyhow.
Things change rapidly and arbitrarily
Wetzel was started with JSON schema draft-03 or draft-04, and many things have changed (or been clarified) in the meantime. There have been considerable changes in the mechanisms behind $id and $ref even between draft 2019-09 and draft 2020-12 (and this makes you wonder whether there will ever be a 'JSON Schema 1.0.0 (final)' ...). Keeping up with the subtle changes between these drafts is challenging.

These points may appear to be a bit shallow and handwaving. But maybe some background is relevant here: wetzel was mainly intended for generating the property reference for the glTF schema. The glTF schema uses IDs like "$id": "accessor.schema.json". So there wasn't so much effort put into implementing a 'JSON schema spec compliant resolution mechanism'. The focus is that it should "Work In Practice®". And at this point, the most important use case is that a $ref contains a file name (like in your "Case 3"), and this is resolved against whatever that file is supposed to refer to.
It may not be perfect in terms of spec compliance. But it works for glTF and other schemas.
An aside: In the refactored state that I pointed to in another issue, I tried to at least carry along some information about the 'base URI' together with the schema. This 'base URI' still consists of a 'directory name' in the current state, but at least, there is a structure for carrying that sort of information, which could either be derived from the $id or from the local file name. While still faaar from being perfect, it might be possible to come closer to the spec based on this state - see SchemaEntry.

So either Wetzel is doing something wrong on the resolution end, or it's just plain ignoring $id. Not sure, but whatever it is, it appears to be non-compliant.

It's both. As far as I know, the $id is not accessed anywhere in the codebase of wetzel at all, and even if it was, it would certainly not be used for any sort of resolution.
I cannot point my finger at "the" reason. And I agree that we could consider to make wetzel more compliant to the specification in this regard. But some aspects to keep in mind:

It's complicated.
The quoted statements like "implementations SHOULD understand ahead of time which schemas they will be using" and "Implementations SHOULD be able to associate arbitrary URIs with an arbitrary schema and/or automatically associate a schema's "$id"-given URI" would still leave me with the question: "What do 'understand' or 'associate' mean here, exactly, on the implementation level?".

I believe you are overthinking it :). The meaning is straightforward and sensible: Ahead of time = before resolving $ref references; understand = know what schemas are available already (e.g. Wetzel's -i option), associate = have the ability to look up an available schema given its canonical URI.
In fact, it's essentially the same set of informational requirements that would be needed to enable handling of circular references, except it would also include this information from some explicit list of available schemas (like -i) in addition to the schema-of-interest.

Schemas are usually not published at the ID path.
The overly naive way of phrasing this is " http://example.com/schema/a.json yields a 404, so why should that work, exactly?". In order to actually work and be resolvable, each schema has to be associated with a "base URI" from where 'ref' schemas actually can be resolved. And this base URI can basically never be obtained from the $id anyhow.

I believe this is the source of your uncertainty. The spec is very explicit about this matter:
From 8.2.1 (emphasis mine):

The "$id" keyword identifies a schema resource with its canonical [RFC6596] URI.
Note that this URI is an identifier and not necessarily a network locator. In the case of a network-addressable URL, a schema need not be downloadable from its canonical URI.

From 8.2.3 regarding resolution of references (emphasis mine):

The resolved URI produced by these keywords is not necessarily a network locator, only an identifier. A schema need not be downloadable from the address if it is a network-addressable URL, and implementations SHOULD NOT assume they should perform a network operation when they encounter a network-addressable URI.

Therefore the premise of the question, "if retrieving a URL indicated by the $id yields a 404 then why should it work?", is not valid: no attempt to access a URL indicated by the $id should ever have been made. That aside, the answer is: because the spec is very clear that the $id defines the canonical URI and that schemas should be identifiable by said URI.
I am not sure which draft made that explicitly clear but it would've been around draft 7. Draft 4 is where the role of ID was clarified and the idea of a "resolution scope" was introduced. The resolution scope was never linked to the retrieval URL; clarification on the "network operation" point was added later, but the intent was there in 04.
Note also these are URIs, not URLs, after all. The difference is that a URI (uniform resource identifier) names a resource without necessarily giving it a location, while a URL (uniform resource locator) provides a path to obtain the resource.
As an aside, I think the most confusing bit is that it's just become almost ubiquitous to use the "http" scheme in arbitrary URIs, and so examples become misleading. Personally, I think that they should've registered e.g. a "schema" URI scheme and stuck with that. It's for that reason that I actually prefer to use "xri" for identifiers where possible rather than "http". In fact, I may make a proposal along those lines, or to at least switch some of the examples over to a different scheme.

Things change rapidly and arbitrarily
Wetzel was started with JSON schema draft-03 or draft-04, and many things have changed (or been clarified) in the meantime. There have been considerable changes in the mechanisms behind $id and $ref even between draft 2019-09 and draft 2020-12 (and this makes you wonder whether there will ever be a 'JSON Schema 1.0.0 (final)' ...). Keeping up with the subtle changes between these drafts is challenging.

100%. I understand that challenge, and the work put into Wetzel so far is definitely recognized (and very appreciated)!
However, the specification and behavior of "id" has been present since draft-03 and the basic definition "id identifies the schema, ref uses those ids in resolution" has never changed:

Draft-03: https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-03#section-5.27
Draft-04: https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04#section-7.2

Change: Clarified role of id, introduced idea of "resolution scope".
Note also that 7.2.3 adds that implementations MUST support canonical dereferencing.

Draft-05: https://datatracker.ietf.org/doc/html/draft-wright-json-schema-00#section-8.2

Change: Defined id in terms of RFC3986 rather than re-describing the RFC.
Change: Allow id's for subschemas as well.
Change: Disallow non-empty fragment in root schema id.
Note that 8.2.1 explicitly states that:

"schemas can be identified by any URI that has been given to them ... including a JSON Pointer or their URI given directly by 'id'."
"tools SHOULD take note of the URIs that schemas, including subschemas, provide for themselves using 'id'"

Draft-06:

Change: Renamed "id" to "$id".

Draft-07: https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-01#section-8.3

Removed the vaguely defined distinction between internal and external references (8.2.1 from draft-05) and replaced with language much closer to the current draft version.
The new language strongly implies that a network operation shouldn't be performed on a schema's canonical URI unless a schema with that URI wasn't otherwise made available to the implementation (i.e. when resolving a ref first check the resolution scope, and if you don't have something matching that URI, then try to treat the resolved reference URI as a URL and fetch the schema).
I.e. the language change took the completely mysterious "external" vs "internal" reference and at least vaguely suggested a heuristic to determine the difference (if an available schema has the URI, it's internal, otherwise, it's external).

Draft-2019-09: https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-02#section-8.2.2

Change: Added a lot of clarification around the initial base URI, and tried to improve "$id" related language in general.
Change: Became more explicit about disallowing fragments in root schema URIs.

Draft-2020-12: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-01#section-8.2

Change: More clarification of canonical URI language.

So, really, the modern behavior dates back to draft-04 or draft-05 (depending on what was taken to be implied in 04).
In other words, $id has always been supposed to identify a schema, and schemas have always been required to be addressable by their $id.

These points may appear to be a bit shallow and handwaving. But maybe some background is relevant here: wetzel was mainly intended for generating the property reference for the glTF schema. The glTF schema uses IDs like "$id": "accessor.schema.json". So there wasn't so much effort put into implementing a 'JSON schema spec compliant resolution mechanism'. The focus is that it should "Work In Practice®". And at this point, the most important use case is that a $ref contains a file name (like in your "Case 3"), and this is resolved against whatever that file is supposed to refer to.

And that would normally be totally fine, except (and this is a lot of the motivation behind my post) that json-schema.org includes Wetzel in its documentation generator implementation list. Additionally, it states:

Wetzel: Generates Markdown and AsciiDoc. With some limitations, supports draft-3, draft-4, draft-7, and 2020-12.

Of course "some limitations" is completely reasonable, but schema IDs are a fundamental feature of JSON Schema. In my opinion, having a lack of ID support is somewhat (granted this is an exaggeration) like saying "Wetzel supports all versions of the spec, with some limitations" where "some limitations" includes inability to parse JSON. :)
IDs are in fact so fundamental the "identifier" is listed as one of the primitive keyword categories. Described in 7.4 as:

Identifiers define URIs for a schema, or affect how such URIs are resolved in references (Section 8.2.3), or both. The Core vocabulary defined in this document defines several identifying keywords, most notably "$id".

So e.g. in the Wetzel readme: "Currently it accepts JSON Schema drafts 3, 4, 7, and 2020-12" could be seen as misleading: Since it's missing a fundamental feature, it could be compellingly argued that it doesn't accept any of those drafts, even "with limitations".
To be clear, my intent isn't to dish out negative criticism. What I mean is: Wetzel can obviously do whatever you want it or need it to do, but I strongly feel that if it's not going to be given some more compliant behavior, then it at least ought to be removed from json-schema.org's front page given its current level of compliance.

It may not be perfect in terms of spec compliance. But it works for glTF and other schemas.
An aside: In the refactored state that I pointed to in another issue, I tried to at least carry along some information about the 'base URI' together with the schema. This 'base URI' still consists of a 'directory name' in the current state, but at least, there is a structure for carrying that sort of information, which could either be derived from the $id or from the local file name. While still faaar from being perfect, it might be possible to come closer to the spec based on this state - see SchemaEntry.

That's definitely helpful. Essentially, the following URIs are defined:

Retrieval URI (a URL): The actual location of the document, be it remote or on the local file system.
Base URI: The base URI for URI resolution.

For the root schema if $id is present, then its $id resolved against the retrieval URI (which is significant if $id is not absolute). If $id isn't present then it's just the retrieval URI (btw, 2020-12 <IP_ADDRESS> recommends all root schemas to contain an $id, with an absolute URI no less, although historically that wasn't always recommended).
For a subschema with a $id, the subschema's base URI is its $id resolved against the parent schema's base URI. Note that subschemas with an explicit $id should then be treated as separate schema documents (i.e. also added to the implementation's URI -> available schema mapping).

Canonical URI: The URI that must be recognized as referring to this schema in all references. Its value is the final value of a given schema's base URI.

And resolution is performed by:

Resolve a given reference URI to an absolute URI using the current context's base URI.
Look up the associated schema in the map of available canonical URIs (and of course handle fragments as paths into those schemas here).
And finally: Technically just a suggestion -- If no schema with the given canonical URI is available, and the URI happens to be some addressable URL (e.g. file, http), then treat it as an external reference and attempt to retrieve the schema (with appropriate security considerations of course).

Much of the above is actually defined in the URI RFC.
Also note that the specific basic case of ...

No $id in root schema
Root schema lives on filesystem (or even remotely)
Refs use the relative path to the schema filename (including the filename alone)

... still works fine under the full resolution scheme, as all reference URIs would resolve to absolute URIs in the filesystem since root schema base URIs are their retrieval URIs when no $id is specified.

glTF
As for glTF, those schemas are technically non-compliant with the current draft.
In particular, note that <IP_ADDRESS> specifically calls for all root schema documents to not only contain an $id, but one that is itself an absolute URI:

The root schema of a JSON Schema document SHOULD contain an "$id" keyword with an absolute-URI [RFC3986] (containing a scheme, but no fragment).

Not only is that technically recommended, but in practice it becomes imp-ortant in complex environments: If the glTF schema exists on a system with many other schemas and applications, then it is important for the glTF schemas to have absolute identifiers -- that is, those schemas can be referenced by IDs that do not depend on their location. There are many reasons for this that I won't go into since this is pretty long already. Also, in addition to location-independence, absolute URIs also of course provide namespacing.
 This request would be entirely justified and theoretically easy to implement; but it would not be possible given Wetzel's compliance level. In other words, the glTF schema in its current form works with Wetzel and whatever; if it works it works. Otoh, the glTF schema will always remain in a form that coincides with Wetzel's limitations, because it would be silly to break a working system. Put another way, if you were to say "the primary motivation to update Wetzel is to keep up with glTF schema support", that equates to not being a motivation to update Wetzel, as the glTF schema is unlikely to change in a way that would require Wetzel to be updated (the path of least resistance is to just force glTF into Wetzel-compliant form).

Anyways... the TL;DR is that IDs are pretty fundamental and have been in the spec for a while, and even though Wetzel + glTF can work together without them, it would greatly improve Wetzel's usability outside of glTF and the most basic schemas.

Open questions in current JSON Schema Spec
So, I left this out of the above, but there actually is a relevant point in the current draft that seems completely underspecified to me, and that is this unassuming little paragraph in 9.2 (Dereferencing) (emphasis mine):

Schemas can be identified by any URI that has been given to them, including a JSON Pointer or their URI given directly by "$id".

It is entirely unclear what leads to a URI being "given to" a schema. In particular: If a root schema has a canonical URI defined by $id, does its retrieval URI remain in the list of URIs that were "given to" that schema?
The answer to that has direct impact on whether or not my "case 3" example should or shouldn't work: If a schema document contains an $id that is not equal to, say, its filesystem name, should that schema still be identifiable by its file name in addition to its canonical URI?
Clarity on this could be fairly important in deciding what (if any) changes to make to Wetzel. However, the draft at least also notes up in 9.1.2:

A schema MAY (and likely will) have multiple URIs, but there is no way for a URI to identify more than one schema. When multiple schemas try to identify as the same URI, validators SHOULD raise an error condition.

So, as far as implementations are concerned, I suppose that if an implementation has the architecture necessary to support many-to-one mappings of  URIs to schemas, then implementing whatever "given to" turns out to mean would ultimately become trivial. On the bright side.... heh.
I will request clarification on that point and let you know if I find anything out.

And I thought that my issue comments were long 😌

Maybe you are overthinking it :). The meaning is straightforward and sensible

I might be overthinging this, but I have seen too many effects of 'underthinking', and this may just be a countermeasure. If you think that you can implement "The Right Solution®", then feel free to open a pull request. As long as the updated state is still generating the same output for glTF, the repository maintainers will probably be willing to merge it.
But if you try, just a word of warning:

know what schemas are available already (e.g. Wetzel's -i option),

The -i option is totally unrelated to the question which schemas are 'known'. Its sole purpose is to not include these schemas (i.e. their types) in the 'Table Of Contents'. The -s option might be closer related to that: It contains a 'search path'. But ... it's difficult (and you will have a hard time convincing me otherwise). There is a DRAFT PR at https://github.com/CesiumGS/wetzel/pull/71 for supporting multiple search paths, but this raises a bunch of questions (most obviously, how to deal with ambiguities, related to the fact that the $id is not really used as an 'ID' in wetzel...)

Therefore the premise of the question, "if retrieving a URL indicated by the $id yields a 404 then why should it work?", is not valid:
....
for example, from a map of the canonical URIs of a user-provided list of additional schemas [potentially falling back on an actual filesystem/network request, more on that below])

I'm roughly (!) aware of some of these caveats. I occasionally looked at https://json-schema.org/understanding-json-schema/structuring.html , which explains some of these concepts on a slightly less formal way than the specs that you linked to (but I won't claim to have thoroughly understood all that, and admit that I did not read the technical version of the specs and all the RFCs that are necessary to really understand that).
My (somewhat shallow) understanding seems to be in line with what you said in a more profound and elaborate form. Roughly:

The $id is not really 'the place where the schema file can be found'

Most important implication: The $id can not be used as a basis for resolving $refs

The $id might be used as a real identifier in wetzel (i.e. actually the key of a dictionary for something = dictionary[schema.$id]), because it should be unique

Caveat 1: It isn't. There may be two schemas that define the same ID
Caveat 2: There may be a $ref that does not use an ID, but a filename.

So this still leaves the question open about where and how exactly a $ref should be resolved. What is the actual URI for resolving a $ref? Yes, implementations SHOULD 'know' that....
const baseUrl = MagicalUrlFairy.whereAreWe();

but doing that in a 'spec-compliant' way that works in all cases that are covered by the spec, and (!) in all cases that appear in the real world can be difficult. Imagine you find a real-world schema that contains a $ref like
"$ref": "example.json"

You could argue that this is wrong, and it should use a proper ID (and that's correct). But that's not what's happening. So where, exactly, is the example.json schema file? That depends on where you found the schema that contains this $ref, and in the case of wetzel, this may have been found in one of the 'search paths' that have been given at the command line...
An aside: All this does not yet address the issue of fragments in $refs. Covering the cases of
"$ref": "#example"
"$ref": "#/definitions/example"
"$ref": "foo.schema.json#/definitions/example"
"$ref": "https://example.com/foo#/definitions/example"

is not entirely trivial. (Some related code is in some branch, but again: This is faaar from perfect - it just 'worked for me', as far as I needed it...)

You seem to read the specs on a more detailed level than I do. So maybe I can throw in that random question here, which I carved out as some sort of "quiz". Consider the following schema:
{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "$id": "base.schema.json",
    "title": "Base",
    "type": "object",

    "definitions": {
        "example": {
            "type": "string"
        }
    },

    "additionalProperties": {
        "$ref": "#/definitions/example"
    }

}

It defines definitions/example to be of type string.
Now consider this one, "extending" it (even though there is no real 'inheritance' going on) :
{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "$id": "extended.schema.json",
    "title": "Extended",
    "type": "object",
    "$ref": "base.schema.json",

    "definitions": {
        "example": {
            "type": "number"
        }
    },

    "additionalProperties": {
        "$ref": "#/definitions/example"
    }
}

It defines definitions/example to be of type number.
Question 1: What type may the additional properties have so that they conform to the second schema?

string
number

Question 2: Are you sure about your answer to question 1.?

Still, the specification and behavior of "id" has been present since draft-03

I have read this 'change log', but admittedly, I will not read through each link. But a big 👍 for that nevertheless, because I might take a closer look at the links when this becomes immediately relevant for my work, and in any case, it is a useful overview (maybe for the case that someone wants to support multiple draft versions).
To summarize it, subjectively: The id/$id (sic!) was always present, but important details have changed considerably (or at least, been clarified) throughout the draft versions. If somebody was supposed to implement something like wetzel from scratch, 'on a green field', it would be far easier to look at the latest spec and follow it diligently. Or to directly address the bottom line:

In other words, $id has always been supposed to identify a schema, and schemas have always been required to be addressable by their $id.

This has never been followed in glTF, and it was never implemented in wetzel.

Of course "some limitations" is completely reasonable, but schema IDs are a fundamental feature of JSON Schema.
...
To be clear, my intent isn't to dish out negative criticism or make demands. What I mean is: Wetzel can obviously do whatever you want it or need it to do, but I strongly feel that if it's not going to be given some more compliant behavior, then it at least ought to be removed from json-schema.org's front page given its current level of compliance.

That's all fine for me. I'm also only a user of wetzel. It does what it was intended for, but there are many aspects of the JSON schema that it did never handle correctly, and many aspects that it did never handle at all (roughly: because it wasn't necessary for glTF).
Or to put it that way: Wetzel MUST SHOULD be improved in many ways.

That's definitely helpful. Essentially, the following URIs are defined:
...
And resolution is performed by:
...

I went through some of these steps/approaches while I tried to use wetzel for a more complex schema. I originally tried to do these changes incrementally, in a somewhat backward-compatible way. But at some point, I had to 'burn some bridges', because the necessary changes completely changed the original implementation, and of course, the refactored state is still far from perfect, and vastly different from something that one could do when...

implementing it this from scratch
implementing it only for the latest schema version
implementing it under the assumption that all inputs perfectly follow the specs

I also considered to use the $id for actual lookups (i.e. as a real identifier), but considering that this is not sufficient for actually resolving a $ref, one still has to carry along the "actual base URL" together with the $id (i.e. one of the "search paths").  Some of that is addressed in the SchemaRepository of the refactored state, but not in a deeply spec-compliant way.

Incidentally, AJV's loadSchema callback ...

I occasionally looked at AJV. It is a project with ~11000 stars, ~2600 commits, ~150 releases, billion-dollar companies as sponsors, 180 contributors, (and still, 169 open issues and 29 pending pull requests). It's an entirely different category of project than wetzel. One may find some "inspiration" there, in terms of spec-compliant handling of details like $id and $ref. But carving out the relevant parts (and translating them to JavaScript) does not seem to be a reasonable approach - and even if someone did that: If the result was something that couldn't re-generate the glTF spec, verbatim, then it would be moot...

As for glTF, those schemas are technically non-compliant with the current draft.
...

 It is a valid point, so why not. The fact that glTF and wetzel are somewhat "coupled" should not prevent changes improvements on either side. But even when the $id in glTF are changed: This will not immediately affect wetzel. As I said: The $id is not used at all right now, so any way of taking it into account would require a considerable refactoring.

I used to be self-conscious about my long comments, but now it's just 🤷♂, haha. I actually edited it down.
Anyways, I will 100% read your reply and address what I can; at the moment I accidentally went down a bit of a rabbit hole. You might be interested in the active conversations at https://github.com/orgs/json-schema-org/discussions/197.

I skimmed over that thread, but may have to re-read it (and some of the spec references mentioned here and there) to get a clearer picture.
A very high-level recommendation seems to be: "Rely on the $id (and sort out the "retrieval" independently of that)".
That certainly could simplify some structures and the implementation tremendously (sorting out actual responsibilities of code paths - divide et impera). And as I mentioned above: I tried that, to some extent - essentially, to populate the SchemaRepository from the refactored state, and then only use the $id for lookups in this repository.
But (with a bit of handwaving: ) given the lack of 'proper' IDs in real schemas, and the existing lookup mechanisms in wetzel, and the difficulties of sorting out and carrying along actual 'retrieval URIs', possible ambiguities for definitions, and (of course, the blanket excuse: ) a lack of time, I ended up with the state that is not ideal (as it only uses a real URL instead of the $id for lookups), but worked for my purposes...


Jekyll enters infinite regenerate loop when using JAPR

I added JAPR to my project and it works fine generating a single JS and CSS file.
However, if I'm in Jekyll watch mode, the first change I do to any page, layout, include, etc. triggers an infinite loop regenerating everything. Does that work for anyone currently?
I'm using jekyll 2.5.2.

did you manage to find a fix for this?

No, I found no work-around...

+1


Add the changelog for the v1.1.0-rc.0 release

What this PR does / why we need it:
Add the changelog for the v1.1.0-rc.0 release. The release is tentatively planned for today, October 26th.
Does this PR introduce a user-facing change?:
NONE

/assign @kron4eg
/hold
for discussion

/hold cancel

/hold

/hold cancel
addressed the review

/retest


tailscale: 1.46.0 -> 1.46.1

Description of changes
Changelog: https://github.com/tailscale/tailscale/releases/tag/v1.46.1
Diff: https://github.com/tailscale/tailscale/compare/v1.46.0...v1.46.1
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.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

[ ] Fits CONTRIBUTING.md.

Note
Per #245769 and patch notes, v1.46.1 should resolve crashes on arm64-linux (with Apple M* processors afaict). If you have this hardware, please build and test this version. Build may still fail on darwin.

If you have this hardware, please build and test this version

Tested, reporting working.


Investigate os.scandir for initial file crawling

os.scandir is a fast directory iterator that avoids stat() syscalls
https://peps.python.org/pep-0471/
b2t currently uses iglob
https://github.com/childmindresearch/bids2table/blob/c3f4c12d97eb7bfb8f18da8ce4150ec3a2348493/bids2table/extractors/bids.py#L45
Not sure what performance improvements are realistic to see here, but this random benchmark shows >10x, so it might be worth investigating
https://dev.to/guionardo/fast-folder-iteration-in-python-3g1f

Thanks for the pointer. I looked into it and it seems iglob uses scandir under the hood. I also did a quick test comparing recursive scandir (as in the blog) with glob and they performed roughly similar. Closing for now but we may revisit this in the future.


Support for copy & paste

The tcell library seems to have added support for pasting into the terminal. We should investigate of copy&paste can now be supported and add it to termdash.
https://github.com/gdamore/tcell/blob/master/CHANGESv2.adoc
Related to #254 and #220.

hey @mum4k , looks like its fixed. Works fine with integrated terminal of intellij + zsh

Thank you for reporting that this works in this terminal type @aomerk. Interestingly enough, this still doesn't seem to work for me on MacOS with iTerm. I can paste, but I cannot select any text to copy. Since I don't really understand why, it may be worthwhile keeping this issue open until we investigate it.
Could you explicitly confirm if you were able to also copy some text from a running Termdash app? If so, which widget did it work on? My failed attempts were when I was trying to copy some content from the Text widget.


Add pull request template

Add a pull request template for our repository so that we can standardize the pull request information.
Following this instruction to create a pull request template.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Close this request as current pull request does not work well on a forked branch.


Support for React-Native

Clear and concise description of the problem
Re.Pack supports MF V1, for V2 supports we need adjust how containers are loaded in React-Native environment.
Suggested solution

create separate loadScript and createScript handlers for React Native environment in @module-federation/sdk
disable auto preload since it only supports browser env atm - related PR: #2741

Alternative

auto preload can be disabled through loaded-first strategy and that can come from Re.Pack's own runtime plugin

Additional context
Related Re.Pack issue: https://github.com/callstack/repack/issues/518
Related Re.Pack PR: https://github.com/callstack/repack/pull/674
Validations

[X] Read the Contributing Guidelines.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

hey i don't sure why it depends on the disable autoPreload . And i support the shareStrategy option , which you can config in runtime/build configuration , maybe this can satisfy your need ?

hey i don't sure why it depends on the disable autoPreload . And i support the shareStrategy option , which you can config in runtime/build configuration , maybe this can satisfy your need ?

hey, shareStrategy is definitely sufficient for this exact purpose, I've been using it in the POC ever since it was implemented and it works as expected 👍
As to why it's necessary: RN startup is complicated - we need to have eager access to react and react-native packages there, but at the same time we want to share them with other federated modules. When it's set to version-first, I think both of these dependencies were set to Promises and this caused Errors in RN env since we need to have sync startup.

@jbroma can you add some more flavor to this one since we had the week working on it.


Option to preserve frame order

For animations, it would be useful to have the option to preserve the frame order in the spritesheet. For example, it would start at frame 0, then frame 1 would be to the right of that, frame 2 would be next, and so on.
In fact... It might be nice if this was actually the default ordering for all sprites, if all the sprites are detected to be the same size.
This would be really good for my less programming-inclined users who aren't capable of parsing the spritesheet data, and it would also be nice to have a little more organized spritesheets.
(By the way, just downloaded the new version, and the animation support looks like it's going to be really cool when it's finished!)

same problem

in this case you should probably use something like imagemagick to pack your spritesheets then, since you don't care about optimizations at all.

No need to shut people down like that. In cases where all sprites are the same size and no trimming is desired, there are no optimizations to be had anyway.

I'm not shutting anyone down. It's just that the main purpose of the software is to pack sprites in an optimized manner.


Set up automatic deploys on merge to main

9/10 times this is what we want, and it's easy to forget.

This has been done on ugc-site-dev


Workaround for Groovy bug

There is a Groovy bug (https://issues.apache.org/jira/browse/GROOVY-6286) which is causing us problems. Basically if a top level class has a static method name that is exactly the same as an inner class, the code will fail. Would it be possible to add alternative method names to Hystrix setter calls as a workaround for this? Obviously Groovy should fix this issue but it seems like it's been a problem for a long time.
Code like this fails:
HystrixThreadPoolProperties.Setter()
Maybe something like this as an alternative method invocation:
HystrixThreadPoolProperties.setterInstance()
This is a problem for HystrixThreadPoolProperties and HystrixCommandProperties. Maybe other places as well.

Just to be clear on what you're proposing, it would be the addition of new methods (like HystrixCommandProperties.defaultSetter().  Then your Groovy code could choose to invoke those new methods and existing applications using Hystrix would be unaffected?

Yeah that seems like the responsible choice if you were willing to add other methods for us. Just having a wrapper method which just turns around and calls the other would be perfect for us.
I'm curious if the Setter() method using a capital letter is a particular style at Netflix? Pretty uncommon to see capitalized method names which must be why this issue with Groovy isn't a bigger deal.

That code style is not a standard, I'm not sure why that naming approach was chosen.
Can you take a look at #968 to make sure that's what you had in mind?


Update remark

Hi folks! 👋
Thanks for using remark. I saw it was a bit outdated though and wanted to help you upgrade.
When upgrading, I found that three rules from remark-preset-lint-recommended were turned off, but when I left them turned on, they didn’t warn. Let me know if I should turn the following off again:

list-item-bullet-indent
no-shortcut-reference-link
no-undefined-references

Let me know if you have questions.
Bye!

@wooorm thanks! <3 remark, I started on some custom rules a while back for our docs, hope to get them done whenever I find time :(


How to properly handle ephemeral state in state channels

I've added a test here https://github.com/zoedberg/rgb-integration-tests/tree/ln_transfers that reproduces an issue we encountered on our LN node (run cargo test --test transfers ln_htlc_transfer).
In the test we try to simulate the creation of a commitment TX and of an HTLC TX spending a vout of the commitment. In this case RGB fails to find inputs when calling the contract_assignments_for method. I assume this is because we haven't consumed the fascia. But AFAIR it would be incorrect to consume the fascia of a commitment TX that hasn't been broadcast and might never be. Therefore I'm not sure how we should address this, I normally call contract_assignments_for to obtain the Opout and PersistedState needed to call the add_input method of the TransitionBuilder.
Just a note: to mimic the behavior of LN we had to add some custom methods to create and color a PSBT, this code is mostly copied from RGB repos so we expect it to be correct. We will extend these methods to make also some complex validation tests but for now it should be sufficient to demonstrate the problem.

Yes, you can't prepare a new state transition since transition builder uses stash, and you do not add ephemeral state on off chain transactions in the channel to the stash.
The proper way is to add them to the stash via consuming fascia, since otherwise in cases of uncooperative channel closing you will lose funds and won't be able to create a penalty transaction. Yes, this means that stash (and also contract state cache and index) will accumulate growing ephemeral historical state - but that was the part of the design from the very begging, and the stash is made to be capable of doing that.
In other words, the same way you keep and accumulate all signatures for the off chain channel transaction - the same way you have to accumulate fascia in the stash.

The proper way is to add them to the stash via consuming fascia, since otherwise in cases of uncooperative channel closing you will lose funds and won't be able to create a penalty transaction. Yes, this means that stash (and also contract state cache and index) will accumulate growing ephemeral historical state - but that was the part of the design from the very begging, and the stash is made to be capable of doing that.

Initially we were consuming the bundles (that are now inside the fascia) but then after some updates we encountered some problems and on telegram (https://t.me/c/1793511697/1041) you said:

So the LN node keeps all the state transitions + anchors (bundles) in its own persistence storage (alongside corresponding signatures) for commitment and htlc transactions never giving them to RGB. Once the channel get closed LN node constructs proper new state transition for a closing or penalty transaction - or uses the most recent bundles from commitment+htlc transactions (in case of unilateral closing) and sends them to RGB ONCE per channel existence.

Anyway, we added a test to the ln_transfers branch, ln_transfers_consume, which consumes the fascia. With this we are able to create the HTLC TX but then we fail to consume the fascia of a later commitment TX that goes back to a previous channel state (simulating an HTLC aborted).

Both is true:

The stash (+index, +constract state) is designed to keep the excessive, ephemeral state or state with transactions which are lately excluded from blockchain due to re-orgs and so (my answer here)
We can deterministically generate state transitions matching previous state (in case of uncooperative closure) so adding them to the stash is not needed in theory (my reply in Telegram)

The problem is that (a) there is no API to do the (2), and (b) designing it represent an immense amount of work.
The only downside of (1) is that it will grow the size of the stash over the time (with channel operations), which can be avoided in case of (2). However, I propose to postpone implementation of (2) for v0.12, since it may require a lot of refactoring and API breaks once again.

Yes, I consider inability to consume following fascia is a bug. It is much easier to fix that comparing to creating builders operating on not just stash but also some additional ephemeral data

Ok so you're going to provide a fix for this before releasing final 0.11, do I get it correctly? Thanks

Yes, I will work on the fix. I might discover that it is impossible to fix and easier to refactor the builder. But let's see.

The test fails with the error IndexInconsistency(DistinctBundleWitness { bundle_id: BundleId(Array<32>(76b5c47778af7458b03d3a3de704edde172d85e1f1a4b4ffd340e12126619700)), present: Bitcoin(Array<32>(1b594eed0455aa65cc0e5effad92a2802efc8ff9d41aa89dfc7ad55c1a5c386e)), expected: Bitcoin(Array<32>(58248091bab4e09fcc7f91d0ae31f537e8fe0b21677a01f2fc91be38a9690404)) })
Basically this happens since existing HTLCs doesn't update their state transitions with new deterministically-generated salts, which results in the fact they have the same RGB state transition bundles and their id, now trying to bind them to a different witness.
The proper way of fixing the problem is to re-generate a new bundle for each HTLCs upon the channel update. Is that possible? Since otherwise I need to remove this safety measure which may reduce off chain wallet security...

Normally, if you have a state transition, it must be associated only with one witness bitcoin transaction committing to it. This checks prevents replacing one associations with other.
If you replace it, you won't be able to "go back" and restore funds in case of uncooperative closing.

Normally, if you have a state transition, it must be associated only with one witness bitcoin transaction committing to it. This checks prevents replacing one associations with other.

This seems an implementation issue more than a protocol/security issue. Maybe we could store bundles together with the witnesses (e.g. the map key would be (BundleId, WitnessId)) so that we can allow bundles to be associated to more than one witness bitcoin transaction?

If you replace it, you won't be able to "go back" and restore funds in case of uncooperative closing.

By saving RGB amounts for each state update (and assuming a static blinding or deterministic one) I think we can recreate the RGB data that would be necessary on uncooperative closing. So IMO this should not be a concern.
Moreover in this way we could avoid consuming every fascia (or store them somewhere else for later consume), making the disk space needed for every channel update smaller. But this would require a way to extract the Opout and PersistedState from the commitment TX in order to construct the HTLC TX without calling contract_assignments_for, which to me seems the best solution to the problems we've shown via the tests.

Yes, this is an implementation issue. I have stated above: while it is possibly to deterministically re-create all RGB-related channel information, it would require a significant work on the rgb-std side, which can/should be postponed to v0.12. In other words: even this is an implementation issue, it requires a lot of re-implementation work.
So instead we can utilize the ability of the stash to consume all the shit and save our time in v0.11:

Both is true:
The stash (+index, +constract state) is designed to keep the excessive, ephemeral state or state with transactions which are lately excluded from blockchain due to re-orgs and so (my answer here)
We can deterministically generate state transitions matching previous state (in case of uncooperative closure) so adding them to the stash is not needed in theory (my reply in Telegram)
The problem is that (a) there is no API to do the (2), and (b) designing it represent an immense amount of work.
The only downside of (1) is that it will grow the size of the stash over the time (with channel operations), which can be avoided in case of (2). However, I propose to postpone implementation of (2) for v0.12, since it may require a lot of refactoring and API breaks once again.

Does anybody read what I write here?

Anyway I have discovered that we need to allow multiple witness transactions for the same bundle, so I will work on that in v.0.11 and you will be able to consume all the fascia for a lightning channel updates: https://github.com/RGB-WG/rgb-std/issues/247
Later I will work on new APIs able to "color" PSBTs from fascia without their consumption into a stash. Maybe I will get it into v0.11, but this will be a low priority and maybe it will get into v0.12

So, with https://github.com/RGB-WG/rgb-std/issues/247 merged the proper way of handling ephemeral state in the state channels for v0.11 is the following:

Write a custom WitnessResolver which will report WitnessOrd::Archived for all transactions related to all past channel states (since we haven't made new transaction, this means for all off chain channel transactions) and call stock.update_witnesses providing that resolver. This is required in order for the stash to see only state from the funding transaction as an unspent state and properly prepare new commitment transaction.

First for commitment transaction, and than for each HTLC transaction:

2.1. Before calling psbt.push_rgb_transition in https://github.com/zoedberg/rgb-integration-tests/blob/0b36bbb286fd8e8758ab58e85e9ac51c1d6c0042/tests/utils/helpers.rs#L1121 call transition.set_nonce, using nonce value 0xFE for the commitment transitions and 0xFF for HTLCs. This will ensure that state from HTLCs are ordered after state from the commitment.
2.2. Consume fascias from all PSBTs for each channel transaction on each of the channel state updates. This will allow to keep the past state necessary for non-cooperative closes
In v0.12 I will work on adding API for using information from fascia alongside stash to generate consignment, which will make  steps 1 and 2.2 unnecessary and will save storage space.

I'm not sure about the need of WitnessResolver, since the current resolver already returns WitnessOrd::Archived for all offchain TXs.
Anyway I confirm the DistinctBundleWitness error doesn't arise anymore (as expected since the error has been completely removed to support bundles with multiple witness TXs).
It seems though there's still a similar issue:
RGB was provided with an updated operation using different witness transaction. This may happen for instance when some ephemeral state (like a commitment or HTLC transactions in the lightning channels) is added to the stash.
This error means the software uses RGB stash in an invalid way and has business logic bug which has to be fixed.
Operation in stash: OutputAssignment { opout: Opout { op: OpId(Array<32>(37b77555023b0597bc1a3db0d1fd7b3bcaeef9c7e000ff8e24be845e7ae74157)), ty: AssignmentType(4000), no: 0 }, seal: Bitcoin(ExplicitSeal { method: OpretFirst, txid: Array<32>(0171d0dbee9d9964cff589b102b88b6fe5824714002bb79c871579074a9d1388), vout: Vout(0) }), state: RevealedValue { value: Bits64(100), blinding: BlindingFactor(Array<32>(9a02000000000000000000000000000000000000000000000000000000000000)), tag: AssetTag(Array<32>(85b7c6e10375b4159c4081bedeeb745a434292fb7915822097593521fba6b3f0)) }, witness: Some(Bitcoin(Array<32>(0171d0dbee9d9964cff589b102b88b6fe5824714002bb79c871579074a9d1388))) }
New operation: OutputAssignment { opout: Opout { op: OpId(Array<32>(37b77555023b0597bc1a3db0d1fd7b3bcaeef9c7e000ff8e24be845e7ae74157)), ty: AssignmentType(4000), no: 0 }, seal: Bitcoin(ExplicitSeal { method: OpretFirst, txid: Array<32>(81ab4e1c3c250ec2138f81b6eadcdbd1c877fbbc19bd47749e6d1d29309d2869), vout: Vout(0) }), state: RevealedValue { value: Bits64(100), blinding: BlindingFactor(Array<32>(9a02000000000000000000000000000000000000000000000000000000000000)), tag: AssetTag(Array<32>(85b7c6e10375b4159c4081bedeeb745a434292fb7915822097593521fba6b3f0)) }, witness: Some(Bitcoin(Array<32>(81ab4e1c3c250ec2138f81b6eadcdbd1c877fbbc19bd47749e6d1d29309d2869))) }

this panic comes from https://github.com/RGB-WG/rgb-std/blob/master/src/contract/assignments.rs#L75.
I think this check should change or be removed since it's preventing us from consuming the fascia (as the DistinctBundleWitness error was doing).

I'm not sure about the need of WitnessResolver, since the current resolver already returns WitnessOrd::Archived for all offchain TXs.

Hm, I believe you need it to report the new commitment transaction as Tentative in order to be able to create HTLCs spending from it.

I think this check should change or be removed

Yes, it was created to prevent from having multiple versions of the same state transition pointing to different witnesses and defining different seals, so now it is unnecessary. Removed in https://github.com/RGB-WG/rgb-std/pull/255

Hm, I believe you need it to report the new commitment transaction as Tentative in order to be able to create HTLCs spending from it.

It doesn't seem so, in my tests I'm able to construct the HTLC TXs without setting the commitment to Tentative.
With https://github.com/RGB-WG/rgb-std/pull/255 the test succeeds. I've also added some logic to it to see what happens if a PSBT representing an old state gets broadacasted and by calling update_witnesses that part works as well. I haven't updated RLN with these changes yet, but in the meantime this issue can be closed after merging https://github.com/RGB-WG/rgb-std/pull/255.

It doesn't seem so, in my tests I'm able to construct the HTLC TXs without setting the commitment to Tentative.

This is probably due to the fact that you build HTLC state transitions not from the state but directly from PSBTs. I forget that.


[DUOS-1971][risk=no] Use the V2 Algorithm for all matches

Addresses
https://broadworkbench.atlassian.net/browse/DUOS-1971
This PR:

Adds a version to the match table to denote which algorithm we used to store the results
Updates all matching logic to query the v2 endpoint and store the results with the v2 version

Have you read CONTRIBUTING.md lately? If not, do that first.

Label PR with a Jira ticket number and include a link to the ticket
Label PR with a security risk modifier [no, low, medium, high]
PR describes scope of changes
Get a minimum of one thumbs worth of review, preferably two if enough team members are available
Get PO sign-off for all non-trivial UI or workflow changes
Verify all tests go green
Test this change deployed correctly and works on dev environment after deployment

Closing in favor of a slightly different approach


handled duplicate project name error

Worked @blackcathacker at @fullstackla where we worked on issue #47 .

Hey Brent.  Thanks for the pull-request.  We're still trying to figure out how things are working around here, so apologies in advance.
I was looking through your changes, and they look pretty good.  However, you unnecessarily added a findByName search to the ProjectController to in order to detect when a project name is already taken.  Since the database already claims that column to be unique (which you can check in postgres), it emits a DataIntegrityConstraintViolatedException when trying to save a new Project with an already used project name.  So, instead of searching and throwing a NestedServeletException, it would be simpler (and less duplication) to use the database constraint exception.
I was already in that area of the code and was inspired by your changes, that I actually took your changes and just applied what I described above and pushed it.  See 71ca26671bcd89603d648dd249a9669b9a1d55a7.  Check through that commit to see what I meant above, and let me know if you agree.
Also another good change would be to stop sending different HTTP status codes to detect custom errors on the frontend, and instead to start sending errors to the frontend with messages already on them so that frontend doesn't need that logic.  If you feel like you are up to the task to tackle that, I'd help you out with it.
Thanks again for the pull request, please feel free to pick up other Issues, ideally come ping us on the public Parrit slack (parrit.slack.com) and we'll point you in the issues we would love to see done first.


Made ability cooldown only apply when calling CommitAbilityCostAndCooldown()...

... or CommitAbilityCooldown() (fixes issue #25)

I've implemented a CommitAbilityCooldown() method and a CommitAbilityCostAndCooldown() which are respectively alternatives to GAS' CommitCooldown() and CommitAbility(), the latter with a longer name for the sake of clarity and to respect how CommitAbilityCost() is named.
This introduces a breaking change, though : All abilities will now NOT apply their cooldown if none of the new methods are called.
This is default GAS behavior, but if you want me to add a bApplyCooldownAtAbilityBegin property that is true by default, let me know.

Actually I think it's best to add that boolean. Let me fix that real quick.
Also, I had to redo my fork and forgot to remove the SetCooldownForAbility in BeginAbility, so I'll just wrap it in an if() and it'll be all good.

Done !
Let me know if you don't like it.

LGTM. I would like to eventually handle cooldowns similar to GAS and do them as Effects so that they can be properly synced in the case of mispredictions, but this design wouldn't change. That would just change the float timer part of it. Thanks!

You're very welcome 👌


Fix docker.get_file for binary files

The file to get is copied to a temp file, and then opened to read into memory. This would open the file in text mode (the default), which would fail on binary files that could not be decoded as utf8.
This changes the file opening to use binary mode. It also simplifies the rest of the code, which would try to handle both strings and bytes, but this is likely a remnant of py2 code (or the maybe copied from files.put where the passed file could possibly be a stream in text mode).

To reproduce this error:
$ cat binary_test.py
from pyinfra.operations import files
files.put(src="binary_file", dest="/binary_file")
files.get(src="/binary_file", dest="/tmp/binary_file")
$ echo -ne '\xf3' > binary_file
$ pyinfra @docker/debian:bookworm-slim binary_test.py --yes
--> Starting operation: files.get (src=/binary_file, dest=/tmp/binary_file)
Traceback (most recent call last):
  File "src/gevent/greenlet.py", line 908, in gevent._gevent_cgreenlet.Greenlet.run
  File "/home/matthijs/.local/pipx/venvs/pyinfra/lib/python3.11/site-packages/pyinfra/api/operations.py", line 184, in _run_host_op_with_context
    return run_host_op(state, host, op_hash)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/matthijs/.local/pipx/venvs/pyinfra/lib/python3.11/site-packages/pyinfra/api/operations.py", line 53, in run_host_op
    return _run_host_op(state, host, op_hash)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/matthijs/.local/pipx/venvs/pyinfra/lib/python3.11/site-packages/pyinfra/api/operations.py", line 121, in _run_host_op
    status = command.execute(state, host, connector_arguments)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/matthijs/.local/pipx/venvs/pyinfra/lib/python3.11/site-packages/pyinfra/api/command.py", line 191, in execute
    return host.get_file(
           ^^^^^^^^^^^^^^
  File "/home/matthijs/.local/pipx/venvs/pyinfra/lib/python3.11/site-packages/pyinfra/api/host.py", line 429, in get_file
    return self.connector.get_file(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/matthijs/.local/pipx/venvs/pyinfra/lib/python3.11/site-packages/pyinfra/connectors/docker.py", line 270, in get_file
    data = temp_f.read()
           ^^^^^^^^^^^^^
  File "<frozen codecs>", line 322, in decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf3 in position 0: unexpected end of data
2024-03-21T21:54:39Z <Greenlet at 0x72ef51c844a0: _run_host_op_with_context(<pyinfra.api.state.State object at 0x72ef52013e50>, Host(@docker/debian:bookworm-slim), '9d1afe224119c48d16c1b791f0422627e757bed3')> failed with UnicodeDecodeError

I have not added any unit tests, since the normal docker unit tests patch out all of the actual docker stuff, so testing that the right calls are done does not seem meaningfull. Maybe a test could be added to the end-to-end tests, but it was not immediately clear to me if that would be a good idea and how to approach that (also, I need to get back to my actual project and pop a few levels of yak shaving here ;-p).


Updated the getAuthObject method to get the current user's access_token

Updated the getAuthObject method for fetch the current user's auth session data

I merged a security fix on the upstream master, so if you change something on your PR, please rebase on it before.


End User - Set a standard for Required fields as certain fields are needed to make it functional

Need to find and determine what fields MUST be required for functionality and data integrity for managing events

Updated in https://github.com/SFDO-Community-Sprints/Summit-Events-App/compare/feature/tjs-org__tjs-org - should have all required fields on Summit Event and Event Instance Object


Fixed typo on the garbage-collection.json

I'm not sure if we need also change visualising to visualizing. Linked blog post is titled as 'Visuali_z_ing Garbage Collection Algorithms'

Thank you. 💜
I actually like the British way of spelling things. But thank you for fixing the typo.


Workflow debugging: if a step panics the "running spinner" never stops

Description
I forced a panic (in code) in the function step which threw the error that the session was not found.
Note
We do some special handling for panic cases (if we didn’t change this already) so this is probably an edge case.
Error log
Error: step 4 crashed: A
14:15:42.844	DEBUG	workflow.session.exec	executed	{"workflowID":<PHONE_NUMBER>37529971, "runnerID":<PHONE_NUMBER>40449651, "runnerRoles": [303885395395953779,<PHONE_NUMBER>96019315], "sessionID":<PHONE_NUMBER>99553651, "stateID":<PHONE_NUMBER>99619187, "stepID": 4, "functionRef": "composeRecordsSearch", "functionKind": "function", "execTime": "8.256979ms"}
goroutine 949 [running]:

Screenshot of error

This can only happen in extreme edge cases where our built in functions would panic due to some implementation issue. To resolve it on back-end, we'd need to do quite a bit of refactoring in terms of panic recovery and session management which won't be easy for any of us.
What I'd suggest is we add an exception to this edge-case where the execution request fails successfully but can't obtain the session info since it was never created because of panic recovery.

The workflow now no longer hangs and recovers properly

@Bojan-Svirkov for QC, at this line https://github.com/cortezaproject/corteza/blob/2022.9.x-wf-panic-recovery/server/system/automation/users_handler.go#L167 add panic("AAAAA")

Tested and confirming that this is now fixed. Added Cl.


Adding uniqueId-ification to masks/paths in main component

It looks like effort was made to ensure masks and path elements would have unique ids in the various pieces.  But that same effort wasn't done in the main Avatar class.  In our app, this caused the avatars to disappear if the first avatar on the page was destroyed or hidden (assumedly because all the avatars were reusing the masks/paths from that initial svg).
The diff is quite noisy because I think I compiled it with a newer version of typescript (not sure though, I'm not a heavy typescript user).  All of my changes were isolated in src/avatar/index.tsx.

Hi Maintainers!
Kindly request you look at and merge this PR.  The current codebase has a bug where different svgs with the same ID are being removed by the browser and messing up any other avatars that may use components with the same ID.  Essentially this makes the library only useful if one avatar is shown at the same time (or if avatars are never removed from the DOM).  This PR fixes those issues.

Thank you for @cgross submitting. I checked the latest code and found that referring to your code has corrected this problem.

@cgross please fix the merge conflicts if you get a chance, I think it will fix this issue of rendering multiple avatars on a single page getting all jumbled up 😅 .

Hi @cgross, sorry I was super busy until recent have a bit time to look into these. Do you mind fixing the conflicts in this PR? So that I can merge it. I just hope the original contributor can get their credit. I can also create a new PR with your change myself to address the conflicts, and then add your name into a contributors list to thank you for making this PR.

@fangpenlin I'm busy myself but definitely not worried about getting created.  Feel free to make a new PR with my changes.  Glad to get this issue knocked out.  We've been maintaining a forked copy due to this bug.

https://github.com/fangpenlin/avataaars/commit/b306029c6316593757e0100356155b77be4a956e seems like I have already brought your changes into the code a while back. thank you so much for the PR, closing this now


Add testers to R2RML processors table

additional to the tester, if there is a row per database+engine, the database should be also included

@dachafra It's something like this?

YES!


grouped-fields: Add new Grouped fields component. Update inputs to support it

grouped-fields: Initial release of component.
To support this component, change how invalid state is applied to autocomplete, combobox, date-picker, date-range-picker, password-input, search, search-input, select, textarea and text-input.
View preview
Playroom
Checklist
Preflight

[x] Prefix the PR title with the slug of the package or component - e.g. accordion: Updated padding or docs: Updated header links
[x] Describe the changes clearly in the PR description
[x] Read and check your code before tagging someone for review
[x] Create a changeset file by running yarn changeset. Learn more about change management.

Testing

[x] Manually test component in various modern browsers at various sizes (use Browserstack)
[x] Manually test component in various devices (phone, tablet, desktop)
[x] Manually test component using a keyboard
[x] Manually test component using a screen reader
[ ] Manually tested in dark mode
[x] Component meets Web Content Accessibility Guidelines (WCAG) 2.1 standards
[x] Add any necessary unit tests (HTML validation, snapshots etc)
[x] Run yarn test to ensure tests are passing. If required, run yarn test -u to update any generated snapshots.

Documentation

[x] Create or update documentation on the website
[x] Create or update stories for Storybook
[x] Create or update stories for Playroom snippets

Creating new component

[x] Document the component for the website (docs/overview.mdx and docs/code.mdx at a minimum)
[x] Preconstruct entrypoint has been created (run yarn in the root of the repo to do this)
[x] Changeset file includes a minor
[x] Export components for docs site and Playroom (docs/components/designSystemComponents.tsx)
[x] Add component to Kitchen Sink (.storybook/stories/KitchenSink.tsx)
[x] Add snippets to Playroom (docs/playroom/snippets.ts)
[ ] Add pictogram to Docs (docs/components/pictograms/index.tsx)

I noticed a playroom example that is missing the error markup. I'm not sure if this was intentional or not.

I noticed a playroom example that is missing the error markup. I'm not sure if this was intentional or not.

Ah, I just copy pasted and made some fields invalid or not to show all the combinations


[QUESTION]

First check

[x] I used the GitHub search to find a similar issue and didn't find it.
[x] I searched the FastAPI documentation, with the integrated search.
[x] I already searched in Google "How to X in FastAPI" and didn't find any information.

Description
first, im new use fastapi and i trying create api with this and use heroku as my hosting
i want create API for convert MP4 to MP3 use ffmpeg.
let say i've code for user post file like this:

@app.post("/api/postfile")
async def postingfile(file: UploadFile = File(...)):
    myf = open(f"data/{file.namefile}", "wb")
    myf.write(file.file.read())
   cmd = f"ffmpeg -y -i data/{file.filename} -b:a {bitrate} -preset superfast -af volume={volume} -c:a libmp3lame -acodec {codecs} data/{title}.mp3"
   call = subprocess.call(cmd, shell=True)
   #another code ...

first before i upload my project to heroku i've test my api on local server(using android Termux), its run correctly and faster for write and convert file only took < 3seconds for result
i test on heroku server its look > 20seconds idk why, maybe i'hve wrong at my code im not sure. .
Im appreciated for any helping..

@dyseo it would be very difficult to help you with extra info and without a simple self-contained example. But at least I can see that you are using async def and then using subprocess.call inside.
subprocess.call is blocking, so you shouldn't use async def. Check the docs about that here: https://fastapi.tiangolo.com/async/


If retry_on_except is false, raise exception

https://ocd.appscale.com:8080/job/Daily Build/451/

https://ocd.appscale.com:8080/job/Daily Build/455/

https://ocd.appscale.com:8080/job/Daily Build/461/

https://ocd.appscale.com:8080/job/Daily Build/517/

https://ocd.appscale.com:8080/job/Daily Build/520/


Sanitize port parsing for pods in play kube

The logic used in parsing the ports to be utilized in a kubenetes api
defined pod did not fully adhere to the kubenetes spec, nor did it map
well to a podman context. This fix sanitizes the input of container
ports to meet the following rules:

A defined containerPort with no defined hostPort does nothing in a
podman context, or is informational. This is line with usage in
Kubernetes.

A defined hostPort with no defined containerPort acts like a
publish [hostPort]:[hostPort]

A defined containerPort and defined hostPort works like it does in
kubernetes, as in a publish [hostPort]:[containerPort]

Addresses https://github.com/containers/libpod/issues/5610
Signed-off-by: Tyler Ramer<EMAIL_ADDRESS>

/cc @giuseppe @mheon

I feel like this might be better handled inside play kube as opposed to more generic pod code, as we don't necessarily want podman pod create -p 80:0 to work

@mheon actually... podman pod create -p 80:0 does currently work (or doesn't work, depending on how you look at it)
libpod$ podman pod create -p 80:0 --name test
9c3c794006a30b475ae71487de91d7c899deedd0d92abeba62a08ed75b8c93da
libpod$ podman ps
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES
libpod$ podman pod ls
POD ID         NAME   STATUS    CREATED          # OF CONTAINERS   INFRA ID
9c3c794006a3   test   Created   13 seconds ago   1                 f615633b85a4
libpod$ podman version
Version:            1.8.2
RemoteAPI Version:  1
Go Version:         go1.14
Git Commit:         028e3317eb1494b9b2acba4a0a295df80fae66cc
Built:              Sat Mar 21 09:30:34 2020
OS/Arch:            linux/amd64
libpod$ podman run --pod test  --rm -d quay.io/redhatworkshops/simple-python-web:latest /usr/bin/python3 -m http.server 8080
ERRO[0004] error starting some container dependencies
ERRO[0004] "failed to expose ports via rootlessport: \"invalid ChildPort: '\\\\x00'\\n\""
Error: error starting some containers: internal libpod error

Also, getPodPorts is only called from inside PlayKubeYAML :
libpod(5610_play_kube_network)$ grep -Rn getPodPorts .
./pkg/adapter/pods.go:595:	podPorts := getPodPorts(podYAML.Spec.Containers)
./pkg/adapter/pods.go:765:// getPodPorts converts a slice of kube container descriptions to an
./pkg/adapter/pods.go:767:func getPodPorts(containers []v1.Container) []ocicni.PortMapping {

 540 // PlayKubeYAML creates pods and containers from a kube YAML file
 541 func (r *LocalRuntime) PlayKubeYAML(ctx context.Context, c *cliconfig.KubePlayValues, yamlFile string) (*Pod, error) {
...
 580 ⇥       hostname := podYAML.Spec.Hostname
 581 ⇥       if hostname == "" {
 582 ⇥       ⇥       hostname = podName
 583 ⇥       }
 584 ⇥       podOptions = append(podOptions, libpod.WithPodHostname(hostname))
 585
 586 ⇥       if podYAML.Spec.HostNetwork {
 587 ⇥       ⇥       podOptions = append(podOptions, libpod.WithPodHostNetwork())
 588 ⇥       }
 589
 590 ⇥       nsOptions, err := shared.GetNamespaceOptions(strings.Split(shared.DefaultKernelNamespaces, ","))
 591 ⇥       if err != nil {
 592 ⇥       ⇥       return nil, err
 593 ⇥       }
 594 ⇥       podOptions = append(podOptions, nsOptions...)
 595 ⇥       podPorts := getPodPorts(podYAML.Spec.Containers)
 596 ⇥       podOptions = append(podOptions, libpod.WithInfraContainerPorts(podPorts))

Apparently our port validation isn't as good as I thought... But that's something for another time.
If this function is only called from within play kube we ought to be fine.
/approve
/ok-to-test

LGTM

/lgtm

/approve


Added American English translation

This will make it MUCH easier for American readers to understand this app, so we don’t have to check a dictionary every time we need to figure out what “colour” or “prioritise” means.
I also removed some sentences with British-isms and comma splices (which are not correct in American English).

wow, motherfucker actually went and did it
you'll need to rebase this so i can merge it, inconvenient timing i realise sorry

🦅 Fixed


add locale to Shuttle Console Map tab

About the PR
added ftl localization for incorrect FTL status of the shuttle
Media

Requirements

[x] I have read and am following the Pull Request and Changelog Guidelines.
[x] I have added media to this PR or it does not require an ingame showcase.

Changelog

:cl:

add: Locale to shuttle-ftl-status-Invalid

I what cases does this even show up as invalid? Isn't that a dummy state that should never occurr?

I what cases does this even show up as invalid? Isn't that a dummy state that should never occurr?

It shouldn't occur, but I've seen this happen a few times in public games where the shuttle just... vanishes (probably destroyed by meteors).

Could you please also add localization for buttons above? Like "DOCK", "MAP", etc

Yeah, those should definitely be localized. But your choice if you want to do that in this PR or a separate one.


Remove dependency on 'slug' field in User model

CommentsComponent cnd Commentable behavior require field named 'slug' to be present in used User model - name of custom field used in comments elements should be configurable. Workaround is setting up virtual field in User model.

Problem persists... Had to create an unnecessary field "slug" in users table.

I still have this issue in version 1.3.1. Had to create an empy slug field on users table.


Create Feature Roadmap/To-Do For Developement

We need a clear document with all the stuff that needs to be done.
Through 3rd party service or simple text file?

You can do that with the "Project" tab
Le ven. 25 mai 2018 à 18:11, TheRealDannyyy<EMAIL_ADDRESS>a
écrit :

Assigned #2 https://github.com/Armaldio/twitchy-desktop-lite/issues/2
to @Armaldio https://github.com/Armaldio.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Armaldio/twitchy-desktop-lite/issues/2#event-1646999286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC8lMy6FZDY3F43nbYn3iRbmwg8Wthctks5t2C0ogaJpZM4UOPBD
.

You need to enable it again since I have no access to repo settings.

Done

Thx, checked it out and it's great. Will finish it sometime soon.


Please remove 1.0.1 tag

Hi,
I am pulling in remarkable2-framebuffer in a build pipeline (packaging it for Debian), and stumbled upon a probably faulty tag 1.0.1. It points to the same commit as 0.0.14.
Could you please delete that tag?
Thanks,
Nik

done, but what does package for debian mean?

what does package for debian mean?

That means that I am building rm2fb-client as a Debian package, to upload to official Debian repositories. And in practice, this means that I am working on making a vanilla Debian userland work from a chroot created using debootstrap inside the Codex Linux on the rM2.
Once it passes the NEW queue, you will find the package here: https://tracker.debian.org/teams/remarkable-pkg/


Planned as Maven Artifact?

I have written a regex benchmark comparing different regex engines for Java. Lately I found your approach and would be curious how it performs compared to the other alternatives.
Yet I restricted the benchmark to projects that are available as maven library artifact. I am not certain whether your project may be distributed in such a way. If so, I would offer to integrate a new benchmark in regexbench (a pull request is also welcome).

Disclaimer: This project originated out of a research project at university. The aim was not to have the fastest implementation, but instead to have a reference implementation for this paper:
http://ddfy.de/sci/det.pdf
About the maven repo:
Since there does not seem to be too much interest of people in using this library, I have not thought about publishing this to maven central. I don't know how much work that would be tbh as I have not done this for any project, yet.

Thanks for your answer.
If you are interested: A documentation how to do this at sonatype is found here. Of course there is some initial work to be done, but after having a sonatype account you can publish new projects with the same namespace without any additional effort.
If it is too much effort you may close this issue.
Best Regards,
Stefan


[WIP] Synchronization of multiple nodes

[x] New data structure: BlockCollection and BranchedChain
[x] Replace the PendingBlocks filed of BlockSynchronizer and make it work normally
[x] Using breakpoint to test whether all the nodes will apply the longest chain
[ ] We found a problem while doing online test, this is because the mining node who was removed from most nodes doesn't request blocks of longest chain during interruption, need to be fixed during refactoring network layer.

Two solutions to cope with the re-sync problem:

Rollback then restart the node automatically

Using the branched chain's start height and end height to request the missing blocks

Basically these two solutions are trying to do initial sync again.


metric depth or relative depth ?

I want to customize your model on my own dataset, which has rgb images + relative depth maps( 8-bit)
Is this possible ?
One example of my ground truth depth maps:

Sure. You need to abandon the scale prediction branch and change the depth loss to scale-invariant.

Since i'm new to the field, can you give me some tips on which files should I start investigating ?
should I implement a scale-invariant loss function and add it to the code ?
Thank you for the response !

Set with_scale=False in the config file, and change the sigloss to scale-invariant loss. Also, don't forget to customize your own dataloader.

Closing this issue. If there are any other questions please open another issue.


JRE missing from 4.1.0 release

Whoops! JRE missing from 4.1.0 release.
Note that files with or without jre have same file size: https://repo1.maven.org/maven2/org/flywaydb/flyway-commandline/4.1.0/

Arggh!! I guess we'll need to fix this in a 4.1.1 release soon!


about create a multiresolution panorama

I wanna know how to create a multires type of panorama?the way you said about running the generate.py file seems difficult to understand for me without knowledge of python and Hugin.
I have download the Hugin and found the path of nona,and now I don't know what to do next
ps: I do not good at English, and thank for your kindness of open-source with such a good thing.

You did not specify what operating system you're using. On Debian or Debian-derived distros such as Ubuntu, it's as simple as installing the required packages with sudo apt-get install hugin-tools python3-pil and then running python3 generate.py yourpanorama.jpg from the utils/multires directory. If you're using Windows or macOS, you're on your own for figuring out how to install Python, Pillow, and Hugin.

sorry to miss that,I use Windows work,and how to use Hugin with Python and create an multiresresolution panorama?I do have not idea about it...
It would be nice for reply my problem,ths again.

and where I should put the picture?

Now I have download the three things and try,got the error...,would you help me ?
C:\Users\he100>py D:\panellum\pannellum-master\utils\multires\generate.py -n "D:\panellum\Hugin\bin\nona.exe" D:\panellum\pannellum-master\aaa\data\multi\H110m.jpg
Traceback (most recent call last):
File "D:\panellum\pannellum-master\utils\multires\generate.py", line 31, in
from PIL import Image
ModuleNotFoundError: No module named 'PIL'

and I have views the similar question and found that the images are all written  without it's path but its name.

I tried once and it seems work but I don't know where to find the result...
C:\Users\he100>py D:\panellum\pannellum-master\utils\multires\generate.py -n "D:\panellum\Hugin\bin\nona.exe" D:\panellum\pannellum-master\aaa\data\multi\H110m.jpg Processing input image information... Assuming --haov 360.0 Assuming --vaov 180.0 Generating cube faces... Generating tiles... Generating fallback tiles...
or I have not finished yet? ths for ur reply

and when I put all the three things in the same place and run,it says already exist,
Output directory "./output" already exists
and I have no idea where are they...

I use Windows 10

By default, the tiles are created in the output directory. That error message means that the output directory already exists.

yeah,I know it said,but where the output folder is...couldn't find this folder...or is there has any way to save the result in folder defined？

its first run seems run without define an output folder,and now still can't find it neither in the same folder..

The output directory is relative to the working directory where you ran the command. Based on the command you posted, that would be C:\Users\he100\output. The --output flag allows you to specify the output directory.

oh I found it..thank you!!!

right now I got another problem.... the code I load multiresolution with this:
var a = pannellum.viewer('surroundView',{             "firstScene":"1_00000000",             "sceneFadeDuration":666,             "autoLoad":true,             "showControls":false,             "minPitch":-50,             'hfov':100.0,             //全景图首张固定             "scenes":{                 "1_00000000":{                                         "type":"multires",                     "basePath": "/aaa/data/1_00000000/output",                     "path": "/%l/%s%y_%x",                     "fallbackPath": "/fallback/%s",                     "extension": "jpg",                     "tileResolution": 512,                     "maxLevel": 5,                     "cubeResolution": 6360                 }             }         });
and it hold step in loading and the console print Uncaught SyntaxError: Unexpected token u in JSON at position 0,but  I havn't use any json file...thx again for ur kindness

right now I got another problem.... the code I load multiresolution with this:
var a = pannellum.viewer('surroundView',{  "firstScene":"1_00000000", "sceneFadeDuration":666, "autoLoad":true, "showControls":false, "minPitch":-50, 'hfov':100.0,   "scenes":{         "1_00000000":{                         "type":"multires",                         "basePath": "/aaa/data/1_00000000/output",                         "path": "/%l/%s%y_%x",                        "fallbackPath": "/fallback/%s",                        "extension": "jpg",                         "tileResolution": 512,                         "maxLevel": 5,                         "cubeResolution": 6360 } } });
and it hold step in loading and the console print Uncaught SyntaxError: Unexpected token u in JSON at position 0,but I havn't use any json file...thx again for ur kindness

right now I got another problem...,and I followthis  to fix my code with :
var a = pannellum.viewer('surroundView',{
"firstScene":"1_00000000",
"sceneFadeDuration":666,
"autoLoad":true,
"showControls":false,
"minPitch":-50,
'hfov':100.0,
//全景图首张固定
"scenes":{
"1_00000000":{
"type":"multires",
"multiRes": {
"basePath": "/aaa/data/1_00000000/output",
"path": "/%l/%s%y_%x",
"fallbackPath": "/fallback/%s",
"extension": "jpg",
"tileResolution": 512,
"maxLevel": 5,
"cubeResolution": 6360
}
}
}
});
and it hold step in loading and the console print Cannot read property 'length' of undefined ,but I havn't use any json file...thx again for ur kindness

Now I found the load event can't work with the multiRes type,and it makes me confused because I have something to do with this event and it works with equirectangular before.
hope for your fervent help

oh I found it! just close the autoLoad to able to use the load event with multiRes!
And it would be nicer for using autoLoad with multiRes,hope for an update for this function

The load event is fired with multiresolution panoramas as well. However, it's fired immediately, so you won't get an event if you create a viewer with a multiRes panorama and autoLoad: true, since the event will be fired before you attach an event listener.

emmm...is there any way to get the current scene's ID each time I change the scene even the first scene?,wait for help.

The getScene() method returns the current scene's ID.

yeah I know...I mean if there's any other way like the load event's work each time changing the scene.I used to use getScene() in load and now it's useless with multiRes..

The load event works perfectly fine for multiRes configurations, as does getScene(). As I said previously, it will fire before you can attach an event listener for multiRes configurations with autoLoad: true. As this is the first scene, you know directly from your configuration which scene it is, so there's no need for an event listener to tell you this. I don't know how to make this any more clear.

Also, calling people's work useless isn't a good way to get people to help you.

Also, calling people's work "useless" isn't a good way to get people to help you.
I'm so sorry to let you misunderstand what I mean...as I used to say I'm not goot at English...thank you any way for answer me each time


Problem with Alpha in an animation

Describe the bug
Can I export to GLB an animation where object(mesh) will appear/disappear ? i am still not succesfull with using of keyframes with changed alpha value.
Any idea?
Thx Petr

Hello,
You need KHR_animation_pointer extension to perform what you want.
This extension is managed, starting Blender 4.2 beta

And then you have to enable the feature at export (available for Scene & NLA Track animation mode)

PS: There is still an issue when your animation starts with alpha value 1.0
Fix in progress