Setting Color with ${color.rgbx} don't work

ha-bridge Version 5.4.0
I use ${color.rgbx} under color Items of the device
If I try to set the color over Alexa it doesn't work. If I say Blue color is set to FFFFFF, Green color is set to FFFFFF....
When I set the color with the "Test Color" Button in the ha-bridge GUI it works, after that it works also via Alexa until next reboot. This problem is reproducible.
log for color green:

12-15-2020 16:44:04.818
DEBUG
executing HUE api request to send message to  MQTT broker:  "{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"${color.rgbx}","qos":"1","retain":"false"}"
com.bwssystems.HABridge.plugins.mqtt.MQTTHome

12-15-2020 16:44:04.818
DEBUG
Request  <<{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"${color.rgbx}","qos":"1","retain":"false"}>>,  not done: false
com.bwssystems.HABridge.hue.DeviceDataDecode

12-15-2020 16:44:04.819
INFO
Hue = 21845.0, Sat = 254.0, Bri = 254.0
com.bwssystems.HABridge.hue.ColorDecode

12-15-2020 16:44:04.819
DEBUG
Color change with HSB New: Hue: 21845, Sat: 254, Bri: 254. Resulting RGB Values: 255 255 255
com.bwssystems.HABridge.hue.ColorDecode

12-15-2020 16:44:04.819
DEBUG
Request  <<{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"FFFFFF","qos":"1","retain":"false"}>>,  not done: true
com.bwssystems.HABridge.hue.ColorDecode

12-15-2020 16:44:04.820
DEBUG
Request  <<{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"FFFFFF","qos":"1","retain":"false"}>>,  not done: false
com.bwssystems.HABridge.hue.ColorDecode

12-15-2020 16:44:04.820
DEBUG
publishing message: HABRIDGE - cmnd/Luftbefeuchter/COLOR - FFFFFF - count: 0

If you could set debug for the HueMulator class to see what the Alexa sends on the first tries that are not request that would help. Thanks

FWIIW, I have the identical behavior in that the color will not start working until after I first test via the 'test color' button, and from that point forward, requesting via Alexa works.  However, the rgb values received via Alexa, in my case, seem completely random.

