_TZ3000_wkai4ga5 actions interpreted twice and long press on buttons not supported

Describe the bug - //I've seen other issues posted but solutions aren't OK or users didn't give you the right information, I've decided to open a new one from scratch with (I hope) all necessary information.

When we use 1 click or  2 clicks (with WHEN) the action is done twice (same for all 4 buttons)
The "Long press" action isn't listed

To Reproduce
Steps to reproduce the behavior:
I've purshased new ones, I did a simple Alternate on click and the lights are going ON and OFF again directly.
I created an advanced flow with variables to increment when I click or double click and each time an action is done once, the variable increments twice.
Expected behavior

Only one action
Add "Long Click" on the actions list

App and Homey version

Homey Pro (Early 2019)
10.0.9
Tuya Zigbee App v0.2.26 dev

Additional context

Please find the Interview of the device :

"ids": {
"modelId": "TS0044",
"manufacturerName": "_TZ3000_wkai4ga5"
},
"endpoints": {
"endpointDescriptors": [
{
"endpointId": 1,
"applicationProfileId": 260,
"applicationDeviceId": 0,
"applicationDeviceVersion": 0,
"_reserved1": 1,
"inputClusters": [
0,
1,
6
],
"outputClusters": [
25,
10
]
},
{
"endpointId": 2,
"applicationProfileId": 260,
"applicationDeviceId": 0,
"applicationDeviceVersion": 0,
"_reserved1": 1,
"inputClusters": [
1,
6
],
"outputClusters": []
},
{
"endpointId": 3,
"applicationProfileId": 260,
"applicationDeviceId": 0,
"applicationDeviceVersion": 0,
"_reserved1": 1,
"inputClusters": [
1,
6
],
"outputClusters": []
},
{
"endpointId": 4,
"applicationProfileId": 260,
"applicationDeviceId": 0,
"applicationDeviceVersion": 0,
"_reserved1": 1,
"inputClusters": [
1,
6
],
"outputClusters": []
}
],
"endpoints": {
"1": {
"clusters": {
"basic": {},
"powerConfiguration": {},
"onOff": {}
},
"bindings": {
"ota": {
"attributes": [],
"commandsGenerated": "UNSUP_GENERAL_COMMAND",
"commandsReceived": "UNSUP_GENERAL_COMMAND"
},
"time": {
"attributes": [],
"commandsGenerated": "UNSUP_GENERAL_COMMAND",
"commandsReceived": "UNSUP_GENERAL_COMMAND"
}
}
},
"2": {
"clusters": {
"powerConfiguration": {
"attributes": [
{
"acl": [
"readable",
"reportable"
],
"id": 0,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 32,
"name": "batteryVoltage",
"value": 30,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 33,
"name": "batteryPercentageRemaining",
"value": 200,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
},
{
"acl": [
"readable",
"reportable"
],
"id": 65533,
"name": "clusterRevision",
"value": 1,
"reportingConfiguration": {
"status": "NOT_FOUND",
"direction": "reported"
}
}
]
},
"onOff": {}
},
"bindings": {}
},
"3": {
"clusters": {
"powerConfiguration": {},
"onOff": {}
},
"bindings": {}
},
"4": {
"clusters": {
"powerConfiguration": {},
"onOff": {}
},
"bindings": {}
}
}
}

is this hard to fix Johan? Can I somehow help reviewing the according code to see where a double trigger could come from?

Hi,
I have the devices, if you need to perform any test, please let me know.

Hi @RBouroubi and @roxart.
Can you please be very specific about what does not work and what is missing?
This is what the driver currently support:
Upper Left Button: 1 Click
Upper Left Button: 2 Clicks
Upper Right Button: 1 Click
Upper Right Button: 2 Clicks
Lower Left Button: 1 Click
Lower Left Button: 2 Clicks
Lower Right Button: 1 Click
Lower Right Button: 2 Clicks
Are these working? If not, what is wrong..
Is "longpress" missing?
If so please use the buttons in all ways and then send me a diagnostic report from the app.

Hi Johan,
The long press is missing.
When you click once, two signals are coming to Homey.
For example, if I create a workflow to alternate ON and OFF for a light, it
doesn't alternate because it goes on and off very quickly.
I put a variable to count how many times the switch sends the command, and
it's always twice.
I don't know how to send a diagnostic report, I've attached in the first
post the discovery JSON.
Le lun. 7 oct. 2024, 19:48, Johan Bendz @.***> a écrit :

Hi @RBouroubi https://github.com/RBouroubi and @roxart
https://github.com/roxart.
Can you please be very specific about what does not work and what is
missing?
This is what the driver currently support:
Upper Left Button: 1 Click
Upper Left Button: 2 Clicks
Upper Right Button: 1 Click
Upper Right Button: 2 Clicks
Lower Left Button: 1 Click
Lower Left Button: 2 Clicks
Lower Right Button: 1 Click
Lower Right Button: 2 Clicks
Are these working? If not, what is wrong..
Is "longpress" missing?
If so please use the buttons in all ways and then send me a diagnostic
report from the app.
—
Reply to this email directly, view it on GitHub
https://github.com/JohanBendz/com.tuya.zigbee/issues/864#issuecomment-2397535786,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BILXORJWFLMVONUGJA7ZVDLZ2LCPDAVCNFSM6AAAAABHX2WG62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJXGUZTKNZYGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yes Johan it works - but every thing triggers 2 times - so the example above gives me 2 push notifications
and there is no longpress correct
this is the report right after I clicked with that flow on: 7a38ea4c-8d33-44c2-aa79-fbf96f57fb0d

also I want to add: the longpress is actually important for me, as I want to use some of these buttons to control blinds and longpress is to go up and stop on release
what is the problem, that those do not work?

@roxart An update to the driver is on it's way, please try and report back. If anything is not working please send a diagnostic report.

In the current test version of the app (v0.2.68) the 4 button switch does not work anymore. I understand (based on your post in the Homey Community Forum) that you are working in a new test version. Thanks in advance for all your efforts. Is there any information I can provide to help you further identify / test the issue?
I did note something else that might be relevant:

The issues with a button press registered twice also relates to the 2 scene (and possible other) versions of this device. In my case, I have the MOES 2 button version: Product ID TS0042, Manufacturer ID: _TZ3000_dfgbtub0.
However, this 2 scene MOES device uses the same device ID as the equivalent device from Marmitek. If I pair this switch to the Marmitek app (which supports 1 and 2 button versions of the switch), it works flawlessly: presses are registered only once (and both the single, double, and long press options are available).

If I am not mistaken, you are also involved / contributed to the Marmitek app. Maybe the code of that apps might help in pintointing the issue.

Hi @SunBeech, thanks for this information.. always hard to code for device i don't have so I rely on community testing :)
OK, good info.. and what is you id for the 4 button version?
_TZ3000_wkai4ga5, _TZ3000_uaa99arv, _TZ3000_jcspr0tp
Yeah, I code the Marmitek app too.. hmm.. just had a look at that code and darn.. you are right... I made a misstake in the Tuya code. I just updated the 2 button code in the tuya app, try it out and let me know if this works better.

for me it still triggers twice on the 4 gang @JohanBendz

Hi @JohanBendz, regarding the 4 button version. The ID is: _TZ3000_wkai4ga5.
In the new test version (v0.2.71) I can confirm @roxart's observation: it triggers twice.
I tested all combinations of button presses: it always triggers twice, except for one case, in which it does not trigger at all (lower right long press)
1 click
Upper Left: triggers twice
Upper Right: triggers twice
Lower Left: triggers twice
Lower Right: triggers twice
2 clicks
Upper Left: triggers twice
Upper Right: triggers twice
Lower Left: triggers twice
Lower Right: triggers twice
Long press
Upper Left: triggers twice
Upper Right: triggers twice
Lower Left: triggers twice
Lower Right: NO TRIGGER
I'll get back to you on the 2 button device.

Hi @JohanBendz, I checked the 2 button switch(_TZ3000_dfgbtub0), which works with both the Tuya Zigbee app and the Marmitek app.
I first checked that the device is still working as expected on the current version of the Marmitek app (v1.1.0, as that was also recently updated): all combinations of button presses work as expected and trigger only once.
I then removed the device from my Homey and added it back again using the Tuya Zigbee app (v0.2.71). Also now the buttons work as expected: a single, double or long press on any of the buttons result in a single trigger only.
The only minor thing I noted relates to the names of the button actions in the WHEN card:

In says 'right button was clicked 2 times' while in all other names the word 'pressed' is used instead of 'clicked'.
The 4 button version uses different namings, though they are consistent :-).

Also now the buttons work as expected: a single, double or long press on any of the buttons result in a single trigger only.

Sweet! Thanks for verifying @SunBeech 👍
Ahhh.. naming standard.. I'll make it consistent.. if only in the app 😄
@roxart And now I can fix the other buttons.. an update is coming.

