Drop needs_reboot conditional in _check_status(...)

Description
This pull request adds juju-reboot to the _check_status(...) function so that the machine will automatically restart if it needs security updates applied. Using juju-reboot helps with automatic deployments as a human-operator is not required to manually intervene when the slurmctld charm is first deployed.
One thing to note is that _check_status(...) is becoming too complex. The linter throws an error unless # noqa C901 is applied to the function. We should set some time aside to identify how we can simplify evaluating the current state of the slurmctld charm.
How was the code tested?
I tested this charm on a private OpenStack instance with<EMAIL_ADDRESS>base images that needed security updates to be deployed.
Checklist

[x] I am the author of these changes, or I have the rights to submit them.
[x] I have added the relevant changes to the README and/or documentation.
[x] I have self reviewed my own code.
[ ] All requested changes and/or review comments have been resolved.

Might want to retry the integration tests. I checked the formatting of the integration environment dependencies in tox.ini and everything seems to be in order. If it fails again, I will see if there is any encoding issues with the file.

Might want to retry the integration tests. I checked the formatting of the integration environment dependencies in tox.ini and everything seems to be in order. If it fails again, I will see if there is any encoding issues with the fil

Turned out to be a missing = for one of the test dependencies :clown_face:

Hey @NucciTheBoss, I've re-run the integration tests a few times, but it keeps failing. Any idea?

Hey @NucciTheBoss, I've re-run the integration tests a few times, but it keeps failing. Any idea?

The issue here is that the integration tests are timing out due to the machines having "Machine needs reboot" status. This behavior seems to be the same across slurmctld, slurmd, and slurmrestd. It looks like the Ubuntu images that Juju is pulling do not have the latest updates applied. Without any way to reboot the machines from outside the pipeline, the source charm (the slurm charm packed inside the pipeline) is waiting for the other slurm charms pulled from Charmhub to successfully start. Since the charms from Charmhub are indefinitely waiting for a reboot, the source charm times out waiting for the relations from the other charms.
We can get around this by letting this pull request through and manually publishing the charms so that they no longer get stuck on needing a reboot, or we wait for when the LXD images are updated so they have the newest slate of updates applied. Let me know your thoughts on this.

Let's move forward with this.


Fix consignment processing

Found some bugs on the consignment processing procedure. I thougt a single PR should ease review, but if needed I'll split this in more PRs.

In Runtime::process_consignment the bundle is stored as a Vec<(NodeId, BTreeSet<u16>)>, but then Collector::process tries to deserialize it into a TransitionBundle like this:
let bundle: TransitionBundle = store
    .retrieve_sten(db::BUNDLES, witness_txid)?
    .ok_or(StashError::BundleAbsent(witness_txid))?;

I've changed how the bundle is stored, assuming we want to store the whole transition bundle and not just concealed transitions.

Then I've changed the way we access the revealed seals, from transition.revealed_seals() to transition.filter_revealed_seals() because the first was always returning an empty list (not sure this is the correct fix or if we should fix the revealed_seals method).

Finally, I added a check (if transition_id.to_vec() == contract_id.to_vec() { continue }) that prevents checking the transition if it refers to the genesis. This check prevents the following failure:
LocalFailure { code: Unknown, message: "transition 50914c89fdc796bcc680b680c4878e39cd3050f5e3a349e63a2d37c46e01dd23 is absent.\nIt may happen due to RGB Node bug, or indicate internal stash inconsistency and compromised stash data storage." }

when looking for the genesis transition. Even here I'm not sure this is the correct fix.

Moreover, after these fixes I'm still struggling to properly receive assets. It seems the ConfidentialSeal never gets "opened" and consequentely saved in the OUTPOINTS table by the receiver, which fails sending the received assets with the following error: UnrelatedInput(OutPoint { txid: 605ee06bd0ae230e8b6d3da92a03448b36f0dbe8f3b991c499955a9a12003932, vout: 1 }).

In Runtime::process_consignment the bundle is stored as a Vec<(NodeId, BTreeSet<u16>)>, but then Collector::process tries to deserialize it into a TransitionBundle

That is a clear bug, thank you for catching and fixing.

Then I've changed the way we access the revealed seals, from transition.revealed_seals() to transition.filter_revealed_seals() because the first was always returning an empty list (not sure this is the correct fix or if we should fix the revealed_seals method).

The difference between revealed_seals and filter_revealed_seals methods is that the first one fails if any of the seals are concealed. Since it was followed by unwrap_or_default it resolved into an empty vec. So yes, this is a bug and you correctly fixed it by using right filter_* method there.

Finally, I added a check (if transition_id.to_vec() == contract_id.to_vec() { continue }) that prevents checking the transition if it refers to the genesis.

This is strange, since the way node_ids are collected they should not contain genesis id ever. We need to make sure we do not miss some other bug here. Also pls see my review comment on non-allocating comparison of two ids.

Moreover, after these fixes I'm still struggling to properly receive assets.

From what I heard from Federico it seems you was able to solve that lately?

This is strange, since the way node_ids are collected they should not contain genesis id ever. We need to make sure we do not miss some other bug here.

That's good to know, thanks. So the correct fix should not be avoiding processing the genesis ID but instead to make it not appear in the node_ids list at all. I'll give it a look and find where it gets accidentally added.

From what I heard from Federico it seems you was able to solve that lately?

Kinda. I'm using this commit https://github.com/crisdut/rgb-node/commit/494ca080f41b820b8b44561538b241c65a9cf1c3 with a little change for opret. But I'm not sure we really need an accept_transfer API. From what I can see the accept method is implemented very similar to the consume_transfer API (some ops overlapping), so couldn't we just enhance the consume_transfer API so that it takes the revealed seal as an optional parameter and tries to open the concealed seal if that's given?

Kinda. I'm using this commit crisdut@494ca08 with a little change for opret. But I'm not sure we really need an accept_transfer API. From what I can see the accept method is implemented very similar to the consume_transfer API (some ops overlapping), so couldn't we just enhance the consume_transfer API so that it takes the revealed seal as an optional parameter and tries to open the concealed seal if that's given?

Hi @zoedberg,
I made a branch with support to reveal a conceal seal using consume_transfer method.
Were you thinking of something like that?

https://github.com/crisdut/rgb-node/tree/feat/consume-reveal

Were you thinking of something like that?

@crisdut yes, more or less. The Reveal object you used doesn't include the close method. So either we should directly get an optional seal::Revealed (which includes the close method), or deduce that from somewhere else. Moreover I tried your commit 2ddbf6b (including some little changes for opret and the code of this PR) on rgb-lib tests and it seems that something is missing in this implementation, since I receive an error on spending the received assets. Right now I don't have time to investigate this, sorry, but thanks for your contribution. Maybe here we should first wait @dr-orlovsky to see if he agrees on having a single API with optional reveal and then evenually fix your commit

@crisdut yes, more or less. The Reveal object you used doesn't include the close method. So either we should directly get an optional seal::Revealed (which includes the close method), or deduce that from somewhere else.

Make sense! I will start tests with opret and update the code.

Moreover I tried your commit 2ddbf6b (including some little changes for opret and the code of this PR) on rgb-lib tests and it seems that something is missing in this implementation, since I receive an error on spending the received assets.

Thanks for feedback, I will check it,

Hi @zoedberg , I found the bug.
I did not save the new transition in transitions and transition_txid tables. Also, I added the CloseMethod property at the Reveal object.
Contract state before spend asset:

Contract state after spend asset:

I was able to spend an asset received, and I used the change address twice.
I made the tests with this branch (I merged the fix/process_consignment branch with feat/consume-reveal)

https://github.com/crisdut/rgb-node/tree/exp/prs

PS: I tested only tapret dbc. I will start tests with opret (I never used this).

Thank you @zoedberg for updating the PR. I propose to continue discussion for the rest of the questions which were not covered in this PR elsewhere - since with merge we can lose the track of them.

Linking my answer to @zoedberg question here, since it looks that I put it into a wrong PR: https://github.com/RGB-WG/rgb-node/pull/204#issuecomment-1250233053


inferencing my trained model

Hi there,
getting error when trying to inference using the trained model:
(udet) home@home-lnx:~/programs/Line-Segmentation-Model$ python demo.py -t single -i ./data/test_images/0.jpg -o ./result -m ./output/000301.pth
Traceback (most recent call last):
  File "demo.py", line 100, in <module>
    model.load_state_dict(torch.load(args.model_weight, map_location=args.device))
  File "/home/home/anaconda3/envs/udet/lib/python3.7/site-packages/torch/nn/modules/module.py", line 830, in load_state_dict
    self.__class__.__name__, "\n\t".join(error_msgs)))
RuntimeError: Error(s) in loading state_dict for UNet:
	Unexpected key(s) in state_dict: "up1.up.weight", "up1.up.bias", "up2.up.weight", "up2.up.bias", "up3.up.weight", "up3.up.bias", "up4.up.weight", "up4.up.bias".
	size mismatch for down4.maxpool_conv.1.double_conv.0.weight: copying a param with shape torch.Size([512, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
	size mismatch for down4.maxpool_conv.1.double_conv.0.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.1.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.1.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.1.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.1.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.3.weight: copying a param with shape torch.Size([512, 512, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
	size mismatch for down4.maxpool_conv.1.double_conv.3.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.4.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.4.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.4.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.4.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for up1.conv.double_conv.3.weight: copying a param with shape torch.Size([256, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([128, 256, 3, 3]).
	size mismatch for up1.conv.double_conv.3.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up1.conv.double_conv.4.weight: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up1.conv.double_conv.4.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up1.conv.double_conv.4.running_mean: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up1.conv.double_conv.4.running_var: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up2.conv.double_conv.3.weight: copying a param with shape torch.Size([128, 128, 3, 3]) from checkpoint, the shape in current model is torch.Size([64, 128, 3, 3]).
	size mismatch for up2.conv.double_conv.3.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up2.conv.double_conv.4.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up2.conv.double_conv.4.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up2.conv.double_conv.4.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up2.conv.double_conv.4.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up3.conv.double_conv.3.weight: copying a param with shape torch.Size([64, 64, 3, 3]) from checkpoint, the shape in current model is torch.Size([32, 64, 3, 3]).
	size mismatch for up3.conv.double_conv.3.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).
	size mismatch for up3.conv.double_conv.4.weight: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).
	size mismatch for up3.conv.double_conv.4.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).
	size mismatch for up3.conv.double_conv.4.running_mean: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).
	size mismatch for up3.conv.double_conv.4.running_var: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).

I am sorry, my mistake, you can check the ìnee

Hi there,
getting error when trying to inference using the trained model:
(udet) home@home-lnx:~/programs/Line-Segmentation-Model$ python demo.py -t single -i ./data/test_images/0.jpg -o ./result -m ./output/000301.pth
Traceback (most recent call last):
  File "demo.py", line 100, in <module>
    model.load_state_dict(torch.load(args.model_weight, map_location=args.device))
  File "/home/home/anaconda3/envs/udet/lib/python3.7/site-packages/torch/nn/modules/module.py", line 830, in load_state_dict
    self.__class__.__name__, "\n\t".join(error_msgs)))