including Debug-Log HueMulator for color blue
12-15-2020 19:08:54.934
DEBUG
HueMulator PUT called on api/* with request <<</api/b56a460139704039b50e72071393375d/lights/534/state>>>, and body <<<{"on":true,"hue":43690,"sat":254}>>>
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:54.935
DEBUG
hue state change requested: b56a460139704039b50e72071393375d from <IP_ADDRESS> body: {"on":true,"hue":43690,"sat":254}
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:54.935
DEBUG
validateWhitelistUser: found a user
com.bwssystems.HABridge.BridgeSecurity
12-15-2020 19:08:54.936
DEBUG
hue/sat request - Hue: 43690, Sat: 254, Bri: 254
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:54.936
DEBUG
Calling on-off as requested.
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:54.936
DEBUG
Decode Json for url items: [{"item":"{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/POWER","message":"ON","qos":"1","retain":"false"}","type":"mqttMessage"}]
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:54.936
DEBUG
Calling Home device handler for type : mqttMessage
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:54.936
DEBUG
executing HUE api request to send message to MQTT broker: "{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/POWER","message":"ON","qos":"1","retain":"false"}"
com.bwssystems.HABridge.plugins.mqtt.MQTTHome
12-15-2020 19:08:54.937
DEBUG
Request <<{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/POWER","message":"ON","qos":"1","retain":"false"}>>, not done: false
com.bwssystems.HABridge.hue.DeviceDataDecode
12-15-2020 19:08:54.937
INFO
Hue = 43690.0, Sat = 254.0, Bri = 254.0
com.bwssystems.HABridge.hue.ColorDecode
12-15-2020 19:08:54.937
DEBUG
Color change with HSB New: Hue: 43690, Sat: 254, Bri: 254. Resulting RGB Values: 255 255 255
com.bwssystems.HABridge.hue.ColorDecode
12-15-2020 19:08:54.937
DEBUG
Request <<{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/POWER","message":"ON","qos":"1","retain":"false"}>>, not done: false
com.bwssystems.HABridge.hue.ColorDecode
12-15-2020 19:08:54.938
DEBUG
publishing message: HABRIDGE - cmnd/Luftbefeuchter/POWER - ON - count: 0
com.bwssystems.HABridge.plugins.mqtt.MQTTHome
12-15-2020 19:08:54.938
DEBUG
Retrieved a MQTT hanlder for name: HABRIDGE
com.bwssystems.HABridge.plugins.mqtt.MQTTHome
12-15-2020 19:08:54.940
DEBUG
Calling color as requested.
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:55.090
DEBUG
Decode Json for url items: [{"item":"{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"${color.rgbx}","qos":"1","retain":"false"}","type":"mqttMessage"}]
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:55.091
DEBUG
Calling Home device handler for type : mqttMessage
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:55.091
DEBUG
executing HUE api request to send message to MQTT broker: "{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"${color.rgbx}","qos":"1","retain":"false"}"
com.bwssystems.HABridge.plugins.mqtt.MQTTHome
12-15-2020 19:08:55.092
DEBUG
Request <<{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"${color.rgbx}","qos":"1","retain":"false"}>>, not done: false
com.bwssystems.HABridge.hue.DeviceDataDecode
12-15-2020 19:08:55.092
INFO
Hue = 43690.0, Sat = 254.0, Bri = 254.0
com.bwssystems.HABridge.hue.ColorDecode
12-15-2020 19:08:55.092
DEBUG
Color change with HSB New: Hue: 43690, Sat: 254, Bri: 254. Resulting RGB Values: 255 255 255
com.bwssystems.HABridge.hue.ColorDecode
12-15-2020 19:08:55.093
DEBUG
Request <<{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"FFFFFF","qos":"1","retain":"false"}>>, not done: true
com.bwssystems.HABridge.hue.ColorDecode
12-15-2020 19:08:55.093
DEBUG
Request <<{"clientId":"HABRIDGE","topic":"cmnd/Luftbefeuchter/COLOR","message":"FFFFFF","qos":"1","retain":"false"}>>, not done: false
com.bwssystems.HABridge.hue.ColorDecode
12-15-2020 19:08:55.093
DEBUG
publishing message: HABRIDGE - cmnd/Luftbefeuchter/COLOR - FFFFFF - count: 0
com.bwssystems.HABridge.plugins.mqtt.MQTTHome
12-15-2020 19:08:55.093
DEBUG
Retrieved a MQTT hanlder for name: HABRIDGE
com.bwssystems.HABridge.plugins.mqtt.MQTTHome
12-15-2020 19:08:55.128
DEBUG
HueMulator GET called on api/* with request <<</api/b56a460139704039b50e72071393375d/lights/534>>>, and body <<<>>>
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:55.130
DEBUG
hue light requested: 534 for user: b56a460139704039b50e72071393375d from <IP_ADDRESS>
com.bwssystems.HABridge.hue.HueMulator
12-15-2020 19:08:55.131
DEBUG
validateWhitelistUser: found a user

Interesting as if you convert what the Alexa sent in an external converter you get FFFFFF. So, trying to understand why Alexa sends that?

Well, intersting enough, if I set the Brightness value to 50, it ends up being 0000FF, which is correct. It must be if the brightness is not set properly, it will be 254 or 100% and that kills the color conversion... This is a bug.

Hi,
I still have this bug in 5.4.1-release. Also the color.rx,color.gx,color.bx are always set on FF each, when I request Alexa to set the color. Doing it in the Web-UI of HA-Bridge it is working. Can you please help? I love the project and have been using it for a long time yet.
I thought that it should have been fixed in 5.4.1 because the topic was closed, but as I can see only the 9-digit problem was solved.
Build it with maven still the same error.
Greetings Michael

Hi, I still have this bug in 5.4.1-release. Also the color.rx,color.gx,color.bx are always set on FF each, when I request Alexa to set the color. Doing it in the Web-UI of HA-Bridge it is working. Can you please help? I love the project and have been using it for a long time yet. I thought that it should have been fixed in 5.4.1 because the topic was closed, but as I can see only the 9-digit problem was solved. Build it with maven still the same error.
Greetings Michael

Same issue, here, Michael. Would really be nice if the HA-Bridge guys can fix this issue.


Fix Unicode normalization on macOS

This is an fix for #586.
Incorrect rendering before normalization (current behavior):

and correct rendering with normalization:

I just met with this nice terminal and haven't look at the codebase deeply.
So adding normalization here may not be appropriate. There may be an unexpected side effects.
Honestly, I'm not sure.

this is a good read about it: http://unicode.org/faq/normalization.html

Sorry for the delay.
@Snack-X thank you so much for your PR. Can you attach a txt file with your ls output in order to reproduce it (and test it with xterm, our hterm replacement)?

This is an old issue, but problem still remains. Original PR was made before the 1.0.0 release. Now times have passed and this PR won't be compatible with recent codebase.
Anyway, you can easily reproduce the same problem with reverse xxd.

First, hexadecimal values of each string.
> Buffer.from("にっぽん", "utf8")
<Buffer e3 81 ab e3 81 a3 e3 81 bd e3 82 93>
> Buffer.from("にっぽん".normalize("NFD"), "utf8")
<Buffer e3 81 ab e3 81 a3 e3 81 bb e3 82 9a e3 82 93>
> Buffer.from("ニッポン", "utf8")
<Buffer e3 83 8b e3 83 83 e3 83 9d e3 83 b3>
> Buffer.from("ニッポン".normalize("NFD"), "utf8")
<Buffer e3 83 8b e3 83 83 e3 83 9b e3 82 9a e3 83 b3>
> Buffer.from("대한민국", "utf8")
<Buffer eb 8c 80 ed 95 9c eb af bc ea b5 ad>
> Buffer.from("대한민국".normalize("NFD"), "utf8")
<Buffer e1 84 83 e1 85 a2 e1 84 92 e1 85 a1 e1 86 ab e1 84 86 e1 85 b5 e1 86 ab e1 84 80 e1 85 ae e1 86 a8>

And using reverse xxd, problem is reproducible.
$ echo "e3 81 ab e3 81 a3 e3 81 bd e3 82 93 0a" | xxd -r -p
にっぽん
$ echo "e3 81 ab e3 81 a3 e3 81 bb e3 82 9a e3 82 93 0a" | xxd -r -p
にっぽん
$ echo "e3 83 8b e3 83 83 e3 83 9d e3 83 b3 0a" | xxd -r -p
ニッポン
$ echo "e3 83 8b e3 83 83 e3 83 9b e3 82 9a e3 83 b3 0a" | xxd -r -p
ニッポン
$ echo "eb 8c 80 ed 95 9c eb af bc ea b5 ad 0a" | xxd -r -p
대한민국
$ echo "e1 84 83 e1 85 a2 e1 84 92 e1 85 a1 e1 86 ab e1 84 86 e1 85 b5 e1 86 ab e1 84 80 e1 85 ae e1 86 a8 0a" | xxd -r -p
대한민국

Screenshots below are the comparison of three terminal softwares, Terminal.app (bundled with macOS 10.12.6), iTerm 2 (latest beta), and Hyper (<IP_ADDRESS>4).

Besides the incorrect rendering(why it got worse?), Terminal and iTerm handles it perfect, while Hyper does not.
If you have problem with font, you can use D2Coding, a monospace font supports Korean Hangul, Japanese Hiragana and Katakana, and CJK Ideographs.

Looks like rendering issue is related with #1535, and corresponding PR is made as #2000.

After almost a year, I can confirm this issue is fixed with latest 2.0.3.
Everything is rendered as expected, no normalization issue. That took long.
You can close this PR if you wish.

We needed to change from hterm to xterm, that's why it took so long @Snack-X
Thanks for your PR though! ❤


Missing 8600G, 8700G in "Supported Configurations"

https://github.com/amd/ryzen-ai-documentation/blob/develop/docs/inst.rst
Are they "Phoenix" as specs page, or "Hawk Point" because of 16 TOPS?

We will refresh the list for 1.2 release soon


SKYOPS-58122 adding Artifact override rule required

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

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

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@abhishekgarg18 - please create a GitHub issue in this repository explaining why this change is useful. Thanks!


Have 'node_deb.start_command' default to 'scripts.start'

Suggestion from a coworker. Need to see if it makes sense.
@jeffhiltz, can you elaborate?

scripts.start is indeed the default spot to put a start script for a Node.js package.  If that script isn't defined but there is a server.js file in the root of the package then scripts.start takes on the default value of node server.js.
The start script is typically called by running npm start.
Details here:
https://docs.npmjs.com/misc/scripts

Fixed by 5575ce0


[Project Addition] : Sports Image Classification

Deep Learning Simplified Repository (Proposing new issue)
:red_circle: Project Title : Sports Image Classification
:red_circle: Aim : To detect 100 different sports using DL models.
:red_circle: Dataset : https://www.kaggle.com/datasets/gpiosenka/sports-classification
:red_circle: Approach : Try to use 3-4 algorithms to implement the models and compare all the algorithms to find out the best fitted algorithm for the model by checking the accuracy scores. Also do not forget to do a exploratory data analysis before creating any model.

📍 Follow the Guidelines to Contribute in the Project :

You need to create a separate folder named as the Project Title.
Inside that folder, there will be four main components.

Images - To store the required images.
Dataset - To store the dataset or, information/source about the dataset.
Model - To store the machine learning model you've created using the dataset.
requirements.txt - This file will contain the required packages/libraries to run the project in other machines.

Inside the Model folder, the README.md file must be filled up properly, with proper visualizations and conclusions.

:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Follow Contributing Guidelines & Code of Conduct before start Contributing.

:white_check_mark: To be Mentioned while taking the issue :

Full name : Aaradhya Singh
GitHub Profile Link : https://github.com/kyra-09
Email ID<EMAIL_ADDRESS>Participant ID (if applicable): GSSOC-2024 Contributor
Approach for this Project :  1. ) Using various different available network architectures such as Xception , ResNet50 , VGG16 etc. to do catagorical classification for 100 different sports using dataset (mentioned below) .
2.) use data augmentation techniques to improve the accuarcy of models.
3.) Comparing performance and accuracy of models using accuracy score ,loss and accuracy graph , confusion matrix for better understanding.
4.) Perfroming EDA (data analysis) for dataset to understand the structure of data.
5.) Using README file for describing the work I've performed.
What is your participant role? (Mention the Open Source program) :- GSSOC-2024 Contributor

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

Assigned @kyra-09

You can't work on two issues at a time. Please complete the assigned issue, then only you can work on this issue and get the assignment.
@kyra-09

Hey @abhisheks008,
I would like to work on this issue under GSSoC '24.
Please assign this issue to me.

Full name : Mehak
GitHub Profile Link: https://github.com/Mehaksaini2808
Email ID<EMAIL_ADDRESS>Participant ID (if applicable): GSSOC-2024 Contributor
Approach for this Project: 1.  Performing EDA
2.  Data processing for increasing efficiency of the model.
3. Model Building - Training model using  EfficientNet, VGG16 and  ResNet50.
4. Compare all models based on accuracy, precision, recall, F1 score, and any other relevant metrics.
What is your participant role? (Mention the Open Source program) :- GSSOC-2024 Contributor

Full name : Arya Vishal
GitHub Profile Link: https://github.com/aryaVishal1706
Email ID<EMAIL_ADDRESS>Participant ID (if applicable): GSSOC-2024 Contributor
Approach for this Project: 1. Performing EDA
2. Data processing for increasing efficiency of the model.
3. Model Building - Training model using EfficientNet, VGG16 and ResNet50.
4. Compare all models based on accuracy, precision, recall, F1 score, and any other relevant metrics.
What is your participant role? (Mention the Open Source program) :- GSSOC-2024 Contributor

Assigned to @Mehaksaini2808 based on FCFS.

@abhisheks008 if I implement atleast 5 different models can this issue be labled as Level 3?

Yes @kyra-09

@abhisheks008 if I implement atleast 5 different models can this issue be labled as Level 3?

Yes

Pardon me for asking another question...bu do we get extra points for creating an issue as well?

@kyra-09 can we both work on this problem??

Pardon me for asking another question...but do we get extra points for creating an issue as well?

Not sure. You can check with the core team for this. I am adding the labels properly, if they allot points for it, you'll automatically get it.
@aryaVishal1706 sorry mate, one contributor can work on one issue at a time.


Succesfully flashed Panamalar NX-SM200

Successfully flashed Panamalar NX-SM200
Amazon link: https://www.amazon.de/gp/product/B07JBRRW1M/
As described in this issue the procedure for flashing the Panamalar devices is a bit different. After starting the start_flash.sh do NOT connect any laptops/smartphones etc to the vtrust-flash Wifi network. Instead just skip step 1 and start with step 2 to connect the Panamalar device to the Wifi network.
Template
I slightly modified the known user template because the Panamalar device does not have any user defined GPIO's available. The Panamalar device also has 2 LED's, a blue one and a red one:
Blue flashing: not connected to WiFi and/or MQTT broker
Blue continuous: connected to WiFi and MQTT broker; device is switched off
Red continuous: device is switched on
I'm not sure how the LED's are connected to the GPIO's. Using GPIO4 as shown below seems to work, but two LED's connected to one GPIO seems strange to me.

Thanks for the contribution, did you add it to the wiki?

@kueblc : I just added the device to the wiki

Thank you very much!

It looks like Panamalar re-designed this smart plug circuitry and used different GPIOs. I just received a new batch of the Panamalar SM-SX200 smart plugs and the Template above doesn't work with the new plugs anymore.
My preliminary result for a new template is:
{"NAME":"NX-SM200","GPIO":[17,0,0,0,52,132,0,0,0,130,21,134,0],"FLAG":0,"BASE":45}

Device info on the new plugs:
ChipID: xxxxxx
MAC: B4:E6:2D:xx:xx:xx
SdkVersion: 1.5.3(aec24ac9)
BootVersion: 4
BootMode: 1
FlashMode: 1M DOUT @ 40MHz
FlashChipId: 146085
FlashChipRealSize: 1048576
FlashChipSize: 1048576
FlashChipMode: 0
system_upgrade_userbin_check: user2 0x81000

Notice the different MAC, FlashChipId and FlashChipMode.

I have two Panamalar from the new batch. Your template doesn't work.

the button is ok
the red led is ok but the blue one continue to blink
the reported voltage is ok but the power of any load is reported as always 0
Moreover your template sets GPIO13=(130) but your GPIO list sets GPIO13=(131)

Same issue here. Current (ampere) is always 0.
The blue LED is at GPIO13
MAC-Adresse | B4:E6:2D:61:1D:A2
ESP Chip ID | 6364578

You are more likely to get help with Sonoff-Tasmota at their project page

Thanks for all the feedback. Unfortunately I haven't had much time lately to dive into this issue. I hope to do this before the end of may.
The cause of this problem is due to an incorrect assignment of BL0937CF, HLWBL CF1, HLWBL SEL and/or HLWBL SELi. These are the pins connected to the BL0937 chip, which manages the voltage, current and power measurements.
If you're feeling adventurous you can help by trying different combinations yourself as described here: https://github.com/arendst/Sonoff-Tasmota/wiki/Configuration-Procedure-for-New-Devices

I've found a working combination for my device:
{"NAME":"NX-SM200","GPIO":[17,0,0,0,134,132,0,0,0,52,21,130,0],"FLAG":0,"BASE":45}

What worked for me:
{"NAME":"NX-SM200","GPIO":[158,0,0,131,0,134,0,0,0,17,132,21,0],"FLAG":0,"BASE":18}


[Bug][Docs] Dead links in docs

Consider running linkchecker or similar as part of your CI.
In particular, https://graphqlite.thecodingmachine.io/docs/other-frameworks#integration has a dead link for Schema
Other docs may be stale. For example, was  container-interop/service-provider deprecated 4 years ago by PSR-11 ?

@bingalls Thanks for submitting this.  Our documentation has received a pretty large update and all dead links should be resolved now.  I've run it through linkchecker, wasn't aware of that tool - pretty cool.


Data augmentation bug on v1.2~v1.3

We found a data augmentation bug, which was more serious in v1.3, so we can't confirm the performance improvement of v1.3, and withdraw a version update. This bug leads to poor quantitative performance of the current model on the benchmark and is expected to be fixed in 3 days.
We think this is also a major reason for the poor performance of 2d animation.

Done.


raspiconfig serial option prompts for user input

Setting the serial interface to enabled (--plugin raspiconfig:"serial=1") causes sdm to display the raspiconfig text UI, and the user has to interactively answer two questions:

Would you like a login shell to be accessible over serial? (this does not seem implied by asking sdm to turn on the serial interface)
Would you like the serial port hardware to be enabled? (this seems implied by asking sdm to turn on the serial interface)

It seems to me like this might be worth exposing in sdm as two options. I haven't tested against any images before Bookworm to see if this behavior changed in raspi-config.
Would you be interested in a PR to address this? I'm getting so much use out of SDM that I would like to contribute back.

I took a quick look at this, and it appears that the issue is raspi-config itself. The questions are asked regardless of the nonint setting on the raspi-config command line. 😵
Off to file a bug on raspi-config and (for now) handle serial-setting in sdm. Sigh.

As far as contributing, I'd be much more interested in contributions of new plugins that add value to sdm and users.

Do you have any suggestions? So far, all of my use cases are handled by sdm well with the exception of:

downloading a raspi base image before using customize
installing nodeJS (the version in apt is very, very old, so I'm fetching/installing a newer version)
provisioning AWS IoT device certs

The first one (download base img) would be difficult to do as a plugin, since plugins aren't called until the IMG is already verified as existing. I've thought about adding this to sdm (without using a plugin), but thus far I've landed on the "it's easier for people to download their own, especially since sufficiently big disks are quite cheap these days.
I haven't looked into nodeJS, so don't understand the issues there, or the complexity in installing a newer version. Is this a point-in-time problem, or something that's likely to continue forever? What would the complexity be in doing it as a plugin?
The AWS iOT device certs sounds interesting. Can you point me at some info on it?
At the moment I'm a bit sad about the raspi-config serial situation, as a proper fix appears to be a bit complex, because the settings are different for a Pi5 vs all other Pis. Since the target Pi isn't known until boot time, that makes setting the serial config properly for the first boot extremely problematic in the general case. Thinking about how to best handle this...😕

I haven't looked into nodeJS, so don't understand the issues there, or the complexity in installing a newer version. Is this a point-in-time problem, or something that's likely to continue forever? What would the complexity be in doing it as a plugin?

For most raspis, I suspect it's as easy as using apt to pull down a fresh build. Unfortunately for the raspi 0, the open js foundation discontinued support for armv6 quite a while ago, and so there aren't supported first-party builds. They do still build the binaries, but they don't list them in apt. This could be solved either with a plugin that allows you to add new apt sources (since they do list the builds in an unofficial apt source) or by downloading the binary directly, untarring it, and making a few symlinks. I'm currently doing the latter because it was easier to bootstrap, but I think the former is more useful as a plugin.

The AWS iOT device certs sounds interesting. Can you point me at some info on it?

Sure! You can find all the docs here. The developer guide is probably the best starting place, but the very high level overview of the service is:

AWS IoT is an MQTT broker; MQTT is a very light-weight pub/sub protocol.
AWS IoT's implementation is stateful, and each Thing (device) has a Shadow (state). The Thing's Shadow contains the desired state of the device and the last reported state of the device. This allows parts of the distributed system to request state changes even when a device is offline, and allows offline devices to set themselves to the correct state when they're reconnected to the system.
Provisioning a Thing can happen in a staggering number of ways, but the end result is typically that the device has a private key and a certificate which are associated in AWS IoT to a policy. The Thing can then connect with its credentials and take the actions allowed in its policy; usually subscribe and publish to various MQTT channels. This is the part that I've written some glue for. It may or may not be a good fit for a plugin because it has a dependency on the AWS CLI or SDK, and I don't see how you'd sidestep that.

At the moment I'm a bit sad about the raspi-config serial situation, as a proper fix appears to be a bit complex, because the settings are different for a Pi5 vs all other Pis. Since the target Pi isn't known until boot time, that makes setting the serial config properly for the first boot extremely problematic in the general case. Thinking about how to best handle this...😕

Can the first boot script interrogate the image to determine how to configure? E.g., if this is on the PATH, configure this way?

Can the first boot script interrogate the image to determine how to configure? E.g., if this is on the PATH, configure this way?

Yes, of course, BUT: This means that the serial port can't be enabled during sdm FirstBoot, since enabling the serial port changes one or both of cmdline.txt and config.txt, which are read LONG before sdm FirstBoot runs. Having a working serial port in the system First Boot seems like a really good idea for debugging, etc.
Thus far my best idea is to configure the serial port for a Pi5 or not-Pi5. Still has a few problems, but it can be configured at Burn time, when theoretically the target system is known. If this pans out in my thought process, I'll remove serial from the raspiconfig plugin, and add a serial plugin that does this, and only this. (As i'm typing this, the more I type, the more I like it).
As far as the AWS config, thanks for the explanation. I think this would be interesting. Since there are a "staggering number of ways" 😲, it seems that a best-choice prescriptive approach would be good. Since there are AWS CLI/SDK dependencies, I'd expect the plugin to install those required bits as well. There are a couple of plugins that install bits not available in apt, such as btwifiset, imon, knockd, ndm, and pistrong.

sdm V11 has the serial plugin, which addresses the question in the original post (providing more granular control over the serial configuration) and the secondary issue of getting the serial port configured for the wrong Pi5 vs not-Pi5 target system.

Closing due to lack of activity. OP, please re-open if futher issues noted. Thx!


remove beta reference from LocalStorageCapacityIsolation GA promotion

this seems to have been missed during the GA promotion in https://github.com/kubernetes/website/pull/35989

Thank you for the fix
/approve


NIFI-7650: Add basic focus management to UI

Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
This PR adds some basic focus management to the NiFi UI. This helps those using assistive technologies or keyboards navigate interactive elements on a page. When testing, you’ll notice the following changes:

A user is now able to tab through all of the interactive controls on the canvas page. This includes the components toolbar, global menu, navigate palette and operate palette.
The global menu is now navigable via the up and down arrow keys.
Focus is now trapped inside of modals as described in the wai-aria modal best practices document, as well as some shell dialogs (for example, Bulletin Board and Templates). Unfortunately, SlickGrid applies tab index to hidden elements it generates, which in turn breaks the code that traps focus inside of shell dialogs. This can be resolved by contributing to SlickGrid or switching to another package in the future. I created a Jira ticket to track the issue.
I applied the same :hover styling to :focus where possible, but some elements (such as the breadcrumb and bulletin button) do not have :hover styling.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[ ] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[ ] Has your PR been rebased against the latest commit within the target branch (typically main)?

[ ] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] Have you verified that the full build is successful on JDK 8?
[ ] Have you verified that the full build is successful on JDK 11?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.

Closing this PR in favor of smaller PRs that are easier to test.


Promisify function that returns some value and takes callback for result/error

I think that promisifying function that returns some value and takes callback for result/error makes result of this function lost, lets say there is some function that returns object for controlling this async process:
function doAsync(params, cb){
  ///...
  return {
    abort: function(){ /* ... */},
    // ....
  }
}

