 Mit Tasmota lässt sich alles einstellen, aber es geht kein An, kein Aus, keine Farbe, noch sonstiges. Sonoff B1 Modul oder ähnliche funktionieren auch nicht. Bei GPIO ... ist überall - None (00) -
Kann ich diese Lampe jetzt weg schmeißen oder gibt es noch Hoffnung mit Tasmota?
PS: Update geht auch alles.

Moin Nuggelbeb,
da muss ich, ohne sehr vorwurfsvoll wirken zu wollen, an den Artikelhinweis erinnern:"Sie sollten sich im Klaren sein, was es heißt, eine alternative Firmware zu flashen." Aber auch ich kenne den Drang, schnell loslegen zu wollen und dabei gelegentlich mal etwas zu wenig zum Thema zu lesen ;)
Du musst die Lampe jetzt natürlich nicht wegschmeißen, es gibt noch Hoffnung. Erstmal musst du das Geräteprofil auf "Generic" ändern, um alle GPIOs zuweisen zu können.  Es wäre toll, wenn Du dich anschließend nochmal mit den GPIOs hier melden würdest, damit wir diese ins Wiki aufnehmen können. Der nächste mit dieser Lampe muss dann nicht mehr suchen.
Gruß
Andi

Hi @Nuggelbeb
You can try the latest development build. We just implemented support for this type of RGB controller. https://github.com/arendst/Sonoff-Tasmota/pull/4991

mmm.,,, ich bin Anfänger und habe keine Ahnung
Also, habe das eingegeben und die Farbe blau ist schaltbar. (also nicht Schrott)
Modultyp = generisch
D3 GPIO0 => Keine
TX GPIO1 => Keine
D4 GPIO2 => Keine
RX GPIO3 => Keine
D2 GPIO4 => PWM1 (37)
D1 GPIO5 => PWM4 (40)
D6 GPIO12 => PWM2￼ (38)
D7 GPIO13 => PWM5 (41)
D5 GPIO14 => PWM3￼ (39)
D8 GPIO15 => Keine￼
D0 GPIO16 => Keine
Was muss ich da probier?

You'll need the latest development build to get this working and set the module type to SYF05

@kueblc  Sorry, ich bin das erste Mal hier auf GitHub, kenne mich noch nicht so richtig aus.
Wo finde ich das letzte Entwicklungsbuild? Das downloade ich dann und füge es in Tasmota als Update ein?

I recommend this guide on the Sonoff-Tasmota wiki for building the firmware. You can then use the firmware upgrade function in the web portal to upload your custom build.
It's safest to do your own build from source as you'll know exactly what's in the binary, plus you'll be able to predefined settings for your device and network.
If you have trouble with this I can build and upload a binary for you, but best learn to fish than to have a fish!

Ok, builden habe ich herausgefunden über Atom, aber was muss im Verzeichnis "Sonoff Tasmota" geändert werden?

You can customize your build in sonoff/my_user_config.h. Specify your WiFi credentials, your MQTT server, make sure USE_SM16716 is enabled, and turn off anything you don't need to save space. You'll want to keep the final binary below 512kb. You may also wish to modify platformio.ini to specify wish version to build, otherwise it'll build all of them and will take a long time.

Sry, aber welche letzte Binärdatei?

It will be in .pioenvs/sonoff(-DE)/firmware.bin

Okay firmware.bin ist fertig und auch geflasht.  Was stelle ich da noch ein?

Set the module type to SYF05 and you should be able to toggle power and change brightness via web portal, and also set color via MQTT.

Leider geht nichts. Sie schaltet nicht und Farbwechsel ist mit MQTT auch nicht möglich. Sie flackert ganz leicht.
ioBroker zeigt

Does the web page toggle not work at all? Does a slider appear?
Can you try to set GPIO13 to SM16716 PWR?
Also, try to send commands from the web console, such as color ff0000 or white 50.

