Smarter cache for snapshot_download

Is your feature request related to a problem? Please describe.
For diffusers many model repositories share identical checkpoint files. Currently when downloading two model repos that share many files both files are downloaded which is good since the whole model repository is self-contained, but arguable storage space is wasted.
Could we add features to snapshot_download that makes it "smart" in a way that it check whether a file has already been downloaded for another repo and then just creates a reference to this?
Example
Let's make the following example. We download both the v1-4 and v1-5 checkpoints from diffusers:
from diffusers import DiffusionPipeline

DiffusionPipeline.from_pretrained("CompVis/stable-diffusion-v1-4", cache_dir="local_cache")
DiffusionPipeline.from_pretrained("runwayml/stable-diffusion-v1-5", cache_dir="local_cache")

Now taking a look at:
tree local_cache

one gets:
├── models--CompVis--stable-diffusion-v1-4
│   ├── blobs
│   │   ├── 0e985ad52577b583221ab4bc6b8e275a9df6a2c6
│   │   ├── 0f998cd15e52f65656cd801497d171c5b9477cc7
│   │   ├── 193490b58ef62739077262e833bf091c66c29488058681ac25cf7df3d8190974
│   │   ├── 1a3e6d1a17dd6e722b4d4297023f979170219680
│   │   ├── 1b134cded8eb78b184aefb8805b6b572f36fa77b255c483665dda931fa0130c5
│   │   ├── 1d668d5d6799dea92e03bdd747de2365f8ef2393
│   │   ├── 2c2130b544c0c5a72d5d00da071ba130a9800fb2
│   │   ├── 469be27c5c010538f845f518c4f5e8574c78f7c8
│   │   ├── 5294955ff7801083f720b34b55d0f1f51313c5c5
│   │   ├── 5ba7bf706515bc60487ad0e1816b4929b82542d6
│   │   ├── 62d48b4d841a3178511fa453df0dae59b22089ace64609cc9d5353d0a7f37c26
│   │   ├── 76e821f1b6f0a9709293c3b6b51ed90980b3166b
│   │   ├── 770a47a9ffdcfda0b05506a7888ed714d06131d60267e6cf52765d61cf59fd67
│   │   ├── 93561f30a14e2a26eb3bf2ce3da74a52b36e90a3
│   │   ├── 97bed2ba03e1a77fe548fab801464c734b0a142b
│   │   └── df430a86cefe4115495e64c47936850adaeac0e9
│   ├── refs
│   │   └── main
│   └── snapshots
│       └── 3857c45b7d4e78b3ba0f39d4d7f50a2a05aa23d4
│           ├── feature_extractor
│           │   └── preprocessor_config.json -> ../../../blobs/5294955ff7801083f720b34b55d0f1f51313c5c5
│           ├── model_index.json -> ../../blobs/0e985ad52577b583221ab4bc6b8e275a9df6a2c6
│           ├── safety_checker
│           │   ├── config.json -> ../../../blobs/97bed2ba03e1a77fe548fab801464c734b0a142b
│           │   └── pytorch_model.bin -> ../../../blobs/193490b58ef62739077262e833bf091c66c29488058681ac25cf7df3d8190974
│           ├── scheduler
│           │   └── scheduler_config.json -> ../../../blobs/1a3e6d1a17dd6e722b4d4297023f979170219680
│           ├── text_encoder
│           │   ├── config.json -> ../../../blobs/df430a86cefe4115495e64c47936850adaeac0e9
│           │   └── pytorch_model.bin -> ../../../blobs/770a47a9ffdcfda0b05506a7888ed714d06131d60267e6cf52765d61cf59fd67
│           ├── tokenizer
│           │   ├── merges.txt -> ../../../blobs/76e821f1b6f0a9709293c3b6b51ed90980b3166b
│           │   ├── special_tokens_map.json -> ../../../blobs/2c2130b544c0c5a72d5d00da071ba130a9800fb2
│           │   ├── tokenizer_config.json -> ../../../blobs/5ba7bf706515bc60487ad0e1816b4929b82542d6
│           │   └── vocab.json -> ../../../blobs/469be27c5c010538f845f518c4f5e8574c78f7c8
│           ├── unet
│           │   ├── config.json -> ../../../blobs/0f998cd15e52f65656cd801497d171c5b9477cc7
│           │   └── diffusion_pytorch_model.bin -> ../../../blobs/62d48b4d841a3178511fa453df0dae59b22089ace64609cc9d5353d0a7f37c26
│           └── vae
│               ├── config.json -> ../../../blobs/1d668d5d6799dea92e03bdd747de2365f8ef2393
│               └── diffusion_pytorch_model.bin -> ../../../blobs/1b134cded8eb78b184aefb8805b6b572f36fa77b255c483665dda931fa0130c5
└── models--runwayml--stable-diffusion-v1-5
    ├── blobs
    │   ├── 19da7aaa4b880e59d56843f1fcb4dd9b599c28a1d9d9af7c1143057c8ffae9f1
    │   ├── 1a02ee8abc93e840ffbcb2d68b66ccbcb74b3ab3
    │   ├── 2c2130b544c0c5a72d5d00da071ba130a9800fb2
    │   ├── 469be27c5c010538f845f518c4f5e8574c78f7c8
    │   ├── 4d3e873ab5086ad989f407abd50fdce66db8d657
    │   ├── 5294955ff7801083f720b34b55d0f1f51313c5c5
    │   ├── 55d78924fee13e4220f24320127c5f16284e13b9
    │   ├── 5ba7bf706515bc60487ad0e1816b4929b82542d6
    │   ├── 5dbd88952e7e521aa665e5052e6db7def3641d03
    │   ├── 6866dceb3a870b077eb970ecf702ce4e1a83b934
    │   ├── 76e821f1b6f0a9709293c3b6b51ed90980b3166b
    │   ├── 82d05b0e688d7ea94675678646c427907419346e
    │   ├── 9d6a233ff6fd5ccb9f76fd99618d73369c52dd3d8222376384d0e601911089e8
    │   ├── a2b5134f4dbc140d9c11f11cba3233099e00af40f262f136c691fb7d38d2194c
    │   └── d008943c017f0092921106440254dbbe00b6a285f7883ec8ba160c3faad88334
    ├── refs
    │   └── main
    └── snapshots
        └── 39593d5650112b4cc580433f6b0435385882d819
            ├── feature_extractor
            │   └── preprocessor_config.json -> ../../../blobs/5294955ff7801083f720b34b55d0f1f51313c5c5
            ├── model_index.json -> ../../blobs/6866dceb3a870b077eb970ecf702ce4e1a83b934
            ├── safety_checker
            │   ├── config.json -> ../../../blobs/5dbd88952e7e521aa665e5052e6db7def3641d03
            │   └── model.safetensors -> ../../../blobs/9d6a233ff6fd5ccb9f76fd99618d73369c52dd3d8222376384d0e601911089e8
            ├── scheduler
            │   └── scheduler_config.json -> ../../../blobs/82d05b0e688d7ea94675678646c427907419346e
            ├── text_encoder
            │   ├── config.json -> ../../../blobs/4d3e873ab5086ad989f407abd50fdce66db8d657
            │   └── model.safetensors -> ../../../blobs/d008943c017f0092921106440254dbbe00b6a285f7883ec8ba160c3faad88334
            ├── tokenizer
            │   ├── merges.txt -> ../../../blobs/76e821f1b6f0a9709293c3b6b51ed90980b3166b
            │   ├── special_tokens_map.json -> ../../../blobs/2c2130b544c0c5a72d5d00da071ba130a9800fb2
            │   ├── tokenizer_config.json -> ../../../blobs/5ba7bf706515bc60487ad0e1816b4929b82542d6
            │   └── vocab.json -> ../../../blobs/469be27c5c010538f845f518c4f5e8574c78f7c8
            ├── unet
            │   ├── config.json -> ../../../blobs/1a02ee8abc93e840ffbcb2d68b66ccbcb74b3ab3
            │   └── diffusion_pytorch_model.safetensors -> ../../../blobs/19da7aaa4b880e59d56843f1fcb4dd9b599c28a1d9d9af7c1143057c8ffae9f1
            └── vae
                ├── config.json -> ../../../blobs/55d78924fee13e4220f24320127c5f16284e13b9
                └── diffusion_pytorch_model.safetensors -> ../../../blobs/a2b5134f4dbc140d9c11f11cba3233099e00af40f262f136c691fb7d38d2194c

As one can see many blobs have an identical hash, e.g.:
76e821f1b6f0a9709293c3b6b51ed90980b3166
5294955ff7801083f720b34b55d0f1f51313c5c5
...

Could it make sense to somehow create a mechanism that does not download files if the exact same hash is already present in a blob of another model repo?
Solution
I wonder whether we can just add a smart_cache=True flag to snapshot_download that if set, it'll check the cache_dir before whether the existing file already exsits in another folder and if yes only references the new file.
I'm wondering whether this is a bit overkill for now though.
It's an issue that originated from discussions with InvokeAI and is also discussed on diffusers here: https://github.com/huggingface/diffusers/issues/1984
Maybe also cc @julien-c

Thanks for the detailed feature request here @patrickvonplaten
A few things popped-up in mind when thinking about it:

Do you see this problem to be related more to disk usage or to network bandwidth (downloading the files)?
TBH, I am not a big fan of having a smart_cache flag that would change the cache structure based on its usage or not. With time, it will get harder for the users/for huggingface_hub to manage the cache (e.g. "can I delete this repo from the cache or will it break another cached repo?").
We could start to have a "blob index" that keeps track of all blobs and the symlinks between them. But I feel this is error-prone in the future -as any index, it would need to be refreshed from time to time-. The current cache-system is not so bad in the sense that it's efficient for a single repo + it you want to delete it, it's all self-contained.
What we could still do is instead of downloading a blob file, we check if we already have it in cache and if yes we duplicate it. It would not solve the disk-usage problem but it seems to be a quick win if you need to test different repos sharing the same file.
If disk usage efficiency really is a problem and if we encounter a lot of cache duplication, maybe we could think of having a single "blobs" folder shared between all repos. It would require:

A script to change existing cache from users
A "blob-index" tracking which repos uses which blobs
Adapt the scan-cache/delete-cache commands (would be straightforward once we have the blob-index)
I'm still a bit reluctant to do that as it would be a major change in users' cache + still not sure there is a lot of demand for such use case.

WDYT? Also interested in @julien-c's opinion since you designed this cache structure (with @LysandreJik I guess?)