RuntimeError: Error(s) in loading state_dict for UNet:
	Unexpected key(s) in state_dict: "up1.up.weight", "up1.up.bias", "up2.up.weight", "up2.up.bias", "up3.up.weight", "up3.up.bias", "up4.up.weight", "up4.up.bias".
	size mismatch for down4.maxpool_conv.1.double_conv.0.weight: copying a param with shape torch.Size([512, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
	size mismatch for down4.maxpool_conv.1.double_conv.0.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.1.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.1.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.1.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.1.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.3.weight: copying a param with shape torch.Size([512, 512, 3, 3]) from checkpoint, the shape in current model is torch.Size([256, 256, 3, 3]).
	size mismatch for down4.maxpool_conv.1.double_conv.3.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.4.weight: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.4.bias: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.4.running_mean: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for down4.maxpool_conv.1.double_conv.4.running_var: copying a param with shape torch.Size([512]) from checkpoint, the shape in current model is torch.Size([256]).
	size mismatch for up1.conv.double_conv.3.weight: copying a param with shape torch.Size([256, 256, 3, 3]) from checkpoint, the shape in current model is torch.Size([128, 256, 3, 3]).
	size mismatch for up1.conv.double_conv.3.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up1.conv.double_conv.4.weight: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up1.conv.double_conv.4.bias: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up1.conv.double_conv.4.running_mean: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up1.conv.double_conv.4.running_var: copying a param with shape torch.Size([256]) from checkpoint, the shape in current model is torch.Size([128]).
	size mismatch for up2.conv.double_conv.3.weight: copying a param with shape torch.Size([128, 128, 3, 3]) from checkpoint, the shape in current model is torch.Size([64, 128, 3, 3]).
	size mismatch for up2.conv.double_conv.3.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up2.conv.double_conv.4.weight: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up2.conv.double_conv.4.bias: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up2.conv.double_conv.4.running_mean: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up2.conv.double_conv.4.running_var: copying a param with shape torch.Size([128]) from checkpoint, the shape in current model is torch.Size([64]).
	size mismatch for up3.conv.double_conv.3.weight: copying a param with shape torch.Size([64, 64, 3, 3]) from checkpoint, the shape in current model is torch.Size([32, 64, 3, 3]).
	size mismatch for up3.conv.double_conv.3.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).
	size mismatch for up3.conv.double_conv.4.weight: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).
	size mismatch for up3.conv.double_conv.4.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).
	size mismatch for up3.conv.double_conv.4.running_mean: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).
	size mismatch for up3.conv.double_conv.4.running_var: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([32]).

Hello,
It’s my mistake not to include bilinear parameter in the demo file. I have updated the code, you can check the change in demo.py file (line 99)

https://github.com/tson1997/Line-Segmentation-Model/blob/05db96ecba520c66146cc42f4808ac8ebae7e24f/demo.py#L99

thanks


Drag & Drop support

Have you thought of adding drag & drop handling? I'd be interested in trying to work on it if you're not already doing so and think it would be a good addition.

Went ahead and made a PR (#10 ) for this if you're interested :-)

Merged #10


Problemwith exportation

Script failed to scan birthdays.
Error message: eyJ0eXBlIjoiU0NBTl9FUlJPUl9USU1FT1VUIn0=

The issue is solved in https://github.com/zagushka/birthday-calendar-extractor/pull/94


Warning of possible problems with firebase messaging

I set up Batch in a flutter project for IOS and android following the documentation found at https://doc.batch.com/flutter/sdk-integration/
My problem is that because it is configured for Android, it uses firebase messaging. And Firebase Messaging causes some warnings in the log when launching on IOS.
Warning:
Launching lib/main.dart on iPhone 14 Pro Max in debug mode...
lib/main.dart:1
Xcode build done.                                           26.8s
Batch started with a DEV API key
Installation ID: 18A985DC-05CC-4644-9D52-77336A3D9547
⚠ Firebase has been detected in your application, but Batch's manual integration has NOT been enabled.
⚠ This can cause issues with Batch's handling of notifications:
⚠ Direct Opens, Mobile Landings and Deeplinks might not work
⚠ More info about the manual integration here: https://batch.com/doc/ios/advanced/manual-integration.html
⚠ The App Group 'group.br.com.cetelem.app.debug-dev.batch' hasn't been configured. See the documentation for more info: https://doc.batch.com/ios/advanced/app-groups
2
Push token (Apple Push Sandbox/Development): 8081638f20fdc7cfd0c8b98057f1f4bda038aad69200a19685de0c54ded743570de86dafcd87408afa67f63785fb87a936aa0631ef3d1a23937cbf188c66a685d5388c2b410c17b0f8357dcc09bcbeff
Connecting to VM Service at ws://<IP_ADDRESS>:49840/-CQRczbeRkk=/ws

I don't use firebase messaging in IOS, but because I use it on android I get these warnings... I believe it is a bug, as I have no intention of using firebase messaging for IOS but Batch itself uses it to handle Android notifications.
my flutter version:
╰─ flutter doctor                                                                                ─╯
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.7, on macOS 13.0.1 22A400 darwin-arm, locale en-BR)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 14.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.3)
[✓] VS Code (version 1.73.1)
[✓] Connected device (3 available)
[✓] HTTP Host Availability

Hi,
While the log is somewhat outdated (it does not cause issues with Direct Opens/landings/etc... since UNUserNotificationDelegate), Firebase can cause Batch to fail to get the APNs token.
Unfortunately there is no good way to know if Firebase is configured or simply there in the code, so the log is triggered when Firebase classes are noticed in your app. This does trigger false positives in multiplatform projects, but has the side effect of informing you that you are shipping unused Firebase code in your iOS app.
I have two suggestions:

If you only want FCM, try not to use the plugin but integrate it manually in the Android project
Try to remove the firebase Pods from your iOS project

I opened an internal ticket to update the log, but removing it is not planned.
Have a nice day,
Arnaud


lxc list consumes ~15-20 % of cpu

lxd 2.4
lxc 2.4
ubuntu 16.04
LXC list consumes lots of CPU.
I am working on a project, which needs to poll lxd every 2 seconds and update list of containers.
I am doing exec of "lxc list" to get the list of containers and their state.
I thought of writing a query to poll from lxd.db, however, it contains only the names of the containers, but their state (running/stopped/frozen) wasn't  available in the DB.
Is there any file, which I can read to obtain the state of the container ?
watch lxc list

The reason why "lxc list" is so expensive is because it's a very very expensive operation.
On the client side to get half reasonable performance, the command hits at least 2 API endpoints for every listed container, it does that in parallel to make things as fast as possible.
On the server side, LXD needs to talk to LXC over a unix socket to query the state, look in the database for snapshots, inject code inside the container to pull its IP addresses out, ...
So yes, scripting around "lxc list" in a tight loop is probably not the best idea, or at least not with the default arguments for it.
What information is it that you want exactly?

(And to answer the obvious question, the container can change state on its own without talking to LXD or LXD even running. The LXD database only stores information which LXD itself controls, the rest is retrieved from the source.)

I am scripting to  monitor the host and container resources which are running, and want to trigger the migration if the container is consuming x% of host's resources to the one with high-end configuration.
I am reading the containers resources data from /sys/fs/cgroup//lxc/ files
and using the "lxc list" to obtain the state of the containers.
As an alternative, I can populate data from db, and then see if container name found in /sys/fs/cgroup directory structure and make it work.
Was curious why it's consuming lots of resources.
In short, I am looking at the resource usage information, of all containers.

Using - - fast should make a massive improvement for you

Hmm..
Thanks for a clear explanation. :)


FastAPI memory usage pile up and OOM error

It seems that after calling an endpoint (at least news-upload presents this behaviour), memory usage will not recover to the levels prior to calling. This eventually leads to OOM errors. Check the links below with relevant issue threads regarding this.

https://github.com/tiangolo/fastapi/issues/1624
https://github.com/tiangolo/fastapi/issues/596
https://fastapi.tiangolo.com/async/

FYI: Seems the issue still persists.


Add option to show git last commit time in short format

Added option to display git last commit time stamp in the old simplier format of days, minutes, hours or seconds.

This was beginning to annoy me, I was about to start working on it. Thank you so much!

Just a small info, in case you are running the version with this PR you should update it. I pushed another commit that fixed trailing whitespaces. Also, for short minutes, no time was being displayed because it missed the color in the colorize function. See 6af74ad

Thanks, awesome. I did hacked it in a few mins to get it to work and get the idea across, didn't tested it thought out.


added outline for product logos

Reason for change

Some of the logos look good, some look ok, and some look bad. Here's a list of the one's that I think look better, about the same, or worse with this change. This is all personal preference though.

Product
👍
🤷♂
👎

ZeroSix

✅

OAuth.io (needs higher res logo)
✅

Elegant CMS
✅

Aiven Cassandra

✅

Aiven Elasticsearch

✅

Aiven Kafka

✅

Aiven PostgreSQL

✅

Aiven Redis .

✅

Dumper

✅

JawsDB Maria

✅

JawsDB MySQL

✅

JawsDB PostgreSQL

✅

LogDNA
✅

Timber

✅

CloudAMQP
✅

IronCache
✅

IronMQ
✅

MemCachier

✅

Mailgun
✅

Posthook
✅