mit GPIO13 - SM16716 PWR`geht An/Aus
Schieberegler ist da - aber geht nicht

Befehle von der Webkonsole

keine Änderung

Bei -white 50- geht sie aus
07:46:16 MQT: stat/sonoff/RESULT = {"POWER":"ON","Dimmer":49,"Color":"0,0,0,124","HSBColor":"0,0,0","Channel":[0,0,0,48]}

Okay sounds like your model is slightly different. Can you post any model numbers you can find on the bulb?
Let's go back to try to figure out the GPIOs then we can remap the SM16716 pins correctly. You said you were able to get a blue light before. Was that a light blue like a cold white or was it deep blue?
With model set to generic and GPIOs set to PWM channels like you had before, you can address each one individually with the command channel<x> <0-100> as in channel1 100. See if you can figure out what GPIO has which effect. Let us know the results!

 Für mich ist das alles noch Neuland. Dabei dachte ich, dass es einfach ist und schnell geht, aber naja.
Anbei sende ich erstmal ein Bild von der Lampe. Die Eingaben mache ich dann etwas später.

Hmm interesting, this indeed looks very different from https://github.com/gsimon75/Tasmota-SYF05-Notes/blob/master/led_board.jpg.
You can clearly see the ESP microcontroller on the right, same board as the LEDs and drivers, instead of on a dedicated board as Tuya distributes. From your picture front left I can identify a SLM211A constant current driver, which takes a PWM from the microcontroller. I'm not able to make out the large 8 pin chip in the back.
I don't see an SM16716 chip anywhere on here so that would explain why the SYF05 module isn't working for you. Once we identify the rear chip we'll have a better understanding of what this needs to drive the LEDs correctly.

Die Daten des Chips:
BHB31
25Q8CCSI
PP3338
Vielleicht können Sie mir doch noch helfen oder mir sagen, an wen ich mich wenden kann.
Danke nochmal.

Happy to help! Looks like the mystery chip is just some flash memory, not relevant for us.
Have you tried testing the individual GPIOs with channel<x> <level>? Any findings?

Leider nein.
 Weitere channels bringen keine Veränderung, nur die Anzeige - Command: unknown -
06:47:42 CMD: channel1 100
06:47:42 MQT: stat/sonoff/RESULT = {"POWER":"ON","Dimmer":100,"Color":"255,0,0,0,255","HSBColor":"0,100,100","Channel":[100,0,0,0,100],"CT":500}
06:48:37 CMD: channel1 50
06:48:37 MQT: stat/sonoff/RESULT = {"POWER":"ON","Dimmer":100,"Color":"127,255,0,0,255","HSBColor":"90,100,100","Channel":[49,100,0,0,100],"CT":500}

I have the same bulb    if set Tasmota to generic 18
GPI/O 4  PWM 1= white  and PWM3= blue
GPI/O 12 =green
GPI/O 13 =blue
GPI/O 14 = red
if set Tasmota to  Arilux LC11 Module
You can  change (some) colors with the cold/warm slider, brightness with the dark/bright slider
and toggle on/off.
I have a backup of the original firmware if it might be useful,but cant seem to attach files here ?

Can someone add this info to the  Queo compatible devices  Wiki  entry please
ChipID: 61dd05
MAC: B4:E6:XX:XX:XX:XX
SdkVersion: 1.5.3(aec24ac9)
BootVersion: 4
BootMode: 1
FlashMode: 1M DOUT @ 40MHz
FlashChipId: 1440c8
FlashChipRealSize: 1048576
FlashChipSize: 1048576
FlashChipMode: 3
system_upgrade_userbin_check: user2 0x81000

Trying a color picker wheel from Node-Red   can only get white and red and adjust brightness of them.
08:15:10 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":8,"Color":"000000050E","HSBColor":"0,0,0","Channel":[0,0,0,1,5],"CT":402}
08:15:11 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":7,"Color":"000000050C","HSBColor":"0,0,0","Channel":[0,0,0,1,4],"CT":402}
08:15:11 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":6,"Color":"000000040A","HSBColor":"0,0,0","Channel":[0,0,0,1,3],"CT":402}
08:15:11 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":5,"Color":"0000000309","HSBColor":"0,0,0","Channel":[0,0,0,1,3],"CT":402}
08:15:11 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":4,"Color":"0000000207","HSBColor":"0,0,0","Channel":[0,0,0,0,2],"CT":402}
08:15:11 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":4,"Color":"0000000207","HSBColor":"0,0,0","Channel":[0,0,0,0,2],"CT":402}
08:15:14 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":3,"Color":"0000000205","HSBColor":"0,0,0","Channel":[0,0,0,0,1],"CT":402}
08:15:14 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":2,"Color":"0000000103","HSBColor":"0,0,0","Channel":[0,0,0,0,1],"CT":402}
08:15:15 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":3,"Color":"0000000205","HSBColor":"0,0,0","Channel":[0,0,0,0,1],"CT":402}
08:15:15 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":8,"Color":"000000050E","HSBColor":"0,0,0","Channel":[0,0,0,1,5],"CT":402}
08:15:15 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":9,"Color":"0000000610","HSBColor":"0,0,0","Channel":[0,0,0,2,6],"CT":402}
08:15:15 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":10,"Color":"0000000712","HSBColor":"0,0,0","Channel":[0,0,0,2,7],"CT":402}
08:15:15 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":10,"Color":"0000000712","HSBColor":"0,0,0","Channel":[0,0,0,2,7],"CT":402}
08:15:20 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"F952FF0000","HSBColor":"298,68,100","Channel":[97,32,100,0,0],"CT":499}
08:15:22 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FF40860000","HSBColor":"338,75,100","Channel":[100,25,52,0,0],"CT":499}
08:15:23 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FF16D40000","HSBColor":"311,91,100","Channel":[100,8,83,0,0],"CT":499}
08:15:24 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FB27FF0000","HSBColor":"299,85,100","Channel":[98,15,100,0,0],"CT":499}
08:15:25 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"4662FF0000","HSBColor":"231,73,100","Channel":[27,38,100,0,0],"CT":499}
08:15:26 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"537BFF0000","HSBColor":"226,67,100","Channel":[32,48,100,0,0],"CT":499}
08:15:29 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FFFFFF0000","HSBColor":"0,0,100","Channel":[100,100,100,0,0],"CT":499}
08:15:30 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"9CFF560000","HSBColor":"95,66,100","Channel":[61,100,33,0,0],"CT":499}
08:15:33 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":94,"Color":"62EF000000","HSBColor":"95,100,94","Channel":[38,93,0,0,0],"CT":499}
08:15:34 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"FF2B800000","HSBColor":"336,83,100","Channel":[100,16,50,0,0],"CT":499}
08:15:38 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":4,"Color":"0A01050000","HSBColor":"333,90,4","Channel":[3,0,1,0,0],"CT":499}
08:15:41 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON","Dimmer":100,"Color":"61C5FF0000","HSBColor":"202,62,100","Channel":[38,77,100,0,0],"CT":499}
08:15:46 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"OFF"}
08:15:46 MQT: stat/Queo_Fcmila/POWER = OFF
08:15:48 MQT: stat/Queo_Fcmila/RESULT = {"POWER":"ON"}
08:15:48 MQT: stat/Queo_Fcmila/POWER = ON

Leider nein.
 Weitere channels bringen keine Veränderung, nur die Anzeige - Command: unknown -
06:47:42 CMD: channel1 100
06:47:42 MQT: stat/sonoff/RESULT = {"POWER":"ON","Dimmer":100,"Color":"255,0,0,0,255","HSBColor":"0,100,100","Channel":[100,0,0,0,100],"CT":500}
06:48:37 CMD: channel1 50
06:48:37 MQT: stat/sonoff/RESULT = {"POWER":"ON","Dimmer":100,"Color":"127,255,0,0,255","HSBColor":"90,100,100","Channel":[49,100,0,0,100],"CT":500}
tele/sonoff/STATE = {"Time":"2019-02-13T06:47:52","Uptime":"0T10:20:14","Vcc":3.403,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"ON","Dimmer":100,"Color":"255,0,0,0,255","HSBColor":"0,100,100","Channel":[100,0,0,0,100],"CT":500,"Scheme":0,"Fade":"ON","Speed":1,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"**********","BSSId":"E8:DF:70:C1:1F:8A","Channel":11,"RSSI":100}}

@Nuggelbeb Did you return the module to Generic and set the GPIO pins to PWMs? What were the settings you used?

I have a backup of the original firmware if it might be useful,but cant seem to attach files here ?

@johng2001 You can post it if you place it inside a .zip file first.

Can someone add this info to the Queo compatible devices Wiki entry please

The wiki is open to edits from the public.

@kueblc Ich habe jetzt folgendes eingestellt

und da bekomme ich

Lampe lässt sich ein- und ausschalten.   Warum? Müssen noch andere GPIO´s belegt werden?

An easy way to figure it out is to set each GPIO to a relay (1-8).  Then you turn each relay on and off and see what color shows on the bulb.  Once you figure that out, you set to PWM.
PWM1 = Red
PWM2 = Green
PWM3 = Blue
PMW4 = Cold White (I think)
PWM5 = Warm White (I think)
The whites could be swapped.

An easy way to figure it out is to set each GPIO to a relay (1-8). Then you turn each relay on and off and see what color shows on the bulb. Once you figure that out, you set to PWM.
PWM1 = Red
PWM2 = Green
PWM3 = Blue
PMW4 = Cold White (I think)
PWM5 = Warm White (I think)
The whites could be swapped.

mit welchen GPIO muss ich anfangen ?

Ah well this makes it tremendously straightforward :smile:
Set GPIO04 to PWM4, GPIO12 to PWM2, GPIO13 to PWM3, GPIO14 to PWM1. Then you should be able to set color with color <hex> via MQTT or the web portal, turn it on and off, and dim.

Ich bin raus. Lampe ist nicht mehr erreichbar. Programmiermodus - 3 x An/Aus - geht auch nicht und Serial geht auch nicht. Aber sie leuchtet weiß und blau blinkert.

I tried more things and managed to get Node-Red color picker working (I think) correctly
though the colors are correct they seem a bit dimer ( as if white is always mixed in )
Generic 18
???      I/O   2  = PWM 4
White   I/O   4  = PWM 5
Green  I/O  12 = PWM 2
Blue     I/O  13 = PWM 3
Red     I/O  14 = PWM 1
adjust the cold/warm slider  to bring back  pure white
dark/bright  works as expected.

I tried more things and managed to get Node-Red color picker working (I think) correctly
though the colors are correct they seem a bit dimer ( as if white is always mixed in )
Generic 18
???      I/O   2  = PWM 5
White   I/O   4  = PWM 4
Green  I/O  12 = PWM 2
Blue     I/O  13 = PWM 3
Red     I/O  14 = PWM 1
adjust the cold/warm slider  to bring back  pure white
dark/bright  works as expected.

Don't worry @Nuggelbeb, it's just reset it's configuration. Check to see if it's broadcasting a WiFi AP called sonoff-XXXX. Connect and reconfigure your WiFi settings at <IP_ADDRESS>.
What caused it to reset?

@johng2001 Do you have both cold and warm white LEDs in this bulb? When you define 5 PWMs, PWM4 is CW and PWM5 is WW.

I tried both PWM 4 and 5  into I/O 4 , the white looks the same to me... also  as long as  the remaining PWM is put into  any one of the unused I/O's  then  cold/warm slider can be used to bring back white
and  dark/bright slider  works as expected  from tasmota web page.
to get the colors I  use ( because it works and is easy)  Node-Red color picker  to send MQTT commands.
still can't attach files here (maybe my version of Firefox is not supported)

Best settings so far for me.
GPIO 2 PWM 4   (any unused I/O just to get slider + PWM 4 or 5 can be swapped seems same result)
pwm 4 should = cold white
GPIO 4 PWM 5 = white							pwm 5 should = warm white
GPIO 12 PWM 2 = green							pwm 2 should = green
GPIO 13 PWM 3= blue							pwm 3 should = blue
GPIO 14 PWM 1  = red							pwm 1 should = red
in node red color picker   format HEX + show  hue and lightness slider.
use cold/warm slider in Tasmota to return to White  obviously there is a MQTT command but
enough for now.

Don't worry @Nuggelbeb, it's just reset it's configuration. Check to see if it's broadcasting a WiFi AP called sonoff-XXXX. Connect and reconfigure your WiFi settings at <IP_ADDRESS>.
What caused it to reset?

Ja, ich habe bei den GPIOs rumgespielt und dann ging nichts mehr. Dann habe ich sie nicht mehr im Netz gefunden, auch unter <IP_ADDRESS> ist sie nicht zu finden. Hardwareseitig geht auch nichts mehr, Lötpins sind abgerissen und ging ja vorher auch nur über W-Lan.

If it still blinks, it's not dead! When you compiled your firmware, what was the value of WIFI_CONFIG_TOOL and WIFI_CONFIG_NO_SSID?

(These are found in my_user_config.h)

#define WIFI_CONFIG_TOOL       WIFI_RETRY
#define WIFI_CONFIG_NO_SSID    WIFI_WPSCONFIG

If your router supports WPS, press the button on your router and then power your bulb. It should hopefully reconnect and you'll be able to redo your configuration. If you know what combination of GPIO settings caused the last reset, let us know so we can avoid that again.

Leider hat das auch nichts gebracht. Die Lampe ist im 7. Himmel.
Ich glaube, ich habe auf GPIO 0 - Relay 1 oder so eingestellt. Leider weiß ich es nicht mehr, habe zu viel rumgespielt.

my node red setup for this bulb  flashed with Tasmota
[{"id":"fa350b71.b8ea2","type":"ui_switch","z":"27b0e016.c0e5a8","name":"","label":"ON / OFF","tooltip":"","group":"517aae8c.06068","order":18,"width":0,"height":0,"passthru":true,"decouple":"false","topic":"cmnd/Queo_Fcmila/power","style":"","onvalue":"on","onvalueType":"str","onicon":"","oncolor":"","offvalue":"off","offvalueType":"str","officon":"","offcolor":"","x":136,"y":2342.75,"wires":[["c0484a50.12baf"]]},{"id":"c0484a50.12baf","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"","qos":"","retain":"","broker":"2902344d.99c694","x":444,"y":2341.25,"wires":[]},{"id":"45da852.2fbdefc","type":"ui_slider","z":"27b0e016.c0e5a8","name":"Set Brightness","label":"SET BRIGHTNESS","tooltip":"","group":"517aae8c.06068","order":2,"width":0,"height":0,"passthru":true,"outs":"all","topic":"","min":"1","max":"100","step":1,"x":132.75,"y":2401.5,"wires":[["2e6aad51.34d77a"]]},{"id":"2e6aad51.34d77a","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/Dimmer","qos":"","retain":"","broker":"2902344d.99c694","x":548,"y":2461.75,"wires":[]},{"id":"f1ccb0ee.c896","type":"mqtt in","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/Dimmer","qos":"2","broker":"2902344d.99c694","x":849,"y":2457.25,"wires":[[]]},{"id":"ae8b953d.e7bf8","type":"ui_colour_picker","z":"27b0e016.c0e5a8","name":"Color Picker","label":"COLOR PICKER","group":"517aae8c.06068","format":"hex","outformat":"string","showSwatch":true,"showPicker":true,"showValue":true,"showHue":true,"showAlpha":true,"showLightness":true,"dynOutput":"false","order":1,"width":0,"height":0,"passthru":true,"topic":"","x":135.75,"y":2472.5,"wires":[["a461755b.a3599"]]},{"id":"73089cc.5176a64","type":"ui_dropdown","z":"27b0e016.c0e5a8","name":"Select Color","label":"SELECT COLOR","tooltip":"","place":"CHOOSE","group":"517aae8c.06068","order":4,"width":0,"height":0,"passthru":true,"options":[{"label":"RED","value":"eb0000","type":"str"},{"label":"GREEN","value":"00b80c","type":"str"},{"label":"BLUE","value":"0000CD","type":"str"},{"label":"WHITE","value":"0xFFFFFF","type":"str"},{"label":"ORANGE","value":"f52100","type":"str"},{"label":"PURPLE","value":"FF00FF","type":"str"},{"label":"YELLOW","value":"FFFF00","type":"str"},{"label":"AQUA","value":"00FA9A","type":"str"},{"label":"MAROON","value":"8B0000","type":"str"}],"payload":"","topic":"","x":140.75,"y":2536.5,"wires":[["a461755b.a3599"]]},{"id":"a461755b.a3599","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/color","qos":"","retain":"","broker":"2902344d.99c694","x":550,"y":2541.5,"wires":[]},{"id":"741c5d43.7f3b9c","type":"mqtt in","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/color","qos":"2","broker":"2902344d.99c694","x":849,"y":2541.75,"wires":[[]]},{"id":"d1a578a5.54674","type":"ui_button","z":"27b0e016.c0e5a8","name":"","group":"517aae8c.06068","order":5,"width":0,"height":0,"passthru":true,"label":"cycle color","tooltip":"","color":"","bgcolor":"","icon":"","payload":"3","payloadType":"str","topic":"cmnd/Queo_Fcmila/scheme","x":158.75,"y":2756.5,"wires":[["e3ae9a81.e6e7e"]]},{"id":"e3ae9a81.e6e7e","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"","qos":"","retain":"","broker":"2902344d.99c694","x":425.75,"y":2757.5,"wires":[]},{"id":"e1ffc018.53d6d","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/scheme","qos":"","retain":"","broker":"2902344d.99c694","x":648.75,"y":2755.25,"wires":[]},{"id":"1308eda3.df1dc2","type":"ui_button","z":"27b0e016.c0e5a8","name":"","group":"517aae8c.06068","order":6,"width":0,"height":0,"passthru":false,"label":"Rapid cycle color","tooltip":"","color":"","bgcolor":"","icon":"","payload":"4 speed 2","payloadType":"str","topic":"cmnd/Queo_Fcmila/scheme","x":181.75,"y":2828.25,"wires":[["6558acac.d4f3ec"]]},{"id":"6558acac.d4f3ec","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"","qos":"","retain":"","broker":"2902344d.99c694","x":425.5,"y":2827.5,"wires":[]},{"id":"3d0731d5.43c99e","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/scheme","qos":"","retain":"","broker":"2902344d.99c694","x":651.5,"y":2828.5,"wires":[]},{"id":"517aae8c.06068","type":"ui_group","z":"","name":"FCmilla Smart Bulb","tab":"43155387.db55dc","order":1,"disp":true,"width":"6","collapse":false},{"id":"2902344d.99c694","type":"mqtt-broker","z":"","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","willTopic":"","willQos":"0","willPayload":""},{"id":"43155387.db55dc","type":"ui_tab","z":"","name":"FCmilla Lamp Bedroom","icon":"dashboard","order":3,"disabled":false,"hidden":false}]

My Node red settings for this bulb ( mistake in first try)
[{"id":"fa350b71.b8ea2","type":"ui_switch","z":"27b0e016.c0e5a8","name":"","label":"ON / OFF","tooltip":"","group":"517aae8c.06068","order":18,"width":0,"height":0,"passthru":true,"decouple":"false","topic":"cmnd/Queo_Fcmila/power","style":"","onvalue":"on","onvalueType":"str","onicon":"","oncolor":"","offvalue":"off","offvalueType":"str","officon":"","offcolor":"","x":136,"y":2342.75,"wires":[["c0484a50.12baf"]]},{"id":"c0484a50.12baf","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"","qos":"","retain":"","broker":"2902344d.99c694","x":444,"y":2341.25,"wires":[]},{"id":"45da852.2fbdefc","type":"ui_slider","z":"27b0e016.c0e5a8","name":"Set Brightness","label":"SET BRIGHTNESS","tooltip":"","group":"517aae8c.06068","order":2,"width":0,"height":0,"passthru":true,"outs":"all","topic":"cmnd/Queo_Fcmila/Dimmer","min":"1","max":"100","step":1,"x":132.75,"y":2401.5,"wires":[["2e6aad51.34d77a"]]},{"id":"ae8b953d.e7bf8","type":"ui_colour_picker","z":"27b0e016.c0e5a8","name":"Color Picker","label":"COLOR PICKER","group":"517aae8c.06068","format":"hex","outformat":"string","showSwatch":true,"showPicker":true,"showValue":true,"showHue":true,"showAlpha":true,"showLightness":true,"dynOutput":"false","order":1,"width":0,"height":0,"passthru":true,"topic":"","x":135.75,"y":2472.5,"wires":[["a461755b.a3599"]]},{"id":"73089cc.5176a64","type":"ui_dropdown","z":"27b0e016.c0e5a8","name":"Select Color","label":"SELECT COLOR","tooltip":"","place":"CHOOSE","group":"517aae8c.06068","order":4,"width":0,"height":0,"passthru":true,"options":[{"label":"RED","value":"eb0000","type":"str"},{"label":"GREEN","value":"00b80c","type":"str"},{"label":"BLUE","value":"0000CD","type":"str"},{"label":"WHITE","value":"0xFFFFFF","type":"str"},{"label":"ORANGE","value":"f52100","type":"str"},{"label":"PURPLE","value":"FF00FF","type":"str"},{"label":"YELLOW","value":"FFFF00","type":"str"},{"label":"AQUA","value":"00FA9A","type":"str"},{"label":"MAROON","value":"8B0000","type":"str"}],"payload":"","topic":"","x":140.75,"y":2536.5,"wires":[["a461755b.a3599"]]},{"id":"a461755b.a3599","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/color","qos":"","retain":"","broker":"2902344d.99c694","x":550,"y":2541.5,"wires":[]},{"id":"2e6aad51.34d77a","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/Dimmer","qos":"","retain":"","broker":"2902344d.99c694","x":548,"y":2461.75,"wires":[]},{"id":"f1ccb0ee.c896","type":"mqtt in","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/Dimmer","qos":"2","broker":"2902344d.99c694","x":849,"y":2457.25,"wires":[[]]},{"id":"741c5d43.7f3b9c","type":"mqtt in","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/color","qos":"2","broker":"2902344d.99c694","x":849,"y":2541.75,"wires":[[]]},{"id":"c1b85ead.2a1ae","type":"comment","z":"27b0e016.c0e5a8","name":"built in tasmote color cycle","info":"","x":202.75,"y":2726.75,"wires":[]},{"id":"d1a578a5.54674","type":"ui_button","z":"27b0e016.c0e5a8","name":"","group":"517aae8c.06068","order":5,"width":0,"height":0,"passthru":true,"label":"cycle color","tooltip":"","color":"","bgcolor":"","icon":"","payload":"3","payloadType":"str","topic":"cmnd/Queo_Fcmila/scheme","x":158.75,"y":2756.5,"wires":[["e3ae9a81.e6e7e"]]},{"id":"1308eda3.df1dc2","type":"ui_button","z":"27b0e016.c0e5a8","name":"","group":"517aae8c.06068","order":6,"width":0,"height":0,"passthru":false,"label":"Rapid cycle color","tooltip":"","color":"","bgcolor":"","icon":"","payload":"4 speed 2","payloadType":"str","topic":"cmnd/Queo_Fcmila/scheme","x":181.75,"y":2828.25,"wires":[["6558acac.d4f3ec"]]},{"id":"e3ae9a81.e6e7e","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"","qos":"","retain":"","broker":"2902344d.99c694","x":425.75,"y":2757.5,"wires":[]},{"id":"6558acac.d4f3ec","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"","qos":"","retain":"","broker":"2902344d.99c694","x":425.5,"y":2827.5,"wires":[]},{"id":"3d0731d5.43c99e","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/scheme","qos":"","retain":"","broker":"2902344d.99c694","x":651.5,"y":2828.5,"wires":[]},{"id":"e1ffc018.53d6d","type":"mqtt out","z":"27b0e016.c0e5a8","name":"","topic":"cmnd/Queo_Fcmila/scheme","qos":"","retain":"","broker":"2902344d.99c694","x":648.75,"y":2755.25,"wires":[]},{"id":"517aae8c.06068","type":"ui_group","z":"","name":"FCmila Smart Bulb","tab":"43155387.db55dc","order":1,"disp":true,"width":"6","collapse":false},{"id":"2902344d.99c694","type":"mqtt-broker","z":"","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","willTopic":"","willQos":"0","willPayload":""},{"id":"43155387.db55dc","type":"ui_tab","z":"","name":"FCmila Lamp Bedroom","icon":"dashboard","order":3,"disabled":false,"hidden":false}]

Unfortunately sounds like @Nuggelbeb's bulb is bricked, so no amount of configuration assistance would resolve this. Closing, if there's any further questions please open a new issue on the relevant project.

Hi in witch mode should the bulb are for the the tuya converter?Fast or short blinking?

Работает отлично


feat: add support for regex match in AutoMod

Please describe the changes this PR makes and why it should be merged:
This PR adds support for regex matching in auto moderation.
If applicable, please reference Discord API Docs PRs or commits that influenced this PR:

https://github.com/discord/discord-api-docs/pull/5504

Upstream PR merged.


Automation that bumps versions after a package has released

The pipeline and basic version bumping automation has been implemented for all languages now.


Scale up audio block

Hello, can you please suggest what layers I need to add to scale up audio encoder? thanks

yes, it can work


SqlClient's transient error handling strategy going forward?

Is your feature request related to a problem? Please describe.
Recently saw https://github.com/dotnet/SqlClient/pull/307 being discussed but was closed in an effort to add some retry support to SqlClient.
This is very much needed, as I feel there is no out of the box retry support for SqlConnection / SqlClient today to combat transient connectivity issues.
Focusing specifically on connecting to Azure SQL, which has pretty terrible connectivity issues, where connections can break and commands can fail mid flight during maintenance operations. Just google "SQL Azure retries" and you will find an abundance of deprecated, copy/paste code, DIY strategies, etc.
As SqlClient / DbConnection / DbCommand / etc classes are either not inheritable or behind interfaces there are problems in implementing retry support today and handing off "resilient" connection instances to application and library code, where they don't need to make any code changes.
There seems to be some support in EF as per https://docs.microsoft.com/en-us/ef/ef6/fundamentals/connection-resiliency/retry-logic but otherwise you are on your own, as documented by https://docs.microsoft.com/en-us/azure/architecture/best-practices/retry-service-specific#sql-database-using-adonet
All examples of providing retry logic on Azure / MSDN for example are incomplete, not practical, or forget about library code. This unfortunately is due to SqlClient not being flexible enough to support this kind of logic.
Describe the solution you'd like
Simple, out of the box, "pit of success", connection and command execution resiliency support for SqlClient.
Automatically handle the generic and SQL Azure specific connectivity issues, with proper backoff support, etc, and optional events to notice when a connection reconnect was required to let the application make a decision and provide logging.
A perfect solution to me feels like simply passing in an IErrorHandlingStrategy interface (example name) to the constructor of SqlConnection, which is invoked when there are SQL errors during connection/command execution that require a decision to be made (retry? backoff?) based on the exception.
By default, we could have No Strategy (existing behavior), or Azure Strategy, which knows to handle its bunch of connectivity errors (of which there are many).
Then downstream code has no idea about the retry strategy. It needs no code changes. Applications dont need further changes either. It just works.
Describe alternatives you've considered

Manually wrapping our code in Polly retry blocks when hitting the database (via extension methods such that command.ExecuteAsync becomes command.ExecuteAndHandleErrorsAsync etc). This makes our code messier to write and also means downstream library code we use is not fixed as we cannot change what method they call.

Attempting to inherit SqlClient / SqlConnection / DbCommand / etc and implement retry logic by overriding appropriate methods. This is not possible because some classes are sealed, and some methods are not virtual.

Additional context
There is unfortunately no clear way to implement reliable resiliency logic today that flows between app code and library code seamlessly due to SqlClient and friends being sealed or not having appropriate methods override-able.
It would be fantastic to discuss what a reasonable approach could look like to implement retry support.
I appreciate it is very nuanced, for example, what if a command fails mid-transaction -- retrying via reconnect is not necessary a correct thing to do, but with perhaps appropriate hook points the application can make a decision.

Hi @Plasma
We discussed the ideas from proposed PR #307, and we have new design ideas that would be addressed by creating a pluggable add-on.
@scoriani would you like to share update regarding progress on the same?

Thanks @cheenamalhotra!
Hey @Plasma, yes original PR was closed as we're working on a more robust and pluggable design for embedded retry logic. Basically, the ideas is to adopt a provider-based approach, where out-of-the-box there will be a "default" retry logic provider that can be associated to SqlConnection and SqlCommand operations, but anyone can implement his own provider with custom logic.
Default provider will come with some pre-defined strategies (e.g. fixed interval, exponential backoff, etc.) and error detection strategies, but these can be replaced/extended in custom providers.
Don't have a precise ETA yet, due to some internal re-prioritization happening, but when ready will create a new PR for review.
HTH

That sounds great, thank you.
If I may, let me point out an edge case to consider, if an application gets a SqlConnection, and the app then initializes that connection (for example, to set the security/session context on the connection), if a DbCommand/SqlConnection disconnects and a retry is invoked,  we would want a way to detect a connection has been re-established.
For example, perhaps a "On connection re-established" hook point also, so the necessary context can be (re)configured before the underlying command is retried (without the right context) - or something like that.
Thank you

That is actually a great point that we're considering and, possibly, extend even further with the idea of a server-side session that can survive network disconnections, and client libraries that can automatically re-establish connectivity and "re-hydrate" existing context in a fully transparent mode. That said, "connection re-established" hook will give devs the ability to inject their own logic there.

See the ongoing discussion about resilience in database drivers in general: https://github.com/dotnet/runtime/issues/34817
Although it's very understandable to want a driver solution that "just works" without any application changes, it's important to realize that there are some real complications here. See especially https://github.com/dotnet/runtime/issues/34817#issuecomment-613031842 and https://github.com/dotnet/runtime/issues/34817#issuecomment-613051180. Specifically:

if you have issued 3 commands and the 4th fails due to error 1205 (result streaming) you have to retry all 4, if they're in the same transaction.

A driver-only solution would have to internally track all commands which have been executed against the transaction, and be able to retry them upon transient failure. Even then, what happens if the user has already read the results for the first three commands (and half of the fourth)? Does the driver read and discard all that information in the second pass, and somehow resume in the right place in the middle of the fourth resultset? What happens if the actual data in those resultsets has changed, since a new transaction was started and the database has been changed in the meantime?
These problems seem extremely complicated, and possibly insurmountable at the driver level, without any sort of application knowledge/handling.

That is actually a great point that we're considering and, possibly, extend even further with the idea of a server-side session that can survive network disconnections, and client libraries that can automatically re-establish connectivity and "re-hydrate" existing context in a fully transparent mode. That said, "connection re-established" hook will give devs the ability to inject their own logic there.

Correct me if I'm wrong, but doesn't the DbConnection state change event already provide a way to inspect if the connection was previously open and is going to be closed (before and after states)?   I would think the event handler would be where the developer would hook in and perform logic.
Is the idea to provide more contextual information to state change event or some other mechanism?

Closing issue as Configurable Retry logic support is now released with v3.0.0-preview1.
Furthermore, seamless reconnection (connection resiliency) abilities during command execution are not supported by SqlClient as it also requires support from server, which is not available at the moment.


RESTful client should retry on UnknownHostException

:mag: Description
Issue References 🔗

When deploying Kyuubi as StatefulSet on Kubernetes, during the rolling upgrade, the Pod stops and creates one by one, and there are a few durations that the Pod is not available, then UnknownHostException is returned.
2024-02-23 23:04:45 [ERROR] [KyuubiRestFrontendService-122] org.apache.kyuubi.client.RestClient#189 - Error:
java.net.UnknownHostException: kyuubi-2.kyuubi-headless.spark.svc.cluster.local
	at java.net.InetAddress$CachedAddresses.get(InetAddress.java:764) ~[?:1.8.0_382]
	...
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:140) ~[httpclient-4.5.14.jar:4.5.14]
	at org.apache.kyuubi.client.RestClient.doRequest(RestClient.java:181) ~[kyuubi-rest-client-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at org.apache.kyuubi.client.RestClient.get(RestClient.java:80) ~[kyuubi-rest-client-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	...
	at org.apache.kyuubi.client.BatchRestApi.getBatchLocalLog(BatchRestApi.java:104) ~[kyuubi-rest-client-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at org.apache.kyuubi.server.api.v1.InternalRestClient.$anonfun$getBatchLocalLog$1(InternalRestClient.scala:57) ~[kyuubi-server_2.12-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at org.apache.kyuubi.server.api.v1.InternalRestClient.withAuthUser(InternalRestClient.scala:81) ~[kyuubi-server_2.12-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at org.apache.kyuubi.server.api.v1.InternalRestClient.getBatchLocalLog(InternalRestClient.scala:57) ~[kyuubi-server_2.12-<IP_ADDRESS>.jar:<IP_ADDRESS>]
	at org.apache.kyuubi.server.api.v1.BatchesResource.$anonfun$getBatchLocalLog$4(BatchesResource.scala:424) ~[kyuubi-server_2.12-<IP_ADDRESS>.jar:<IP_ADDRESS>]

Describe Your Solution 🔧
Treat UnknownHostException as a retriable exception to tolerant the transient Pod FQDN not available cases during rolling upgrade on K8s.
Types of changes :bookmark:

[x] Bugfix (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)

Test Plan 🧪
Pass GA.

Checklist 📝

[x] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

cc @turboFei and @lightning-L, have you meet the similar issue?

yes

It happend after recreating pods.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 61.07%. Comparing base (1adf392) to head (0df3883).

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #6081      +/-   ##
============================================
- Coverage     61.12%   61.07%   -0.05%
  Complexity       23       23
============================================
  Files           623      623
  Lines         37206    37206
  Branches       5041     5041
============================================
- Hits          22743    22725      -18
- Misses        12012    12018       +6
- Partials       2451     2463      +12

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

Merged to master/1.8


Enormous heap when iterating over 10million records

I'm getting a very large heap when doing a simple count of all the records in the DB.
I have a little over 10 million records in the DB. Below is the code I'm using:
ldbCount :: DB.DB -> ResourceT IO ()
ldbCount db =
  DB.withIterator db
                  def
                  (\ i -> do
                      let stream = DB.keySlice i DB.AllKeys DB.Desc :: DB.Stream (ResourceT IO) DB.Key
                      totalCount <- DB.foldl' (\c _ -> c + 1) (0::Int) stream
                      liftIO . putStrLn $ show totalCount
                  )

Here is the output when using stack exec -- count db_dir +RTS -s
  6,385,123,872 bytes allocated in the heap
  1,770,246,472 bytes copied during GC
     459,767,960 bytes maximum residency (12 sample(s))
         3,930,216 bytes maximum slop
             845 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0     11952 colls,     0 par    1.856s   1.752s     0.0001s    0.0063s
  Gen  1        12 colls,     0 par    1.408s   2.037s     0.1697s    0.9557s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time   15.436s  ( 16.567s elapsed)
  GC      time    3.264s  (  3.789s elapsed)
  EXIT    time    0.012s  (  0.080s elapsed)
  Total   time   18.748s  ( 20.435s elapsed)

  %GC     time      17.4%  (18.5% elapsed)

  Alloc rate    413,651,455 bytes per MUT second

  Productivity  82.6% of total user, 81.5% of total elapsed

The database itself is only 2.5G. Could there be a memory leak of some kind that allows the heap to grow so large or have I made a naive assumption in the implementation?

There was a mistake with my stack exec command not rebuilding with profiling so I was testing an old version of my program.


Classifying reversion mutations

We thought it would be a good idea to get a handle on revertants (i.e. mutations whose derived state is equivalent to the state of their parent mutation). We think these are mostly erroneous, so it would be good to identify what's going wrong. We could classify them by the nodes they are above (e.g are they above a recombinant, or a reversion push)

We have code for classifying mutations as reversions here so I think we want two things:

A plot to summarise the path length and time back to the thing its reverting (i.e., either the parent mutation, or the root. All mutations have a time in sc2ts). So, I guess a method giving a histogram of these two things would be a useful thing to add to the TreeInfo
A plot to classify the types of nodes that these reversions happen on. A simple first thing to do would be to do a bar chart with the categorial axis is the node flags. This would also be a useful thing to add to the TreeInfo

I think it's handy to add these QC-type functions to the notebooks/qc-template as they are done, so that we have something that you can run on a new set of trees to get an overall view of the quality.


drivers: WINC1500: issues with buffer allocation when using sockets

While using the sockets library with WINC1500 (which is offload), the driver is not able to allocate more buffers after calling connect(). I'm using a nrf52840 and WINC1500 is able to scan, connect and disconnect from WiFi Networks.
Here is the log I got:
[00:00:01.778,991] <dbg> net_sock.zsock_socket_internal: (0x200010b8): socket: ctx=0x20001568, fd=0
[00:00:02.280,822] <dbg> wifi_winc1500.winc1500_socket_cb: sock 0 Msg 1 Bind socket event.
[00:00:02.289,978] <dbg> wifi_winc1500.winc1500_socket_cb: sock 0 Msg 5 Connect socket event.
[00:00:02.289,978] <err> wifi_winc1500: CONNECT: socket 0 error 0
(APP)(INFO)Sock to delete <0>
[00:07:37.029,846] <err> wifi_winc1500: Could not allocate data buffer
[00:07:37.029,846] <err> wifi_winc1500: Could not reserve packet buffer

And the code that generates it:
    struct sockaddr_in addr;
    int ret, sockfd;
    static char buf[64];

    sockfd = socket(AF_INET, SOCK_STREAM, 0);

    addr.sin_family = AF_INET;
    addr.sin_port = htons(SERVER_PORT);
    inet_pton(AF_INET, SERVER_IP, &addr.sin_addr);

    ret = connect(sockfd, (struct sockaddr *)&addr, sizeof(addr));

    if(!ret){
        printf("Connected!\n");
        snprintk(buf, 12, "Hello World");
        send(sockfd, buf, 12, 0);
    }else{
        printf("Error: Connect failed\n");
        goto close;
    }

close:
    close(sockfd);
    wifi_disconnect();

After some debugging, discovered that connect() calls recv() under the hood. And that the issue resides in the fact that recv() is taking a buffer out of the pool (L569) without putting it back again.
https://github.com/zephyrproject-rtos/zephyr/blob/888ce377995715e0d7e8620af8f4010ee12625d7/drivers/wifi/winc1500/wifi_winc1500.c#L555-L585
I solved my issue temporary by increasing the pool size, but I don't think that is the right solution. My question is: Is recv() supposed to not give the buffer back to the pool and I'm missing something out?

This seems really interesting. The last time I had a look at the driver it had the feeling that it was a proof of concept with a lot of workarounds. I do not have any of the hardware anymore so I cannot reproduce it myself.

@diocorreia Just hit into same issue. Do you find any correct way to get the buffer back?

@aectaan No, I haven't found other solution than this. I have simply changed WIFI_WINC1500_BUF_CTR to 2.

I am experiencing the same issue, recv() fails on not having enough space on buffers. I tried with
CONFIG_WIFI_WINC1500_BUF_CTR=2
CONFIG_WIFI_WINC1500_MAX_PACKET_SIZE=10000

But doesn't seem to work either. I'm on a nRF5340. Any suggestion on this?


Jitwei98/storage component

good job in the storage code. Please add test cases for the storage component, thanks!

Please write the test cases for storage components!

Erm I wrote it while adding each methods


doc changes for 2.1 release

Description of Change
We have the 2.0.x plugin on NuGet for about 7 months, and all issues reported since then are resolved, so I think we should do a non-beta 2.1 release. In this PR I updated the changelog and the NuGet package data for a 2.1 release.
@jfversluis  You may have to adjust the final version number afterwards, the version number 2.1.18 was just my guess and depends on if the beta build automatically increments the version number.
Issues Resolved
none
Platforms Affected
all

It should publish any minute!

Yay, thank you! And I even got the version number correct :-)


[Esint] Fixing linting on './plugins'

Fixing linting rules on './plugins' folder

Require order is important on some tests - fixed

💯 ✨  Thanks for fixing these


Implement Display for num_bigint::Sign

Here's an example.
Tests have been added

Did you know you can get almost the same effect with "{:+}" format?  Except that a zero will be printed as "+0", just like primitive integers do, unlike what you've done for NoSign.
So your example shows how to use it, but I'm looking for why you need it.

Oh I don't need it in that case, thanks (you may close this PR if you want)

OK, thanks anyway!


Disable aria allowed attr

This should remain disabled until we can upgrade to using axe-core 3.1.1. The current version does not recognize certain attributes as appropriate for certain roles that we use together and will cause failures to this rule.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #465   +/-   ##
=======================================
  Coverage   99.42%   99.42%
=======================================
  Files          71       71
  Lines        1914     1914
  Branches      305      305
=======================================
  Hits         1903     1903
  Misses         11       11

Flag
Coverage Δ

#builder
100% <ø> (ø)
:arrow_up:

#runtime
95.98% <ø> (ø)
:arrow_up:

#srcapp
100% <ø> (ø)
:arrow_up:

Impacted Files
Coverage Δ

config/axe/axe.config.js
100% <ø> (ø)
: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 ed55460...dfe44d7. Read the comment docs.

Related issue: https://github.com/blackbaud/skyux2/issues/1964


Record of listing copy

As a part of the listing duplication feature, we need to store a record of if a listing was copied and what it was copied from, and surface it in the listing export.
AC:

We can surface a "Copy or Original" column and a "Copied from" column in the listing export

Technical Notes:

https://github.com/prisma/prisma/issues/991

Might need to do some discovery to relate the listing table to itself - relate two ids on the same tabs
If it's supported by Prisma, use that
If that doesn't work, just make it a string field on the DB

@sarahlazarich should the Copied From field show the original listing's name or id? Listing names are technically not unique

@mcgarrye let's do listing ID

Cannot be QA'ed by Product


usermessagingplatform.framework does not support the minimum os version specified in the info.plist.

usermessagingplatform.framework does not support the minimum os version specified in the info.plist.
admob 11.3, 11.2
xcode: 15.3
mac: 14.4.1

how did you fix this issues. It seems to work fine for me in cocoapods but i get this error with SPM

how did you fix this issues. It seems to work fine for me in cocoapods but i get this error with SPM

I also had a problem with SPM.
I checked and found out that the AdMob I added was the latest version, but the AdMob's dependency libraries were not up to date. So I went ahead with the update.
In my case the problem wasn't solved by deleting and reinstalling AdMob,
I solved it through "Update to Latest Package Version" in the left menu of Xcode.


Fix git push error for protected CLA branch

The pull request is created from master636922433317454799 to master to fix git push error for protected CLA branch

@gewarren : Thanks for your contribution! The author, @, has been notified to review your proposed change.


Updated namechanger to use HTTPS

Thank you for the contribution. It was merged directly as 73ebe20d6fd17bdbcb81d54079670dd95540f7eb to keep commit history cleaner. Your contribution is still credited to you.


Static builds fails to load awssdk package

When I build my project statically after editing my cmakelists.txt file to include find_package(AWSSDK REQUIRED COMPONENTS S3), cmake fails with below. I tried passing CMAKE_PREFIX_PATH and CMAKE_INSTALL_PREFIX after looking around but no luck.
If I pass BUILD_SHARED_LIBS=ON to my build, cmake works but its globally applied to my project which we don't want.
I built and installed the SDK in /usr/local/lib by default.
cmake ../aws-sdk-cpp -DBUILD_ONLY=s3
Workaround:
sudo vi /usr/local/lib/cmake/AWSSDK/AWSSDKConfig.cmake
set(BUILD_SHARED_LIBS "on")
If I need to follow some steps, I will be happy to try it out.
What platform/OS are you using?
Ubuntu
Which version of the SDK?
Found AWS SDK for C++, Version: 1.7.266
What compiler are you using? what version?
C++ 11
What are your CMake arguments?
cmake ../aws-sdk-cpp -DBUILD_ONLY=s3
Can you provide a TRACE level log? (sanitize any sensitive information)
-- Found AWS SDK for C++, Version: 1.7.266, Install Root:/usr/local, Platform Prefix:, Platform Dependent Libraries: pthread;crypto;ssl;z;curl
-- Components specified for AWSSDK: s3, application wll be depending on libs: aws-cpp-sdk-s3;aws-cpp-sdk-core
-- Try finding aws-cpp-sdk-core
CMake Error at /usr/local/lib/aws-c-common/cmake/aws-c-common-config.cmake:7 (include):
include could not find load file:
/usr/local/lib/aws-c-common/cmake/static/aws-c-common-targets.cmake

Call Stack (most recent call first):
/usr/local/share/cmake-3.9/Modules/CMakeFindDependencyMacro.cmake:37 (find_package)
/usr/local/lib/aws-c-event-stream/cmake/aws-c-event-stream-config.cmake:2 (find_dependency)
/usr/local/share/cmake-3.9/Modules/CMakeFindDependencyMacro.cmake:37 (find_package)
/usr/local/lib/cmake/aws-cpp-sdk-core/aws-cpp-sdk-core-config.cmake:2 (find_dependency)
/usr/local/lib/cmake/AWSSDK/AWSSDKConfig.cmake:303 (find_package)
dmn/sobject/CMakeLists.txt:161 (find_package)
CMake Error at /usr/local/lib/aws-checksums/cmake/aws-checksums-config.cmake:4 (include):
include could not find load file:
/usr/local/lib/aws-checksums/cmake/static/aws-checksums-targets.cmake

Call Stack (most recent call first):
/usr/local/share/cmake-3.9/Modules/CMakeFindDependencyMacro.cmake:37 (find_package)
/usr/local/lib/aws-c-event-stream/cmake/aws-c-event-stream-config.cmake:3 (find_dependency)
/usr/local/share/cmake-3.9/Modules/CMakeFindDependencyMacro.cmake:37 (find_package)
/usr/local/lib/cmake/aws-cpp-sdk-core/aws-cpp-sdk-core-config.cmake:2 (find_dependency)
/usr/local/lib/cmake/AWSSDK/AWSSDKConfig.cmake:303 (find_package)
dmn/sobject/CMakeLists.txt:161 (find_package)
CMake Error at /usr/local/lib/aws-c-event-stream/cmake/aws-c-event-stream-config.cmake:8 (include):
include could not find load file:
/usr/local/lib/aws-c-event-stream/cmake/static/aws-c-event-stream-targets.cmake

Call Stack (most recent call first):
/usr/local/share/cmake-3.9/Modules/CMakeFindDependencyMacro.cmake:37 (find_package)
/usr/local/lib/cmake/aws-cpp-sdk-core/aws-cpp-sdk-core-config.cmake:2 (find_dependency)
/usr/local/lib/cmake/AWSSDK/AWSSDKConfig.cmake:303 (find_package)
dmn/sobject/CMakeLists.txt:161 (find_package)

Hi @kkbachu ,
I'm a bit confused on what you're trying to do, and when you're getting this error. It sounds like the problem is that you are trying to use the sdk as a static library when it by default builds as shared.
If you want to build and use the sdk as a static library, then you'd have to add -DBUILD_SHARED=OFF when you build the sdk.
cmake ../aws-sdk-cpp -DBUILD_ONLY=s3 -DBUILD_SHARED=OFF
Let me know if this helped or what I'm missing.

Thanks @KaibaLopez for quick response.
I am building a static binary but it requires few .so libraries via find_package(). For eg.,
-- fuse: /usr/include
-- libfuse: /usr/lib/x86_64-linux-gnu/libfuse.so
When I do the samething for awssdk that is installed in /usr/local/lib, it does find this /usr/local/lib/cmake/AWSSDK/AWSSDKConfig.cmake:303 (find_package) but dependent makefiles it looks in a static directory usr/local/lib/aws-c-common/cmake/static/aws-c-common-targets.cmake.  So, after much looking around, I changed AWSSDKConfig.cmake to set BUILD_SHARED_LIBS=on as workaround, then everything works.
I understand that I need to build sdk statically but not necessary for what i am doing. Just wondering - how to use sdk that is built with BUILD_SHARED_LIBS=ON but find_package(sdk) is called from a static build of the application that is trying to use the dynamic sdk.

hmm so unless I'm getting your question wrong, in which case sorry in advance, you're having a problem because even though you are able to use the shared libs of the sdk, the shared lib flag is not passed down to the sdk's find_package() and so it looks for static libraries for the sdk's dependencies?
I think your "workaround" is a good solution honestly, since you're mixing static and shared builds I don't think you can use find_package() in a simple way, specially in cases like this sdk where it's like a project within a project.
But maybe we could change something in the config file to add this.... Could you share your cmakelists.txt? or a mock one to replicate this behavior?

Hi @kkbachu ,
As an update, after some digging we came to the conclusion this is more of a limitation on cmake with multiple projects and mixing shared and static builds than an error with the sdk, so for now I'm afraid the workaround will have to do.
Thanks for pointing it out and sorry I can't give you better news on that.


Popup when opening Files.

Description
Whenever I open Files, wsl.exe tries to open as well. Why is it looking for Linux?
Win 11

Steps To Reproduce
Open Files.
Requirements

e.g. Fix crash that occurs when...
Expected to be no popup.

Files Version
<IP_ADDRESS>
Windows Version
11pro 24H2
Log File
debug.log

Thanks for the report, this is an issue with Windows Dev and Canary builds not Files.


Fix CI by adding a VTK build

Building VtkGlue in remote CI tests should be possible. Before build ITK step add a "build VTK step", and then add -DModule_ITKVtkGlue:BOOL=ON and -DVTK_DIR:PATH=/path/to/vtk/build to ITK configure line. If the latest VTK is problematic, we can use version 8.2 or whichever one works best. We can also trim down the VTK build by reducing number of requested modules, so it builds faster.

@PranjalSahu

VTK build

Few weeks ago, I discussed with @mathstuf adding support for publishing the VTK SDK on a weekly (or daily) basis. We should finalize this step, this now tracker by https://gitlab.kitware.com/vtk/vtk/-/issues/18257

Closing this issue. Handled in https://github.com/InsightSoftwareConsortium/ITKThinShellDemons/pull/11


don't throw, reject

FYI @scamden, I hope this will make it so the process doesn't just die, instead it rejects to the caller. This might solve the infinite spinner

Can you link me to the change in the fork?

uh strange PR https://github.com/watershed-climate/xlstream/commit/77fc4411c0c28dc572f5e718f8d172ac0221d007


Update clang-format to new Google style.

Apparently the format bot uses a bleeding edge clang-format that uses
the new Google style and reformats a bunch of files in every PR. This is
an empty commit to trigger this in a separate commit.
See https://github.com/llvm-mirror/clang/commit/62e3198c4f5490a1c60ba51d81fe2e1f0dc99135

@wally-the-cartographer merge

Will be also necessary in ROS, can do this later.

Merge requested by authorized user gaschler. Merge queue now has a length of 1.

Would be great if you could revert the format commits in other PRs here and in Cartographer ROS.
A merge triggered with a press on "update branch" in GitHub should be enough.


Allow users to set the environment.

Allow for a config-level option to set the environment.

This is done for next release.


Hash#select!(Enumerable) can skip over elements in the argument

Hash#select!(Enumerable) is implemented as:
class Hash(K, V)
  def select!(keys : Enumerable) : self
    each { |k, v| delete(k) unless keys.includes?(k) }
    self
  end
end

This calls Enumerable#includes?, which may consume the entire Enumerable, even though the elements of keys need to be checked for each element in self. The result is that some entries can be missing in the returned value:
# finds 1, skipping over 2
# cannot find 2, skipping over 3
# cannot find 3
{1 => 'a', 2 => 'b', 3 => 'c'}.select!([2, 1, 3].each) # => {1 => 'a'}

This is inconsistent with #select, #reject, and #reject!.

A quick search indicates Crystal::ASTNode#unbind_from(Enumerable(ASTNode)) also has this issue, but it is internal to the compiler and thus can be easily promoted to Indexable(ASTNode)

I think the PR that introduced this should be reverted.

This is not efficient at all but prevents the interface from breaking.
I propose we keep the Enumerable argument with an internal conversion to a set and keep an overload for Array | Tuple that preserves the original implementation.
# Removes every element except the given ones.
#
# ```
# h1 = {"a" => 1, "b" => 2, "c" => 3, "d" => 4}.select!({"a", "c"})
# h2 = {"a" => 1, "b" => 2, "c" => 3, "d" => 4}.select!("a", "c")
# h3 = {"a" => 1, "b" => 2, "c" => 3, "d" => 4}.select!(["a", "c"])
# h4 = {"a" => 1, "b" => 2, "c" => 3, "d" => 4}.select!(Set{"a", "c"})
# h1 == h2 == h3 == h4 # => true
# h1                   # => {"a" => 1, "c" => 3}
# ```
def select!(keys : Enumerable) : self
  # Convert enumerable to a set to prevent exhaustion of elements
  key_set = keys.to_set
  each { |k, v| delete(k) unless k.in?(key_set) }
  self