var process = doAsync({/* some params */}, function(err, result){
 // handle result or err
});

// something happens
process.abort();

now after promisifying this function I can't access this process object
var doAsyncPromised = Promise.promisify(doAsync);
doAsyncPromised({/* some params */})
  .then(function(result){
    // handle result
  }, function(err){
    // handle err
  });

so what I'm missing here is some callback that I could intercept this returned value
doAsyncPromised({/* some params */})
  .intercept(function(process){
    // something happens
    process.abort();
  })
  .then(function(result){
    // ...
  });

Maybe creating functions that returns value and calls callback is not the best pattern but some libraries doing that already exists (for example request).

Tried to use promisifyAll on sign.
jwt.sign({ foo: 'bar' }, cert, { algorithm: 'RS256' }, function(token) {
  console.log(token);
});

I end up getting the token value inside the error. ( because it doesn't have any error param)
Im quite new to promises. is it just me or is it really strange ?

@spacemonkey92 sounds like you're not actually using the promisified version.

That was the actual method.
jwt.signAsync({ foo: 'bar' }, cert, { algorithm: 'RS256' })
      .then((token)=>{
      console.log(token);
      })
      .catch((err)=>{
      console.log(err);
      });

This is going to the error block.
gives me this
{ [Error: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzZXNzaW9uSWQiOiJibGI1SEI1VWNqZElzNVR6c1ViR0RrOGxTWVJWQU5jWGh6QXkiLCJpYXQiOjE0NTcwOTkxNDAsImV4cCI6MTQ1NzEwMjc0MH0.V-ClT-in0dzyl1lGZ8vJh-F0Nn5fWxbXOqchhfUXOi-nsfkidN034FP-X7p-9qCl9s1WqE6_75d0WrTH5qVt-5mpKR310FJW0crf2ZDF3chXYf17_BpcqM72XotKmxi4lIaDOUlNyPxQcJeg4LX2HSKVLsGD1Aw62SsoClfGv3s]
cause: [Error: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzZXNzaW9uSWQiOiJibGI1SEI1VWNqZElzNVR6c1ViR0RrOGxTWVJWQU5jWGh6QXkiLCJpYXQiOjE0NTcwOTkxNDAsImV4cCI6MTQ1NzEwMjc0MH0.V-ClT-in0dzyl1lGZ8vJh-F0Nn5fWxbXOqchhfUXOi-nsfkidN034FP-X7p-9qCl9s1WqE6_75d0WrTH5qVt-5mpKR310FJW0crf2ZDF3chXYf17_BpcqM72XotKmxi4lIaDOUlNyPxQcJeg4LX2HSKVLsGD1Aw62SsoClfGv3s],
isOperational: true }


User should see pop to add webapp to homescreen

valid webapp manifest
android has native add to homescreen
iphone should show a short tutorial how to once in a while

@sirpy added the PR for manifest. Pending designs to be able to finish this.

@dminones implement something basic for android. you can use a Toast component

@sirpy so we should intercept and control this behavior as suggested on the post shared by fernando and not allow the browser use default behavior right?

@dminones lets start with the basics. if android has own prompt thats ok for now. no need for own design. but see if you can implement it in a modular way so it will be easy to change

@sirpy ok, this are my findings and test:
According to this chrome behavior (which matches with android behavior mostly) in new versions you get the "Mini-infobar" when meeting the criteria and regarding the preventDefault (so we cannot avoid this on init app but will be only shown once on 90 days)
https://developers.google.com/web/updates/2018/06/a2hs-updates
We can get this prompt reference and then use it in other places but we either just show it when we want to or we need custom ui to have a button to fire this
You can test this on this url, when entering to dashboard you should get a propmt
https://deploy-preview-532--good-dapp.netlify.com/AppNavigation/Dashboard/Home
Perhaps this options is too invasive, in that case we would need to add a similar ui to the iOS version and fire this prompt on click.
What do you think? @fernandomg @sirpy

i'll be working with Liav on the exact flow on monday

@dminones hey the flow to implement would be as follows:

on all platforms: by some TBD trigger: pop is displayed showing:

explanation text
button: maybe later
button: ok

if user press ok then
2.1 on desktop: activate prompt
2.2 on android: activate prompt with an overlay image that will probably be an arrow pointing to the toast that native android is showing at the bottom
2.3 on ios OR on android if we don't have the install prompt event (since user declined in the past or something) we show in the same popup the instruction on how to manually add to homescreen

@dminones
design here:
https://github.com/GoodDollar/GoodDAPP/issues/524#issuecomment-529793977
the first popup design is for the first time it is shown to the user, we keep a state the we showed the pop up to the user
if the pop display is triggered again at some other point in the future the second popup is shown.
for ios we overlay the small explanation popup

@sirpy what trigger should we use on the first version? Would be entering to dashboard ok?

@dariominones yes just make it easy to trigger from other places

@Nordwhale See https://github.com/GoodDollar/GoodDAPP/issues/524#issuecomment-529793977 for the design screens.
See also my last comment in the review of the PR https://github.com/GoodDollar/GoodDAPP/pull/532
The PR has been merged and reverted, so it needs to be recreated.
The implemented design in the PR/branch doesnt match the design.
on IOS we don't show instructions in the pop, once the user presses ok in the popup we show
the 3rd screen in the design which is a little popup overlay

Pop-up is work as per requirements and user can successfully add and launch app from homescreen.
Checked on Dev environment.

@yaroslav-fedyshyn-nordwhale needs to update when it is triggered to user.
@LiavGut I dont recall and can't find the logic we decided for the add to homescreen.
Can you explain when is the first trigger for the popup and if user presses later after how much time do we remind him.

@sirpy
As I recall, we decided that the popup will be triggered right after the loading of the dashboard finishes.
If the user presses 'later', then we should remind him after the next time he 'claim', but we should test that timing...


Error while launching.

hello I am facing this error when I do
roslaunch simulate_robot_rl simulate_robot.launch

for training and gazebo is also not getting open
python3 -m dqn_for_slam.rl_worker
/usr/bin/python3: No module named dqn_for_slam.rl_worker
[agent-8] process has died [pid 4391, exit code 1, cmd /home/arvind/rl_ws/src/ros_rl_for_slam/simulate_robot_rl/scripts/run_agent.sh __name:=agent __log:=/home/arvind/.ros/log/9990352e-aaed-11ec-9899-283a4d5b8bff/agent-8.log].
log file: /home/arvind/.ros/log/9990352e-aaed-11ec-9899-283a4d5b8bff/agent-8*.log

Solved just need to install  the given package manually


FlushTimeout may always return "nats: timeout" and connection stops dispatching

There is a race that could cause calls to Conn.Flush() and/or Conn.FlushTimeout() to always
return nats.Timeout error and make the connection stop dispatching incoming messages
and protocols, causing the server to break the connection as a Slow Consumer.

Was closed with an inadvertent push to master instead of branch. PR coming.


Add GitHub Issue and Pull Request templates

This pull request adds GitHub Issue and Pull Request templates that prompt contributors to add the necessary information (such as DITA-OT version, platform, transformation type, etc.) when creating issues and pull requests.
To test the templates, I created a dummy repository at infotexture/ot-issue-templates, where you can create a new issue or new pull request to see how the templates are used to populate the issue bodies.
Other changes:

Commit 3461558 moves the current CONTRIBUTING.md file to the new .github/ subfolder alongside the issue templates for a cleaner top-level structure.
8a8204d simplifies the contribution guidelines by removing the issue requirements (which are now in the template) and linking to the DCO explanation on the project website rather than including the DCO text verbatim.
f106082 updates a docs link in the ReadMe
06da706 cleans up the Markdown in the ReadMe (whitespace, indents, headings & reference links)

View the raw template files:

.github/ISSUE_TEMPLATE.md
.github/PULL_REQUEST_TEMPLATE.md

Jekyll issue template for reference https://github.com/jekyll/jekyll/blob/master/.github/ISSUE_TEMPLATE.md

👍 Yes, I think the contribution guidelines and “not a question” checkboxes make sense.
I like the intro the Jekyll templates provide and will add something similar to our templates too.
Based on recent experience, I'll also add a signoff checkbox to the PR template and link to our DCO page.

Addressed review feedback in 5b8e80b.

Shall we merge this now so issues & PRs for 2.5 onwards use the new templates?

@jelovirt 5b8e80b should cover your comments.
Ready to merge from my side, unless there are other changes you'd like to include.
(This is something we can easily refine later if we need to.)


Inspection.Autocomplete is missing 'in' and meta keywords

section foo; a = let b = 1 |
Autocomplete should include in, and meta.

This turned out to be a bigger issue. I'll be working on a fix for this. I hope to have a PR early next week.


TaskBuilder 2 release

This is a follow up on #15 to focus on how we release PR #14 .
TaskBuilder 1.1.1 (I think) already fixed @forki 's errors, the ones that #15 was originally about. It is stable.
1.1.1 and 1.2.0-rc have the same features and performance characteristics. They use the same underlying code for bind, tryFinally, etc. The difference is that thanks to @gusty rewriting the builder classes, 1.2.0-rc should work with older versions of the F# compiler, and will also be compatible if future versions of the compiler revert the type inference changes that came with F# 4.1. See the F# compiler issue. I consider this change good but not urgent, so we have time to do this smoothly.
TaskBuilder 1.2.0-rc is "source compatible" with code written for earlier TaskBuilders, but not binary compatible. I.E. if you upgrade you shouldn't have to edit any of your code -- BUT you will have problems mixing the two .dlls in one solution. If you have one project referencing 1.1.1 and another project referencing 1.2.0-rc, you can't then reference both projects in your web app or whatever. I don't think binding redirects fix this.
I do agree that 1.2.0-rc should have been versioned as 2.0.0-rc. When I versioned it I was only thinking about the source compatibility not the binary compatibility.
I guess we could take route 1 or route 2. Either way, the next version I publish will be 2.0.0.

Publish 1.2.0-rc as 2.0.0. and have Giraffe coordinate with their downstream users so everybody updates TaskBuilder together. This keeps the code clean but will cause a headache or two downstream.

Revise 1.2.0-rc to include both builders, with the new @gusty ones in a v2 namespace. Mark the old builders as obsolete. This is messy but smooth as it would make everything binary compatible.

To elaborate on route 2, suppose you currently you reference TaskBuilder 1.1.1. Upon upgrading to 2.0.0,  you would get warnings because you are using the obsolete builder in every file where you have a task {...} block. You would fix those warnings by changing open FSharp.Control.Tasks.ContextInsensitive to open FSharp.Control.TasksV2.ContextInsensitive. If you depend on a library that was written against 1.1.1, it will still work, because the builders in the old namespace still exist and there is no conflict between the two.
What's the preference of folks using this?

Isn't it possible to release a version 2.0.0 with slightly different namespaces, so if the end user is somehow accessing both versions everything works fine?

Yes, this is pretty much what "route 2" would be.
It's just a question of which is worse:
a. Changing the namespace for the V2 API
or
b. Dealing with a bumpy migration to V2

Very nice summary! I like both approaches and I'm open to apply both of them.
Only (minor) side effect of approach #2 is that when you mark the old builders obsolete I think it would be nice to presume that these obsolete builders will eventually disappear with a future 2.x.x release, which gives end users a smoother transition period to upgrade their namespaces to V2. However, if a 2.x.x release removes the old builders then it sort of doesn't make sense to have a single namespace called "V2".
Maybe approach #3 is identical to #2, except that the old builder's namespace will change to open FSharp.Control.Tasks.ContextInsensitive.Old and the new one remains open FSharp.Control.Tasks.ContextInsensitive.

I think that might work if we also change the DLL name, so that it's possible to have two TaskBuilder versions distributed with an app as two DLLs. Otherwise, code written against the old version wouldn't be able to resolve its class/method references against the new version DLL, with them having moved to another namespace.

Well, I've been dreading this and putting it off long enough, so it's time to wince and pull the trigger on 2.0.0.
The new code is under FSharp.Control.Tasks.V2 (e.g. FSharp.Control.Tasks.V2.ContextInsensitive).
This is what the the README now recommends.
The old code is under FSharp.Control.Tasks for compatibility.


Windows support?

I don't know if it's possible.
Is there a way to run this program on Windows?
Thanks!

Umm... I don't use Emacs on Windows so I don't too...
This library do not use OS APIs directly (for example, use git library to manipulate git repositories), so if these libraries support windows then this package does, too.


Issue when processing dataframes in which some rows have nearesrefmag as null.

ZTF-SIMPLE is at this moment unable to process data in which some rows (but not all) have nearestrefmag as 'null'. The program can handle the other cases where nearestrefmag for the whole sheet either has values or has none. I am currently working on a fix for this.

This issue has been fixed by modifying the txt_to_csv function to delete columns with null values before generating the csv that later dataframes use.

This issue has been fixed by modifying the txt_to_csv function to delete columns with null values before generating the csv that later dataframes use.


Android - Unable to bind VC in inji app

Describe the bug
Unable to bind VCs in specific devices (device details added at at last)
To Reproduce
Prerequisite:

VC is downloaded in inji app (UIN)
IDP is configured

Steps:

unlock the app
clicks on enabling verification link
Otp is prompted to enter
enter received Otp -> Otp matched

Expected behavior
All VC's should be able to bind without any errors
Observed
Unable to bind VC, projecting error message on specific device (device details added bellow)
Screenshots

Smartphone :
Device 1 :
Android version : 10
BLE version : BLE 5.0
device name : redmi note 10 lite
Device 2 :
Android version : 12
BLE version : 5.0
device name : vivo Y73
Remaining details :
MOSIP Version: <IP_ADDRESS>
MOSIP server: qa-1201-b2.net
APP link; https://github.com/mosip/inji/actions/runs/3986424542

Unable to replicate this issue anymore.
NO CODE fix made from dev team.
Please retest with the latest build.

Tested this issue on the new APK, and we are able to replicate this issue again, but its working intermittently and occurs in only a set of specific devices
Screenshot :

Smartphone :
Android version : 10
BLE version : BLE 4.2
device name : redmi 7A
Remaining details :
MOSIP Version: <IP_ADDRESS>
MOSIP server: qa-1201-b2.net
APP link; https://github.com/mosip/inji/actions/runs/4123991786

Tested this issue in the new APK,  unable to replicate the issue currently, I have tested it on devices where I was facing this issue since I am unable to replicate this issue iam closing right now
Smartphone :
Device 1 :
Android version : 10
BLE version : BLE 5.0
device name : redmi note 10 lite
Device 2 :
Android version : 12
BLE version : 5.0
device name : vivo Y73
Android version : 10
BLE version : BLE 4.2
device name : redmi 7A
Remaining details :
MOSIP Version: <IP_ADDRESS>
MOSIP server: qa-1201-b2.net
APP link; https://github.com/mosip/inji/actions/runs/4123991786


Missing parentheses for yield in condition of a ternary

(This is not a duplicate of #411.)
Input:
function*a(){(yield a) ? 1 : 2}

Output:
function* a() {
  yield a ? 1 : 2;
}

... which means:
function* a() {
  yield (a ? 1 : 2);
}

Expected:
function* a() {
  (yield a) ? 1 : 2;
}

This also applies to yield*.
https://jlongster.github.io/prettier/#{"content"%3A"function*a(){(yield a) %3F 1 %3A 2}"%2C"options"%3A{"printWidth"%3A80%2C"tabWidth"%3A2%2C"singleQuote"%3Afalse%2C"trailingComma"%3Afalse%2C"bracketSpacing"%3Atrue%2C"doc"%3Afalse}}
Found using the fuzzer.

Arg, I saw it parse, I thought it was parsing the same way! Good find


add Collapse support

Hi @beiliubei. Thanks for contributing! This is certainly a good addition. However, instead of having a label that is touchable, I would prefer a link (called “less”, analog to “more”)  that triggers the collapsing. What do you think?

@mkoehnke think of long long text label, The user needs to slide to the bottom, it is not convenient for the users

Yes, good point. Let’s keep it that way. Nevertheless, I’ll make the collapse behaviour optional with the default ‘disabled’. I will add some delegate methods to achieve that.


[Questen] no more support for spring-cloud-gateway-rsocket

Hello!
I'm sorry to ask this question in here, but since there is no activity in spring-cloud-incubator/spring-cloud-rsocket, I want to ask you something about it.
I think It's very nice solution to make a micro service architecture with RSocket. So I'm looking forward when it could move out from incubator.
Is it still not scheduled? and Are you working about some improvements like some retrying feature? I wish you have not forgot spring-cloud-rsocket.

Please see https://github.com/rsocket-routing


MC - (sidesheet) - the window to see punch / WO / etc is limited. make it bigger

Please can we expand the area where you can see punch / WO?
We have laods of space to use -> so lets use it :)
punch limited space

WO is also cut off

its not a showstopper, but would be nice for usablitly


Deprecate methods in AbstractChannel that have no real usage.

Motivation:
We should deprecate methods that are not used.
Modifications:
Add @Deprecated to methods
Result:
Be able to cleanup stuff sooner.

@Scottmitch @nmittler @trustin PTAL

lgtm

Cherry-picked into 4.1 (195d747) and 4.0 (7c2f1f5)


Feat/473: TypeaheadSelector component

https://github.com/jambonz/jambonz-webapp/issues/473
Created a new UI typeachead-selector component and used in application-select and account-select component
The features of the new component:
Key features:
- Input field with autocomplete functionality
- Dropdown toggle button with chevron icons
- Dropdown list of filterable options
- Keyboard navigation support
- Accessibility attributes (ARIA)

Thanks @rammohan-y , could you please help to attach an image about that component here :) I need it to validate on my local run