Also 1 thing maybe relevant: when a user do hf_hub_download or snapshot_download, it return a path to the cached file. It is actually a path to a symlink to the blob file. The user is expected to read the file but never to write in it. If a user do so, its cache will become corrupted, especially if it's the blob file itself that has been edited.
We can't really mitigate this issue and it's at the user's discretion to use the filepath correctly. However in case of a bad usage, only 1 cached repo is impacted. The user can always delete it and restart. If we start to share blobs between repos, this kind of issues can be much more difficult to track down -except deleting the entire cache-. This is also the case if we duplicate blobs between repos (instead of redownloading) - we could end up duplicating a corrupted blob file.
A way of mitigating this is to have a kinda-sanitize-cache command that checks every blob file, compute the sha and report if it's not consistent with the blob name (or check blob name/sha consistency just before duplicating it). Wouldn't be too hard to do, but still some extra work.

also would be interested in @coyotte508's opinion as he recently computed the % of LFS files that are duplicated across the whole Hub (and it's not super large). Also cc @Kakulukian
My hunch would be that this is a bit overkill, but indeed if we do go this way in the future, I wouldn't do this as an option, but always store blobs on a flat level, as @Wauplin says.
Note also that while collisions between SHA256 (what LFS uses) are rare, collisions between SHA1 (what raw git uses, so for non-LFS files) are definitely a thing.
So it would be easy to create a random file that overrides any other file (user still needs to download it to their local cache, of course)

TL;DR: My hunch is that for now, let's monitor the evolution of the % of file duplication across the Hub. If it goes up in the coming months, let's re-assess

TL;DR: My hunch is that for now, let's monitor the evolution of the % of file duplication across the Hub. If it goes up in the coming months, let's re-assess

While I agree with this ("let's not care too much until it's really a problem"), let's keep in mind that we are not talking here about % of file duplication across the Hub but % of file duplication between repos that are used by a same roup of users (and in this case, diffusers users).

hmm, yes, but the two are bound to be highly correlated, no? (maybe not for a few users, but averaged on all users)

Yep on average it's the same. For now it seems that it's mostly impacting only (some?) diffusers users.
In any case, @patrickvonplaten unless you think there is a huge need for such an optimization, I don't think we will change something in the near future.

For now it seems that it's mostly impacting only (some?) diffusers users.

Is this pattern of "construct a pipeline that makes use of multiple models and store all those models under a single repo" a pattern that's unique to diffusers?

Is this pattern of "construct a pipeline that makes use of multiple models and store all those models under a single repo" a pattern that's unique to diffusers?

At least for what I am aware of, yes it is. Let's ping @sgugger to be sure it's not the case in transformers ? At least this optimization has not been suggested so far.
(@sgugger TL;DR of this topic: diffusers have some pipelines re-using a lot the same files between repos. In the current cache-system it means same files are duplicated (once per repo) -apparently there could be a 20% gain of disk usage in some cases-. For now we will not proceed further in this direction to keep repos cache "self-contained")

We don't use snapshot_download at all in Transformers, so the problem doesn't appear :-)

Actually the question is more around the cache-system itself so both hf_hub_download and snapshot_download.

We also don't re-use the same large files between repos. Some tokenizer files are duplicated but they're not too big so it's not a problem on our end.

It's quite unique to diffusers (for now at least). If many more "composite" models (VQ-Tokenization + generation) would find their way into transformers, then it could become interesting there as well, but that's not really the case and doesn't seem to happen anytime soon


Add lang attribute to PDOM root

@terracoda ran a sim through the WAVE (Web Accessibility Evaluation Tool) which provided an error that no lang attribute is specified.
Over slack @terracoda suggested:

And for now, since the PDOM is the only accessible text, I am wondering if it makes sense to assign English to the page like this, lang="EN" until we figure out how to translate our a11y strings? Or it might make sense to assign English to the a11y-root div. The lang attribute can be placed on any element.

I think that this could be an option when creating a display. Right now,  Sim.js can pass in a hard coded "EN"  but in the future we can change that to "phet.chipper.locale"

I considered an option but it didn't seem necessary to add to the Display API. Instead I just went with a setter on Display.accessibleDOMElement.  But I don't feel strongly if you think an option would be better @zepumph.

Looks great to me! Thanks

Is this going on all a11y sims with interactive description?

Yes, and it has been since February


RatbagdButton.Type always returns unknown on at least the G403

Noticed while implementing button mappings in Piper: the Type property on a RatbagdButton DBus object always returns unknown. According to @whot this is a bug, hence this issue.

Note that type refers to the button physical type (left, right, thumb, etc...) not the associated binding. It's read only (given that it's hardware dependent) and is a per-driver bug, not a general one.

Yes, I am aware of that. In Piper it's needed to display the function of a button mapping, i.e. if I assign logical button 1 to physical button 0, in Piper it should say "Right mouse button click".

if I assign logical button 1 to physical button 0, in Piper it should say "Right mouse button click".

I still think you are confused here. The type is the position of the button on/under the mouse. It has nothing to do with bindings. For instance on the G700, I have 4 thumbs buttons and they are typed as thumb, thumb2, thumb3 and thumb4. On piper, there is absolutely no need to retrieve this property given you have the SVG to rely on which is far more explicit than any type we could think of.

I don't think I am confused. If I map to my physical button 0 (i.e. the left mouse button) the logical button 1 (i.e. the right mouse button), then in Piper it should display "Right mouse button click". In order to do so, I need to know the type of the logical button that my physical button is mapped to, so that I can grab the correct string in the type-to-description table here.
How would I do this without needing the logical button's type?

The fact that you name button 1 to Right mouse button click has nothing to do with ratbagd and further more the type property of a button. It's a convention in X that button 1 is the right click, but you should not use the physical information from type to get to the description of what a button does.
Also the fact that logical button 1 manages to map to Right click (which should not be working given that right click is at the third position) would be pure coincidence.
Again, type is the physical description of a physical button and it is not supposed to change during the lifetime of the device. If you want to have fancy naming (button 1 to right click, button 2 to middle, 14 to forward IIRC, etc...), then this is something piper specific and it should not end up in ratbagd.py

I am indeed confusing some things. It was @whot's comment:

I think this is something where the GUI has to make the decisions and limit what can be done compared to the raw interface on the commandline. It's acceptable to have a list of "left click", "right click", ... etc and then map those to the respective button numbers without having to expose the button number option to the user. The wacom configuration is a guideline here, see https://wiki.gnome.org/Design/SystemSettings/Tablet though that one is not up to date. Look at the stylus config, it says "Left button click". I think we should do the same here.

that made me think that this was the right approach, i.e. "map those to the respective button numbers". @cvuchener's comment now also makes a lot more sense.
Would an alternative, correct approach be to have a list within Piper of the following:
button 0 → left click
button 1 → right click
button 2 → middle click
button 3 → back
button 4 → forward
as suggested by @cvuchener in the linked comment, and leave the rest as-is? (e.g. "button 5", "button 6", et cetera)

Yes, this would be much better.

Couple of things:

keeping this one still opened as there are some work to be done in the drivers to have proper type support

I think we introduced the type of a button to allow the UI to restrict the list of choices when it sees a button of a certain type. It could be interesting to implement in piper "physical Left and Right buttons can only be remapped to button 0 and 1". This adds restrictions on the usage, but we could also make some sanity check on the mappings when there is something obviously wrong ("you have 2 profiles enabled and can't change them on the mouse", "you have no primary or secondary click, are you using it as a mouse?", etc...)

@Hjdskes merged the patch for the left/right button swap in piper, see above.
What are we going to do with this one now? As a temporary fix we could just add this to the .device files until we know how to coerce the driver into giving us this info


Not getting response in Mutation.

I am trying to call Mutation method with MutationOptions. Method and query are as follow.
Method:
final graphql.MutationOptions options =
        graphql.MutationOptions(document: graphql.gql("""
           mutation {
       createPost(
    spaceId: "id",
    input: {
      postTypeId: "type"
      mappingFields: [
        {
          key: "title"
          type: text
          value: "title"
        },
        {
          key: "content"
          type: text
          value: "content"
        }
      ]
      publish: true
    }
  ) {
    id
  }
    }

      """));
    var result = await fluttergql.GraphQLClient(
      cache: fluttergql.GraphQLCache(),
      link: _link,
    ).mutate(options);
    print("============> ${result.toString()}");
  }

Response:
QueryResult(source: QueryResultSource.network, data: null, context: Context({ResponseExtensions: Instance of 'ResponseExtensions', HttpLinkResponseContext: Instance of 'HttpLinkResponseContext'}), exception: OperationException(linkException: null, graphqlErrors: [GraphQLError(message: Validation Params Failed, locations: null, path: null, extensions: null)]), timestamp: 2022-08-29 11:03:51.778335)

Data is null while GraphQl showing error "Validation Params Failed" while Query is working i confirmed with other app.
Please guide me through this.

This is a server error and not a bug in the library. Try and validate your mutation in other clients, or reach out for help on our discord channel.

Can you guide how to validate mutation. As I Check the query, It's working, just not getting response in flutter only.

Can you guide how to validate mutation??

Try and perform your mutation in a different client (e.g. postman) and see if this is only happening in this client.

As I Check the query, It's working,

How are you "checking" your query?
How do you verify that this is working?

just not getting response in flutter only.

It is working though. You're getting an error from the server because your mutation is invalid.

I have checked query in Postman Its working fine getting response in Postman also

Do you have a screenshot of this?

Check this screenshots, It's not passing the value which cases error. Do you have any suggestion how to pass it?

Cool. First off, I can't verify that these two requests are the same because you've decided to crop the message.
Secondly, the second screenshot is now a different error (which is caused by you not escaping your quotes properly).

Yes, I got it. As i'm new to graphql, i don;t have much idea about this. Can you guide me how can i get rid of this error. I have trying to resolve this since last few days.
Can you help me, How can i pass this query.
final graphql.MutationOptions options =
graphql.MutationOptions(document: graphql.gql("""
mutation {
createPost(
spaceId: "spaceid",
input: {
postTypeId: "id"
mappingFields: [
{
key: "title"
type: text
value: ""Hi, eveyone""
},
{
key: "content"
type: html
value: ""Good Afternoon""
}
]
publish: true
}
) {
id
}
}
  """));
var result = await fluttergql.GraphQLClient(
  cache: fluttergql.GraphQLCache(),
  link: _link,
).mutate(options);

I'm trying to help you. If you'd please share the screenshot of executing exactly the same query in postman.

In this query , in mappingFields and in value , I need send json string, which I am unable to send.
Here is a screenshot of exact same query from postman,

Here, what I am trying to send in flutter