end

# :ditto:
def select!(keys : Array | Tuple) : self
  each { |k, v| delete(k) unless k.in?(keys) }
  self
end

This would be a nice case to have a type for finite and stable collections #12092 👀

This issue is also interesting because it might be a bit unexpected that the Enumerable is exhausted. In my mind when you iterate an iterator over and over it should be rewinded. There was an issue for that but we never got to do it. If that were the case then we wouldn't need to change this method. But for now we can go with that solution.

Iterator isn't the only single-pass Enumerable and rewinding is not universally possible. I think something like Enumerable::Stable(T) might have merits but if a method calls #each on an argument exactly once then there is no need to require that argument to be stable.

rewinding is not universally possible

Right, but I don't think that's a good reason not to do it. I think maybe reading stuff from a socket or TTY might not be rewindable, but that's almost it.

If #rewind exists, does the caller or the consuming method call it? It is a nice to have feature but I don't think that's the solution to Enumerable exhaustion. In fact I expect it to be that way when a more specific restriction is absent.

This is what I came up with in the past. I would love it if Crystal worked that way: https://github.com/crystal-lang/crystal/issues/8504#issuecomment-600858734

Obviously it would work like that for all iterators, without having to call ruby. The idea is that each with block rewind the internal Iterator. Actually it could dup the original Iterator so it could work well too in nested blocks.