Scaledrone

✅

Till

✅

Aiven Grafana

✅

InfluxDB
✅

Informant
✅

Scout

✅

StatusHub
✅

Blitline

✅

Custom Image regognition

✅

Generic Image Tagging

✅

HyPDF

✅

Piio

✅

Valence

✅

Ziggeo

✅

Bonsai Elasticsearch

✅

Websolr

✅

Cloudcube

✅

Prefab.cloud

✅

IronWorker
✅

PDFShirft

✅

Testing
Open various products in the marketplace component to see how the logos appear with the outline.

Codecov Report

Merging #111 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #111   +/-   ##
=======================================
  Coverage   53.03%   53.03%
=======================================
  Files          30       30
  Lines         709      709
  Branches      164      164
=======================================
  Hits          376      376
  Misses        331      331
  Partials        2        2

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 80f8d97...fe4bb8d. Read the comment docs.

lol I love the comparison table

@ntassone WDYT?

Wow looks awesome!


Try avoid putting run commands into shell history

A user in https://github.com/microsoft/vscode/issues/192943#issuecomment-1720167002 is using profile environments to try workaround source and run commands being added to shell history, leading to more problems:

I actually need this to prevent VS Code from cluttering my shell history, otherwise my history is filled up with entries such as source /some/path/.venv/bin/activate.fish and /some/path/.venv/bin/python /some/path/src/myscript.py or subsequent commands I tried for that specific project which are irrelevant as my shell history in my general day to day usage!

Shells have various ways of avoiding adding entries into history. For example in bash you can add a space to the start of the command to have it not enter history. There are also some HIST* variables that define how history behaviors which are worth a read.

Related issues: https://github.com/microsoft/vscode-python/issues/7041 https://github.com/microsoft/vscode/issues/85887 https://github.com/microsoft/vscode-python/issues/9316 https://github.com/microsoft/vscode/issues/85887 https://github.com/microsoft/vscode/issues/87779
This is less of a problem now that we don't send activation commands in terminal, only when executing or debugging a file, which is maybe okay to put in shell history.
https://github.com/microsoft/vscode/issues/87779 hints that debugging is maybe solved now?

This is less of a problem now that we don't send activation commands in terminal, only when executing or debugging a file, which is maybe okay to put in shell history.

Ideally the extension shouldn't be adding anything to history imo.

Thank you for submitting your feature request and everyone who considered it! Unfortunately, this issue did not receive enough votes over the allotted time, and so we are closing the issue.

I think this would essentially be fixed by adding a single space in front of some of the sendText activation commands.

@Tyriar For debugging, the DAP client in VSCODE has to do this. Debugger just does a run-in-terminal request.

@karthiknadig if you put a space in front of the command you request, some shells will not add it to history

@Tyriar This feels like VS Code should handle it at least for debugger scenarios. Then it would be something that is controlled by a setting in VS Code, than something that every DAP server has to implement.

@karthiknadig perhaps, not sure it's been brought up with the debugger folks. The main example this was issue was specifically about the activate command which is still an option I believe

The main example this was issue was specifically about the activate command which is still an option I believe

For now, but may very well go away once terminal activation is solid enough to launch to a 100% of stable.


[RFC] Support empty lists

The main use case for this is that we want to turn on "implicit derive" in a future PR, where all children that don't use an explicit @derive annotation get an automatic "@derive(,)" behavior added internally, so that inheritance automatically gives you the functions you expect without extra boilerplate.  This raises the potential for someone to want to override this behavior.  One obvious way that jumps to mind to do that is "@derive([],[])", meaning "derive nothing please". Alternatives could include the addition of an @noderive annotation, which might be cleaner, particularly if we want to avoid empty list support everywhere.  But maybe we want empty lists anyways.

My current leaning after having implemented this is that @noderive might be a cleaner way to handle the "don't derive" use case, and empty lists could easily be error-prone.  There's a lot to be said for just not allowing them.  That said, empty lists are common and useful, and I don't imagine we'd have to work too hard to come up with other use cases, particularly if we start adding "foreach" support or something.
@matt-sheets @l0kod any thoughts?

My current leaning after having implemented this is that @noderive might be a cleaner way to handle the "don't derive" use case, and empty lists could easily be error-prone. There's a lot to be said for just not allowing them. That said, empty lists are common and useful, and I don't imagine we'd have to work too hard to come up with other use cases, particularly if we start adding "foreach" support or something.
@matt-sheets @l0kod any thoughts?

For syntax I like the @noderive better than the @derive([],[]) for general readability.
But with that being said supporting an empty list is probably not a bad thing, if we have a viable use case.  We may run into situation where the code assumes the list has content, but we probably shouldn't be making that assumption anyway and fixing it should be straightforward.

supporting an empty list is probably not a bad thing, if we have a viable use case

I'm not overly convinced we do.  The two use cases illustrated here are

giving an AV rule no perms, causing to to be removed entirely.  I guess that could potentially be desirable?  It probably needs higher level list processing constructs that we don't have yet to actually be useful.  Maybe something like a call that takes multiple arguments, one of which is a list of perms, the empty list could be used to omit the rules referencing that list?  I'm not convinced that wouldn't be really confusing for users though, and I don't have a concrete "this is why you might want that as a policy writer" sort of use case.
The @derive case that's the key motivator, but I think I agree with you that @noderive is more clear

We may run into situation where the code assumes the list has content, but we probably shouldn't be making that assumption anyway and fixing it should be straightforward.

Yes, that seems mostly fair.  That said, our sexp generating code will happily take empty lists and output invalid CIL from them.  Off the top of my head, I'm not sure where CIL takes an empty list.  So we'd have to take extra care that we never actually output anything from a list that's non-empty.  We maybe should do that, but doing it thoroughly and well and having confidence may be a higher effort than I've put into this PR so far.


Find the user's configuration file doesn't work for Chemacs 2 users

The code in init.el checks for the two usual locations of emacs configs , but not if you are using Chemacs 2.
Sorry my emacs lisp-FU is extreme novice level, and have no idea how to correct it.

I have Chemacs2 working on Windows, but only if I edit early-init.el. And that is because I didn't install it in the folder that the documentation recommends. Which is either ~/.rational-emacs or ~/.config/rational-emacs.
So I edited early-init-el from:

(defvar rational-config-path
  (let ((home-dir (getenv "HOME")))
    (if (file-exists-p (expand-file-name ".rational-emacs" home-dir))
      (expand-file-name ".rational-emacs" home-dir)
    (expand-file-name ".config/rational-emacs" home-dir)))
  "The user's rational-emacs configuration path.")

to:

(defvar rational-config-path user-emacs-directory)

and that makes it work for me.
I'm not sure why rational Emacs has to be installed to a specific location and not just use the built in variable user-emacs-directory. And on Windows there is no HOME variable by default, so that could also cause problems.
You don't say what OS you're on but if you try to change early-init.el as above it might work for you.

I'm on MacOS (m1)  and Linux , though I only tested it on the Mac.
Thanks

This is an interesting conundrum. The reason is due to the fact we are looking for the rational-emacs-path in the early-init.el file, and we need to know fairly explicitly where to find that path. Initially, we used the ~ alias for the HOME folder, but as was mentioned in #19 that may not exist on Windows. I have a patch for that implementation in #32, but that only barely alleviates the problem here.
I can think of a couple of improvements:

Use an environment variable, ala RATIONAL_EMACS_HOME, the fall back will be the APPDATA/HOME implementation in #32.
Move the load of the early-config.el file from the rational-emacs-path to much earlier in the file so it can override everything. The side-effect here is the need for checks on everything to see if has already been set, or something along the lines of "ignore this setting" types of variables. Thus we end up with code like: (unless keep-tool-bar-p (push '(tool-bar-lines . 0) default-frame-alist)) for people who want to keep the toolbar mode activated (or whatever... just an example).

There might be other approaches as well, just some ideas in case someone wants to pick this up (I'd be happy to do it, but I'd prefer @daviwil  mention a preferential direction - which might be none of the above, and that's super fine with me).

PR created for this issue, @harryfrogfather or possibly @sdaaish , could you review please and/or test? Let me know your feedback and I'll update the PR as necessary.

@jeffbowman So I tested this both with and without Chemacs, and it seems to work. I submitted a PR in your repo for a typo in early-init.el But with that change it works.
So:

Chemacs in ~/.emacs.d
Rational-emacs in ~/rational-test
Rational-config in ~/rational-config

And that worked for me. Tested in Windows with a clean setup (sandbox) where HOME is in $env:APPDATA, the default.
The only thing is the personal config-files needs the same structure with ~/rational-config/.config/rational-emacs so this might be mentioned in the README.
I set the environment-variable in the shell, but have not tested the variant with it set in .emacs-profiles.el.

@sdaaish Thanks!! I have installed chemacs to try to figure out the issue. It should not create an additional .config/ structure in your rational config folder. I have completely rewritten the logic now, it seems to work for me and my neophyte/naive usage of chemacs, seems to also continue to work without chemacs. I'd appreciate it if you could pull the changes from my branch and test one more time. And thanks for the PR to fix the spelling error I had!

Sure thing.
The number of test-cases increases with the options, so it's hard to keep track of them now… But I tested two of them anyway. Long story below.
The short story: It worked as expected what I can see.
Testing
Two tests, both with Chemacs2 and custom installation of rational_emacs. The second one with custom config path. Both cases with Windows 11 in a sandbox. Use of emacs built in $HOME variable wich is the same as ${env:AppData} in Windows.
test 1
Chemacs, custom installation of rational-emacs.
Installation
# Clone emacs repositories
& git clone https://github.com/plexus/chemacs2.git $env:AppData/.emacs.d
& git clone -b more-friendly-for-chemacs https://github.com/jeffbowman/rational-emacs.git $env:AppData/rational-test

~/.emacs-profiles.el
(("default" . ((user-emacs-directory . "~/rational-test"))))

rational-config-path
rational-config-path is a variable defined in ‘early-init.el’.
Its value is
"c:/Users/WDAGUtilityAccount/AppData/Roaming/rational-test/rational-emacs"

Documentation:
The user’s rational-emacs configuration path.

rational-config-file
rational-config-file is a variable defined in ‘init.el’.
Its value is
"c:/Users/WDAGUtilityAccount/AppData/Roaming/rational-test/rational-emacs/config.el"

Documentation:
The user’s configuration file.

Result
By adding a local config to $HOME/rational-test/rational-emacs/config.el the setup works with Chemacs2. $HOME is in this case the same as $env:Appdata.
So the test was successful.
test2
chemacs, custom installation and custom config-path.
Installation
# Clone emacs repositories
& git clone https://github.com/plexus/chemacs2.git $env:AppData/.emacs.d
& git clone -b more-friendly-for-chemacs https://github.com/jeffbowman/rational-emacs.git $env:AppData/rational-test

~/.emacs-profiles.el
(("default" . ((user-emacs-directory . "~/rational-test"))))

rational-config-path
rational-config-path is a variable defined in ‘early-init.el’.
Its value is
"c:/Users/WDAGUtilityAccount/AppData/Roaming/my-rational-emacs-config"

Documentation:
The user’s rational-emacs configuration path.

rational-config-file
rational-config-file is a variable defined in ‘init.el’.
Its value is
"c:/Users/WDAGUtilityAccount/AppData/Roaming/my-rational-emacs-config/config.el"

Documentation:
The user’s configuration file.

user-emacs-directory
user-emacs-directory is a variable defined in subr.el.

Value
"~/rational-test/"

Result
The test was successful, rational-emacs found config.el in the correct directory and loaded it without any errors.
Output
From test2.

Chemacs2
Custom installation of rational-emacs.
Custom config path.
Use of environment variable RATIONAL_EMACS_HOME.

Fantastic!! Thanks for the help!! I'm going to update the docs then see if @daviwil will merge the update.

With the merge of #38 can this issue be closed?
@harryfrogfather @daviwil

yes it looks ok from my perspective


Fix Image.iterator() returning address of local

On stage 2 in debug mode this causes stack corruption.

This is already fixed in stage2_compat branch: https://github.com/zigimg/zigimg/commit/6fdc604021236a223f91042dd6664dc09fd45097

The stage2_compat branch has been merged into master with the fix :)


Make use of trailing semicolons optional

Many programmers are no longer using a semicolon to terminate code lines in languages where it's optional. Our team doesn't use trailing ; when programming in TypeScript and/or JavaScript. However, when Intellisense inserts a line, it automatically terminates it with ;. Would be really helpful if the option whether to end each line with a semicolon or not was configurable globally per language. Then, Intellisense and other plugins could honor it to make one's coding more efficient.

VSCode Version: 1.18.1
OS Version: macOS High Sierra 10.13.1

Steps to Reproduce:

Remove import statement for an existing type
Accept Intellisense suggestion to add import statement
When import is added  a ; is auto added at the end of the line

Reproduces without extensions: Yes

Can you please explain what specific action is triggering the semicolon to be inserted?

Sure. It's just as I wrote in the description pretty much.

Let's say I write this line where IAd is a new type:

const ad: IAd = ctx.request.body

The Intellisense kicks in and suggests me to import it, i.e.

I accept the suggestion and this is what's added to the import block. Note the trailing ;

import IAd from './ad.interface';

I'd like to be able to instruct VS Code that I don't use ending semicolons in some language, e.g. TypeScript, JavaScript etc. And then have Intellisense, plugins, snippets to honor that setting. Currently, I have to take care of the semicolons myself and that makes coding less efficient.
Hope this helps. Please let me know if you need more info.

Thanks for the additional info. This falls under https://github.com/Microsoft/TypeScript/issues/18780 and  https://github.com/Microsoft/TypeScript/issues/19882
Using the TSlint workaround from the SO question may help for now: https://stackoverflow.com/a/47667384/306149
Closing as upstream

@mjbvz Thanks. Will those cover other languages (besides TypeScript) that also have ; optional?

Yes, those issues apply to both JavaScript and TypeScript. The TypeScript project is what provides our JS language support


[5.1 Early] [ModuleInterface] Escape Type and Protocol when they're type members

Previously, we wouldn't escape Type and Protocol at all in the
ASTPrinter, which lead to unfortunate build failures while compiling an
interface.
Instead, make sure we escape them whenever we print a name that's a type
member. Except for methods, which are erroneously allowed to be called
Type and Protocol.
rdar://49858651
(Cherry-pick of #24111 to 5.1-early because I barely missed the branch time)
Originally reviewed by @jrose-apple and @nathawes

@swift-ci Please test


Source as table doesn't generate vector_layers key

vector_layers key is a required (do not know why) of tilejson and should contain at least all ids and fields of the source.
For example, it is the easy way to find what to put in source-layer field of map.addLayer method.
Quick view of what I am talking about:

And in tests martin have it too:
https://github.com/maplibre/martin/blob/9e5ed2fc02a7815f1e32b44bcc7a882e763898af/tests/expected/auto/mb_mvt.json#L23-L33

That test is for .mbtiles file which has that content as part of the metadata table. We will need to generate something similar for postgres. Thx for reporting.

ok, implemented first pass, need some feedback ^


Handling GIs

In light of https://github.com/epiforecasts/EpiNow2/issues/806 and https://github.com/epiforecasts/EpiNow2/pull/799#issuecomment-2383651483, we should probably implement our own check or handling for GIs with density on day 0. I'd think that would go here:
https://github.com/CDCgov/cfa-epinow2-pipeline/blob/418d027cdce91b433dd3d10e227b715f4aa3631d/R/fit_model.R#L112-L120
The correct way to handle this is a bit subtle because there's a few conflicting things going on:

We'll want our own check because we're running an older version of EpiNow2 (at least until #9)
We're updating the formatting in some way in https://github.com/cdcent/cfa-parameter-estimates/issues/67, so we'll want this to respect whatever that formatting is. It's a bit tricky here if that doesn't include a left-hand-side zero-pad because we'll have to guess whether to zero-pad or not. We wont be able to know whether an input is wrong except by convention.
We'll want the ability to backtest on the old GI to compare to old prod estimates to new model setups. I don't quite know how we do that -- is it to save the biased GI in a readable-for-EpiNow2 format? Something else?

And I'm not sure how to handle this so (2) and (3) are both achievable. It's not hard on the face of it because we could make (1) a warning, but https://github.com/epiforecasts/EpiNow2/issues/806 makes up-to-date EpiNow2's check an error. So we'd need to reformat our old estimate to be both different and still wrong if we want to be able to do a true backtest once we bump the version.
I think the answer is probably we throw a warning and zero-pad the left-hand side of the PMF here if the PMF is not already zero-padded. And we overwrite the old PMF to be knowingly biased by zero-padding the current prod estimate so we can reproduce old behavior. Thoughts @athowes @kgostic?

ping @athowes. I think final resolution here is dependent on https://github.com/cdcent/cfa-parameter-estimates/issues/67 but that's marked as V2. Do you have guidance on how I should handle here?

For the time being until V2 we are going to do zero PMF at zero and include left pad with zero as output of cfa-parameter-estimates.


CLI error output

Any time there's an error, the usage text is output. It seems like a legitimate error (as opposed to mis-use of the cli) should just output the error text:
# ./amtool silence expire d08ead34-1119-400a-a1bb-2788853fc520
Error: expired silence must not be modified
Usage:
  amtool silence expire [flags]

Global Flags:
      --alertmanager.url string   Alertmanager to talk to
      --config string             config file (default is $HOME/.amtool.yml)
  -o, --output string             Output formatter (simple, extended, json) (default "simple")
  -q, --quiet                     Only show silence ids
  -v, --verbose                   Verbose running information

This should just be
# ./amtool silence expire d08ead34-1119-400a-a1bb-2788853fc520
Error: expired silence must not be modified

That's my opinion, anyway. Thoughts?
@mxinden @fabxc @brancz @kellel

Is there a --help flag? If so we can omit the usage text and just add something along the lines of: For further help run "amtool --help"

https://github.com/prometheus/alertmanager/pull/724
I did the linking of pr to issue incorrectly


should we have a LICENSE.md and a CONTRIBUTING.md here?

We can link to them from the readme and have them be seen at this level to encourage participation

CODEOWNERS too


How to disable first row selection

By default, in all examples, it seems the first row always starts selected. How can I prevent that, making the selection occur only after an user clicked a row?

Show your code, by default the code doesn't selects the first row..

I'd say the opposite.
In all examples the first row starts selected (unless you use selectMode: 'multi'). The same behavior replicates to my project.
I couldn't find any clue in the documentation on how to start my grid without selections.
Here is my configuration code:

Show Code
{
  editable: false,
  noDataMessage: 'No data could be found here.',
  actions: {
    add: false,
    edit: false,
    delete: false
  },
  columns: {
    titulo: {
      title: 'Name'
    }
  }
}

i have the same.

(Messy) Workaround:

Find data-set.js in your node_modules/ng2-smart-table;
Search for this.willSelect and override it with a 'none' string:

this.willSelect = 'none';

Explanation:
willSelect is what defines if the table will start with first or last row selected. But sadly the option is not exposed to the settings object, which means you can't change its behavior unless you change it directly in the component code.
So as of today you have three options:

Edit the code directly in your node_modules (as described above);
Clone this repo, submit a PR, and wait (or use your own fork in your project);
Copy the entire component into your project, instead of using it via npm install.

I was able to solve the problem of first click with this code made by me:
this.table.grid.dataSet.deselectAll();
this.table.grid.dataSet['rows'][0].isSelected = false;
this.table.grid.dataSet['selectedRow'] = null;

And to auto select the first row and populate the 'selected' class to well style the row:
setTimeout(function () {
   $($(`ng2-smart-table tbody tr`).first()[0]).trigger('click');
});

The two code snippets together solve the problem that the self-selecting row does not have the selected class.
I hope this small contribution will help someone.
Regards.

Hi to all, I've fixed this bug by my own and I've maded a pull request, if you're interested in.

Hi !
As the pull request of @NicolaLC has not been accepted yet, I've managed to select only the row that the user clicked on.
I use the LocalDataSource to store my data and when it changes ( new data loaded or pagination events ), I set the selected row of the user.
Here is the code I've made :
ngAfterViewInit() {   this.localDataSource.onChanged().subscribe(() => {       this.table.grid.dataSet.deselectAll();       if (this.dataSelected) {         this.table.grid.dataSet.getRows().map(           row => {             if (row.getData() === this.dataSelected) {               return this.test.grid.dataSet.selectRow(row);             }          });       }     }); }
Hope it will help ^^

The userRowSelect was supposed to handle it, but it seems that it doesn't work neither, and happen on the onInit.

Solution: The userRowSelect event supposed to handle it. Worked and solved for me
<ng2-smart-table [settings]="tableSetting" [source]="tableSource" (userRowSelect)="onSelectRow($event)"></ng2-smart-table>

This helps not triggering the initial select function. However, row one is still selected and thus will not trigger the userRowSelect function if the first row is clicked.

this.table.grid.dataSet.select(-1);

this.table.grid.dataSet.select(-1);

Just add selectedRowIndex: -1 to your table settings like this
tableSettings = {     hideSubHeader: true,     mode: 'external',     selectedRowIndex: -1   };

Humati's solution is perfect!

Just add selectedRowIndex: -1 to your table settings like this tableSettings = { hideSubHeader: true, mode: 'external', selectedRowIndex: -1 };

Not working for me

Just add selectedRowIndex: -1 to your table settings like this tableSettings = { hideSubHeader: true, mode: 'external', selectedRowIndex: -1 };

Works perfectly, thanks! Weird it's not in the docs.


Dark mode doesn't work on webkit.

This is highly likely to be a missing tailwind  property that is not necessary on other browsers.

After a brief inspection I found that the bug is related on how the hsl value of the background is declared. Hsl values are composed by three numbers. the 2nd and 3rd number are % values. Chromium and gecko browsers are tolerant to the missing % symbol on the declaration, but not webkit. Webkit will not convert 0 to 0%.
My suggestion is to change the following lines:
-     --background: 0 0 7%;
+     --background: 0 0% 7%;

Closed by mistake. wait until #2 is merged

Awesome, Thank you!


Allow fixing snapshots without disabling pytest rewriting

Yesterday a teammate asked if --inline-snapshot=fix could be enabled by default. I also think I'd quite like this. But it seems that the main problem is that doing so disables pytest rewriting, making assertions worse even in tests that aren't using snapshots.
While I understand that pytest rewriting interferes with executing, it seems there are still two ways that fixing snapshots can work in common cases without disabling rewriting:

In Python 3.11+, executing still works even inside pytest assertions, right?
If executing can't find the node, try (approximately, I'm simplifying and not checking this code) statement = only(ex.stmts); node = only(child for child in ast.walk(statement) if isinstance(...) and child.func.id == 'snapshot') or maybe something like assert isinstance(statement, ast.Assert); node = statement.value.operands[1]).

Either of these would suffice for us 100% of the time. All our uses of snapshot are of the form assert ... == snapshot(...), and although we support Python 3.8 we develop in Python 3.12.
It also looks like working without rewriting might be helpful for https://github.com/15r10nk/inline-snapshot/issues/41.

if --inline-snapshot=fix could be enabled by default.

This would mean that your snapshots are always fixed and your tests would always pass. I don't think that this is what you mean.
I think that I understand you wrong here and that the problem is that you found some incorrect snapshots when you run pytest the first time and that you have to run your test again when you want to fix the snapshots.
If this is the case then #48 might be helpful, because it would allow you to run
pytest --inline-snapshot-ui which would open a browser if your tests fail and give you the option to fix your snapshots without running pytest twice (yes, you are basically open the browser ui in this case to press a button. I could also ask in some different way for approval, but the approval is important).

In Python 3.11+, executing still works even inside pytest assertions, right?

The problem is that pytest changes the location of all sub-expressions in the assertion to the source range of the whole assertion.
https://github.com/pytest-dev/pytest/blob/2cba2237cdbff964854e7964986cdbe6855bf75e/src/_pytest/assertion/rewrite.py#L966C1-L968C49
We would need to change this in pytest if executing should work for expressions in assert statements. There might still be some problems for ast nodes which are generated by pytest to instrument the source, but the general idea should work.

If executing can't find the node, try ...

There are probably a lot of corner cases, because snapshot() can be used almost anywhere.
I started a pull-request some time ago https://github.com/alexmojaki/executing/pull/64 which I would prefer in this case.
It works similar to the PositionNodeFinder (uses lineno), but with some crazy mapping logic.
This should work for 3.8+.
I think the pull-request needs some more work, let me know what you think about the idea.
I can not promise 100% that everything will work, but there is a path.

It also looks like working without rewriting might be helpful for https://github.com/15r10nk/inline-snapshot/issues/41.

Definitely. This things are connected.

This would mean that your snapshots are always fixed and your tests would always pass. I don't think that this is what you mean.

That's 100% what I mean. I'm sure that changes to snapshots would not go unnoticed in the git diffs. And this would of course be disabled in CI.
Personally the way I use inline-snapshot at the moment is that I have a 'run configuration' for every test file that contains snapshots, and the configuration sets --inline-snapshot=fix. So I'm very regularly running entire files with fix even when I expect all the tests to pass, just because it's convenient like that. I only don't have fix when running all the tests or when running one test function.

The problem is that pytest changes the location of all sub-expressions in the assertion to the source range of the whole assertion.

I wonder why I seem to remember PositionNodeFinder working inside pytest assertions. Looking now I can see that it doesn't. Did something change, or am I just completely misremembering?

There are probably a lot of corner cases, because snapshot() can be used almost anywhere.

It wouldn't always work, but it usually would. My thinking is that pytest rewriting would still be disabled by default but that this would be configurable. So there'd be a way to fix while still having pytest rewriting, and if inline-snapshot failed to reliably find a node using any method at all it would raise an error.

I started a pull-request some time ago https://github.com/alexmojaki/executing/pull/64 which I would prefer in this case.
It works similar to the PositionNodeFinder (uses lineno), but with some crazy mapping logic.
This should work for 3.8+.
I think the pull-request needs some more work, let me know what you think about the idea.

Of course I would love this for executing even outside of inline-snapshot, but it's obviously a lot of work and I don't actually know if/when it'll actually happen, whereas I'm hoping that this proposal would be a lot easier.

I'm sure that changes to snapshots would not go unnoticed in the git diffs

The problem here is that I'm not so sure in the general case (for some random user at some time of the day (I know that I make a lot more mistakes when I'm tired :smile: .)).
I can not recommend your workflow for the average user which is using inline-snapshot for the first time. The probability that some snapshot are changed unintentionally is too height in my opinion.
I have nothing against your approach of making fix the default for you by creating a 'run configuration', if you know what you do.

