Added support for entertainment api v2 (hue gradient strips)

Summary
This PR adds support for Philips hue entertainment API version 2. Version 1 of the API does not support the gradient light strip showing multiple colors of light. In the entertainment API v2, the concept of channels was introduced. This means that a hue light could have multiple channels (e.g the gradient light strip)and a channel could have multiple lights and it's these channels that are addressed when coloring the lights. This feature can be enabled as described in the attached image.

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] Feature
[ ] Code style update
[ ] Refactor
[ ] Docs
[ ] Build-related changes
[ ] Other, please describe:

If changing the UI of web configuration, please provide the before/after screenshot:
Before

** After **

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing setups:
The PR fulfills these requirements:

[x] This PR was brought about following this discussion here. https://github.com/awawa-dev/HyperHDR/discussions/469

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.
Other information:

Because a hue light can have multiple channels, the Power off on black has been removed when using API v2
Because a hue light can have multiple channels as well as a channel having multiple lights, the color space calculation has been removed. Also, its also documented by hue that if a color out of the color space of a light is selected, it resolves it to the closest color within its color space
Philips hue documentation https://developers.meethue.com/develop/hue-api-v2/migration-guide-to-the-new-hue-api/

Disclaimer
This is the first time I have programmed in c++ since the days of BlackBerry 10 OS. So if there are any issues, let me know.

Initial Tests show the V2 API working successfully, with some changes from the V1 API. When running the entertainment set up, lights no longer appear to be added to the list indiividually, appearing as quadrants.
.

As another note, it seems that the light ids no longer appear to match up to a single light. This may be because I have multiple gradient lights, but they seem to affect different zones instead of the individual lights. This makes placing light locations much more difficult.

You can blink the particular LED to identify it using this:

That's what I've been using to try to place them the best I can. The issue I'm having is that a single light id is affecting multiple separate lights. I'd 0 will blink my play strip, my gradient floor lamp, and table lamp.

I think for API v2 when settings the color for the lamp in the wizard, new format command should be used: httpX:///clip/v2/resource/light/ instead of API v1 httpX:///api//lights//state (it generates all behavior where the gradient strip is one lamp). And the passed json has also different format. @gibahjoe could you take a look?

That's what I've been using to try to place them the best I can. The issue I'm having is that a single light id is affecting multiple separate lights. I'd 0 will blink my play strip, my gradient floor lamp, and table lamp. As a result I can't separate each light segment into its own channel .

The only way that will happen is if you have multiple lights on the same channel.
Would you mind making an api call and sharing the response here? I can prepare it and send to you if you are interested.

Sure, happy to help. May take me a day or two to run it but I'm more than happy to.

Please make the below api calls on your terminal and share the response.
what is the name of the entertainment area you are trying to configure?
You can get the ip address and the username from the configuration page for the Philips Hue

curl --location --request GET 'https://{{HUE_IP_ADDRESS}}/clip/v2/resource/entertainment_configuration' \
--header 'hue-application-key: {{HUE_USERNAME}}'

curl --location --request GET 'https://{{HUE_IP_ADDRESS}}/clip/v2/resource/entertainment' \
--header 'hue-application-key: {{HUE_USERNAME}}'

~I think for API v2 when settings the color for the lamp in the wizard, new format command should be used: httpX://ipaddress/clip/v2/resource/light/[v2-id] instead of API v1 httpX://ipaddress/api/[appkey]/lights/[v1-id]/state (it generates old behavior where the gradient strip is one lamp). And the passed json has also different format.~
void LedDevicePhilipsHueV2::identify(const QJsonObject &params) in PR is rewritten so I also think it is a Philips Hue user configuration issue. @gibahjoe could you take a look?

I am on it

Running the commands with https gives me
root@LGwebOSTV:~# curl --location --request GET 'https:/(IP_Address)/clip/v2/resource/entertainment_configuration' --header 'hue-application-key: (HUE_KEY)'
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
removing https and placing http gets me

hue personal wireless lighting

Oops, there appears to be no lighting here

Did I do something wrong on the install?

HI, I added the insecure flag to ignore ssl. see updated commands below
curl --insecure --location --request GET 'https://{{HUE_IP_ADDRESS}}/clip/v2/resource/entertainment_configuration' \
--header 'hue-application-key: {{HUE_USERNAME}}'

curl --location --request GET 'https://{{HUE_IP_ADDRESS}}/clip/v2/resource/entertainment' \
--header 'hue-application-key: {{HUE_USERNAME}}'

@dbell669

Please make the below api calls on your terminal and share the response.
what is the name of the entertainment area you are trying to configure?
You can get the ip address and the username from the configuration page for the Philips Hue

curl --location --request GET 'https://{{HUE_IP_ADDRESS}}/clip/v2/resource/entertainment_configuration' \
--header 'hue-application-key: {{HUE_USERNAME}}'

curl --location --request GET 'https://{{HUE_IP_ADDRESS}}/clip/v2/resource/entertainment' \
--header 'hue-application-key: {{HUE_USERNAME}}'

Enertainment zone is called Game Zone. I am aslo getting the same messages with the --insecure tag.

Was able to get the files. Turns out I just needed to change the port to 443 in the curl command. Entertainment zone is called Game_Zone.
hue_output_Entertainment_Configuration.txt
hue_output_Entertainment.txt

You have multiple lights in a channel. I suspect this is due to how you positioned your lights in the entertainment configuration so there is some overlap.
This means that when you click that identification button, whichever device that lights  up have channels that will show the same color.
If you could send a screenshot of your game zone light placements from the hue app, that will help me confirm or disprove my hypothesis.
If I am correct about the above,
A workaround if you need full control (you don't want channels to be grouped) will be to create an entertainment area and place the lights in completely different locations where they won't overlap.
In the meantime, I will update this PR to identify channels instead of lights for v2 (only the channels will light up instead of the entire light).

Does that work?

It seems I have too many lights for the placement workaround to work. Is there a way to seperate the channels back to lights in the v2 api?.

Did you try placing them very far apart even towards the couch in the image above?
Please note that this issue you are experiencing is just for initial placement. Just complete the wizard, everything should work as usual. If the placements are off, you can correct this in the  "led layout" tab in HyperHDR.
Please try that and let us know the outcome.
I will update this PR so that it's just the channels (segments) of gradient strips/lamps that flash not the entire light/lamp. This should cause less confusion than flashing the entire device

If you complete the wizard and start syncing, what behavior do you experience?

Same as before unfortunately. Multiple lights light up when testing channels

@awawa-dev I just pushed up an update to the identify for v2 api. This update flashes the channels (segments) of a gradient strip for instance instead of the entire light. This should help with Identification. Please review
@dbell669 Please update to the latest push and let us know what you experience.

Hi @gibahjoe
Thanks for the update. I not a fan of initializing Philips Hue in the identify method but I understand it's necessary to make the  stream writes works: so if it solves the last problem and @dbell669 confirms it, I'm OK with that. I was thinking also about extending the late configuration phase and add blink to the context menu which was introduced here: https://github.com/awawa-dev/HyperHDR/pull/379 . The device should be already initialized then. In fact the 'blink' can be used even now by disabling a led in the context menu for a moment to identify it.

@awawa-dev
I will take a Look at that over the weekend.

Ok, no problem. There are two minor issues/warning when compiling on webOS:

I will convert spaces to tabs before merging anyway

Ok, no problem. There are two minor issues/warning when compiling on webOS:

I will convert spaces to tabs before merging anyway

I will clean this up too

So after applying the new version, I wasn't able to see much difference in the the led setup. The lights were still on multiple channels and could not be individually places. I noticed that actually testing the lights became more difficult as hitting the identify button would not blink the lights until I left the hue entertainment wizard

The channels alternate between red, blue, green. It might be difficult to notice if you have an active stream going on. Could you try agin and share your logs. Sorry for bothering you.

No problem at all. I'm happy to help if I can find a way to remove the sync box and put it somewhere else. I can get you the logs shortly. I do see them alternate between the three colors. I'm more worried about the lag at this point, but I can try without an active stream and see what I can get to you.

hue_identify_log.txt
Heres my log. let me know if you need anything else

I've also noticed that it now has random signal drops on occasion, but I dont know if its the blackbar detection or something else

The update seems to have made no change in the selection of lights. The channels are still hitting multiple lights. I guess the next thing i was going to look at was how my placement was working. should I be trying to place these in the context of an LED frame or by letting the config wizard handle it?

@dbell669 as you can see a warning you have enabled grouping in the LED strip configuration. So light no. 1 and no. 2 are sharing the same color and is affecting the testing for sure. You can correct it in applying the same group setting attribute as it's shown on the following screenshot. The question is how this setting was activated? Did you edited the LED strip configuration manually? Make sure the warning about grouping disappears after your changes.

@dbell669 could you check your build version 'advanced->about->system report->build Now when you click the 'identify button' you should see a sequence of: red, green, blue colors in the interval of 1 second. Do you confirm such behavior?

@gibahjoe if there is a collection in devicesId could it send the command to the whole group despite you have rewritten the identify method to use the stream?

The compiler warnings are fixed now, restored formatting in ProviderRestApi.cpp and added a check for a group to be not included when Entertainment API is disabled.

OK. I fixed the grouping, now it looks like

group config.txt
There is an issue when hitting the identify buttons on the lights. they seem to crash the hyperhdr UI and make navigation unusable. it seems to come back after a few secons, and most of the time it will identify itself with the R/B/G sequence after it recovers. This makes the hue wizard basically unusable on my end. The initial method of having them blink blue worked. I believe my initial issue with identification stemmed from the lights sharing channels.  Is there a way to seperate the channels back into their own lights, or is this a consequence of the move to the v2 api?
System Version
master (awawa-dev-3502af9/6ebbb93-1674302206)

Thanks for the feedback: probably the main thread is taking too much time to send 'identify' messages to lamps (because now we initialize Philips Hue fully then) so the websocket from UI thinks that it's down because it is not responding in time or HyperHDR is crashing and the service is bringing it back (but I'm not sure if it works that way on webos, rather e.g. for systemd on Rpi).
Did you have Philips Hue instance working (sending colors stream) before you ran the wizard now? If so try to disable it first in the remote tab and then run the wizard when everything stops to work.