It only works for Iterator, not other Enumerable types in general. Also something as simple as x = 0; Iterator.of { x += 1 } will not work.

Exactly, it uses includes, which rely on each. It would work fine.
I think I have an idea of how to implement this. It doesn't matter that in some cases it doesn't work well, like with Iterator.of

It definitely matters, it just replaces one set of surprising behavior with another set. And I would argue this makes things even more confusing because the iterator types we use are private and it is unclear which of them have a working #rewind and which do not.

It seems I went through this before: https://github.com/crystal-lang/crystal/pull/10089
We were really close to merging that! But we didn't because the generic dup implementation was cloning too much. But if we require Iterator to provide clone and rewind (or not require it, but use them when available) then it'll be really intuitive and predictable, like in Ruby.
I really think we should revive that PR in some form.
Then for example the issue here wouldn't be an issue at all, because includes? will call each which will always iterate from the beginning.

The actual implementation of Enumerator#each(&) seems to be much simpler; it just calls #each(&) of the wrapped object, so if someone does it = [1, 2, 3].each; it.next; it.each {} then the each goes through all elements without caring it's own state. The exception is if there isn't a wrapped object like x = 0; Enumerator.produce { x += 1 }.
IMO that is the opposite of intuitive, even in Ruby. An Iterator represents an iteration state. It should be part of its contract that #each always yields the same elements as successive calls of #next. Anything else violates that contract and defies expectation.
A stable Enumerable on the other hand should not maintain iteration state. Dir#@dir is being used as an iteration state. To make it stable, what we should do is duplicate that member instead whenever we call #each(&) or #each. Then we don't need Dir#read and Dir#rewind either, because they only apply to an iteration state, which there would be none in Dir itself anymore.

