Worker 1 stops processing completely after Worker 2 starts stealing leases.

Hi,
Thanks for making this library available.
I've run into an issue when testing this out on a large-ish stream. The issue comes into play when starting a second worker on the application. The new worker (Worker 2) will start to steal leases, as expected. But as soon as the old worker (Worker 1) notices, work on all other shards begins to grind to a halt. Worker 1 will eventually shutdown as soon as CheckpointConfig.timeout has elapsed. Worker 2 will continue on just fine and will eventually end up with all the leases.
To my untrained eye, it looks like there may be some race condition that comes into play when a lease is stolen, and the Dispatcher gets shutdown earlier than expected.
I'm including a slightly curated section of debug output relating to a single shard (the first one the ends up timing out), starting right when Worker 2 steals its first lease. I'd appreciate any insight you have here.
====
Feb 06 13:40:25 ip-172-31-21-209 java[17635]: 13:40:25.585 DEBUG [LeaseRenewer-0011] s.a.k.l.d.DynamoDBLeaseRefresher - Renewing lease with key shardId-000000001212
Feb 06 13:40:25 ip-172-31-21-209 java[17635]: 13:40:25.591 DEBUG [LeaseRenewer-0011] s.a.k.l.d.DynamoDBLeaseRenewer - Worker i-09400d30a3c7beef3 successfully renewed lease with key shardId-000000001212
Feb 06 13:40:28 ip-172-31-21-209 java[17635]: 13:40:28.905 DEBUG [LeaseRenewer-0005] s.a.k.l.d.DynamoDBLeaseRefresher - Renewing lease with key shardId-000000001212
Feb 06 13:40:29 ip-172-31-21-209 java[17635]: 13:40:29.015 DEBUG [LeaseRenewer-0005] s.a.k.l.d.DynamoDBLeaseRenewer - Worker i-09400d30a3c7beef3 successfully renewed lease with key shardId-000000001212
Feb 06 13:40:29 ip-172-31-21-209 java[17635]: 13:40:29.506 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT20.852S ago.  Not submitting new task.
Feb 06 13:40:30 ip-172-31-21-209 java[17635]: 13:40:30.507 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT21.853S ago.  Not submitting new task.
Feb 06 13:40:31 ip-172-31-21-209 java[17635]: 13:40:31.508 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT22.854S ago.  Not submitting new task.
Feb 06 13:40:32 ip-172-31-21-209 java[17635]: 13:40:32.206 DEBUG [LeaseRenewer-0003] s.a.k.l.d.DynamoDBLeaseRefresher - Renewing lease with key shardId-000000001212
Feb 06 13:40:32 ip-172-31-21-209 java[17635]: 13:40:32.213 DEBUG [LeaseRenewer-0003] s.a.k.l.d.DynamoDBLeaseRenewer - Worker i-09400d30a3c7beef3 successfully renewed lease with key shardId-000000001212
Feb 06 13:40:32 ip-172-31-21-209 java[17635]: 13:40:32.509 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT23.855S ago.  Not submitting new task.
Feb 06 13:40:33 ip-172-31-21-209 java[17635]: 13:40:33.597 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT0.096S ago.  Not submitting new task.
Feb 06 13:40:33 ip-172-31-21-209 java[17635]: 13:40:33.616 DEBUG [ShardRecordProcessor-0046] s.a.kinesis.lifecycle.ProcessTask - Calling application processRecords() with 5506 records from shardId-000000001212
Feb 06 13:40:33 ip-172-31-21-209 java[17635]: 13:40:33.627 DEBUG [default-akka.actor.default-dispatcher-50] s.a.k.c.ShardRecordProcessorCheckpointer - Checkpointing shardId-000000001212, token d5afb3c2-32c7-44e9-b447-c825597b676a at specific extended sequence number {SequenceNumber:<PHONE_NUMBER>9102449425719911162763455643313037808593030082,SubsequenceNumber: 626}
Feb 06 13:40:33 ip-172-31-21-209 java[17635]: 13:40:33.627 DEBUG [default-akka.actor.default-dispatcher-50] s.a.k.c.ShardRecordProcessorCheckpointer - Setting shardId-000000001212, token d5afb3c2-32c7-44e9-b447-c825597b676a checkpoint to {SequenceNumber:<PHONE_NUMBER>9102449425719911162763455643313037808593030082,SubsequenceNumber: 626}
Feb 06 13:40:33 ip-172-31-21-209 java[17635]: 13:40:33.627 DEBUG [default-akka.actor.default-dispatcher-50] s.a.k.l.d.DynamoDBLeaseRefresher - Updating lease Lease(leaseKey=shardId-000000001212, leaseOwner=i-09400d30a3c7beef3, leaseCounter=43808, concurrencyToken=d5afb3c2-32c7-44e9-b447-c825597b676a, lastCounterIncrementNanos=49669894780451, checkpoint={SequenceNumber:<PHONE_NUMBER>9102449425719911162763455643313037808593030082,SubsequenceNumber: 626}, pendingCheckpoint=null, ownerSwitchesSinceCheckpoint=0, parentShardIds=[shardId-000000001055, shardId-000000001054])
Feb 06 13:40:33 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:33.633] [default-akka.actor.default-dispatcher-50] [akka://default/user/tracker-i-094/shardId-000000001212] Checkpointed Successfully: shardId-000000001212 is at<PHONE_NUMBER>
Feb 06 13:40:34 ip-172-31-21-209 java[17635]: 13:40:34.598 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT1.097S ago.  Not submitting new task.
Feb 06 13:40:35 ip-172-31-21-209 java[17635]: 13:40:35.528 DEBUG [LeaseRenewer-0007] s.a.k.l.d.DynamoDBLeaseRefresher - Renewing lease with key shardId-000000001212
Feb 06 13:40:35 ip-172-31-21-209 java[17635]: 13:40:35.535 DEBUG [LeaseRenewer-0007] s.a.k.l.d.DynamoDBLeaseRenewer - Worker i-09400d30a3c7beef3 successfully renewed lease with key shardId-000000001212
Feb 06 13:40:35 ip-172-31-21-209 java[17635]: 13:40:35.599 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT2.098S ago.  Not submitting new task.
Feb 06 13:40:36 ip-172-31-21-209 java[17635]: 13:40:36.601 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT3.1S ago.  Not submitting new task.
Feb 06 13:40:37 ip-172-31-21-209 java[17635]: 13:40:37.602 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT4.101S ago.  Not submitting new task.
Feb 06 13:40:38 ip-172-31-21-209 java[17635]: 13:40:38.603 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Previous PROCESS task still pending for shard shardId-000000001212 since PT5.102S ago.  Not submitting new task.
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: 13:40:56.904 DEBUG [ForkJoinPool.commonPool-worker-9] s.a.kinesis.lifecycle.ShutdownTask - Invoking shutdown() for shard shardId-000000001212, concurrencyToken d5afb3c2-32c7-44e9-b447-c825597b676a. Shutdown reason: LEASE_LOST
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: 13:40:56.904 DEBUG [ForkJoinPool.commonPool-worker-9] s.a.kinesis.lifecycle.ShutdownTask - Record processor completed shutdown() for shard shardId-000000001212
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:56.907] [default-akka.actor.default-dispatcher-10] [akka://default/user/tracker-i-094/shardId-000000001212] Shutting down tracker shardId-000000001212
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:56.910] [default-akka.actor.default-dispatcher-40] [akka://default/user/tracker-i-094/shardId-000000001212] shardId-000000001212 Tracker started using Dispatcher[akka.actor.default-dispatcher]
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:56.910] [default-akka.actor.default-dispatcher-26] [akka://default/user/tracker-i-094/shardId-000000001212] Message [px.kinesis.stream.consumer.checkpoint.ShardCheckpointTrackerActor$Process] from Actor[akka://default/temp/$a] to Actor[akka://default/user/tracker-i-094/shardId-000000001212#-554709570] was not delivered. [1] dead letters encountered. If this is not an expected behavior, then [Actor[akka://default/user/tracker-i-094/shardId-000000001212#-554709570]] may have terminated unexpectedly, This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:56.910] [default-akka.actor.default-dispatcher-26] [akka://default/user/tracker-i-094/shardId-000000001212] Message [px.kinesis.stream.consumer.checkpoint.ShardCheckpointTrackerActor$Process] from Actor[akka://default/temp/$b] to Actor[akka://default/user/tracker-i-094/shardId-000000001212#-554709570] was not delivered. [2] dead letters encountered. If this is not an expected behavior, then [Actor[akka://default/user/tracker-i-094/shardId-000000001212#-554709570]] may have terminated unexpectedly, This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
Feb 06 13:40:57 ip-172-31-21-209 java[17635]: 13:40:57.905 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Shutdown(shardId-000000001212): Lease lost triggered.
Feb 06 13:40:57 ip-172-31-21-209 java[17635]: 13:40:57.905 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Shutdown(shardId-000000001212): Subscriber cancelled.
Feb 06 13:40:58 ip-172-31-21-209 java[17635]: 13:40:58.906 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Shutdown(shardId-000000001212): Lease lost triggered.
Feb 06 13:40:58 ip-172-31-21-209 java[17635]: 13:40:58.906 DEBUG [KinesisScheduler-0000] s.a.kinesis.lifecycle.ShardConsumer - Shutdown(shardId-000000001212): Subscriber cancelled.
Feb 06 13:40:58 ip-172-31-21-209 java[17635]: 13:40:58.906 DEBUG [KinesisScheduler-0000] s.a.kinesis.coordinator.Scheduler - Removed consumer for shardId-000000001212 as lease has been lost
Feb 06 13:45:56 ip-172-31-21-209 java[17635]: 13:45:56.934 ERROR [ForkJoinPool-1-worker-7] i.n.a.DataLakeLoader$Loader - process took longer than: Timeout(5 minutes) for shardId-000000001212
Feb 06 13:48:31 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:48:31.149] [default-akka.actor.default-dispatcher-7] [akka://default/user/tracker-i-094/shardId-000000001212] Shutting down tracker shardId-000000001212

Hi @ewestern,
Could you provide a few more details?

How many shards do you have in total?
Are the 2 workers running on the same machine?
Are you using the default LeaseManagementConfig?
What parallelism have you set for the marking of messages as processed?

Just to clarify, the logs above are from Worker 1?
From what i see in the logs (assuming they are from worker 1):
Worker 1 is : i-09400d30a3c7beef3

Worker 1 is processing on shard-1212, taking quite a lot of time processing a single batch of records.

Worker 1 is periodically renewing its lease (normal) for shard-1212 and eventually the tracker for shard-1212 requests a checkpoint  after having processed some records. It successfully checkpoints.

[akka://default/user/tracker-i-094/shardId-000000001212] Checkpointed Successfully: shardId-000000001212 is at<PHONE_NUMBER>

Eventually worker 2 steals the lease for shard-1212 at which point the scheduler for Worker 1 notifies the record processor (shard-1212), telling it that the lease is lost and then proceeding to shut it down.

Feb 06 13:40:56 ip-172-31-21-209 java[17635]: 13:40:56.904 DEBUG [ForkJoinPool.commonPool-worker-9] s.a.kinesis.lifecycle.ShutdownTask - Invoking shutdown() for shard shardId-000000001212, concurrencyToken d5afb3c2-32c7-44e9-b447-c825597b676a. Shutdown reason: LEASE_LOST
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: 13:40:56.904 DEBUG [ForkJoinPool.commonPool-worker-9] s.a.kinesis.lifecycle.ShutdownTask - Record processor completed shutdown() for shard shardId-000000001212
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:56.907] [default-akka.actor.default-dispatcher-10] [akka://default/user/tracker-i-094/shardId-000000001212] Shutting down tracker shardId-000000001212

The last log above is normal, the tracker associated with shard-1212 is correctly shut down since the corresponding record processor has shut down.

We then see that a new tracking actor is started for shard-1212

Feb 06 13:40:56 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:56.910] [default-akka.actor.default-dispatcher-40] [akka://default/user/tracker-i-094/shardId-000000001212] shardId-000000001212 Tracker started using Dispatcher[akka.actor.default-dispatcher]

My guess is that there is an in-flight message to the tracker for shard-1212 that is delivered after it shuts down, this causes a new tracker to be created for that shard.

Some in flight process messages (these are sent when you mark a record as processed) are delivered to dead letters between the time that the actor shuts down and is recreated (not restarted).

Feb 06 13:40:56 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:56.910] [default-akka.actor.default-dispatcher-26] [akka://default/user/tracker-i-094/shardId-000000001212] Message [px.kinesis.stream.consumer.checkpoint.ShardCheckpointTrackerActor$Process] from Actor[akka://default/temp/$a] to Actor[akka://default/user/tracker-i-094/shardId-000000001212#-554709570] was not delivered. [1] dead letters encountered. If this is not an expected behavior, then [Actor[akka://default/user/tracker-i-094/shardId-000000001212#-554709570]] may have terminated unexpectedly, This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
Feb 06 13:40:56 ip-172-31-21-209 java[17635]: [INFO] [02/06/2019 13:40:56.910] [default-akka.actor.default-dispatcher-26] [akka://default/user/tracker-i-094/shardId-000000001212] Message [px.kinesis.stream.consumer.checkpoint.ShardCheckpointTrackerActor$Process] from Actor[akka://default/temp/$b] to Actor[akka://default/user/tracker-i-094/shardId-000000001212#-554709570] was not delivered. [2] dead letters encountered. If this is not an expected behavior, then [Actor[akka://default/user/tracker-i-094/shardId-000000001212#-554709570]] may have terminated unexpectedly, This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.

Because these messages were delivered to dead letters instead of the intended actor, the Future that is returned by the markProcessed method on the Records will timeout after 5min. If you have a parallelism of 1, you will see that your stream will essentially halt, waiting for this future to complete. This is probably the reason you see the stream for Worker 1 "grind to a halt" when it loses the lease. Once the future fails, your entire stream will fail, resulting in the worker shutting down.

I'm still a little confused as to why the messages get delivered to dead letters instead of to the newly created shard tracker actor. Indeed, there appears to be a race condition here when leases are lost and messages are being marked processed.
Could you enable debug logs for the px.kinesis.stream.consumer package? I'd like to get a little more insight into what exactly is going on.
Also, are you experiencing this issue consistently? In the setup we have, when the worker dies, it gets restarted (container restarts). It should eventually steal leases without issue but would cause a lot of fighting between workers for them to eventually "come to terms".
Thanks for identifying the issue.
In the meantime, when I get a chance, I will look into addressing the race condition with shard tracker creation.

Thanks for looking into this.
To your questions:

90 shards in total
Two workers are on different machines.
I am using the default lease management config, with the exception that I'm setting maxLeasesForWorker to a default of 100.
As for parallelism, the pipeline is forked into ~ 16 substreams (using .groupBy). Substreams of course run in parallel, but within each substream, messages are batched for processing. After each batch is processed, the batch is traversed and Future computations are submitted asynchronously.
Flow[() => Future[Done]].mapAsync(16)(_.toVector.traverse(_.apply()))
Correct, the logs are for Worker 1.
Yes, the issue is consistent.

Happy to try to get more log output. Will circle back when I get a chance.

Because these messages were delivered to dead letters instead of the intended actor, the Future that is returned by the markProcessed method on the Records will timeout after 5min. If you have a parallelism of 1, you will see that your stream will essentially halt, waiting for this future to complete. This is probably the reason you see the stream for Worker 1 "grind to a halt" when it loses the lease. Once the future fails, your entire stream will fail, resulting in the worker shutting down.

I think I see the problem. Because I am doing a traversal of the Seq[Future], that means that the future of the entire batch won't resolve until the last future of the Seq. Since one of those is the message that went to DLQ, the entire batch gets halted.  Breaking up the batch and checkpointing records individually does seem to remedy the problem. Thanks for this!

@ewestern , Thanks for the info.
Indeed that is a large stream, 90 shards 😄.

I think I see the problem. Because I am doing a traversal of the Seq[Future], that means that the future of the entire batch won't resolve until the last future of the Seq. Since one of those is the message that went to DLQ, the entire batch gets halted. Breaking up the batch and checkpointing records individually does seem to remedy the problem. Thanks for this!

Yes, doing individual messages should help in your case however this race condition still exists.
I believe I've identified the problem and i'll hopefully release a fix soon.

Openning again until the release is done.

@ewestern I just released 0.1.4, it should be available on Maven Central in about 20min. Please let me know if it fixes the issue you see.

Great, I'll let you know @ukayani

This has fixed the issue. Thanks @ukayani !

@ewestern , Glad it fixed the issue. I did make a blooper in that release though, left an info log statement that will probably pollute your logs. I've released 0.1.5 which does not have that log message.
Cheers.

Closing as it has been addressed by #3


Make build passing for ruby 1.9-2.1

Coverage decreased (-0.01%) to 95.47% when pulling f0527366bc74e31e5bb0a89704e0e8b162f92522 on kikihakiem:master into 90f8f2a1a957eb83cfad6344717e44c3ec8d31d0 on geokit:master.

Coverage remained the same at 95.49% when pulling f0527366bc74e31e5bb0a89704e0e8b162f92522 on kikihakiem:master into 90f8f2a1a957eb83cfad6344717e44c3ec8d31d0 on geokit:master.

Coverage remained the same at 95.49% when pulling f0527366bc74e31e5bb0a89704e0e8b162f92522 on kikihakiem:master into 90f8f2a1a957eb83cfad6344717e44c3ec8d31d0 on geokit:master.

@mnoack could you please review?
This PR contains the correct usage of net/http for all ruby version
http://ruby-doc.org/stdlib-1.9.3/libdoc/net/http/rdoc/Net.html
http://ruby-doc.org/stdlib-2.2.2/libdoc/net/http/rdoc/Net/HTTP.html

Thanks very much @kikihakiem - I've been wanting to fix this but didn't have the time. Awesome work.


Eliminate WORKER_IMAGE Env Var from manifest

Unlocked by #4765
The only use of WORKER_IMAGE seems to be to set up the init container in the worker replication controller. https://github.com/pachyderm/pachyderm/blob/master/src/server/pps/server/worker_rc.go#L269
Related to #4762

How do we get the current running version of pachd (ie. 1.10)
Downward API? https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api

From go code? It's a global variable in the package github.com/pachyderm/pachyderm/src/client/version

I explored the go option, but it gets populated from git sha, not tag I think?
https://github.com/pachyderm/pachyderm/blob/7f6a123b17550ccdfa8c7a1ac63b94aeedc2571c/Makefile#L16-L17

It's the MajorVersion, MinorVersion, and MicroVersion constants in that package

Looks like exposing it through the downward api was closed as won't fix https://github.com/kubernetes/kubernetes/issues/19475

It's a little convoluted, but it looks like we can combine getting pod name and namespace from downward API, then hitting the kubernetes API to get the docker image and tag
ie
http://localhost:8080/api/v1/namespaces/default/pods/dapi-env-test-pod


feat(Locomotion): add improved touchpad movement script

Adds a new touchpad locomotion script that supports multiple configurable movement options for horizontal and vertical axis.

I didn't test it but I just needed to underline how clean that code looks. Good work 👍

I'll do a full review, but you'll also need a git description explaining the solution:
best thing to do is a git commit --amend and just add in the git body (if you look at some other commits in the repo, you'll see they have fairly lengthy commit messages explaining the commit)
When you've updated the commit just force push your branch back to github and it will auto update the pull request.
If you need any help with the gits then just hollar

I also have no idea if this is possible, but how viable is it to have this class just inherit the touchpad walking class and override and add to it to provide these additional features?

There were the following issues with your Pull Request

Commit: d285d55a31c5cbc2d7c215dd18f4b2253dbbd9be
Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/thestonefox/SteamVR_Unity_Toolkit

This message was auto-generated by https://gitcop.com

close :)
just needs line breaks in the description to keep it under 72 characters long :D

This all looks good to me now, anything else you wanna change on it or are you happy for me to do a final play test and then merge it?

It's all good now for an initial version so you can test and merge if no problems occur.

Ok cool I'll try a bit later today

I just added a speed multiplier to touchpad walking: https://github.com/thestonefox/VRTK/commit/a57af77675291ceee5f4eaf682c70e7deabbbdc3
Do you wanna add the feature into this PR as well?

Yeah, did :)

@reznovVR I tested it, all works fine.
The one thing i'm wondering though is.... should the speed multiplier be for more than just the slide speed?
Would it make sense also to have the warp go more steps if you have the speed button held down?
And the rotation go faster with the button down? (rotation could potentially be a separate setting maybe)
What do you think?

Yeah it could work and is an option anyway. I'll also split the modifier so each axis has it's own since for horizontal actions the same modifier value could be too intense in some cases.


Quake Movement breaks the Helium Flamingo from the mod Artifacts

Mod is found here.

I also noticed it breaks the umbrella slow falling effect.


Provide release artifacts on Maven repo

Could kauailabs please put the Java Roborio library (navx_frc.jar) on a Maven repo so that users can add  the navx library as a dependency? Thanks.

Is any work being done on this?

This item is currently assigned low priority, as we are currently focusing our efforts on other new features and products.

Has there been any additional movement on this?

We've got the latest navX-MXP FRC Java library available on a maven repository now.  We could use some help testing it.  Instructions on how to reference the repository are here:  http://www.pdocs.kauailabs.com/navx-mxp/software/roborio-libraries/java/
See the "Maven Repository" section at the bottom of the page - and please let us know how this works for you.


20h2

patch failed what version win this for?

11

test

This dll hook to undocumented api. Target function WaitForVsync is not exist in 10. I have no idea about 11 since I can't access my main PC now.


Another fix

This #PATCH# fixes an issue with switching _.forEach to Array.prototype.forEach

@psbanka self-merging


Implement Docs for GraphQL Shield

:tada: This PR is included in version 5.3.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Added group and nested group functionality

Implement functionality to create groups based on “deployed in” and “composed of” relationships.
Note: Additional logic is required to dynamically adjust the size of group containers to fit the nodes they encompass.

For the containers nodes, we should also give them a dashed outline instead of the solid colour one and make it a subtler grey colour


do you used 2d keypoint model?

thank you for your work!
how to use the demo code ? do you used 2d keypoints when you train and vis?

thank you for your work! do you used 2d keypoints when you train and vis?

https://github.com/SangbumChoi/MobileHumanPose/issues/2
For the question of using 2d keypoints please refer to the above issue
For the demo code you might try
python3 demo.py --gpu 0-1 --modelpath {model_path} --input_image {input_image.jpg} --backbone LPSKI

However, I found that current demo code is quite old so it requires to give input of headnet but I need to fix this.

#2
For the question of using 2d keypoints please refer to the above issue
For the demo code you might try
python3 demo.py --gpu 0-1 --modelpath {model_path} --input_image {input_image.jpg} --backbone LPSKI

However, I found that current demo code is quite old so it requires to give input of headnet but I need to fix this.

thank you very much


[Howto?] start occ files:scan

I would like to start a file scan, however its not possible cause sudo or su do not work..
Please help me out :)

docker exec -ti nextcloud occ files:scan
There's an occ I've made using su-exec so it's even easier to use.

Just for reference, because I learned about Wonderfall's script just now:

apk add Südostasien
sudo -u #991 php7 path/to/occ files:scan

Nice, thanks!
Von meinem iPhone gesendet

Am 19.02.2017 um 20:22 schrieb Wonderfall<EMAIL_ADDRESS>docker exec -ti nextcloud occ files:scan
There's an occ I've made using su-exec so it's even easier to use.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Support for Twitter/X API v2

Hello @ArthurHoaro
I noticed a bit by mistake that Twitter API v1.1 was deprecated and that my shaares were not published to Twitter/X anymore.
Do you plan to add support for Twitter/X API v2?

Hi!
Yes Twitter API previous version got removed at some point in the spring this year, I think. I don't really use Twitter anymore these days so I haven't been rushing fixing that.
It could probably be fixed relatively easily by replacing the 3rd party SDK we use.
Again, not really a priority for me, so any help would be appreciated.

I understand :)
Indeed using another SDK should make the transition fairly easy. I'll see what I can do if I manage to find some time.
Le lundi 27 novembre 2023 à 05:25, ArthurHoaro @.***> a écrit :