I had philips hue working  and sending colors before the push that started to use the red blue green flashing. even with it disabled in the remote tab its still not handling the flash action well. it wont seem to send them until after I close the wizard. So I can set locations, but trying to ping them does not work.

Hi, sorry I had a busy weekend. @dbell669 using channels is a consequence of api v2 but what I don't know is why the philips hue system has added multiple lights to one channel. I have tried escalating to their team but I am not getting any feedback. Is it possible you grouped the lights somehow (either using third party apps etc)? My setup has 1 gradient strip and a few bulbs so it's just guesswork at this point. As for the lag issue with identify, I will further optimize that. Expect an update soon.

@awawa-dev
Taking a look at the last log sent by @dbell669  (relevant parts below), the initialization does not seem to be the problem
2023-01-20T18:14:47.441Z [WEBSOCKET] (JsonAPI.cpp:1630) message: [{"command":"leddevice","ledDeviceType":"philipshuev2","params":{"channelId":9,"clientkey":"166714F14535C644BF55E371CE4965E4","entertainmentConfigurationId":"14b3d2fa-d52f-4025-bf05-fc54000eda39","host":"<IP_ADDRESS>:443","user":"hK-3rTHmCqTKkr5B3n1VTWSdVC7W4ewrr5ZgIlQf"},"subcommand":"identify","tan":1}]
2023-01-20T18:14:47.441Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:1355) params: [{"channelId":9,"clientkey":"166714F14535C644BF55E371CE4965E4","entertainmentConfigurationId":"14b3d2fa-d52f-4025-bf05-fc54000eda39","host":"<IP_ADDRESS>:443","user":"hK-3rTHmCqTKkr5B3n1VTWSdVC7W4ewrr5ZgIlQf"}]
2023-01-20T18:14:47.442Z [LEDDEVICE] (ProviderRestApi.cpp:170) GET begin: [https://<IP_ADDRESS>:443/auth/v1] []
2023-01-20T18:14:47.447Z [LEDDEVICE] (ProviderRestApi.cpp:191) GET end (5 ms): [https://<IP_ADDRESS>:443/auth/v1] []
2023-01-20T18:14:47.448Z [LEDDEVICE] (ProviderRestApi.cpp:310) Reply.httpStatusCode [200]
2023-01-20T18:14:47.448Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:515) Application ID is 3a91a748-d600-4a22-b471-f884d0d1fb01
2023-01-20T18:14:47.448Z [LEDDEVICE_PHILIPSHUEV2] (LedDevice.cpp:168) deviceConfig: [{"host":"<IP_ADDRESS>","hs_attempts":5,"hs_timeout_max":2000,"hs_timeout_min":600,"psk":"166714F14535C644BF55E371CE4965E4","psk_identity":"hK-3rTHmCqTKkr5B3n1VTWSdVC7W4ewrr5ZgIlQf","refreshTime":20,"retry_left":60,"seed_custom":"dtls_client","servername":"Hue","sslport":2100,"type":"philipshuev2"}]
2023-01-20T18:14:47.448Z [LEDDEVICE_PHILIPSHUEV2] (LedDevice.cpp:222) Refresh interval = 20ms
2023-01-20T18:14:47.448Z [LEDDEVICE_PHILIPSHUEV2] (LedDevice.cpp:197) Device is not ready to start a timer
2023-01-20T18:14:47.448Z [LEDDEVICE_PHILIPSHUEV2] (LedDevice.cpp:232) RefreshTime updated to 20ms
2023-01-20T18:14:47.448Z [LEDDEVICE_PHILIPSHUEV2] (ProviderUdpSSL.cpp:122) Successfully parsed <IP_ADDRESS> as an ip address.
2023-01-20T18:14:47.448Z [LEDDEVICE_PHILIPSHUEV2] (ProviderUdpSSL.cpp:153) UDP SSL using <IP_ADDRESS>:2100
2023-01-20T18:14:47.448Z [LEDDEVICE_PHILIPSHUEV2] Channel ID 9 ("", LED index "9") created
2023-01-20T18:14:47.448Z [LEDDEVICE] (ProviderRestApi.cpp:170) GET begin: [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] []
2023-01-20T18:14:47.481Z [LEDDEVICE] (ProviderRestApi.cpp:191) GET end (33 ms): [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] []
2023-01-20T18:14:47.482Z [LEDDEVICE] (ProviderRestApi.cpp:310) Reply.httpStatusCode [200]
2023-01-20T18:14:47.484Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:352) Group state                   : {"channels":[{"channel_id":0,"members":[{"index":0,"service":{"rid":"d0563cd5-1225-48b9-abbf-92d053fc55d9","rtype":"entertainment"}},{"index":0,"service":{"rid":"92fd41bb-9c1c-487e-8d90-4510b9b24c48","rtype":"entertainment"}},{"index":2,"service":{"rid":"5501ca92-e622-4ec3-867b-27546a8e61cf","rtype":"entertainment"}},{"index":6,"service":{"rid":"d6fe9cdb-9c12-4f17-9ef2-401fbf548f2f","rtype":"entertainment"}}],"position":{"x":0.4,"y":0.8,"z":-0.4}},{"channel_id":1,"members":[{"index":1,"service":{"rid":"d0563cd5-1225-48b9-abbf-92d053fc55d9","rtype":"entertainment"}},{"index":1,"service":{"rid":"92fd41bb-9c1c-487e-8d90-4510b9b24c48","rtype":"entertainment"}},{"index":5,"service":{"rid":"d6fe9cdb-9c12-4f17-9ef2-401fbf548f2f","rtype":"entertainment"}}],"position":{"x":0.4,"y":0.8,"z":0}},{"channel_id":2,"members":[{"index":0,"service":{"rid":"385e5a28-cc18-4283-90d9-27f755e49d18","rtype":"entertainment"}},{"index":0,"service":{"rid":"722b1dec-d270-41f3-8a74-ff56e3bc104d","rtype":"
2023-01-20T18:14:47.484Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:352) Stream status                 : inactive
2023-01-20T18:14:47.484Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:847) Start entertainment stream
2023-01-20T18:14:47.484Z [LEDDEVICE] (ProviderRestApi.cpp:170) PUT begin: [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] [{"action":"start"}]
2023-01-20T18:14:47.611Z [LEDDEVICE] (ProviderRestApi.cpp:191) PUT end (127 ms): [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] [{"action":"start"}]
2023-01-20T18:14:47.611Z [LEDDEVICE] (ProviderRestApi.cpp:310) Reply.httpStatusCode [200]
2023-01-20T18:14:47.611Z [LEDDEVICE] (ProviderRestApi.cpp:170) GET begin: [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] []
2023-01-20T18:14:47.645Z [LEDDEVICE] (ProviderRestApi.cpp:191) GET end (34 ms): [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] []
2023-01-20T18:14:47.645Z [LEDDEVICE] (ProviderRestApi.cpp:310) Reply.httpStatusCode [200]
2023-01-20T18:14:47.647Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:352) Group state                   : {"active_streamer":{"rid":"3a91a748-d600-4a22-b471-f884d0d1fb01","rtype":"auth_v1"},"channels":[{"channel_id":0,"members":[{"index":0,"service":{"rid":"d0563cd5-1225-48b9-abbf-92d053fc55d9","rtype":"entertainment"}},{"index":0,"service":{"rid":"92fd41bb-9c1c-487e-8d90-4510b9b24c48","rtype":"entertainment"}},{"index":2,"service":{"rid":"5501ca92-e622-4ec3-867b-27546a8e61cf","rtype":"entertainment"}},{"index":6,"service":{"rid":"d6fe9cdb-9c12-4f17-9ef2-401fbf548f2f","rtype":"entertainment"}}],"position":{"x":0.4,"y":0.8,"z":-0.4}},{"channel_id":1,"members":[{"index":1,"service":{"rid":"d0563cd5-1225-48b9-abbf-92d053fc55d9","rtype":"entertainment"}},{"index":1,"service":{"rid":"92fd41bb-9c1c-487e-8d90-4510b9b24c48","rtype":"entertainment"}},{"index":5,"service":{"rid":"d6fe9cdb-9c12-4f17-9ef2-401fbf548f2f","rtype":"entertainment"}}],"position":{"x":0.4,"y":0.8,"z":0}},{"channel_id":2,"members":[{"index":0,"service":{"rid":"385e5a28-cc18-4283-90d9-27f755e49d18","rtype":"entertainm
2023-01-20T18:14:47.647Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:352) Stream status                 : active
2023-01-20T18:14:47.647Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:852) The stream has started.
2023-01-20T18:14:48.257Z [LEDDEVICE_PHILIPSHUEV2] Philips Hue Entertaiment API successful connected! Start Streaming.
2023-01-20T18:14:51.293Z [LEDDEVICE_PHILIPSHUEV2] Release mbedtls
2023-01-20T18:14:51.293Z [LEDDEVICE] (ProviderRestApi.cpp:170) PUT begin: [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] [{"action":"stop"}]
2023-01-20T18:14:51.397Z [LEDDEVICE] (ProviderRestApi.cpp:191) PUT end (104 ms): [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] [{"action":"stop"}]
2023-01-20T18:14:51.397Z [LEDDEVICE] (ProviderRestApi.cpp:310) Reply.httpStatusCode [200]
2023-01-20T18:14:51.397Z [LEDDEVICE] (ProviderRestApi.cpp:170) GET begin: [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] []
2023-01-20T18:14:51.419Z [LEDDEVICE] (ProviderRestApi.cpp:191) GET end (21 ms): [https://<IP_ADDRESS>:443/clip/v2/resource/entertainment_configuration/14b3d2fa-d52f-4025-bf05-fc54000eda39] []
2023-01-20T18:14:51.420Z [LEDDEVICE] (ProviderRestApi.cpp:310) Reply.httpStatusCode [200]
2023-01-20T18:14:51.422Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:352) Group state                   : {"channels":[{"channel_id":0,"members":[{"index":0,"service":{"rid":"d0563cd5-1225-48b9-abbf-92d053fc55d9","rtype":"entertainment"}},{"index":0,"service":{"rid":"92fd41bb-9c1c-487e-8d90-4510b9b24c48","rtype":"entertainment"}},{"index":2,"service":{"rid":"5501ca92-e622-4ec3-867b-27546a8e61cf","rtype":"entertainment"}},{"index":6,"service":{"rid":"d6fe9cdb-9c12-4f17-9ef2-401fbf548f2f","rtype":"entertainment"}}],"position":{"x":0.4,"y":0.8,"z":-0.4}},{"channel_id":1,"members":[{"index":1,"service":{"rid":"d0563cd5-1225-48b9-abbf-92d053fc55d9","rtype":"entertainment"}},{"index":1,"service":{"rid":"92fd41bb-9c1c-487e-8d90-4510b9b24c48","rtype":"entertainment"}},{"index":5,"service":{"rid":"d6fe9cdb-9c12-4f17-9ef2-401fbf548f2f","rtype":"entertainment"}}],"position":{"x":0.4,"y":0.8,"z":0}},{"channel_id":2,"members":[{"index":0,"service":{"rid":"385e5a28-cc18-4283-90d9-27f755e49d18","rtype":"entertainment"}},{"index":0,"service":{"rid":"722b1dec-d270-41f3-8a74-ff56e3bc104d","rtype":"
2023-01-20T18:14:51.422Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:352) Stream status                 : inactive
2023-01-20T18:14:51.422Z [LEDDEVICE_PHILIPSHUEV2] (LedDevicePhilipsHueV2.cpp:895) The stream has stopped
2023-01-20T18:14:55.309Z [WEBSOCKET] (JsonAPI.cpp:1250) log streaming activated for client ::ffff:<IP_ADDRESS>

Also attaching an image incase the above does not display properly

The time taken for the identify to begin (when the command is received from the front end) and when the stream is stopped takes about 4 seconds (note that this also includes the 1 second cycling of RGB). There has to be something else at play here for the lag.
@dbell669 Could you confirm what device hyperhdr is running on?

I had philips hue working  and sending colors before the push that started to use the red blue green flashing. even with it disabled in the remote tab its still not handling the flash action well. it wont seem to send them until after I close the wizard. So I can set locations, but trying to ping them does not work.

Sorry. Which remote tab are you referring to?

I was thinking about disabling the 'LED device', not USB grabber. On webos USB support is disabled and that button does nothing.

yep that did it. turning off LED device made it update and identify in a much quicker manner.

It gets trickier if user enabled the light device before running the wizard. Maybe it would be simpler to run just two json commands (they are already available) from JS wizard before displaying the dialog with Philips lamps at the end to 1) enable a color (black?) as an effect to have a video source for sure 2) turn the Philips Hue on (Led device component for the instance which is already configured and saved) which enables the streaming. And in Identify method do not initialize Philips Hue again but only check the status _isOn and if it's OK then write colors to the stream.

To consider:
// clear current effect, should be called also on exit
requestPriorityClear();
// set color
setTimeout(function(){
	// rgb and duration: 0 = inf.
	requestSetColor(255, 255, 0, 0);
}, 100);
// turn on led device if disabled
requestSetComponentState('LEDDEVICE',true);

It gets trickier if user enabled the light device before running the wizard. Maybe it would be simpler to run just two json commands (they are already available) from JS wizard before displaying the dialog with Philips lamps at the end to 1) enable a color (black?) as an effect to have a video source for sure 2) turn the Philips Hue on (Led device component for the instance which is already configured and saved) which enables the streaming. And in Identify method do not initialize Philips Hue again but only check the status _isOn and if it's OK then write colors to the stream.

There are some use cases this approach would not cover.

user does not have an existing configuration saved (in which case current identify in this PR covers)
user has an existing configuration saved but is updating the configuration by changing the group ID or even the bridge (the identify would go to the old configuration)

Also, the identify in this PR is using a new instance of the Leddevice I believe so the _isOn variable would not be shared. Isnt that the case?
else if (subc == "identify")
		{
			ledDevice = LedDeviceFactory::construct(config);
			const QJsonObject& params = message["params"].toObject();
			ledDevice->identify(params);

			sendSuccessReply(full_command, tan);
		}

The Approach I was trying to take was to detect in the identify method if there is an active stream, pause it, perform the identification and then resume it. But the instances of the leddevice are different so still struggling with that.

To consider:
// clear current effect, should be called also on exit
requestPriorityClear();
// set color
setTimeout(function(){
	// rgb and duration: 0 = inf.
	requestSetColor(255, 255, 0, 0);
	// turn on led device if disabled
        requestSetComponentState('LEDDEVICE',true);
}, 100);

This most definitely will work for identify(blink) in the led layout tab

Also, the identify in this PR is using a new instance of the Leddevice I believe so the _isOn variable would not be shared. Isnt that the case?

Yes, I will test if we could use final user instance. For initialization in Identify there are more potential problems like UDP stream handler and some Philips Hue routines has some autoresume mechanisms which may cause problems with overall HyperHDR state when something goes wrong during transmission in Identify (or if new Identify instance disrupts the user instance if it was running before: cascade of autoresumes), because it was not design for such operation either.

I've modified the code to use the LED instance when API v2 is used (tested with small tweak only with v1). If you could test if it works in 2 scenarios: there is other LED device (eg. debug/file, press F5 in browser to make sure it's an actual server configuration) configured before running Philips Hue wizard  or there is already configured Philips Hue and it's running but we want to run the wizard again. $('#btn_wiz_save').click(); in wizard probably should be better guarded to run it only once after the dialog with 'Identify' buttons is shown.

Will take a look.
I have pushed up adding an identify to led layout tab.
Now, this is expected to work with other led devices please take a look. I had to update the signature of some other files. I am happy to change it if you have any issues

As far as global signals go, I don't plan any changes there just for the single API method which doesn't need to be propagated further than the single instance: just add new method to the HyperHdrInstance  to set some new properties like index of the LED to blink and timeout (please use internal timers, you have direct communication from JsonAPI/API to HyperHdrInstance each running on different thread, preferably set new properties asynchronously instead of the blocking invoke) and later include them both in HyperHdrInstance ->updateResult processing which already includes similar solution for disabled LEDs.

I think to use new identifyLed from HyperHdrInstance  for that purpose.

This line 	$('#btn_wiz_save').click(); uses the wizard to close prematurely. Once I click on Identify, the wizard closes and reloads the page. Sometimes, the application recovers properly, sometimes it shows a blank page and I have to restart it. Either way, I am unable to identify from the wizard
I tested out the identify you just pushed and it works well on v2.
If I comment out the line above, I am able to identify only if I have an existing Philips hue v2 configuration and I select the same entertainment configuration (group).
I also made some adjustments to workaround the lightscount errors.
I think a combination of this and the other one that initialized the UDP connection in identify should give us a working solution.

This line $('#btn_wiz_save').click(); causes the wizard to close prematurely. Once I click on Identify, the wizard closes and reloads the page. Sometimes, the application recovers properly, sometimes it shows a blank page and I have to restart it. Either way, I am unable to identify from the wizard

Thanks for the fix. This need to be investigates further in such case, cant reproduce it on my system...maybe some differences between our configurations and I tested it for API v1 (moved that part to v1 section in same function and changed caller id for the Identify) I will take a  look tomorrow. Which browser do you use and did you edit existing and working Philips Hue instance?

OK, I think I have fixed it.

Any other tests needed from my end before I start tinkering with the other types of led strips?

@dbell669  it would be great if you could test again newest version. Beside changed 'identify' button in the wizard there is also a new 'identify' button in the context menu (https://github.com/awawa-dev/HyperHDR/pull/379). Try both if they work fine for your setup.

I have confirmed they both work for my setup

Yes, but @dbell669's configuration is/was more problematic and started these numerous changes in the wizard ;) It would be good to know the final result.

Ok. Just tested. It seems like the lag issues on identification are gone, and the identify button in the led layout page works well.

Thanks @dbell669 for the feedback. @gibahjoe I refactored the code reducing shared code between 2 Philips Hue classes (finally ~550 new lines instead of ~1700 in single class, it will be easier for me in future to maintain that driver) and fixed some minor issues e.g. saving/restoring state when V2 is used. You've done a really great job 👍 I have reviewed and refactored all the code and have no plans to make any further changes on my part. I'm wondering whether to include this PR in v19 and in the upcoming v20. I freeze v19beta2 ahead of final release, but we still have some time to test this PR. What do you think?

Thank you. I think releasing earlier rather than later is better so we can get feedback from a wide range of users. So, v19.

works really good for me, thanks!
is there a definitive go-to layout for the gradient? I'm seeing mismatches to the zone alignment and seem to not be able to make the top corner zones as wide as they really are.
maybe I'm doing something stupid here
https://imgur.com/a/6oRXYS1

@gotschi did you try to use the context menu later in the LED layout designer to correct it later? You can resize them and change their position as you want. Usage: https://github.com/awawa-dev/HyperHDR/pull/379 In the wizard where you configure the hue options, the options are limited. I can add later few predefined lamps but I must now their size/location...beside the list is long and it's hard to find a proper element already.

oh yes, changing the values in the properties menu works, I think it glitched out earlier for me
awesome! thanks

@gibahjoe I post a short post on my blog for each version. May I use your photos in the description of the API v2 feature that you implemented in version 19?

@awawa-dev Yes that's fine. Sorry just saw this.


feat(*): rename to @mixer/client-node

@ProbablePrime be sure to run the deprecation command on npm for beam-client-node after this has been published!

After E3, just in case we need to hotfix this during the event


Visual bugfixes and unexpected error

DRAFT for VISIBILITY and DISCUSSION
Changes

Adds modified date to CollectionLinks (which might need to be renamed to CollectionListItems?)
Adds client title to list item if available (ie, project list)
Adds .form-select instead of .form-control in order to get a bootstrap <select> to show the little down arrow
Adds NavLink instead of Link from react-router. This allows main menu items to be .active` on partial path matches (ie subpages)
Add some minor tweaks in custom.css (padding, hover, etc)

enhanced list
dropdown
main menu highlight

Question
I wanted to experiment with adding the new resource [client, person or project] form component on the list page (see Projects page).   The action succeeds, however, this throws an error in in the useNewResource hook.  @evert  I'm curious if that's expected to happen in this case.

Ah interesting! Exceptions should never be thrown in hooks so this looks like a bug in useNewResource


Monitor connection broken from 4e3ac

I have been iterating on a machine config for a bit and about a week ago I noticed my mpf monitor was no longer displaying the swtiches and leds I had mapped on it. After a closer look this evening, I found I could get the monitor working through commit 60fe0 as shown:

However, the immediate next commit of 4e3ac produces BCP errors:

Hope this helps to pin it down!

The center tmux pane is after running mpf both -X if that's not clear from the screenshots.

Seems to be resolved after getting all Repos pointing to the dev branches per q-dog suggestion on Slack.


This PR adds the option to run the produced gltf export through gltfpack with various options

Hi there,
Juan and I thought of extending this plugin with the option to run the exported glTF through the tool gltfpack (aka meshoptimizer).
By default gltfpack outputs regular .glb/.gltf files that have been optimized for GPU consumption using various cache optimizers and quantization and can also compress textures using Basis Universal format stored in a KTX2 container.
gltfpack will output to a subfolder gltfpacked in the folder you exported the glTF to.
For the plugin to be able to run the originally exported glTF, you need to have gltfpack installed on your system somewhere and configure its path in the plugin preferences, then gltfpack relevant options will also appear in the export dialog, where you can also decide if you want to make use of gltfpack or not, among the options you can pass through that tool.
Any feedback is welcome

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: deccer:x: JuanDiegoMontoyaYou have signed the CLA already but the status is still pending? Let us recheck it.

(And you should rebase with main branch, as I fixed some bugs after recent changes in Blender)

Thank you for taking a look :)

Hello,
Can you please rebase with main?
I will merge it soon

Thanks @donmccurdy to point it
I will propose a PR soon


Cannot compile due to incorrect libpq version

Since a few days ago, I can no longer compile with cargo lambda build --release --arm64
It seems like it's an issue with an internal library I have built as a diesel PostgreSQL connection.
It fails when I compile with cargo with the following errors:
  = note: warning: unsupported linker arg: -znoexecstack
          warning: unsupported linker arg: -zrelro
          warning: unsupported linker arg: -znow
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-auth-scram.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-connect.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-exec.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-lobj.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-misc.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-print.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-protocol3.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-secure.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-trace.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'legacy-pqsignal.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'libpq-events.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'pqexpbuffer.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-auth.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-secure-common.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-secure-openssl.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-gssapi-common.o' is neither ET_REL nor LLVM bitcode
          ld.lld: warning: /opt/homebrew/opt/libpq/lib/libpq.a: archive member 'fe-secure-gssapi.o' is neither ET_REL nor LLVM bitcode
          ld.lld: error: undefined symbol: PQresultStatus
          >>> referenced by result.rs:29 (src/pg/connection/result.rs:29)
          >>>               diesel-07255079c869e3c3.diesel.8914a008-cgu.6.rcgu.o:(diesel::pg::connection::result::PgResult::new::h6ce2334735c291c9) in archive /Users/abraxas/code/memoir/connectors/memoir-connector-telegram/target/aarch64-unknown-linux-gnu/debug/deps/libdiesel-07255079c869e3c3.rlib

          ld.lld: error: undefined symbol: PQnfields
          >>> referenced by result.rs:34 (src/pg/connection/result.rs:34)

I have tried to compile it through he docker image, giving the following errors:
rust_compile-rust_compiler-1  |   = note: warning: unsupported linker arg: -znoexecstack
rust_compile-rust_compiler-1  |           warning: unsupported linker arg: -zrelro
rust_compile-rust_compiler-1  |           warning: unsupported linker arg: -znow
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-auth-scram.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-connect.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-exec.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-lobj.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-misc.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-print.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-protocol2.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-protocol3.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-secure.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(legacy-pqsignal.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(libpq-events.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(pqexpbuffer.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-auth.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-secure-common.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-secure-openssl.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-gssapi-common.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |           ld.lld: error: /usr/lib/x86_64-linux-gnu/libpq.a(fe-secure-gssapi.o) is incompatible with aarch64linux
rust_compile-rust_compiler-1  |
rust_compile-rust_compiler-1  |

I have libpq v 15 installed, the only one available in Homebrew.
The failing dep is :
diesel = { version = "2.0.3", features = ["postgres", "uuid", "chrono", "serde_json", "libc"] }
I could compile this last week without any issues.

Ok, thank you for the reply.
So you are saying I can't use diesel for any cargo-lambda project?

Ok, thank you.
I'll go back and try to figure out why this would compile without issues a few days ago.
I'll close this issue now, thank you for your help

Ok.
Thank you so much for your help.


Fix error in split function

if protocol params dont be string type it provide a syntax error

The crash is expected if the function is called with a protocol argument that is not a string.

Thank you anyway.

Yes, I figured it, but with this manner is easier for to find the error. When crash happened the error was invisible for me in the first time and after this fix the error show us clearly in console.
I appreciate your consideration! Tks


blockdev: Use --direct-io=on for losetup

This is what other projects do; it avoids double buffering and is generally a good idea.

Ah gotcha.  My English parser is buggy :laughing:

Yeah, the code in https://github.com/util-linux/util-linux/blob/master/sys-utils/losetup.c#L687 also indicates the default is "off". But this is super nice, we will try this for osbuild too.


setting width from math glyph

as this is an internal method it should actually check the width from the math glyph
I dont have a good direct solution... only it maybe should not fail hard on negative widths as those are required in an intermediate  calculation...
https://github.com/robofab-developers/fontParts/blob/master/Lib/fontParts/base/glyph.py#L1466

the ufo spec does not mention that a negative width is not supported
maybe the validator should not check on negative glyph.width
http://unifiedfontobject.org/versions/ufo3/glyphs/glif/#advance
I understand that binary fonts at the end needs this but UFO is a source format and this is useful to be able to store or even generate in memory (fe in an interpolation and some glyph math)

I agree

removed in
https://github.com/robofab-developers/fontParts/commit/f2739eee9af9070205d28ecd17a76e9f32c63ff6
https://github.com/robofab-developers/fontParts/commit/9834de217347b3f17eb00ef2ce5c2f37d5f1cd91

Also agree.

the same thing applies for glyph.height


Remove docker build step in favor of using the default image

Changes

Dockerfile & docker build is removed from the action
Action scripts changed to be a volume in the container itself
Entry script is passed as a param to docker run command

Checklist

[x] Read the contribution guide and accept the code of conduct
[x] Readme (updated or not needed)
[x] Tests (added, updated or not needed)

Most of these changes are already in, updating the dependencies.
I'm not really sure if removing the build command really solves something here. 30 seconds is nice, but the code becomes less explicit, as part now assumes the steps are in a mounted folder, which makes the image incomplete before runtime.
While I applaud the effort to speed up and improve the build time, I do not feel great about merging it. Closing for now.

Most of these changes are already in, updating the dependencies.
I'm not really sure if removing the build command really solves something here. 30 seconds is nice, but the code becomes less explicit, as part now assumes the steps are in a mounted folder, which makes the image incomplete before runtime.
While I applaud the effort to speed up and improve the build time, I do not feel great about merging it. Closing for now.

Honestly don't understand what's bothering you. My reasons for this change:

Github is not utilizing cache for docker, so basically every time build happens from very scratch and taking quite a time.
The image itself is useless - it's basically the same image with a few additional files (which can be mapped through volume) and command over it. There is no reason to have a docker image because nobody can reuse it anyhow.
Overall I think that this change reducing code complexity since the whole step is removed. Yes the run command is starting to be more complex, but it is one command, you don't have to go across the code to find out what will be executed in the container.

Honestly don't understand what's bothering you. My reasons for this change:

Github is not utilizing cache for docker, so basically every time build happens from very scratch and taking quite a time.
The image itself is useless - it's basically the same image with a few additional files (which can be mapped through volume) and command over it. There is no reason to have a docker image because nobody can reuse it anyhow.
Overall I think that this change reducing code complexity since the whole step is removed. Yes the run command is starting to be more complex, but it is one command, you don't have to go across the code to find out what will be executed in the container.

Honestly don't understand what's bothering you.

Nothing is bothering me. I'm one of the maintainers of the project and as such responsible for the quality of the project.

Github is not utilizing cache for docker, so basically every time build happens from very scratch and taking quite a time.

This PR doesn't actually make GitHub use cache for docker more than it is now. Please note that the build command only builds a single layer, which isn't really heavy at all.

The image itself is useless - it's basically the same image with a few additional files (which can be mapped through volume) and command over it. There is no reason to have a docker image because nobody can reuse it anyhow.

Respectfully disagree, the Dockerfile is an explicit definition of what the docker image looks like, which helps developers understand what's happening. This becomes harder if thing implicitly work though mounting it. Which could be worth it if real time is saved but 30 seconds on a 30+ minutes build isn't a real concern.

Overall I think that this change reducing code complexity since the whole step is removed. Yes the run command is starting to be more complex, but it is one command, you don't have to go across the code to find out what will be executed in the container.

Less commands isn't necessarily better. If anything the repository becomes more complex by this change and it doesn't add any real value, making merging it mostly a risk. I'm sorry your contribution couldn't be merged.

Honestly don't understand what's bothering you.

Nothing is bothering me. I'm one of the maintainers of the project and as such responsible for the quality of the project.

Github is not utilizing cache for docker, so basically every time build happens from very scratch and taking quite a time.

This PR doesn't actually make GitHub use cache for docker more than it is now. Please note that the build command only builds a single layer, which isn't really heavy at all.

The image itself is useless - it's basically the same image with a few additional files (which can be mapped through volume) and command over it. There is no reason to have a docker image because nobody can reuse it anyhow.

Respectfully disagree, the Dockerfile is an explicit definition of what the docker image looks like, which helps developers understand what's happening. This becomes harder if thing implicitly work though mounting it. Which could be worth it if real time is saved but 30 seconds on a 30+ minutes build isn't a real concern.

Overall I think that this change reducing code complexity since the whole step is removed. Yes the run command is starting to be more complex, but it is one command, you don't have to go across the code to find out what will be executed in the container.

Less commands isn't necessarily better. If anything the repository becomes more complex by this change and it doesn't add any real value, making merging it mostly a risk. I'm sorry your contribution couldn't be merged.


refactor: replace execa w/ ezspawn

I first encountered the package @jsdevtools/ez-spawn through bumpp, which uses exspawn under the hood.
Though no longer being actively maintained, ezspawn already fulfills almost every use case and doesn't suffer from breaking bugs.
@jsdevtools/ez-spawn has fewer dependencies than execa and takes up only 47% of the disk space (the installation size of @jsdevtools/ez-spawn is 142 KiB compared to execa at 301 KiB). Moreover, its usage is extremely straightforward. Unlike execa, which has separated execa and execCommand, ezspawn's single method can perform both functions.

This cli tool do not need third-party package to execute command. Just use childProcess.execSync is enough.
import childProcess from "node:child_process";
const config= JSON.parse(
  childProcess.execSync(`echo '{"hello":"world"}'`).toString("utf8"),
);
console.log(config); // {hello: 'world'}


importing numutils from cooltools

Running: Python 3.7.1; conda 4.6.9; cooler 0.7; cooltools 0.1.0
Hi, really excited about coolpup.py but having some issues getting it going. Installs fine, but when I call the --help command I get some errors
Traceback (most recent call last):   File "/data/demmerlejt/conda/envs/02_coolpuptest/bin/coolpup.py", line 6, in <module>     from coolpuppy.__main__ import main   File "/data/demmerlejt/conda/envs/02_coolpuptest/lib/python3.7/site-packages/coolpuppy/__init__.py", line 1, in <module>     from .coolpup import *   File "/data/demmerlejt/conda/envs/02_coolpuptest/lib/python3.7/site-packages/coolpuppy/coolpup.py", line 23, in <module>     from cooltools import numutils ImportError: cannot import name 'numutils' from 'cooltools' (/data/demmerlejt/conda/envs/02_coolpuptest/lib/python3.7/site-packages/cooltools/__init__.py)
When I go look at the cooltools init.py file, there is no "numutils" in it. It reads only
from .consul import Consul from .redshift import Redshift from .slack import Slack
However, in the cooltools guthub the equivalent file imports '.lib' and then imports numutils from .lib, which can be seen here https://github.com/mirnylab/cooltools/blob/master/cooltools/init.py
So, not sure why these are different, but should I change them manually, or am I installing something incorrectly? If so, any ideas on how to fix it?
Also, I tried installing both the pip cooltools and via the https://github.com/mirnylab/cooltools/archive/master.zip link, and it didn't make a difference.
Thanks in advance for your help,
Justin

Hi, I can have a more careful look at this tomorrow, but you definitely
want cooltools from mirnylab github - the ones on pypi are unrelated and
will hopefully be soon replaced by the right ones. Pleas make sure it's
properly installed from github, it should work then, let me know of it
doesn't!
Ilya
On Wed, 3 Apr 2019, 23:23 Justin Demmerle<EMAIL_ADDRESS>wrote:

Running: Python 3.7.1; conda 4.6.9; cooler 0.7; cooltools 0.1.0
Hi, really excited about coolpup.py but having some issues getting it
going. Installs fine, but when I call the --help command I get some errors
Traceback (most recent call last): File
"/data/demmerlejt/conda/envs/02_coolpuptest/bin/coolpup.py", line 6, in
 from coolpuppy.main import main File
"/data/demmerlejt/conda/envs/02_coolpuptest/lib/python3.7/site-packages/coolpuppy/init.py",
line 1, in  from .coolpup import * File
"/data/demmerlejt/conda/envs/02_coolpuptest/lib/python3.7/site-packages/coolpuppy/coolpup.py",
line 23, in  from cooltools import numutils ImportError: cannot
import name 'numutils' from 'cooltools'
(/data/demmerlejt/conda/envs/02_coolpuptest/lib/python3.7/site-packages/cooltools/init.py)
When I go look at the cooltools init.py file, there is no "numutils" in
it. It reads only
from .consul import Consul from .redshift import Redshift from .slack
import Slack
However, in the cooltools guthub the equivalent file imports '.lib' and
then imports numutils from .lib, which can be seen here
https://github.com/mirnylab/cooltools/blob/master/cooltools/__init__.py
So, not sure why these are different, but should I change them manually,
or am I installing something incorrectly? If so, any ideas on how to fix it?
Also, I tried installing both the pip cooltools and via the
https://github.com/mirnylab/cooltools/archive/master.zip link, and it
didn't make a difference.
Thanks in advance for your help,
Justin
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Phlya/coolpuppy/issues/4, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACwsusb18oj2N8GF8_kte-kgyu55Tg4vks5vdSnpgaJpZM4cbjtE
.

Closing this, feel free to reopen if you still have a problem.


Reference block

Read the reference block information on packets. Expose it also via an appropriate nestegg_packet function.

Thanks, this looks good.


add launchsettings to git ignore and update the default launchsetting

Problem
launchSettings.json should be something developer can override and not worry about accidentally commit.
Solution
Add launchSettings.json file to gitignore
Fix default launchSettings for Virtual Assistant to be the same as the bot file.

#118

Lauren mentioned that if we don't have the launchSettings file under source control, it would be generated with a random port which is different from the deployment script which will make developer's local run fail. We should still keep this file and just be sure to not include it in any changes. You can always add changes on top of it to override any settings locally.


[Feature Request]: ITMS-91061: Missing privacy manifest

Is there already an issue requesting this feature?

[X] I have searched the existing issues.

Please select affected platform(s)

[ ] Android
[X] iOS
[ ] Linux
[ ] macOS
[ ] Web
[ ] Windows

Use case
Apple's latest official review requirements mandate that SDKs must include a privacy manifest, otherwise the app will not be allowed on the App Store. Therefore, I kindly request that the author updates the SDK accordingly. My current version is geolocator: 8.0.1.
Proposal
ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/geolocator_apple.framework/geolocator_apple”, which includes geolocator_apple, an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting November 12, 2024, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements.
Specific requirements or considerations
No response
Additional information or context
No response

Hi @xljhd,
The privacy manifest has been added to the geolocator_apple package in version 2.3.7 and is available since March 18th of 2024.
Version 8.0.1 of the geolocator is heavily outdated, to resolve this issue make sure to update to version 13.0.0 of the geolocator plugin.

thanks!
------------------ 原始邮件 ------------------
发件人: "Maurits van @.>;
发送时间: 2024年9月13日(星期五) 下午3:48
收件人: @.>;
抄送: @.>; @.>;
主题: Re: [Baseflow/flutter-geolocator] [Feature Request]: ITMS-91061: Missing privacy manifest (Issue #1572)
@.***，
隐私清单已添加到 2.3.7 版 geolocator_apple 包中，自 2024 年 3 月 18 日起可用。
地理定位器 8.0.1 版本已经严重过时，要解决此问题，请确保将地理定位器插件更新至 13.0.0 版本。
—
直接回复此电子邮件、在 GitHub 上查看或取消订阅。
您收到此邮件是因为有人提及了您。消息ID ：< @.*** >


Update linux-snap.md

Summary
Global tools produce an error when installed using the snap because it isn't to locate the DOTNET_ROOT. I am including this change to highlight this others.
Fixes #Issue_Number (if available)

Thank you for this suggestion. Do you know if the snaps can just set that for you automatically? Is there some other configuration through a snap profile or something that can set this up? I don't know linux well enough to answer these questions. @rbhanda perhaps you can answer?
@phillipsj I don't think this should be a section pointing out the error, this should be a section just about configuring the system for global tools when you use snap for dotnet.

Hi @adegeo I could not find anything in snap documentation to set this up automatically.


Error: Process completed with exit code 126.

Hey i treid setting it up with a privated repo and it wont work could someone help me thanks
error:
/home/runner/work/_temp/c028c4fe-33b2-43fe-8608-67fa8e98025a.sh: line 254: .git/FETCH_HEAD: Permission denied
Error: Process completed with exit code 126.
workflow:
`name: Deploy to remote Server
on:
workflow_dispatch:
push:
branches:
- main
jobs:
deploy_job:
runs-on: ubuntu-latest
name: Deploy
steps:
- name: 🚚 Get latest code
uses: actions/checkout@v4
with:
fetch-depth: 0
  - name: 📂 Sync files
    uses: milanmk/actions-file-deployer@master
    with:
      remote-protocol: "sftp"
      remote-host: ${{ secrets.SFTP_SERVER }}
      remote-user: ${{ secrets.SFTP_USERNAME }}
      remote-password: ${{ secrets.SFTP_PASSWORD }}
      remote-port: ${{ secrets.SFTP_PORT }}
      remote-path: ./
      sync: delta
      sync-delta-excludes: |
        .github/**
        .git/**
        README.md`

Seems like a file permission issue in the runner. Are you running this in a self-hosted runner?

Seems like a file permission issue in the runner. Are you running this in a self-hosted runner?

I just added your action to a workflow like the examples

Please share the run logs for this workflow.


own data

Hi, if the chessboard is rigid enough, can we calibrate the lidar and camera without a board? Thus , we can set the offset as 0 mm  and  0 mm.

I'm not sure what you mean by "if the chessboard is rigid you can calibrate without a board"? If you are referring to the backing board that the chessboard is placed on, then yes you wouldn't need it if your chessboard is very rigid. The main idea is to have a completely flat chessboard surface; how you achieve that is up to you. The offset of the lidar is specific to the internal lidar calibration and not related to the rigidity of the chessboard.


Update tfms

I realized the net8.0 was not correctly setting the feature flags and was not optimized :/
Then thought I could just remove netstandard and add the specific ones since when using netstandard you still need to add an core one (recommendation).
I will definitely change my mind, but for now this is what it is.

Thanks for the feedback Marko


test(e2e,playwright): Header

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Related to #51705

camperbot cant code

Makes sense, how is my test cases otherwise? Should I add/change something. This is my first contribution so asking.

Hi, have made the changes as per your comments.

Hi, I have added the tests for the exam Navigation and Header testing is complete now.


Resource raw_read() method cannot read the GeoJSON data

datapackage        1.1.4
python 3.6
the case from this website:[https://frictionlessdata.io/docs/joining-data-in-python/]

world = json.loads(countries_dp.get_resource('countries') .raw_read()**.decode(
'UTF-8'))
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36-32\lib\sit
e-packages\datapackage\resource.py", line 218, in raw_read
for chunk in self.iter():
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python36-32\lib\sit
e-packages\datapackage\resource.py", line 166, in iter
raise exceptions.DataPackageException(message)
tableschema.exceptions.DataPackageException: Methods iter/read are not supported
for non tabular data

@wengdanyu
Please upgrade the lib version to 1.2.4+. It was fixed - https://github.com/frictionlessdata/datapackage-py/commits/master

@roll  get it!


Fix CI task - lock numpy below V2

Pull Request
Description
This should fix the failing CI task. Meanwhile I can look into upgrading this repo to numpy 2.0 too.
Fixes #77
How Has This Been Tested?
 The only part that failed was the coverage report upload.

[x] Yes

Checklist:

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

You might prefer #79 instead

Shall i close this due to #80?

Ah yes, will close


iframe inside dialog

is it possible to post some code using iframe inside dialog?

This is some jQuery UI dialog matter, sure can find some in stack overflow


[gateway] instances cannot be reached from different parts of the world

Does not work from Europe (@InoMurko ) /Asia (@sk-enya ):
https://bobabeam.boba.network/
https://bobabase.boba.network/
https://testnet.avax.boba.network/
https://avax.boba.network/
https://testnet.bnb.boba.network/
https://bnb.boba.network/
Works:
https://gateway.rinkeby.boba.network/
https://gateway.boba.network/

Does https://gateway.bobabeam.boba.network work for you?

The bobabeam gateway should be reachable globally based on the tests.
https://www.uptimia.com/website-availability-test/f3b53342

The bobabeam gateway should be reachable globally based on the tests.
https://www.uptimia.com/website-availability-test/f3b53342

I can't reach our alts with my phone either (LTE). 😩

Getting something like this when I open other gateway which @InoMurko has mention not working.

Yeah this is working for me.

curl https://bobabase.boba.network/ --verbose
*   Trying <IP_ADDRESS>:443...
* Connected to bobabase.boba.network (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=bobabeam.boba.network
*  start date: May  4 00:00:00 2022 GMT
*  expire date: Jun  2 23:59:59 2023 GMT
*  subjectAltName: host "bobabase.boba.network" matched cert's "bobabase.boba.network"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x139010000)
> GET / HTTP/2
> Host: bobabase.boba.network
> user-agent: curl/7.79.1
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 405
< date: Sat, 01 Oct 2022 10:50:37 GMT
< content-length: 0
< vary: Origin
<
* Connection #0 to host bobabase.boba.network left intact

Does https://gateway.bobabeam.boba.network/ work for you?

@Boyuan-Chen
Yeah this is working for me.

For me too


LDP instance_subjects derived table with changes and comments

All queries:
- [ ] Pull request is based on a new branch (not main)
- [ ] Pull request scope is not overly broad
- [ ] Release notes have been added or updated in CHANGES.md
- [ ] Query runs without errors
- [ ] Query output is correct
- [ ] Query logic is clear and well documented
- [ ] Query is readable and properly indented with spaces (not tabs)
- [ ] Table and column names are in all-lowercase
- [ ] Quotation marks are used only where necessary

Report queries:
- [ ] Query has complete user documentation
    - [ ] Purpose of report
    - [ ] Sample output
    - [ ] Query instructions

Derived tables:
- [ ] Query begins with user documentation in comment lines
- [ ] File name is listed in `runlist.txt` after dependencies
- [ ] All columns have indexes
- [ ] Table is vacuumed and analyzed

due to a data structure change for subjects please ran it in LDP1_folio_snapshot environment since it has the most current structure.


Adding unit tests and other clean-up

Refactoring OneLoginAuthConnector into two classes to make it more testable
Adding unit tests
Removing some unused code

Changes Unknown when pulling 3569a02d8f55f2171eb7e821d48958e452a4f3cb on tlisonbee:unit-tests into ** on Nike-Inc:master**.

Changes Unknown when pulling 677fa0627136d32643be9bb50e7ad0e18a11bbc0 on tlisonbee:unit-tests into ** on Nike-Inc:master**.

Changes Unknown when pulling 049c0ee77baefc5746697c97ab4f45c99ee94fd3 on tlisonbee:unit-tests into ** on Nike-Inc:master**.


glob / wildcard matching issue

  $ touch a
  $ touch b
  $ touch c

  $ ls -l
  total 0
  -rw-r--r-- 1 muesli muesli 0 Feb  2 11:40 a
  -rw-r--r-- 1 muesli muesli 0 Feb  2 11:40 b
  -rw-r--r-- 1 muesli muesli 0 Feb  2 11:40 c

  $ ls bar*
  a  b  c

As you can see the non-matching 'bar*' glob essentially translates to an empty string and "ls" is executed. This is potentially dangerous.

We can have wildcards that expand to nothing throw an error by default, and add a nothing-ok modifier (cf #298) to suppress this failing behavior.
PS. @muesli to be precise, your bar* did not evaluate to an empty string (that would be ls "") but rather nothing (giving ls no argument at all).

Spec for new (just implemented) behavior: https://github.com/elves/elvish/wiki/Language-Specification#wildcards


under develop!

under develop! under develop! under develop! under develop! under develop! ?

i think thats under develop!


refactor(protocol): very minor optimization for gas and readability

No logical changes, but some minor optimizations are done to the code.

Please read the README.md to upgrade foundry.

Nice


Upgrade docs with better search

Fix #304
Upgrades Nextra which has better built-in search. This also removes Prism since the new Nextra includes Shiki to generate highlighting at build time. A notable change is highlight="1,2-3" is now {1,2-3} (docs).
Also have to disable React strict mode. We're on React 17 so it's tricky to support the hash slugger without the new React 18 APIs.

(Later we can introduce a noindex option to skip pages like /terms.)

How hard is it to do noindex? it's really invading most results

Actually not hard, will add it today!

I think we'll wait until that to merge

Named it as searchable since noindex is commonly used for another purpose.

Loading spinner and error on the preview at the moment

@shuding might be broken because turbo docs site is using FS API and .nextra isn't part of the upload.

Let's see if removing FS api solves it? https://github.com/vercel/turborepo/blob/main/docs/vercel.json#L4

Gotcha, or maybe moving that folder to .output (via a script)? Let me try removing it first.


fpml to PURE translation

This issue is stale because it has been open for 30 days with no activity. Please remove stale label or add any comment to keep this open. Otherwise this will be closed in 5 days.


Added Pytorch for deep learning in machine-learning section

Added Deep learning using PyTorch.

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.

As there has been no response from your end for a while, we are closing this PR.
Feel free to request this PR to be reopened or create a new PR, if you still wish to make the changes you originally added plus any additional change requests asked of you.  Also, remember to update your fork, so you have the latest version of master in case it has changed significantly.
Happy Coding!


README: use env delete bootargs for manual steps only

This PR must be merged ONLY after the merge of the https://github.com/xen-troops/meta-xt-rcar/pull/65

As far as env delete bootargs is the part of the boot scripts, we should mention that this command is required only for the manual steps.

PR is not relevant any nore, due to changes in the mentioned PR.


Disable Annotation Delete Buttons During Active Audio Play

When the audio is playing, the delete all annotations for a marker should not be active

https://github.com/KoALa-MHF/koala-app/pull/322


[android] react-native unlink doesn't remove strings added in strings.xml

Is this a bug report?
Yes

Have you read the Contributing Guidelines?
Yes
Environment

react-native -v: 0.47.1
node -v: 6.11.2
npm -v: 4.6.1
yarn --version: 0.27.5

Then, specify:

Target Platform: Android

Development Operating System: macOS 10.12.6

Build tools: Android Studio

Steps to Reproduce

(Write your steps here:)

react-native init reproProject
cd reproProject
npm install mobile-center-crashes mobile-center-analytics --save
react-native link
react-native unlink mobile-center-crashes

Expected Behavior

With react-native link linking two npm package "mobile-center-crashes" and "mobile-center-analytics", two strings are added to /android/app/src/main/res/values/strings.xml as a result.
<string moduleConfig="true" name="mobileCenterCrashes_whenToSendCrashes">ALWAYS_SEND</string>
<string moduleConfig="true" name="mobileCenterAnalytics_whenToEnableAnalytics">ALWAYS_SEND</string>

I expect react-native unlink mobile-center-crashes to remove <string moduleConfig="true" name="mobileCenterCrashes_whenToSendCrashes">ALWAYS_SEND</string> in the /android/app/src/main/res/values/strings.xml.
Actual Behavior

However, in android project, react-native unlink mobile-center-crashes remove everything except <string moduleConfig="true" name="mobileCenterCrashes_whenToSendCrashes">ALWAYS_SEND</string> in the /android/app/src/main/res/values/strings.xml. It makes everything right except the strings.xml.
Reproducible Demo

I have created a repro project following all the 5 steps in "Steps to Reproduce" here. You can see after unlink, string is not removed from /android/app/src/main/res/values/strings.xml.
I believe I was able to identify the root cause of this issue. It is caused by a bug in the regular expression at Ln21-Ln23 in the react-native/local-cli/link/android/unregisterNativeModule.js.
  strings.replace(
    /moduleConfig="true" name="(\w+)">(.*)</g,
    (_, param, value) => {
      params[param.slice(toCamelCase(name).length + 1)] = value;
    }
  );

param.slice(toCamelCase(name).length + 1) is making an assumption that all the matching strings must comes from npm package with the same length of the name. In my case, I have two npm packages "mobile-center-crashes" and "mobile-center-analytics" with different length of package name. Regular expression matching mobileCenterCrashes_whenToSendCrashes and mobileCenterAnalytics_whenToEnableAnalytics, so it doesn't work because they have different length.
Looks like I am running into an edge case that this regular expression doesn't work well. Let me know if I you need more information for reproducing this bug.

maybe you can try
yarn add xxx
react-native-link
react-native-unlink
yarn remove xxx.

@wuyunqiang Thanks. It won't help because the problem is actually with react-native unlink <package>. It has nothing to do with installing or removing the package, so yarn remove <package> won't help.

This bug still exists in<EMAIL_ADDRESS>My workaround is quite straight forward--manually remove extra strings in strings.xml. I guess not many people are bumping into this issue, but it creates some trouble for automating linking and unlinking process.


replace input amqp url to AMQP::Address

AMQP::Address cannot correctly parse url when password contains '@', randomly generated password always contains this character
eg: AMQP::Address(amqp:://admin:admin@123@<IP_ADDRESS>:5672/).hostname() will be<EMAIL_ADDRESS>

Thanks for the offer. I'd prefer to make another ctor for this case. I'll do it soon.
I'd also leave the ctor parameter "AMQP::Address address" instead of "AMQP::Address&& address" since that allows the "address" parameter to be used as both an l-value and an r-value.


Wrap the camera in a View.

Wrap the camera in a View with the passed style so the needed space
is allocated even before the Camera component is initialized.

Before
After

great job @bfabio, @moaazsidat can you publish a patch release with that fix please?


Out Of Memory

Dear nothinglo,
Thank you for sharing your code!
When I ran [Experimental_Code_Data], it soon got an OOM.
here is my GPU information:
name: TITAN Xp
major: 6 minor: 1 memoryClockRate (GHz) 1.582
pciBusID 0000:01:00.0
Total memory: 11.91GiB
Free memory: 11.36GiB
But [Experimental_Supervised_Code] works well.
Can someone help me?

Have you reduced batch size in DATA.py?

hi Dear nothinglo,
I have this issue too! I've reduced batch size to 1 but I get this error yet :(

@XuRongYan do you have solve this problem?please tell me your method,thank you!
i set batch_size = 1 and my GPU memory only 2.0GB , can i train this project by GPU?

could you please tell me how to run Expeimental_Supervised_Code?I meam how to prepare the data and txt files.

Hi,
When I run the TF.py in the "[Online_Demo_Models]_Deep-Photo-Enhancer/LPGAN_exp_G3_736" file, I face this error:
Shapes (2, 1, 32, 32, 128) and () are incompatible
in line: netG_test_output1 = model(netG, test_df.input1, False, netG_act_o, is_first=True)
Would you mind helping me with it? Thank you in advance.

Hi,

Hi
I don't find the code you shared on your web
Could you please show me how to get the code?
Thank you in advance.


MDExpansionPanel

Good afternoon, guys, see if anyone can help me, I've tried everything and I can't figure out what I'm doing wrong, I can't get the items to be displayed. This code will be modified later to display the final items, follow...
`#TelaConsultaPro.py
from kivymd.uix.screen import MDScreen
from kivy.uix.screenmanager import SlideTransition
from kivymd.uix.expansionpanel import MDExpansionPanel, MDExpansionPanelThreeLine
from kivy.uix.boxlayout import BoxLayout
from kivy.uix.label import Label
from kivy.uix.button import Button
class TelaConsultaPro(MDScreen):
def transicao_tela(self, tela):
    self.manager.transition = SlideTransition(direction="right")
    self.manager.current = tela

def on_start(self):

    for i in range(10):
        panel = MDExpansionPanel(text="Painel " + str(i))
        content = BoxLayout(orientation="vertical")
        content.add_widget(Label(text="Conteúdo do painel " + str(i)))
        content.add_widget(Button(text="Botão " + str(i)))
        panel.content = content
        self.ids.box.add_widget(panel)

`
`#TelaConsultaPro.kv
:
MDBoxLayout:
orientation: 'vertical'
    MDTopAppBar:
        title: "Cadastro"
        left_action_items: [["menu", lambda x: app.callback()]]
        right_action_items: [["arrow-left", lambda x: root.transicao_tela("TelaPrincipal")]]
        elevation: 10
        md_bg_color: "#000000"
        specific_text_color: "white"

    MDScrollView:
        MDGridLayout:
            id: box
            cols: 1
            adaptive_height: True

    MDTopAppBar:
        type: "bottom"
        mode: "free-end"
        elevation: 10
        md_bg_color: "#000000"`

The issue is deprecated due to the new API of the KivyMD library 2.0.0 version


Typo in help command

Description:
Typo in below section .
The word "sharable" should be changed to "shareable"
BALLERINA COMMANDS
    Available commands are:
        compile         Compile Ballerina module/project in-to a sharable
                        library(balo)

Steps to reproduce:
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

Compile command will be removed from 1.0.0-beta and will be replaces by build -c


Handling inline references in the main schema even when subSchemas are provided

Right now, if subSchemas are provided, it prevents inline references in the main schema from being resolved.
javascript
var schema = Enjoi({
'title': 'Example Schema',
'type': 'object',
'properties': {
'firstname': {
'$ref': '#/definitions/firstname'
},
'surname': {
'$ref': 'definitions#/surname'
}
},
'definitions': {
'firstname': {
'type': 'string'
}
}
}, {
'definitions': {
'surname': {
'type': 'string'
}
}
});

Would throw up this error:

AssertionError: Can not find schema reference: #/definitions/firstname.

This PR fixes just that + adds proper test checking this use case.

(related: https://github.com/krakenjs/swaggerize-builder/issues/33 ).

I believe this was resolved by https://github.com/tlivings/enjoi/commit/31175d9df59838bd035c0ca647c083941472052d (allowing to override source for inline references by providing subSchema with # key).


Fix e2e bug for IKS- 1.25

Removing tee as this is used to redirect O/P to file. I don't see the O/P being used anywhere in the script. keeping this command will not give accurate execution status of ginkgo. Return code is based on tee command was success/fail.

IKS 1.25 , E2E tests are timing out. More details:  https://github.ibm.com/alchemy-containers/armada-storage/issues/3884
Added flag in ginkgo command. This could be temporary fix and RCA has to be done

We need to understand 1.25 changelog  - https://sysdig.com/blog/kubernetes-1-25-whats-new/
Especially this point - End-to-end testing has been migrated [from Ginkgo v1 to v2](https://github.com/kubernetes/kubernetes/pull/109111).

We still not do RCA whether this flag is the right fix or not. As of now we can go ahead with the fix to unblock e2e as it is not impacting our verification.

Closing as we will fix this in #61

We still need to do RCA whether this flag is the right fix or not. As of now we can go ahead with the fix to unblock e2e as it is not impacting our verification.

RCA done and reason explained here
In 1.25 secrets are not present for service accounts. So we get timeout error.


Default target directory should be current working directory, same as "cmd"

Default target directory should be current working directory, same as cmd. Currently when opened from other terminal or from explorer its target directory is default home directory of current user.
This is how "cmd" behaves

This is how "terminal" behaves

Have to pass command line arguments to achieve same behavior, wt -d .. It would be great to have it behave like cmd.

This issue has been raised before. I believe wt -d . is the recommended way to make this work. See issue https://github.com/microsoft/terminal/issues/878#issuecomment-579508860.

I know this and mentioned it myself. But It would be great if it does automatically.

Yeah, I'm just telling you that what you're doing is the recommended approach. This issue has been raised many times before, and the answer is always that you need to use the method you're already using. See #4287, #4330, #4647, #4787, #4936, #5220, #5796, #6031, and #6132.

Yea, I think I'm going to resolve this one as a dupe. Thanks for triaging @j4james!
/dup #878, #4287, #4330, #4647, #4787, #4936, #5220, #5796, #6031, and #6132.


Spring Data Spanner: Get commit timestamp after successful commit

It would be great if we can get  CommitResponse and timestamp of it, whenever write happens in transaction and LastUpdateTimestamp column which has allow-commit-timestamp=true enabled. Google spanner have docs for RPC which suggests its available with the calls RPC Docs. Also it is available in client library as well and can be found in Spanner Repo.

@ChengyuanZhao

@don-mayur I'll look into the CommitResponse.
The  last-updated timestamp column feature is already available. Check the refdoc here
https://github.com/spring-cloud/spring-cloud-gcp/blob/master/docs/src/main/asciidoc/spanner.adoc#columns
spannerCommitTimestamp

@ChengyuanZhao Thanks for suggesting column option spannerCommitTimestamp which  is helpful and I will use it, But in this issue I was referring about ability to retrieve commitTimestamp after successful transaction commit as a CommitResponse and way to get it, without again querying the database. Please see example in Spanner Git Repo for this.

@ChengyuanZhao Do you have an update on this?

@meltsufin no response at the moment. This is a feature request we haven't looked into or implemented yet.

There is a Spanner customer who is interested in this -- is this a lot of work? Should we just file a new feature request?

Hi @ChengyuanZhao, this feature is very important for us. Please try to get it prioritised.

I'll take a look. I've recently been in the client library code dealing with this.

Sorry, will look in the new year. Ran out of time.


new buttons (beta) objections/opinions

First, thanks for picking this project up; it's been awesome seeing it actually get updates again!
As for the new buttons:

Removing the borders causes some of the same problem that we see in buttons in Apple's interfaces post skeumorphism crusade and in some material design scenarios:

It's not clear that they're buttons until you attempt to interact with them.
It's not clear where the edge of the interactable space is until you attempt to interact with them.
When it looks like they're just text, the vertical alignment of the text is now (in my opinion) visually "expected" to be at the same baseline as other things around it. For example, in the Update Project dialog, I now expect the buttons' text baseline to align with the "Do not show this dialog in the future" text.

At the very least, the at-rest background color/tone should be different than the background they're sitting on to avoid these problems.
These are, of course, just my opinions :smile:.
Thanks, again!

I agree with your opinions, but this is a choice I've made with incorporating Material Design guidelines into this project. Maybe at some point I'll also insert the concept of raised buttons/primary buttons to contrast with the background - for instance in the update dialog at the very least a call to action should be visible through a primary button. It also depends on what the IntelliJ SDK is letting me do with it :)
Also, for now I'm taking inspiration from the Sublime Text plugin, so at the very least it should mimic its features and not deviate too much. The color between the buttons and other components are mainly because the other components colors are not the right ones. At some point I might want to change them to be white only on hover or when a checkbox is checked. But this is not the priority at the moment, and the buttons was just a nice touch to experiment what we can do with the plugin SDK :)
Thanks for the remarks though 🥇

I don't suppose you'd be interested in making it configurable? The un-delineated buttons thing is just such a pet peeve of mine. I'll probably just end up getting stuck on the version previous to this one forever because I like the rest of this project so much outside of that. :smile:

Theoretically it should be possible to make it configurable, I'll think of something in the future :)
--
Elior Boukhobza
On Apr 24, 2017, 21:55 +0300, Chris Harwood<EMAIL_ADDRESS>wrote:

I don't suppose you'd be interested in making it configurable? The un-delineated buttons thing is just such a pet peeve of mine. I'll probably just end up getting stuck on the version previous to this one forever because I like the rest of this project so much outside of that. 😄
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/mallowigi/material-theme-jetbrains/issues/14#issuecomment-296789094), or mute the thread (https://github.com/notifications/unsubscribe-auth/AEyIzChe3WHxsr3f08b8V2p8F4Mubvblks5rzPAJgaJpZM4NGQso).

My hero.


cmd: add a version command to print version, as an alternative of --version

Codecov Report

Merging #2229 (6c19923) into main (90786c1) will decrease coverage by 0.02%.
The diff coverage is 55.55%.

@@            Coverage Diff             @@
##             main    #2229      +/-   ##
==========================================
- Coverage   61.76%   61.74%   -0.03%
==========================================
  Files         137      138       +1
  Lines       25035    25044       +9
==========================================
  Hits        15464    15464
- Misses       7768     7777       +9
  Partials     1803     1803

Impacted Files
Coverage Δ

cmd/version.go
50.00% <50.00%> (ø)

cmd/main.go
48.38% <100.00%> (+0.27%)
:arrow_up:

pkg/vfs/reader.go
77.18% <0.00%> (-3.11%)
:arrow_down:

pkg/meta/redis.go
71.57% <0.00%> (-0.05%)
:arrow_down:

pkg/meta/sql.go
66.05% <0.00%> (+0.09%)
:arrow_up:

pkg/meta/tkv.go
76.53% <0.00%> (+0.42%)
:arrow_up:

pkg/chunk/utils_unix.go
93.33% <0.00%> (+20.00%)
: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 90786c1...6c19923. Read the comment docs.