@HertzDevil What would you expect this to output?
a = [1, 2, 3].each
b = a.select(&.odd?)

a.each do |x|
  puts x
end

b.each do |x|
  puts x
end

My personal opinion: the way I think about composing iterators is that they represent a query to perform. This would be similar to Rails' ActiveRecord queries. For example in Rails you can do this:
all_users = User.all
users_with_some_email = all_users.where(email: "...")
above_users_but_adults = users_with_some_email.where(adult: true)

Consuming the contents of all_users shouldn't affect consuming the contents of users_with_some_email. In Rails these aren't iterators, but the concept is the same: a kind of "query" to execute on some data.
Now, there's no next in Rails for this. These aren't enumerables. But it's fine! In Crystal next is a low-level primitive to implement everything else. Is the single method that makes iterators work. In practice, unless you need to traverse two iterators at the same time (zip) then you will never use next. Furthermore, it's very rare to have to combine next with any of the other methods (each, to_a, select, etc.)
So in my mind the above Crystal could should work like in Ruby.

I would expect a.each to print everything and b.each to print nothing, because this is what it is: [1, 2, 3].each represents a single iteration pass. To request another iteration you call #each on the original array again. This is the elegance of Iterator.
Types can keep the Enumerator kind of guarantees in Crystal if they don't return an Iterator. And those enumerators probably wouldn't have #next, either.