Hi @JohanBendz ,
I'm struggling to install this version, when I make the install i have messages on the validation step.
But As I installed only once fe weeks ago, maybe I'm doing something wrong
homey app install
✓ Pre-processing app...
Added FlowCard the-breath-alarm-turned-off for type triggers
Added FlowCard the-breath-alarm-turned-on for type triggers
Added FlowCard the-large-presence-alarm-turned-off for type triggers
Added FlowCard the-large-presence-alarm-turned-on for type triggers
Added FlowCard the-small-presence-alarm-turned-off for type triggers
Added FlowCard the-small-presence-alarm-turned-on for type triggers
Added FlowCard the-breath-alarm-is-onoff for type conditions
Added FlowCard the-large-presence-alarm-is-onoff for type conditions
Added FlowCard the-small-presence-alarm-is-onoff for type conditions
Added FlowCard resetEnergyMeter for type actions
Added FlowCard start_effect for type actions
Added Driver christmas_lights
Added FlowCard move_open for type actions
Added FlowCard move_close for type actions
Added Driver curtain_module
Added Driver curtain_motor
Added Driver dimmer_1_gang
Added Driver dimmer_1_gang_tuya
Added Driver dimmer_2_gang
Added Driver dimmer_2_gang_tuya
Added Driver doorwindowsensor
Added Driver doorwindowsensor_2
Added Driver doorwindowsensor_3
Added Driver double_power_point
Added Driver flood_sensor
Added FlowCard handheld_remote_4_buttons for type triggers
Added Driver handheld_remote_4_buttons
Added Driver lcdtemphumidluxsensor
Added Driver lcdtemphumidsensor
Added Driver lcdtemphumidsensor_2
Added Driver lcdtemphumidsensor_3
Added Driver motion_sensor
Added Driver motion_sensor_2
Added Driver outdoor_2_socket
Added Driver outdoor_plug
Added Driver pir_sensor_2
Added Driver pirsensor
Added Driver plug
Added Driver radar_sensor
Added Driver radar_sensor_2
Added Driver relay_board_4_channel
Added Driver rgb_bulb_E14
Added Driver rgb_bulb_E27
Added Driver rgb_led_light_bar
Added Driver rgb_led_strip
Added Driver rgb_led_strip_controller
Added Driver rgb_mood_light
Added Driver rgb_spot_GU10
Added Driver rgb_spot_GardenLight
Added FlowCard alarm_siren for type triggers
Added FlowCard alarm_state for type actions
Added FlowCard alarm_duration for type actions
Added FlowCard siren_volume for type actions
Added FlowCard alarm_tune for type actions
Added Driver sirentemphumidsensor
Added Driver slim_motion_sensor
Added Driver smart_door_window_sensor
Added Driver smart_garden_irrigation_control
Added Driver smart_motion_sensor
Added FlowCard smart_remote_1_button for type triggers
Added Driver smart_remote_1_button
Added FlowCard smart_remote_1_button_2 for type triggers
Added Driver smart_remote_1_button_2
Added FlowCard smart_remote_4_buttons for type triggers
Added Driver smart_remote_4_buttons
Added Driver smart_switch
Added Driver smart_water_timer
Added Driver smartplug
Added Driver smartplug_2_socket
Added Driver smoke_sensor
Added Driver smoke_sensor2
Added Driver socket_power_strip
Added Driver socket_power_strip_four
Added Driver socket_power_strip_four_three
Added Driver socket_power_strip_four_two
Added Driver soilsensor
Added Driver switch_1_gang
Added Driver switch_2_gang
Added Driver switch_2_gang_metering
Added Driver switch_3_gang
Added Driver temphumidsensor
Added Driver temphumidsensor2
Added Driver temphumidsensor3
Added FlowCard window_open_status_get for type conditions
Added FlowCard window_open_status_set for type actions
Added Driver thermostatic_radiator_valve
Added Driver tunable_bulb_E14
Added Driver tunable_bulb_E27
Added Driver tunable_spot_GU10
Added Driver valvecontroller
Added Driver wall_curtain_switch
Added Driver wall_dimmer_tuya
Added FlowCard wall_remote_1_gang_buttons for type triggers
Added Driver wall_remote_1_gang
Added FlowCard wall_remote_2_gang_buttons for type triggers
Added Driver wall_remote_2_gang
Added FlowCard wall_remote_3_gang_buttons for type triggers
Added Driver wall_remote_3_gang
Added FlowCard wall_remote_4_gang_buttons for type triggers
Added Driver wall_remote_4_gang
Added FlowCard wall_remote_4_gang_buttons_2 for type triggers
Added Driver wall_remote_4_gang_2
Added FlowCard wall_remote_4_gang_buttons_3 for type triggers
Added Driver wall_remote_4_gang_3
Added Driver wall_switch_1_gang
Added Driver wall_switch_1_gang_tuya
Added Driver wall_switch_2_gang
Added Driver wall_switch_3_gang
Added Driver wall_switch_4_gang
Added Driver wall_thermostat
Added Driver water_detector
Added Driver water_leak_sensor_tuya
Added Driver zigbee_repeater
Added Capability alarm_breathe_presence
Added Capability alarm_large_presence
Added Capability alarm_siren
Added Capability alarm_small_presence
Added Capability away_mode
Added Capability child_lock
Added Capability last_watering_time
Added Capability lidl_xmas_mode
Added Capability measure_water_flow
Added Capability meter_valve_state
Added Capability remaining_watering_time
Added Capability shutdown_timer
Added Capability soil_moisture
Added Capability target_distance
Added Capability temp_calibration
Added Capability temperature_unit
Added Capability thermostat_preset
Added Capability valve_state_auto_shutdown
Added Capability window_open
✓ Validating app...
× App did not validate against level debug:
× Error: manifest.drivers['curtain_module'].settings[0].type should be equal to one of the allowed values ["text","password","textarea","label"]
manifest.drivers['curtain_module'].settings[0] should have required property 'id'
manifest.drivers['curtain_module'].settings[0].type should be equal to one of the allowed values ["number","slider"]
manifest.drivers['curtain_module'].settings[0] should have required property 'id'
manifest.drivers['curtain_module'].settings[0].type should be equal to one of the allowed values ["radio","dropdown"]
manifest.drivers['curtain_module'].settings[0] should have required property 'id'
manifest.drivers['curtain_module'].settings[0] should have required property 'values'
manifest.drivers['curtain_module'].settings[0].type should be equal to one of the allowed values ["checkbox"]
manifest.drivers['curtain_module'].settings[0] should have required property 'id'
manifest.drivers['curtain_module'].settings[0].children[1].type should be equal to one of the allowed values ["text","password","textarea","label"]
manifest.drivers['curtain_module'].settings[0].children[1].step should be number
manifest.drivers['curtain_module'].settings[0].children[1].type should be equal to one of the allowed values ["radio","dropdown"]
manifest.drivers['curtain_module'].settings[0].children[1] should have required property 'values'
manifest.drivers['curtain_module'].settings[0].children[1].type should be equal to one of the allowed values ["checkbox"]
manifest.drivers['curtain_module'].settings[0].children[1].type should be equal to one of the allowed values ["group"]
manifest.drivers['curtain_module'].settings[0].children[1] should have required property 'children'
manifest.drivers['curtain_module'].settings[0].children[1] matched no available schemas, see previous errors
manifest.drivers['curtain_module'].settings[0] matched no available schemas, see previous errors
at App._validate (C:\Users\ameno\AppData\Roaming\npm\node_modules\homey\lib\App.js:132:13)
at async App.install (C:\Users\ameno\AppData\Roaming\npm\node_modules\homey\lib\App.js:802:19)
at async exports.handler (C:\Users\ameno\AppData\Roaming\npm\node_modules\homey\bin\cmds\app\install.js:25:5)

@RBouroubi Try updating Homey CLI. If this is still an issue please create a separate issue.

just installed the new version now my 4 gang does not react at all:
68841fc3-64b9-4c4d-aef6-199fcb634591
started top left 1 click 2 click longpress
top right
bot left
bot right

Hi @JohanBendz ,
I've updated my tools, now I could install.
I have now v0.2.72, and the buttons doesn't react at all, no functions.

Oh.. my bad,, now fixed. Try again @roxart @RBouroubi

HI @JohanBendz ,
Seems fine now, I'll do complete tests and get back to you, but feels much better.

Hi @JohanBendz, I also checked my 4 scene switch and all combinations are working now with a single trigger. Thanks a lot for your efforts!

Great to hear @roxart and @SunBeech.
Closing this issue. If you have problems with other devices please start a new issue for that problem.

sorry to bother in here - seems to work but I have to additional questions:
how long is the press time for longpress? seems very long and is it adjustable?
2nd is it possible to add "longpress release" card
this to be able to use buttons to do  blinds up and down :)
also for the lora tap 6 btw ;)

Hi @roxart, The long press is 5 seconds. That is the time after which the LED indicator light on the button switches off. Als the manual of my MOES device specifies 5 seconds. If you hold it too long (more than 10 seconds), and depending on the button, you enter the pairing mode.

ok lets keep this out of here then - and discuss in the forum

@JohanBendz: issue #793 seems to be the same (also for the same device ID). I have been using the work-around mentioned in that issue, but it is no longer necessary as you solved the issue today. I assume that one can also be closed? One additional item of your to do list 😊.


Update intallation configs

Description
Multiple changes:

Scale to 24 nodes rather than 27
Use the kube-burner OCP wrapper to run node-density and variants
Add cluster-density-v2
Update instance/volumes sizes in some configs
Disable workload nodes on control-plane bechmarks
Remove empty aws_profile, aws_access_key_id and aws_secret_access_key variables. We don't need to specify them, as they are fetched from vault
Disable non-aws cloud platforms. They are actually commented
Standarize benchmark and installation config files naming. and update manifest.yaml accordingly.

Running playground if you wan't to take a look
Signed-off-by: Raul Sevilla<EMAIL_ADDRESS>

Hi @rsevilla87  👋
Was looking at the failed DAG Unit Tests. Can you update the   assert hits
from this file tests/openshift_nightlies/util/test_manifest.py

Before toggling off workload node entirely, we should resolve https://github.com/cloud-bulldozer/airflow-kubernetes/issues/303


Add arabic dialects

Data loading script and dataset card for Dialectal Arabic Resources dataset.
Fixed git issues from PR  #976

merging since the CI is fixed on master


load_qa_chain   _   RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cuda:0 and cpu!

pipline issue

it was pipline issue

hi, I also encounter this error, could you please tell me how you deal with this error, thx

it was pipline issue

How did you handle it ??
pipe=pipeline("text-generation",
                model=model,
                tokenizer=tokenizer,
                torch_dtype=torch.bfloat16,
                device_map='auto',
                do_sample = True,
                temperature=0.7,
                top_p = 0.92,
                exponential_decay_length_penalty = (512, 1.03),
                eos_token_id = tokenizer.eos_token_id,
                max_new_tokens=512,
                min_new_tokens=-1,
                top_k=30
                )

  hf_pipe=HuggingFacePipeline(pipeline=pipe, model_kwargs={"device": "cuda"})
  prompt = PromptTemplate(input_variables=['context', 'question'], template=template)
  qa_chain = load_qa_chain(llm=hf_pipe, chain_type="stuff", prompt=prompt, verbose=True)

In my case, I use like this.


New Release ??

Last release (1.3.1) is one years old (7 Mar 2019).
Any plan to do a new one ?
Many commit since the last one.
*** Release early, release often ***

Yes, good point, I need to find a bit of time to look back into how to do it 😬

Done! Thanks.


Tree not restored when re-opening Opera

Organizing tabs into trees per drag'n'drop would be great, too. Cheers

Having the same problem here. Very annoying to have to regroup all my tabs each time I open Opera.


Update cats-effect to 3.2.7

Updates org.typelevel:cats-effect from 3.1.1 to 3.2.7.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel", artifactId = "cats-effect" } ]

labels: library-update, semver-minor

Superseded by #302.


feat(protocol): introduce breaking changes for gas optimization

The objective of this change is to optimize the gas cost of the proposeBlock, proveBlock, and verifyBlock functions. On mainnet, even small reductions in gas usage can lead to significant Ether savings over time.
Changes
proposeBlock

Block proposer must be the same as the block prover. Custom contracts can handle proposer-prover settlements, as seen in the ProverSet contract. This removes the proposer-prover assignment hook from the protocol.
Moved livenessBond from storage to block metadata as it is static per block. Added a boolean state variable to mark if the livenessBond is returned.

These changes reduce the number of storage writes in proposeBlock from three to two.
proveBlock

Defined a block segment as 16 consecutive blocks. For the first 15 blocks in a segment, stateRoot is forced to be zero, skipping its verification and storage writes. The 16th block writes stateRoot to storage. This change saves 15/16 of storage writes and reads per block.
The best segment size is yet to be determined. With a 30-second interval between blocks, synchronizing the L2 state root to L1 every 8 minutes (16 blocks) seems reasonable, larger values could delay synchronization.