Your mutation itself is a string and you're not escaping your double quotes properly. This is not a graphql problem but a problem with how you're using dart.
You have different ways of escaping your \, the easiest probably is to prefix your mutation with r. This'll treat the string as a raw string which will not read your backslash as trying to escape your quote.
For example, take the program
print("hello"); // prints hello
print("\"hello\""); // prints "hello"
print("\\\"hello\\\""); // prints \"hello\"
print(r"\"hello\"); // prints \"hello\"

I tried putting 'r' It's giving me this error:
QueryResult(source: QueryResultSource.network, data: null, context: Context({}), exception: OperationException(linkException: ServerException(originalException: null, parsedResponse: Response(data: null, errors: [GraphQLError(message: Syntax Error: Expected ":", found Name "everyone"., locations: null, path: null, extensions: null)], context: Context({ResponseExtensions: Instance of 'ResponseExtensions'}), response {errors: [{message: Syntax Error: Expected ":", found Name "everyone"., code: 10, timestamp: 2022-08-30T12:45:49.283Z}]})), graphqlErrors: []), timestamp: 2022-08-30 18:15:49.284640)

So this is, again, a server error. I don't know why it won't accept your data as I don't know what api you're developing against. But it is not an error in this framework.
I can see that you've changed the mutation from when you called with postman, so have you tried:

Changing it back, I.e. adding the comma between Hi and everyone?
Restarting your app

I tried all possible solutions, but didn't get success.
But thanks for your help.

If you need more help, feel free to reach out on our discord.


KAFKA-9793: Expand the try-catch for task commit in HandleAssignment

As title suggests, we would like to broaden this check so that we don't fail to close a doom-to-cleanup task.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

test this please

Java 11 passed, but Java 8 failed with
java.lang.AssertionError: unexpected exception type thrown; expected:<java.lang.RuntimeException> but was:<java.lang.AssertionError>
	at org.junit.Assert.assertThrows(Assert.java:1020)
	at org.junit.Assert.assertThrows(Assert.java:981)
	at org.apache.kafka.streams.processor.internals.TaskManagerTest.shouldCloseActiveTasksDirtyAndPropagatePrepareCommitException(TaskManagerTest.java:1270)

Could this be related?

Let me check @mjsax

Fixed by relaxing the ordering check @mjsax

Retest this please.

Retest this please

test this please

Only one test failure on jdk 8:
kafka.api.PlaintextAdminIntegrationTest.testAlterReplicaLogDirs

Error Message
org.scalatest.exceptions.TestFailedException: only 0 messages are produced within timeout after replica movement. Producer future Some(Failure(java.util.concurrent.TimeoutException: Timeout after waiting for 10000 ms.))

Retest this please.

10:11:30 Execution failed for task ':streams:compileJava'.
10:11:30 > Compilation failed; see the compiler error output for details.

@guozhangwang I think we need to merge https://github.com/apache/kafka/pull/8424 first

test this please

test this please

test this please

test this please

test this please

test this please

test this please

test this

test this please

Okay I'm done with jenkins bot and manually build two: https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/1622 and https://builds.apache.org/job/kafka-pr-jdk11-scala2.13/5641

Both jenkins succeed, merging to trunk now.


Add diagnostic and test tools to the build

Board test and diagnostics require interactive control of the hardware.  The tag.sh commands can be used for this and need to be augmented.

This is a duplicate of issue #14  Closing


2FA New Phone

I do have a backup of my wallet but since new release the wallet is not syncing. I added nodes, but still getting the message 0 active nodes. Then after a while it shuts down or crashes. If I do not have 2FA phone how do I restore?

If you still have issue with this, please contact us at<EMAIL_ADDRESS>


Switch to hatchling commands and remove scripts

Switch to Hatchling for package management.
Remove scripts directory and use Hatch commands.

Awesome use of scripts!!!

@ofek Thanks for the great work :)


test_pv_sys_drop_which_generates_overnight

Pull Request
This pull request corresponds to the function drop_pv_sys_generating_overnight.py and its test test_pv_generating_overnight.py
Description
This method consists of two steps

In the first step, it assigns the day/night status for each timestamp as an extra coordinate.
In the second step, considering those day/night status, drops any pv systems which has values of 0 or NaN in their night status coordinate.

Fixes #
How Has This Been Tested?
This has been tested with pvoutput_datapipe and artificially constructed data array. This data array has three systems, in which two systems have np.zeros values for the entire time range(including day and nights), and np.ones for the other system. Hence it will drop the third system as it is clearly producing non_zero or np.nan over night.

[ ] Yes

If your changes affect data processing, have you plotted any changes? i.e. have you done a quick sanity check?

[ ] Yes

Checklist:

[ ] My code follows OCF's coding style guidelines
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my code and corrected any misspellings

Codecov Report

Merging #127 (b29c0e0) into main (427b8ee) will increase coverage by 0.49%.
The diff coverage is 100.00%.

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

@@            Coverage Diff             @@
##             main     #127      +/-   ##
==========================================
+ Coverage   80.76%   81.25%   +0.49%
==========================================
  Files         111      113       +2
  Lines        4356     4433      +77
==========================================
+ Hits         3518     3602      +84
+ Misses        838      831       -7

Impacted Files
Coverage Δ

ocf_datapipes/select/__init__.py
100.00% <100.00%> (ø)

...tapipes/select/drop_pv_sys_generating_overnight.py
100.00% <100.00%> (ø)

ocf_datapipes/transform/xarray/__init__.py
100.00% <100.00%> (ø)

...ipes/transform/xarray/pv/assign_daynight_status.py
100.00% <100.00%> (ø)

ocf_datapipes/select/remove_bad_pv_systems.py
70.00% <0.00%> (+70.00%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Be compatible with Resque Ruby GUI

Wondering, ist there a reason why this pull request hasn't been merged yet.
FYI - same error occurs on the newer resque web interface as well.


RFE: Signed Versions / Checksums

Hi,
for security reasons I would appreciate OPENPGP-Signatures for the files provided under https://www.owasp.org/index.php/OWASP_Dependency_Check (Download: http://dl.bintray.com/jeremy-long/owasp/).
Maybe it's easier first to provide checksums of the files on https://www.owasp.org/index.php/OWASP_Dependency_Check  (would not be too easy to attack the Owasp-Server and the download server). Checksums on the download server would not really make sense from a security standpoint as it would be no problem to also put the checksum of the forged program there.
Thanks
Regards
Tim

In reality - I'm not sure signatures on the Wiki would make any sense as it is a wiki with a ton of contributors.
I'll look into providing the gpg signature in the future and posting that to bintray along side the dependency. Yes, if the site was compromised they could replace the signature with their own...
<rabbitHole>
So let me ask you this - why do you trust a file published with a signature more then one published without? It is entirely possible to publish the source code for a given/tagged version - and add/modify the code prior to compilation, publication, and distribution that is not included in the public source code repository. By posting a signature - yes, you are limiting your attackers or praying that the binary distribution platform has good security AND that the publisher has good operational security with their keys...  Wouldn't you rather BYOB (Bring-Your-Own-Binaries) by meticulously reviewing the source code for a given tagged version and then compiling it yourself? Oh wait...  did you review the OS and JDK source code too? Where does the rabbit whole of trust end?  I love the Ken Thompson paper, "Reflections on Trusting Trust"
</rabbitHole>

Well, of course do I have to trust you and your code, otherwise I wouldn't run it and I also have to trust all the other developers of the programs I use. And yes, I also have to trust you that you handle the signing key securely, and I am aware of the fact that in general there is no absolute security.
But for me it still makes sense to provide signatures for downloads as this increases the chance to know that a program that has been provided by a trusted person, has not been tampered by others, who have access to the download server (legitimate or due to criminal acting). I think it's a matter of likelihood and personally I think that the risk of someone breaking into a download site and putting a trojaned version there is nowadays quite high. It's the best way for someone who wants his trojaned version to be installed on many sites at once.
Regards
Tim

Please don't get me wrong - I am planning on providing the signatures. Which is why I tried to put that block above in more of a separate section.  This is actually one of my areas on interest - is what is published based on the actual source that is tagged as the given version.
Regardless - I'll try to post the signature files to bintray during the next release.

Hi Jeremy,
thanks a lot for your work.
Regards
Tim


gcc: place cross-compiled target libraries in lib output

Motivation for this change
This is my take on an alternative, subjectively cleaner implementation of #58606 and #81788. The only functional difference is that the libraries are placed in $lib/$targetConfig/lib (which is the directory convention using by the GCC build scripts) rather than $lib/lib. This requires a minor change to cc-wrapper. Subjectively, I believe it is cleaner because it unifies the handling of the cross and non-cross cases and is therefore easier to reason about.
I have tested this change by building pkgsCross.armv7l-hf-multiplatform.hello and pkgsCross.aarch64-multiplatform.hello.
While searching for potential ramifications of this change, I found a patchelf invocation that is no longer needed. I have verified that the lib output of the native x86_64 builds of all supported GCC versions still contain no references to their corresponding out output after this change.
I also included the sotruss removal patch from #58606.
Things done

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

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

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

cc @illegalprime @floki @matthewbauer @eamsden

I removed the sotruss commit because I didn't see any references to build time bash. If someone thinks it is still needed, it can be included in a different PR.

I hope someday the location of thtings can be the same for native and cross, but if it solves a real problem it is fine for now. The GCC build system is too much of a mess to fight slowly, it has to be an all or nothing attack.

@Ericson2314 Isn't your eventual goal to always cross-compile and use prefixed compilers (#44583 #21471), in which case this would be the correct solution and $targetConfig would be set even for native builds.

@lopsided98 Yes, but my goal is also to build (or at least have build outputs as if we built) standard libraries like regular libraries, which means everything goes in $lib/lib. Given using GCC's monolithic build system, that would mean putting target vs host libs in separate outputs so they would both be in $output/lib.

This probably broke i686 builds: https://hydra.nixos.org/build/114095842

The problem is that targetConfig is set, but GCC seems to not consider this to be a cross-compiler, so it doesn't put the target libraries in a target specific directory.

#82510 should fix that.


Clicker: Implement unlock conditions

Easiest middleground is "owning X amount" of things, and make it an array

Done


The new option Clean should have defaulted to false or been highlighted as a breaking change

After upgrading to v3 our deployed app started failing due to being unable to get various javascript files.
It appears that the value for clean is defaulted to true, since on every deployment I only had one set of javascript files.  After changing the value explicitly to false I got the expected new set of files for every deployment.
This caused problems for us since previously downloaded SPA apps were looking for older versions of the javascript files.  This worked fine in V2.
It would be nice to hightlight this as a breaking change on the relase page rather than just a new feature.  Since it can causes issues and is a change in behaviour.

Since I was storing data files locally, this caused enormous data loss for me. Extremely bad customer service here.

We also experienced data loss due to this "feature". Something that could be as destructive as this should definitely be defaulted to OFF or be a required field - whereas this was optional.

Same here, data loss - thank God we had copious backups.

I can't believe that a new option that deletes existing files has been introduced with a default value that destroys data.


Use current system view instead of the legacy

Learn Build status updates of commit 38aceb9:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/ssms/register-servers/execute-statements-against-multiple-servers-simultaneously.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@markingmyname
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#reassign:rwestMSFT

Thanks as always, @zikato. You triggered an article refresh, so this is incorporated into an internal PR and will close when that PR is merged.


Open the update dialog the same way you open all dialogs

Checklist

[X] I'm reporting a problem with Chatterino
[X] I've verified that I'm running the most recent nightly build or stable release
[X] I've looked for my problem on the wiki
[X] I've searched the issues and pull requests for similar looking reports

Describe your issue
If the chat occupies a large part of the screen in height, you have to resize the window to go to the update.
I propose to make the behavior the same as for other dialogs - open in the center of the Chatterino window.
Screenshots

OS and Chatterino Version
Chatterino 2.4.4 (Impossible to show the bug after update to 2.4.5) • Running on macOS Ventura (13.5), kernel: 22.6.0

A similar problem appeared when trying to open a thread.

I have the same problem, with thread, update, and settings windows not respecting screen boundaries and going off-screen.  Somehow, the user card window (clicking on a username) still works ok. Chatterino 2.4.5 on Windows 10, OS Build 19045.3324


Fix windows version validator under Chinese

Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.
Flutter tool currently uses OS Version: to find the installed version of windows from systeminfo command, however, the command may return localized string. Take Chinese as an example:
主机名:           XXXXXXXXXXXX
OS 名称:          Microsoft Windows 11 专业版
OS 版本:          10.0.22621 暂缺 Build 22621
OS 制造商:        Microsoft Corporation
OS 配置:          独立工作站
OS 构建类型:      Multiprocessor Free
注册的所有人:     暂缺
注册的组织:       暂缺
产品 ID:          XXXXXXXXXXXX
初始安装日期:     2022/11/9, 13:33:50
系统启动时间:     2022/11/30, 13:36:47
系统制造商:       ASUS
系统型号:         System Product Name
系统类型:         x64-based PC
处理器:           安装了 1 个处理器。
                  [01]: Intel64 Family 6 Model 151 Stepping 2 GenuineIntel ~3600 Mhz
BIOS 版本:        American Megatrends Inc. 2103, 2022/9/30
Windows 目录:     C:\WINDOWS
系统目录:         C:\WINDOWS\system32
启动设备:         \Device\HarddiskVolume1
系统区域设置:     zh-cn;中文(中国)
输入法区域设置:   zh-cn;中文(中国)
时区:             (UTC+08:00) 北京，重庆，香港特别行政区，乌鲁木齐
物理内存总量:     65,277 MB
可用的物理内存:   55,333 MB
虚拟内存: 最大值: 75,005 MB
虚拟内存: 可用:   61,781 MB
虚拟内存: 使用中: 13,224 MB
页面文件位置:     C:\pagefile.sys
域:               WORKGROUP
登录服务器:       \\XXXXXXXXXXXX
修补程序:         安装了 3 个修补程序。
                  [01]: KB5020622
                  [02]: KB5019980
                  [03]: KB5019304
Hyper-V 要求:     已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。

This causes the original approach always fail. The PR updates RegExp to prevent the hardcoded Version.
List which issues are fixed by this PR. You must list at least one issue.
#116280
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@eliasyishak please take a look at this one (at a glance seems reasonable)

@ctrysbita can you rebase this PR with the latest from tip of tree? The Google testing infra is failing as this PR is 80 commits behind.


Will react localize redux package set the lang attribute in  element ?

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Will react localize redux package set the lang attribute in  element ?
What is the expected behavior?
As per accessibility issues, we see Html element is not set with a lang attribute.

This would be up to you to set this attribute as react-localize-redux is completely agnostic when it comes to setting up the languages you're supporting. This would be a matter of updating the html lang attribute every time the active language changes. The implementation of that is outside the scope of this library though as it really depends on how your app is setup. e.g. Is the  element part of your react app vs not


Use Ruby base image for cookiecutter-ruby builds in CircleCI

Whoops, we still use tox on main with multiple versions, so this make it worse by taking away the Python versions.


Pressing [Alt Gr] key (right Alt-key on german keyboard) clears Command input

When entering a command which requires any character accessible with by pressing the  [Alt Gr] key, like | @ \ ~, the command input gets cleared.

Hi Skeeve, could it be a local problem?
I tried it on several unix machines and there don't exist that problem.
Ich als Besitzer einer deutschen Tastatur besitze das Problem nicht. ;-)
getestet auf Redhat, SunOS, Debian.
Client: Windows 7 x86
Supper putty Version: <IP_ADDRESS>