Thanks @rammohan-y , could you please help to attach an image about that component here :) I need it to validate on my local run

@xquanluu the new component will be reflected across webapp where account selection and/or application selection is involved. From UI point of view it looks similar to the selector component

@xquanluu can you pls review it

Hi @rammohan-y
Please check that font-size, font weight, and background, border is not aligned with orther component, could you make it more align as much as possible.

For functionality which is working very nice, just fix the styling then we are good to go

For functionality which is working very nice, just fix the styling then we are good to go

@xquanluu i fixed styles issue, but i did not understand the border alignment, I am seeing that the border is properly aligned, can you please help me find the issue with border alignment


Update sign documentation making support clearer

Adding the remark about non-supported platforms a clearer note to draw attention to it.

Docs Build status updates of commit 4299fd9:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/reference/cli-reference/cli-ref-pack.md
:warning:Warning
View
Details

docs/reference/cli-reference/cli-ref-sign.md
:white_check_mark:Succeeded
View

docs/reference/cli-reference/cli-ref-pack.md

Line 17: [Warning] Invalid file link:(~/consume-packages/package-references-in-project-files).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


meta object empty

Version
2.2.0
Reproduction link
https://github.com/gomonk3037/vue-chalkack
Steps to reproduce
Before
export default [
  {
    path: '/home',
    meta: { requiresAuth: true },
    name: 'UserPage',
    component: UserPage,
  },
];