verifyBlock

Due to changes in proveBlock, stateRoot is synchronized only every 16 blocks. For the first 15 blocks in a segment, stateRoot is not read as it is zero.
Changed the odds of attempting to verify blocks. Now, proposeBlock transactions for blocks 0 and 8 and proveBlock transactions for blocks 4 and 12 trigger verification attempts. Each verification attempt can verify up to 16 blocks across segment boundaries.

This change makes verification attempts more efficient, as only the last block's verifying transition ID is written to storage, instead of writing for each verified block.
Early Feedback
Before diving into fixing the implementation bugs in this PR, I would appreciate your feedback on these changes. The value of gas reduction is significant, as every sstore and sload operation translates to real dollar savings.
TODOs

[ ] Fixing existing test failures
[ ] Add more tests for protocol fork
[ ] Figure out how the client can handle this breaking change

Block proposer must be the same as the block prover. Custom contracts can handle proposer-prover settlements, as seen in the ProverSet contract. This removes the proposer-prover assignment hook from the protocol.

Taiko Simplified also does this: https://github.com/Brechtpd/taiko-mono/blob/7516eab250e111d80d75d5621c2d59ed2e1bde0f/packages/protocol/contracts/L1/actors/ProverPayment.sol. And many more simplifications that make things simpler (and save gas). And I think Taiko Simplified currently doesn't even go far enough for certain things, more things to be done!

The value of gas reduction is significant, as every sstore and sload operation translates to real dollar savings.

That's also why I'm always advocating doing as little as possible onchain! Keeps things simple (fewer chance of bugs) and either is already efficient by not doing anything or makes it easier to optimize when necessary. I did not feel that was the direction chosen with the current smart contract implementations, which is one of the reasons I made Taiko Simplified.

In short: I feel it very risky.
It is nice that we want to remove some extra complexity and lowering the gas consumption, but - tho it could have been done before launching mainnet, i remember kind of these discussions back in the day about Assigment Hooks necessity - we need to ask some one important questions: what can we gain and what can we lose ?
We can gain:

some $$$, which I agree is not insignificant, but only in case if we can pull it off with a technically properly executed fork, that does not cause any hiccups
We can lose:
trust if we dont execute it properly, without major fuck ups

The fact that mainnet already diverged from Hekla a bit (so not 100% equivalency) would also require to maintain 2 separate branches for these upgrades, one for Hekla one for mainnet and not only on protocol level but possibly in the client makes it even more risky.
So more pairs of eyes, maybe an extra audit could be necessary (to stamp it with a "safe" upgrade), which would increase the manpower and possibly slow down the process.
I'd leave these kind of breaking changes to BBR honestly.

Block proposer must be the same as the block prover. Custom contracts can handle proposer-prover settlements, as seen in the ProverSet contract. This removes the proposer-prover assignment hook from the protocol.

Taiko Simplified also does this: https://github.com/Brechtpd/taiko-mono/blob/7516eab250e111d80d75d5621c2d59ed2e1bde0f/packages/protocol/contracts/L1/actors/ProverPayment.sol. And many more simplifications that make things simpler (and save gas). And I think Taiko Simplified currently doesn't even go far enough for certain things, more things to be done!

The value of gas reduction is significant, as every sstore and sload operation translates to real dollar savings.

That's also why I'm always advocating doing as little as possible onchain! Keeps things simple (fewer chance of bugs) and either is already efficient by not doing anything or makes it easier to optimize when necessary. I did not feel that was the direction chosen with the current smart contract implementations, which is one of the reasons I made Taiko Simplified.

Every design has different assumptions and objectives, such as if proposing and proving blocks shall be permissionless or permissioned. I hope to see BBR can achieve simplification AND permissionless at the same time.

In short: I feel it very risky.
It is nice that we want to remove some extra complexity and lowering the gas consumption, but - tho it could have been done before launching mainnet, i remember kind of these discussions back in the day about Assigment Hooks necessity - we need to ask the most important question: what can we gain and what can we lose ?
We can gain:

some $$$, which I agree is not insignificant, but only in case if we can pull it off with a technically properly executed fork, that does not cause any hiccups

We can lose:

trust if we dont execute it properly, without major fuck ups

The fact that mainnet already diverged from Hekla a bit (so not 100% equivalency) would also require to maintain 2 separate branches for these upgrades, one for Hekla one for mainnet and not only on protocol level but possibly in the client makes it even more risky.
So more pairs of eyes, maybe an extra audit could be necessary (to stamp it with a "safe" upgrade), which would increase the manpower and possibly slow down the process.
I'd leave these kind of breaking changes to BBR honestly.

I agree this PR is risky, we definitely need to add more unit tests and then use private devnet to ensure the fork is thoroughly tested before rolling it out to Hekla and testnet (BTW, hekla has been upgraded to the latest code and is using the same code as the mainnet).
I'm also considering a followup one week additional audit, I've talked about it with OZ last night. But this shall be started only when the code is well tested already.

Damn, accidentally merged!


performance result

Hi, thanks for your contributions. when I run MNER task, i.e., twitter17, the final result is a little different from the paper. I finally get f1 86.54 by running four times but it should be 87.49. Does the torch version or other factors influence the final results?
My env is Tsela K40, Cuda 10.1 Torch 1.7.0

Different environments may have different best hyperparameters. Maybe you can tune the learning rate and batch size. (learning rate is recommended to be between 1e-5 and 5e-5 and batch size is recommended to be between 8 and 32)


Questions about information API URL

Hello there,
Thanks a lot for this repository, it's definitely useful, especially for the port forwarding part.
I have one simple to answer question regarding the API url https://serverlist.piaservers.net/vpninfo/servers/ because I need to support both v3 and v4 PIA servers, ideally (for this project).
I noticed you can access it through https://serverlist.piaservers.net/vpninfo/servers/v4 and https://serverlist.piaservers.net/vpninfo/servers/v3.

Is the v4  giving the nextgen v4 servers information and v3 the older servers?
The ports from the groups don't match what you have in your openvpn zip files (such as https://www.privateinternetaccess.com/openvpn/openvpn-ip-nextgen.zip, is this expected? Will, for example port 1198 (UDP normal encryption), work on them still?
I noticed the hostnames have the domain privacy.network even for v3 servers, can we now safely assume all hostnames changed to *.privacy.network for the older v3 servers too?

Thank you in advance!

Is the v4  giving the nextgen v4 servers information and v3 the older servers?

Both v3 and v4 give NextGen Servers. v3 does not have meta tags. We recently introduced meta tags for added functionality.
When using v4, you will get a list of meta tags which you can use to get the new authentication token, which provides faster authentication. Here is an example on how to get the the token. For OpenVPN, put half of the token in the username and the other half in the password. All this will be exemplified when we finish the OpenVPN scripts.

The ports from the groups don't match what you have in your openvpn zip files (such as https://www.privateinternetaccess.com/openvpn/openvpn-ip-nextgen.zip, is this expected? Will, for example port 1198 (UDP normal encryption), work on them still?

The NextGen tutorial for OpenVPN from the website works, yes. I am thinking about how to add scripts for OpenVPN for this repo and also keep the user-friendly way this works for WireGuard.
The ports on the website are dedicated for native clients, however the serverlist gives the ports available for the official PIA applications. For native connections, please use the tutorial on the website till we finish this project with examples for OpenVPN.

I noticed the hostnames have the domain privacy.network even for v3 servers, can we now safely assume all hostnames changed to *.privacy.network for the older v3 servers too?

v3 is the version of the server list, not the version of the servers. privacy.network is the domain for NextGen and it is there just in case people really need to use DNS to connect. We are starting to move everything away from the DNS, as it has delays in propagating the correct information. Please use the IPs you get in the server list and not the ones you get in the DNS, as the server list gets the new data a lot faster and has a better algorithm for providing load balancing.

@qdm12 can this issue be closed?

Hello @g00nix thank you so much for the quite detailed answer. I should be good to go 👍

Please use the IPs you get in the server list and not the ones you get in the DNS

Funnily enough, that's why I was asking. I am currently extracting the IP addresses from your openvpn zip files and hardcoding the resulting IP addresses in that Docker image I'm working on, so that users don't need to rely on their DNS setup when running the container. I'll now definitely use that endpoint to update your nextgen v4 servers IP addresses, although I'll keep using the zip file approach for your older v3 servers.
Anyway, a big thanks for your work and help 💯

I'm guessing I can hardcode any IP addresses return by v4 list of servers. How can we get notified if there's ever a v5 (or any future version) of the server list?
Also, what does auto_region refers to? It seems all servers have that field as true
Last, given that all the servers domains end with .privacy.network does it mean that all servers returned by v4 are NextGen and the list doesn't contain any older "CurrentGen" servers?

Last, given that all the servers domains end with .privacy.network does it mean that all servers returned by v4 are NextGen and the list doesn't contain any older "CurrentGen" servers?

Yes: no current gen (v3) servers on this API endpoint it seems weather you use the /v3/ or /v4/ uri path.

I'm guessing I can hardcode any IP addresses return by v4 list of servers. How can we get notified if there's ever a v5 (or any future version) of the server list?

v5 is planned and will have provide 3 servers per protocol, instead of 1 server per protocol. The first server will stil bel the best, but the 2nd and 3rd servers will be listed for reconnect just in case the 1st server is not reachable.
I will discuss internally how we can announce when new versions of the serverlist are out.

Also, what does auto_region refers to? It seems all servers have that field as true

auto_region will be false if the entire region has some issues. The full App will avoid connecting to these regions when the user automatically connects (without picking a specific region). I am not sure if this should also be added these scripts, but I will think about it.

Last, given that all the servers domains end with .privacy.network does it mean that all servers returned by v4 are NextGen and the list doesn't contain any older "CurrentGen" servers?

The serverlist.piaservers.net/vpninfo/servers/ API will return only NextGen servers. Live versions in the apps are v3 and v4, but please use v4. We will upgrade these scripts to v5 as soon as it is ready for production.
We will gradually provide all the support required so that you can use only NextGen, as it has multiple improvements for security and performance. If you have troubles using NextGen, please open an issue.


feat: add SPACEFISH_PROMPT_BOLD option

Description
This change adds an ability to toggle font weight of prompt via SPACEFISH_PROMPT_BOLD option
Motivation and Context
It will be great to have the ability to disable default bold styling of the prompt
Types of changes

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

Screenshots (if appropriate):

How Has This Been Tested?

[x] I have tested using MacOS
[ ] I have tested using Linux

Checklist:

[x] I have checked that no other PR duplicates mine
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have updated the tests accordingly.

