Update readme

Codecov Report
Patch and project coverage have no change.

Comparison is base (26c2d04) 98.93% compared to head (4aa55b6) 98.93%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #497   +/-   ##
=======================================
  Coverage   98.93%   98.93%
=======================================
  Files          16       16
  Lines        1315     1315
=======================================
  Hits         1301     1301
  Misses         14       14

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Rework shard block and fraud proof (shard state transition) spec

Issue

Make the fraud-proofs.md spec in Python functions.
Add a basic test for shard transition.

How did I fix it

beacon-chain.md

Rework shard block

Replace block wrapper with signable pattern
Add proposer_index to shard block since the proposal index helps clients to validate the block in network level.

Refactor get_light_client_committee a bit.
Fix the wrong get_shard_proposer_index function calls
Update apply_shard_transition

Rewrite the current fraud-proofs (shard state transition) spec in Python code
Add basic sanity test for shard transition

Thanks @djrtwo!
All comments are applied or replied.
Changelog

Apply PR feedback
Rename & fix typos
phase1-fork.md:

Add stub PHASE_1_GENESIS_SLOT, set it to SLOTS_PER_EPOCH now.

fraud-proofs.md and beacon-chain.md

https://github.com/ethereum/eth2.0-specs/pull/1703/commits/bb49c0891298ec5d88e540abf34855c0aac723a3 and https://github.com/ethereum/eth2.0-specs/pull/1703/commits/010201c65a5e45625f5fa4156e728662c1588329:

Agreed that the skipped slot should affect  gasprice.
Should have used beacon_parent_root=get_block_root_at_slot(state, offset_slots[i]), thanks!
1. We could use the latest non-skipped slot block as the shard parent block, but it seems to not affect shard state at all? I simplified it to just BeaconBlock(slot=offset_slot[i]) in https://github.com/ethereum/eth2.0-specs/pull/1703/commits/010201c65a5e45625f5fa4156e728662c1588329 now since only slot matters in shard transition now.

https://github.com/ethereum/eth2.0-specs/pull/1703/commits/1aab7883ab9002c8dd60e0e40bae8f6fb9484162: Add verify_shard_block_message. Note that currently it won’t throw exception from get_shard_transition since get_shard_transition is a helper to select the valid proposals. Note that the honest validator guide may use verify_shard_block_message, so verify_shard_block_message and is_valid_fraud_proof would only be called upon receiving the shard blocks.

Substantive changelog

Fix typo attestation.slot == state.slot -> attestation.data.slot == state.slot in is_winning_attestation
Check verify_shard_transition_false_positives after process_operations
Fix shard_attestations filter in process_crosslinks: since attestations come from block, should use attestation.data.slot + MIN_ATTESTATION_INCLUSION_DELAY == state.slot
[TBD] Allow empty light_client_signature to make the tests pass
Tests updates

Rework and refactor test_process_crosslink
Add basic phase 1 test_blocks ✨

test_process_beacon_block_with_normal_shard_transition: with basic on time shard attestation
test_process_beacon_block_with_empty_proposal_transition: The protocol acutally allows on time attestation that votes for "empty shard block proposal", i.e., creating shard transition with shard_blocks=[] for the skipped shard block.

After (3), some other tests failed. (e.g., test_finality), this PR updates the test helpers for backward compatibility, still kinda messy though.

Fix shard_attestations filter in process_crosslinks: since attestations come from block, should use attestation.data.slot + MIN_ATTESTATION_INCLUSION_DELAY == state.slot

Note, MIN_ATTESTATION_INCLUSION_DELAY is essentially deprecated wth the new phase 1 design and must be set to 1

Looks good in general! I'm happy to merge soon and move on with subsequent testing PRs

@djrtwo

Note, MIN_ATTESTATION_INCLUSION_DELAY is essentially deprecated wth the new phase 1 design and must be set to 1

👍 Added a comment to note that.

I'm happy to merge soon and move on with subsequent testing PRs

I refactored the tests and I'm happier with it now 😄
also squashed the reviewed commits by review cycles. I think it's okay to merge it now and then add more tests with other PRs.


Feature/wsio 720 blog article author bio streamx

WSIO-720
Screenshots (if appropriate)

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue) labeled with bug
[ ] New feature (non-breaking change which adds functionality) labeled with enhancement
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] My code follows the code standards of this project.
[ ] My change requires updating the documentation. I have updated the documentation accordingly.

50 tests fails, mostly spacing, some of them due to image differences (tests are to sensitive maybe, images not changed). And one problematic:


Add Update lifecycle stage field to UpdateWorkflow and PollUpdate response protos

What changed?

Add a new field stage to UpdateWorkflowExecutionResponse and PollWorkflowExecutionUpdateResponse

Why?

See https://github.com/temporalio/temporal/pull/5084
Both these endpoints attempt to wait until a requested Update lifecycle stage is reached, but they lack a way to explicitly communicate what was learned about the Update stage during this long poll. Instead, they imply this via the presence or absence of the outcome.
In particular, outcome=null means Accepted but not Completed is known to have been reached.
In addition to this being unclear, we have found that we want to use outcome=null to mean something different in another context (https://github.com/temporalio/temporal/issues/4742).

Breaking changes

No: addition of a field only

Ready for final review.

Note that you're blocked on the gogo refactor in the server repo for now and won't be able to use this, you might want to also open a PR targeting a branch before this refactor if you're eager to use these protos already.

https://github.com/temporalio/api/pull/326


Add/expose additional NodeJS.Timer functions to the timer implementat…

…ions #124

Codecov Report

Merging #128 (e32ae59) into main (9ca411f) will increase coverage by 0.02%.
The diff coverage is 100.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #128      +/-   ##
==========================================
+ Coverage   98.89%   98.92%   +0.02%
==========================================
  Files          63       64       +1
  Lines         999     1023      +24
  Branches      201      208       +7
==========================================
+ Hits          988     1012      +24
  Misses         11       11

Impacted Files
Coverage Δ

lib/src/timer/handler.ts
100.00% <100.00%> (ø)

lib/src/timer/idle.ts
100.00% <100.00%> (ø)

lib/src/timer/interval.ts
100.00% <100.00%> (ø)

lib/src/timer/timeout.ts
100.00% <100.00%> (ø)


[EN DateTimeV2] Specific datetime phrase returns two results instead of one

Describe the bug
When given the phrase "between 7 and 9 last night", the DateTimeRecogniser returns two results - the first refers to "between 7 and 9" and has a null Resolution, and the second result refers to "last night" and contains a timespan of 20:00 to 24:00 with yesterdays date.
The phrase is a fairly common usage in conversational British English. It would seem that the problem is with the underlying DateTimeRecogniser.
Expected behavior
Ideally, this would be a single timespan of yesterdays date between 19:00 and 21:00.
[bug]

More info:
https://github.com/Microsoft/botbuilder-dotnet/issues/1472

Closing this issue as partially resolved in #2180. Remaining issues tracked as #2262.


Dragon form only shows remaster options

Dragon form only shows options for monster core dragons, even though old (bestiary) dragons should still be viable picks. The text for dragon form simply references common dragons, see "choose one type of common dragon".
This is further reinforced by the player core's reprinting of the reactive transformation spell, which lists:
Trigger You take acid, cold, electricity, fire, or poison damage; Effect Choose a shape from dragon form that resists the triggering damage.
If monster core dragons were the only viable options, then only 2 out of these 5 listed damage types would have a valid option to shape into with this reaction.
The legacy module has the old options for dragon form, but requiring a module for options which should be available to anyone isn't ideal, especially since a feat (reactive transformation) references options that wouldn't exist without these old dragons. On top of that, the legacy module has the old dragon forms with varying damage dice for the breath weapons and attacks, while they should all be uniform since the remaster (10d6 base and 14d6 heightened for the breath weapon for example), as per the dragon form spell in the player core.

Hi there,
The current version of the Dragon Form spell is predicated on dragons associated with magic traditions. Legacy dragons unfortunately do not have any associated magic traditions. Paizo will need to provide clarification on their end on how Legacy dragons fall in line with the traditions of magic.
We will leave the issue open for the time being.

The spell effects for the older dragons can be found in the legacy content module.
We'll revisit this and any other legacy content if Paizo issues guidance on converting them.


MF-1668: Auto renewal of expired certificates from the PKI issuer

What does this do?
Renew the expired cert, If the cert is not available in bootstrap and thing service, then it will remove all the certs.
Which issue(s) does this PR fix/relate to?
Resolves #1668
List any changes that modify/break current functionality
Have you included tests for your changes?
Did you document any new/modified functionality?
Notes

@mainflux/maintainers
Hello,
At present, in certs table, one thing can have Mutiple certificate, in cert table one thing will Mutiple expired certificate,
So if this PR tries to renew all the expired certificate of one thing, then there will be lot of certificates for a thing,
So to solve this problem, this PR is approach in different way, One thing can have one certificate.
The cert service will renew expired thing certificate and update the serial number in cert table.

Codecov Report

Merging #1669 (b23b77a) into master (933b5de) will decrease coverage by 0.71%.
The diff coverage is 1.53%.

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

@@            Coverage Diff             @@
##           master    #1669      +/-   ##
==========================================
- Coverage   68.99%   68.27%   -0.72%
==========================================
  Files         147      147
  Lines       11811    11931     +120
==========================================
- Hits         8149     8146       -3
- Misses       2941     3063     +122
- Partials      721      722       +1

Impacted Files
Coverage Δ

certs/postgres/certs.go
0.00% <0.00%> (ø)

certs/service.go
48.34% <2.94%> (-37.37%)
:arrow_down:

pkg/messaging/nats/publisher.go
50.00% <0.00%> (-9.10%)
:arrow_down:

things/service.go
65.35% <0.00%> (-0.72%)
:arrow_down:

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

This PR depends on the following issues
https://github.com/mainflux/mainflux/issues/1677
https://github.com/mainflux/mainflux/issues/1676


[GOCA] externalize client and modify the way to access to the resources (warning: breaking changes )

Description
This pull request make some changes on the client, and the whole API.
/!\ It's an important breaking change /!\
As this imply breaking changes, I added some documentation (PR in the docs repository, and added some examples)
This pull request adds a controller notion.
It's an cheap layer added between the client and the entities API (host, vm ...).
It allows to rework the way to access to the resources via the API in a way that seems more intuitive to use.
For instance, to make requests, now, it's like this:
vm, err := ctrl.VM(id).Info()                              // Retrieve VM informations
err := ctrl.VM(id).Delete()                                // Delete a VM
err := ctrl.VMs().Create(template, boolean)    // Create a VM
vms, err := ctrl.VMs().Info()                            // Retrieve a list of VM informations (with less informations per instance)
id, err := ctrl.VMByName("vm_name")            // Retrieve an ID by name

In addition, this controller embed a client.
This pull request also externalize the client and allow to redefine it (For instance you may want to define a pool of clients to enabling some concurrency, or make a client that retry if the request fails ... ).
If the RPCCaller interface is implemented, the controller can use the external client.
I added some configuration for the HTTP client, which correspond exactly to the GOCA use case.
I also added some changes to the lock part to be more maintainable, add added some missing methods
Use case
Users of GOCA may want more flexibility on the client, and a more natural way to access the resources
Interface Changes
A great part of the API change.
Additional Context
I will provide a pull request in this way.

Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

This is a very useful improvement. Any feedback from the OpenNebula team whether or not this is something that will be merged?

Thank you very much for your feedback :)
It's not perfect, but it proposes some changes that we need.
I discuss with the OpenNebula member in charge of the Go binding, he seems busy but as far as I know it's being reviewed and some other pull request have been merged these days.