Hi!
Yes Twitter API previous version got removed at some point in the spring this year, I think. I don't really use Twitter anymore these days so I haven't been rushing fixing that.
It could probably be fixed relatively easily by replacing the 3rd party SDK we use.
Again, not really a priority for me, so any help would be appreciated.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

I understand :)
Indeed using another SDK should make the transition fairly easy. I'll see what I can do if I manage to find some time.


support for Rocko

Hi,
I just tested this layer on Rocko release for colibri t30 SOM (from Toradex), the only change I had to do was enabling rocko in LAYERSERIES_COMPAT_meta-influx.
Could You include rocko release in your repo ?

Done. Thank you.


ANC - Diabetes - Already Diagnosed [4h]

Issue
Currently, if a patient has been diagnosed with diabetes in a previous ANC visit during this pregnancy and they continue to have high glucose numbers, we continue to refer them to the hospital.
This doesn't need to happen. After speaking with Wendy, if a patient has been diagnosed with diabetes we should continue to run the random blood sugar test at each visit and record those values in the progress report. There will be no next steps because the patient is already in a program.
All E-Heza needs to do is prompt the nurse to run the lab and then record the numbers in the patient's chart.
To Do:

Update the logic

@balagan73
We had these requirments as part of #331 and #332, but I don't see QA report  addressed it.
Please verify one Nutrotion env.