Thank you @kiurchv for the contribution! 😄
I'd love to get this merged in as soon as the feature is approved in https://github.com/denysdovhan/spaceship-prompt/pull/519.
For the time being, would you be able to add tests for the new configuration option to __sf_lib_section.test.fish and __sf_section_dir.test.fish?

Hey, @matchai! I've added some tests and rebased my commits on the current master

Thank you @kiurchv!
It appears there's still some uncertainty about how they plan to implement this feature upstream in spaceship, so I'm still a little hesitant to merge this in. 🤔
I'll keep an eye on the conversation and will keep you updated.

Closing this feature until the associated feature is implemented upstream.

@matchai I don't see this. Where was it added to upstream? The linked PR seems relatively abandoned.


Usage of deprecated package brings High severity Snyk issue

as per npm, package request was deprecated https://www.npmjs.com/package/request
Please replace it

Fixed in latest release.
Please use the updated SDK.
For any info, please let us know.
Thanks


[BUG] Service is unable to recover if the temporary driver-directory gets removed

Context:

Playwright Version: 1.17.0
Operating System: Linux
Browser: All

Describe the bug
Playwright uses a /tmp directory for creating the driver directory:
https://github.com/microsoft/playwright-java/blob/8d84afccec214856852fd812aa26a50e88e1f9e7/driver-bundle/src/main/java/com/microsoft/playwright/impl/DriverJar.java#L31-L34
However, if this directory gets removed, the service will not recover from the situation, but instead all attempts to launch a new browser will fail:
Caused by: java.io.IOException: Cannot run program "/tmp/playwright-java-16255647668257527045/playwright.sh": error=2, No such file or directory

I'm filing this as a bug because I would argue it should be safe to remove old files from the /tmp directory. We encountered this issue, because tmpreaper removed the driver directory after seven days.
I think ideally the service should create a new temporary directory if the old one gets removed. Also, it might be beneficial to be able to configure where these driver directories are created?

This is by design. Here are some details on how it works. Platform-specific driver binary (Node.js + node modules) is distributed in a jar file. In order to launch the driver we unpack it first into a temporary directory and then launch it from there. This step happens only once when you launch playwright. When the process finishes the temporary directory will be automatically removed. Playwright expects the the temp files that it creates to stay intact while it is running.

I'm filing this as a bug because I would argue it should be safe to remove old files from the /tmp directory. We encountered this issue, because tmpreaper removed the driver directory after seven days.

According to you description the tool removes files that are still in use by a running application which sounds wrong to me (btw, was Playwright running for >7 days?)

I think ideally the service should create a new temporary directory if the old one gets removed.

This is too much hassle. Imagine the directory being removed from under your feet, if some of the files are still open by the application they won't be removed while others will. Then the application may keep running until it tries to access another file from the driver which has been deleted. We considered providing a way to install driver as separate step independently from Maven and avoid using temp dir altogether, but so far the approach of bundling it in a jar has been working well enough. If we wanted to avoid the temp dir problem we'd rather require preinstalling the driver (see this feature request: https://github.com/microsoft/playwright-java/issues/467).

Also, it might be beneficial to be able to configure where these driver directories are created?

Yes, but again that seems inferior to just preinstalling the driver as a separate step whereas today maven handles all the dependencies and doesn't require any manual steps.

Yes; by default tmpreaper deletes files that haven't been touched for seven days. And our JVM process had been running for over seven days.

Yes, but again that seems inferior to just preinstalling the driver as a separate step whereas today maven handles all the dependencies and doesn't require any manual steps.

You could offer the possibility to override the temp-dir e.g. via some predefined system property (such as -Dplaywright.tmpdir=/path/to/somewhere)... 🤷
The fact is, as it stands now, you cannot have a long-running Playwright process running on a system where there is some clean-up script (such as tmpreaper) cleaning old files from the /tmp directory — unless you override the java.io.tmpdir (which is what we did). But overriding java.io.tmpdir affects ALL other library calls (not just Playwright), so it might not be ideal for every use-case.
Anyway... I do realize this is a minor issue. And probably not affecting many users. Just stating that (IMHO) ideally the service shouldn't become unusable if some cleaner-script deletes file old files from the temp directory. :) And I also realize, the ROI for fixing this might be quite small. :) Feel free to close this issue, if need be; I won't be offended. 😁

You could offer the possibility to override the temp-dir e.g. via some predefined system property (such as -Dplaywright.tmpdir=/path/to/somewhere)...

I guess this doesn't hurt, adding playwright.driver.tmpdir in the linked PR, should be available in the next release. If there are more requests about similar issues we can do something better but it sounds like it will unblock you for now.


fpm command line option -c doesn't work

fpm command line option "-c " doesn't work when specifying "-c 1".
In the case of "-c 1" it actually create most possible worker threads.
On my testbed with 4 cores, 2 worker threads are actually created and the other two are reserved for OS and control thread.
In fact many examples have similar issue, I will send patch to fix the issue soon.
Below are gdb backtrace to testify there are two worker threads and the command line option is "-c 1"
     example/fpm/fpm -i veth1,veth2 -c 1
     gdb -p <pid of fpm process>
     bt
     Thread 4 (Thread 0x7f2340ddd700 (LWP 11918)):
     #0  schedule_release_atomic () at ../../../odp/platform/linux-generic/odp_schedule.c:473
     #1  0x00007f234cf7acfd in schedule_release_context () at ../../../odp/platform/linux-generic/odp_schedule.c:320
     #2  do_schedule (max_deq=4, max_num=16, out_ev=0x7f2340ddcc80, out_queue=0x7f2340ddcc78)
         at ../../../odp/platform/linux-generic/odp_schedule.c:534
     #3  schedule_loop (out_queue=0x7f2340ddcc78, wait=18446744073709551615, out_ev=0x7f2340ddcc80, max_num=<optimized out>,
         max_deq=4) at ../../../odp/platform/linux-generic/odp_schedule.c:719
     #4  0x0000000000408973 in default_event_dispatcher (arg=0x4083e0 <ofp_eth_vlan_processing>) at ofp_pkt_processing.c:82
     #5  0x00007f234cd53b4f in odp_run_start_routine (arg=0x7ffea7b44f68) at ../../odp/helper/linux.c:40
     #6  0x00007f234c2c361a in start_thread (arg=0x7f2340ddd700) at pthread_create.c:334
     #7  0x00007f234bffd59d in clone () from /lib64/libc.so.6
     (gdb) thread apply 3 bt

     Thread 3 (Thread 0x7f23405dc700 (LWP 11919)):
     #0  queue_deq (queue=0x7f234d38b900) at ../../../odp/platform/linux-generic/odp_queue.c:514
     #1  0x00007f234cf78bec in odp_queue_deq (handle=handle@entry=0x21) at ../../../odp/platform/linux-generic/odp_queue.c:635
     #2  0x00007f234cf7ab9f in do_schedule (max_deq=<optimized out>, max_num=16, out_ev=0x7f23405dbc80, out_queue=0x7f23405dbc78)
         at ../../../odp/platform/linux-generic/odp_schedule.c:669
     #3  schedule_loop (out_queue=0x7f23405dbc78, wait=18446744073709551615, out_ev=0x7f23405dbc80, max_num=<optimized out>,
         max_deq=4) at ../../../odp/platform/linux-generic/odp_schedule.c:719
     #4  0x0000000000408973 in default_event_dispatcher (arg=0x4083e0 <ofp_eth_vlan_processing>) at ofp_pkt_processing.c:82
     #5  0x00007f234cd53b4f in odp_run_start_routine (arg=0x7ffea7b44fd0) at ../../odp/helper/linux.c:40
     #6  0x00007f234c2c361a in start_thread (arg=0x7f23405dc700) at pthread_create.c:334
     #7  0x00007f234bffd59d in clone () from /lib64/libc.so.6

Hi,
True.  You can find the reason around:
num_workers = odp_cpumask_default_worker(&cpumask, num_workers);
ODP changed and at OFP no one had time to properly update all the example applications (except for my attempt before OFP 2.0 release)
Take a look at https://github.com/OpenFastPath/ofp/blob/master/example/webserver2/app_main.c for some alternative.
BR,
Bogdan
From: Dapeng Liu<EMAIL_ADDRESS>Sent: Wednesday, January 25, 2017 5:37 AM
To: OpenFastPath/ofp<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: [OpenFastPath/ofp] fpm command line option -c doesn't work (#142)
fpm command line option "-c " doesn't work when specifying "-c 1".
In the case of "-c 1" it actually create most possible worker threads.
On my testbed with 4 cores, 2 worker threads are actually created and the other two are reserved for OS and control thread.
In fact many examples have similar issue, I will send patch to fix the issue soon.
Below are gdb backtrace to testify there are two worker threads and the command line option is "-c 1"
 example/fpm/fpm -i veth1,veth2 -c 1

 gdb -p <pid of fpm process>

 bt

 Thread 4 (Thread 0x7f2340ddd700 (LWP 11918)):

 #0  schedule_release_atomic () at ../../../odp/platform/linux-generic/odp_schedule.c:473

 #1  0x00007f234cf7acfd in schedule_release_context () at ../../../odp/platform/linux-generic/odp_schedule.c:320

 #2  do_schedule (max_deq=4, max_num=16, out_ev=0x7f2340ddcc80, out_queue=0x7f2340ddcc78)

     at ../../../odp/platform/linux-generic/odp_schedule.c:534

 #3  schedule_loop (out_queue=0x7f2340ddcc78, wait=18446744073709551615, out_ev=0x7f2340ddcc80, max_num=<optimized out>,

     max_deq=4) at ../../../odp/platform/linux-generic/odp_schedule.c:719

 #4  0x0000000000408973 in default_event_dispatcher (arg=0x4083e0 <ofp_eth_vlan_processing>) at ofp_pkt_processing.c:82

 #5  0x00007f234cd53b4f in odp_run_start_routine (arg=0x7ffea7b44f68) at ../../odp/helper/linux.c:40

 #6  0x00007f234c2c361a in start_thread (arg=0x7f2340ddd700) at pthread_create.c:334

 #7  0x00007f234bffd59d in clone () from /lib64/libc.so.6

 (gdb) thread apply 3 bt

 Thread 3 (Thread 0x7f23405dc700 (LWP 11919)):

 #0  queue_deq (queue=0x7f234d38b900) at ../../../odp/platform/linux-generic/odp_queue.c:514

 #1  0x00007f234cf78bec in odp_queue_deq (handle=handle@entry=0x21) at ../../../odp/platform/linux-generic/odp_queue.c:635

 #2  0x00007f234cf7ab9f in do_schedule (max_deq=<optimized out>, max_num=16, out_ev=0x7f23405dbc80, out_queue=0x7f23405dbc78)

     at ../../../odp/platform/linux-generic/odp_schedule.c:669

 #3  schedule_loop (out_queue=0x7f23405dbc78, wait=18446744073709551615, out_ev=0x7f23405dbc80, max_num=<optimized out>,

     max_deq=4) at ../../../odp/platform/linux-generic/odp_schedule.c:719

 #4  0x0000000000408973 in default_event_dispatcher (arg=0x4083e0 <ofp_eth_vlan_processing>) at ofp_pkt_processing.c:82

 #5  0x00007f234cd53b4f in odp_run_start_routine (arg=0x7ffea7b44fd0) at ../../odp/helper/linux.c:40

 #6  0x00007f234c2c361a in start_thread (arg=0x7f23405dc700) at pthread_create.c:334

 #7  0x00007f234bffd59d in clone () from /lib64/libc.so.6

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/OpenFastPath/ofp/issues/142, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJpgrhORTY9AQg2uw77BxKFvuidxhTWlks5rVsNugaJpZM4LtEF9.