fix: remove eventsource dependency

We dont need the dependency, as we only need it for the types of EventSource. smee-client is returning an EventSource instance. Also we have already EventSource definitions provided by typescript ;).

Node 22.3 also added experimental built in EventSource. We may be able to use this in smee-client once it's stable.

@AaronDewes
https://github.com/nodejs/node/pull/51575
:D
As there is no intensive test suite for EventSource like Autobahn Testsuite for Websockets, it is maybe far in the future to remove its experimental status. Also it uses wpt tests for EventSource and if i remember correctly also the tests of the eventsource npm implementation :D.
But maybe one day.


Fix docker build failure

The error is below:
Step 5/10 : FROM gcr.io/distroless/base-debian11
manifest for gcr.io/distroless/base-debian11:latest not found

Exited with code exit status 1

Sample failed build here

Fixed by https://github.com/devatherock/artifactory-badge/pull/235


Improve strings

The variable-length strings idiom can be improved with a assert (test Kind pattern) and by adding a max-length facet to each string.

Fixed in 6b5b67edf7410033f27d0e7ea455008e074ef97a


Feature/home page text

Title: Improve the text at the top of the home page
Description: Received the latest home page text from the product team.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: harrish3 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Use Process.spawn to start gui and server

🦟 Bug fix
Partially addresses #44 to improve the cross-compatibility of gz sim to spawn both server and GUI.
Summary
When gz sim is invoked without specifying the GUI -g or server -s, the cmdsim.rb script will fork itself twice, and each child process calls into a different entrypoint.
This doesn't work well on macOS, where it is generally unsupported to fork without exec. Instead, the script makes the user manually start the server and GUI processes separately.
This changes the script to, immediately after parsing options and noticing the absence of -g or -s flag, spawn gz sim -s and gz sim -g. This is a more cross-platform way to execute the GUI and server in subprocesses. It also reduces some code duplication.
Downsides include:

The subcommands can output the same thing twice. A simple case is:
 $ gz sim --version
 Gazebo Sim, version 9.0.0
 Copyright (C) 2018 Open Source Robotics Foundation.
 Released under the Apache 2.0 License.

 Gazebo Sim, version 9.0.0
 Copyright (C) 2018 Open Source Robotics Foundation.
 Released under the Apache 2.0 License.

Another example would be if some error happens when loading the library, it will be printed twice.

On Windows, the GUI might immediately exit, so the parent will kill the server too. The user should manually specify -s.

It might be incorrect in some pathological case to launch the children with gz sim, e.g., if the original command was executed by explicit executable path, and the first result for gz in the search path is not the same binary.