Did something change, or am I just completely misremembering?

I don't know, it is also too long ago for me.

It wouldn't always work ...

The problem for inline-snapshot is that I would have to explain and document the cases where it does not work. It is not the best user experience when the user has to change his code almost randomly to make it work.
The way which I would prefer, is to change the code in pytest which currently changes the node locations. This should allow executing to find the nodes for 3.11+. This is also easy to explain for the user (feature x is only available for 3.11+).

The docs would be something like:

--keep-pytest-rewriting

Normally --inline-snapshot=fix/update/create disables pytest's assertion rewriting so that snapshot() can work reliably. This flag prevents that so that assertion error messages are more useful. This means that it's more likely that snapshot() can't tell where it's being called from, particularly if there's more than one snapshot() call in a single assert statement. If this happens, snapshot() will raise an error. This flag is not recommended for most users.

Anyway, I agree that if you can make it just work in 3.11+ with pytest, that'd be good too.


Bug Report: cupy.cumsum triggers an Out shape is mismatched error

Description
cupy.cumsum triggers an Out shape is mismatched error
To Reproduce
import cupy as xp
a1 = xp.ones((1, 1), dtype="int64")  # (1,1)
print(xp.cumsum(a1).shape) # output: (1,)
a2 = xp.empty((1), dtype="int64")  # (1,)
print(a2.shape) # output: (1,)
xp.cumsum(a1, out=a2)
print(a2)

Output:
(1,)
(1,)
Traceback (most recent call last):
  File "/code/test.py", line 6, in <module>
    xp.cumsum(a1, out=a2)
  File "/usr/local/lib/python3.10/dist-packages/cupy/_math/sumprod.py", line 159, in cumsum
    return _math.scan_core(a, axis, _math.scan_op.SCAN_SUM, dtype, out)
  File "cupy/_core/_routines_math.pyx", line 692, in cupy._core._routines_math.scan_core
  File "cupy/_core/_routines_math.pyx", line 709, in cupy._core._routines_math.scan_core
  File "cupy/_core/_kernel.pyx", line 1350, in cupy._core._kernel.ufunc.__call__
  File "cupy/_core/_kernel.pyx", line 654, in cupy._core._kernel._get_out_args_from_optionals
ValueError: Out shape is mismatched

Output show that a2's shape is the same as xp.cumsum(a1)'s shape, but xp.cumsum(a1, out=a2) triggers an Out shape is mismatched error.
Installation
Wheel (pip install cupy-***)
Environment
OS                           : Linux-6.8.0-49-generic-x86_64-with-glibc2.35
Python Version               : 3.10.12
CuPy Version                 : 13.3.0
CuPy Platform                : NVIDIA CUDA
NumPy Version                : 2.1.0
SciPy Version                : 1.13.1
Cython Build Version         : 0.29.36
Cython Runtime Version       : 0.29.37
CUDA Root                    : /usr/local/cuda
nvcc PATH                    : /usr/local/cuda/bin/nvcc
CUDA Build Version           : 12060
CUDA Driver Version          : 12040
CUDA Runtime Version         : 12060 (linked to CuPy) / 12020 (locally installed)
CUDA Extra Include Dirs      : []
cuBLAS Version               : 120201
cuFFT Version                : 11008
cuRAND Version               : 10303
cuSOLVER Version             : (11, 5, 2)
cuSPARSE Version             : 12101
NVRTC Version                : (12, 2)
Thrust Version               : 200600
CUB Build Version            : 200600
Jitify Build Version         : <unknown>
cuDNN Build Version          : None
cuDNN Version                : None
NCCL Build Version           : None
NCCL Runtime Version         : None
cuTENSOR Version             : None
cuSPARSELt Build Version     : None
Device 0 Name                : NVIDIA GeForce RTX 4070 Laptop GPU
Device 0 Compute Capability  : 89
Device 0 PCI Bus ID          : 0000:01:00.0