Hi Bogdan,
Thank you for the comment.
I think the reason of the issue is that num_workers is decremented to 0 by mistake. When passed in 0 odp_cpumask_default_worker use its logic to choose worker threads. You mean the same, right?
When you expect a single thread for easy debug it turns out to be many threads on a multi-core system. This is a little annoying.
I am going to fix the issue in fpm using this ticket. If I have time I will change other examples accordingly.
Best Regards,
Dapeng


IMX519

Hi,
what do I have to do in order to use PiDNG with the IMX519?
Thanks for your time!

To elaborate,
In the example script, I set resolution and depth and processed the file without errors, but the resulting images are black.
Do you maybe have a hint, about what's going on?


Error install

i install Core on centos7 but when command: mvn clean install
show error:

I have the same problem, did you fix it ?

i dont know fix

I founded how to fix it! Thanks to chat-GPT... I'll post here soon how to do

I founded how to fix it! Thanks to chat-GPT... I'll post here soon how to do

post soon


Make FIFO async iterable, add close() method

Hello! This is a pull request which makes FIFO asynchronously iterable, so you can do this:
for await (const value of queue) {
	console.log(value);
}

Additionally, there is an extra close method added to the FIFO which allows you to signal that the queue is over and that any iterations should break.
The features can be completely ignored, and the FIFO can be used exactly the same way as before.

Kind of ironic that I hadn't already thought of this, as I actually use this in the internal implementation of another project of mine that allows for async iteration of WebSocket messages.

Yeah, those changes make sense to me too.


Adds support for AuditLogs

Attempts to convert the protobuf body of Audit logs to JSON for easier viewing.
Also attempts to convert all body key/values of Audit logs to labels on the log.
Filtering on these new labels should properly add a new filter to the query.

Sorry, I didn't see your PR and added the similar feature in mine: https://github.com/GoogleCloudPlatform/cloud-logging-data-source-plugin/pull/40
Since my PR has some extra things (I probably should break it to smaller ones), maybe you can review mine? Thanks!

Sorry, I didn't see your PR and added the similar feature in mine: #40
Since my PR has some extra things (I probably should break it to smaller ones), maybe you can review mine? Thanks!

@xiangshen-dk Hello. Just getting back from vacation. I took a quick look at the PR (which has since been merged). The parts related to Audit Logs looked ok to me. I think I only noticed two differences compared to this PR.

I attempted to display the body as a JSON string rather than protobuf string. Not really necessary (and possibly not the correct approach), but generally made it easier to look at in my opinion.