When one child process exits, the other is killed by the parent. However, it seems the kill command always errors for me on macOS, I'm not sure why.
/opt/homebrew/Cellar/gz-sim9/8.999.999-0-20231016/lib/ruby/gz/cmdsim9.rb:202:in
`kill': No such process (Errno::ESRCH)

Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

cc @srmainwaring -- I don't think this will quite work due to the drawbacks, but wondering what others' thoughts are.
It would probably work better to have a small shim binary that just accepts the arguments to runServer() and/or runGui() to execute, and then you could fork-and-exec (or spawn) and it would be happy.

I don't think this will quite work due to the drawbacks, but wondering what others' thoughts are.

@rgov - I find launching the server and gui separately less of an issue than the side-effects you highlight. In fact I prefer to run the server and gui separately for most of my work. Often I'll need to restart the server (changing controller PIDs or other params that do not change the number of entities), the GUI I can leave running with whatever visualisations are required. It is also easier to trace what is going on in the console with verbose output when the serve and gui outputs are not interleaved.
When using ROS launch scripts to bring up a more involved simulation the separation of server and gui is not an issue, just an extra line or so in the launch description.

Agreed the solution presented here has too many drawbacks. I prefer the lib host process idea, where Ruby just does command line parsing and then executes one or more binaries that expect a fixed set of arguments.
Consider that many tutorials are written with the assumption that gz sim launches both. It creates confusion to have these basic commands have different behaviors on different platforms. It doesn't help the situation to make every tutorial have to call out these idiosyncrasies.
(10,000 ft viewpoint: Gazebo and ROS both aim to be cross platform but in reality Linux support is leaps ahead. With the ease of WSL, Docker Desktop, and VMs these days, it probably would be both a better user experience and far less development effort if the projects focused on Linux.)

it probably would be both a better user experience and far less development effort if the projects focused on Linux

Except that there is currently no VM that provides accelerated graphics for Gazebo on macs, and docker is a non-starter for graphics as well. The performance of the M1 laptops running ROS 2 and Gazebo natively is very good. Example: the nav2 stack are scaling back the rendering of the turtlebot example in the migration away from Gazebo Classic because of performance issues. A M1 MacBook will run Gazabo Harmonic, nav2 and ArduPilot SITL at RTF >=1 - easily. So I think it's worth the effort.

I'm a vocal supporter of native software for macOS, so I'm with you that a native experience would be great. Unfortunately, in trying to run Gazebo Harmonic, I've hit many stumbling blocks (installation failures: https://github.com/osrf/homebrew-simulation/issues/2549, freezing GUI: https://github.com/gazebosim/gz-gui/issues/513, gz sim tutorial commands don't work as-is as in the intro tutorials, the "banana for scale" is all black, etc.).
I'm hoping to use ROS with Gazebo, that means installing ROS from source. And hopefully the needed rosdeps are installable on macOS---by my count about 247 are, vs 1096 for Ubuntu.
For me right now, a non-hardware accelerated VM would be lower friction. Even better, VMware Fusion supports graphics acceleration to Linux VMs, and probably this is provided by Virtualization.framework?

On Apple Silicon, Fusion can deliver OpenGL 4.3 with blazing fast 3D hardware acceleration to arm-based Linux virtual machines with Linux kernel 5.19 or greater.

Docker for GUI apps indeed is not user friendly at all. The options I've explored are connecting into the container with VNC, and forwarding to XQuartz on the host. If you have graphics acceleration on the guest, you can add VirtualGL to improve performance. The multicast UDP favored by Gazebo also requires some workarounds.
At any rate, I'll close this because it was a bad solution, but I hope another solution will help remove this speed bump on macOS.

@rgov - sorry to hear your experience running Gazebo on macOS has not been good. I build Gazebo from source and don't run into that many issue in daily use. I'm about on Discord if you need a hand getting set up (including ROS Humble).

@rgov @srmainwaring I've managed to install ROS2 Jazzy and Gazebo Harmonic on MacOS (apple silicon)!
I've made a one-liner installation script at https://github.com/IOES-Lab/ROS2_Jazzy_MacOS_Native_AppleSilicon
Yes, https://github.com/gazebosim/gz-gui/issues/609 does occur and gz sim building_robot.sdf from intro tutorials fails with Unable to find or download file But as @srmainwaring metioned, it seems ok for daily tests. Much referenced from @srmainwaring! My student will spend time building your wave - sailboat simulator this summer! (much to port for Jazzy-Harmonic combinations).

@woensug-choi Nice work. Do you think you could contribute some of your patches upstream to the osrf/homebrew-simulation tap?

working on https://github.com/ros2/ros2_documentation/pull/4550#pullrequestreview-2126816084 first :)


Update SCsub file in /servers/ folder

Both spatial_sound and spatial_sound_2d folders are no longer exist in master.

Thanks! I was going to this but forgot 😆


Bugfix/ab#23449 enable close status

hi @AndreGAot -- this is now ready for your review. Thanks.

@aurelio-aot - as discussed, these methods / services needs some renaming and refactoring, I will have a look at what needs to be done here and get back to you


Turn this into a separate package

After some time we might want to push this into js2-mode repo/org, but for now let's have a package with cask, buttercup and all the nice things.

https://github.com/Fuco1/flow-js2-mode


Rework of Push Material

I have an internal URL where I staged this. Googlers ping me if you need it.

It's also here: https://pr-2767-dot-weasel-dot-web-central.appspot.com/web/fundamentals/engage-and-retain/?hl=en
I need to look over this


[quarkus] refactor rabbitmq pubsub

Description

https://labs.gree.jp/blog/2010/06/262/
https://blog.mookjp.io/memo/rabbitmq-learning/#amqpのコンセプト

jaxrs
# producer
exchange.name=converter
default-routing-key=converterkey
# consumer
exchange.name=message
routing-keys=messagekey
queue.name=jaxrs

converter
# producer
exchange.name=message
default-routing-key=messagekey
# consumer
exchange.name=converter
routing-keys=converterkey
queue.name=converter

consumer
# consumer
exchange.name=message
routing-keys=messagekey
queue.name=consumer


Create julia.school.md

The static site https://julia.school is a fast-loading 100% free resource for the growing community of Julia coders. Thanks for giving life to the 1MB club!

Thanks! Updated accordingly.


[enhancement] Please add screenfull.min.js to npm

It would be very helpful if you could please add screenfull.min.js to npm.  My application uses many front end libraries and screenfull is the only one that does not publish the minified version to npm.
Adding this would help my usecase tremendously and should not impact anyone else's usage of the library.
Thank you for considering it.

I'm not interested in that. You can get a minified version at https://unpkg.com or https://www.jsdelivr.com


Allow loading PSK-ID's longer than 64 chars from settings

I have been testing out the various features of the Golioth SDK and console. When testing the 'samples/settings' project I ran into an issue (net_sock_tls: TLS handshake error: -7780) when the system client was trying to connect to the Golioth servers .
After debugging the issue, the root cause is that golioth_dtls_psk_id (in system_client.c)  is only set to allow PSK-ID's with a max length of 64 chars.
This fix is needed because 'console.golioth.io' will auto-generate and allow psk-id's over 64 chars.

Closing, since #394 was merged and addressed the same issue.


⚠ Bofrost.nl has degraded performance

In 7e35501, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 1939 ms

Resolved: Bofrost.nl performance has improved in bda7d0a after 6 minutes.


WAV Duration Limit & RF64 Delay

Hello! I updated to v1.9.8 today and noticed that my Google Nest Audio speakers stop playing every 2 hours, 4 minutes, and 16 seconds. Sure enough, as I test it with VLC by playing the stream locally, the duration of the stream is exactly 2:04:16. This is probably due to the changes you announced some versions ago to LPCM, WAV, etc. as it matches what I would expect to see if the WAV file is limited to 4GB in total. The current situation is this:
The only format that plays nicely with the Google Nest Audios is WAV:

On WAV/16/48, it lasts about 6 hours with a delay of ~4 seconds.
On WAV/24/96, it lasts about 2 hours with a delay of <1 second.
RF64 plays, it lasts about 3 hours, but has a truly massive delay on the order of ~10 seconds.
LPCM straight up won't play any more.
FLAC plays, but with a host of issues.

I am using WAV/24/96 to keep the delay to a minimum, but the time limit is quite noticeable when you resume playing many times a day. Since I just tell my speakers to play the stream, essentially what you call internet radio mode, there is no decent way to automatically resume (certainly no seamless way that I know of).
I do not know whether Nest Audios just don't handle RF64 right or what else would cause that extreme delay and 3 hour limit. It might be noteworthy that RF64/24/96 lasts 3h, 6m, 28s which is almost exactly 50% longer than WAV/24/96 to the second (~4 s difference) so maybe there is something going on inside swyh-rs that causes this?
Long story short:
Is there any way for me to make the WAV stream be infinite duration (or at least very, very long) in the settings? I assume that everybody who is using internet radio mode will run into the same situation.

What has changed is the http content-length header value, to accomodate some other speakers.
I could make it configurable in the config file, a value for each format, allowing you to experiment with it.
Previously IIRC it was u64::max and I had to change it to i64::max and i32::max for these speakers.
You could then compute the value based on bytes per sample, sample rate, number of channels (always 2 here) and the desired duration and insert that value in the config file.
What do you think?
I suppose that the Nest only accepts u64::max as an indication  for a never ending stream because that is also what the RF64 header does.

Sure, that sounds reasonable!

Can you try the new RC1 prerelease?

I released 1.9.9, most combinations of format/streamsize work OK here with my Moode players, at least 2 streamsizes for every format.


Question mark for childless + split selection and explosion from label to icon

#90 and #91

@ddelpiano I also found a bug with the hierarchy component node selection and expansion.
If you click on the expand/collapse of a node for the first time, it fires an event to select the node. It only happens the first time the expand/collapse icon is clicked, works fine after.


Add preset aliases to the search index

When I add a POI and search for "barber", it only finds "Hairdresser Supply Store" (shop=hairdresser_supply) but not "Hairdresser" (shop=hairdresser). I was wondering if it would be possible to tweak the code to find both for this value.
I browsed through the code and I thought maybe it's related to the id-tagging-schema, but searching for a barber in iD does come up with hairdresser.

Actually, aliases should be used in search, so let's keep this.

Done in 3518beb.


Docker Compose Rewrite

Summary

RFCs: Link to RFC, Link to RFC, or $\emptyset$.
Categories: any of protocol-units, networks, scripts, util, cicd, or misc.

Changelog

Testing

Outstanding issues

gali

gali

gali

Looking into Celestia Websocket unavailability. The only parameter related to the websocket not listening on <IP_ADDRESS> was --proxy_app.
If --proxy_app does not prove to be a fix, then we will have to take a deeper dive into Celestia networking in Docker containers. Unfortunately, there are no merged docs; and, there's is not much here about specifically using celestia-appd within Docker:  https://github.com/celestiaorg/docs/pull/1364
A fall back could be use use a Mocha or Arabic light client. Additional setup scripts for this would need to be provided.

https://github.com/celestiaorg/celestia-app/discussions/3578

just fix the conflicts at merge it ; it PR is too huge to review in a timely manner


Questions about exception propagation in Armeria gRPC client with a RetryingClient decorator

Hi there! I have 2 questions about how exception propagation behavior in Armeria gRPC client with a RetryingClient decorator. It seems to me that there could be a bug.
Setup
Armeria version: 1.16.0
Client setup
I build a gRPC client stub with a ClientBuilder and I add 3 decorators to the ClientBuilder as shown below:
// Please note that "Site A/B/C/D" mentioned in the comment below will be referred in later discussion.

// Decorator 1
clientBuilder.decorator((delegate, ctx, req) => {
    val httpResponse = delegate.execute(ctx, req)
    httpResponse
        .mapHeaders(respHeaders => {
             // Site A
             // 1. create an exception based on the response header content.
             // 2. throw the created exception.
        }
})

// Decorator 2
clientBuilder.decorator((delegate, ctx, req) => {
    ctx.log() // ClientRequestContext
      .whenComplete()
      .thenAccept(requestLog => {
          val exception = requestLog.responseCause()
          // The above `exception` is always null except in the case where
          // the last retry attempt fails.
          // Site B
       })
    delegate.execute(ctx, req)
})

// Decorator 3
val retryDecorator = RetryingClient.newDecorator(createRetryConfig())
clientBuilder.decorator(retryDecorator)

def createRetryConfig(): RetryConfig = {
   // ...
   val retryRuleBuilder = RetryRule.builder()
   retryRuleBuilder.onException((_: ClientRequestContext, cause: Throwable) => {
     // This callback is NEVER invoked.
     // Site C
   })
   retryRuleBuilder.onResponseTrailers((ctx, trailers) => {
     // This callback is invoked. The retry decision is made based on `trailers`
     // Site D
   })
   // Create a RetryConfig with the above `retryRuleBuilder` and return it.
}

Test setup
I wrote a test where a client with above decorators send one request to a server which always fails the requests and populates the response header with some error information. When the client receives the response, I expect the decorator 1's httpResponse.mapHeaders callback (Site A) is invoked and an exception is created and thrown there. Then I expect the client to retry up to 3 times and eventually fail (because the server always fails the request and triggers an exception on the client side).
Observations

Retry kicked in and 3 requests were sent sequentially. All 3 attempts failed that lead to client stub invocation failure. This behavior is expected :)
The order of invocation during each request attempt: Site A --> Site D --> Site B. Note that Site C is never invoked.
In the first 2 request attempts at Site B,  requestLog.responseCause() == null. However, in the 3rd/final request attempt at Site B, requestLog.responseCause() == exception_thrown_at_Site A.

Questions

For observation 2, why does Site C never invoked? Is it a bug or I did something wrong?
For observation 3, is this the expected/correct behavior? Specifically, does Armeria intentionally try to hide the exception from Site B (the ctx.log().whenComplete() callback) until the max retry attempt is reached? If it is intentional, could you share the rationale behind this design?

I read Armeria code RetryingClient to better understand its behavior. Here are my findings (and more questions):
For "question 1"
retryRule.shouldRetry(derivedCtx, responseCause) is called and the responseCause come from here (shown below)
final Throwable responseCause =
    log.isAvailable(RequestLogProperty.RESPONSE_CAUSE) ? log.responseCause() : null;

If responseCause is null, Site C is not invoked because retryRule.shouldRetry consider it as no exception. Interestingly, my debugger shows that in the above code log.isAvailable(RequestLogProperty.RESPONSE_CAUSE) == true BUT log.responseCause() == null. It confuses me.
Is this a bug or my misunderstanding of RequestLog's semantics?
My debugger also shows that exception thrown at Site A is set to response0 (here) as shown below:
final HttpResponse response0 = cause != null ? HttpResponse.ofFailure(cause) : null;

Then response0 is passed to the handleResponse method. So the question is: why doesn't handleResponse pass response0 to retryRule.shouldRetry (and instead it passes responseCause)?
For "question 2"
I tried to understand how RetryingClient triggers the invocation of Site B (the ctx.log().whenComplete() callback). I realized that in handleRetryDecision method (shown below):

abortResponse(originalRes, derivedCtx) triggers the invocation of Site B after request attempt 1 and 2 fails. derivedCtx.log().responseCause() == null. This probably explains why the exception is not presented to Site B. But why is derivedCtx.log().responseCause() == null? Is this behavior expected/intentional?

future.complete(originalRes) triggers the invocation of Site B after the 3rd/final request attempt fails. originalRes contains the exception thrown at Site A. This probably explains why the exception is presented to site B.

    private void handleRetryDecision(@Nullable RetryDecision decision, ClientRequestContext ctx,
                                     ClientRequestContext derivedCtx, HttpRequestDuplicator rootReqDuplicator,
                                     HttpRequest originalReq, HttpResponse returnedRes,
                                     CompletableFuture<HttpResponse> future, HttpResponse originalRes) {
        final Backoff backoff = decision != null ? decision.backoff() : null;
        if (backoff != null) {
            final long millisAfter = useRetryAfter ? getRetryAfterMillis(derivedCtx) : -1;
            final long nextDelay = getNextDelay(ctx, backoff, millisAfter);
            if (nextDelay >= 0) {
                abortResponse(originalRes, derivedCtx);
                scheduleNextRetry(
                        ctx, cause -> handleException(ctx, rootReqDuplicator, future, cause, false),
                        () -> doExecute0(ctx, rootReqDuplicator, originalReq, returnedRes, future),
                        nextDelay);
                return;
            }
        }
        onRetryingComplete(ctx);
        future.complete(originalRes);
        rootReqDuplicator.close();
    }

In my use case, question 1 is more important than question 2. Because it will be a problem for us if the retry decorator cannot access exception thrown at "decorator 1" (Site A).

log.isAvailable(RequestLogProperty.RESPONSE_CAUSE) == true BUT log.responseCause() == null. It confuses me.
Is this a bug or my misunderstanding of RequestLog's semantics?

It's not a bug. Sorry about confusing you.
It returns null if the response was successful.
https://github.com/line/armeria/blob/b1374d772c3c204a6fa26c082bf7722f4410a72e/core/src/main/java/com/linecorp/armeria/common/logging/RequestLog.java#L143
When RequestLogBuilder.endResposne() is called, it sets the availabilities of all properties including RESPONSE_CAUSE.
That's why we always check if log.responseCause() is null or not.
https://github.com/line/armeria/blob/98cfcec6d695f49d9289c6d440c70ba971d3e18d/core/src/main/java/com/linecorp/armeria/common/logging/BuiltInProperty.java#L321-L322
We are also returning null for responseContent() if the content wasn't set when the response is complete.
However, I agree that it's confusing. Let me talk to the team if we can improve it.

why doesn't handleResponse pass response0 to retryRule.shouldRetry (and instead it passes responseCause)?

I think it's because we wanted to handle the cause it in one place. However, I think it's not a good idea and fix to handle the cause directly. Let me make a PR for that.

This probably explains why the exception is not presented to Site B. But why is derivedCtx.log().responseCause() == null? Is this behavior expected/intentional?

Not intentional and we can fix it. 😄

This probably explains why the exception is presented to site B.

That's exactly. 👍

Thanks @minwoox for your clarification.
IIUC you will make 2 fixes/changes with which the behavior of my test setup will be:

When an exception is thrown at Site A will be passed to Site C so that I can make retry decisions based on the exception.

At the end of every failed retry attempt, Site B will always be able to access the exception thrown at Site A by requestLog.responseCause(). For example, if the max retry attempt is 3 and every retry attempt fails (Site A throws an exception), Site B will be able to access the exception 3 times sequentially.

Could you confirm my above understanding is correct? Thanks!

Could you confirm my above understanding is correct?

That is correct. 😄

Could you confirm my above understanding is correct?

That is correct. 😄

This is great! Should we leave this issue open until you merge those 2 fixes/changes and make a new release?

Should we leave this issue open until you merge those 2 fixes/changes and make a new release?

We can close this when #4559 is merged. The next release will be in mid-December. Thanks!

Sorry about that I missed this comment. 😓

Is this fix mostly likely going to be part of the 1.21.0 release?

I think so.

Is it there a chance that this fix can be back ported to 1.16.0?

If you want, I can release a patch version. 😄

If you want, I can release a patch version.

That'd be great! Here is the reason why it would be super helpful for us:
We are on 1.16.0 and my team currently does not have the resource/bandwidth to upgrade to the newest release version of Armeria. So, a patch fixing the issue in 1.16.0 would be the best.
Thanks! @minwoox

1.16.1 has been released. 😉
https://repo.maven.apache.org/maven2/com/linecorp/armeria/armeria-bom/1.16.1/
https://github.com/line/armeria/commits/1cca43dec3b7cb84dc4131e228603dcf3b9caa7c


Chart not resetting each day since 1.1.7

Since 1.1.7 my chart isnt resetting each day

These are my settings (Ive starred out the givtcp code) -
Example configurations are below, you must set up your own sensors
update_every: 30
sensors:

name: sensor.givtcp_*********_load_energy_today_kwh
days: 14
incrementing: True
reset_daily: True
interval: 30
units: kWh
future_periods: 96
database: True

Is this stil an issue?

No, seemed to fix itself a few releases ago


Can somebody modifies this to run on colab?

I don't have an decent video card for training.if some one can modify this to run on colab will be much appreciated.
or if I can run this totally on CPU,without video card support?

https://github.com/Linaqruf/kohya-trainer
You can use this repo to run sd-scripts in colab


Fixed displaying tooltips in the toolbars

#5116

@epwinchell @martinpovolny ^^

@h-kataria please review

@martinpovolny @h-kataria Looks good

Looks good, tested in UI.


fix the import path issue for mlx_lm

the pull request fix the problem when I try to run convert.py and generate.py, it reports the following issue:
Traceback (most recent call last):
File "/Users/zhangfan/Documents/AI/mlx-examples/llms/mlx_lm/generate.py", line 6, in
from .utils import generate_step, load
ImportError: attempted relative import with no known parent package

mlx_lm is meant to be used as a package, so your fix will break that. Check out the docs for more on how it should be used.
Here is a sample command for the CLI:
python -m mlx_lm.generate --model mistralai/Mistral-7B-v0.1 --prompt "hello"

If you want to run it without building first, you should be able to just run that from outside the mlx_lm directory.


OSGi Import Package header change

This is the OSGi "import package" change that adds resolution:=optional option to the manifest file for packages that optionally need to be there at a particular release.

@cla-bot[bot] check


[Bug] [Relay] Error when compiling ONNX with LeakyRelu

[Bug] [Relay] Error when compiling a simple ONNX model
Description
When compiling following model with TVM, it will error.
The model(with ONNX as frontend) with error is as follows, check bug.onnx in bug5.zip.

I think it is because ONNX allows attribute alpha in LeakyRelu with a default value 0.01. Please check LpPool in ONNX: https://github.com/onnx/onnx/blob/master/docs/Operators.md#leakyrelu
Error Log
Traceback (most recent call last):
  File "check.py", line 11, in <module>
    mod, params = relay.frontend.from_onnx(onnx_model, {})
  File "/Users/luyaor/Documents/tvm/python/tvm/relay/frontend/onnx.py", line 2806, in from_onnx
    mod, params = g.from_onnx(graph, opset, freeze_params)
  File "/Users/luyaor/Documents/tvm/python/tvm/relay/frontend/onnx.py", line 2613, in from_onnx
    op = self._convert_operator(op_name, inputs, attr, opset)
  File "/Users/luyaor/Documents/tvm/python/tvm/relay/frontend/onnx.py", line 2721, in _convert_operator
    sym = convert_map[op_name](inputs, attrs, self._params)
  File "/Users/luyaor/Documents/tvm/python/tvm/relay/frontend/common.py", line 603, in __call__
    return get_relay_op(self._new_name)(*inputs, **attrs)
TypeError: leaky_relu() missing 1 required positional argument: 'alpha'

How to reproduce
Environment
Python3, with tvm, onnx
tvm version: c31e338 Wed Dec 9 14:52:58 2020 +0900

Download bug5.zip
Run python check.py.

Fixed in #7259.

Fixed in #7259.


Replace download link with new one in doc

https://github.com/peggyjs/peggy/blob/main/docs/index.html#L53

                minified
                |
                development

the old release has js file with release

so where we link new peggy?

I've only got a minified build handy with the current build process.  Once we're done with #60, hopefully there will be a sourcemap'd version in github, which will be appropriate for development use.

Adding a download attribute wouldn't cause a download because this is being served cross-site.  Re-opening so this can be re-fixed after #60.

This no longer depends on #60.  This could just be a download link to https://peggyjs.org/vendor/peggy/peggy.min.js, but I want to make it clear that people should be caching it from unpkg rather than github.


Feature/add cors to server

Adding cors to the server will mean that the front end and the back end can be run independently of each other for the purpose of development

merge conflicts


Release 0.12.0-m3

Due to a bug in shipyard, the m2 release was squashed and the release is now renamed to m3.
Depends on submariner-io/shipyard#701

The release artifacts are available on https://github.com/submariner-io/releases/releases/tag/v0.12.0-m3, so from a dependency perspective this is done; closing so that dependent PRs can be merged.


Update issue templates

Sample comment. I am a beginner student

Sample comment. I am a beginner student

closing this request

closing this request


Fix the Model Validation

Current default template for Model Validation part fails because of the two errors below:

error_1.
The full error msg is below:
Validation failed : API request to list files under path `` failed with status code 400. Response body: {"error_code":"INVALID_PARAMETER_VALUE","message":"Invalid name 'local_dev.custom_project.custom_project_model'. A workspace registered model name must be a non-empty UTF-8 string and cannot contain forward slashes(/), periods(.), or colons(:). If trying to access models in the Unity Catalog, make sure to install version 2.4.1 or above of the MLflow Python client, then configure the MLflow client to access models in Unity Catalog via mlflow.set_registry_uri('databricks-uc') before accessing models."}
Fix to error_1: add "mlflow.set_registry_uri('databricks-uc')"
error_2:
Fix to error_2:  change to "fare_amount" which is the correct prediction target

Thanks for the changes @qili86 ! Would you mind generating a Stacks repo from your local branch and adding screenshots of the validation workflow working as well?

@arpitjasa-db I generated the stack repo "test_mv" from my local branch, and the model validation part is now working fine without error


Not utilizing original generator/discriminator in combined model

Line 145 in master branch
Line 168-169 in cGAN branch
Line 154 in ac-gan branch
Line 160 in info-gan

Thank you for catching this!
Fixed: 2130ef4397a93354fbf378a302e84c97c1b52dd9

Fixed in all branches I think


ChainSync refactor

Summary of changes
Changes introduced in this pull request:

Handles syncing asynchronously through sync workers on separate tasks

All syncing logic now belongs in the SyncWorker struct, and the ChainSyncer just handles network events and scheduling/ handling sync workers
Separating some of the fields so they are threadsafe across tasks meant there was some auxiliary updates

Updates peer selection for blocksync request to be random (should be made better with #692)
Fixes some bugs with tipset scheduling and other functions

So the loading/ fetching of tipsets from hello protocol is done in separate threads as to not block the ChainSyncer polling or the network event channel will fill and stall (what was happening before). This can be handled better but I want to keep the scope of this PR to a minimum as it's already changing a lot.
Reference issue to close (if applicable)

Closes #690
Other information and links

It seems like while in bootstrap phase, every hello we get, we'll be doing a sync from that Tipset? So if there are 3 Hello messages, they all get scheduled? Or am I misreading?

No, only tipsets that aren't connected get scheduled, which is the point of having multiple workers (so one doesn't get sidetracked with an invalid chain and have to start from scratch again)

No, only tipsets that aren't connected get scheduled, which is the point of having multiple workers (so one doesn't get sidetracked with an invalid chain and have to start from scratch again)

What do you mean by connected here? If i understand, connected means common ancestor?
Lets say we receive a Hello from PeerA. We start doing a reverse header sync. Half way through a reverse header sync, we receive another Hello from PeerB. PeerB will probably have a newer head than PeerA. If we start to do a reverse header sync on PeerB as well, in most cases (assuming no attacks or weird things which I think is the most likely and far more common scenario), we will have a large amount of the same fetches. This is because a reverse header sync can take quite a bit of time if the chain is long, and the blocks dont get persisted into the store until ALL the blocks from head -> 0 are fetched, so WorkerB fetching from PeerB will not know that WorkerA fetching from PeerA is already fetching the same blocks.

No, only tipsets that aren't connected get scheduled, which is the point of having multiple workers (so one doesn't get sidetracked with an invalid chain and have to start from scratch again)

What do you mean by connected here? If i understand, connected means common ancestor?
Lets say we receive a Hello from PeerA. We start doing a reverse header sync. Half way through a reverse header sync, we receive another Hello from PeerB. PeerB will probably have a newer head than PeerA. If we start to do a reverse header sync on PeerB as well, in most cases (assuming no attacks or weird things which I think is the most likely and far more common scenario), we will have a large amount of the same fetches. This is because a reverse header sync can take quite a bit of time if the chain is long, and the blocks dont get persisted into the store until ALL the blocks from head -> 0 are fetched, so WorkerB fetching from PeerB will not know that WorkerA fetching from PeerA is already fetching the same blocks.

It's all based on the hello messages received, they get grouped as they come in, so as long as there isn't a break in between two epochs (probably rare) they will be considered on the same chain. This is determined by checking if either the tipset parent is the other or if they are the same.
This logic existed, but is used more correctly than before (can still be improved on later). This is the point of having those tipset buckets (to track which tipsets are being synced and what to assign another worker to)


License is ridiculous

long post but the gist is that this clause should be removed. At best it's worthless. At worst, it has negative value to contributors.

4. Redistributions of any form whatsoever must retain the following
acknowledgment: 'This product includes software developed by
skadistats (http://www.skadistats.com/).' Web applications and
properties built using the clarity library must additionally include
a visible, legible hypertext link with text "Powered by skadistats"
linking to the URL http://www.skadistats.com on every page containing
data obtained by using this library. Removal of this attribution
shall be granted immediately (within one business day) if
requested by skadistats or its authorized agents.

This clause is incredibly questionable and appears to have been written with no real understanding of either copyright or law. For one thing, it means that the software is not in actuality open-source, because you're implicitly claiming some form of copyright/sublicensing of data. Which is nonsense. That data came from Valve and if you really wanted to fight it you'd probably get slammed for violating the Steam Subscriber Agreement anyways.
"Web applications" isn't defined. "Properties" isn't defined. "Pages" isn't defined. "Skadistats" isn't defined. Is Skadistats incorporated? It surely isn't, because it's never referred to by a legal company name. And who's actually authorized to make those requests? If someone fakes being a partner of skadistats and requests a site that uses the library to remove the attribution within one day, that site is required to remove it if they don't hear back, except they're not penalized either way by either attributing or not attributing skadistats.
And what about providing the software as-is? That stuff is standard, but if you disclaim liability for that then how can the clause that implies (but doesn't say anything further) that skadistats can make a request to users of the library even be enforceable without skadistats actually being liable? Doesn't that make the clause an actual risk to skadistats?
Also, there's an obvious workaround that would allow a site to use clarity with exactly zero attribution whatsoever, assuming they're willing to argue that you have no right to sublicense Valve's copyrighted data anyways, which you don't, which the attribution requirement basically says. That is, that's what someone might do if the penalties weren't completely toothless anyways. And if they weren't, normal users of it would be vulnerable to and exploitable by griefers anyhow.
tl;dr: Penalties: toothless. Protections to you: zero or possibly negative (risky). Open-source: hardly.

So what your saying is you would like to use the library we wrote without attribution?

On Jan 18, 2015, at 2:35 AM, Andrew Toulouse<EMAIL_ADDRESS>wrote:
long post but the gist is that this clause should be removed. At best it's worthless. At worst, it has negative value to contributors.

Redistributions of any form whatsoever must retain the following
acknowledgment: 'This product includes software developed by
skadistats (http://www.skadistats.com/).' Web applications and
properties built using the clarity library must additionally include
a visible, legible hypertext link with text "Powered by skadistats"
linking to the URL http://www.skadistats.com on every page containing
data obtained by using this library. Removal of this attribution
shall be granted immediately (within one business day) if
requested by skadistats or its authorized agents.

This clause is incredibly questionable and appears to have been written with no real understanding of either copyright or law. For one thing, it means that the software is not in actuality open-source, because you're implicitly claiming some form of copyright/sublicensing of data. Which is nonsense. That data came from Valve and if you really wanted to fight it you'd probably get slammed for violating the Steam Subscriber Agreement anyways.
"Web applications" isn't defined. "Properties" isn't defined. "Pages" isn't defined. "Skadistats" isn't defined. Is Skadistats incorporated? It surely isn't, because it's never referred to by a legal company name. And who's actually authorized to make those requests? If someone fakes being a partner of skadistats and requests a site that uses the library to remove the attribution within one day, that site is required to remove it if they don't hear back, except they're not penalized either way by either attributing or not attributing skadistats.
And what about providing the software as-is? That stuff is standard, but if you disclaim liability for that then how can the clause that implies (but doesn't say anything further) that skadistats can make a request to users of the library even be enforceable without skadistats actually being liable? Doesn't that make the clause an actual risk to skadistats?
Also, there's an obvious workaround that would allow a site to use clarity with exactly zero attribution whatsoever, assuming they're willing to argue that you have no right to sublicense Valve's copyrighted data anyways, which you don't, which the attribution requirement basically says. That is, that's what someone might do if the penalties weren't completely toothless anyways. And if they weren't, normal users of it would be vulnerable to and exploitable by griefers anyhow.
tl;dr: Penalties: toothless. Protections to you: zero or possibly negative (risky). Open-source: hardly.
—
Reply to this email directly or view it on GitHub.

No, I'm not saying anyone who want to could anyways and your license would do nothing.  And your license is basically not valid because it claims rights you don't have, because of your fourth clause.

Thank you for the clarification in your stance. I likely mis-interpreted the tone of your initial post. This sounds like something we should discuss further and decide whether it makes sense to alter the license.

Changed the issue title to be less inflammatory

I think we might have found the only lawyer on the Internet, guys.
But seriously, he has a point. That clause is kind of like a piracy warning on a DVD. What we didn't want was to keep it closed source, and what we didn't want moreover was to encourage people to take it without considering that a lot of hard work went into it, for which there is AMPLE precedent in this very scene.
Truth be told you could say the same thing if we had gone GPL instead. What, is Richard Stallman going to descend in his FSF chariot (YOU CANT RUN FROM HEAVEN) and personally fight for Freeasinspeech dota replay parsing in the 9th circuit?
The lawyer has a point though, it's toothless either way. One just looks worse.

On Jan 18, 2015, at 11:30 AM, Andrew Toulouse<EMAIL_ADDRESS>wrote:
No, I'm not saying anyone who want to could anyways and your license would do nothing.  And your license is basically not valid because it claims rights you don't have, because of your fourth clause.

Reply to this email directly or view it on GitHub.

YOU CANT RUN FROM HEAVEN

Damn Zeus pickers :)
On the subject though: I think the clause should be removed too. Let's ask for attribution in the docs. Nice people will do it without hesitation, because they are thankful, and the others would probably not mentioned it even with the clause in the license.


avoid invalid in-place division in CUB-based mean

This bug fix was split out from PR #2903 for easier review. For integer dtypes it is not possible to perform in-place division by a float.

Thanks!

Thanks.
Jenkins, test this please

Jenkins CI test (for commit 4c72d0d521b2797dd9255bf11794ebcde582e98f, target branch master) succeeded!

👍


wrote logic for LCM method

added a method signature for counting number of words in a string
added test file for the above method test/countNoOfWords.test.js

Closes #theRelatedIssueNumber

[x] Running yarn lint does not trigger any linter errors
[x] The test of the method you have fixed is passing
[x] You have written a new skeleton method for someone else to work on!
[x] You have written tests to accompany your skeleton method

@MahikanthNag Thanks for the contribution! Could you please write a new issue for your added method? It would help us out a ton.


Evaluate using additional optimizations like LTO and PGO

Hi!
As I have done many times before, I decided to test the Profile-Guided Optimization (PGO) technique to optimize the application's performance. For reference, results for other projects are available at https://github.com/zamazan4ik/awesome-pgo . Since PGO helped a lot for many other apps, I decided to apply it to the project to see if the performance win can be achieved. Here are my benchmark results.
This information can be interesting for anyone who wants to achieve more performance with the library in their use cases.
Test environment

Fedora 40
Linux kernel 6.10.7
AMD Ryzen 9 5900x
48 Gib RAM
SSD Samsung 980 Pro 2 Tib
Compiler - Rustc 1.79.0
tex-fmt version: main branch on commit f2689ac7e2c713cfb6106220c09a44141770a638
Disabled Turbo boost

Benchmark
For benchmark purposes, I use built-in into the project benchmarks. For PGO optimization I use cargo-pgo tool. For all measurements I used the same command but with different binaries - taskset -c 0 tex_fmt tests/source/* tests/target/*.
taskset -c 0 is used for reducing the OS scheduler's influence on the results. All measurements are done on the same machine, with the same background "noise" (as much as I can guarantee).
Results
I got the following results in hyperfine's format:
hyperfine --warmup 25 --min-runs 100 --prepare "cp -r ../tests/* tests" "taskset -c 0 ./tex_fmt_release tests/source/* tests/target/*" "taskset -c 0 ./tex_fmt_lto tests/source/* tests/target/*" "taskset -c 0 ./tex_fmt_optimized tests/source/* tests/target/*" "taskset -c 0 ./tex_fmt_instrumented tests/source/* tests/target/*"

Benchmark 1: taskset -c 0 ./tex_fmt_release tests/source/* tests/target/*
  Time (mean ± σ):      92.3 ms ±   1.2 ms    [User: 72.6 ms, System: 8.5 ms]
  Range (min … max):    90.6 ms …  98.6 ms    100 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs.

Benchmark 2: taskset -c 0 ./tex_fmt_lto tests/source/* tests/target/*
  Time (mean ± σ):      87.3 ms ±   1.0 ms    [User: 67.5 ms, System: 8.6 ms]
  Range (min … max):    85.5 ms …  91.1 ms    100 runs

Benchmark 3: taskset -c 0 ./tex_fmt_optimized tests/source/* tests/target/*
  Time (mean ± σ):      80.1 ms ±   0.6 ms    [User: 60.2 ms, System: 9.1 ms]
  Range (min … max):    78.3 ms …  81.2 ms    100 runs

Benchmark 4: taskset -c 0 ./tex_fmt_instrumented tests/source/* tests/target/*
  Time (mean ± σ):     133.0 ms ±   1.6 ms    [User: 110.6 ms, System: 9.8 ms]
  Range (min … max):   131.0 ms … 139.4 ms    100 runs

Summary
  taskset -c 0 ./tex_fmt_optimized tests/source/* tests/target/* ran
    1.09 ± 0.01 times faster than taskset -c 0 ./tex_fmt_lto tests/source/* tests/target/*
    1.15 ± 0.02 times faster than taskset -c 0 ./tex_fmt_release tests/source/* tests/target/*
    1.66 ± 0.02 times faster than taskset -c 0 ./tex_fmt_instrumented tests/source/* tests/target/*

where (with binary size information - it's important for some cases too):

tex_fmt_release - default Release profile, 2.6 Mib
tex_fmt_lto - default Release profile + LTO, 2.4 Mib
tex_fmt_optimized - default Release profile + LTO + PGO optimized, 2.4 Mib
tex_fmt_instrumented - default Release profile + LTO + PGO instrumented, 4.5 Mib

According to the results, LTO and PGO measurably improve the application's performance.
Further steps
As a first easy step, I suggest enabling LTO only for the Release builds so as not to sacrifice the developers' experience while working on the project since LTO consumes an additional amount of time to finish the compilation routine. If you think that a regular Release build should not be affected by such a change as well, then I suggest adding an additional release-lto profile where additionally to regular release optimizations LTO also will be added. Such a change simplifies life for maintainers and others interested in the project persons who want to build the most performant version of the application. Using ThinLTO also should help).
Also, Post-Link Optimization (PLO) can be tested after PGO. It can be done by applying tools like LLVM BOLT to tex-fmt.
Thank you.
P.S. It's just an idea, not an actual issue. Possibly, Ideas in GitHub's Discussions is a better place to discuss such proposals.

Thanks for this, it is very interesting. I will try to replicate these results myself and will definitely consider including this in release binaries if it makes a noticeable improvement.

Working on this in the lto-pgo branch, see cfdb6444cf2d7a041b04fe1cfeb96972ddd78df3.

I have implemented this in extra/build.sh and extra/perf.sh -- could you take a look and let me know if it aligns with what you were thinking? I do get some improvement, but not as much as you seem to attain. This may be because I'm not using taskset (it seems to slow down the benchmark), or just a hardware difference.
Benchmark 1: tex-fmt
  Time (mean ± σ):      93.6 ms ±   0.7 ms    [User: 87.1 ms, System: 6.2 ms]
  Range (min … max):    92.6 ms …  96.3 ms    50 runs

Benchmark 1: tex-fmt (no PGO)
  Time (mean ± σ):      97.9 ms ±   1.6 ms    [User: 92.0 ms, System: 5.4 ms]
  Range (min … max):    96.3 ms … 105.3 ms    50 runs

Excuse me for the so late response.
Thank you a lot for implementing it in the scripts! Yep, that's what exactly I was thinking about. I have several small and neat pieces of advice:

https://github.com/WGUNDERWOOD/tex-fmt/blob/lto-pgo/extra/build.sh#L9 - I think it should be enough to run once during the training phase instead of 210 times - the optimization result should be the same. I see that in https://github.com/WGUNDERWOOD/tex-fmt/commit/9942c416eb284f07b69873ee7b0577297983ec69 you increased the runs count - what was the reason for that? No performance wins from PGO with fewer training runs?
https://github.com/WGUNDERWOOD/tex-fmt/blob/lto-pgo/extra/perf.sh#L33 - maybe I missed something but here we have the same binary as for the usual Release build without PGO. Am I blind or here we need to do something more?
Just to recheck - are PGO applied for binaries that are published at GitHub?

Thanks for the response!

I am running the script several times before optimization as I think this is what's recommended in the cargo-pgo README -- it says to run the binary for "at least a minute".
perf.sh#L33 is a comparison test without PGO -- the test with PGO begins at L19.
PGO is not currently applied for GitHub binaries at the moment, though I will include it if consistent performance gains are apparent.

I am running the script several times before optimization as I think this is what's recommended in the cargo-pgo README -- it says to run the binary for "at least a minute".

Oh, I see. No worries - in your case you should be able to ignore it. This recommendation is true for larger applications. For example, we want to optimize some large applications, like a database that internally has a lot of different subsystems. When we are waiting for a minute, it increases the chances that all (or almost all) subsystems will be executed at least once during the workload (like running database benchmarks). tex-fmt is a bit different :)

PGO is not currently applied for GitHub binaries at the moment, though I will include it if consistent performance gains are apparent.

Yep, sounds good

There have been some substantial improvements to the performance of tex-fmt over the last few releases, and I'm no longer seeing any advantages when using PGO. As such, I'm going to close this issue for now. Thank you very much for your help and for discussing this; I am more than happy to reopen the issue in the future if necessary.


Return lastEpisodeTime on /search/byterm (and other search) endpoint(s)

Hello,
In AntennaPod we got this request:

When I search for a podcast I often find podcasts that are old and inactive. It would be awesome to search for podcasts that have at least released a podcast in the last 30 days.

It would be great if the date of the most recent episode was shown in the search results, and that the search results could be sorted by most recent episode date.

The /search/byterm endpoint already provides lastUpdateTime. To fulfil the user's request, it would be helpful if it would also return a lastEpisodeTime. Ideally this would be the the most recent pubDate from all the episodes (items) in the feed, but if not, maybe the value of the first episode (top item) which in most cases would be the same item.

Hmm. You just want a way to limit the search results returned by last publish time. I can probably figure that out.

No, sorry, I don't think our end-user requested to limit the search results. They just want to have, per podcast, one piece of extra information: the release date of the most recent episode.

Oh I see. Yes that’s very doable.

Done!

Oh my. So fast. Thanks a lot!

Going to reopen this because Steven let me know that this naming doesn't match a similar property in another endpoint response.  Going to fix that. Hang tight...


Add Université Centrale

@WassimKa Please provide us with:

the university official website URL, if different from the domain you are submitting
an URL of a page on the official website where an IT-related long-term (>1 year) course is offered by the university
an URL of a page or another proof (.pdf or a screenshot are OK) showing that the university recognizes the domain which you are submitting as an official email domain for the students.

Hi @philipto ,
Here are the requested informations (in French however):
Website: https://www.universitecentrale.net
Software Engineering: https://www.universitecentrale.net/polytech/fr/filiere/16/genie-informatique
Proof of the email domain:

@WassimKa Thank you for the clarification. Pull request merged.


Stackoverflow -> Stack Overflow

To stay true to Stack Overflow's branding, it should be two words :)

Good to know, thx!


Sublime Text support

Please add support for Sublime Text https://www.sublimetext.com/

Someone has already ported it to sublime https://github.com/sainnhe/everforest/wiki

@sainnhe only the dark option is available and the generator that was used does not work anymore..

https://github.com/sainnhe/everforest/blob/95110894cddf4663b871e2ca231e10e196899ed8/doc/everforest.txt#L464-L470

I don't use sublime, if you're not satisfied with that port, you can create one by yourself.

late reply but https://github.com/avelican/everforest-sublime
Converted automatically from https://github.com/sainnhe/everforest-vscode using https://github.com/tobiastimm/code-theme-converter


Allow logging to multiple places.

Created by: nc6
Previous behaviour just picked one at random; no reason for
the limitation.
(Random PR whilst waiting for Mero to rebuild...)

Closing as an obsolete


Add LOG.isDebugEnabled for some debug logical of Coordinator

This may very slightly affect the performance or not.

for issue: https://github.com/apache/incubator-doris/issues/3346


Moved some helpers into OCI* and added helpers

Not sure why statement.go is showing the whole file has changed. :/

@mattn Could you please restart Travis build?


Nitsche solid simulation with simplex

When using a simplex mesh for both the Nitsche solid and the fluid, particles are lost at the very first iteration.
Maybe this has something to do with the mapping. I can provide files for testing that.

@oguevremont I assign this to you as we talked about it, we could work together on that whenever you are ready :)

I'll take a look into it this week.


Add ERB support

Recently started using this gem for a project, but I needed to use ERB tags inside the yaml files and that did not seem to be supported.
Added a conditional to check for the presence of a ".erb" file extension in the yaml_path variable. If present, we load the yaml content through the ERB interpreter first. The fact that this check is in the ext_load_file_recursive class method means that it checks all files up the chain of extends, so it will convert ERB tags in parent yaml files (with an erb file extension) also.

check for yml.erb file extension to process yaml with ERB
add test

@johndavid400 thank you very much for your contributions, just merged it with some more specific additions. A new release will follow within the next few minutes

@johndavid400 thank you very much for your contributions, just merged it with some more specific additions. A new release will follow within the next few minutes

Thanks Matthäus!
That was the fastest PR review I have ever seen! Appreciate your work on
this gem, it was very helpful - thanks!
JD
On Tue, Jan 26, 2021 at 10:13 AM Matthäus J. N. Beyrle <
<EMAIL_ADDRESS>wrote:

@johndavid400 https://github.com/johndavid400 thank you very much for
your contributions, just merged it with some more specific additions. A new
release will follow within the next few minutes
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magynhard/yaml_extend/pull/12#issuecomment-767652397,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA4CMTGXHTCSEA75KISJLDS33S4DANCNFSM4WTUHAXQ
.

Thanks Matthäus!
That was the fastest PR review I have ever seen! Appreciate your work on
this gem, it was very helpful - thanks!
JD
On Tue, Jan 26, 2021 at 10:13 AM Matthäus J. N. Beyrle <
<EMAIL_ADDRESS>wrote:

@johndavid400 https://github.com/johndavid400 thank you very much for
your contributions, just merged it with some more specific additions. A new
release will follow within the next few minutes
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magynhard/yaml_extend/pull/12#issuecomment-767652397,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA4CMTGXHTCSEA75KISJLDS33S4DANCNFSM4WTUHAXQ
.


CASMSMF-7509: Fresh install customization.yaml changes to authorize PCIM GUI

Summary and Scope
Summarize what has changed. Explain why this PR is necessary. What is impacted? Is this a new feature, critical bug fix, etc?
Is this change backwards incompatible, backwards compatible, or a backwards compatible bugfix?
Issues and Related PRs
List and characterize relationship to Jira/Github issues and other pull requests. Be sure to list dependencies.

Resolves - https://jira-pro.it.hpe.com:8443/browse/CASMSMF-7509

Testing
List the environments in which these changes were tested.
Tested on:
Tyr
Hela

John Heemstra mentioned in the ticket @shreni123:
for CSM versions greater than 1.4, this change needs to be made via a single PR in the shasta-cfg repo: https://github.com/Cray-HPE/shasta-cfg
Once that PR merges, we'll "git vendor" it into both the release/1.5 and release/1.6 branches in the csm repo.


User Experience - UX Section

[X] I followed the CONTRIBUTING guidelines.

Add a topic about UX and its procedures. It needs to be discussed yet if the section fits on the guide.

dated pullrequest


have the windows installer add a tap-windows6 device to the system

This makes the Windows installer add a tap-windows6 device to the system:

mirror https://github.com/OpenVPN/tap-windows6 source (GPL)
add tap-windows6 binaries
add_tap_device.bat adds a TAP device to the system, if one is not already found:

rename it outline-tap0 (will make it easy for the client to find)
puts it on the 10.0.85.x subnet

custom_install_steps.nsh invokes the above batch file

Numerous TODOs but this has worked for me on several systems, with OpenVPN and Docker installed.

@trevj, did you mean to merge this PR to master? I see you merged it to trevj-full-vpn.


How to output all commands and options through -- help

How to output all commands and options through --help
Similar to --help full

What do you mean by "output all commands and options"?
What info is not displayed in the "--help" screen that you would like to see?


Added various instructional messages and small fixes

Closes #1552 #1553 #1554 #1556

where's the part about telling people they must add a Title to a post?

where's the part about telling people they must add a Title to a post?

Actually covered in another PR.


risc-v/mpfs: emmcsd: allow switching from SD to eMMC

If the system starts up using the SD-card, and later wants to switch to use the eMMC, it's not going to happen. SD-card will be kept selected within the FPGA making the transition fail.
It's been possible to switch from eMMC to SD, but now the transition is possible for both directions.
Signed-off-by: Eero Nurkkala<EMAIL_ADDRESS>Summary
Switching from SD-card -> eMMC is possible. Fix this issue. At power-on, eMMC is selected. If SD-card is used by a hart, and later eMMC is needed, this doesn't happen.
Impact
MPFS Icicle
Testing
Icicle Polarfire kit, NuttX bootloader at hart0 which loads data from SD card, and starts another NuttX (hart1) that uses eMMC.

Oops, had some extra stuff accidentally with the patch, now ok.


Implement PubID parsing for PLATEAU

Document identifier parsing is currently implemented in https://github.com/relaton/relaton-plateau
Some identifiers examples:

PLATEAU Handbook #00 第1.0版
PLATEAU Handbook #09 第3.0版
PLATEAU Technical Report #00

@ronaldtse would you like to add anything?

Look at the Relaton.org page on Plateau, gives you all you need 👍

Maybe you can use GPT to even write this.

@ronaldtse @andrew2net there are identifiers I'm not sure how correctly to parse:

PLATEAU Handbook #03-1 第1.0版 - is it correct that "-1" here is annex?
PLATEAU Technical Report #46_1
PLATEAU Technical Report #46_2 - what is "_1" and "_2" here?
PLATEAU Handbook #11 第1.0版（民間活用編）
PLATEAU Handbook #11 第1.0版（公共活用編）

What to do with （民間活用編） and （公共活用編）. The literal meaning through Google Translate: edition for "private" or "public" use. But only two identifiers have these, others don't. Does it mean by default all documents have edition for public use? （公共活用編）

When can we get this done? This has been forever...

PLATEAU Handbook #03-1 第1.0版 - is it correct that "-1" here is annex?

Yes. - means Annex if it is a Handbook. This is the only Handbook Annex.

PLATEAU Technical Report #46_1
PLATEAU Technical Report #46_2 - what is "_1" and "_2" here?

See: https://www.mlit.go.jp/plateau/file/libraries/doc/plateau_tech_doc_0046_1_ver01.pdf
Actually these should be:

PLATEAU Technical Report #46-1
PLATEAU Technical Report #46-2

These are "parts".

PLATEAU Handbook #11 第1.0版（民間活用編）
PLATEAU Handbook #11 第1.0版（公共活用編）

What to do with （民間活用編） and （公共活用編）.

Let's treat this as "part distinguishing description". i.e. consider the content inside parentheses like 民間活用編 as part numbers.


24.0.7 image tags: No matching manifest

It seems the 24.0.7 images were not properly pushed to Docker Hub. The tags exist, but no image layers: https://hub.docker.com/_/docker/tags?page=1&name=24.0.7
$ docker pull docker:24.0.7-dind
24.0.7-dind: Pulling from library/docker
no matching manifest for linux/amd64 in the manifest list entries

This results in failures when using automated tag updates e.g. by renovate.

#454 was opened while I wrote this issue. Closing in favor of it.


Add direct transfers and instant withdrawals to CLI/SDK

Currently I don't believe this functionality is available in the SDK and, if not, it would be beneficial to add it.

A bit more detail:  The CLI and underlying SDK implements on-chain Deposits, Transfers and Withdrawals.  However, it's possible to directly send a Transfer or Withdraw (but not a Deposit) to a Proposer, to save the cost of posting it on-chain.  This functionality is shown in the tests.  At present the CLI and SDK do not implement this functionality and it needs adding.
Likewise, it's possible to instantly withdraw funds without waiting for the 1 week finalisation period, if one pays a fee to a Challenger who is providing this service. This functionality is also in another test but not yet implemented in the CLI/SDK.


Add Node 10 & 12 to AppVeyor & Travis config

Coverage remained the same at 96.5% when pulling a46384e7b79805b6dbdc9ee5b72081c8cbd801fc on chasenlehara-patch-1 into f81d44d3413accf5232455cb60803ee75c4f3502 on master.


Correctly unschedule all sources for a multi-source config

What does this PR do?
Multiple LogSources can correspond to a single ServiceID, so store the
sources in a slice.
Motivation
Bug discovered with
docker run --rm \
  -v /tmp/share:/tmp/share  \
  -l com.datadoghq.ad.logs='[{"type":"file","path":"/tmp/share/test.log"},{"type":"docker"}]' \
  mingrammer/flog /bin/flog -f apache_error -o /tmp/share/test.log -d 1 -t log

where the file source remains even after the container exits.
This was a regression in 7.36.
Additional Notes
This still has an implicit assumption, but this most closely adheres to the implementation in 7.35.
Perhaps a better approach would be to index sources by the digest of the config from which they were generated?
Possible Drawbacks / Trade-offs

Describe how to test/QA your changes
See AML-174 for details.  Basically, run the agent in a docker-standalone environment and start a container as described above, then stop the container.  Observe in agent status that all of the log sources are gone.
Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the config template has been updated.

TBD whether this should get backported to 7.36.

I think there's another assumption at play here: that sources added by things other than schedulers will also get removed by the scheduler.  In particular, the kubernetes and docker launchers add Type="file" sources to handle logging containers from files, and those sources would have been removed by the scheduler in 7.35.  In 7.36 and later (including with this PR), those sources would not be removed as they are not in the scheduler's private list of things it has scheduled.

I've overhauled the PR to take a different approach: re-implementing the behavior in 7.35.0.  THe PR description is also updated.