Current
export default [
  {
    path: '/home',
    meta: { requiresAuth: true },
    component: UserPage,
    children: [
      {
        path: '',
        name: 'UserPage',
        component: MainPage,
      },
    ],
  },
];

What is expected?
Children inherit meta value of the parent router object
What is actually happening?
meta object empty in '/home' route & children route

Hi, thanks for your interest but Github issues are for bug reports and feature requests only. You can ask questions on the forum, the Discord server, gitter or StackOverflow.

Sharing your whole project as the repo is just too much... If you manage to boil it down in a jsfiddle, I can take a look

@posva https://jsfiddle.net/jm84numq/2/

I think this is by design, not a bug - although a way to access the parent route would be really nice.

Yeah, it's by design. Inheriting meta fields can be problematic. To get access to the meta fields of the parent, you have to look at the matched property


[Suggestion] CODEOWNERS

Reviewing PRs before accepting them is a good practice, especially in case of changes to security critical files.  GitHub repositories can be configured to automatically request someone if certain files were changed.  Therefore, a configuration file named .github/CODEOWNERS needs to be created appropriately.
With CODEOWNERS configured, the named people are always asked for review automatically when a new PR is submitted.  The user raising the PR does not need to select one or more reviewer(s) themselves when creating the PR because GitHub will select the respective users based on the CODEOWNERS settings.  In addition, merging is blocked automatically until all reviewers enforced by CODEOWNERS approved the PR.  IMPORTANT:  This feature prevents from unlocking the GitHub achievement "YOLO".
When using Dependabot on a repository with CODEOWNERS and preferring Mail Merging, I recommend to additionally configure Bors as it does not need to wait for all CODEOWNERS' approvals before merging a PR; instead, they can be mirrored to Bors' configuration file, at option, such that Mail Merging is still possible or can be processed differently.
@tobealive, are you interested?