I created a brand new function for converting the Audit Log body to labels. Because of this I was able to handle both nested maps and arrays (I don't believe the function that you were reusing was handling arrays well. I think it just ended up dumping everything from that point forward into a single string). This allowed for proper log filtering with both map and array based properties (I had to also add a little bit of custom code to remove the [x] from the label key when adding to the query filter for it to work correctly).

I specifically think the features I had in (2) were useful (could be added to the existing label creation function to make both JSON and Protobuf labels more functional overall). Let me know what you think and if you'd like me to just close this PR. Thanks!

Thanks for the explanation! Would you mind to update your PR and resubmit it?


Handle revoked attributes

closes #22

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

:exclamation: No coverage uploaded for pull request base (main@e800580). Click here to learn what that means.
Report is 1 commits behind head on main.

Files
Patch %
Lines

src/types/ethr.rs
98.97%
2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #28   +/-   ##
=======================================
  Coverage        ?   93.00%
=======================================
  Files           ?       11
  Lines           ?     1343
  Branches        ?        0
=======================================
  Hits            ?     1249
  Misses          ?       94
  Partials        ?        0

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


arm64: fix compile failed 'tpidr_el1' undeclared

Summary
time/lib_localtime.c: In function 'tz_lock':
time/lib_localtime.c:396:7: error: 'tpidr_el1' undeclared (first use in this function)
  396 |   if (up_interrupt_context() || (sched_idletask() && OSINIT_IDLELOOP()))
      |       ^~~~~~~~~~~~~~~~~~~~

Impact
arm64
Testing
ci

[Experimental Bot, please feedback here]
No, this PR does not fully meet the NuttX requirements based on the provided information.
Here's why:

Insufficient Summary: The summary only provides a compiler error. It doesn't explain the why, what, or how of the change.  It needs to describe the root cause of the error, the intended solution, and the specific code modifications made.  Mentioning any related issues would also be helpful.
Incomplete Impact: While it mentions arm64, it doesn't fully describe the impact.  It needs to specify YES/NO for all impact categories and provide descriptions where necessary.  For example, even if the other impacts are NO, it should explicitly state that.
Inadequate Testing: Simply stating "ci" isn't sufficient.  The testing section requires details about the build host and target environments, along with actual testing logs from both before and after the change to demonstrate the fix.  "ci" only implies that continuous integration tests were run, but doesn't provide any evidence of their outcome or the specific tests executed.

The PR needs to provide significantly more detail to meet the NuttX requirements.


How to get the JSON of the button payloads in Rasa and display them on the User Interface

Rasa Core version: 0.12.3
Python version: 3.6.7
Operating system : Ubuntu
Issue: My button payloads are working fine in the command line, but on the user interface button are not displayed and i type the payload but it does not work. So my question is that how can we first get the JSON of the button payloads and then how can we show them on the interface?. Help would  be much appreciated. Thanks.

Which interface are you using?

Django

any solution?

Ok I think you have to handle the buttons case for your custom UI then, there's not much we can do here since it seems to be a custom UI implementation :)


Upgrade oauth gems

I rule and have completed some work on Case Manager that's ready for review!
The oauth library ecosystem has resolved its weird hangups, so we can unpin a couple of our oauth libraries. And keeping oauth libraries up to date is important, because ~ authentication~ !
This pull request makes the following changes:

bump devise
bump omniauth-google-oauth2

I could get this to work locally but we should be sure to hammer on it on sandbox too.
It relates to the following issue #s:

Fixes #1171

Codecov Report

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

@@           Coverage Diff           @@
##           master    #1422   +/-   ##
=======================================
  Coverage   94.83%   94.83%
=======================================
  Files          65       65
  Lines        1568     1568
=======================================
  Hits         1487     1487
  Misses         81       81

Impacted Files
Coverage Δ

app/models/user.rb
98.95% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Publisher: Attribute defs without key

Running version
3.15.2-nightly.1
Describe the bug
if UISeparatorDef() added to get_attribute_defs on any  plugin with OpenPypePyblishPluginMixin class.
Traceback (most recent call last):
  File "C:\CODE\__PYPE\OpenPype_3.15_up\openpype\tools\publisher\widgets\overview_widget.py", line 268, in _on_subset_change
    instances, context_selected, convertor_identifiers
  File "C:\CODE\__PYPE\OpenPype_3.15_up\openpype\tools\publisher\widgets\widgets.py", line 1674, in set_current_instances
    instances, context_selected
  File "C:\CODE\__PYPE\OpenPype_3.15_up\openpype\tools\publisher\widgets\widgets.py", line 1441, in set_current_instances
    instances, context_selected
  File "C:\CODE\__PYPE\OpenPype_3.15_up\openpype\tools\publisher\control.py", line 1945, in get_publish_attribute_definitions
    value = attr_val[attr_def.key]
  File "C:\CODE\__PYPE\OpenPype_3.15_up\openpype\pipeline\create\context.py", line 572, in __getitem__
    return self._data[key]
KeyError: None

[cuID:OP-5021]

Resolved by https://github.com/ynput/OpenPype/pull/4534


IE11 hover bug with dropdown in nav

Have a look at the image (it's a screenshot from http://materializecss.com/navbar.html). When hovering the dropdown item (or in the lower vicinity) in Internet Explorer 11 it shows an empty div. Is this a bug and will be fixed?
I should mention that when clicking, the dropdown meny shows correctly.
Ideas?

I doesn't have IE 11, could you check if this is still an issue with the last version?
Closed due inactivity, feel free to reopen it if it is still necessary.


Use pkg_config to resolve ffmpeg native dependencies

closes #21

Let's bump version to 0.7.1 so we will release it 😉

done


Incomplete download - EOFError: Compressed file ended before the end-of-stream marker was reached

reported by @faris-k

Forgot to push a new release. Should be solved in v0.2.0


GET https://jeromeetienne.github.io/AR.js/data/data/camera_para.dat 404 (Not Found)

The issue arised about 15-20 mins ago and none of my experiences work anymore.
it says

GET https://jeromeetienne.github.io/AR.js/data/data/camera_para.dat 404 (Not Found)

Can somebody please help me out here please?

It was a temporary issue due to website update. sorry about that

No issues. Closed it as soon as it was fixed.
Thanks.


decrease likelihood of possible race condition

Description

This is to decrease the likelihood of a race condition that could occur if a machine is running HookOS and Tink worker is connected and running when a workflow is created.
The workflow would start to execute but then be cut off when the reboot action is called. This has been shown to cause undefined behavior.

important to note that because the BMC interactions are just creation CRD creations and these happen quite quickly, there's no guarantee that this even decreases the likelihood of this race condition.

Why is this needed

Fixes:
How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:
I have:

[ ] updated the documentation and/or roadmap (if required)
[ ] added unit or e2e tests
[ ] provided instructions on how to upgrade

@mergify refresh


applied like color-toggle again

production was failing without any reason so reverted and pushing again

@bhoopesh369 we're getting these errors in the build.

Maybe due to older posts not having this property is what's causing the problem.

you may work on the development branch of this project, which is already having these changes and try to fix the issue, if before me.

try running the build script and check that production build

Heyy @narayan954
I have solved the issue
now you can merge the pull request

Heyy @narayan954 I have solved the issue now you can merge the pull request

I have made a new PR... check it out

Heyy @narayan954 I have solved the issue now you can merge the pull request

I have made a new PR... check it out

checked and merged


Big refactoring

All the changes are described in details in the article: https://medium.com/@chvanikoff/lets-refactor-std-json-io-e444b6f2c580
This PR brings backward-incompatible changes so in case it will ever be merged, minor version of the library must be increased to 0.2.0.

@hassox What are the chances of this getting merged in and released soon?

@chvanikoff Why did you remove the __using__ functionality?

@geolessel because it's useless and is not actually a functionality, but requirement: you have to perform unnecessary initial setup (create module, add it to your app's supervision tree) and the only thing you get from it is an ability to call MyApp.MyIoServer instead of just StdJsonIo.

This seems well thought out, would also love to see this merge.  Also had problems with current version because of 64k chunk issue. Let me know if there is anything I can do to help get this accepted and merged. I can test it further on my own apps, load test it for perf issues, and/or add additional unit tests if felt needed.

@somlor you are welcome to test the PR in any ways you can think of, I would be very thankful for a feedback. If you know about any use-cases not yet covered by tests - let me know as well.

@chvanikoff just reading the comments. The using module provided for this was to prevent global configuration and allow for multiple jobs apps to be mounted and rendered. I haven't been paying attention to the job side of this lib so not sure if that is still a thing that would need to be handled on this side

The main use case I have in mind for such a multi app setup is when mounting another app as a library inside your main application (although that is not the only use case).
For example the (exq lib)[https://github.com/akira/exq] can run as a stand alone app, or be mounted in a hot app yet provides it's own front end. (I know they use ember but the pattern is the same)

@hassox hi, glad you joined the discussion.
About configuration - it's not a big deal to add StdJsonIo.configure/1 and don't start workers in case config is empty. So instead of defining a module you still will only have to write something like StdJsonIo.configure(script: "rect-stdio") in Application.start callback, for example. Similar to how poolboy works.
About different runners - never thought about it / used it in a such way, but it's also not that hard to add a support for this.

I think it's the different runners that I'm concerned about. If support for that is removed then lib writers would not be able to use it (I believe) for fear of stepping on the main application. Is that assumption still correct or has the js side been updated to be able to handle it?

Sorry hit send too quickly. I also imagine that ember and elm will eventually get a server side renderer and I'm wondering how that would be supported.

different runners can be implemented somehow like this:
# in runtime
configure(runner, config)
# or via config
config :std_json_io,
  react: %{
    script: "react-stdio"
    ...
  },
  elm: %{
    script: "some-elm-renderer.js"
    ...
  }

and then any library can run configure("some_lib_react", %{script: "my-react-stdio"})
Sorry, not sure I understand what you mean by JS-side update.


Update Integration Studio documentation

Purpose
Updating Integration Studio documentation. Fixing typos and formatting.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.


feat(atomic_update): Allow the atomic_update property

STATE:
When trying to setup '/etc/resolv.conf' for a docker image, chef fails
with the following error:

================================================================================
Error executing action create on resource 'template[/etc/resolv.conf]'
Errno::EBUSY
Device or resource busy @ rb_file_s_rename - (/etc/.chef-resolv20220527-680-734sd3.conf, /etc/resolv.conf)
Cookbook Trace: (most recent call first)
/opt/kitchen/cache/cookbooks/resolver/resources/config.rb:99:in `block in class_from_file'

The logic behind this error is describe on the follwing issue:
https://github.com/moby/moby/issues/9295#issuecomment-140350434
And a PR was created to fix this in a previous recipe:
https://github.com/sous-chefs/resolver/pull/22
PROPOSED SOLUTION:
Add the 'atomic_update' property on the resource
Signed-off-by: Jeremy MAURO<EMAIL_ADDRESS>Description
Describe what this change achieves
Issues Resolved
List any existing issues this PR resolves
Check List

[x] A summary of changes made is included in the CHANGELOG under ## Unreleased
[x] New functionality includes testing.
[x] New functionality has been documented in the README if applicable.

Hello,
I think the first test error is not related to my PR, but a git workflow issue. How could I help fixing it?
Kind regards,
JM

Hello,
I think the first test error is not related to my PR, but a git workflow issue. How could I help fixing it?
Kind regards, JM

If you apply the same changes as https://github.com/sous-chefs/yum-epel/commit/b8fde01aec64f2bb2f4c068f5cbb577edfee6115, that should fix it. Delivery has been deprecated so the CI config just needs updating to take this into account.

Hello,
Done the workflow has been updated.
Kind regards,
JM

Oh but also this PR is not setting atomic_update to false in the tests, you should try that first.

Released as: 4.1.0


99551 remove zimbra references

Setup Sitecore 8.1 and Community 9.2

Tested MVC Sample

https://telligent.tpondemand.com/entity/99551


Rename variable names to subreddit instead of reddit

See https://github.com/reactjs/redux/issues/2742.

Oh, I see. It's nomenclature, not a mis-used variable. Interestingly, this was already done in the docs: https://github.com/reactjs/redux/blob/master/docs/advanced/ExampleRedditAPI.md
Thanks!


[KYUUBI #5605] Add mock output table rule

Why are the changes needed?

When debugging SQL tasks, we may need to replace the output table with a test table to avoid overwriting online data.
So I implemented a MockOutputTable rule to replace the output table with a mock table which ends with _mock_${System.currentTimeMillis()}.
How was this patch tested?

[X] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Was this patch authored or co-authored using generative AI tooling?

No

Codecov Report

Merging #5605 (7b7739f) into master (591250c) will decrease coverage by 0.28%.
Report is 11 commits behind head on master.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #5605      +/-   ##
============================================
- Coverage     61.69%   61.42%   -0.28%
  Complexity       23       23
============================================
  Files           603      603
  Lines         35670    35669       -1
  Branches       4869     4869
============================================
- Hits          22005    21908      -97
- Misses        11281    11381     +100
+ Partials       2384     2380       -4

see 29 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Fix meta class cast exception when generator not supported

Fixes #9034.  GpuGenerateExecSparkPlanMeta was blindly downcasting in tagPlanForGpu.  That's safe in convertToGpu, as we've pre-checked that all the exprs are supported.  However in tagging a child may be unsupported, and therefore the downcast needs to be checked before casting.

build


[Feature request] Ability to delete multiple tags at once

It seems that tag_name accepts String only.
We wanted to use this Actions to delete multiple tags, but there seems no way (with can be used only at once I believe).
The solution would be that tag_name accepts an array or a regex. Using an array might be preferable since it makes implementation simpler.

We could add that feature in the future (or now with a PR from someone) but there are already several existing Actions in the GitHub Actions marketplace that allow bulk deletes as you are suggesting by an array of tags.  The GitHub API could also be called directly and you could pass in your token and iterate over your tag set.

Or perhaps our other Action is what you need depending on your
criteria https://github.com/dev-drprasad/delete-older-releases

Thanks, I googled it and found this repository first. I'll look for other Actions that do what we want.
I'll keep this issue open until finding alternative solutions.

@okuramasafumi do you still need this feature?  or were you able to find an alternative solution?

@thadguidry Currently I don't need this feature anymore. I'll close this for now. Thanks!


ARROW-12190: [Rust][DataFusion] Implement parallel / partitioned hash join

This implements a first version of parallel / partitioned hash join / grace join and uses it by default in the planner (for concurrency > 1)
Master (in memory / 16 threads / partitions, SF=1, batch size = 8192)
Query 5 avg time: 141.29 ms
Query 10 avg time: 477.63 ms

PR
Query 5 avg time: 91.60 ms
Query 10 avg time: 272.25 ms

Also when loading from parquet it also achieves ~20% speed up in total and has better utilization of all threads (this is SF=10 with 16 partitions on 16 threads in Parquet running 10 iterations):

FYI @andygrove
Note: I think the same approach could also be used by the hash aggregate, rather than the partial / full approach taken now, but this might be only be better when we have a high number of distinct group by by values (in extreme cases - groups with one row), e.g. the "full" hash aggregate takes up a lot of the time/memory.
@alamb
I think your earlier comment w.r.t. "CoalesceBatches" is especially applicable here - I am seeing quite some overhead in CoalesceBatches/Concat after RepartitionExec with hash repartitioning, as this will make each produced batch roughly num_partitions times smaller (in contrast to roundrobinbatch repartitioning - which keeps the same batches which makes it almost free on a single node). The overhead is so big that lowering the concurrency setting to 8 instead of 16 on my 8-core / 16-hyperthreads laptop yields better performance. Increasing the batch size (to 32000-64000) also recovers the performance / avoids the overhead penalty mostly - but I recently reduced this as for most queries ~8000 was the sweet spot.
Rewriting to buffer them inside the RepartitionExec and only produce them when they exceed the batch size probably would solve this issue and improve the performance of the parallel hash join quite a bit - or maybe by optimizing the concat kernel.

Codecov Report

Merging #9882 (5942020) into master (5bfae36) will increase coverage by 0.08%.
The diff coverage is 88.72%.

@@            Coverage Diff             @@
##           master    #9882      +/-   ##
==========================================
+ Coverage   82.60%   82.68%   +0.08%
==========================================
  Files         255      256       +1
  Lines       59674    60144     +470
==========================================
+ Hits        49295    49732     +437
- Misses      10379    10412      +33

Impacted Files
Coverage Δ

rust/arrow-pyarrow-integration-testing/src/lib.rs
0.00% <ø> (ø)

rust/arrow/src/datatypes/field.rs
55.47% <0.00%> (ø)

rust/arrow/src/error.rs
11.11% <0.00%> (-0.52%)
:arrow_down:

rust/arrow/src/ipc/writer.rs
86.70% <0.00%> (-0.74%)
:arrow_down:

rust/benchmarks/src/bin/tpch.rs
38.42% <0.00%> (+0.09%)
:arrow_up:

rust/datafusion/src/logical_plan/expr.rs
83.39% <ø> (ø)

rust/datafusion/tests/dataframe.rs
100.00% <ø> (ø)

rust/parquet/benches/arrow_writer.rs
0.00% <0.00%> (ø)

rust/datafusion/src/scalar.rs
51.22% <33.33%> (-0.15%)
:arrow_down:

.../datafusion/src/physical_plan/regex_expressions.rs
86.15% <60.00%> (-2.18%)
:arrow_down:

... and 20 more

Continue to review full report at Codecov.

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

@jorgecarleitao I am wondering if you have found a more performant implementation or ideas for the concat kernel in your arrow2 branch?
In this case (even though the extra parallelism has better performance and better scalability), through CoalesceBatches it is adding significant overhead, but looking at the implementation think there are probably quite some opportunities to improve performance there - especially for the concat case there seems too much work currently done in the MutableArrayData and creating intermediate Vecs. etc.

This is looking really good. I agree with your suggestion about buffering data and only emitting batches when they reach a target size.

@jorgecarleitao I am wondering if you have found a more performant implementation or ideas for the concat kernel in your arrow2 branch?

The concat before the transform module was 6x slower ^_^. arrow2 is a bit faster than arrow. However, the bottleneck in both implementations is concatenating validities. While buffers are a simple memcopy, bits require more due to the bit offsets. E.g. concatenating an array to an array1 where array1.len() % 8 != 0 requires shifting the whole bitmap of array2. This causes concatenating with validities to be ~2x more expensive than without validities, in both implementations. https://github.com/jorgecarleitao/arrow2/issues/12 tracks this on the arrow2 side of things.
The other potential improvement is to downcast instead of using vtables, since downcasting allows the compiler to inline some operations.

Thanks @Dandandan  -- I plan to review this carefully later today

@alamb added one test with multiple partitions - maybe later I can add some more tests. I also tried running the TPC-H benchmarks, which return the same results / failures as on master.

I plan to review this later this today

I think this looks great. Thanks @Dandandan !

Thanks! Really excited about it myself! 🙂


Custom logger to have visibility into the filter from the outside

This PR allows integration testing to have more visibility into what is happening inside the cache filter by exposing logs into the response headers. Logs are stored only when the cache is built with visible-logs feature flag.

@unleashed Can you please just confirm that syntax around if cfg!(feature = "visible_logs") {...} is fine or can be improved?

@rahulanand16nov some of the comments above extra lines were not addressed here.


New db schema and migrations

In parallel to the UI changes I started updating the database model to ensure we have the data that we need to render the UI.
This PR proposes the following schema for benchmarks:
CREATE TABLE benchmarks(
	run_at timestamp without time zone,
	duration interval NOT NULL,
	repo_id varchar(256) NOT NULL,
	commit varchar(50) NOT NULL,
	branch varchar(256),
	pull_number integer,
	name varchar(256),
	data jsonb
);

In addition to this I added omigrate as a development dependency to the project to help with future schema changes.

I think knowing the duration is generally useful. Specially because we want to add quick/slow annotations. This would allow us to better quantify quick and slow.
And yes, I think having a graph for this would be good too. This would be an extra metric provided by OCaml Benchmarks. I discussed with Ewan adding some other metrics like overall memory/cpu usage during the benchmark.

I think knowing the duration is generally useful. Specially because we want to add quick/slow annotations. This would allow us to better quantify quick and slow.
And yes, I think having a graph for this would be good too. This would be an extra metric provided by OCaml Benchmarks. I discussed with Ewan adding some other metrics like overall memory/cpu usage during the benchmark.


Support React 15.5.0 PropTypes

Upgrade the project to use the new 'prop-types' package.

Thank you 🙏


Logo Proposal

Hello sir, I'm a graphic designer and I would love to contribute to your project with a logo. This is completely free, take it as a contribution. In case you agree I would be presenting sketches and you will be choosing/modifying the aspects you like more so we could work on the perfect logo for your project together.
Let me know what do you think? best regards :)

This is not a proper forum for this kind of inquiry.

Why?

Because this is not an issue, or problem with AudioKit.  Contact one of us by email, which is easy enough to discover.


Please include the SOF-ELK parsers and dashboards as offline build options

Please include the SOF-ELK parsers and dashboards, either as a default include with the offline build, or as an option:
"All parsers and dashboards for this VM are now maintained in this Github repository. You can access them directly via http://for572.com/sof-elk-git "
https://github.com/philhagen/sof-elk/blob/master/VM_README.md

I'll have to consider this after the 2.0 release.  Not enough time to
integrate this at this point.
On Dec 1, 2016 08:27, "charlesfair"<EMAIL_ADDRESS>wrote:

Please include the SOF-ELK parsers and dashboards, either as a default
include with the offline build, or as an option:
"All parsers and dashboards for this VM are now maintained in this Github
repository. You can access them directly via http://for572.com/sof-elk-git
"
https://github.com/philhagen/sof-elk/blob/master/VM_README.md
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rocknsm/SimpleRock/issues/77, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKeNpKHL84IIFqcfRyN7YOoRguXmxDMks5rDtlWgaJpZM4LBdCj
.

The capabilities introduced with SOF-ELK, while terribly useful in the defense of a network, are far afield of the core purpose of what we're trying to achieve.  In a larger scale deployment, with an ELK cluster as opposed to a single instance, you could implement a logstash ingest point with the SOF-ELK configs to complement your NSM data.  With the lift of setting up the ELK cluster already done, it would be a reasonable next step, but not one that falls within the NSM goals of ROCK.


Feature/create node kwargs

When users are running create_vm it's useful to define defaults for some drivers. this would be in create_node_kwargs within the config.yaml for each driver setting.

I would personally prefer for those (additional create_node kwargs) to be an action parameter.
This way it's easier to re-use and test it (action params are almost always preferred since they make code more re-usable and easier to test).

both would be nice too.... having defaults removes the need to constantly parse them around.

If you want to bind action parameter to some particular value, one thing you can do is create a wrapper action metadata file which binds that parameter to a value. And if you want you can also make that parameter immutable.
For example, something like:
---
name: gce_create_vm
runner_type: run-python
description: Create a new VM in GCE.
enabled: true
entry_point: create_vm.py
parameters:
  credentials:
    type: string
    description: Name of the credentials set (as defined in the config) to use.
    immutable: true
    default: "gce"
....
  extra_kwargs:
    type: object
    description: ....
    required: false
    default: { "ex_foo": "blah" }
...


Hitting the file descriptor limit is unhandled

Hitting the file descriptor limit is unhandled
Description
Not sure if this is the appropriate place for this, but something I wanted to bring up.
If you have the default FD count on Ubuntu for example per user (1024 or 2048), you very quickly will hit the file descriptor limit due to the sheer amount of http requests some clients can submit to nodes (eth_blockNumber, eth_getTransactionReceipt, eth_getLogs) are some classic ones that are used a lot.
basichost failed to resolve local interface addresses {"error": "route ip+net: netlinkrib: too many open files"}

Your environment

OS and version Ubuntu 20
version of the Polygon SDK develop
branch that causes this issue develop

Steps to reproduce

Tell us how to reproduce this issue
Start a node using systemctl and set a low FD limit such as LimitNOFILE=1024. Use https://github.com/mrwillis/eth-txn-spam or a similar tool to spam transactions at the node.

Get the PID of the SDK node and run
lsof -p $PID
You'll see there is a huge amount of FDs allocated to TCP requests.

Where the issue is, if you know
Which commands triggered the issue, if any

Expected behaviour
Not really sure
Actual behaviour
All RPC requests after the fact hang after the limit is reached
Logs
basichost failed to resolve local interface addresses {"error": "route ip+net: netlinkrib: too many open files"}

Proposed solution
Maybe this is a documentation improvement for the "recommended minimum" FD amount. Generally you might handle this at a layer above.

Hi @mrwillis ,
Thank you for raising this issue.
After some extensive testing, we've determined that the optimal FD value should be 65535 .
We've updated the official PolygonSDK documentation with this information under the Local and Cloud Setup sections.
Closing this issue.


Disambiguate duplicate Member names

This adds a safer name mutation strategy in output.rs, by checking to see if a pascal/snake rename would generate a duplicate name, and then suffixing the name if it does to keep it rust compatible.
This is to fix certain pathological cases like #165.
This solution does not drop information, and always manages to include everything in the struct (even if we don't know which one will eventually go away, like the case with relabeling actions).
Annotated Example
Using the PodMonitor CRD with the clashing relabeling actions, this is what we now produce on the the struct by default (minus my explaining comments about where the member name came from):
#[derive(Serialize, Deserialize, Clone, Debug)]
pub enum PodMonitorPodMetricsEndpointsMetricRelabelingsAction {
    #[serde(rename = "replace")]
    Replace, // originally named "replace" in the spec (a deprecated name)
    #[serde(rename = "Replace")]
    ReplaceX, // originally named "Replace" in the spec
    #[serde(rename = "keep")]
    Keep, // originally named "keep" in the spec (deprecated)
    #[serde(rename = "Keep")]
    KeepX, // originally named "Keep" in the spec

    #[serde(rename = "labelmap")]
    Labelmap, // originally named "labelmap" in the spec (deprecated)
    LabelMap, // originally named "LabelMap" in the spec
    /// ....
}

Caveats

You might have to rename the code down the line if "deprecated" attributes got removed (removing the need for the suffix)
You can end up with extremely similar struct names, but there's also no way to avoid this without actually removing variants we would ideally want to remove (no deprecated attrs). You reap what you sow.

Maybe in the future if the OpenAPI spec can include deprecated attrs, we can remove this logic.
(This PR was originally trying to deduplicate members by name, but this ended up picking the wrong names, leaving the good ones unreachable by chance. Will squash away commits at the merge.)

I like this a lot & it completely removes the need for my home grown solution (I have used yq to remove duplicate fields before passing the modified YAML to kopium). Running this against all CRDs in kube-custom-resources-rs yields a single warning though: The natOutgoing and nat-outgoing fields in an Calico IPPool resource are not enums and thus should use snake_case. The generated code is here: https://github.com/metio/kube-custom-resources-rs/blob/kopium-206/kube-custom-resources-rs/src/crd_projectcalico_org/v1/ippools.rs#L38

thanks @sebhoss , have added a smarter suffixing var to deal with the differences between struct and enum members now!

also nice to see all that manual override code go away :smile:

yeah this solution here is a lot better since it retains all enums/fields so people can actually use all possible values (even though they are deprecated upstream).
Great stuff - thanks a lot!


Audio Playback issue when a new song is queued

When the new song is added to the queue the bot stops playing the current song unless the new song is played

Its a simple if statement fix which was found out by SC #0600
Link to Fix: https://canary.discord.com/channels/416512197590777857/804459883017142272/827077697204650005
Server Link: https://discord.gg/menudocs
    const player = client.music.create({
      guild: message.guild.id,
      textChannel: message.channel.id,
      voiceChannel: message.member.voice.channel.id
    });
    // Here we check if the player was connected before or not . If not then only we connect
   // - player.connect();
   if (player.state !== "CONNECTED") {
   	 player.connect();
   }


Bluetooth audio experiences breakup under moderate CPU load

Routing via the CRAS audio adaptor from Crouton's chroot works pretty well, (using Guayadeque or Quod Libet), even when relaying audio to a nearby Bluetooth Audio adaptor.
However, I experience issues when any CPU load is introduced, such as when scrolling browser windows or loading new pages. It sounds like it's causing buffers to underrun as the browser process priority allows it to take resources from the processes serving the audio relay.
Any idea what processes I need to 'renice' in order to prioritise the various audio buffer daemons over the browser. I've tried prioritising like sudo renice 19 28734 with the appropriate process numbers  for Guayadeque and Quod Libet, the minijail of bluetoothd, and the minijail of cras, cras itself, pulseaudio but so far I still experience the issue whenever anything's happening in Chromium.
I've also tried the opposite - deprioritising Chromium like...
ps aux | grep chromium | awk '{print $2}' | xargs -n1 sudo renice -19
...but the breakups still occur.
Do I have to go down the route of changing the kernel scheduler to make this possible? Any other options I have?
Without solving this, I can't easily have audio in my office environment as almost any use of the chromebook causes breakups.

Do you have similar issues when playing audio on Chrome OS directly? Or is it just when playing from crouton?
Can you provide the output of croutonversion? Is pulseaudio running in the chroot?

I've encountered breaks in audio within Google's Play Music, and BBC's online audio player. It doesn't seem to be as easy to recreate there, however. Within e.g. Guayadeque, I can consistently recreate the problem by launching a rebuild in the Java-based software I use to edit javascript. However, this doesn't consistently affect playback in Google Play Music the same way. Somehow the ChromeOS media playback, isn't exposed to the CPU burstiness the same way.
This Crouton build is a fairly recently-updated LXDE Ubuntu Trusty.
crouton: version 1-20150811114815~master:f6b810fe
release: trusty
architecture: amd64
xmethod: xorg
targets: lxde-desktop,core,extension,keyboard
host: version 7077.134.0 (Official Build) stable-channel swanky
kernel: Linux localhost 3.10.18 #1 SMP Sun Aug 16 14:03:22 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux
freon: yes```

I can see a process like ```/usr/bin/pulseaudio --start --log-target=syslog``` which I think proves pulseaudio is running.


Add ability to change docker registry for external tests

Related to the now stale pull request for https://github.com/adoptium/aqa-tests/pull/1833, this enhancement issue is to add support for using Docker images from other registries (besides where we currently pull from... the AdoptOpenJDK Docker repo).
This is not urgent, but wanted to create it so we do not lose the request, as we will close the stale PR that has no associated issue.

@smlambert please can i take this

Please assign me to this. I would like to work on it

@jnjerin I have a draft for this https://github.com/adoptium/aqa-tests/compare/master...sophia-guo:test?expand=1. Please take a look and try. Any question or problem just ping me. Thanks

Okay. I'm on it @sophia-guo

For the private docker registry, we should also consider supporting user-provided credentials.

@llxia for credentails I would suggest to track in a different issue.


Rendering of IMG, IFrame appears to be broken

These 2 classes if presented in dataframe should be rendered in HTML to img and iframe tags. For me it didn't work. Our youtube example relies on this feature, so I went and checked if the previously working example is still intact, but the answer is no for IntelliJ project. In datalore its even worse, it breaks completely when i run cell with "load", although it doesn't even use any iframe or anything like that, only special rendering of URL. At this point i decided not to investigate Datalore issue further.

Where it's used
https://github.com/Kotlin/dataframe/blob/0160fbd7fbf1f58d72c70639c10af5169442d6ad/examples/idea-examples/youtube/src/main/kotlin/org/jetbrains/kotlinx/dataframe/examples/youtube/youtube.kt#L58
And how it supposed to look

It seems that problem is with CellRenderer. Jupyter uses different implementation, rendering there is just fine


Fix typo in Intro To Livebook

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @nathanbegbie :)


Suppress warning - Unable to use the [locale] URL segment

When starting my local dev server, I get an overload of warnings about the library not being able to use URL segments for specific page. However for these pages I'm using content from a CMS instead of static strings. So it's a bit annoying to get all these warnings everything I start up my dev server.
warn  - unable to use the `en-GB` URL segment for `/Users/code/project/pages/[slug].jsx`. The message file `/Users/code/project/pages/[slug].en-GB.properties` does not exist.

Ultimately it would be nice to be able to suppress these kinds of warnings.

@jurrianlammerts good catch - will push a release shortly to remove these warnings! Thanks for reporting it.

@jurrianlammerts which version of next-multilingual are you using? I can no longer find this warning message in our code and this warning should be eliminated by this code here: https://github.com/Avansai/next-multilingual/blob/864075a54c47228edd865f7598302975b3ccb317/src/config/index.ts#L194
I'd suggest to update to get rid of the warning - let me know if this does not resolve the issue!

@nbouvrette Thanks for the help! Upgrading to the latest version resolved the issue.

After changing my config file to my needs, I came across the following: I do have static pages that are translated with content from the CMS, but without a dynamic [slug]. So I do understand why I still get this warning after adding all my pages back in the project:
warn  - unable to create the en-GB slug for pages/contact.jsx. The message file pages/contact.en-GB.properties does not exist.

It still would be a nice option to be able to config these warnings!

@jurrianlammerts can you explain a bit more the use case - are you saying you do not want to use the localized URLs? Unless I a missing something, you should be able to add slugs for static pages,

@nbouvrette with static pages I mean the ones located in the /pages folder, for these pages I'm getting the warnings. I indeed don't use localized URLs.

@jurrianlammerts this issue has been inactive for a while - I still have an open question in my last comment, feel free to comment and re-open if you have a chance!


[REQUEST]  add attribute version

The rich api changes frequently, requires access to the current version of lib rich (print (rich .__ version__)) from the python interpreter itself.
AttributeError: module 'rich' has no attribute '__version__'

https://github.com/willmcgugan/rich/issues?q=is%3Aissue+is%3Aclosed++__version__

https://github.com/willmcgugan/rich/issues?q=is%3Aissue+is%3Aclosed++__version__

The link is empty. I also could not find information on the __version request.
Can you tell us what you mean? 🤗
@willmcgugan

Search issues for version

Solution I found (I'm sorry I wasted my time on this). It's not worth it.
 import pkg_resources
 pkg_resources.get_distribution("rich").version

9.5.0
I don't want to take this approach (it's slow and resource-intensive). I'm not even sure if it worked on my system, it might not work for others.
Better to duplicate code than importlib_metadata (comments on issues on this topic speak for themselves).
https://github.com/python-poetry/poetry/issues/144


Adding regions and languages

working on : Enumerate Languages And Dialect Regions #79
for countries: https://www.iban.com/country-codes

Solved issues :  #60 , #79

for Ubuntu / Unix like systems, issue #55 is solved

@TrifanBogdan24 thanks for opening this PR!
Can you remove the .idea folder from this PR?  You can add it to the .gitignore file.
Each new file should also contain some documentation on where it was sourced from, or removed if not used.
Before I review further, please run
cargo fmt

and fix warnings/errors returned by
cargo clippy

Sure. I will push the corrected code ASAP.

@AldaronLau, I solved the warning generated by cargo clippy (most of them were related to cyclomatic complexity, therefore I had to split the code in multiple functions).
I don't know how to solve cargo fmt
Please double check the language and country encodings to be correct.

@TrifanBogdan24 apologies it's taken me so long to get to this.
When running cargo fmt, use +nightly:
cargo +nightly fmt

It may take me a while to get through verifying the country encodings.

Found the ISO documentation not behind a paywall or limiting copyright at government websites:
For reference, languages should be checked against https://www.loc.gov/standards/iso639-2/ISO-639-2_utf-8.txt
And countries should be checked against https://www.cia.gov/the-world-factbook/references/country-data-codes/ (CSV file)
I can do the checking / testing against what you have.  I think the .txt files you have in this PR can be deleted.

@TrifanBogdan24 are you still interested in working on this after my most recent feedback to split into multiple PRs?  (Also, apologies about the merge conflicts).
It would be nice to have your fix for #55 in whoami 1.5.0.  Otherwise, I can split it out of this PR if you're no longer interested in working on this.  Thank you


Create migration guide

Show migration steps from fluxible-plugin-routr/flux-router-component to fluxible-router.

https://github.com/yahoo/fluxible-router/blob/master/UPGRADE.md


Sets kontena vault list width to be 80 characters and not cropping

See issue #615
If the key is longer than 54, then the whole line will be longer (with the timestamp at the end). This ensures that no keys get cropped.

 You should sign our Contributor License Agreement in order to get your pull request merged.

Looks good, thanks!


Toggle Buttons Have Shrunk and Have No Text on the Staging Server

Toggle buttons (I am not sure if this is the correct name of the object) have shrunk and have no text on the staging server.  I can still select a toggle button, but I don't know know what I'm selecting because of the lack of text.
Here's list of toggle buttons I have found and how to recreate the error.

Create a new person.  The "Role" toggle button has shrunk and doesn't have text.
Create a new position.  The "Type" toggle button has shrunk and doesn't have text.
Create a new position.  The "Permissions" toggle button has shrunk and doesn't have text.
Create a new organization.  The "Type" toggle button has shrunk and doesn't have text.

The "Status" toggle buttons for actions/milestones are okay.
The "Atmospherics" toggle buttons for reports are okay.

@VassilIordanov @gjvoosten The last release to the staging server corrected this.  I am closing this issue.


SPARK-36791 fix spelling mistakes in running-on-yarn.md file where JH…

…S_POST should be JHS_HOST
this is a spelling mistakes in running-on-yarn.md file where JHS_POST should be JHS_HOST

Can one of the admins verify this patch?

@HyukjinKwon thank you,I will modify it according to your suggestion

@jiaoqingbo mind enabling GitHub Actions in your forked repository? see also https://github.com/apache/spark/pull/34031/checks?check_run_id=3672048545

@HyukjinKwon

Is there some thing wrong when I enable github action，please help me to find the problem，thanks


bug

Please note: An issue only reports one problem. If you have many probles, please create other issues
Please note: if you are going to feedback some unimportant bugs, please post in the discussion

FluentLauncher Bug Report :
FluentLauncher Version : 2.X.XX .
The main idea : What's wrong with the FL.
Is the game crash : yes/no
The Main Content :

Some annexs :

The importance of the bug is : (1-10 points)

wont let me play

wont let me play

What happened, tommycollingwood ?
Do you have any exact question  ?
Please give more information about why you cann't play ?
Such as Game Crash Error or Fluent Launcher Error .


Remove libc dependency

Coverage remained the same at 91.554% when pulling 2200a7d6d2d63f92ba065e490c040c8e27b6f947 on serprex:master into 7b08a0a5832c4900eb84bc5a9abfb258c1636f2e on kbknapp:master.

Oops I independently filed #886. Seems like you forgot some libc references in yours.


update dependencies to fix npm audit warning

fixes #67

Thanks for taking the time to help out with this, I'll update the dependencies as part of the next release which is tracked by this milestone: https://github.com/nickcolley/jest-axe/milestone/1

I've bumped all the dependencies and will do a release soon thanks for your help.


Implement preventDefault for events

Goal of this PR is to allow users to prevent default on the react navigation events.
React.useEffect(() => {
  const unsubscribe = navigation.addListener('tabPress', (e) => {
    // Prevent default behavior
    e.preventDefault();

    // Do something manually
    // ...
  });

  return unsubscribe;
}, [navigation]);

also for listeners props, we often dos something similar to this

Good news!
I've manged to get it working on iOS 🎉 cc: @gunnartorfis
https://github.com/user-attachments/assets/2c153f8d-28f1-4657-95ca-2c006ffa81a0

🔥🔥