I would expect a.each to print everything and b.each to print nothing, because this is what it is: [1, 2, 3].each represents a single iteration pass.

It represents a single iteration pass... right now, because we couldn't implement it better.
Imagine .each didn't exist in Crystal and we'd like to introduce it. Which behavior you would like to have in Crystal? I would personally like it to behave the same as in Ruby.

Thw way we already have right now, rather than Ruby's.

which can be iterated over and over again, but each iteration sequence needs to be self-contained and makes #next weird

Right, well, in Ruby the same object represents the two things at the same time. This is very convenient because if you want to go one by one, you can do it. If you want to sub-filter or consume everything, you can do it too! Ruby for the win!

Expect when it doesn't, because there is no way to tell whether a #rewind call will succeed.

That's within the types we know in the standard library only. Nothing prevents people from writing non-rewindable Iterators outside, and nothing should prevent people.

Well, let's compare the situations:

Now: no iterators can be rewinded, you can't compose iterators without one iterator affecting others, etc.
A possible future: most iterators can be rewinded (if someone adds a new iterator in a shard and it can be rewinind, I'm sure someone will send a PR to improve that), you can compose most iterators without one affecting others, etc.

Which one do you all prefer?
(I prefer pragmatism over perfection)

There is a more primitive operation than #rewind that is also worth considering:
module Iterator::Bidi(T)
  include Iterator(T)

  abstract def prev : T | Iterator::Stop

  # default impl
  def rewind
    until prev.is_a?(Iterator::Stop)
    end
  end
end

If we also add some notion of a "current" element then we arrive at Java-style iterators.

My first thought when I read Bidi 😆


TTY and Compression for SSH

When using commands requiring a TTY (such as Rails console), this
script won’t work.
So enabling a TTY resolves the issue. Also compression should be
enabled by default I think.

@josegonzalez Could you merge this PR please or is there a problem with it?

@michaelshobbs any thoughts on this pr?

From the ssh man page:
Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks.

I'm fine with -t though.

@michaelshobbs I’ve removed the -C flag :)


Remove konghq trailing links

Summary
Remove the trailing slash from any links to konghq.com
Reason
SEO impact for the marketing team
Testing
I ran the broken link checker on the whole site using the following instructions:
cd broken-link-checker
npm ci
netlify dev
node full.js --host http://localhost:8888

There were no new broken links (some old ones which we can fix in a followup PR)

Changes made with the following:
HTML:

grep -lEr "https://konghq.com/.*/" app | xargs gsed -i 's/\("https:\/\/konghq.com\/.*\)\/"/\1"/'

Markdown:

grep -lEr "https://konghq.com/.*/“ app | xargs gsed -i 's/\((https:\/\/konghq.com\/.*\)\/)/\1)/'

There are some broken links, but none that are related to the changes made today. With that in mind, I'd like to ignore them today and revisit after the 3.0 release + archiving of old content.
Vale is erroring too, but given this is an automated update I think we can ignore the suggestions.

@lena-larionova This PR specifically targets https://www.konghq.com and https://konghq.com which are configured to run without a trailing slash.
The slides shared are an issue, but that's separate to what this PR aims to address. I believe we should fix old redirects to point to the trailing slash URLs, fwiw


Fix broker id example

The comments state to use stand alone broker id, but the old examples used brokers/brokerid. Broker ID alone seems to be correct.

this has been addressed in the current configs


chore(nxext): remove ionic packages

Hi!
What was the reason for deleting this package?

Hi
Can you explain why this package was removed?
I was using the capacitor package and was wondering why this was removed too.

Hey, @a616101  and @c01nd01r,
the packages now live here https://github.com/nxext/nx-extensions-ionic
There are all of the ionic packages now.


Feature request: overscroll listener

It'd be great to have some kind of onOverScrolled(float) listener, which accurately calls the overscroll amount whenever it occurs.
I've currently hooked into translateView(), but this does not get called when the view is settling back into place.  Hooking into the settling animation doesn't seem possible externally.
My use case: having views react to a RecyclerView's overscroll and transform in various ways, and reverse these transformations when the overscroll touch is released.  I'm sure there are many others :)

Hey,
thanks for this feedback!
It so happens that I've been planning on introducing such a listener for a while now -- but haven't done so yet since no requests have been made on such a feature.
So basically I'd like to thank you for putting interest into it! I now how proper motivation to implement that :-)

Hey,
Are there any progress about overscroll's offset listener ?
Thanks for library. Have a good day.

Hi,
haven't got to it yet, I'm afraid. Hoping to get to it real soon.
BTW do you have an idea as to what kind of a callback you would find most useful?

@duckinferno cuz both the realization of translation and bounce-back anmation are based on View.setTranslationX(float) or View.setTranslationY(float), you could override that method of your view, and will get the value of overscroll either on touch-scroll or on animating.

Hi,
Firstly, thanks for your interest. I think that the callback should return position(top, right, bottom, left), offset and view.

Sure. Always happy to get feedbacks.
@XavierSAndroid good call, that could work as an intermediate solution.
@andanicalik Not sure I follow. By 'position' - you're referring to the view's absolute position? if so, that can be retrieved from the view itself. As for the offset - I agree: offset in pixels; could also be used for computing as a ratio (value in (0..1]) compared to the scrollable view's total height, if needed.
I'm also thinking about adding the 'state' -- scrolled start / scroll in-progress / bouncing-back / scroll-ended.

By 'position', I want to refer bouncing position. It can be top-end of list if it's vertical, also left-right of list if it's horizontal, not view absolute position. Sorry for misunderstanding.

@Xavier yeah that's my interim solution too ☺
On 29/03/2016 3:22 am, "Xavier"<EMAIL_ADDRESS>wrote:

@duckinferno https://github.com/duckinferno cuz both the realization of
translation and bounce-back anmation are based on
View.setTranslationX(float) or View.setTranslationY(float), you could
override that method of your view, and will get the value of overscroll
either on touch-scroll or on animating.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/EverythingMe/overscroll-decor/issues/8#issuecomment-202413217

Featured added to new version - 1.0.2.
Feedbacks would be appreciated!


run d2go on the A100-SXM-80GB GPU

from d2go.model_zoo import model_zoo
model = model_zoo.get('faster_rcnn_fbnetv3a_C4.yaml', trained=True)
Error:
/apps/d2go/lib/python3.9/site-packages/torch/cuda/init.py:104: UserWarning:
A100-SXM-80GB with CUDA capability sm_80 is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities sm_37 sm_50 sm_60 sm_61 sm_70 sm_75 compute_37.
If you want to use the A100-SXM-80GB GPU with PyTorch, please check the instructions at https://pytorch.org/get-started/locally/
warnings.warn(incompatible_device_warn.format(device_name, capability, " ".join(arch_list), device_name))
Can d2go run on A100-SXM-80GB GPU? Is it possible to update to Cuda 11? Thanks!

This looks like an issue for PyTorch. Is the PyTorch compiled with correct CUDA version? Could you try building PyTorch from source?