Additional Information
No response

Thanks, could you make a pull-request for this? @AnonymousPlayer2000


clarified upgrade mode per-user instead per-tenant

the upgrade mode of the users involved are relevant, not the upgrade mode of the entire tenant.

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@LolaJacobsen PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


MINOR :  Update NetworkClient.java

Removing reference to AK 1.0.0 to remove any potential confusion as such old version would unlikely be in use anymore
Committer Checklist (excluded from commit message)

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

@chia7712 I've update the PR title yes, thank you


cli: Improved error handling

Uppercase error message edited, part of fixing https://github.com/openservicemesh/osm/issues/4524
Signed-off-by: mudit singh<EMAIL_ADDRESS>
Description:

Testing done: NA

Affected area:

Functional Area

New Functionality
[ ]

CI System
[ ]

CLI Tool
[x ]

Certificate Management
[ ]

Control Plane
[ ]

Demo
[ ]

Documentation
[ ]

Egress
[ ]

Ingress
[ ]

Install
[ ]

Networking
[ ]

Observability
[ ]

Performance
[ ]

SMI Policy
[ ]

Security
[ ]

Sidecar Injection
[ ]

Tests
[ ]

Upgrade
[ ]

Other
[ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project?

Did you notify the maintainers and provide attribution?

Is this a breaking change?

Has documentation corresponding to this change been updated in the osm-docs repo (if applicable)?

Hi @jaellio @trstringer @nojnhuh @shashankram can I get a review on this, please.

Thanks, @schristoff @jaellio @shashankram for the review.


Support unconditional file generation

In order to support usage of a protoc plugin in bazel rules one needs to ensure that such plugin does always generate a file per each input file.
Would it be fine to add a feature to force a file generation? e.g. force feature which would just unconditionally return true as the result of GenerateFile(...)

Yeah that's not a problem. Feel free to open a PR. I think a better name would be -allow-empty


[choreolib] AutoChooser Fix: removed selected getter and added .instance for elastic

The .instance isn't needed for glass but it is needed for elastic so this just adds a dummy value of 0 as per the elastic source it's not used.


TaskID does not place in Integer

Hello guys.
When I started download task, library gives me negative task id. I guess id does not place in (int) primitive.
This problem occurs in big files.
I guess it will be fixed by replacing this type to (long).
       BaseDownloadTask.IRunningTask runningTask = FileDownloadList.getImpl().get(fileRow.getDownloadTaskId());
in this part runningTask will be null.

Below is the code for generating id:
    @Override
    public int generateId(String url, String path, boolean pathAsDirectory) {
        if (pathAsDirectory) {
            return FileDownloadUtils.md5(formatString("%sp%s@dir", url, path)).hashCode();
        } else {
            return FileDownloadUtils.md5(formatString("%sp%s", url, path)).hashCode();
        }
    }

You can see that the id is a hash code of the string, so it's reasonable that the id is negative sometime.


youtube seperate audio video streams are not playable?

Downloaded  using -f350 and -f280 on video https://www.youtube.com/watch?v=5jFNE8nMbxI. One is opus audio only and the other is 360 vp9 video only. After download, playing audio in VLC produces garbage noises. Playing video shows no video. In the past when I've accidentally downloaded video only, the video plays. Not sure what's wrong here.

I can confirm that something is wrong with this link (can't download or check video formats):
youtube-dl -v --geo-bypass -F https://www.youtube.com/watch?v=5jFNE8nMbxI
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', '--geo-bypass', '-F', 'https://www.youtube.com/watch?v=5jFNE8nMbxI']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2018.10.29
[debug] Python version 3.7.1 (CPython) - Linux-4.18.16-arch1-1-ARCH-x86_64-with-arch
[debug] exe versions: ffmpeg n4.0.2, ffprobe n4.0.2, rtmpdump 2.4
[debug] Proxy map: {}
[youtube] 5jFNE8nMbxI: Downloading webpage
[youtube] 5jFNE8nMbxI: Downloading video info webpage
ERROR: The uploader has not made this video available in your country.
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/youtube_dl/YoutubeDL.py", line 792, in extract_info
ie_result = ie.extract(url)
File "/usr/lib/python3.7/site-packages/youtube_dl/extractor/common.py", line 508, in extract
ie_result = self._real_extract(url)
File "/usr/lib/python3.7/site-packages/youtube_dl/extractor/youtube.py", line 1897, in _real_extract
raise ExtractorError(error_message, expected=True)
youtube_dl.utils.ExtractorError: The uploader has not made this video available in your country.
Other youtube links are passing well.

It's DRM protected.


Why stop-grad on actor's input state in imagine() function ?

Hi,
While I'm taking a close look in the imagine() function in the world model,
I wonder why the gradient from the input feature to the actor should be stopped.
WorldModel's imagine fuction (agent.py)
def imagine(self, policy, start, is_terminal, horizon):
flatten = lambda x: x.reshape([-1] + list(x.shape[2:]))
start = {k: flatten(v) for k, v in start.items()}
start['feat'] = self.rssm.get_feat(start)
start['action'] = tf.zeros_like(policy(start['feat']).mode())
seq = {k: [v] for k, v in start.items()}
for _ in range(horizon):
action = policy(tf.stop_gradient(seq['feat'][-1])).sample()
In my opinion, for the full gradient from the initial state to the last step of the sequence, shouldn't the 'feat' flow through the computation graph without the stop gradient? I just wonder why there is a stop gradient. have you tried the code without the stop gradient? What was the result like?
I'm struggling to find out the reason for the stop gradient and ask it here for help.
Thanks!

This just seemed like the safer choice. In practice it doesn't seem to make a difference last time I've tried a few years ago :)


do not merge unconsistent shell script

do not merge unconsistent shell change

Checkmarx One – Scan Summary & Details – 861d30f6-5d92-462c-a71f-2d29dfeaf442
No New Or Fixed Issues Found


Documentation how composeWith deprecates composeP

I have this super useful composition of async and sync functions:
import * as R from 'ramda';
import { promises as fs } from 'fs';

await R.composeP(
    console.log,
    JSON.parse,
    R.toString,
    fs.readFile,
)('path/to/file');

I did not manage to transfer the same behavior to composeWith which should replace composeP. Can someone point me to the documentation with an example?

You need to wrap the arguments to pipeWith(yourFunction( or composeWith(yourFunction) in an array.
The idea is that R.composeWith (R.andThen) does what composeP did, except that it now requires an array.  (We don't want to add any new variadic functions to Ramda.)
So that should be
await R.composeP (R.andThen) ([
    console.log,
    JSON.parse,
    R.toString,
    fs.readFile,
]) ('path/to/file');

You're right that this should be in the documentation.  Are you interested in creating a PR to add additional JSDoc examples for this?

cool thx! Yes When I find the time I will look for a PR to update the docs. So you mean
await R.composeWith (R.andThen) ([
    console.log,
    JSON.parse,
    R.toString,
    fs.readFile,
]) ('path/to/file');

not composeP

Why don't you want to introduce new variadic fns? I mean I get it in general but in this case I would prefer consistency to the known compose/pipe functions.

Yes, sorry, I meant composeWith.
We'd prefer consistency too, and sometime after v1.0, I'm hoping we'll make compse / pipe match this.   We'd really like to have no variadic functions remaining in the library.

Yeah totally. That would also help typing the whole library perfectly with TypeScript.

Pinging @vinnichase: Are you still interested in writing a PR for this?  If so, the documentation is generated from the JSDocs tags in the source file.

@CrossEye @vinnichase As I am not sure whether our documentation site can support multiple examples and whether it makes sense to document this in the latest version of the manual (we don't have composeP anymore), I chose to simply put this as a comment to #3218 for now.
Hope that's ok.


Move from RCLPY to RCLCPP (ROS lib from Python to C++)

Hello,
Thanks to @megmll, we now have benchmarks that show a performance increase up to 100x faster when using rclcpp (ros2 in c++) for sending eigen matrix over a topic, rather than using rclpy (ros2 for python).
(The benchmark in question https://github.com/MegMll/timings_ros2_conversion_msg)
Thus, we should move this part of the code to c++.
I think the interpolator node can be easily completely re-written in c++, but for the MPC node, if it is too annoying, we could just write a c++ lib that manage the ros messages and bind it to python...
Cheers

As this issue concerns the ROS architecture of the MPC and not the simple-mpc repo, I'm closing it.


Improved landing page UI and made responsive

added navbar , background animation , improved cards design , added animated footer section and made the landing page responsive

I want to contribute to this issue under JWOC , please assign me.

@shloksuman Great!! You nailed it 💯💯

Thanks for your kind words 😄


Problems using program in Sublime terminal

When I build this small prog in Sublime:
echo "What's your name? " var name: string = readLine(stdin) echo "Hi, ", name, "!"
my name is asked on (Sublime) terminal; when I type one and enter, nothing seems to happen.
Adding:
flushFile(stdout)
doesn't help.
Somehow the program is stalled ...
The code shown first works OK in a native terminal (cmdprompt).

Sublime text doesn't have a builtin interactive terminal.
Watch this video on how to set up Terminus:
https://www.youtube.com/watch?v=etIJMVIvVgg


Filter plate attachment should be sturdy

What has to be done
Acrylic that holds the air filters should not be bendy and floppy. Might require additional hardware attaching it to the main equipment frame.
How do you know it has to be done
It is floppy.
TODO: link video from MD 0.3 build
Code pointers
TODO
Don't forget

[ ] Put the issue in a milestone
[ ] Assign it to one of the projects
[ ] Add appropriate labels
[ ] Mention dependent/blocked issues if any

Seems that the just having more vertical supports may not be enough. Unlike the top, there is nothing to prevent the metal from flexing inwards. Might have to make side-tabs just like for the upper face plate to stabilize it with respect to the enclosure.

there is now an additional support in the middle of the filter panel
there are now tabs on the bottom of these supports to firmly attach to bottom enclosure plate and prevent forward flexing

These changes are checked-in in the branch addressing #957


Calculate nPr

Description
Calculate nPr in C++
Fixes #2096
Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings

Review my PR under LGMSOC'21 this is separate PR for Calculate nPr #2096 after deleting old Calculate_nPr.cpp
@Amit366 @ravikr126 @Ayush7614

I already merge your pr why you create duplicate pr??@sunilcoder36

It was for different issue #2095 and it was merged with PR #2097 this PR  was for issue #2096. You merged it with issue #2095


Suggestion: allow :close to be one of the allowed control opcodes

I think it may be a good idea to add :close atom value to allowed control opcodes, so that handle_in/2 and handle_info/2 could choose to push some data into the socket and close it immediately afterwards.
I ran into this issue while experimenting with moving a custom binary protocol websocket handler from Cowboy to Bandit with WebSock. Current implementation does some initial handshake-style message passing, and in case of failure it sends an in-protocol detailed error before closing the connection. I find it a valuable feature, especially for a binary protocol, since it allows giving the client some actionable context about a failed handshake.
I understand that I could do a send(self(), :do_close) call and a {:push, {:binary, error_message}, %{state | to_be_closed: true}} return, and add a special-case handler in handle_in/2 and handle_info/2 that would return a {:stop, :normal, state} tuple if the to_be_closed flag is set to true, but I think that allowing  :close atom is a more appropriate solution for this problem. It seems to me that the concern of "push some data and close right after" is a generic one

First up: I agree this is a valuable feature and something we should do!
In terms of mechanism, I'm a little anxious about allowing a :close tuple to be sent like {:push, {:close, 1000}, state}, mostly because the message parameter is allowed to be a list of frames to send, and so return values like {:push, [{:text, "Goodbye"}, {:close, 1000}, {:text, "Now what?"}], state} lead to some awkward edge cases. That's explicitly the reason that Bandit doesn't support sending close tuples except as a side effect of closing the connection.
I'd rather see a :stop tuple with an optional 'list of messages to send before closing' parameter; something like {:stop, :normal, code, msg, state} for the happy path, and {:stop, reason, code, msg, state} for the sad path.
WDYT?

Somewhat related to https://github.com/phoenixframework/websock_adapter/issues/2

{:close, code, messages, state} works for me. :stop as well.

@mtrudel, thanks for a prompt reply! I'm glad you're onboard with this feature existing.
I agree that Bandit's way of allowing a :close statement wherever in messages and just discarding the rest feels somewhat not-explicit. I think a :stop/:close tuple with an explicit list of messages to be sent is a good clear option.
Adding a 5-arity stop tuple to existing 3-arity and 4-arity feels reasonable, if maybe a bit hard to juggle with {:shutdown, :restart} value for the second tuple element. I think I mildly prefer :stop to :close because it conveys the fact that the websocket process is going to stop a little better, but I'm not sure I have much more to offer as far as my opinion goes.

I'll get this worked up in the next couple of days!

Candidate API change up for review at https://github.com/phoenixframework/websock/pull/12

Merged as part of WebSock 0.5.3, implemented in WebSockAdapters 0.5.4 & Bandit 1.0.0-pre.13, both just published.
Thanks for the suggestion!


Sentence splitter not working properly affecting part of speech tagger

Problem
I tried to run the sentence splitter submodule (sentence_splitter.py) but it didn't work in Greek language for me. I tried loading both el_core_news_sm and el_core_news_md  and also tried inserting and encoding text in unicode utf-8. However it does not recognize different sentences but sees them as one. At the same time this affects the part of speech tagger.
Do you have any idea what might the problem be?
Thanks in advance.
Environment
spaCy version:    2.1.4
Location:        /home/dimitris/.local/lib/python3.6/site-packages/spacy
Platform:         Linux-4.18.0-17-generic-x86_64-with-Ubuntu-18.04-bionic
Python version:   3.6.7
Models:           el, en

Hello, thanks for reporting this!
Could you please tell from where did you download the models?
Are you using spacy-nightly?

No, I downloaded the models from https://spacy.io/models/el . Should I use spacy-nightly?

Could you try uninstall spacy, install spacy-nightly, download the models through nightly and then check again?
Sorry for the trouble, I need to check if it is a version problem.

I tried but I faced the same problem .
In order to install models through spacy-nightly I used: python3 -m spacy install el_core_news_md .
Is that correct? Any other suggestion on something that I may did wrong?

I am facing the same problem after trying both.

The problem remains.
Is the development team working in it or has it been abandoned?
It is kind of important to know because if it is has been abandoned, we should turn to different solutions.


Move the dbs state tracking from config.json to a separate file

Addresses issue #27.

What you think

Not quite yet, but I'm getting there.

May want to update the README as well to indicate where the UUID can be retrieved from - it references config.json exclusively. The section that cites it talks about utilizing user-agent to whitelist proxy connections.

Thanks for catching that.  Updated.

Any thoughts, @micahsnyder ?  I'm happy to re-work anything, but I'd like to roll some variation of this out to our lab.

@micahsnyder Thanks for wrapping this up.  Sorry for dropping it, but I got pulled onto a long-running project at work and it fell off my priority list.  Ironically, today was my last day!  Glad it was a helpful start - I'll let my coworkers know to watch out for the next release..


Add eslint

Hello everyone, in advance I apologize for my English, I am French :p
I propose an integration of Eslint+Prettier !
Why?
If many dev work on the project but that each one has its own rules that may be a real site not readable!
I just made the integration, it is necessary to configure, for me it is with you to configure it with your way of seeing the things, if you wish to have a github actions which lint automatically ask me and I will set it up on this branch.
Hello from France.

Hi! thank you for doing PR for this, actually I've tried several eslint configuration, if you don't mind, can you tell me about the rules of the eslint? is it configured to have the same code too?

Eslint and prettier allows you to put rules in place to have a nice code, for example an indentation of 2 spaces, line breaks between each function, etc... to have all the rules: https://eslint.org/docs/rules/
Currently only recommendation rules are active!
To know that the final output code (so once compiled) is the same, the lint is only checked on TS files.
Currently a lot of warning and error because I did not take the time to correct, because I wait that you give your rules!

the warn and error is actually the things that's makes me think about it again, but i'll try it later

also, thank you for your contributions 👍


[Enhancement]: able to specify nodeport

Is there an existing issue for enhancement?

[X] I have checked the existing issues.

What would you like to be added ?
In some scenarios, user may want to specify nodeport on their own.
Why is this needed ?
No response
Additional information
No response

closed via #303


Added "slice-upstream-gm" script

Downloads PvPoke's gamemaster.json file and slices a list of root keys to smaller files under dist/data.
Usage:
npm run build; node ./dist/sandbox/slice-upstream-gm; ls ./dist/data/;

Hey I forgot to wipe out unrelated commits. Let me redo this.


Make tar import API async

We're currently using the synchronous tar library, so we need to
do bridging.  This pushes the bridging down a layer, changing
our tar import API to be async.
Then things will be even clear if we switch to e.g.
https://crates.io/crates/tokio-tar
But we need https://github.com/vorot93/tokio-tar/pull/3

Sorry for the delay! tokio-tar 0.3.0 targeting tokio 1 has been released.


OpenXR Toolkit does not show menu F1 on Pimax Crystal in Windows 11

Have Pimax Client running, OpenXR Toolkit companion app open and PimaxVR control center as well as OpenComposite
When in VR trying the Crystal it does not show the menu so I can't put my settings for 3080 as shown from Pimax and Disco-VR Tetiana in Youtube. What should I do. Have tried everything for the last 4 hours

Your game probably isn't using OpenXR. Also "F1" was never the key to bring up the menu.
Start attaching some log files if you want help, because as it is, your query is way too vague.
There's a troubleshooting guide here: https://mbucchia.github.io/OpenXR-Toolkit/troubleshooting.html

Thanks for your promt reply. I could now open the toolkit with F2 as said but with CTRL+F2
Have MSFS2020 and a Nvidia GeForce RTX 3080 video card, CPU is i7-13700K not overclocked.
Have tried all the settings of Tetiana from DiscoVR :"Best VR Performance of MSFS with RTX 3080. Opened Pimax Client, PimaxXR Control and Open Composite.
Result: I cannot read well instruments and outside view is not optimal. My Reverb G2 is much better except Brighntness of Pimax Crystal that is better. Note that Tetiana from DiscoVR changed overriding resolution from  the OpenXR  System Tab from 3531x5106 to 2685x3883 and that gave her maximum sharpness and performance. On my headset (also Crystal) I cannot set this resolution. If I go to 2685 it shows 2685x3177. Have tried various settings up or down but it is never sharp. The sharpest one was 2685x3177 but a lot less sharp than Reverb G2. Also the settings of Tetiana in Performance Tab under Size 47% do not result the same in mine.
Can you help me?
Attached my log file
On Saturday, August 19, 2023 at 12:22:51 AM AST, Matthieu Bucchianeri @.***> wrote:
Your game probably isn't using OpenXR. Also "F1" was never the key to bring up the menu.
Start attaching some log files if you want help, because as it is, your query is way too vague.
There's a troubleshooting guide here: https://mbucchia.github.io/OpenXR-Toolkit/troubleshooting.html
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Sorry, I'm only providing assistance with technical issues, not settings.
Settings are something for you to figure out and taylor specifically to your system. Can't help with that.

The MSFS forum has many threads about VR settings, you will get much better input there:
https://forums.flightsimulator.com/c/gd-commsupport/vr/227


parseJsonLogic is not returning correct query when trying to parse a rule with only a notIn operator

Steps to reproduce:

Construct the following rule with the query builder:
{  "combinator": "and",  "rules": [      {          "id": "052b6212-fac1-4aa3-9721-f6a3ec9fbd3b",          "field": "platform",          "operator": "notIn",          "valueSource": "value",          "value": [              "1",              "2",              "3"          ]      }  ],  "id": "f0b29b0a-d4e3-46ab-bd62-1a7a61d8d1a4" }

Parse the query to JsonLogic with the following function:
formatQuery(query, 'jsonlogic')

The output will be
{  "!": {      "in": [          {              "var": "platform"          },          [              "1",              "2",              "3"          ]      ]  } }

Parse the jsonLogic back to the query with following function:
parseJsonLogic({  "!": {      "in": [          {              "var": "platform"          },          [              "1",              "2",              "3"          ]      ]  } })

The output will be the following:
{field: 'platform', operator: 'notIn', value: '1,2,3', valueSource: undefined}

Try to format the output back to jsonLogic or try to import it:
formatQuery('{field: 'platform', operator: 'notIn', value: '1,2,3', valueSource: undefined}', 'jsonLogic')

Expected result:
The parseJsonLogic should return the query properly
Actual result:
The following error is thrown:

Uncaught TypeError: Cannot read properties of undefined (reading 'length')

Thanks for the bug report! Looks like it fails to wrap the rule result in a group object in some cases.
How urgent is this for you? I ask because I'm working on version 6 and it isn't quite ready yet, but I can probably put out a v5.4.1 patch fairly quickly if you really need it.

FYI the same problem exists when the operator is "notBetween".

@kyaruntsdavit I just published v5.4.1 with this issue resolved.

@jakeboone02 thank you very much for solving this. Sorry, I was away for a long time and did not have a chance to react to your messages.

No problem! Happy to help.


Refactor tailer and add tests

Codecov Report
Attention: 25 lines in your changes are missing coverage. Please review.

Comparison is base (b0a04f9) 78.60% compared to head (dababb8) 79.24%.
Report is 1 commits behind head on main.

Files
Patch %
Lines

...metheus/exporter/jgc/collector/parser/Parsers.java
65.71%
7 Missing and 5 partials :warning:

.../prometheus/exporter/jgc/tailer/TailerManager.java
50.00%
3 Missing and 2 partials :warning:

...us/exporter/jgc/collector/parser/GCAggregator.java
40.00%
2 Missing and 1 partial :warning:

...in/java/prometheus/exporter/jgc/tailer/Tailer.java
62.50%
2 Missing and 1 partial :warning:

src/main/java/prometheus/exporter/jgc/Config.java
50.00%
2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##               main      #67      +/-   ##
============================================
+ Coverage     78.60%   79.24%   +0.63%
- Complexity      121      126       +5
============================================
  Files            13       14       +1
  Lines          1631     1633       +2
  Branches        141      139       -2
============================================
+ Hits           1282     1294      +12
+ Misses          271      267       -4
+ Partials         78       72       -6

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fix: remove the get_data_catalog() function

This is related to #1713 and #1860 insofar that it removes the get_data_catalog() function. This is being done separately from the sub-crates work since it's easy enough to remove and frankly doesn't work properly anyways for Python users, which is the only caller we currently have in our codebase
Fixes #1860

@ion-elgreco I dunno, I strongly doubt people are using that functionality. The Unity catalog functionality is practically worthless IMHO since you have to have credentials for Unity catalog to lookup a table's location, and then a second set of credentials to actually access that storage.
IMHO it is not worth slowing changes for a couple reasons:

I think Unity is highly unlikely to be used by Python users in this way
We're not a 1.0 crate or wheel yet

I however defer to @wjones127 here since he's much more familiar with the Python ecossytem than I am.
I do need this to merge before #1825 because there's this presumption in this API that all available catalogs will be compiled into deltalake-core which is I need to remove for sub-crates.

Given they are not functional and don't have a maintainer right now, I'm fine removing them for now.
https://github.com/delta-io/delta-rs/issues/1466

We need to remove the python code paths as well.

I'm trying/struggling to understand the current state of Unity Catalog support.

Is it true that UC support has been removed from 0.15?
If so, is it planned to bring it back in future so I could connect to a table via UC without having direct access to the S3 bucket?
If it is planned to bring it back, are there any estimates of when that will be - e.g. 2024? Or are there no firm plans to bring back UC support at this stage?

@dhirschfeld I would love to get UC support but this is all in the hands of databricks. They simply made it impossible to read data that is behind a catalog outside of databricks...

@dhirschfeld I would love to get UC support but this is all in the hands of databricks. They simply made it impossible to read data that is behind a catalog outside of databricks...

Well, that's disappointing 😞
I thought it might be possible as they have a lot of docs around managing storage credentials - e.g.

https://docs.databricks.com/en/connect/unity-catalog/index.html
https://docs.databricks.com/api/account/accountstoragecredentials/get

...but maybe that just gives access from withing the DataBricks UI and doesn't actually expose the underlying storage token 😞

@dhirschfeld One of the requirements of grabbing the storage credential is:  have some permission on the storage credential.
I don't think that would be the same as read access to a certain table, so you still need some form of high level access, and I assume the people who have access to the managed credential they likely already have access directly to the object store.
If you find another way, we can definetely add it! :) I'm personally also hampered by the fact that I can't read delta tables in UC with delta-rs

If you find another way, we can definetely add it! :)

I don't know much about Databricks, and less about Unity Catalog, but I'll have a poke about to see what I can find. If you have been unable to find a way to do it, I'm not that hopeful, but we'll see...
I opened https://github.com/delta-io/delta-rs/discussions/2066 to track my progress! 😄


Delete .github/workflows/quarto-publish.yml

Hi again @sahiradv. We're glad you found this tutorial worth working on. I'm closing this pull request but you are welcome to comment by opening an issue.


chore(main): release 0.13.3

:robot: I have created a release beep boop
0.13.3 (2024-01-20)
Bug Fixes

doc: fix gitgraph rendering in readme (#275) (0bb7588)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/nader-eloshaiker/screen-geometry-app/releases/tag/v0.13.3 :sunflower:


using fine-grained repository-scoped token fails

TL;DR
using fine-grained repository-scoped token fails
Expected behavior
fine-grained repository-scoped token work the same as personal access tokens
Observed behavior
No response
Action YAML
on:
  push:
    branches:
      - main

name: release-please

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v3
        with:
          token: ${{ secrets.PAT_ACCESS }}
          release-type: node
          package-name: release-please-action

Log output
2022-12-15T02:50:10.0343630Z Download action repository 'google-github-actions/release-please-action@v3' (SHA:5c07f8be172b1f6e90f9c35baf8184461b91b85f)
2022-12-15T02:50:11.1155933Z ##[group]Run google-github-actions/release-please-action@v3
2022-12-15T02:50:11.1156383Z with:
2022-12-15T02:50:11.1157206Z   token: ***
2022-12-15T02:50:11.1157460Z   release-type: node
2022-12-15T02:50:11.1157778Z   package-name: release-please-action
2022-12-15T02:50:11.1158081Z   fork: false
2022-12-15T02:50:11.1158318Z   clean: true
2022-12-15T02:50:11.1158582Z   bump-minor-pre-major: false
2022-12-15T02:50:11.1158932Z   bump-patch-for-minor-pre-major: false
2022-12-15T02:50:11.1159300Z   changelog-host: https://github.com
2022-12-15T02:50:11.1159698Z   github-api-url: https://api.github.com
2022-12-15T02:50:11.1160084Z   github-graphql-url: https://api.github.com/graphql
2022-12-15T02:50:11.1160432Z   monorepo-tags: false
2022-12-15T02:50:11.1160703Z ##[endgroup]
2022-12-15T02:50:12.0491561Z ✔ Looking for latest release on branch: main with prefix: release-please-action
2022-12-15T02:50:12.0492237Z ❯ Fetching merge commits on branch main with cursor: undefined
2022-12-15T02:50:12.2059632Z ##[error]release-please failed: Personal access tokens with fine grained access do not support the GraphQL API

Additional information
No response

GitHub roadmap issue for fine-grained PATs support for GraphQL: https://github.com/github/roadmap/issues/622

This may have been fixed April 27, 2023 in https://github.blog/changelog/2023-04-27-graphql-improvements-for-fine-grained-pats-and-github-apps/


Dls release merge

I have implemented the changes I could find from Arvinder's 2-4-3 release here.
I also removed a stray print out test.

I think the PR #21 that I just merged may be behind the conflict... Please update this branch and resolve :+1:

Otherwise looks good. @GDYendell please go ahead and merge once you've resolved the conflict.


[SPARK-46710][SQL] Clean up the broadcast data generated when sql execution ends

What changes were proposed in this pull request?
Add config spark.broadcast.cleanAfterExecution.enabled(default false) . Clean up the broadcast data generated when sql execution ends ( only suitable for long running Spark SQL services ).
Before this PR: broadcast data cleaning can only rely on when GC is triggered, which may lead to a lot of waste of memory usage , and may also cause query instability if a single GC takes too long.
After this PR: after the execution of sql is completed, the broadcast data generated during the execution of the sql will be cleared.
Note: this parameter is only suitable for long running Spark SQL services. If this parameter is turned on and one dataframe is collected twice, the broadcast data will not be found during the second execution (because it has been cleaned).
Why are the changes needed?
Reduce memory load on driver and executor. This can make a long running spark service more stable.
Does this PR introduce any user-facing change?
Add config spark.broadcast.cleanAfterExecution.enabled.
Default false,  If true, the broadcast data generated by the sql will be destroyed when it is completed.

I tested a scenario (a large number of broadcast join, lots of iceberg expire snapshot & remove_orphan_files SQL executed concurrently), and found its effect to be very noticeable.
On the left side, the job has the parameter enabled, and the job can run smoothly to completion, with memory consumption stable at 40%. On the right side, the parameter is disabled, and it runs out of memory (OOM) after an hour.

Because of the problem with the git fork repository, I re-submitted a PR

gentle ping @cloud-fan

will we reuse the broadcast data after the query completes? e.g. call df.collect() multiple times.

@cloud-fan currently unable to reuse broadcast data.
When the sql execution ends, the broadcast data will be cleaned. So I wrote in PR description that this only works for spark sql service (broadcast data can be reused in one sql).
However, I think it is also possible to implement the functionality of regenerating the broadcast data after it has been cleaned up.

I think it's true for SQL queries, but not sure about dataframe queries, which keeps the physical plan as a lazy val and users can repeatedly execute the same physical plan.

I think it's true for SQL queries, but not sure about dataframe queries, which keeps the physical plan as a lazy val and users can repeatedly execute the same physical plan.

Yes, dataframe queries cannot be collected repeatedly. This param is for sql queries.

This PR is useful in our scenario. We test on TPC-DS 1000,  executor 25 instance * 8G .
Before this PR，executor will OOM and killed by yarn, after this PR, executor runs stably and no OOM.