Sounds good :+1: 🙂

CODEOWNERS is configured as follows:
* @tobealive

This will trigger an automatic review request for every PR.  The positive side effect is that you will always receive a notification in case Dependabot should forget to assign you.
Just add this line to .github/CODEOWNERS and the feature is activated.

Nice, thanks alot @kevinmatthes !


2.0: Empty modify being saved to JSON

Some users reported seeing empty modify values in their JSON. This seems to happen randomly during duplication, or other scenarios. My guess is this is related to the duplicate group issue that we had.
In any way, we should clear the modify just like we clear it if the studio.tokens or $extensions field is empty.
To reproduce

Go to JSON view
Paste this JSON

{
 "blue": {
    "value": "#ff0000",
    "type": "color",
    "$extensions": {
      "studio.tokens": {}
    }
  },
  "red": {
    "value": "#ff0000",
    "type": "color",
    "$extensions": {
      "studio.tokens": {
        "modify": {}
      }
    }
  },
 "valid": {
    "value": "#ff0000",
    "type": "color",
    "$extensions": {
      "studio.tokens": {
        "modify": {
          "type": "darken",
          "space": "srgb",
          "value": "0.5"
        }
      }
    }
  }
}

Notice that the "red" one keeps the empty modify.
Notice that the "blue" one correctly removes the empty extensions / studio.extensions field

Expected:
In this example only the "valid" token which has a non-empty modify piece is being kept, the rest should be removed, so the expected output would be
{
 "blue": {
    "value": "#ff0000",
    "type": "color"
  },
  "red": {
    "value": "#ff0000",
    "type": "color"
  },
 "valid": {
    "value": "#ff0000",
    "type": "color",
    "$extensions": {
      "studio.tokens": {
        "modify": {
          "type": "darken",
          "space": "srgb",
          "value": "0.5"
        }
      }
    }
  }
}

Just for some extra info on the experience with this bug
This is occurring across all token types. It occurs when I edit the name of a token and then rename variables as I save it. Attached are a few videos of the same issue across a view different token types
The result is the Figma cannot understand the value being passed and so it does not update the value.
To resolve it, i have to go into the JSON and remove any instances of this extension.
Reasonably frustrating one to my workflow, any idea when this will be resolved?
Thanks! 🙏
https://github.com/tokens-studio/figma-plugin/assets/100885654/12460aa8-0942-4212-bcae-0d8e0778d54e
https://github.com/tokens-studio/figma-plugin/assets/100885654/f0532332-0de2-43c3-a4cf-76f2281f23e3
https://github.com/tokens-studio/figma-plugin/assets/100885654/676e487e-fd0b-4998-8343-e47e49794914
https://github.com/tokens-studio/figma-plugin/assets/100885654/36ce5067-a5a1-49ae-84ec-305dad223b03


file:///tmp/browser.1293014077.html ERR_FILE_NOT_FOUND

I use it like this:
	request, err := http.NewRequest("POST", login_url, strings.NewReader(formData.Encode()))
	if err != nil {
		return err
	}
	request.Header.Set("Referer", login_url)
	request.Header.Set("Content-Type", "application/x-www-form-urlencoded")
	response, err := client.Do(request)
	if err != nil {
		return err
	}
	fmt.Printf("status code POST: %d\n", response.StatusCode)
	browser.OpenReader(response.Body)

The file /tmp/browser.1293014077.html contains the html.
But the browser seems to not find the file.
I use Chromium on Ubuntu Linux

The following example worked on macOS. If it worked for you too, you may have placed the files in an insecure directory.
package main

import (
	"log"
	"os"
	"path/filepath"

	"github.com/pkg/browser"
)

func main() {
	pathDirTmp, err := os.MkdirTemp(os.TempDir(), "sample_dir_*")
	if err != nil {
		log.Fatal(err)
	}

	pathFileTmp := filepath.Join(pathDirTmp, "sample_file.html")
	dummyContent := `<html><body>Hello World2</body></html>`

	// Create file under the temporary directory
	if err := os.WriteFile(pathFileTmp, []byte(dummyContent), 0644); err != nil {
		log.Fatal(err)
	}

	// Open the file in the browser
	// if err := browser.OpenURL(pathFileTmp); err != nil {
	// 	log.Fatal(err)
	// }

	// Open the file for reading
	osFile, err := os.Open(pathFileTmp)
	if err != nil {
		log.Fatal(err)
	}

	// Consume the contents and present the results in a browser
	if err := browser.OpenReader(osFile); err != nil {
		log.Fatal(err)
	}

	// Open the directory of the temporary file
	if err := browser.OpenURL(pathDirTmp); err != nil {
		log.Fatal(err)
	}
}

Env info

Google Chrome v104.0.5112.101
go version 1.18 and 1.19 (darwin/amd64)

You said "you may have placed the files in an insecure directory"
But I am using it like this:
browser.OpenReader(response.Body)

This means, that I am not explicitly putting the content into a directory....
I had a look at how this gets handled by Python, but that's a huge file: https://github.com/python/cpython/blob/3.10/Lib/webbrowser.py
Sorry, I need to leave now. Feel free to close this, if you don't have time and energy.

@guettli

But I am using it like this:
browser.OpenReader(response.Body)

Yes yes, that's why the file pointer is passed like this.

osFile, err := os.Open(pathFileTmp)
** snip **

err := browser.OpenReader(osFile)
** snip **

My point was that "Where was the temp file created?"
The path "/tmp/browser.1293014077.html" seems to be insecure. For example, on macOS, temporary files are created in private/var/folders.
file:///private/var/folders/8c/lmckjks95fj4h_jqzw4v3k_w0000gn/T/browser.140875179.html

The /tmp/browser.1293014077.html contained the response.Body value, so it is assumed that the OS or the browser is blocking it for security reasons. Not sure.
Try using os.MkdirTemp() and os.TempDir() to store the value of response.Body in a temporary directory. Then open it and look at the difference in paths.

Feel free to close this, if you don't have time and energy.

Unfortunately, I'm only a passer-by to help and don't have the privilege to close this issue.


Clashes with Google Optimize Anti Flicker Snippet

Recording this as a potential issue due to the popularity of Google Optimize.
Issue:
With the Google Optimize Anti flicker snippet installed on a page AND the cookie consent code from this repository, after choosing 'accept all', pages with scripts managed by cookie consent will then show a white screen for approximately 2-4 seconds before the first content renders on screen.
Background:
Google optimize is a popular tool to A/B test web pages.  One negative side effect of Google Optimize is the 'flicker' effect where content changes after page load (when the variant is switched in).  To alleviate this, Google provides a standard 'Anti Flicker' code snippet as a work around to this.  However, Google Optimize works in conjunction with Google Analytics & connects to a GA property - thus a cookie consent user may feasibly wish to manage the anti flicker code as well too.
Pre-conditions:

A web page with cookie consent code installed & configured and run as an 'As external script' as described here: https://github.com/orestbida/cookieconsent (e.g. page_scripts: true, with data-cookiecategory="analytics" added to third party, non-necessary cookie scripts.)

A website with the google optimize anti flicker snippet installed as per google documentation (e.g. very beginning of  tag) and the data-cookiecategory attribute added to the script include:

--
  |
  |
  |

Environments:

Google Chrome Latest, Mac OS X latest
Galaxy S9 - Chrome (latest)
(These are the only two I've tried, I'm sure there are others)

Steps to re-produce issue:

Choose accept all and the load the page again