I used the following command to update the Cuda.
conda install pytorch torchvision torchaudio cudatoolkit=11.1 -c pytorch -c nvidia
But it couldn't install and update successfully, it was stuck in the update.

You may consider build pytorch from source.


versioning issues with pyvista

EmeraldTriangles user @burningsage reports an issue when exporting to vtk using emeraldtriangles.io.vtk.dump
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[28], line 2
      1 #Save interface
----> 2 emeraldtriangles.io.vtk.dump(data.project_tin, os.path.join(vtkdir, f'{PickleStub}_RockInter_{today()}.vtk'), z_col="z_bedr")

File lib/python3.9/site-packages/emeraldtriangles/io/vtk/__init__.py:17, in dump(tri, filename, layer_depths, **kw)
     15     volume.to_pyvista(tri, layer_depths=layer_depths, **kw).save(filename)
     16 else:
---> 17     surface.to_pyvista(tri, **kw).save(filename)

File lib/python3.9/site-packages/emeraldtriangles/io/vtk/surface.py:32, in to_pyvista(tri, **kw)
     30 for col, dtype in meshdata["point_arrays"].dtypes.items():
     31     if dtype != float: continue
---> 32     m.point_arrays[col] = meshdata["point_arrays"][col]
     33 for col, dtype in meshdata["cell_arrays"].dtypes.items():
     34     if dtype != float: continue

File lib/python3.9/site-packages/pyvista/core/dataset.py:115, in DataSet.__getattr__(self, item)
    113 def __getattr__(self, item) -> Any:
    114     """Get attribute from base class if not found."""
--> 115     return super().__getattribute__(item)

AttributeError: 'UnstructuredGrid' object has no attribute 'point_arrays'

This reminds me of a warning message that I've often seen when using pyvista for export:
env/lib/python3.8/site-packages/pyvista/core/dataset.py:1418: PyvistaDeprecationWarning: Use of `point_arrays` is deprecated. Use `point_data` instead.
  warnings.warn(

Sure enough, I'm using a different version. he's got pyvista==0.38.1 whereas I have pyvista==0.36.1. @burningsage reports that by downgrading his version of pyvista, this error goes away.
We have two solutions here:

Force emeraldtriangles users to have a certain version of pyvista
Fix the reference to the depracated point_array in the code and update it to the latest nomenclature.

Closing from emerald-installer in use now


Add Compliance check: blockWorkflowPRApproval

How the Check Works
Provide a clear definition based on the spreadsheet
Pending Tasks
You can find more details in the contributing guide

[ ] 1. Define a Good Implementation Example

[ ] Read the documentation (guidelines, best practices...)
[ ] Brainstorm how to implement this check (logic, alerts, tasks, validations, edge cases...).
[ ] Achieve an agreement on the implementation details before starting to work on this.

[ ] 2. Update Check Record Example

[ ] Update the compliance_checks row with the following fields: how_to_url, implementation_status, implementation_type and implementation_details_reference
[ ] Check the migration scripts using npm run db:migrate and npm run db:rollback
[ ] Update the database schema by running npm run db:generate-schema

[ ] 3. Implement the Business Logic Validator Example and Check Example

[ ] Add the specific validator in src/checks/validators/index.js
[ ] Add the check logic in src/checks/complianceChecks
[ ] Ensure that the check is in scope for the organization (use isCheckApplicableToProjectCategory)
[ ] Ensure that the severity value is well calculated (use getSeverityFromPriorityGroup)
[ ] Add the alert row in the compliance_checks_alerts table when is needed.
[ ] Add the task row in the compliance_checks_tasks table when is needed.
[ ] Add the result row in the compliance_checks_results table.

[ ] 4. Ensure It Works as Expected

[ ] Add new unit tests for the validator check.
[ ] Add new integration test cases for this check.
[ ] Verify that all tests are passing.
[ ] Run the command check run --name {check_code_name} and verify the changes in the database. Update the seed script if needed (npm run db:seed)

[ ] 5. Update the website Example

[ ] Review the current content it in https://openjs-security-program-standards.netlify.app/details/{check_code_name}
[ ] Create a PR in https://github.com/secure-dashboards/openjs-security-program-standards to include how we calculate this check and include additional information on the mitigation if needed.

Blocked by https://github.com/OpenPathfinder/visionBoard/issues/150#issuecomment-2543373086. Once landed we can use the column github_actions_can_approve_pull_request_reviews=false to validate the check at GitHub org level.


✨ Draft scripts to support external processes

Summary
This PR adds a first draft of scripts designed to support more complex deployment scenarios, as outlined in #788.  These scripts are concerned with the following two things.

Support generation of server credentials to pass to kcp or plain kube server via --tls-sni-cert-key.
Create alternate kubeconfig files by replacing the protocol://host:port prefix of cluster server URLs and the CA certificate data.

These scripts are factored so that the user can launch the kcp server in their own way and support multiple sets of clients needing to connect to the kcp server using different domain names.
Related issue(s)
Fixes #

/cc @francostellari
/cc @pdettori
/cc @ezrasilvera
/cc @dumb0002

/lgtm

@MikeSpreitzer thank you very much, great job!

/approve


Mongo use for python actions

Is it possible to have pymongo and watson-developer-cloud packages for the python actions like we have in the Javascript actions, currently we have to run a Docker action to use those packages and because of the 60 second limit on docker actions, saving to mongo fails when saving large documents.

Hi @Abiwax Which 60 second limit on docker actions are you referring?
60 seconds is just a default.
Actions can run up to 5 minutes for example
wsk action create --docker example janesmith/blackboxdemo --timeout 300000

Also I would recommend you take a look on using virtualenv to package any 3rd party python libraries in a python zip action, check the docs here https://github.com/openwhisk/openwhisk/blob/master/docs/actions.md#packaging-python-actions-with-a-virtual-environment-in-zip-files
please re-open the issue if I miss understood your problem

@csantanapr We can make for a large set of included python packages, in general, to include a few more popular SDKs. It could make it easier vs venv.

@rabbah
I agree, I'm more or a nodejs guy and have a good feeling what are the "more popular" libraries to include.
Take into account that we will update to the latest version at our will at any time to keep it current, so users using them should not be surprised when a lib goes from 1.1.0 to 2.2.0 for example.
I'm OK if @rabbah and @cclauss take stab on picking a few popular libs, we start by matching the nodejs ones but for python.
PS: what about Java and swift? who wants to take on those?

We should do Java on demand IMO or when we have more data that we've analyzed. For Swift maybe @paulcastro has some initial input on feasibility.

@csantanapr please note that docker actions do not run beyond 60 seconds even with the timeout cap.
Will try the new addition of using virtualenv with python actions instead.

@Abiwax are you doing a blocking invoke? If so, that's true, a request/response must complete in 60s to retrieve the result.

@rabbah yes, the action is part of a sequence.

Are you on slack.openwhisk.org? If so direct message me.

thanks @rabbah , will join the the slack team now.


Update auth, dynamodb, s3 to 2.15.62

Updates

software.amazon.awssdk:auth
software.amazon.awssdk:dynamodb
software.amazon.awssdk:s3

from 2.15.61 to 2.15.62.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

labels: library-update, semver-patch

Superseded by #529.

Superseded by #529.


Reusable continuation chains

Thanks for this fantastic library @Naios. The amount of work you must have put into the documentation is really appreciated.
 If it is possible, could you please give a brief summary of what would need to be done/how it should be approached? I'd be interested in implementing such a thing and would appreciate your thoughts.

I'm glad that you like the library and especially the documentation which took a lot of effort indeed.
I thought about reusable continuation chains before and the core library is well suited for such an implementation, when putting connections aside.
Currently the plain callback interface looks like this:
template<typename... Args>
struct callback {
  void operator() (Args...) &&;
  void operator() (cti::exception_arg_t, cti::exception_t) &&;
};

Because the library treats continuiables as a use once object the continuation chain which was already invoked is left behind while the chain to come is moved into the next continuation.
This is also reflected by the continuation interface which acceps the next callback as a whole:
template<typename... Args>
struct continuation {
 void operator() (callback<Args...>);
 bool operator() (cti::is_ready_arg_t) const;
 std::tuple<Args...> operator() (cti::query_arg_t);
};

Further we call a reusable continuation channel and its reusable promise type sink.
In order to make such a feature to work one must change the behaviour of callback propagation such that the callbacks are not moved but kept through the continuation chain.
template<typename... Args>
struct callback {
  void operator() (Args...);
  void operator() (cti::exception_arg_t, cti::exception_t);
};

The main file which must be changed for this is include/continuable/detail/core/base.hpp through changing the moves to pass by l-value reference.
https://github.com/Naios/continuable/blob/fdd9a061c4d1b808e550f519bba400b2cfa2eea6/include/continuable/detail/core/base.hpp#L548
Further a new wrapper class for continuable -> channel and promise -> sink needs to be introduced and make continuable and channel interoperable where applyable.
Probably it won't be that simple as described above but this is the basic idea I think.
Let me know if you need further help on this.

Thanks for your detailed reply; it will be very useful. I'll report back here with my progress (though it likely won't be for a couple of months).
I was hoping to implement connections for channels too, but you hinted above that it's not possible. What is currently blocking the implementation of connections between channels?

Basically the when_seq and when_all connection are the difficult ones. when_any is probably tirivial to implement.
The issue will be to cache multiple results of many channels and then dispatch them to the waiting channels in order. The difference to the use once chain is that many connection frames with different progresses can wait on the next result of one channel.


ShowInTaskbar Affect window display

Describe the bug
When the window is minimized and ShowInTaskbar is false by default,
Window cannot be hidden normally,
There will be a piece in the lower right corner of the desktop
To Reproduce

Expected behavior
Window can be hidden normally,
Screenshots
No response
OS version
win10、win11
.NET version
.net 6
WPF-UI NuGet version
3.0.3
Additional context
No response

Bugs belong to WPF


different runs on same data produce slightly different outputs