SuperPuTTY <IP_ADDRESS>
Windows 7 Enterprise SP1
When not connected to any host, Trying to enter a pipe or @ doesn't do anything in the command input field. The character seems to be ignored.
When connected to Linux 2.6.32-431.e16.x86_64 #1 (?) Pressing Alt-GR key because I require an @ in the command input field erases that field. Entering the @ in the shell window or pasting it into the command input field yields no problem.
No clue what else I could do to give more help.
There is also no issue with the ALt-Gr key in the host, login or password input field

New observation: When enter any character requiring me to press Alt-Gr into the command input field, not only the input field gets erased, but the character is copied into every open shell.
Example.
I want to type "Skeeve@Home" into the command input field.
I type "Skeeve" -> It appears in the field.
I press Alt-Gr -> The field get emptied
I continue with the "@" sign -> The field remains empty but the shell now has an @
I type "home" -> It appears in the field

Same behavior. Pressing AltGr cleares the Command field and pressing an additional key prints the character into the putty window.

Bump


Create a shared i18n helper for vue components

esco content menu and eyebrow user info share an i18n js file.
https://github.com/uPortal-contrib/uPortal-web-components/blob/e03700897a1299d741a9eece0409f3115a55321f/%40uportal/esco-content-menu/src/i18n.js#L1
https://github.com/uPortal-contrib/uPortal-web-components/blob/e03700897a1299d741a9eece0409f3115a55321f/%40uportal/eyebrow-user-info/src/i18n.js#L1
It could be helpful to break this into a helper function that can be applied to any vue component in the uPortal ecosystem.

+1 I thought about that too there are several weeks ;)

And we can do a similar thing for fontawesome.


Vue treated as external when building monorepo vue files - Yarn 2 monorepo

Describe the bug
When using vite build within the context of a yarn 2 monorepo app vue can end up externalized of the bundle because the node module resolution fails (because the package only define vue as peerDependency and yarn strict resolution tree make it fail)
'vue' is imported by ../../.yarn/$$virtual/vite-lib-virtual-3e369e6683/1/packages/vite-lib/TestComp.vue?vue&type=script&lang.js, but could not be resolved – treating it as an external dependency
Proposed solution
#234
We could always resolve local vue because in the case of the build command, vue does not get optimized and resolved correctly in this case.
Reproduction
https://github.com/AlexandreBonaventure/vite-resolve-vue-build
run git clone && yarn && yarn workspace vite-app build
System Info

required vite version: 0.16.6
required Yarn version: berry

I'll tackle monorepo support in the future since it requires some rethinking on how dependencies are reoslved - for now, I don't think we should monkey patch stuff to make it work.


Example web application compilation gives error:  package.json should exist

Steps to produce the error:
git clone --depth 1 https://github.com/eggjs/examples.git
cd examples/helloworld
npm install
nodec node_modules/.bin/egg-bin
cd ../
./helloworld/a.out dev

The output a.out will look for web app's source code first, e. g. package.json.
⚠  Error: egg is not found in /srv/examples/node_modules
⚠  Command Error, enable `DEBUG=common-bin` for detail

+1
So that means nodec only compiled the node and egg-bin? Not compile the web source code?


StackOverflowError occurs when thousands of strings are concatenated in a single expression

Here's the repeating portion of the stack trace:
$ java -jar compiler.jar test.js
java.lang.StackOverflowError
	at com.google.javascript.jscomp.parsing.IRFactory.justTransform(IRFactory.java:931)
	at com.google.javascript.jscomp.parsing.IRFactory.transform(IRFactory.java:734)
	at com.google.javascript.jscomp.parsing.IRFactory.access$300(IRFactory.java:163)
	at com.google.javascript.jscomp.parsing.IRFactory$TransformDispatcher.processBinaryExpression(IRFactory.java:1322)
	at com.google.javascript.jscomp.parsing.IRFactory$TransformDispatcher.process(IRFactory.java:2517)
	at com.google.javascript.jscomp.parsing.IRFactory.justTransform(IRFactory.java:931)

test.js is attached. Note it's a concatenation of 2,000 strings in a single expression.
There are two workarounds for this issue that I have found:

Break the string concatenation up into multiple statements
Increase JVM stack size, e.g. -Xss8M

test.js.zip

There's nothing we can really do here as we are using a recursive descent parser. This should happen rarely and when it does, both workarounds are relatively simple.

@Dominator008 That isn't completely true, minimizing the amount of stack used can help a lot.  There used to be a test for this specifically.

@concavelenz Yes, I recall the test was either deleted or reduced to a few hundred binary operations. @MatrixFrog

fwiw, there's a trick to handle this in a recursive descent parser. You can basically unroll the recursion for simple cases, like a tail-call optimizer would. (I think the old parser used to do this)