QA Review
Found issues and questions:

When at first encounter I do not enter all data for the patient, just go for labs, do a test, and then pause the encounter, then after finishing the test (random blood sugar test), and coming back for subsequent visits, it is not possible to enter patient data, eg. pregnancy data, photo. I think this is the precondition of validation not working on Obstetrical exam, because we have no EGA data.

Available activities (plus next steps under To Do)

Now for some reason I cannot end the encounter, when I enter high blood sugar under case management, even if I have entered all data before.

I am stuck with this, cannot end encounter after entering lab results with Case management. I have tried repairing my device, it did not help. After repairing the device, not all patient have images in the directory. @anvmn Can you help me with this?

https://nutrition-ihangane.pantheonsite.io/
QA Review
Checked and approved:

Now I could end the encounter when doing Case management.

Patient is referred to hospital at first encounter, when blood glucose level is high according to logic.
Then at subsequent encounter no more hospital referral is happening.

More high blood glucose lab results
One referral


kafka output trigger always expect some value

Kafka output trigger always expects some value if no values passed it throwing below error
Microsoft.Azure.WebJobs.Extensions.Kafka: Message value was not defined.
there are some business scenario on which will define whether to publish the message or not. So, if there is no value Or value = null, it's throwing this error.

@jainharsh98 @raorugan Can you help with this?

@Alpesh1984909090 Currently passing the value as null is not supported. Adding the code link for reference.
Can you please add an issue here for tracking of the feature request.

Closing this as answered, but please let us know if you have any additional questions.


SwiftPM should not log warnings for remote dependencies - there's nothing I can do about those

Description
Given a package that depends on some other package "MyLib"...
When MyLib has build errors, I get warnings about them and there's nothing I can do about them.
Should we rather only log warnings about my package, which I can do something about?
E.g.
// swift-tools-version: 5.7

import PackageDescription

let package = Package(
    name: "MyPackage",
    dependencies: [
        .package(url: "https://github.com/ktoso/SomeLib", from: "1.0.0"),
        .package(url: "https://github.com/apple/swift-docc-plugin", from: "1.0.0"),
    ],
    targets: [
        .executableTarget(
            name: "MyPackage",
            dependencies: [
                .product(name: "SomeLib", package: "SomeLib")
            ]),
    ]
)

And that package has:
/// Some warning in documentation ``WrongType``
public struct some_lib {
    public private(set) var text = "Hello, World!"

    public init() {
        _ = sample // use the deprecated value
    }
}

@available(*, deprecated, message: "Some deprecation in library")
let sample: String = ""

I still get warnings about it inside MyPackage:
ktoso@dynames [08:45:46] [/tmp/example/MyPackage]
-> % cat Package.swift | grep Lib
        .package(url: "https://github.com/ktoso/SomeLib", from: "1.0.0"),
                .product(name: "SomeLib", package: "SomeLib")

ktoso@dynames [08:45:43] [/tmp/example/MyPackage]
-> % swift package clean

ktoso@dynames [08:45:46] [/tmp/example/MyPackage]
-> % swift build
Building for debugging...
/private/tmp/example/MyPackage/.build/checkouts/SomeLib/Sources/SomeLib/some_lib.swift:7:13: warning: 'sample' is deprecated: Some deprecation in library
        _ = sample // use the deprecated value
            ^
[5/5] Linking MyPackage
Build complete! (4.84s)

Expected behavior
We should log only warnings about libraries where I have a chance to do something about them:

the current package
local package dependencies

Actual behavior
Warnings are logged for all targets, including remote package dependencies.
Steps to reproduce

Use the pasted above Package.swift file to depend on https://github.com/ktoso/SomeLib/blob/main/Sources/SomeLib/some_lib.swift that has a deprecation warning
swift build
notice the deprecation warning

Swift Package Manager version/commit hash
No response
Swift & OS version (output of swift --version && uname -a)
5.7
Radar
rdar://94473684

Completely agreed.  Since it is the compiler that is logging errors in this case, I think that probably what needs to happen here is that SwiftPM needs to start special-casing remote packages and pass flags to suppress warnings when building them.  This can definitely be done with Clang, but it sounds as if there's no way to do that with Swift according to https://forums.swift.org/t/swift-should-allow-for-suppression-of-warnings-especially-those-that-come-from-objective-c/19216/66.

The alternative would for SwiftPM to suppress only warnings (not errors and other unexpected compiler output) from remote packages, but I wonder how fragile that will be — I could easily see bugs in which too much information is suppressed by mistake.
If we start parsing .dia files and showing the diagnostics from them instead of showing the compiler stderrr output then it would be a little easier.

Actually it looks like there is a -suppress-warnings flag now in SwiftC — I am not sure I've seen that before.  So it sounds as if we have a solution here.


missing example code for js-tiktoken

Hi,
I'm trying to run tiktoken-js without using npm, just pure JS.
However, I can't find a working example - the readme contains node instructions.
Could anyone provide code that turns "Hello world" into tokens, for example using jsfiddle? Thanks!

Hi,
I’ve created a project that runs tiktoken-js in pure JS without npm, using Browserify. You can find it here: purejs-ticktoken. It includes an example for tokenizing "Hello world" directly in the browser.
Hope this helps!


[Extensibility] Remove local from GetPhysInvtRecordHeader in "Phys. Invt. Record Line"

Describe the request
Please remove the local modifier from the GetPhysInvtRecordHeader function in table "Phys. Invt. Record Line"
-   local procedure GetPhysInvtRecordHeader()
+   procedure GetPhysInvtRecordHeader()
    begin
        TestField("Order No.");
        TestField("Recording No.");

        if ("Order No." <> PhysInvtRecordHeader."Order No.") or
           ("Recording No." <> PhysInvtRecordHeader."Recording No.")
        then
            PhysInvtRecordHeader.Get("Order No.", "Recording No.");
    end;

Please make PhysInvtRecordHeader available as protected:
-    var
+    protected var
        PhysInvtRecordHeader: Record "Phys. Invt. Record Header";