I'm doing a classification task where I have multiple segments (more than 2) and my data is prepared into a format like [PAD,...,PAD,A,SEP,B,SEP,C,SEP,...,SEP,CLS]
To do this, I used the xlnet.py file as per the suggestion of the "Custom Usage" section. I pretty much just copied what the code in that section said to do, but since I have more than 2 segments for my problem, I had to write my own data input functions.
I grab summary = xlnet_model.get_pooled_out(summary_type="last") (just getting the CLS embedding) and then just put a single dense layer on top of that summary. I define my placeholders for those inputs, define my loss and an Adam optimizer and train the model using a tf.Session() and then save the overall model using a tf.save_model.simple_save().
When I reload the model and run it on the exact same input data multiple times, I get slightly differing outputs each time. The difference is slight, but significant enough to affect my average metrics by 3-5%. I am having a hard time understanding how a model loaded from memory can have non-deterministic behavior. I have double checked the inputs (input_ids, seg_ids, input_mask), and they are exactly the same across runs (to confirm that the tokenizer wasn't sampling different tokenizations for some unknown reason). I am pretty baffled by this behavior, can anyone shed some light? The difference seems to be too large to be some sort of floating-point rounding error, and the combinatorical shuffling of the inputs done to pre-train XLNET is shut off at finetuning time right? Is it possible the shuffling is still happening without my knowledge or something like that?

After thinking through things a bit more, I realized I just never turned off the training mode so the discrepancies are probably brought about by the dropout layers or other layers that behave randomly during training. What would be the best suggested way to do that on XLNET on a saved model? Should I call "create_run_config" again after training, before saving my model, with training set to false?

You can turn it off mannuay:
    xlnet_config.dropout = 0.0
    xlnet_config.dropatt = 0.0

I truned off the dropout, set is_training=False and is_finetune=True, but get different results for seq_out.  Did you encounter the same problem?


Fix our dear #693 type checker bug

Hello :octocat:
This fixes #693!
The problem was: even though type variables for parameters are free, we were failing to keep track of this fact after substitutions. So, considering the example:
val b(x: int -> str): int = val c = x.keys() { 1 }

Suppose x has type variable t0, which is free. Once we analyze x.keys(), we'll perform a unification and apply substitutions, resulting in t0 being replaced by t1 -> t2 (since x has to be a map in order for it to be an argument for keys()). However, since t1 and t2 are not free names, when we exit the let definition, the types are quantified, and we loose track that those types are related to the parameter type.
The solution is to make sure that, in a substitution like t0 |-> t1 -> t2, if t0 is a free variable, then t1 and t2 also have to be free.
Also, I found another small bug in the integration with Apalache due to the different representation of row types between quint and apalache. The Apalache representation doesn't allow nested rows (that is, a concrete row in the tail). This also adds a small fix for that.

[x] Tests added for any new code
[x] Documentation added for any new functionality
[x] Entries added to the respective CHANGELOG.md for any new functionality
[ ] Feature table on README.md updated for any listed functionality

Could you explain where we need the row type simplifier? afaik, nested rows are already flattened on the Apalache side: https://github.com/informalsystems/apalache/blob/315d43ad3afca3ed3abbb5e8f2610e3bd9bc9929/tla-io/src/main/scala/at/forsyte/apalache/io/quint/QuintTypeConverter.scala#L60-L73

Interesting, I didn't realize we are already doing this in Apalache.
So... I've added this simplification step because I was hitting an error where Apalache complained about mismatching row types, something like "expected Var or Empty, found Row", which I instantly interpreted as nested rows and jumped to a fix. However, I can't reproduce that anymore :thinking:. Perhaps it was caused by some intermediate state of my other fix or something like that.
While trying to decide if this simplification is worth keeping, I noticed we do similar processes both before printing rows and before unifying rows. So I'll extract it from this PR and just add it in a separate cleanup PR accounting for all these scenarios.


Updating write functions to return length of written bytes

This PR updates the embedded_io::Write trait to return the number of bytes written for the write_fmt function. It seems the length was originally omitted out of simplicity/lack of demand.
However, during my usage, I noted that without this, using a byte slice with write!() doesn't provide a result to indicate where the written object ends:
let mut bytes = [0; 1024];
let _should_be_len = write!(&mut bytes[..], "{:?}", MyObjectThatImplsDebug).unwrap();

// At this point, there is no way to know how many bytes in `bytes` were written, so we don't know where the formatting ends.

This breaks compatibility with std::io::Write. Whether that's a bad thing or not in this case is unclear because imo it was a mistake in the write_fmt signature to not return the number of bytes written (https://github.com/rust-lang/rust/issues/63614).
An alternative to this, which I have used in the past before even embedded-io existed is to use a wrapper type which counts the number of bytes written to the inner buffer, which you can then retrieve after you're done formatting. Perhaps something like this could be added to this crate to avoid people rolling their own.

This breaks compatibility with std::io::Write. Whether that's a bad thing or not in this case is unclear because imo it was a mistake in the write_fmt signature to not return the number of bytes written (https://github.com/rust-lang/rust/issues/63614).

I guess a valid question would be whether or not we're trying to be ane exact replacement. If so, then I agree that we should keep the same function signature.

An alternative to this, which I have used in the past before even embedded-io existed is to use a wrapper type which counts the number of bytes written to the inner buffer, which you can then retrieve after you're done formatting. Perhaps something like this could be added to this crate to avoid people rolling their own.

Yeah, which is essentially the embedded equivalent of std::io::Cursor. I'm not opposed to this approach.

Using the Cursor approach results in some pretty awful code. For some reason, the compiler is not able to determine the return arguments from the write!() macro, so you have to tell it the explicit error type.
let mut cursor = Cursor::new(buf);
write!(cursor, "{:?}", error)?;
Ok::<_, embedded_io::WriteFmtError<core::convert::Infallible>>(cursor.position())

I guess a valid question would be whether or not we're trying to be ane exact replacement. If so, then I agree that we should keep the same function signature.

Good question! I'm not sure of the long-term goal of embedded-io. I guess @Dirbaio has an idea.

Edit: To answer my own question, there's already some documented differences: https://github.com/rust-embedded/embedded-hal/tree/master/embedded-io#differences-with-stdio

I think the main difference here is that those are differences because of limitations in core, and where possible we add std impls so that std continues to work as expected. This would be a conscious decision to make a breaking change to improve the API.

The write_fmt function in std has the following description:
Glue for usage of the [write!](https://doc.rust-lang.org/std/macro.write.html) macro with implementors of this trait.

This method should generally not be invoked manually, but rather through the [write!](https://doc.rust-lang.org/std/macro.write.html) macro itself.

And the write! macro doesn't specify exactly what its return value would be:
The macro returns whatever the write_fmt method returns; commonly a [fmt::Result](https://doc.rust-lang.org/std/fmt/type.Result.html), or an [io::Result](https://doc.rust-lang.org/std/io/type.Result.html).

So code using the std version of this method probably doesn't rely on an exact type being returned anyway. Changing the embedded-io version to return the bytes written doesn't look like a bad idea to me.

The Write impl for &mut [u8] shortens the slice as you write, so you can calculate the amount of written data. This works for both std::io and embedded-io:
    let mut bytes = [0; 1024];

    let mut w = &mut bytes[..];
    let len = w.len();
    write!(w, "{:?}", 1234).unwrap();
    let n = len - w.len();

    println!("{}", n); // prints 4

Using the Cursor approach results in some pretty awful code. For some reason, the compiler is not able to determine the return arguments from the write!() macro, so you have to tell it the explicit error type.

How have you implemented Cursor? that looks like you haven't constrained the error type.

I'm not sure whether deviating from std::io is worth it on this. Getting the written length is already possible with the std::io API (with either the snippet above, or Cursor). I agree it's somewhat verbose, but so is std::io.

The Write impl for &mut [u8] shortens the slice as you write, so you can calculate the amount of written data.

Ah, this indeed solves my use-case quite well with a single extra function call, which is even easier than the Cursor-based approach.

How have you implemented Cursor? that looks like you haven't constrained the error type.

Apparently not because I got the exact same error when using your snippet as:
let start = buf.len();
write!(buf, "{}", MyType)?;
Ok(start - buf.len())

However, oddly enough doing the following fixed it. I have a suspicion its because Rustc may be being arbitrarily restrictive on inferring Closure return types:
let start = buf.len();
write!(buf, "{}", MyType).and_then(|_| Ok(start - buf.len())

Could some of you document this problem and solution in the method or somewhere else in embedded-io?

I opened a PR here: https://github.com/rust-embedded/embedded-hal/pull/507

Closing this as it was superseded by https://github.com/rust-embedded/embedded-hal/pull/507 (thanks @MabezDev! I got busier than expected)


Overriding CustomerQueries in tests

What would be the best/easiest way to override this string in my tests?

@cincuranet Like this: https://github.com/npgsql/efcore.pg/blob/b11080d5d4276612d1c19a84405b4280cb2ce1ba/test/EFCore.PG.FunctionalTests/TestModels/Northwind/NorthwindNpgsqlContext.cs


Net471 project: Paket pulls in netstandard2.0 dependency instead of net35

Description
I have created a repro here
Basically it's a Framework v4.7.1 project pulling in 2 dependencies: xUnit and Jetbrains DotMemory
DotMemory has 2 libs: netstandard2.0 and net35
Paket is pulling in the netstandard2.0 library (see the .csproj file), whereas I would have expected it to pull in the net35 dependency.
How can I trace why Paket is choosing that library, and how can I force it to choose the net35 library instead?

How can I trace why Paket is choosing that library, and how can I force it to choose the net35 library instead?

Only by trying to understand this file. There is no real spec we followed we try to prefer stuff and give penalties for stuff we don't want: https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/Versioning/PlatformMatching.fs
Ideally we would follow the nuget spec (whatever that might be)
usually we prefer framework on framework dependencies but here it might have out-ruled something else, because from 4.7.1 to net3.5 there are a lot of versions in between?

And you should feel comfortable to replace/rewrite or edit this particular area as I think the test-coverage there is quite good.

Thanks @matthid but I'm not the one you want rewriting that code - I don't know F# and my knowledge of the permutations of net frameworks / standard isn't deep.
I did find this website  (linked to from Microsoft docs) which claims to find the nearest framework operation using Nuget's logic, and that one found net35.
The code behind that tool is MIT licensed, perhaps it would be possible to leverage that logic or re-implement the same logic in Paket?

We have a similar issue, I assume it has the same origins. (please tell me if not; then I'll create a dedicated issue)
We use the package System.IO.Abstractions (in v4.1.6, but that doesn't matter). It declares no dependencies for net40, and System.IO.FileSystem.AccessControl for netstandard20.
We used to target net452 so the only way out was to take the empty net40 dependency declaration an everything was fine. After the update to net472 paket has two options as both as net472 is compatible to both, net40 and netstandard20. Now things became weird: On half of our deveoper's machines paket takes the net40-route (no further depdencies), on the other half it tries to get AccessControl nuget required by the netstandard20 declaration (and fails as this spurious package is not available on our internal mirror).
In all cases paket-5.181.1 was used, on the machines that fail we could reproduce the failure with paket-5.207. As of now we haven't found what makes the one half of the machines different from the other. We have mixed win7 and win10 systems; with VS2015 and/or VS2017 installed.

Finding/Workaround
Upon running paket.exe clear-cache, Paket works as expected, taking the net40 route instead of netstandard20 for System.IO.Abstractions, when the framework restriction is set to net472 in paket.dependencies.
Methodology

Taking up the suggestion in comment 2, we added a breakpoint to findBestMatch.
We noticed that on the affected systems, the breakpoint is not hit at all upon doing a paket update, whereas on the systems, wherein Paket behaves as expected, the breakpoint is hit every time paket update is trigerred.
This suggests that some part of the code relies on factors specific to a machine, cache was the easiest guess.
We cleared the cache and Paket started behaving as expected, takes the net40 route for System.IO.Abstractions, when the framework restriction is set to net472 in paket.dependencies

We could not debug the issue further due to time & resource limitations. It would be nice to know the reason for this behavior. Maybe it is well-known among the maintainers already or there is some documentation for this.


No Image Open error when running ImageJ commands

Open napari
Open brick
Run Gaussian Blur... command (highlighted in yellow)
Get No Image error

I'm assuming this command needs to be run from the ImageJ GUI because it needs an ImageWindow? We probably don't want to show any Ij1 commands then right..?

Open napari

Open brick

Run Gaussian Blur... command (highlighted in yellow)

Get No Image error

I'm assuming this command needs to be run from the ImageJ GUI because it needs an ImageWindow? We probably don't want to show any Ij1 commands then right..?

@hinerm so what we can do is use the LegacyImageMap to set the current ImagePlus to the current active layer on the fly, so that these things would work. I think I started doing this on the active-layer-to-active-ij-window branch with this commit. I never did finish that work, though...

I'm closing this, as #207 has been merged.