This is actually failing in the post parse processing of the AST (to convert it to the internal AST).  The actual parse is fine (which doesn't recurse for this case)

I'm landing a change to reduce the stack space usage (for another issues), so the stack will go from:
    at com.google.javascript.jscomp.parsing.IRFactory.justTransform(IRFactory.java:931)
    at com.google.javascript.jscomp.parsing.IRFactory.transform(IRFactory.java:734)
    at com.google.javascript.jscomp.parsing.IRFactory.access$300(IRFactory.java:163)
    at com.google.javascript.jscomp.parsing.IRFactory$TransformDispatcher.processBinaryExpression(IRFactory.java:1322)
    at com.google.javascript.jscomp.parsing.IRFactory$TransformDispatcher.process(IRFactory.java:2517)
    at com.google.javascript.jscomp.parsing.IRFactory.justTransform(IRFactory.java:931)

to
    at com.google.javascript.jscomp.parsing.IRFactory.transform(IRFactory.java:734)
    at com.google.javascript.jscomp.parsing.IRFactory$TransformDispatcher.processBinaryExpression(IRFactory.java:1322)
    at com.google.javascript.jscomp.parsing.IRFactory$TransformDispatcher.process(IRFactory.java:2517)
    at com.google.javascript.jscomp.parsing.IRFactory.transform(IRFactory.java:734)

which will help in some cases.

https://github.com/google/closure-compiler/commit/069e6378f8ba41372c9a1a38d4f4ebbbb4328fe1 fixed this for most cases.


PHP 8.1.6 - composer create-project doesn't work

Creating a "spiral/app" project at "./backend"
Installing spiral/app (v3.0.0)
  - Downloading spiral/app (v3.0.0)
  - Installing spiral/app (v3.0.0): Extracting archive
Created project in /Users/guozhu/WorkSpace/onearth.fun/backend
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - spiral/roadrunner-bridge[2.0-beta, ..., 2.0.x-dev] require psr/simple-cache 2 - 3 -> satisfiable by psr/simple-cache[2.0.0, 2.x-dev, 3.0.0, 3.0.x-dev].
    - You can only install one version of a package, so only one of these can be installed: psr/simple-cache[1.0.0, 1.0.1, 2.0.0, 2.x-dev, 3.0.0, 3.0.x-dev].
    - spiral/roadrunner-kv v2.2.0 requires psr/simple-cache ^1.0 -> satisfiable by psr/simple-cache[1.0.0, 1.0.1].
    - Conclusion: install spiral/roadrunner-kv v2.2.0 (conflict analysis result)
    - Root composer.json requires spiral/roadrunner-bridge ^2.0 -> satisfiable by spiral/roadrunner-bridge[2.0-beta, ..., 2.0.x-dev].

Hi @better-maksim!
Do you have php-psr extension?

@butschster the composer loads roadrunner-kv v2.2 (master branch using alias) that requres simple-cache v1.
Possible solutions:

update rr-kv master branch to use simple-cache 2-3
remove minimum-stability dev from spiral/app

@better-maksim could you try again?

@roxblnfk @butschster .
Cannot install now.
composer version
➜  onearth.fun composer -v
Composer version 2.3.5 2022-04-13 16:43:0

psr extension
➜  onearth.fun php -m | grep psr
psr

➜  onearth.fun composer create-project spiral/app backend
Creating a "spiral/app" project at "./backend"
Installing spiral/app (v3.0.0)
  - Installing spiral/app (v3.0.0): Extracting archive
Created project in /Users/guozhu/WorkSpace/onearth.fun/backend
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - spiral/roadrunner-bridge[2.0-beta, ..., 2.0.1] require psr/simple-cache 2 - 3 -> satisfiable by psr/simple-cache[2.0.0, 2.x-dev, 3.0.0, 3.0.x-dev].
    - You can only install one version of a package, so only one of these can be installed: psr/simple-cache[1.0.0, 1.0.1, 2.0.0, 2.x-dev, 3.0.0, 3.0.x-dev].
    - spiral/roadrunner-kv v2.2.0 requires psr/simple-cache ^1.0 -> satisfiable by psr/simple-cache[1.0.0, 1.0.1].
    - Conclusion: install spiral/roadrunner-kv v2.2.0 (conflict analysis result)
    - spiral/roadrunner-bridge 2.0.x-dev requires spiral/roadrunner-jobs ^2.6 -> found spiral/roadrunner-jobs[dev-master, dev-hotfix/payload-body, 1.0.x-dev (alias of dev-master), v2.0.0-beta1, ..., v2.5.0, v3.0.0, 3.x-dev] but it does not match the constraint.
    - Root composer.json requires spiral/roadrunner-bridge ^2.0 -> satisfiable by spiral/roadrunner-bridge[2.0-beta, ..., 2.0.x-dev].

Coul you try to disable extension and try to install again?

Could you please run composer why-not spiral/roadrunner-kv 3.0?

@roxblnfk @butschster
Thank you. It's already done
RoadRunner (v2.11.4) has been installed into /Users/guozhu/WorkSpace/onearth.fun/backend/rr

 [OK] Your project is now ready in /Users/guozhu/WorkSpace/onearth.fun/backend

Whats Next?
===========

 * For more detailed documentation, see the https://roadrunner.dev
 * To run the application, use the following command: $ rr serve

What was the reason of impossibility to install app?


Error when compile flutter app

Description
Hello:
No toolchains found in the NDK toolchains folder for ABI with prefix: arm-linux-androideabi
Cause: android license not accepted
Thank you very much
Virtual environments affected

[ ] Ubuntu 16.04
[ ] Ubuntu 18.04
[X] Ubuntu 20.04
[ ] macOS 10.15
[X] macOS 11
[ ] Windows Server 2016
[ ] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
Current
Is it regression?
No response
Expected behavior
No response
Actual behavior
No response
Repro steps
[!] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
! Some Android licenses not accepted.  To resolve this, run: flutter doctor --android-licenses
No toolchains found in the NDK toolchains folder for ABI with prefix: arm-linux-androideabi
Cause: android license not accepted

Hi @bitsjoanrobira!
Is it the same issue as described here?
https://github.com/actions/virtual-environments/issues/4144#issuecomment-929295216
Does the workarounds help?

Hi @bitsjoanrobira! Is it the same issue as described here? #4144 (comment) Do the workarounds help?

yes, is the same

@bitsjoanrobira Does the workaround help you to resolve the issue?
We're looking forward to your reply.

@bitsjoanrobira I'm going to close the issue as we haven't received a reply from you.
Please feel free to contact us if you have any concerns.
Thank you!


model

Hi,
I'm kinda new to this, and checked some tutorials for nanopore eventalign, however I don't understand how to get the model file. As I see it I have the following in my nanopolish/etc/r9-models dir:
r9.4_450bps.cpg.6mer.template.model
r9.4_450bps.nucleotide.5mer.template.model
r9.4_450bps.nucleotide.6mer.template.model
r9_250bps.cpg.6mer.template.model
r9_250bps.nucleotide.5mer.complement.pop1.model
r9_250bps.nucleotide.5mer.complement.pop2.model
r9_250bps.nucleotide.5mer.template.model
r9_250bps.nucleotide.6mer.complement.pop1.model
r9_250bps.nucleotide.6mer.complement.pop2.model
r9_250bps.nucleotide.6mer.template.model
And according to the tutorial I'm following I should cp everything into my working directory and the run:
nanopolish eventalign
-t8
--sam
-- reads .fasta
--bam .sorted.bam
--genome .contigs.fa
--models nanopolish_models.fofn \
and obviously get "Error: could not read nanopolish_models.fofn"
Appreciate all the help you can give!

Hi,
The --models parameter is no longer required. If you omit that parameter it should work. What tutorial are you following? I'll have to update it.
Jared

Hi Jared,
Thank you for the quick reply!
I'm using 0.5.0, will use 0.6.0 and see if it works better!

Also, the tutorial I was following was one from Porecamp 2016:
https://porecamp.github.io/2016/tutorials/PoreCamp2016-04-Assembly.pdf


Age Gauge Limit Flag

Janky WIP for Early Feedback
As discussed in #23, this PR implements a limit on the maximum number of age gauges that may be reported from a spectatord process.
The purpose of this feature is to limit a potential source of memory leaks for long-running spectatord processes where the tags associated with an age gauge vary over time. The limit defaults to 1000 and we do not think that most users will hit this limit on a per-node basis. The limit is customizable with the --age_gauge_limit flag, in the event that users need to adjust this setting for their particular service.

There are a couple of warnings to consider:
INFO: From Compiling spectator/tags_test.cc:
In file included from external/com_google_googletest/googletest/include/gtest/gtest.h:62:0,
                 from spectator/tags_test.cc:2:
spectator/tags_test.cc: In function 'void {anonymous}::verify_tags(const spectator::Tags&, int)':
spectator/tags_test.cc:62:31: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   ASSERT_TRUE(tags.capacity() >= n);
               ~~~~~~~~~~~~~~~~^~~~

INFO: From Compiling spectator/registry.cc:
spectator/registry.cc: In member function 'std::shared_ptr<spectator::AgeGauge> spectator::Registry::GetAgeGauge(spectator::Id)':
spectator/registry.cc:32:40: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
     if (all_meters_.age_gauges_.size() < config_->age_gauge_limit) {
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~

Regarding the comparison between signed and unsigned warnings, we can just size_t to the arguments of those functions (instead of int) or just cast them at the time of comparison. We can address those in a separate PR.

I think this PR is ready to go, if we punt on two issues:
(1) meter_map modifications due to mutex access, and
(2) cannot include test_utils.h in spectatord_test.cc for access to my_age_gauges - it breaks compilation.
server/spectatord_test.cc:5:10: fatal error: spectator/test_utils.h: No such file or directory
 #include "spectator/test_utils.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

server/spectatord_test.cc:5:10: fatal error: ../spectator/test_utils.h: No such file or directory
 #include "../spectator/test_utils.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

I think this PR is ready to go, if we punt on two issues:
(1) meter_map modifications due to mutex access, and
(2) cannot include test_utils.h in spectatord_test.cc for access to my_age_gauges - it breaks compilation.
server/spectatord_test.cc:5:10: fatal error: spectator/test_utils.h: No such file or directory
 #include "spectator/test_utils.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

server/spectatord_test.cc:5:10: fatal error: ../spectator/test_utils.h: No such file or directory
 #include "../spectator/test_utils.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

It's not included in the spectator library so you'd have to add it to your sources (BUILD.bazel). Something like:
cc_test(
    name = "spectatord_test",
    srcs = [
        "bin/test_main.cc",
        "server/proc_utils_test.cc",
        "server/spectatord_test.cc",
        "spectator/test_utils.h",
        "spectator/test_utils.cc",
    ],
...

This PR looks good to me, so feel free to merge at your convenience.


address_transactions: order and retrieve by date (desc)

Currently, address_transactions is ordered by address id. However, on the UI it would be desirable to see the latest transactions first and, if the number of transactions is large, to somehow retrieve them by date (can also be by month, year, whatever).

Had a look at the problem I think both of the things can be achived by restructuring how we query the table.
In e.g. the REST interface we often query the table like this:
select * from  address_transactions where address_id_group=264 and address_id=2647117;

Which results in random order. The tables clustering order is defined as follows:
...
    PRIMARY KEY (address_id_group, address_id, is_outgoing, tx_id)
) WITH CLUSTERING ORDER BY (address_id DESC, is_outgoing DESC, tx_id DESC)

Tx_id desc gives us temporal order but only if we query the right way (background), only if is_outgoing included in the filter we get ordered results (desc by tx_id).
select * from  address_transactions where address_id_group=264 and address_id=2647117 and is_outgoing=true;
select * from  address_transactions where address_id_group=264 and address_id=2647117 and is_outgoing=false;

So to receive ordered results we need to split the queries into two and add some logic in the client (REST etc.) to combine the result-sets (merge).
By including is_outgoing in the where clause we can also support range queries and switching up the order e.g.
select * from  address_transactions
where address_id_group=264 and
             address_id=2647117 and
             is_outgoing=true and
             tx_id > 1000
             order by tx_id ASC;

Using some additional lookups this could be even done by block number or date:

Get the block number for the start timestamp (raw  block)
Get the first tx_id in that block (raw block_transactions)
Get the block number for the end timestamp  (raw  block)
Get the last tx_id in that block (raw block_transactions)

Getting the blocknumber by date is currently not efficient but could be solved by a materialized view or binary search.

@myrho this is already implemented even in the rest interface right?


Increase deregister critical interval to 1 minute

The consul documentation says:

In Consul 0.7 and later, checks that are associated with a service may also contain an optional deregister_critical_service_after field, which is a timeout in the same Go time format as interval and ttl. If a check is in the critical state for more than this configured value, then its associated service (and all of its associated checks) will automatically be deregistered. The minimum timeout is 1 minute, and the process that reaps critical services runs every 30 seconds, so it may take slightly longer than the configured timeout to trigger the deregistration. This should generally be configured with a timeout that's much, much longer than any expected recoverable outage for the given service.

That's why we're seeing these warning messages:
2019/04/25 16:44:57 [WARN] agent: check 'service:xyz' has deregister interval below minimum of 1m0s

That's why this PR just sets the deregisterCritical interval to 1 minute per default.

@dennis-tra Thank you very much for the PR! Merge right the way! = )


Fixed: Passed itemSeqId and orderItemSeqId explicitly while creating shipment for the TO to handle the case of multiple order items with the same product. (#579)

Related Issues

Closes #
Short Description and Why It's Useful
Fixed: Passed itemSeqId explicitly while creating shipment for the TO to handle the case of multiple order items with the same product. (#579)
Screenshots of Visual Changes before/after (If There Are Any)

IMPORTANT NOTICE - Remember to add changelog entry
Contribution and Currently Important Rules Acceptance

[ ] I read and followed contribution rules

This is dependant on the following OMS PR - https://git.hotwax.co/commerce/oms/-/merge_requests/4850


Themes

Could you please explain how the 'theme' structure works?
There is a 'theme' folder with variable.scss. How does it actually work if I want to add my own SCSS? Do I need to reuse variable.scss?

You can find more info here and here.


Custom drop-downs  instead of select tag

It would be nice to have custom drop-downs for years and month dropdowns.
Because It is often required to style dropdowns according to layout.
Do you have plans to add custom  dropdowns ?
Thanks in advance

If the original daterangepicker has it I will have it exposed in the next v3.x release


add Kuzushiji-MNIST dataset

I'd like to suggest adding the Kuzushiji-MNIST dataset to Chainer.
The Kuzushiji-MNIST dataset is designed to be an
MNIST-like dataset focusing on handwritten Japanese
characters. All data features of KMNIST are identical to
MNIST, such as number of train and test images, image
size, etc with the intent of making it easy to run any
MNIST-based analysis or benchmarks against this new
dataset.
Details available here: https://github.com/rois-codh/kmnist

Jenkins, test this please.

Jenkins CI test (for commit 93cc4ed46ddb2b46b30815a6b90e7c179ccb450e, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

I'm wondering if we should use the more verbose "kuzushiji_mnist" instead of "kmnist" if we we're to provide "kuzushiji_49" and "kuzushiji_kanji" in the future, for consistency that is. Another argument for this would be that "fashion_mnist" already follows this naming convention. @wintercarver what do you think?

jenkins, test this please.

Jenkins CI test (for commit 01e7d35f5980ef650894d584d77b2ba8bf2e014b, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

jenkins, test this please.

Jenkins CI test (for commit 01e7d35f5980ef650894d584d77b2ba8bf2e014b, target branch master) succeeded!

LGTM!

Jenkins CI test (for commit 01e7d35f5980ef650894d584d77b2ba8bf2e014b, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)


Implement a reusable empty state partial for all places that need them

We don't do a great job at showing empty states in the app. We show them sometimes, and other times not. The task in this issue is to implement a single empty state partial. Given most of our empty states are used with filters, we can have default text in the partial like 'No results matching your search criteria', and to handle other cases, e.g., 'You have no liked pets', we can pass the string we want to display, and if provided, show that instead.
Please place this partial somewhere top level because it will be used throughout the app, e.g., app/views/shared and then update all places we should use an empty state.
Off the top of my head, this includes

Staff > pets, adoption applications, fosters, default pet tasks (where we use filters)
The adoptable pets path
Adopter Fosterer > liked pets, adopted pets, fostered pets
click around and see if you can find another place...but I think that's it?

We have some places that display an empty state in a table (like adopter fosterer > adoption applications, or Staff > Pet photos/attachments). It might make sense to leave these as is and not use the new partial. You can be final judge of that.

I'd like to help with this!

@jp524 Thanks!

@kasugaijin In the existing code I'm seeing places where i18n is used through the config/locales/en.yml file. There are some places where i18n isn't used though. What is the preference here?

@jp524 please use translations and structure them for lazy look up where possible. Technically all our view copy should come from a translation file…there’s a few spots that have not been updated yet.


Update a broken attribute in the example of main.rs

I'm not sure if this is correct, but the examples in the book are not working, and the example in the GitHub description shows this version. Could be quite a blocker for new people trying to follow the book on 0.4.x

No, this is intentional, sorry. As I state in the docs, you'll need to replace perseus_integration with perseus_warp. The reason development of the examples uses this is because CI needs to test with all the server integrations, and perseus_integration is a glue crate to make that work properly with feature flags. All the examples in the repo can be run with bonnie dev example ....
The docs on the website should mention this, is there anywhere you think I could make it clearer?
With that all said, I do want to phase that crate out, because I agree that it's confusing. String replacement of some form would probably be the best way to do this. If you have any interest in making a PR for that, I'd be happy to accept it!

@arctic-hen7 Ah my bad then. I started by using 0.3.5, but there was that issue with Tokio so I switched to 0.4beta and probably didn't pay enough attention to the docs to notice it.
But as I'm looking at it right now, it is quite hidden. Just one sentence in a folded prompt. I was searching for the word integration but I didn't find it because the text is folded.
I would add a sentence right below the code "Replace perseus_integration with ..." and maybe even in code, put it in <> to indicate that the name is not a real code.

Yeah agreed. I think it's also mentioned in the example readmes, but they aren't on the website, to be fair. If you want to submit a new PR making that clear in the docs, that would be great!


rustfmt removes parenthesis in macro call

In the following snippet:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9b0e4357d4c32e40b179c243c6861f6c
macro_rules! mymacro {
    ($tt1:tt $(+ $tt2:tt)*) => {
        fn foo<F>(f: F)
        where
            F: $tt1  $(+ $tt2)*
            {}
    }
}

mymacro!((for<'a> Fn()) + Send + Sync);

rustfmt removes paren in the following macro call:
mymacro!((for<'a> Fn()) + Send + Sync);

so that it gets turned into:
mymacro!(for<'a> Fn() + Send + Sync);

Unfortunately, the latter is not equivalent and does not compile

Thanks for the report. In the more immediate term you may just want to change the call site delims to {} or [] to prevent this from occurring, or if you're using nightly, leverage the skip_macro_invocations option with my macro for the same

@rustbot claim


Support for emotion 10

Emotion 10 has been released and react-emotion deprecated in favor of @emotion/styled.
See the migration guide here: https://emotion.sh/docs/migrating-to-emotion-10

Sorry, been away from from a bit. This should roll out soon as v1.0

@Betree - should be good to go. please let me know if you have any issues


aliases for tool backend

right now the [aliases] portion of mise.toml is designed for tool versions:
[alias.node]
lts = "20"

however, what we don't have is a way for us to do this with the tool backend:
[alias]
docuum = "cargo:docuum"

I'm not sure how we might want to present this. The above is my first thought, but it wouldn't allow having both aliased versions and aliased backend, so that would need to be figured out. A couple of alternatives:
[default_backends]
docuum = "cargo:docuum"

[registry]
docuum = "cargo:docuum"

"registry" might be ideal here since it maps reasonably well to the codebase, and maybe it could allow for alternate registries like we have for the old asdf-specific shortname stuff

I have what I think is a practical example of the usefulness of this.
I was trying to use the ubi backend with https://github.com/psastras/sarif-rs. The project publishes each cli tool it has as separate releases as opposed to a zip of all tools. I couldn't figure out a way to make it so I could grab multiple cli tools from the same source.
Something like perhaps:
[registry]
sarif-fmt = "ubi:psastras/sarif-rs"
shellcheck-sarif = "ubi:psastras/sarif-rs"

[tool]
sarif-fmt = "sarif-fmt-v0.6.6"
shellcheck-sarif = "shellcheck-sarif-v0.6.6"

That said my issue might be hinting more at a way to have multiple versions of the same tool (with an alias for the command) active at the same time.

thinking about this more I'm starting to prefer this as the config:
[alias]
docuum = "cargo:docuum"
[alias.node.versions]
lts = "20"

Then if you want to alias the name and the versions:
[alias.node]
name = "altnode"
versions = {lts = "20"}

Of course this would still do the same thing for backwards-compatibility, but I probably would remove it from the docs:
[alias.node]
lts = "20"

I'm trying to test this but it doesn't seem to work… am I using it right?
[tools]
rust-analyzer = "2024-10-21"
[alias]
rust-analyzer = "ubi:rust-analyzer/rust-analyzer"

$ RUST_BACKTRACE=full mise install --verbose --verbose
…
TRACE  1 [src/config/mod.rs:91] config_paths: ["/home/tomi/.config/mise/config.toml"]
TRACE  1 [src/file.rs:151] cat ~/.config/mise/config.toml
TRACE  1 [src/config/config_file/mise_toml.rs:91] parsing: ~/.config/mise/config.toml
TRACE  1 [src/config/mod.rs:108] config: Config {
    Config Files: [
        "~/.config/mise/config.toml",
    ],
    Aliases: {
        "rust-analyzer": Alias {
            full: Some(
                "ubi:rust-analyzer/rust-analyzer",
            ),
            versions: {},
        },
    },
}
DEBUG  1 [src/toolset/mod.rs:177] install_versions: rust-analyzer@2024-10-21
TRACE 16 [src/cache.rs:129] reading ~/.cache/mise/ubi-rust-analyzer-rust-analyzer/remote_versions-308df.msgpack.z
The application panicked (crashed).
Message:  Pre-condition of install_version violated: ctx.tv.backend().backend_type == self.get_type()
Location: src/backend/mod.rs:424

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 7 frames hidden ⋮
   8: mise::backend::Backend::install_version::panic_cold_display::h0f39cf1b060a97d4
      at <unknown source file>:<unknown line>
   9: mise::backend::Backend::install_version::hb81e72d33ecf14ac
      at <unknown source file>:<unknown line>
  10: std::sys::backtrace::__rust_begin_short_backtrace::ha532bcb1e3a0268c
      at <unknown source file>:<unknown line>
  11: core::ops::function::FnOnce::call_once{{vtable.shim}}::h76b2f83f951e502e
      at <unknown source file>:<unknown line>
  12: std::sys::pal::unix::thread::Thread::new::thread_start::hcdbd1049068002f4
      at <unknown source file>:<unknown line>
  13: start_thread<unknown>
      at ./nptl/pthread_create.c:447
  14: __GI___clone3<unknown>
      at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.

And then with
[tools]
stylua = "0.20.0"
[alias]
stylua = "ubi:JohnnyMorganz/StyLua[exe=stylua]"

I get
DEBUG  1 [src/toolset/mod.rs:177] install_versions<EMAIL_ADDRESS>Error:
   0: No repository found for plugin ubi:JohnnyMorganz/StyLua[exe=stylua]

Location:
   src/plugins/asdf_plugin.rs:79

Version:
   2024.11.9 linux-x64 (01b7d8b 2024-11-13)

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 2 frames hidden ⋮
   3: mise::plugins::asdf_plugin::AsdfPlugin::get_repo_url::hb16368ea7a51e16e
      at <unknown source file>:<unknown line>
   4: <mise::plugins::asdf_plugin::AsdfPlugin as mise::plugins::Plugin>::install::hd83a98779f0b8581
      at <unknown source file>:<unknown line>
   5: <mise::plugins::asdf_plugin::AsdfPlugin as mise::plugins::Plugin>::ensure_installed::h7ff8ca041caad607
      at <unknown source file>:<unknown line>
   6: mise::toolset::Toolset::install_versions::h5c5f6cd6b47fbfdf
      at <unknown source file>:<unknown line>
   7: mise::cli::Commands::run::hb56a6fa380ec3d7a
      at <unknown source file>:<unknown line>
   8: mise::cli::Cli::run::h94fd88e10d07547b
      at <unknown source file>:<unknown line>
   9: mise::main::h997cac13f6acb388
      at <unknown source file>:<unknown line>
  10: std::sys::backtrace::__rust_begin_short_backtrace::hdf707c4efda7a634
      at <unknown source file>:<unknown line>
  11: main<unknown>
      at <unknown source file>:<unknown line>
  12: __libc_start_call_main<unknown>
      at ./csu/../sysdeps/nptl/libc_start_call_main.h:58
  13: __libc_start_main_impl<unknown>
      at ./csu/../csu/libc-start.c:360
  14: _start<unknown>
      at <unknown source file>:<unknown line>

it won't do anything if the plugin is already installed with that name

it won't do anything if the plugin is already installed with that name

Okay, fair enough, but the stylua = "ubi:JohnnyMorganz/StyLua[exe=stylua]" alias still doesn't work even if after I uninstall:
$ mise install
mise ERROR failed to install<EMAIL_ADDRESS>mise ERROR Failed to install with ubi<EMAIL_ADDRESS>HTTP status client error (404 Not Found) for url (https://api.github.com/repos/jc00ke/asdf-stylua/releases/tags/v2.0.0)
mise ERROR Run with --verbose or MISE_VERBOSE=1 for more information

You do not need [exe=stylua] in this case, just use lower case repo name: "ubi:JohnnyMorganz/stylua".


Crunched file does not run and crashes.

Hi Tony,
I tried all possible combinations of switches.
Either I get an empty screen (-i) or it is stuck at run.
Without -i I can, manually start from Vice Mon with G 8400. (quedex.prg) wokrs fine with TinyCrunch.
qloader.prg starts but wen ending instead of loading run/stop Restore happens.
Same Loader works fine with TinyCrunch.
quedex.prg, qloader.prg and qloader_ts.prg
files.zip
Best regards
Stefan

Hi Stefan, and thanks for giving TSCrunch a go.
The problem here is in the file dump that you have, spanning $0800 to
$ffff, thus overwriting the nmi and irq vectors.
Crunching data anywhere in $0000-$ffff is supported for mem crunching only,
both regular and inplace. Self executable files though, can only be
crunched in $0100-$ffbf (actually a bit more than that on certain files...).
Trimming the source file (which doesn't seem to have data in that area
anyways) to $0800-$ffbf makes it crunchable.
Support for $0100-$ffff self executable files might still happen in a
future version, though!
Thanks
On Tue, Jan 31, 2023 at 1:02 AM MacGyver4B @.***> wrote:

Hi Tony,
I tried all possible combinations of switches.
Either I get an empty screen (-i) or it is stuck at run.
Without -i I can, manually start from Vice Mon with G 8400. (quedex.prg)
wokrs fine with TinyCrunch.
qloader.prg starts but wen ending instead of loading run/stop Restore
happens.
Same Loader works fine with TinyCrunch.
quedex.prg, qloader.prg and qloader_ts.prg
files.zip https://github.com/tonysavon/TSCrunch/files/10541396/files.zip
Best regards
Stefan
—
Reply to this email directly, view it on GitHub
https://github.com/tonysavon/TSCrunch/issues/3, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMSYTCSTOU5SNTMI7PRT5XLWVBQCXANCNFSM6AAAAAAUL2E63M
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


fix(publish): adds quotes around workingDir

running
yalc publish

from a path containing spaces, eg /Users/me/Cool Project/blah was failing with an error:
/bin/sh: line 0: cd: /Users/me/Cool: No such file or directory

Adding quotes around options.workingDir fixes it for me, maybe others had this issue too?

the unit tests miss this one, as this block isn't covered in the tests (scriptRunCmd is always empty string in the tests)
if (scriptRunCmd) {
    const scriptNames: (keyof PackageScripts)[] = [
      'preyalc',
      'prepare',
      'prepack',
      'prepublishOnly',
      'prepublish'
    ]
    const scriptName = scriptNames.filter(name => !!scripts[name])[0]
    if (scriptName) {
      const scriptCmd = scripts[scriptName]
      console.log(`Running ${scriptName} script: ${scriptCmd}`)
      execSync(scriptRunCmd + scriptName, execLoudOptions)
    }
  }

is this repo maintained? anyone looking at PRs?

published


FALLING edge interrupt not being installed properly

I'm using bone script 0.2.4, node.js v0.8.22 on a BBB.
uname -a gives:
Linux beaglebone 3.8.13 #1 SMP Thu Sep 12 10:27:06 CEST 2013 armv7l GNU/Linux
Using pin p8_12, when I attach an interrupt of type bonescript.FALLING, I actually get an interrupt of type bonescript.CHANGE. Attaching an interrupt of type bonescript.RISING works as expected.
What should happen:
Attaching an interrupt of type bonescript.FALLING should attach an interrupt which is triggered on the 1 -> 0 change of the input pin state only.

This issue was moved to beagleboard/bonescript#20


Object prototype compatibility...

Would you mind wrapping the for..in loop with a hasOwnProperty check on line 395 of lib\view.js?
for (var key in dynamicHelpers) {
    if (dynamicHelpers.hasOwnProperty(key)) {
        this.__dynamicHelpers[key] = dynamicHelpers[key].call(
            this.app
          , this.req
          , this);
    }
}

If a library or application extends the object prototype the above code will protect from invalid key references.
Thanks!
-Marcus

You should add the property using enumerable: false in the property descriptor. Read up on Object.defineProperty.

In my case the library is not exclusively built for ecma5 so backwards compatibility would not be achievable. And even if it were ecma5 exclusive, there are still a number valid use cases of wanting functions on the object prototype to be iterable which is why hasOwnProperty is part of the language spec.
Thanks!

-1 from me I dont want to slow down internals just for enumerables

@visionmedia What's your performance degradation threshold? Or rather, how much do you think the hasOwnProperty check will slow it down by? And would you consider including it if I optimized any portion of the view class to make up for the thousandths of a second?

I just dont think we should have to change code in another framework just because something was not defined on Object.prototype properly

@MarcusPope What valid reason is there for making an enumerable property on Object.prototype? I can't think of any.
Also, if backwards compatibility is a concern, conditionally define the property such that when Object.defineProperty exists you use that, otherwise just use a regular property set.

hmm, well that sucks.  It's certainly proper to define functions on the object prototype as enumerable, that's why the option exists for defineProperty.  But blindly iterating over objects as hashes is a bad practice in JavaScript because for..in loops were designed to enumerate all properties of objects not just the local properties of your "hash".
What is the harm in making express.js more compatible/bug-free?  Performance loss would be infinitesimal and I would honor my offer of submitting a performance patch to make up for it.  You don't even have to use hasOwnProperty(), you could use typeof xxx === 'function' which would protect the code from both prototype extensions and users accidentally adding objects instead of functions to the dynamicHelpers object.
Anyway, there's no use beating a dead horse if you are just firmly against fixing this bug by adding one line of code to your codebase.  But you should look to others as models, Jade, MongoDB, NodeUnit, Fomatto, Geddy, Jake and a slew of other frameworks all use hasOwnProperty checks because it's the right thing to do.
Cheers!

if performance really is the issue here you could also iterate over Object.keys with a for loop, which seems to be the fastest solution in V8.
http://jsperf.com/hasownproperty-vs-for-in/8
"Object.keys returns an array whose elements are strings corresponding to the enumerable properties found directly upon object. The ordering of the properties is the same as that given by looping over the properties of the object manually."
win-win i'd say

@TooTallNate

I can't think of any.

reflection, dynamic code generation, polymorphism, function overloading and the likes are all made easier to implement and clearer to read when prototype iteration is available.
And the conditional definition of properties as not enumerable doesn't work for my purposes, the property set is dynamic and manually walking the prototype chain with getOwnPropertyNames doesn't allow for distinguishing between properties that are intended to be enumerable and those that are not.
@klaemo Good suggestion, it has my vote.  Though I doubt performance is really the issue here since the object being iterated over is a hash of functions designed to run on every request.  It would most likely contain a dozen or so keys and even at 100 keys the performance loss would be meaningless by comparison to the 100 functions being executed.
In the meantime I'll just keep hacking this one line of code in if I continue to use express, or I'll disable dynamicHelpers via the config options if I find they don't add value to my use-case.
Anyhoo, thanks y'all, it's been an interesting thread!

for/in without hasOwnProperty is only bad practice because of legacy browser issues, extending the object proto with non-configurable/enumerable/writable props is just bad news in general

reflection, dynamic code generation, polymorphism, function overloading and the likes are all made easier to implement and clearer to read when prototype iteration is available.

 If you want to see how reflection is implemented, take a look at util.inspect's source code.
Haven't you read: http://erik.eae.net/archives/2005/06/06/22.13.54/ :p
But seriously, always set enumerable: false when extending Object.prototype...

personally I wish property descriptors did not exist, and no special casing for getters/setters etc as well but that's for a different argument :D

I'm fine with Object.keys(), but hasOwnProperty() is something I hope to never see again, it's very rarely a need

I agree that hasOwnProperty() is really only needed because of legacy purposes. This is node and we are blessed with only having to worry about 1 JS implementation, so I can see why TJ is reluctant.
Anyways, #1034 implements the ECMA5-y fix for this: https://github.com/visionmedia/express/pull/1034/files

The proposed fix seems very simple and I don't think it warrants the back and forth that has happened here. I can't imagine the "performance" loss is anything meaningful and I agree with @MarcusPope. Please don't loose pragmatism just to adhere to some belief about how the language should work.

@shtylman certainly but that doesn't mean people should not argue / educate eachother, it's not a personal attack

@visionmedia completely understood, I just felt like there was a lot of discourse and no patch. I only saw the pull request after I commented. I will butt out of the convo now :)

@shtylman the thing is any lib that goes and augments Object.prototype with enumerable props is going to indirectly affect other libraries, that's just how it is. One might not have a problem with dynamic helpers after such a patch but you will run into this in other places, not just enumerating objects, it's code smell


Code hygiene: Use types rather than interfaces

Update to declare types over interfaces.
•	Hooks, immer, and recoil will all prefer types over interfaces to avoid prototype breaks
•	Infer types when possible - there are some places where types are over-declared
•	We can leverage inferred types to help the code require less maintenance and not assume mismatched type

This is an ongoing thing across releases, so closing for R11


installer should work with a partition instead of a full disk

Is your feature request related to a problem? Please describe.
You can only install the OS on a full disk. But for people who want to dual boot it would be useful to simply install the OS on a single partition.

A single partition would be doable however there should be a detection strategy to know if a partition (exisiting one) is a efi or boot partition. This partition should then be mounted so that the fstab can be generated properly and can then be used to install grub or rEFInd on.

This issue was closed by accident.

Before fixing this issue and the #31 issue the installer should be rewritten. But before such a big change can be implemented we must do a few things. I recommend we do the following.
Build a simple tool not written in bash but written in another more scalable language eg python, go or something simular. the written application should be an API that is then sourced by a certain frontend eg ncurses or qt. We should thus have 3 different repositories. Backend api -> qt frontend, ncurses frontend

I will leave another comment here once the backend and basic frontend is provided. We will first work on that (providing the same functionality as now) before implementing these issues

This should be added in the latest installer (at least in the api) however this functionality is not present in the frontend


Something is sending R/xxxxx/system/0/Serial all the time

Something is sending R/xxxxx/system/0/Serial all the time
an I get a lot of MQTT Messages with "#"
Before I installed "bus-mqtt-devices" I had only the keepalive payload items.

I don't believe this has anything to do with the driver itself. The driver does not publish to those topics.

Ok, I have to search somewhere else.
It's just that I had the keepalive items been send, and now I have thousands of messages.


Support Symfony 6.1

Pull Request
What does this PR do?
Adds Support for Symfony 6.1 with resolved deprecations
PR checklist
Please check if your PR fulfills the following requirements:

[ ] Does this PR fix an existing issue?
[x] Have you read the contributing guidelines?
[x] Have you made sure that the title is accurate and descriptive of the changes?

bors merge


Add SQL schema from Botwinder.core

We should add the SQL schema from Botwinder.core to more easily get started with the website locally.

Possibly use Xethron/migrations-generator instead to allow for different database engines rather than MariaDB for development

Fixed in 38a722006831e9258d033aed005a758bfc40d808


[MKLDNN] Independent gradients requests check with respect to weights and bias of convolution

Description
As it was described in #15464, MXNet with MKL-DNN gives a wrong gradient of a convolution with respect to its biases unless the gradient with respect to its weights is also requested. In the implement of convolution with MKL-DNN, only request for gradients with respect to weights is checked. It should be checked independently for bias.
Checklist
Changes

[x] Independently check the requests for gradients with respect to weights and bias of convolution.
[x] Convolution can give the gradient with respect to any one of weights or bias.

Comments

No comments.

@pengzhao-intel @ciyongch @TaoLv Please help me review on this PR. Thanks. 😃

Could you try to add a UT for this case?

Could you try to add a UT for this case?

Sure. The exists UT passed with this PR on a local test. I will add some UTs for checking the correctness of the results of the gradients' requests combinations.

@matteosal Could you help to verify this PR with the test case in your project?

The example of https://github.com/apache/incubator-mxnet/issues/15464 is fixed here, but I see a failure with this one, where the weights gradient is requested in isolation (so the opposite of https://github.com/apache/incubator-mxnet/issues/15464 ):
import mxnet as mx

sym = mx.sym.Convolution(
	mx.sym.Variable('in'),
	mx.sym.Variable('w'),
	mx.sym.Variable('b'),
	kernel=(1, 1),
	num_filter=1
)
args = {
	'in': mx.nd.ones([1, 1, 3, 3]),
	'w': mx.nd.ones([1, 1, 1, 1]),
	'b': mx.nd.ones([1]),
}
grad = {
	'in': mx.nd.zeros([1, 1, 3, 3]),
	'w': mx.nd.zeros([1, 1, 1, 1]),
	'b': mx.nd.zeros([1]),
}
req = {'in': 'null', 'w': 'write', 'b': 'null'}
outgrad = mx.nd.ones([1, 1, 3, 3])

ex = sym.bind(mx.cpu(), args, args_grad=grad, grad_req=req)

ex.forward(True);
ex.backward(out_grads=outgrad);
mx.ndarray.waitall()

This is what gets printed to command line:
Traceback (most recent call last):
  File "script2.py", line 27, in <module>
    mx.ndarray.waitall()
  File "/home/matteo/Git/mxnet/python/mxnet/ndarray/ndarray.py", line 166, in waitall
    check_call(_LIB.MXNDArrayWaitAll())
  File "/home/matteo/Git/mxnet/python/mxnet/base.py", line 253, in check_call
    raise MXNetError(py_str(_LIB.MXGetLastError()))
mxnet.base.MXNetError: std::exception

It doesn't fail on master

@matteosal I tested your example with commit 9ca042, and it ran successfully without any exception. Could you test it again with commit 9ca042?

@matteosal I tested your example with commit 9ca0428, and it ran successfully without any exception. Could you test it again with commit 9ca0428?

Ops sorry, I've missed that commit. Yes, it works on that

@matteosal Thanks. That's great. I am working on a unit test for this feature. Then we can merge it to master after further review and verification.

@pengzhao-intel @TaoLv Please re-review on this PR. It should be noted that the new unit test function will be unevaluated in context of GPU because of the possible precision degradation resulted from the autotuned cudnn convolution. From a local test, the autotuned convolution has no more than 1.0% mismatches compared to a non-autotuned one, when any of the gradient request is set to be null (atol=1e-3, rtol=1e-3).

he possible precision degradation resulted from the autotuned cudnn convolution.

How much degrade from GPU? Could we set a low bar for GPU?

I will take some tests to see whether a low bar works.

@TaoLv  @ciyongch please take a reveiw too.

@mxnet-label-bot add [MKLDNN, pr-awaiting-review]

@ciyongch The equality assertion error happened with the outputs of convolution forward when any of the gradients requests (x, w, b) was null.  Not sure about whether the Backward process drops the numerical precision.

Thanks for your contribution. Merging now :)


fix: dev pack start auto remove cache

Codecov Report

Merging #17 into master will increase coverage by 0.04%.
The diff coverage is 77.77%.

@@            Coverage Diff             @@
##           master      #17      +/-   ##
==========================================
+ Coverage   66.78%   66.83%   +0.04%
==========================================
  Files          32       32
  Lines        2008     2017       +9
  Branches      492      495       +3
==========================================
+ Hits         1341     1348       +7
- Misses        614      616       +2
  Partials       53       53

Impacted Files
Coverage Δ

packages/faas-dev-pack/src/common.ts
83.33% <77.77%> (-5.56%)
:arrow_down:

Continue to review full report at Codecov.

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


Screen Cast Mode UI Indicator

In screencast mode, show an indicator in the UI that allows toggling on/off (like auto-attach)

@joaomoreno I'd love to take this one as well @joaomoreno

Closing as out of scope.


Add support for callbacks

This is a different take based on @dead-horse's pr.

Coverage remained the same when pulling b05923c45ba14fb209c0a7ff833ff37b4842aa3b on seegno:feature/add-support-for-callbacks into 27fa50bad00b65a1e664ca085c65acd8c5988572 on thenables:master.

finally landed this patch https://github.com/thenables/thenify/commit/2308efeb46764871a9733f87a765d8855328ef67

thanks!

Awesome, thanks!


🐛 biome.lspBin didn't work after update to latest extension

VS Code version
1.87.0
Extension version
2.2.1
Biome version
1.5.3
Operating system

[ ] Windows
[X] macOS
[ ] Linux

Description
I use settings biome.lspBin to find my biome,however, it doesn't work after today I update this extension.And I rollback to v2.1.2, it still works.
"biome.lspBin": "./common/autoinstallers/rush-format/node_modules/@biomejs/biome/bin/biome",

Maybe you should well test before publish.I'm tired of finding new bugs...
I will keep use old versions.
Steps to reproduce
Use the same settings and will fail in the latest extension.
Expected behavior
work as before.
Does this issue occur when using the CLI directly?
No
Logs
No response

Maybe you should well test before publish.I'm tired of finding new bugs...
I will keep use old versions.

Hi @SleepDevil,
Thanks for opening this issue. I understand your frustration with this bug and apologize for any inconvenience it has caused.
It's important to remember that our project is open source, and as such, it relies on contributions from the community, including testing and reporting bugs. While we strive for quality releases, it's not always possible to catch every issue before publishing. Your input is crucial in helping us identify and address these issues effectively.
However, I must emphasize that while feedback is encouraged, it's essential to maintain a respectful and constructive tone in our communication. Comments that include personal attacks or derogatory remarks are not in line with our community guidelines.
That being said, I've released v2.2.2, which should solve this issue. Please try it and let me know if it does.

In fact, I mean no hostility, if you feel offended, I'd like to say sorry to you.
I just want to report a bug, and it's really frustrated when you open vscode and update this extension, and you find something went wrong. Especially when I've met too many bugs with the same extension.
Last, thanks for your work.