Additional context
Prevent code duplication, as we need this function.
Internal work item: AB#550934

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 25201.


Add CORS related tests

Purpose
$subject

Codecov Report
Patch coverage has no change and project coverage change: +55.44% :tada:

Comparison is base (76db7b9) 24.66% compared to head (c5ff202) 80.10%.
Report is 3 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1513       +/-   ##
===========================================
+ Coverage   24.66%   80.10%   +55.44%
===========================================
  Files         134        9      -125
  Lines       15689      548    -15141
  Branches     2434      246     -2188
===========================================
- Hits         3869      439     -3430
+ Misses      11685      109    -11576
+ Partials      135        0      -135

Flag
Coverage Δ

idp-domain-service
80.10% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 143 files with indirect coverage changes

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


[SPARK-22190][CORE] Add Spark executor task metrics to Dropwizard metrics

What changes were proposed in this pull request?
This proposed patch is about making Spark executor task metrics available as Dropwizard metrics. This is intended to be of aid in monitoring Spark jobs and when drilling down on performance troubleshooting issues.
How was this patch tested?
Manually tested on a Spark cluster (see JIRA for an example screenshot).

Can one of the admins verify this patch?

ok to test

Test build #83041 has started for PR 19426 at commit ca43764.

Test build #83041 has finished for PR 19426 at commit ca43764.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/83041/
Test FAILed.

Thanks @hvanhovell  for pushing the test. I see that the test build threw an error on Scala style tests: the logs report "/Executor.scala:443:0: Whitespace at end of line". However, I cannot reproduce the error when I run scalastyle locally, moreover it appears to me that line Executor.scala:443 is empty (so no extra space there).

Test build #83268 has started for PR 19426 at commit dd3b9a2.

Thanks @umehrot2 for the review and comments. Indeed well spotted that I had forgotten a couple of metrics and added one of them twice. This is hopefully fixed with the latest commit. As for your comment on the Spark Executor task metric JVMGCTime, my first reaction is that (1) I think it is good to have this type of info in the context of the executor metrics (2) It does not appear to me that JVMGCTime measured at the executor task level provides a direct duplication of info available in the JVM source (I am available to investigte this in more details in follow-up comments if you wish).

Test build #83268 has finished for PR 19426 at commit dd3b9a2.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/83268/
Test PASSed.

LGTM, merging to master!


Issues Running SV Caller Pipeline with Manta and Lumpy

Hello Bcbio Team,
I am trying to run the SV Caller Pipeline using lumpy and manta SV callers and I keep getting the following error -
[smoove]:2020/01/04 16:30:00 error running command: set -eu; lumpy_filter -f /gpfs/fs1/data/bcbio_data_1.1.9/genomes/Hsapiens/hs37d5/seq/hs37d5.fa bcbio_sv_20200103/work/prealign/Sample2/Sample2-prealign.bam bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.split.bam.tmp.bam bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.disc.bam.tmp.bam 2 && mv bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.split.bam.tmp.bam bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.split.bam && mv bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.disc.bam.tmp.bam bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.disc.bam && cp bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.split.bam bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.split.bam.orig.bam && cp bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.disc.bam bcbio_sv_20200103/work/bcbiotx/tmp64w53h0r/Sample2.disc.bam.orig.bam -> exit status 127
[smoove] 2020/01/04 16:30:07 done calculating bam stats
panic: exit status 127
goroutine 1 [running]:
github.com/brentp/smoove/lumpy.Lumpy(0x7ffddb115e5f, 0x3c, 0x7ffddb115e12, 0x45, 0x7ffddb115ea5, 0x5a, 0xc00016ef80, 0x2, 0x2, 0xc000174a00, ...)
        /home/brentp/go/go/src/github.com/brentp/smoove/lumpy/lumpy.go:127 +0x57e
github.com/brentp/smoove/lumpy.Main()
        /home/brentp/go/go/src/github.com/brentp/smoove/lumpy/lumpy.go:335 +0x261
main.main()
        /home/brentp/go/go/src/github.com/brentp/smoove/cmd/smoove/smoove.go:124 +0x1ce
' returned non-zero exit status 2.
[1:apply]: CalledProcessError: Command '/gpfs/fs1/data/bcbio_data_1.1.9/anaconda/bin/python3.6 /gpfs/fs1/data/bcbio_data/anaconda/share/manta-1.0.3-0/bin/configManta.py --bam=bcbio_sv_20200103/work/prealign/Sample1/Sample1-prealign.bam --bam=bcbio_sv_20200103/work/prealign/Sample2/Sample2-prealign.bam --referenceFasta=/gpfs/fs1/data/bcbio_data_1.1.9/genomes/Hsapiens/hs37d5/seq/hs37d5.fa --runDir=bcbio_sv_20200103/work/bcbiotx/tmplb0i0eex/manta
Traceback (most recent call last):
  File "/gpfs/fs1/data/bcbio_data/anaconda/share/manta-1.0.3-0/bin/configManta.py", line 34, in <module>
    from mantaOptions import MantaWorkflowOptionsBase
  File "/gpfs/fs1/data/bcbio_data/anaconda/share/manta-1.0.3-0/lib/python/mantaOptions.py", line 32, in <module>
    from configureOptions import ConfigureWorkflowOptions
  File "/gpfs/fs1/data/bcbio_data/anaconda/share/manta-1.0.3-0/lib/python/configureOptions.py", line 171
    except OptParseException, e :
                            ^
SyntaxError: invalid syntax
' returned non-zero exit status 1.

Additionally when I ran the pipeline previously I was getting an error saying that the smoove command could not be found. I manually linked the smoove binary installed under bcbio/anaconda/bin directory to a directory in my path across all the nodes on my server and after that this error went away. But now I see the error that the tool lumpy_filter cannot be found.
I have run into such errors previously in regards with tools such as apropos and gsort. Normally bcbio always looks under the --tooldir that was specified during install for any tool it needs but recently I have been noticing that for some tools it looks for them directly in the user's path and if the tool can't be found in the path bcbio crashes. It would be great if this issue regarding the location of the tools can be fixed in the long term.
Any pointers towards fixing the above highlighted issue would be greatly appreciated? Kindly let me know if there is any further information I can provide to help debug this issue. I am using bcbio version 1.1.8.
Thanks,
Moiz

Hi Moiz!
Thanks for reporting the issue!
It looks your bcbio was not successfully installed. The tools like gsort, smoove are widely used in many projects and should be there by default, no need to link them manually.
I'd suggest you to update bcbio and tools to the latest development 1.2.0a and post the details here first. And we will try to see if your installation is ok.
Sergey

Hi @mbootwalla,
For a lot of the tools, we try to find the full path to them in the bcbio installation, but we have missed places, you can see for the lumpy_filter call we aren't using the full path. I'll fix that, but there are likely other ones. If you put the tool-directory/bin in your PATH it will find these files.

Should be all set now!

Thank you @roryk and @naumenko-sa. I will try out the updated version of bcbio and report back if I run into any issues.


More concise printing of detector type?

I'm wondering if we can make the printing of TracerSparsityDetector() shorter. At the moment it looks like
julia> TracerSparsityDetector()
TracerSparsityDetector{SparseConnectivityTracer.GradientTracer{SparseConnectivityTracer.IndexSetGradientPattern{Int64, BitSet}}, SparseConnectivityTracer.HessianTracer{SparseConnectivityTracer.DictHessianPattern{Int64, BitSet, Dict{Int64, BitSet}, SparseConnectivityTracer.NotShared}}}()

But we don't have to specify all type parameters if they correspond to the default settings. You can draw inspiration from the new printing I coded for ADTypes, which only tries to reproduce the constructor. See example here:
https://github.com/SciML/ADTypes.jl/blob/f206682addbc27b450f51d51e9a4082fb9b7cdb4/src/dense.jl#L190-L196

Yes, that would be an improvement.

How about this?
julia> for detector in (:TracerSparsityDetector, :TracerLocalSparsityDetector)
           @eval function Base.show(io::IO, d::$detector{GradientTracer{PG}, HessianTracer{PH}}; indent=0) where {PG,PH}
               println(io, $detector, "{")
               println(io, "  ", "GradientTracer pattern: ", PG)
               println(io, "  ", "HessianTracer pattern:  ", PH)
               print(io, "}")
               return nothing
           end
       end

julia> TracerSparsityDetector()
TracerSparsityDetector{
  GradientTracer pattern: SparseConnectivityTracer.IndexSetGradientPattern{Int64, BitSet}
  HessianTracer pattern:  SparseConnectivityTracer.DictHessianPattern{Int64, BitSet, Dict{Int64, BitSet}, SparseConnectivityTracer.NotShared}
}

Or should we just print TracerSparsityDetector() instead of leaking all our internals?

Ideally, Base.show(io, object) is supposed to give you a string that you can parse back into the object itself. Of course not everyone knows or cares.
In any case, I don't think most users will ever go beyond TracerSparsityDetector(), and those users don't need to know the type parameters. So for them, I would simplify printing of at least the default detector, and maybe leave complex printing if one of the settings differs from the default?

Or adaptive:
Julia> for detector in (:TracerSparsityDetector, :TracerLocalSparsityDetector)
    @eval function Base.show(io::IO, d::$detector{GradientTracer{PG}, HessianTracer{PH}}; indent=0) where {PG,PH}
        is_gradient_default = PG == DEFAULT_GRADIENT_PATTERN
        is_hessian_default = PH == DEFAULT_HESSIAN_PATTERN
        if is_gradient_default && is_hessian_default
            println(io, $detector, "()")
        else
            println(io, $detector, "{")
            println(io, "  ", "GradientTracer pattern: ", PG)
            println(io, "  ", "HessianTracer pattern:  ", PH)
            print(io, "}()")
        end
        return nothing
    end
end

julia> TracerSparsityDetector()
TracerSparsityDetector()

julia> TracerSparsityDetector(gradient_tracer_type=SparseConnectivityTracer.GradientTracer{SparseConnectivityTracer.IndexSetGradientPattern{Int,Set{Int}}})
TracerSparsityDetector{
  GradientTracer pattern: SparseConnectivityTracer.IndexSetGradientPattern{Int64, Set{Int64}}
  HessianTracer pattern:  SparseConnectivityTracer.DictHessianPattern{Int64, BitSet, Dict{Int64, BitSet}, SparseConnectivityTracer.NotShared}
}()


add tool to generate JS wrappers from .d.ts files

Describe the feature
see title
Proposed Solution
No response
Additional Information
Possibly helpful:

https://github.com/Microsoft/dts-gen