Expected outcome:
The web page behaves as normal
Actual outcome:
On page load - a white screen shows for as long as 4 seconds
Notes:
Strangely, if you choose 'reject all' - this stops happening; or if I comment out the anti-flicker code, this also reverts back to normal.
Third Party Dependancies:
I Currently have GA, Google Optimize, Facebook login JS, and Hotjar installed.  'critical' css inlining (https://www.npmjs.com/package/critical)
Cookie Consent config:
cc = initCookieConsent();
    cc.run({
        current_lang : 'en',
        autoclear_cookies : true,                   // default: false
        cookie_name: 'cc_cookie_preferences',       // default: 'cc_cookie'
        cookie_expiration : 365,                    // default: 182
        page_scripts: true,                         // default: false

        // auto_language: null,                     // default: null; could also be 'browser' or 'document'
        // autorun: true,                           // default: true
        // delay: 0,                                // default: 0
        // force_consent: false,
        // hide_from_bots: false,                   // default: false
        // remove_cookie_tables: false              // default: false
        // cookie_domain: location.hostname,        // default: current domain
        // cookie_path: "/",                        // default: root
        // cookie_same_site: "Lax",
        // use_rfc_cookie: false,                   // default: false
        // revision: 0,                             // default: 0

        gui_options: {
            consent_modal: {
                layout: 'box',                      // box,cloud,bar
                position: 'bottom right',           // bottom,middle,top + left,right,center
                transition: 'slide'                 // zoom,slide
            },
            settings_modal: {
                layout: 'box',                      // box,bar
                // position: 'left',                // right,left (available only if bar layout selected)
                transition: 'slide'                 // zoom,slide
            }
        },

        onFirstAction: function(){
            console.log('onFirstAction fired');
        },

        onAccept: function (cookie) {
            console.log('onAccept fired ...');
        },

        onChange: function (cookie, changed_preferences) {
            console.log('onChange fired ...');
        },

        languages: {
            'en': {
                consent_modal: {
                    title: ' We use cookies! ',
                    description: 'Hi, this website uses essential cookies to ensure its proper operation and tracking cookies to understand how you interact with it. The latter will be set only after consent. <button type="button" data-cc="c-settings" class="cc-link">Let me choose</button>',
                    primary_btn: {
                        text: 'Accept all',
                        role: 'accept_all'              // 'accept_selected' or 'accept_all'
                    },
                    secondary_btn: {
                        text: 'Reject all',
                        role: 'accept_necessary'        // 'settings' or 'accept_necessary'
                    }
                },
                settings_modal: {
                    title: '',//'',
                    save_settings_btn: 'Save settings',
                    accept_all_btn: 'Accept all',
                    reject_all_btn: 'Reject all',
                    close_btn_label: 'Close',
                    cookie_table_headers: [
                        {col1: 'Name'},
                        {col2: 'Domain'},
                        {col3: 'Expiration'},
                        {col4: 'Description'}
                    ],
                    blocks: [
                        {
                            title: 'Cookie usage',
                            description: 'MirrorTrip uses cookies to ensure the basic functionalities of this website and to enhance your online experience. You can choose for each category to opt-in/out whenever you want. For more details relative to cookies and other sensitive data, please read the full privacy policy.'
                        }, {
                            title: 'Strictly necessary cookies',
                            description: 'These cookies are essential for the proper functioning of the website (E.g. to login or make a booking). Without these cookies, the website would not work properly',
                            toggle: {
                                value: 'necessary',
                                enabled: true,
                                readonly: true          // cookie categories with readonly=true are all treated as "necessary cookies"
                            }
                        }, {
                            title: 'Performance and Analytics cookies',
                            description: 'These cookies allow us to measure anonymous, aggregate data in order to optimize the MirrorTrip customer experience.',
                            toggle: {
                                value: 'analytics',     // there are no default categories => you specify them
                                enabled: true,
                                readonly: false
                            },
                            cookie_table: [
                                {
                                    col1: '^_ga',
                                    col2: 'google.com',
                                    col3: '2 years',
                                    col4: 'Used to distinguish users.',
                                    is_regex: true
                                },
                                {
                                    col1: '_gid',
                                    col2: 'google.com',
                                    col3: '1 day',
                                    col4: 'Used to distinguish users.',
                                },
                                {
                                    col1: '_hjid',
                                    col2: 'hotjar.com',
                                    col3: '1 year',
                                    col4: 'Used to analyze website usability.',
                                }
                            ]
                        }, {
                            title: 'More information',
                            description: 'For any queries in relation to my policy on cookies and your choices, please contact support.',
                        }
                    ]
                }
            }
        }

    });

Hi @gr9,
from what I understand, the antiflicker script might not behave well, unless loaded with a high priority (synchronous loading) and executed ASAP.

The anti-flicker snippet should only be installed inline – directly on your web page – and never with a tag management system (TMS) or another asynchronous script. If you can't install the anti-flicker snippet inline you should skip it altogether.

By adding data-cookiecategory you're delaying the execution.
Google also recommends installing Optimize through its own snippet, rather than via GTM:

We strongly recommend using the optimize.js installation method as it offers the best performance and is the easiest way to install Optimize.

Actual outcome:
On page load - a white screen shows for as long as 4 seconds

Based on this video/tutorial, it is a normal behavior. You could try modifying the snippet's 4000 ms to a shorter value.

Strangely, if you choose 'reject all' - this stops happening; or if I comment out the anti-flicker code, this also reverts back to normal.

This is expected, since you're not loading anything: analytics/optimize/antiflicker are all disabled.
I can't really help with optimize + antiflicker as it looks like they were not meant to be used with a consent tool.
There are a few threads regarding Google Optimize/Antiflicker Snippet and GDPR:
https://support.google.com/optimize/thread/71035930?hl=en
https://support.google.com/optimize/thread/118843232?hl=en
https://support.google.com/optimize/thread/93117284?hl=en
https://support.google.com/optimize/thread/7956883/cookie-consent-and-google-optimize?hl=en


REPLACE DEFAULT VALUE

Hi @yruslan
copybook looks like below
01 DATA-MASTER.
     02 RECORD-KEY    PIC X(03).
     02 REC-XFER-REASON PIC X(07).
     02. REC-VALUE  PIC 9(05) COMP-3 VALUE 0.

Incase of REC-VALUE is null, then how to do I replace value 0 ?

Hi, just to clarify. Do you want to replace nulls with zeros or the other way around?

Fill values in case of nulls which specified in copybook

You can post-process dataframes you get from Cobrix in this way:
val df = spark.read.format("cobol")...

// Replaces nulls in REC_VALUE with zeros
val df2 = df.withColumn("REC_VALUE", coalesce($"REC-VALUE", lit(0))


Refactor Lightstep code

This PR refactors lightstep driver out of http_tracer_impl into a separate file. This will simplify addition of zipkin driver ( #700 )
There is no functional change in this PR.
cc @RomanDzhabarov @fabolive

Yes I realized the same last night. Will push out another commit to
refactor the tests later today.
On Sat, Apr 8, 2017 at 12:55 PM Roman Dzhabarov<EMAIL_ADDRESS>wrote:

@RomanDzhabarov commented on this pull request.
nice! One comment, and i'll check in details in a bit
In source/common/tracing/http_tracer_impl.cc
https://github.com/lyft/envoy/pull/724#discussion_r110522546:

Http::MessagePtr message = Grpc::Common::prepareHeaders(driver_.cluster()->name(),

                                                       lightstep::CollectorServiceFullName(),

                                                       lightstep::CollectorMethodName());

message->body() = Grpc::Common::serializeBody(std::move(request));

uint64_t timeout =

   driver_.runtime().snapshot().getInteger("tracing.lightstep.request_timeout", 5000U);

driver_.clusterManager()

   .httpAsyncClientForCluster(driver_.cluster()->name())

   .send(std::move(message), *this, std::chrono::milliseconds(timeout));

}
-}

-LightStepDriver::TlsLightStepTracer::TlsLightStepTracer(lightstep::Tracer tracer,
Ideally, can you also move LS related tests (driver/etc) into separate
test files?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lyft/envoy/pull/724#pullrequestreview-31705336, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH0qd_UFB_EG9rqV5_T8r4hqQ56VlR-kks5rt7wSgaJpZM4M3lAb
.

--
~shriram


Edit Developer Guide

Consolidated all get commands and changed the sequence diagrams to show get commands that require parameters and get commands that only require a prefix
Updated user story for getting past appointments
Updated Logic component to reflect the logic flow of get commands

Codecov Report
Base: 66.19% // Head: 66.19% // No change to project coverage :thumbsup:

Coverage data is based on head (66367b1) compared to base (e365920).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #201   +/-   ##
=========================================
  Coverage     66.19%   66.19%
  Complexity      709      709
=========================================
  Files           116      116
  Lines          2355     2355
  Branches        295      295
=========================================
  Hits           1559     1559
  Misses          699      699
  Partials         97       97

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Saving caffemodel and solverstate

Hi! Always thank you for this great program. May I ask about saving caffemodel and solverstate?
I tried to save the trained model as .caffemodel and .solverstate files. It seemed that the snapshot of cifar10_quick_solver.prototxt did not work in SparkNet.
I found commented lines in CifarDBApp.scala:
if (i % 10 == 0) {
  net.setWeights(netWeights)
  net.saveWeightsToFile("/root/weights/" + i.toString + ".caffemodel")
}

But I could not understand how to use those lines. At the same time, it seems that many things have been changed with recent update so I guess even if I had found out how to use those lines, it would not be applicable to the new version of SparkNet.
I feel sorry to ask a question because I can see that you are very busy. A lot of code update! Thank you for always responding to my issue writings and questions.

Good point, saving models is critical, so we need to reintroduce that code (it's no longer in the master).
In the code snippet above, we first move the weights from the WeightCollection object netWeights into the Net object net. Then we call the net's method saveWeightsToFile which calls a caffe method that stores a snapshot of the weights.
We could save the WeightCollection object directly, but we probably want to provide an interface for reading/writing .caffemodel files so that SparkNet interfaces nicely with Caffe.

Thank you!


Deprecation issue fixed

Awesome, thanks a lot! We will release a new version including your pull request soon.

Implemented by 0916f1a3c0bb8837fb18584cd89b0a1c94b05018

Released as new version 1.3.1


Update at-time-zone-transact-sql.md

verified on SQL2016

@victren : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Cant download VSC to windows link not working

Cant dowload VSC for windows link in not working the redirect takes me to an empty page.

Does this issue occur when all extensions are disabled?: Yes/No

If you open the Developer Tools for your browser, do you see any input?
You can try this link as well https://aka.ms/win32-x64-user-stable.
Note that you would need to enable JavaScript to be able to download it.


[SDL1/2]: Resizing an OpenGL window trashes contents

SDL2.0.9RC2 - MiniGL2.23
A really bad bug in the SDL window drawing/resizing routine.
If i resize a window (with running OpenGL drawn contents) the contents gets trashed.
Not only that, if i switch back a trashed content window to fullscreen it stays trashed and won´t rectify itself, even after a scene change inside the app.
Can be tested with ResidualVM and the Grim Fandango Demo from here: http://demos.residualvm.org/grim-win-demo2-en.zip
See attached pictures:
Window Normal -> Window Resized -> Fullscreen -> Fullscreen Next Scene

Please try OS4 Depot version of MiniGL and retest. I will try to reproduce later (April?) with demo.

Since i can't build any new residualvm due to that dreaded png error, this may take some time

I just cloned residualvm yesterday, configured and built. I didn't see issue with PNG. Even if there would be issue, it should be possible to work around?
I can see the resize issue on MiniGL but it seems that window resize functionality requires the framebuffer objects. Disabling FBO capabilities in context.cpp on Linux, window content is no more resizable, even though the window itself is. There will be black borders.
So my question to you and ResidualVM devs: should window be resizable without FBOs?

Maybe it's because of the flags i use?
I have these LDFLAGS in envarc
-athread=native -Wl,-no-keep-memory -L/sdk/local/newlib/lib
and these CXXCFLAGS
--std=gnu++11
and i'm doing this when configuring
sh ./configure --enable-static
I just tried with gmake clean, it still breaks at the same position

Breaks how? I think I used GCC4 but don't remember (should work anyhow).

It errors out at the "image" bit when compiling the png part from sdlsurface (iirc).I can add the correct error output once I get back to the amiga.I tried to configure the png part out but the error is still there, probably because it's the png part from sdl and nit the one from residualvm.
-------- Original message --------From: capehill<EMAIL_ADDRESS>Date: 01/05/2019  10:51  (GMT+01:00) To: AmigaPorts/SDL<EMAIL_ADDRESS>Cc: Hubert Maier<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [AmigaPorts/SDL] [SDL1/2]: Resizing an OpenGL window trashes
  contents (#71) Breaks how? I think I used GCC4 but don't remember (should work anyhow).
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/AmigaPorts/SDL","title":"AmigaPorts/SDL","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/AmigaPorts/SDL"}},"updates":{"snippets":[{"icon":"PERSON","message":"@capehill in #71: Breaks how? I think I used GCC4 but don't remember (should work anyhow)."}],"action":{"name":"View Issue","url":"https://github.com/AmigaPorts/SDL/issues/71#issuecomment-488237921"}}}
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/AmigaPorts/SDL/issues/71#issuecomment-488237921",
"url": "https://github.com/AmigaPorts/SDL/issues/71#issuecomment-488237921",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

I'm using GCC 8.3.0...maybe that's the problem?Need to try and compile with GCC 4 to cross check if the error still exists.If not it could be a problem of the GCC 8.3.0 toolchain?
null

Tried with gcc 4.2.4, same issue on compiling
writePNG is not a member of image (something like that)
So, i'm still not able to compile a working exe of residualvm, sorry

I think you can disable USE_PNG for now as a workaround. I seem to have some wrong version of libPNG because configure fails to find it.

Did you try that?
Setting USE_PNG to NO ot OFF?
I did some time back and it still failed, because the problem lies in sdlsurface source and not in png (or so i think)
I will try again once my compiler is ready again and report back

Ok, so Bastien heard my pleads and "fixed" the PNG error even with --disable-png for me
https://github.com/residualvm/residualvm/commit/119ff7f2f3ec9c8cf7204fa54f5376212e014e47
I'm finally able to build both SDL1 and SDL2 residualvm again (with --disable-png in place, so no in-program screenshots).
I'm on to testing again, give me some minutes/hours and i'll report back

ResidualVM -SDL1 - behaviour cannot be tested because the window does not have a resize gadget!
ResidualVM - SDL2 - behaviour is still there
Test with original (OS4Depot) MiniGL.library doesn´t change it, still there!

If I understand it correctly, this is still open: "my question to you and ResidualVM devs: should window be resizable without FBOs?"
MiniGL doesn't have frame buffer objects. I tested on Linux and without FBOs, window content cannot be resized without FBOs.

Yes, i know and i apologize, but i haven't got an answer myself from the forums.
I have now sent a message directly to one of the maintainers, lets see...

Finalkly got an answer, hope it helps
quote:
On desktop we render directly to the default framebuffer (either a window or the full screen), no FBO is involved.
As the native resolution of the games are fixed, there is no reason to allow resizing.
There is also no code path that calls SDL_CreateWindow with the SDL_RESIZABLE flag, so the answer is a solid "no" on all fronts.

If i understand it correctly, window shouldn't be allowed to be resized at all?

quote:
I think it is SDL's task to inform the OS this window does not want to be resized.

Thanks for info. Obviously your window has the resize gadget so something has gone wrong :)

@capehill
You were spot on, that was the exact place where it adds the resize gadget.
PR opened on the ResidualVM codebase: https://github.com/residualvm/residualvm/pull/1574
And i guess this issue can be closed?
Thank you very much

Ok, but why change is only for AmigaOS 4? If the window is not supposed to be resizable, then it still is for other platforms?

True.
I was about to change it for every platform, but since i'm waiting for confirmation on the PR anyway i was hoping for discussion on why the RESIZABLE flag was set there in the first place.
Secondly it seems that only AmigaOS4 is affected by this, because i got zero feedback on the forums (guessing that this may mean no one else has this kind of problem.
And finally there may be the possibilty of a code snippet that deals with the resizable windows elsewhere (which "fix" it for all the other platforms), which i didn't want to ditch completely.

Changed in residualvms source now (see link above), albeit taking platforms with FBOs (and games who support resizing) into account, which leads me to the question, will minigl ever have FBOs in the future or are they mutually exclusive?

@raziel-  well nobody is actively working on MiniGL and even less with the classical Warp3D.

@capehill
Hmm, i thought Daytona Tool over MiniGL for his MiniGL/Warp3D reloaded (or something linke that) project.


PNA site to submit configuration

you mean the fact that we get keys from vault or files? that's just to make our transition to only-vault easier.  If you mean having to configure almost an identical YML for each server, yeah, i'm with you, we should come up with something better DRY-ish.

yea, the duplicate yml, not the keys in vault files.


On branch edburns-msft-ibm-382-apply-lessons

modified:   docs/howto-update-offer-in-partner-center.md

Commit 14058d8 is to fix the most recent deployment issue reported by @edburns and @venunathb. The root cause is that when the new version 1.2.1 of OLO is available, the startingCSV doesn't work with open-liberty-operator.v1.2.0 anymore. Updating to open-liberty-operator.v1.2.1 solves the issue.
Testing
Manually install the OLO 1.2.1 to verify if the change works:
oc apply -f open-liberty-operator-subscription.yaml
# subscription.operators.coreos.com/open-liberty-certified created

oc get deployment -n openshift-operators -w
#NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
#olo-controller-manager   0/1     1            0           16s
#olo-controller-manager   1/1     1            1           30s

The OLO 1.2.1 is successfully installed:

Hello @venunathb , this workflow succeeded. https://github.com/azure-javaee/azure.liberty.aro/actions/runs/5497592098 . I request you to please merge this PR.

@edburns @majguo
Minor comment, I thought the OLO version would be updated via automation.


To upgrade ingress-nginx helm chart version + cert-manager helm chart…

Hello.

nginx-ingress upgraded to latest helm chart available 4.0.15, app version 1.1.1
cert-manager helm chart upgraded to latest available 1.6.1, app version 1.6.1
added the spec.ingressClassName to ingress resources as the annotation kubernetes.io/ingress.class has been deprecated since k8s 1.18
Standardisation between azurecli and azurepowershell commands

@carvido1 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@carvido1 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@carvido1 Thank you for contributing to Microsoft Docs.
@Nickomang @lachie83 @zr-msft Could you review the proposed updates to your articles? Thanks.

Hello.
Do you want me to resolve the conflicts ? Seems this mr is getting old.

Hello. Do you want me to resolve the conflicts ? Seems this mr is getting old.

Hi @carvido1 - It looks like the two conflicting files are no longer in the repository, and they'll need to be removed from the PR. However, until a SME reviews the proposed update, more merge conflicts might develop.
@Nickomang @lachie83 @zr-msft Could you review the proposed updates to your articles? Thanks.

Thank you for the feedback and sorry for the delay.
These fixes have been addressed in other commits.
#please-close


Adding "share via email"

Hi there,
Great plugin, very well done!
I would like to know though, is it possible to add an extra option to share pages via email?
Thanks :)

Hi, Thank you!
Yes, I'm gonna add build-in email sharing soon. Thank you for the request!
For now it's easy to add it from out side with the code:

jsSocials.shares.email = {
    label: "E-mail",
    logo: "fa fa-envelope",
    shareUrl: "mailto:?subject={text}&body={url}",
    countUrl: ""
};

$("#share").jsSocials({
    shares: ["email", "twitter", "facebook", "googleplus", "linkedin", "pinterest"]
});

And add css, e.g. for the flat theme:
.jssocials-share-email .jssocials-share-link {
  background: #0a88ff; }
  .jssocials-share-email .jssocials-share-link:hover {
    background: #006ed6; }

Or even better to get the src, add the email color to _shares.scss, and build with grunt css for all themes:
$share-names: ('twitter', 'facebook', 'googleplus', 'linkedin', 'pinterest', 'email');
$share-colors: (#00aced, #3b5998, #dd4b39, #007bb6, #cb2027, #0a88ff);

Awesome, works perfectly.
Thanks! :)