WIP. See the dedicated repo: https://github.com/bait-lang/dts-wrap


fix(syntex_syntax): Don't expand builtin derive decorators

@homu: r+

:pushpin: Commit dc176ef has been approved by erickt

:hourglass: Testing commit dc176ef with merge 80b52b0...

:sunny: Test successful - status


Detecting ramen resources per application

Current system does not have uniform way to find all the relevant ramen resources for specific application.
The system makes it very hard to locate all the resources without known the resource kind (e.g. kubectl get all -n namespace return only some kinds).
Use cases
One application per namespace - subscriptions/rbd
hub:
  app-namespace:
    drpc:
      name: app-name-placement-1-drpc
cluster1:
  app-namespace:
    vrg:
      name: app-name-placement-1-drpc
    vrs:
    - name: pvc-name
cluster1:
  app-namespace:

One application per namespace - applicationset/rbd
hub:
  openshift-gitops:
    drpc:
      name: app-name-placement-drpc
cluster1:
  app-namespace:
    vrg:
      name: app-name-placement-drpc
    vrs:
    - name: pvc-name
cluster1:
  app-namespace:

One application per namespace - applicationset/cephfs
hub:
  openshift-gitops:
    drpc:
      name: app-name-placement-drpc
cluster1:
  app-namespace:
    vrg:
      name: app-name-placement-drpc
    replicationsources:
    - name: pvc-name?
cluster1:
  app-namespace:
    vrg:
      name: app-name-placement-drpc
    replicationdestinations:
    - name: pvc-name?```

Multiple application per namespace
When creating an app we can use the same application namespace (subscription) or the same remote namespace (application sets).
hub:
  openshift-gitops:
    drpc:
      name: app1-name-placement-drpc
      name: app2-name-placement-drpc
cluster1:
  shared-apps-namespace:
    vrgs:
      - name: app1-name-placement-drpc
      - name: app2-name-placement-drpc
    vrs:
    - name: pvc1-name?
    - name: pvc2-name?
cluster1:
  shared-apps-namespace:

Looks like this is hard to get right for users - deployment name and pvc names will conflict.
Seems impossible with ocm-ramen-samples.
One application, multiple namespaces
(Not sure how this will look, @hatfieldbrian may add more info on this)
Locating stuff

drpc

Depends on application implementation (subscription/application sets)
Depend on undocumented drpc name format that may change in future versions

vrg

Depend on drpc name format, again implementation detail that can change in future versions

vr/replicaiton{source,destination}

Depend on the pvc name, need to know the specific deployment

Suggested solution
When users create applications in ACM, they must create an application name and use it to
locate the application and perform actions.
Users also create an application namespace, not sure if we can use the same namespace to have multiple applications in the same namespace.
When the application is create from the UI, all resources related to the application can have the same label common label:
labels:
  app.kubernetes.io/name: mysql

This can be applied to:

subscription
placement
applicationset
drpc
vrg (ramen can propagate the label from the drpc)
vr (ramen can propagate the label from the vrg)
replication{source,destination}? (ramen can propagate the label from drpc/vrg)
manifestwork?
namespaces?
application resources?

With this tools (like ramen kubectl plugin) can identify an application using:
kubectl ramen status --namespace xxx --app-name yyy

Or using kubectl:
kubectl get --selector app.kubernetes.io/name=yyy

Tools can deal with the difference between subscriptions and applications sets by looking the application namespace and gitops namespace on the hub.
Current ocm-samples-ramen yamls already contain similar label:
$ grep -r -A1 labels: subscription/
subscription/placementrule.yaml:  labels:
subscription/placementrule.yaml-    app: busybox-sample
--
subscription/subscription.yaml:  labels:
subscription/subscription.yaml-    app: busybox-sample

But we don't have this in openshift. We need a uniform configuration in upstream
and downstream so tools can work in the same way.
Issues

subscription/placement/applicationset label - depends on OCM/ACM?
maybe we can add the label when assigning drpolicy to an application?

See also

ancient issue for vrg: #14
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

@BenamarMk @ShyamsundarR what do you think?

Looks like this already mostly implemented - these resources already have app: app-name:

subscription
placementrule (minikube)
placement (openshift)
drpc
vrg

Can be nice to have the same label on the vrs and replccation{source,destination} and maybe other but we can start using the current labels instead of depending on drpc/vrg/vr name.

Does not work for discovered apps:
The drpc has app= label added by the samples:
$ kubectl get drpc -l app=deployment-rbd -n ramen-ops --context hub
NAME                  AGE   PREFERREDCLUSTER   FAILOVERCLUSTER   DESIREDSTATE   CURRENTSTATE
deployment-rbd-drpc   18m   dr1                                                 Deployed

But the label is not propagated to the vrg and vrs:
$ kubectl get vrg -l app=deployment-rbd -n ramen-ops --context dr1
No resources found in ramen-ops namespace.

$ kubectl get vr -l app=deployment-rbd -n deployment-rbd --context dr1
No resources found in deployment-rbd namespace.

@raghavendra-talur do you know why the vrg and vr are missing the label from the drpc?


openlayers not working with samsung browser 4.0 ?

Hi all!
It seems that my openlayers-map is not showing up, if someone uses the default samsung browser.
The browser string is
Mozilla/5.0 (Linux; Android 6.0.1; SAMSUNG SM-A500FU Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/4.0 Chrome/44.0.2403.133 Mobile Safari/537.36
The code which is generating the map is
var map = new ol.Map(
{
	target: 'mapDiv',
	layers:
	[
		new ol.layer.Tile(
		{
			source: new ol.source.XYZ({ url: 'http://a.tile.openstreetmap.fr/hot/{z}/{x}/{y}.png'});
		}),
		new ol.layer.Vector(
		{
			source: new ol.source.Vector({});
		}),
		new ol.layer.Vector(
		{
			source: new ol.source.Vector({});,
			style: styleFunction1
		}),
		new ol.layer.Vector(
		{
			source: new ol.source.Vector({});
		}),
		new ol.layer.Vector(
		{
			source: new ol.source.Vector({});
		})
	],
	view: new ol.View(
	{
		center: ol.proj.fromLonLat([16.41, 48.24]),
		zoom: 12,
		minZoom: 1,
		maxZoom: 19
	}),
	controls: []
});

ol.LEGACY_IE_SUPPORT = true;

the above code works very vell with desktop browsers as IE11, FF53, Google Chrome and Opera as well as mobile browsers FF53, Google Chrome, Opera and Opera Mini, etc...
Is there a compatibility-issue, or did I anything wrong?

I found the Issue with a remote debugger, it is not related with openlayers!
Sorry for opening an issue!
(I had a function using let-declarations, which is not yet supported by SamsungBrowser. This was throwing an error so my code generating the map was not called at all!)


Added Fishways build steps

Added the build steps and render for the HS Fishways project build. 🐟 🪜

Also adding the build steps for the ES Seaweed Farming project build 🧑🌾 🪸


authorizeChannel must return a promise

Package version
0.2.3
Describe the bug
In the documentation, https://github.com/adonisjs/transmit#channel-authorization, the example return a boolean. This throw a TS error because the returned type of this function is Promise<boolean>. You need to add async in the example or to allow the function to return boolean.
https://github.com/adonisjs/transmit/blob/main/src/transmit.ts#L142
Reproduction repo
No response

Maybe a more realistic example like this one could be useful:
transmit.authorizeChannel<{ questionId: string }>(
  ':questionId/events',
  async ({ auth }: HttpContext, { questionId }) => {
    const user = await auth.authenticateUsing(['api'])

    const question = await user
      .related('questions')
      .query()
      .where('questions.id', questionId)
      .firstOrFail()

    return question.id === questionId
  }
)

You need to add async in the example or to allow the function to return boolean.

We should change the return type to have Promise<boolean> | boolean. Can you create a PR for it?

Maybe a more realistic example like this one could be useful:

Yes, we can probably improve the example, it will be done in the real documentation (website),.

I'll make a PR later today!
If you plan to move documentation into the Adonis docs, I will not touch the readme and wait for the release!


Tags missing on master since v1.1.0

I noticed that since v1.1.0, release tags are no longer picked up by git describe (and in turn show wrong in the interface footer). For example, from the current GitHub master:
$ git clone git@github.com:go-gitea/gitea.git .
$ git describe --tags
v1.1.0-894-g1687aa59

What's weird is that the missing tags do show on git tag:
$ git tag | tail -1
v1.3.2

Anyone know what's up?

No we can not tag master as it is way ahead and there is already PR merged for next major release

I'd be fine with removing the version number and just showing the commit hash. I see that https://try.gitea.io already has such a version in the footer:

But when I build from the git source, I seem to always get the output of git describe --tags in my footer. I wonder if try.gitea.io is built differently, hmm.

Commit has is part of the git-describe output (final part, after the "g").
In general, tagging before branching would fix this problem.
I think the procedure described in the documente added by PR https://github.com/go-gitea/gitea/pull/2609 (HOWTO_RELEASE) would give us that.

At most we could tag RC1 on master but I don't see much point in that

If we want to put tag on master we should consider master has stable and use a develop branch (currently master branch) but that is not the same git flow than currently.

Tag before branch would definitely work as the tag is also visible on the branch, see below example workflow:
$ git init
$ git commit --allow-empty -m "first"
[master (root-commit) 8829b85] first
$ git tag v1.0.0 -m v1.0.0
$ git commit --allow-empty -m "second"
[master f6f310f] second
$ git describe
v1.0.0-1-gf6f310f
$ git branch branch
Branch 'branch' set up to track local branch 'master' by rebasing.
$ git checkout branch
Switched to branch 'branch'
Your branch is up to date with 'master'.
$ git describe
v1.0.0-1-gf6f310f

Just the rethinking of it as 1.5.0 release iscoming.
I agree with @silverwind we could also tag master before but it will work only for major release 1.5.0 (that could be enough to mark progress) but we could not add minor tag 1.5.1 to master as it will differ from branch release where it should be.
I propose another solution, couldn't we tag master as 1.5.0-dev and 1.6.0-dev after releasing 1.5.0 ?
This way we know that it is a dev version of 1.X and will be consistent with default tag used without make env. https://github.com/go-gitea/gitea/blob/master/main.go#L24

Yes, that why I suggest 1.X.0-dev to show that it is a dev version as better alternative.


Nuitka:WARNING: Did not follow import to unused 'sqlite3', consider include options.

Nuitka version, full Python version, flavor, OS, etc. as output by this
command (it does more than you think, and we are adding more all the time):

python -m nuitka --version
0.8.3 Commercial: None Python: 3.9.9 (tags/v3.9.9:ccb0e6a, Nov 15 2021, 18:08:50) [MSC v.1929 64 bit (AMD64)] Flavor: Unknown Executable: C:\Users\pando\AppData\Local\Programs\Python\Python39\python.exe OS: Windows Arch: x86_64 WindowsRelease: 10

How did you install Nuitka and Python

Using pip install nuitka

Provide in your issue the Nuitka options used

nuitka --mingw64 --onefile --follow-imports --include-package=httpx,psutil,PIL,Crypto,sqlite3 file.py
Idk why it does this and i want to incluse sqlite3 in it since when i run the exe after the compilation it gives ModuleNotFound sqlite3

Answer:
Sorry for wasting your time, I found the answer in one of the recent issues and it was just to include the import sqlite3 in the code


Register and tag package

Can this package be registered and tagged with METADATA.jl such that one does not need to perform Pkg.clone to make use of it?

@afternone please do this! We have it listed in LightGraphs as a plotting option.

OK, I'll register it today.

Checking in - it would be great to be able to Pkg.add() this.

Also - if you want to move it under JuliaGraphs, let me know :)

I'm pleased to move it under JuliaGraphs. What should I do?

Go to the repo settings, under "Danger Zone", select "Transfer", and then the repo name (to confirm) and the organization name (JuliaGraphs). Once it's there I'll set you up with full privs for the repo.

You'll then want to make sure all links point to the new location of the repo, and then we'll probably need to tag a new version.

I received "You don’t have admin rights to JuliaGraphs" when transfer the repo.

Argh. Sorry - I thought I had set up the permissions properly. One sec.

Ah, you haven't joined the JuliaGraphs team yet. I sent an invite 2 days ago. Could you accept it?

Sorry, I think I will receive a notification about the invitation. I have figured out that and accepted the invitation.

Try now - I'm pretty sure it's ready to go.

If that doesn't work, you could make me an admin on this project and I can transfer it over. I'm pretty sure we won't need to do that though.

I forgot to update the links in document. Can you fix them?

Sure, I can do this tonight - but you should have full access to the repo. The only thing that should have changed is where it lives.

I made the change to README.md. I think what you'll want to do is register the package in METADATA.

OK. Can we register this now? (Do you want me to do it?)

I'm glad you doing it.

ref JuliaLang/METADATA.jl#6402. Still no luck with that?

Haven't had a chance to get back to it. Hopefully today.

We're tagged at 0.1.0.


Informative error logging in case components can't be updated No.2

Is your feature request related to a problem? Please describe.
I'm just evaluating this component as an alternative to a middleware component I'm already using.
Unfortunately I'm struggling with the initial setup. I can't get my components updated and always getting following error message:
prometheus-cachethq_oxy_1  | time="2021-06-15T09:50:43Z" level=debug msg="Configuration successfully loaded and logger configured"
prometheus-cachethq_oxy_1  | time="2021-06-15T09:50:43Z" level=info msg="Starting prometheus-cachethq version: 1.1.1 (git commit: e14df6b) built on 2020-11-09T17:27:14Z"
prometheus-cachethq_oxy_1  | time="2021-06-15T09:50:43Z" level=info msg="Server listening on :8080"
prometheus-cachethq_oxy_1  | time="2021-06-15T09:50:43Z" level=info msg="Server listening on :9090"
prometheus-cachethq_oxy_1  | time="2021-06-15T09:51:16Z" level=debug msg="request started" client_ip=<IP_ADDRESS> http_method=POST http_proto=HTTP/1.1 http_scheme=http remote_addr="<IP_ADDRESS>:59186" request_id=5172ad0d-4e40-4c66-a2c6-ed25fc1a7e8b uri="http://localhost:8080/prometheus/wehbook" user_agent=curl/7.58.0
prometheus-cachethq_oxy_1  | time="2021-06-15T09:51:16Z" level=error msg="request complete" client_ip=<IP_ADDRESS> http_method=POST http_proto=HTTP/1.1 http_scheme=http remote_addr="<IP_ADDRESS>:59186" request_id=5172ad0d-4e40-4c66-a2c6-ed25fc1a7e8b resp_bytes_length=-1 resp_elapsed_ms=0.048 resp_status=404 uri="http://localhost:8080/prometheus/wehbook" user_agent=curl/7.58.0

I already read through this reported issue.
Describe the solution you'd like
Some suggestions what else I could try to get it running
or
More output when debug logs are on, e.g. seeing how a request is sent out with what parameters and why it fails instead of a non-informative 404 error.
Describe alternatives you've considered

I tried several different configuration variations with or without groupName or labels e.g.
simple curl command against http://localhost:8080/prometheus/wehbook is giving 404 as well
Cachet API key should be correct because it's working for the other middleware in the same setup

Additional context
My setup:
docker-compose
  prometheus-cachethq_oxy:
    ports:
      - "8080:8080"
      - "9099:9090"
    image: oxynozeta/prometheus-cachethq:1.1.1
    volumes:
      - ./oxy_config.yml/:/conf/config.yaml

prometheus-cachethq configuration:
# Log configuration
log:
  # Log level
  level: debug
  # Log format
  format: text

# Server configurations
#server:
#  listenAddr: "<IP_ADDRESS>"
#  port: 8080

# Cachet configuration
cachet:
  url: http://cachet:8000
  apiKey: <redacted>

# Targets
targets:
  - component:
      name: testcomponent
#      groupName: test
      status: MAJOR_OUTAGE
    alerts:
      - name: testcomponent

crafted alertmanager request:
curl -X POST http://localhost:8080/prometheus/wehbook -d '{"receiver":"cachethq-receiver","status":"firing","alerts":[{"status":"firing","labels":{"alertname":"testcomponent"},"annotations":{},"startsAt":"2018-05-22T20:00:32.729840058-04:00","endsAt":"0001-01-01T00:00:00Z","generatorURL":""}],"groupLabels":{"alertname":"testcomponent"},"commonLabels":{"alertname":"testcomponent"},"commonAnnotations":{},"externalURL":"http://localhost.localdomain:9093","version":"4","groupKey":"{}:{alertname=\"testcomponent\"}"}'

Would be great if you can give me some hints what I might do wrong here. Thank you very much!

Hello,
Thanks for your issue. I must admit that I know I need to add some logs to this project, but I don't have the time yet to add them sorry...
But I might have a clue for your problem:

Can you fix the typo in your curl to webhook and not wehbook (h and b are switched) ?
The error get from Cachet (if any) should be put in the json response body.

Tell me if you have any problems.
Regards,
Oxyno-zeta

Hi,

Can you fix the typo in your curl to webhook and not wehbook (h and b are switched) ?

Well, that's embarrassing... I starred at it for a long time but didn't catch it. That was the root cause.
Thank you very much!
I'm going to make myself familiar on what your component can do. If I need a specific feature in the future it will be hard for you to work on right now. So you would rather prefer a PullRequest instead, correct?

Hello @thomas315 ,
No worry. It happens ;) .
Yeah for the moment, I'm stopping devs for some weeks for health reasons... When I will be able to start again, I want to finish the new major version I was working on for s3-proxy (already started but stopped...). After that I will think about how to rework this one.
All of this to say, yes, if you can create a PR I will be happy to check it with the corresponding issue for the feature, it will be perfect. If you don't know how to do it/don't want to do it, I will do it as soon as I can.
Feel free to add issues etc. Thanks for testing the project ;)

Thanks for the information, @oxyno-zeta .
Going to close this issue.
I wish you a speedy recovery!


Use consul node address as a backup when filtering service instances

Otherwise, when ServiceAddress is not specified during consul registration (which is valid use case), istio fails to find any services for the node.

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

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

/ok-to-test

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

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
29d238c839a05a8c6b493d8f34484b6755287206
link
/test istio-presubmit

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


Add version: LuaLS.lua-language-server version 3.5.6

Pull request has been created with Komac v1.9.1 :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/116111&drop=dogfoodAlpha

@wingetbot waivers Add Validation-Executable-Error

/azp run


:mute: fix: Remove console.logs

Description
Remove stray console.logs
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #382   👈

PR #381

PR #379

PR #380

PR #371

This comment was auto-generated by Graphite.


Error codes of failed requests

How to get an error code of failed requests? It is necessary for my project.

I can't find the way to get these codes i source code of framework..

@FonyRockfeel could you clarify what error code do you need?
If you mean modbus exception codes then SlaveException  and its  property SlaveExceptionCode is what you need.

I have this code:
    PortName = cfg.Port;

     _port = new SerialPort(PortName) {BaudRate = cfg.BaudRate, ReadTimeout = cfg.Timeout};

     _modbus = ModbusSerialMaster.CreateRtu(_port);

     _modbus.Transport.Retries = 3;
     _modbus.Transport.WaitToRetryMilliseconds = 250;
     var regs = _modbus.ReadHoldingRegisters(slave, start, amount).ToList();

How to use SlaveException class in this code?

ReadHoldingRegisters throws SlaveException in case if your device returns modbus exception code

Thank you!


Update to React 16

Great calendar by the way, much nicer than some of the alternatives.
I'm using it with React 16 and hoping to remove the npm warnings I get, namely:
<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^15.0.0 but none is installed.
recompose supports React 16 as of v0.25.1 so this should be an easy fix.
The package.json already allows the React 16 alpha, can this be bumped to the v16.0.0 release?
I forked the project with the hopes of submitting a pull request with these changes, but after  running npm install and npm start I get the following error:
Failed to compile with 1 error.

 ERROR  in   TypeError: Cannot read property 'request' of undefined

This one should fix it https://github.com/clauderic/react-infinite-calendar/pull/197


Access Telegram API

Is it possible to access Telegram API such as bot.telegram.sendMessage via micro-bot?

@realies
You can define method like this and use bot.telegram.sendMessage
bot.init = async (mBot) => {
    bot.telegram = mBot.telegram;
}


Pronunciation model in the new Portal

Hi,
In the section "Related data for text training", it is stated that

Utterances can be provided as a single or multiple text files. The closer the text data is to what will be spoken, the greater the likelihood that accuracy is improved. Pronunciations should be provided as a single text file. Everything can be packaged as a single zip file and uploaded to the Custom Speech portal.

However, in the new portal speech.microsoft.com for related text, zip files are not accepted, only a single txt file is accepted per dataset. How is it then possible to upload a pronunciation file in the new portal on top of LM adaptation data?
Best,
Sam

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 120ebdde-5785-5850-c963-803bf3744112
Version Independent ID: 82bc9a4e-3908-499f-dd2c-31eacc227fff
Content: Prepare test data for Custom Speech - Speech Services
Content Source: articles/cognitive-services/Speech-Service/how-to-custom-speech-test-data.md
Service: cognitive-services
Sub-service: speech-service
GitHub Login: @erhopf
Microsoft Alias: erhopf

@sam-pell Thank you for your feedback, I will investigate and get back to you soon.

@sam-pell Hi Sam, you can do it by Upload Data - Select Audio + human-labeled transcript, then you can upload zip file.


Enable adding multiple users to sugroup via a loop

Overall Review of Changes:
Enable user to provide a list of users to add to the rhel_sugroup via a loop.
Issue Fixes:
None.
Enhancements:
Enable user to provide a list of users to add to the rhel_sugroup via a loop.
How has this been tested?:
Tested deployment on several freshly installed RHEL 8.5 and 9 servers.

Apologies for cluttering the pull requests. On reflection I don't think adding sudoer was the intention of that section.


[Redesign] Re-work the huhhop preset dialog

Is your feature request related to a problem? Please describe.
Implement the HubHop Search in the new UI.
There are a couple of items that can be improved when selecting presets using our hubhop-style search.
Describe the solution you'd like
The original functionality is available in the new UI including

Performance improvements
Improved sort order in drop down, e.g. last used aircraft, categories, etc. first
If a preset is a customized preset, show it at the top of the list

It would be good if search criteria could be for all words instead of exact text match
For example specify AP DEC and get all events that contain both words.


Error when setting initial value of Editor to a markdown link or html  tag

Describe the bug
Error when setting initial value of Editor to a markdown link or html  tag. I'm using "@toast-ui/react-editor": "^3.2.0", and it is a Next.js application
Additionally when I click the "Insert Link" button from the Editor that functionality does not work for my production app.
To Reproduce
Steps to reproduce the behavior:

Add code such as this

const test = "Testing"
<Editor
        placeholder={props.placeholder}
        initialValue={test}
        previewStyle="vertical"
        height="400px"
        hideModeSwitch={true}
        initialEditType="wysiwyg"
        useCommandShortcut={true}
        onChange={handleChange}
        onBeforePreviewRender={handleBeforePreviewRender}
        onBeforeConvertWysiwygToMarkdown={handlBeforeConvertWysiwygToMarkdown}
        onCaretChange={handleCursorChange}
        onKeyup={handleKeyup}
        onKeydown={handleKeydown}
        ref={editorRef}
      />

Go to page with editor
See error

Expected behavior
I should be able to add links to the wysiwyg editor
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

I think this is related to https://github.com/nhn/tui.editor/pull/2729#pullrequestreview-1105989640

@spencerpowell Sorry, We don't fully support SSR. It's our todos.

@jwlee1108 This doesn't have to do with SSR.  It is related to this bug https://github.com/nhn/tui.editor/pull/2729#pullrequestreview-1105989640
https://github.com/nhn/tui.editor/issues/2687
Reverting to version  3.1.8 fixed the bug for me
"@toast-ui/editor": "3.1.8",
"@toast-ui/react-editor": "3.1.8",

@spencerpowell We'll check it. Thank you for the issue.

I have the same issue and it is not SSR. And I can reproduce it by simply running the editor with "markdown" as being default mode.
Then typing the [text](https://google.com) in the editor and switching tab to WYSIWYG mode. And  the same error pops up that the getCustomAttrs is not defined.

@jwlee1108  안녕하세요!
Your codesandbox works fine but I created a sample repo that exposes the error.
It is a vanilla NextJS app that I added toast-ui react editor to.
Here is the shared workspace on codesandbox that you can open to see it running codesandbox
And github repo: https://github.com/benderillo/nextjs-toastui-editor
Steps:

Editor loads in markdown mode
type in text
Switch to wysiywg mode
Tada! Exception is thrown saying getCustomAttrs is not defined.

@benderillo
Thank you for doing your best for reproducing. When I checked, the function(getCustomAttrs) in the module wasn't connected properly when I bundled it. I haven't found the cause yet, but I'll check it whenever I can. Our team is currently working on several projects other than TOAST UI, so it is difficult to process them quickly. Please use the previous version that works.

check v3.2.1 please, if you use react or vue wrapper, you need to use v3.2.2


Fix for potential issue where application is using both aws-s3 and right_http_connection

Sometimes applications are using both right_aws AND aws-s3.  This is notably true with the paper_clip gem, which is relying on aws-s3.
Both right_http_connection and aws-s3 do a few tricks with Net::HTTP.  My patch will rescue an error where send_request_with_body_stream is potentially redefined by aws-s3.  Their version only takes 4 arguments, as opposed to your 5.

+1

I think this issue and #4 are fixable by adding a new method with 5 arguments instead of the current approach of changing the signature of an existing method to take 5 arguments instead of 4. Reading right_aws, aws-s3 and rest-client source it seems to me that all three could coexist if right_aws patched Net::HTTP more carefully.

Oh, I had no idea that send_request_with_body_stream was a private method in Net::HTTP!  Why would right_aws chagne its method signature?  That seems bad!   Very bad! No wonder things are breaking.
right_aws definitely needs an update.   My pull request is simply a band-aid.  right_aws should not be redefining method signatures of core ruby libraries.
Furthermore this pull request has been opened for months.  I get the hint that this gem is no longer supported.  Is it being supported elsewhere?

When I said "right_aws" I meant of course right_http_connection, which is this project. right_aws uses right_http_connection to talk to aws.
right_aws (I mean it this time) does seem to be receiving more maintainer love than right_http_connection.

ditto.  I meant right_http_connection as well.

I intend to take a stab at rewriting Net::HTTP patches by right_http_connection to be less intrusive, no promises on when this happens though.

+1


Severe slowdown on larger galleries

简略描述 / Describe the bug
Galleries with a large number of images suffer from severe slowdown when looking at the thumbnails, often to less than 5 FPS. This is seemingly arbitrary, some galleries are slow while others don't suffer from it at all. For example, https://exhentai.org/g/1391961/d9999764df/ slows to about 2 FPS, while https://exhentai.org/g/1434664/68a2856374/ is at full speed.
I have a high-end device so I don't think my phone's performance is the issue. I should also note that I have the 40 thumbnail rows perk enabled.
如何重现 / To Reproduce
Steps to reproduce the behavior:

Load up a large gallery (e.g. https://exhentai.org/g/1391961/d9999764df/)
Page will start slowing down as more thumbnails load in
Slowdown stops once it goes into reader mode

预期行为 / Expected behavior
No slowdown.
设备型号与 Android 版本 / Device model and Android version

Device model: Samsung Galaxy Note 9
Android version: Android 9.0

What if only 4 rows are shown?


Trying to move a Page with restricted Parent Page Type results in Error

Issue Summary
We have several overview page - specific child page relationships in a project. The relationship is managed by using the parent_page_types and subpage_types attribute.
We noticed that, if a page has a single parent page type, wagtail crashes when a editor want's to move the page using the admin's bulk action.
Steps to Reproduce

Start a new project with wagtail start myproject
Edit models.py as follows:

from wagtail.models import Page

class SubPage(Page):
    parent_page_types = ["home.HomePage"]

class HomePage(Page):
    pass

Add a subpage of type SubPage to the existing Homepage
Try to move the subpage using the bulk action in the page overview
Get an error:

DoesNotExist at /admin/bulk/wagtailcore/page/move/
HomePage matching query does not exist.

This is probably a bug due to the root page being the initial value for the bulk action's form, which is not in the queryset determined by the allowed parent types. The error does not appear if you further allow SubPage to parent_page_types though.

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

Technical details

Python version:  3.10.6
Django version: 4.1.9
Wagtail version: Tested for Version 4.1., 4.2. and 5.0
Browser version: Firefox 113

Can confirm this issue. Basically as soon as you select a page with parent_page_types, the bulk move tool will crash.
I think the problematic code line is the following:
https://github.com/wagtail/wagtail/blob/6d4265cbfafdf6c0a556bb406aa0e9396fd2d1a4/wagtail/admin/views/pages/bulk_actions/move.py#L46
The MoveBulkAction always uses the root page as the initially selected page, and since the root page is usually a Page, this will probably fail if the target_parent_models are restricted to subclasses of Page. Removing or Page.get_first_root_node() fixes the issue.
I'm really questioning this initial selection of the root page as a default. Even in cases where the user can move the pages to any location, auto-selecting the root page as the default seems a bit error-prone, since the user may just click on the confirmation button by accident, moving all pages to the root... Moving pages to the root seems to be a very unusual action.
I think we should not auto-select any page, we should force the user to make a selection. Especially with more complex type restrictions, the opened page chooser will help the user to find a possible target page. Also auto-selecting a feasible default would be quite challenging (different page restrictions, different sub-trees,...).
Will try to make a PR based on a failing test.

Wondering why the failing test does not fail with the latest main-branch: it has been fixed with #10362 :sweat_smile:
I'm still not sure, if we should really select the root page by default...


IDL-to-C++11 v1.6

[ ] Add support for @optional
[ ] Extend support for the new type traits for bitmask

Specification: https://www.omg.org/spec/CPP11/1.6
Issues fixed in v1.6: https://issues.omg.org/issues/spec/CPP11/1.6/fixed

Support for the new IDL to C++11 type traits for bitmask has been added to the prototype.

First code to support @optional annotation on https://github.com/jwillemsen/taox11/tree/jwi-idl4optional


does not mention the  element

the reference element is a child of the itemgroup element . It is used to reference an assembly.  It is not mentioned in this article.  This article defines <item> as the only child type of itemgroup.
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a7148a9c-77db-81c7-0362-f2ce6b0c6274
Version Independent ID: ccef6249-9a81-9376-a9c8-fe884d0b094f
Content: ItemGroup Element (MSBuild) - MSBuild
Content Source: docs/msbuild/itemgroup-element-msbuild.md
Product: visual-studio-windows
Technology: msbuild
GitHub Login: @ghogen
Microsoft Alias: ghogen

@leotohill
Probably what is needed here is a statement that any of various elements that are items can be used.  For example, any of the elements listed as item types here: https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-items?view=vs-2022


Basic usage breaks in Nuxt SSR

FeathersVuex breaks on Nuxt SSR with the most basic usage.
$FeathersVuex.Todo items load fine on client side (open root, then click the link to /todos);
On server side (refresh /todos), infinite recursion happens in toJSON in feathers-vuex/lib/service-module/model.js:237.
Steps to reproduce
See this repo/branch for a reproduction:
https://github.com/Palivonas/feathers-vuex-bug-reproduction/tree/models-tojson-nuxt-ssr
FeathersVuex 1.7.0-pre.54.
Node 10 and 8 tested, app created using create-nuxt-app.

Woops... That's my fault probably. Why does infinite recursion happen? Is there a circular reference?

There's likely a circular reference in the instanceDefaults that's causing this.  The fix is likely to make toJSON more intelligent so it excludes props that are getters, setters, or other models.

Shoot. That's not super simple to do, is it? I've experienced complications in doing that in the past.

It's way simple. Each Model already keeps an internal list of relationships, so that will just need to be made accessible to the toJSON method.

Sweet. Well I can try to look at this at some point. Thanks for the reproduction repo @palivonas!

Just a tip to make your work easier: run node ./node_modules/.bin/nuxt in your IDE so you can place breakpoints and stuff.

Yeah, this is the same spot to fix the getters.

Sorry for the later reply. Thanks for the effort @NickBolles, this does fix some things! Not completely, unfortuntely.
Updated the reproduction repo. Getter data gets included in toJSON result, therefore SSR still breaks completely and models can't be stringified on client side either. Apart from breaking, including getter data in toJSON is undesirable, I think.
Maybe this could be fixed by listing properties from instanceDefaults() and excluding any getters and methods present in there?
I also realized another (bigger?) SSR-related issue. FeathersVuex models don't only lack instanceDefaults methods when loaded via SSR - they don't have any model methods (clone, save, etc.). Methods get serialized into empty objects though.
I guess objects in the pre-rendered state should be wraped in FeathersVuex constructors on load somehow?

@Palivonas the issue with models loaded after ssr is a separate issue from tojson. (Classrs and getters/setters/methods can't be serialized)
We can look at wrapping everything in the store again, which should restore all getters/setters/methods.
What getters are you seeing being included that shouldn't be? Maybe we need to include an option to overide/extend the tojson implementation?

@NickBolles Yeah, SSR data wrapping is out of scope for this issue, agreed.
What I mean about undesirable data in JSON is simply instanceDefaults getters being included in toJSON result. In the example repo User model has a todos getter, which finds all todos in store belonging to the user. Todo has a user getter (which is commented out as the circular structure breaks toJSON currently). These are handy to use in rendering or some logic (that's why it was introduced to FeathersVuex after all).
When I patch a model (or do anything else requiring its serialization), I wouldn't expect or want all the relationships and virtual properties (which are all defined as getters) to be included in the JSON. Validation on API side, unnecessarily large payloads, unintentionally exposing sensitive data (like the user object), duplicate objects for the same record in state loaded from SSR.
But maybe I'm approaching this wrong? Let me know what you think.

Yea. I agree. But I'm not sure what the default state is, of a JavaScript class with a getter only.
You can always do object.defineproperty with enumerable false to define the getter, which should make the property non enumerable and ignored by the merge function, and thus the toJSON method.

enumerable: false is a great idea actually. So simple that I'm ashamed I didn't think about it 😅 It solves both the circular reference problem and undesirable computed data being present in JSON.
No need to reopen this issue then. Model instantiation can be tackled with in the other issue. Thanks again for the help!

@NickBolles @Palivonas I know one of you mentioned docs, recently.  I'm not sure which issue it was in.  I've moved the docs into this repo if there's anything to update.  Just check out the docs directory.  You can build locally with npm run docs:dev, since it's a vuepress site, now.

@Palivonas BTW, Check out this runkit for some tests on classes/properties and combinations of defineProperty.
https://runkit.com/nickbolles/lodash-merge-and-defineproperties

note: the rest is kinda for self-documentation and should move into the feathers-vuex docs at some point

Basically getters should, by default be enumerable: false, (another source) whether they are setup on a class, or without passing the enumerable key to the defineProperty call.  So in order to have something from instanceDefaults (or any javascript object/class) serialize to json you have to set enumerable: true.
For Feathers-Vuex, this means that instance defaults should be setup with Object.defineProperty, or Object.defineProperties calls. This can be before or after the object is constructed (see modifying a property)


Duplicate address

Bug report
Duplicate address
** During each checkout, the address is duplicated.
1. framework Version: v1.2.0-BETA1
2. Commit id: 80bd331123bfd24b87f5926afe7f90599b14e27c

Steps to reproduce
1. Checkout with a new address and check save address
2. Next time select the address and checkout
3. Try another checkout, you'll see the address has been duplicated

Expected result

Saved address should not be copied to save again.

@sha443
It seems you are using the bagisto v1.1.2 as the reported bug is already fixed in our Beta release 1.2.0. please check here https://github.com/bagisto/bagisto/issues/2987
Take the Pull from this PR then check again.

@sha443
Hope your query is resolved now, so closing this.
Feel free to reopen it any time.


Odd ncdump + hdf4 behavior on macOS

All, I'm a bit baffled by this and I need some help from the gurus with an oddity reported by a colleague.
I build netCDF in a set of libraries and as far as I can tell, on both my mac and Linux builds, hdf4 and netcdf-c are all built with the same options. With hdf4 I pass in --disable-netcdf and with netcdf-c I pass in --enable-hdf4. The only big difference is CC, CXX, and FC (clang/gfortran or clang/nagfor on macOS, various on Linux).
But ncdump (and thus I assume all of netcdf?) act differently. On Linux I get:
$ ncdump MOD04_L2.A2017090.0010.051.NRT.hdf | head
netcdf MOD04_L2.A2017090.0010.051.NRT {
dimensions:
	Cell_Along_Swath\:mod04 = 203 ;
	Cell_Across_Swath\:mod04 = 135 ;
	Solution_3_Land\:mod04 = 3 ;
	Solution_1_Land\:mod04 = 2 ;
	Solution_2_Land\:mod04 = 3 ;
	Solution_4_Land\:mod04 = 4 ;
	MODIS_Band_Land\:mod04 = 7 ;
	QA_Byte_Land\:mod04 = 5 ;

on macOS I get:
$ ncdump -hsc MOD04_L2.A2017090.0010.051.NRT.hdf | head
netcdf MOD04_L2.A2017090.0010.051.NRT {
dimensions:
	Cell_Along_Swath\:mod04 =<PHONE_NUMBER>2820359168 ;
	Cell_Across_Swath\:mod04 =<PHONE_NUMBER>1679508480 ;
	Solution_3_Land\:mod04 = 50331648 ;
	Solution_1_Land\:mod04 = 33554432 ;
	Solution_2_Land\:mod04 = 50331648 ;
	Solution_4_Land\:mod04 = 67108864 ;
	MODIS_Band_Land\:mod04 = 117440512 ;
	QA_Byte_Land\:mod04 = 83886080 ;

Now this file is around 500 kiB so I'm guessing Linux has it right. (The macOS one wouldn't fit in the known universe probably.)
Does anyone know why this is happening? I freely admit it might be "You built hdf4 wrong with clang" or "on macOS" as, well, I never use hdf4 files myself (only netcdf4) so it's possible I've been doing this wrong for years.

@DennisHeimbigner Well that is...weird. I mean, one machine is NCCS Discover (SLES12) and the other is a MacBook Pro (macOS Ventura). Neither are big-endian at all, and my Baselibs has no flags for endianness conversion.
I guess I'll stare at the macOS config.log for hdf4 (and dependent libraries like szip and jpeg) and see if it's somehow getting the wrong endianness?

Huh. Well from the hdf4 (and hdf5 and netcdf) configure:
checking whether byte ordering is bigendian... no

so autotools is quite satisified this is a big-endian system.
My colleague whipped up a code that reads the HDF4 file via netcdf (Fortran in this case) and on Linux:
+ ./test.x
  filename=MOD04_L2.A2017090.2000.051.NRT.hdf
 fileName=MOD04_L2.A2017090.2000.051.NRT.hdf
 ncid=       65536
 lon_name=Cell_Along_Swath:mod04
 ck step 1
 ck step 2
  nlat, nlon                             135                             203

but on macOS:
+ ./test.x
  filename=MOD04_L2.A2017090.2000.051.NRT.hdf
 fileName=MOD04_L2.A2017090.2000.051.NRT.hdf
 ncid=       65536
 lon_name=Cell_Along_Swath:mod04
 ck step 1
 ck step 2
  nlat, nlon                     -2030043136                      -889192448

Just...bizarre.
I even tried using -fconvert=big-endian on the macOS one to see if that changed anything, but no difference (as expected).

Well, I managed to show oddities with hdp and asked the HDF Group here:
https://forum.hdfgroup.org/t/weird-hdf4-behavior-on-macos/11603


[Bug] [EC][JDBC] JDBC connection does not support multi-tasking parameter passing

What is the purpose of the change

Optimize JDBC connection support cache by task id
optimize manager module entity class override toString method
check_env.sh add source bash profile step
Fix dataSource build assembly bug

Related issues/PRs
Related issues: close #5006
Related pr:#591
Brief change log

Optimize JDBC connection support cache by task id
optimize manager module entity class override toString method
check_env.sh add source bash profile step
Fix dataSource build assembly bug

Has this issue been resolved?


Fix CI error on test_misspelled_key

Error seem to be due to pytest wrapping errors, and the str()
representation of the error not always having the full error message of
the underlying error.

I have issues reproducing the error locally so this is kind-of a shot in the dark.

The pytest 5.0.0 release notes mention that you should change assert "some message" in str(e) to assert "some message" in str(e.value). Does this work without changing the string?

Yup, that seems to be OK.

The pytest 5.0.0 release notes mention that you should change assert "some message" in str(e) to assert "some message" in str(e.value)

Ah thanks I missed that.
Hope you had some good time off !

I did, thanks :-)


Mismatch parenthesis

import Html exposing (text)

(

main =
  text "Hello, World!"

The current error message doesn't mark the parenthesis at line 3.
-- SYNTAX PROBLEM ----------------------------------------------------
I ran into something unexpected when parsing your code!

5| main =

I am looking for one of the following things:

    whitespace

Thanks for the report! Going to continue tracking in meta issue #177.

Working on new parser that gives better error messages. Here's the new error:

The trick is that you can start a definition with ( like (x,y) = 42. If you have specific requests of how to improve this message further, open a new issue.


Added ability to EXPLAIN queries in Debug panel

I add explain queries in debug panel and method in Query class.

Any news on this? Is this reviewed? Ready to be merged? Something missing?

I am unsure this will work, since actual query is not written in the logs.
Logs contain only a close approximation to the actual query been performed.
Although it may work in some cases, explain may fail unexetecly for some queries.

@klimov-paul This works only for FIND queries. Now all FIND queries are logged using MongoCursor::info, so everything is standardized and should be no problem.

Merged manually.
Thank you.