mit SOC abfrage und erneuten anstecken kein laden.

Wenn ich mein Auto mit Zielladen auf 80% SOC über den EVCC lade., das Auto danach benutze und es wieder anstecke, z.B. mit einen SOC von 30% wird nicht wieder geladen.  Auch nach "Stop" und wieder auf "Sofort" wird nicht geladen. Erst wenn ich das Zielladen auf 100% stelle fängt EVCC an zu laden. Danach wird auch der SOC vom Auto wieder neu abgefragt und an die Stelle geschrieben. Danach kann man das Zielladen wieder auf 80% stellen.
Meiner Meinung wird nicht nach erneuten verbinden der SOC vom Auto abgefragt und entsprechend entschieden ob geladen werden muss.

Meiner Meinung wird nicht nach erneuten verbinden der SOC vom Auto abgefragt und entsprechend entschieden ob geladen werden muss.

Das sollte so sein. Bitte vollständiges Issue mit Config und Logfile.

Meiner Meinung wird nicht nach erneuten verbinden der SOC vom Auto abgefragt und entsprechend entschieden ob geladen werden muss.

Das sollte so sein. Bitte vollständiges Issue mit Config und Logfile.

Mache ich gern.
evcc.yaml.zip
Der SOC vom Nissan LEAF wurde auch nicht aktualisiert. Da kam immer eine Fehlermeldung.

Beim Versuch ein Logfile zu erzeugen habe ich den EVCC beendet und mit "sudo systemctl start evcc.service" wieder gestartet.
Danach wurde auch der SOC vom LEAF wieder eingelesen.
Kannst du mir bitte sagen wo ich ein Logfile vorhandenes Logfile finde. Oder wie ich eins anlegen lassen kann?
In der Config habe ich das immer an:
# log settings log: error levels:   core: debug   lp-1: debug   lp-2: debug

Mache ich gern.
evcc.yaml.zip
Der SOC vom Nissan LEAF wurde auch nicht aktualisiert. Da kam immer eine Fehlermeldung.

Beim Versuch ein Logfile zu erzeugen habe ich den EVCC beendet und mit "sudo systemctl start evcc.service" wieder gestartet.
Danach wurde auch der SOC vom LEAF wieder eingelesen.
Kannst du mir bitte sagen wo ich ein Logfile vorhandenes Logfile finde. Oder wie ich eins anlegen lassen kann?
In der Config habe ich das immer an:
# log settings log: error levels:   core: debug   lp-1: debug   lp-2: debug

Also verstehe ichs richtig:

target soc 80%
auto abziehen
auto mit 30% wieder anstecken
laden startet nicht?

 Was hat SoC kann nicht gelesen werden damit zu tun?
Richtig wäre: falls der SoC nicht gelesen werden kann, immer zu laden. Ziel: niemand steht mit leerem Auto da.

Also verstehe ichs richtig:

target soc 80%
auto abziehen
auto mit 30% wieder anstecken
laden startet nicht?

 Was hat SoC kann nicht gelesen werden damit zu tun?
Richtig wäre: falls der SoC nicht gelesen werden kann, immer zu laden. Ziel: niemand steht mit leerem Auto da.

Also verstehe ichs richtig:

target soc 80%
auto abziehen
auto mit 30% wieder anstecken
laden startet nicht?
Ganz genau, so ist es.

Wo ist das entsprechende Logfile?  Was hat SoC kann nicht gelesen werden damit zu tun?

Ich verstehe nicht was du mir damit sagen willst. Ich wollte wissen, ob irgendwo auf dem Raspberry das Logfile geschrieben wird. Wenn ich das wüsste könnte ich das Logfile hier posten.

Richtig wäre: falls der SoC nicht gelesen werden kann, immer zu laden. Ziel: niemand steht mit leerem Auto da.

Genau, das wäre schon mal der richtige Weg, für den Fall dass kein SOC neu eingelesen werden kann.
 Auch das Model 3 hat kein SOC angezeigt. Es stand nur "verbunden" da.
Nachdem ich EVCC neu gestartet habe hat wieder alles funktioniert.
Aktuell sieht man das, bei SOC werden angezeigt.

Zur Erklärung warum das Model 3 nicht lädt. Beim Model 3 habe ich intern ein Ladeziel von 80% eingestellt. Deshalb lädt er jetzt nicht weiter, EVCC Ladeziel steht auf 100%
WARUM?
Bei diesen Temperaturen wird der nutzbare SOC im Model 3 stückweise immer mal wieder um 1% reduziert (Akku Schutz). Wenn das passiert wird EVCC das 1% immer wieder nachladen. Ich möchte das aber nicht. Das Auto würde alle paar Stunden zum Laden geweckt und ein paar Minuten nachgeladen. Die Kapazität ist ja nicht weg, sondern wird nur nicht mit so kalten Akku genutzt.
Man könnte das ändern in dem man nicht den nutzbaren SOC an EVCC übergibt sondern den tatsächlichen SOC. Ob das besser oder schlechter ist könnte man diskutieren.

Also verstehe ichs richtig:

target soc 80%
auto abziehen
auto mit 30% wieder anstecken
laden startet nicht?
Ganz genau, so ist es.

Wo ist das entsprechende Logfile?  Was hat SoC kann nicht gelesen werden damit zu tun?

Ich verstehe nicht was du mir damit sagen willst. Ich wollte wissen, ob irgendwo auf dem Raspberry das Logfile geschrieben wird. Wenn ich das wüsste könnte ich das Logfile hier posten.

Richtig wäre: falls der SoC nicht gelesen werden kann, immer zu laden. Ziel: niemand steht mit leerem Auto da.

Genau, das wäre schon mal der richtige Weg, für den Fall dass kein SOC neu eingelesen werden kann.
 Auch das Model 3 hat kein SOC angezeigt. Es stand nur "verbunden" da.
Nachdem ich EVCC neu gestartet habe hat wieder alles funktioniert.
Aktuell sieht man das, bei SOC werden angezeigt.

Zur Erklärung warum das Model 3 nicht lädt. Beim Model 3 habe ich intern ein Ladeziel von 80% eingestellt. Deshalb lädt er jetzt nicht weiter, EVCC Ladeziel steht auf 100%
WARUM?
Bei diesen Temperaturen wird der nutzbare SOC im Model 3 stückweise immer mal wieder um 1% reduziert (Akku Schutz). Wenn das passiert wird EVCC das 1% immer wieder nachladen. Ich möchte das aber nicht. Das Auto würde alle paar Stunden zum Laden geweckt und ein paar Minuten nachgeladen. Die Kapazität ist ja nicht weg, sondern wird nur nicht mit so kalten Akku genutzt.
Man könnte das ändern in dem man nicht den nutzbaren SOC an EVCC übergibt sondern den tatsächlichen SOC. Ob das besser oder schlechter ist könnte man diskutieren.

Mir fehlt einfach ein aussagekräftiges Logfile um das nachvollziehen zu können.

Mir fehlt einfach ein aussagekräftiges Logfile um das nachvollziehen zu können.

Mir fehlt einfach ein aussagekräftiges Logfile um das nachvollziehen zu können.

Ja, das verstehe ich.
Kannst du mir bitte mitteilen wie ich ein Logfile finde oder ein neues erzeuge. Ich kann ja den Fehler bestimmt reproduzieren.

Mir fehlt einfach ein aussagekräftiges Logfile um das nachvollziehen zu können.

Ja, das verstehe ich.
Kannst du mir bitte mitteilen wie ich ein Logfile finde oder ein neues erzeuge. Ich kann ja den Fehler bestimmt reproduzieren.

Log wird einfach auf Konsole geschrieben, das sollte egtl zu sehen sein. Wie startest Du es denn?

Log wird einfach auf Konsole geschrieben, das sollte egtl zu sehen sein. Wie startest Du es denn?

Ich starte bzw. lassen EVCC automatisch über einen systemctl auf einen Raspberry starten. Deshalb sehe ich da nichts.
Mit Absicht habe ich das Issuetemplate nicht ignoriert. Der Code in den Issuetemplate ist im Editor für mich mit den ganzen Zeichen nicht so leicht zu lesen. Ich sehe es mir jetzt nochmal genau an und versuche hier alles zu beantworten.
EVCC details:
Show output of evcc -v:
evcc version 0.41 (c368f7d)

Show output of evcc dump -c configfile:
Unsupported Config Type ""

Show evcc configuration file evcc.yaml:
uri: <IP_ADDRESS>:7070 # uri for ui
interval: 10s # control cycle interval
log settings
log: error
levels:
core: debug
lp-1: debug
lp-2: debug
meter definitions
name can be freely chosen and is used as reference when assigning meters to site and loadpoints
for examples see https://github.com/andig/evcc-config#meters
meters:

name: sma-grid
type: sma
serial: 300613xxxx
name: sma-pv
type: modbus
model: sma-sunspec
uri: <IP_ADDRESS>:502
id: 126

charger definitions
name can be freely chosen and is used as reference when assigning charger to vehicle
for examples see https://github.com/andig/evcc-config#chargers
chargers:

name: GO-eCharger1
type: go-e # GO-eCharger
uri: http://<IP_ADDRESS>
name: GO-eCharger2
type: go-e
uri: http://<IP_ADDRESS>

vehicle definitions
vehicles:

name: tesla
type: tesla
title: Model 3
capacity: 79
clientid: xxx
clientsecret: xxx
user: xxx # your email address used on Tesla website
password: xxx # your password used on Tesla website password
vin: xxx # the VIN of you car (can be obtained from Tesla website)
cache: 5m

name: nissan
type: nissan
title: Leaf # display name for UI
capacity: 40 # kWh
user: xxx # user
password: xxx # password

region: DE # carwings region, leave empty for Europe
cache: 5m # cache API response
site describes the EVU connection, PV and home battery
site:
title: Vogelhaus # display name for UI
meters:
grid: sma-grid # grid meter
pv: sma-pv # pv meter
battery: battery # battery meter
prioritySoC: 60 # give home battery priority up to this soc (0 to disable)
loadpoint describes the charger, charge meter and connected vehicle
loadpoints:

title: Wallbox 1
charger: GO-eCharger1
vehicle: nissan
mode: now
soc:
poll:
mode: charging
interval: 5m
min: 0 # immediately charge to 0% regardless of mode unless "off" (disabled)
target: 80 # always charge to 100%
estimate: false # set true to interpolate between api updates
levels: # target soc levels for UI

30
50
80
100
onDisconnect: # set defaults when vehicle disconnects
mode: now # switch back to pv mode
targetSoC: 80 # charge to 100%
phases: 3 # ev phases (default 3)
enable: # pv mode enable behavior
delay: 1m # threshold must be exceeded for this long
threshold: 0 # minimum export power (W). If zero, export must exceed minimum charge power to enable
disable: # pv mode disable behavior
delay: 5m # threshold must be exceeded for this long
threshold: 200 # maximum import power (W)
guardduration: 5m # switch charger contactor not more often than this (default 10m)
mincurrent: 6 # minimum charge current (default 6A)
maxcurrent: 16 # maximum charge current (default 16A)

title: Wallbox 2
charger: GO-eCharger2

meters:
charge: charge # charge meter
vehicle: tesla
mode: now
soc:
poll:
mode: charging
interval: 5m
min: 0 # immediately charge to 0% regardless of mode unless "off" (disabled)
target: 80 # always charge to 100%
estimate: false # set true to interpolate between api updates
levels: # target soc levels for UI
- 30
- 50
- 80
- 100
onDisconnect: # set defaults when vehicle disconnects
mode: now # switch back to pv mode
targetSoC: 80 # charge to 100%
phases: 3 # ev phases (default 3)
enable: # pv mode enable behavior
delay: 1m # threshold must be exceeded for this long
threshold: 0 # minimum export power (W).  USE AT YOUR OWN RISK.
[lp-2  ] WARN 2021/01/26 20:42:58 poll interval '5m0s' is lower than 1h0m0s and may deplete your battery or lead to API misuse.  Deshalb sehe ich da nichts.
Mit Absicht habe ich das Issuetemplate nicht ignoriert. Der Code in den Issuetemplate ist im Editor für mich mit den ganzen Zeichen nicht so leicht zu lesen. Ich sehe es mir jetzt nochmal genau an und versuche hier alles zu beantworten.
EVCC details:
Show output of evcc -v:
evcc version 0.41 (c368f7d)

Show output of evcc dump -c configfile:
Unsupported Config Type ""

Show evcc configuration file evcc.yaml:
uri: <IP_ADDRESS>:7070 # uri for ui
interval: 10s # control cycle interval
log settings
log: error
levels:
core: debug
lp-1: debug
lp-2: debug
meter definitions
name can be freely chosen and is used as reference when assigning meters to site and loadpoints
for examples see https://github.com/andig/evcc-config#meters
meters:

name: sma-grid
type: sma
serial: 300613xxxx
name: sma-pv
type: modbus
model: sma-sunspec
uri: <IP_ADDRESS>:502
id: 126

charger definitions
name can be freely chosen and is used as reference when assigning charger to vehicle
for examples see https://github.com/andig/evcc-config#chargers
chargers:

name: GO-eCharger1
type: go-e # GO-eCharger
uri: http://<IP_ADDRESS>
name: GO-eCharger2
type: go-e
uri: http://<IP_ADDRESS>

vehicle definitions
vehicles:

name: tesla
type: tesla
title: Model 3
capacity: 79
clientid: xxx
clientsecret: xxx
user: xxx # your email address used on Tesla website
password: xxx # your password used on Tesla website password
vin: xxx # the VIN of you car (can be obtained from Tesla website)
cache: 5m

name: nissan
type: nissan
title: Leaf # display name for UI
capacity: 40 # kWh
user: xxx # user
password: xxx # password

region: DE # carwings region, leave empty for Europe
cache: 5m # cache API response
site describes the EVU connection, PV and home battery
site:
title: Vogelhaus # display name for UI
meters:
grid: sma-grid # grid meter
pv: sma-pv # pv meter
battery: battery # battery meter
prioritySoC: 60 # give home battery priority up to this soc (0 to disable)
loadpoint describes the charger, charge meter and connected vehicle
loadpoints:

title: Wallbox 1
charger: GO-eCharger1
vehicle: nissan
mode: now
soc:
poll:
mode: charging
interval: 5m
min: 0 # immediately charge to 0% regardless of mode unless "off" (disabled)
target: 80 # always charge to 100%
estimate: false # set true to interpolate between api updates
levels: # target soc levels for UI

30
50
80
100
onDisconnect: # set defaults when vehicle disconnects
mode: now # switch back to pv mode
targetSoC: 80 # charge to 100%
phases: 3 # ev phases (default 3)
enable: # pv mode enable behavior
delay: 1m # threshold must be exceeded for this long
threshold: 0 # minimum export power (W). If zero, export must exceed minimum charge power to enable
disable: # pv mode disable behavior
delay: 5m # threshold must be exceeded for this long
threshold: 200 # maximum import power (W)
guardduration: 5m # switch charger contactor not more often than this (default 10m)
mincurrent: 6 # minimum charge current (default 6A)
maxcurrent: 16 # maximum charge current (default 16A)

title: Wallbox 2
charger: GO-eCharger2

meters:
charge: charge # charge meter
vehicle: tesla
mode: now
soc:
poll:
mode: charging
interval: 5m
min: 0 # immediately charge to 0% regardless of mode unless "off" (disabled)
target: 80 # always charge to 100%
estimate: false # set true to interpolate between api updates
levels: # target soc levels for UI
- 30
- 50
- 80
- 100
onDisconnect: # set defaults when vehicle disconnects
mode: now # switch back to pv mode
targetSoC: 80 # charge to 100%
phases: 3 # ev phases (default 3)
enable: # pv mode enable behavior
delay: 1m # threshold must be exceeded for this long
threshold: 0 # minimum export power (W).  USE AT YOUR OWN RISK.
[lp-2  ] WARN 2021/01/26 20:42:58 poll interval '5m0s' is lower than 1h0m0s and may deplete your battery or lead to API misuse.    Für den PV oder Awattar Case brauchts sowas Ähnliches.

Schau mal hier: https://github.com/andig/evcc/blob/master/core/soc/soctimer.go. Für den PV oder Awattar Case brauchts sowas Ähnliches.

Ah. Nein, das findest du da nicht.
Mir war nicht bewusst, dass du das hier brauchst tut mir leid.
Ich weiß jetzt was ich tun muss und werde morgen, wenn ich mein Auto wieder anstecke tracen.

Ah. Nein, das findest du da nicht.
Mir war nicht bewusst, dass du das hier brauchst tut mir leid.
Ich weiß jetzt was ich tun muss und werde morgen, wenn ich mein Auto wieder anstecke tracen.

Wo ist das entsprechende Logfile?  Was hat SoC kann nicht gelesen werden damit zu tun?

Ok, dann neuer Versuch und Logfile. Wenn ich sehe, was passiert kann ich auch rausfinden warum ;)

Wo ist das entsprechende Logfile?  Was hat SoC kann nicht gelesen werden damit zu tun?

Ok, dann neuer Versuch und Logfile. Wenn ich sehe, was passiert kann ich auch rausfinden warum ;)

@martinez81 wenn du über SystemD startest, kannst du das Log nachträglich sehen über journalctl -e -u evcc.service

@martinez81 wenn du über SystemD startest, kannst du das Log nachträglich sehen über journalctl -e -u evcc.service

Ich kann aus den Beiträgen oben nicht lesen, welches Auto (Leaf oder Model3) von dem Fehler betroffen ist. Wenn es um den Leaf geht, dann habe ich einen Verdacht, mir ist gestern dasselbe passiert. Es ist offenbar immer noch so, dass bei der SoC-Abfrage des Leaf anfangs ein veralteter Wert  zurückgegeben wird, im geschilderten Fall kann es sein, dass bei der ersten Abfrage nach dem Anstecken der SoC-Wert vor der Abfahrt zurückgegeben wird und kein Ladebedarf erkannt wird. Martinez, das kannst Du einfach prüfen, indem Du während der Fahrt bzw. kurz vor dem Anstecken mit der Nissan-App oder MyLeaf mal den SoC checkst. Dann ist der aktuelle Wert im "Cache", und evcc bekommt bei der Abfrage einen realistischen Wert.

Folgende Ereignisse sind wichtig:
Leaf aufgeladen am Mittag bis SoC 87% (nicht im Log enthalten). Abfahrt ca. 15:00
Neustart von evcc v0.41 um 15:56:39 (Zeile 1)
Rückkehr und Anstecken des Leaf um 18:02:29 (Zeile 7112). SoC laut Fahrzeugdisplay: 63%
Start der Aufladung mit 19A Ladestrom.
Abfrage des SoC bei Nissan um 18:03:00. (Zeile 7162) Sofortige Rückmeldung eines SoC von 87%- das ist unplausibel, denn die Abfrage dauert 30 sek. bis eine Minute. Es ist der Wert vor der Abfahrt.
Feststellung, dass "targetSoC reached: 87.0 > 80 ... charger disable" (Zeile 7176). Ladung wird beendet.
Um 18:25:56 setze ich im Webinterface den SoC auf 90. (Zeile 8362). Die Ladung beginnt.
Um 18:26:30 wird erneut der SoC bei Nissan abgefragt, er liefert den korrekten Wert 63% zurück. (Zeile 8453)
Um 18:57:18 setze ich im Webinterface den SoC auf 80 zurück. (Zeile 10608).
Um 21:28:30 wird ein SoC von 80% erreicht und die Ladung beendet.  (Zeile 20767)
Es müsste in EVCC sichergestellt werden, dass der SoC-Wert wirklich aktuell ist, z.B. den ersten Wert verwerfen und erst den zweiten Wert nehmen.
Ich hoffe, das hilft weiter.
Beste Grüße,
Gunnar
evcc.log

Ich kann aus den Beiträgen oben nicht lesen, welches Auto (Leaf oder Model3) von dem Fehler betroffen ist. Wenn es um den Leaf geht, dann habe ich einen Verdacht, mir ist gestern dasselbe passiert. Es ist offenbar immer noch so, dass bei der SoC-Abfrage des Leaf anfangs ein veralteter Wert  zurückgegeben wird, im geschilderten Fall kann es sein, dass bei der ersten Abfrage nach dem Anstecken der SoC-Wert vor der Abfahrt zurückgegeben wird und kein Ladebedarf erkannt wird. Martinez, das kannst Du einfach prüfen, indem Du während der Fahrt bzw. kurz vor dem Anstecken mit der Nissan-App oder MyLeaf mal den SoC checkst. Dann ist der aktuelle Wert im "Cache", und evcc bekommt bei der Abfrage einen realistischen Wert.

Folgende Ereignisse sind wichtig:
Leaf aufgeladen am Mittag bis SoC 87% (nicht im Log enthalten). Abfahrt ca. 15:00
Neustart von evcc v0.41 um 15:56:39 (Zeile 1)
Rückkehr und Anstecken des Leaf um 18:02:29 (Zeile 7112). SoC laut Fahrzeugdisplay: 63%
Start der Aufladung mit 19A Ladestrom.
Abfrage des SoC bei Nissan um 18:03:00. (Zeile 7162) Sofortige Rückmeldung eines SoC von 87%- das ist unplausibel, denn die Abfrage dauert 30 sek. bis eine Minute. Es ist der Wert vor der Abfahrt.
Feststellung, dass "targetSoC reached: 87.0 > 80 ... charger disable" (Zeile 7176). Ladung wird beendet.
Um 18:25:56 setze ich im Webinterface den SoC auf 90. (Zeile 8362). Die Ladung beginnt.
Um 18:26:30 wird erneut der SoC bei Nissan abgefragt, er liefert den korrekten Wert 63% zurück. (Zeile 8453)
Um 18:57:18 setze ich im Webinterface den SoC auf 80 zurück. (Zeile 10608).
Um 21:28:30 wird ein SoC von 80% erreicht und die Ladung beendet.  (Zeile 20767)
Es müsste in EVCC sichergestellt werden, dass der SoC-Wert wirklich aktuell ist, z.B. den ersten Wert verwerfen und erst den zweiten Wert nehmen.
Ich hoffe, das hilft weiter.
Beste Grüße,
Gunnar
evcc.log

Moin Gunnar,
welches Auto bei mir den Fehler hatte, bzw. verursacht hat... Aus dem Bauch heraus würde ich sagen beide. Aber das werde ich genau testen.
Danke!

Moin Gunnar,
welches Auto bei mir den Fehler hatte, bzw. verursacht hat... Aus dem Bauch heraus würde ich sagen beide. Aber das werde ich genau testen.
Danke!

So, heute habe ich es hoffentlich zufriedenstellen und ergebnisorientiert untersucht und notiert.
Da ist 4x mal den EVCC im Testablauf neu gestartet habe hänge ich 4 Logs hier an.
Ich hoffe sehr, dass wir so das Problem finden.
Nur nur der Leaf startet nicht wieder sondern auch das Model 3. Ich gehe also davon aus, das es nicht mit der schlechten API des Nissan Leaf zu tun hat.
 Aber es muss meiner Meinung nach, wenn keine neuen Daten vom SOC kommen geladen werden. Ein leerer Akku muss verhindert werden.
Jetzt zu meiner Auswertung.
Ablauf:
13:18 Uhr EVCC Neustart mit Trace im Terminal ($ sudo evcc  --log trace)
13:20 Uhr Model 3 mit SOC 77% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt
13:21 Uhr Leaf mit SOC 54% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt
13:31 Uhr Model 3 erreicht SOC 80% EVCC beendet das Laden
14:08 Uhr Model 3 abgesteckt
16:50 Uhr Model 3 mit SOC 61% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt NICHT
16:51 Uhr Leaf mit SOC 81% abgesteckt (kurze Testfahrt mit den Leaf um den SOC unter 80% zu bringen)
16:57 Uhr Leaf mit SOC 76% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt NICHT
17:04 Uhr beide Autos laden nicht, sind aber angeschlossen
17:04 Uhr EVCC Neustart
17:04 Uhr Model 3 bekommt sofort den aktuellen SOC von 61%, EVCC startet das Laden
17:04 Uhr Leaf hat noch einen SOC von 81% (real aber 76%) im EVCC beginnt kurz zu laden und nach ca. 30 sek stoppt EVCC das Laden
17:16 Uhr Model 3 lädt, Leaf hat immer noch im EVCC einen SOC von 81% (real 76%) und wird deshalb nicht geladen.
17:17 Uhr EVCC Neustart
17:18 Uhr Model 3 lädt (SOC aktuell), Leaf hat immer noch im EVCC einen SOC von 81% (real 76%) und wird deshalb nicht geladen.
17:19 Uhr Leaf SOC wird über App abgerufen. App zeigt 81% an (real 76%), reload gesendet.
17:24 Uhr Leaf SOC wird immer noch nicht korrekt in der App angezeigt, App sagt SOC 81%, App mehrmals alle 5 Min zum SOC pushen angeregt.
18:11 Uhr Leaf App, endlich wird jetzt der aktuellen SOC 76% angezeigt.
18:13 Uhr EVCC Leaf SOC immer noch bei 81%
18:26 Uhr Model 3 SOC 80% erreicht EVCC beendet das Laden vom Model 3
18:32 Uhr Leaf abgesteckt und wieder neu angesteckt.
18:45 Uhr Leaf hat im EVCC immernoch das alten SOC von 81%, die Leaf App zeigt 76% an. Der Leaf wird nicht geladen.
18:47 Uhr EVCC stop.
18:47 Uhr EVCC start
18:48 Uhr Leaf bekommt sofort neuen aktuellen SOC von 76%, EVCC beginnt mit Laden
18:49 Uhr Test wird beendet. EVCC Stop.
Ich bekomme hier eine Fehlermeldung beim Einfügen von den ganzen Logfiles, deshalb im nächsten Post per zip File.
"You can't comment at this time — your comment is too long (maximum is 65536 characters)."

So, heute habe ich es hoffentlich zufriedenstellen und ergebnisorientiert untersucht und notiert.
Da ist 4x mal den EVCC im Testablauf neu gestartet habe hänge ich 4 Logs hier an.
Ich hoffe sehr, dass wir so das Problem finden.
Nur nur der Leaf startet nicht wieder sondern auch das Model 3. Ich gehe also davon aus, das es nicht mit der schlechten API des Nissan Leaf zu tun hat.
 Aber es muss meiner Meinung nach, wenn keine neuen Daten vom SOC kommen geladen werden. Ein leerer Akku muss verhindert werden.
Jetzt zu meiner Auswertung.
Ablauf:
13:18 Uhr EVCC Neustart mit Trace im Terminal ($ sudo evcc  --log trace)
13:20 Uhr Model 3 mit SOC 77% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt
13:21 Uhr Leaf mit SOC 54% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt
13:31 Uhr Model 3 erreicht SOC 80% EVCC beendet das Laden
14:08 Uhr Model 3 abgesteckt
16:50 Uhr Model 3 mit SOC 61% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt NICHT
16:51 Uhr Leaf mit SOC 81% abgesteckt (kurze Testfahrt mit den Leaf um den SOC unter 80% zu bringen)
16:57 Uhr Leaf mit SOC 76% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt NICHT
17:04 Uhr beide Autos laden nicht, sind aber angeschlossen
17:04 Uhr EVCC Neustart
17:04 Uhr Model 3 bekommt sofort den aktuellen SOC von 61%, EVCC startet das Laden
17:04 Uhr Leaf hat noch einen SOC von 81% (real aber 76%) im EVCC beginnt kurz zu laden und nach ca. 30 sek stoppt EVCC das Laden
17:16 Uhr Model 3 lädt, Leaf hat immer noch im EVCC einen SOC von 81% (real 76%) und wird deshalb nicht geladen.
17:17 Uhr EVCC Neustart
17:18 Uhr Model 3 lädt (SOC aktuell), Leaf hat immer noch im EVCC einen SOC von 81% (real 76%) und wird deshalb nicht geladen.
17:19 Uhr Leaf SOC wird über App abgerufen. App zeigt 81% an (real 76%), reload gesendet.
17:24 Uhr Leaf SOC wird immer noch nicht korrekt in der App angezeigt, App sagt SOC 81%, App mehrmals alle 5 Min zum SOC pushen angeregt.
18:11 Uhr Leaf App, endlich wird jetzt der aktuellen SOC 76% angezeigt.
18:13 Uhr EVCC Leaf SOC immer noch bei 81%
18:26 Uhr Model 3 SOC 80% erreicht EVCC beendet das Laden vom Model 3
18:32 Uhr Leaf abgesteckt und wieder neu angesteckt.
18:45 Uhr Leaf hat im EVCC immernoch das alten SOC von 81%, die Leaf App zeigt 76% an. Der Leaf wird nicht geladen.
18:47 Uhr EVCC stop.
18:47 Uhr EVCC start
18:48 Uhr Leaf bekommt sofort neuen aktuellen SOC von 76%, EVCC beginnt mit Laden
18:49 Uhr Test wird beendet. EVCC Stop.
Ich bekomme hier eine Fehlermeldung beim Einfügen von den ganzen Logfiles, deshalb im nächsten Post per zip File.
"You can't comment at this time — your comment is too long (maximum is 65536 characters)."

Logfiles:
13.18 Uhr EVCC Start Terminal-Ausgabe.txt
17.04 Uhr EVCC Neustart Terminal-Ausgabe.txt
17.17 Uhr EVCC Neustart Terminal-Ausgabe.txt
17.47 Uhr EVCC Neustart Terminal-Ausgabe.txt
EVCC Terminal-Ausgabe.zip

Logfiles:
13.18 Uhr EVCC Start Terminal-Ausgabe.txt
17.04 Uhr EVCC Neustart Terminal-Ausgabe.txt
17.17 Uhr EVCC Neustart Terminal-Ausgabe.txt
17.47 Uhr EVCC Neustart Terminal-Ausgabe.txt
EVCC Terminal-Ausgabe.zip

Super. Erste Erkenntnis von hinten:

18:45 Uhr Leaf hat im EVCC immernoch das alten SOC von 81%, die Leaf App zeigt 76% an. Der Leaf wird nicht geladen.
16:50 Uhr Model 3 mit SOC 61% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt NICHT

Da gibts anscheinend einen Fehler mit mode: charging, analysieren wir gerade in Slack. Klingt genau so. Aus irgendeinem Grund wird auch beim Reconnect der SoC nicht abgefragt obwohl er sollte.

17:19 Uhr Leaf SOC wird über App abgerufen. App zeigt 81% an (real 76%), reload gesendet.

Das müssen wir akzeptieren.  An der Stelle: keine Chance. Ok?
@martinez81 je nachdem wie fit Du bist: eine Remote Debug Session mit LiveShare uns VSCode wäre der Traum- dann könnte ich direkt bei Dir rein schauen. Falls Du Go hast und das compiliert bekommst?

Super. Erste Erkenntnis von hinten:

18:45 Uhr Leaf hat im EVCC immernoch das alten SOC von 81%, die Leaf App zeigt 76% an. Der Leaf wird nicht geladen.
16:50 Uhr Model 3 mit SOC 61% angeschlossen, Zielladen über EVCC auf 80% - laden beginnt NICHT

Da gibts anscheinend einen Fehler mit mode: charging, analysieren wir gerade in Slack. Klingt genau so. Aus irgendeinem Grund wird auch beim Reconnect der SoC nicht abgefragt obwohl er sollte.

17:19 Uhr Leaf SOC wird über App abgerufen. App zeigt 81% an (real 76%), reload gesendet.

Das müssen wir akzeptieren.  An der Stelle: keine Chance. Ok?
@martinez81 je nachdem wie fit Du bist: eine Remote Debug Session mit LiveShare uns VSCode wäre der Traum- dann könnte ich direkt bei Dir rein schauen. Falls Du Go hast und das compiliert bekommst?

Da gibts anscheinend einen Fehler mit mode: charging, analysieren wir gerade in Slack. Klingt genau so. Aus irgendeinem Grund wird auch beim Reconnect der SoC nicht abgefragt obwohl er sollte. Mit mode: connected geht es vmtl, aber das willst Du egtl. ja nicht.

Ja, das will ich vermeiden. Das hält das Auto wach, und kostet beim Model gute 300-400Wh.

17:19 Uhr Leaf SOC wird über App abgerufen. App zeigt 81% an (real 76%), reload gesendet.

Das müssen wir akzeptieren.  An der Stelle: keine Chance. Ok?

Richtig, das ist der schlechten API oder Nissan Server geschuldet. Gestern war es echt schlimm. Heute ging es ziemlich schnell, dass er den aktuellen Wert hatte.

@martinez81 je nachdem wie fit Du bist: eine Remote Debug Session mit LiveShare uns VSCode wäre der Traum- dann könnte ich direkt bei Dir rein schauen. Falls Du Go hast und das compiliert bekommst?

Gerne kann ich helfen, wenn es das Projekt voran bringt.
Go und VSCode habe ich eben auf den Mac geladen.
Welchen zeitlichen Ablauf denkst du an? 40 Std Arbeitswoche, Familie mit kleinen Kinder ist vorhanden ;)
30 Min per Teamviewer ist kein Thema, wenn das aber ein paar Stunden bis spät in die Nacht gehen soll, wird das schwierig...

Da gibts anscheinend einen Fehler mit mode: charging, analysieren wir gerade in Slack. Klingt genau so. Aus irgendeinem Grund wird auch beim Reconnect der SoC nicht abgefragt obwohl er sollte. Mit mode: connected geht es vmtl, aber das willst Du egtl. ja nicht.

Ja, das will ich vermeiden. Das hält das Auto wach, und kostet beim Model gute 300-400Wh.

17:19 Uhr Leaf SOC wird über App abgerufen. App zeigt 81% an (real 76%), reload gesendet.

Das müssen wir akzeptieren.  An der Stelle: keine Chance. Ok?

Richtig, das ist der schlechten API oder Nissan Server geschuldet. Gestern war es echt schlimm. Heute ging es ziemlich schnell, dass er den aktuellen Wert hatte.

@martinez81 je nachdem wie fit Du bist: eine Remote Debug Session mit LiveShare uns VSCode wäre der Traum- dann könnte ich direkt bei Dir rein schauen. Falls Du Go hast und das compiliert bekommst?

Gerne kann ich helfen, wenn es das Projekt voran bringt.
Go und VSCode habe ich eben auf den Mac geladen.
Welchen zeitlichen Ablauf denkst du an? 40 Std Arbeitswoche, Familie mit kleinen Kinder ist vorhanden ;)
30 Min per Teamviewer ist kein Thema, wenn das aber ein paar Stunden bis spät in die Nacht gehen soll, wird das schwierig...

Bist du bei uns im Slack? Link siehe Wiki? LiveShare Plugin für vscode installiert? Debuggen mit Deiner normalen Config geht? Dann könntest mich mal über LiveShare einladen. Teamviewer müssten wir übers WE verabreden.

Bist du bei uns im Slack? Link siehe Wiki? LiveShare Plugin für vscode installiert? Debuggen mit Deiner normalen Config geht? Dann könntest mich mal über LiveShare einladen. Teamviewer müssten wir übers WE verabreden.

@junibart das Leafproblem müssen wir uns nochmal extra anschauen. Hier ist irgendwas anderes faul.

@junibart das Leafproblem müssen wir uns nochmal extra anschauen. Hier ist irgendwas anderes faul.

Ich glaube ich habs gefunden. Falls ihr so nicht testen könnt würde ich es mergen.

Ich glaube ich habs gefunden. Falls ihr so nicht testen könnt würde ich es mergen.

Super!
Wenn du mir ein fertiges File für linux_armv6 sendest, teste ich es gern!

Super!
Wenn du mir ein fertiges File für linux_armv6 sendest, teste ich es gern!

ARMv6: evcc.gz

ARMv6: evcc.gz

Ich habe das File eben drauf gespielt. Ich werden berichten.

Ich habe das File eben drauf gespielt. Ich werden berichten.

...uuuuuuuund? Eine Positivmeldung hab ich schon. Falls Du nicht dazu kommst würde ich es sonst einfach durchschieben.

...uuuuuuuund? Eine Positivmeldung hab ich schon. Falls Du nicht dazu kommst würde ich es sonst einfach durchschieben.

Ich bin seit 12 Uhr unterwegs.... 400km
Ich komme erst 19 Uhr wieder zuhause an.
Du kannst es auch durchschieben...

Ich bin seit 12 Uhr unterwegs.... 400km
Ich komme erst 19 Uhr wieder zuhause an.
Du kannst es auch durchschieben...

Hi,
ich kann auch etwas positives berichten.
Poll mode "charging", mit der Armv6-Datei hier aus dem issue zwei Ladevorgänge gestartet: In beiden Fällen wird wie gewünscht der SoC abgefragt und anschließend geladen.
Ich kann aber auch bestätigen, dass es nach wie vor mit der Aktualität des SoC von Nissan hapert.  Das führt auch immer dazu, dass der Leaf bei Ziel-SoC 80% bis 82% real geladen wird.
Hätte ein neues, aktuelles Tracelog von heute, das dieses Verhalten zeigt.
Wollen wir dazu #488 nochmal aufmachen oder soll es ein neues Issue sein?

Hi,
ich kann auch etwas positives berichten.
Poll mode "charging", mit der Armv6-Datei hier aus dem issue zwei Ladevorgänge gestartet: In beiden Fällen wird wie gewünscht der SoC abgefragt und anschließend geladen.
Ich kann aber auch bestätigen, dass es nach wie vor mit der Aktualität des SoC von Nissan hapert.  Das führt auch immer dazu, dass der Leaf bei Ziel-SoC 80% bis 82% real geladen wird.
Hätte ein neues, aktuelles Tracelog von heute, das dieses Verhalten zeigt.
Wollen wir dazu #488 nochmal aufmachen oder soll es ein neues Issue sein?

 Das führt auch immer dazu, dass der Leaf bei Ziel-SoC 80% bis 82% real geladen wird.

Das wär ja erstmal nicht so schlimm. Mach bitte ein neues Ticket.  Das führt auch immer dazu, dass der Leaf bei Ziel-SoC 80% bis 82% real geladen wird.

Das wär ja erstmal nicht so schlimm. Mach bitte ein neues Ticket. Wir müssten rausfinden:

wo das heute wirklich ein Problem ist (jenseits von Optik)
wie der SoC verlässlich ausgelesen werden kann ohne dabei die Regelungslogik aus dem Trab zu bringen


Short issue title

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

ITT technical institute of technology and

Hey there @khyveasna11111908 I'm going to go ahead and close this issue but feel free to open another with more information filled out! Thanks!


Allow Reentrancy for Actors

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-reentrancy

This is a duplicate of: https://github.com/dapr/dapr/issues/2901


Highlight parts of the card when start swiping.

Hi man,
Thanks for the library. It's great and it fits almost all my requirements. There's one thing I can't do.
I have like 2 relative layouts in the bottom of the card with text and image and I would like to highlight (change color) of each of them depending if I'm swiping left or right. Basically similar to what the library already does with the left/right images overlay.
Is there a way to make this work with layouts or maybe another event that I can listen to, to make this works.
Thanks for the help.

hmm at one point i was going to expose the x and y values for the card to allow for more customization, i haven't done that yet.
what do you mean by highlight?

By highlighting I mean animate a background in my button layouts inside the card view.
I ended up achieving it by setting image left and right as background drawables on the buttons and now I have the desired effect.
Another thing that would be nice to have smoother animations was to allow custom duration on the swipe ones as they are hard coded in the library. And interpolators.
And also I've been doing some testing and on the swipe left off screen animation if you put the below code to remove the card and get the new card inside animation.endWithAction it looks way smoother.

if you want to make some changes, send a pull request i'd be happy to add them.

Cool. If I have some time in the weekend I'll send a pull request with the little changes I did

that would be great, and if i have time i'll consider the custom animations
idea. it's a good one.
On Fri, Mar 4, 2016 at 10:08 PM, Joao Alves<EMAIL_ADDRESS>wrote:

Cool. If I have some time in the weekend I'll send a pull request with the
little changes I did
—
Reply to this email directly or view it on GitHub
https://github.com/aaronbond/Swipe-Deck/issues/19#issuecomment-192235972
.


Refactor logic when creating extension via CLI

Summary
Refactored the code so it now creates a new extension request with the version 999-snapshot
Please check the relevant options

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Dependency update
[x] Refactoring
[ ] Release (follows conventions described in the RELEASE.md)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] This change requires a documentation update
[ ] This change requires execution against OCP (use run tests phrase in comment)

Checklist:

[x] Example scenarios has been updated / added
[x] Methods and classes used in PR scenarios are meaningful
[x] Commits are well encapsulated and follow the best practices

Thanks @TimonCzech , I am not sure, but don't have time to invest ATM. @jedla97 please check thoroughly

CI is green, so merging.


strides function implementation

It is deprecated functionality in pandas since version 0.23.0 (ref).

It was removed from pandas (ref).


Update PMTL Landing Page text to v1.1

Update PMTL Landing Page text to v1.1.  The tickt number is PPDC-171

LGTM


Plugins lost saved settings

Over night, all my plugins were disabled (minus homeworld). I lost all my bank tags/tabs, screen markers, tile markers, etc.). I have tried to restore from a previous version but there were none that were able to be recovered. Even now, I can't use some plugins such as item prices. I would like the most to get the bank tabs back if possible.

Closing as incredibly stale.
For further questions of support, please join the Discord


Falco Trace Github Link Fix

Falco Trace  Url
https://github.com/krisnova/falco-trace - failing
https://github.com/kris-nova/falco-trace - working
Signed-off-by: Ercan Aydoğan<EMAIL_ADDRESS>
What type of PR is this?
content
Any specific area of the project related to this PR?
documentation
What this PR does / why we need it:
Falco Trace link pointing wrong github url.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Hey @eaydogan
Good catch! And thank you for opening this PR. It LGTM, however, we do not allow merge commits. Could you rebase instead? Let me know if you need any help.
cc @kris-nova :hugs:

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Already fixed by https://github.com/falcosecurity/falco-website/pull/530
/close

@leogr: Closed this PR.

In response to this:

Already fixed by https://github.com/falcosecurity/falco-website/pull/530
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Newsletter 7: Add Veloren February content

Part of #64 ("Newsletter 7: Coordination/Tracking")
This includes a Youtube iframe template. Hopefully it's ok to add.

This includes a Youtube iframe template. Hopefully it's ok to add.

Hmm. I've been deliberately trying to avoid everything that GitHub's Markdown render can't handle - so previews & diffs stay useful.
@17cupsofcoffee @Lokathor @AlexEne @erlend-sh - what do you think?

I would go for the ease of preview, you can leave it as a link

I have no philosophical objection to including YouTube embeds in the newsletter, but would also slightly lean towards doing them in a way that shows up on GitHub's PR preview if at all possible.
If you put the embed HTML directly in the markdown file, does it show up on GitHub? If so, maybe we could keep the CSS classes and provide an example of how to use them in the 'ideal section structure' at the top of the newsletter template? Might be less maintainable though, somewhat torn 😅

If you put the embed HTML directly in the markdown file, does it show up on GitHub?

Nope, GitHub's Markdown doesn't support it.

Bah, understandable (would probably be a security nightmare) but annoying!

I understand that it would be great to be able to preview what it looks like in the PR, but it really seems like we'd be shooting ourselves in the foot on this one. Youtube videos are a good standard of something that plays videos on the newsletter, and I imagine there will be times that this comes up again in the future.
As far as I can find, there isn't anything that can embed youtube videos into Github markdown without doing an external link.

As a bonus it also makes for easier diffs like @ozkriff  said.

I usually used either GIFs or youtube screenshots for linking to videos.

Another potential consideration would be that if we allowed YouTube embeds, we'd have to strip them out if we ever started sending the newsletter out as an email, as most email clients block iframes. That kinda makes me lean towards @ozkriff's suggestion, although I agree it's not ideal to not have the videos inline.

kk sounds good, I'll go for the gif option

@ozkriff Should be good to go now :)


Try using DOT to describe changes to a document -> LLM Code Llama

DOT:
digraph G {
    User -> MySection_1 [label="renamed from My Cars to My Favourite Cars"]
    User -> MySection_0 [label="Removed"]
    User -> MySection_3 [label="Added"]
}

https://dreampuf.github.io/GraphvizOnline
what is the overall purpose of this DOT graph:

digraph G {
    User -> MySection_1 [label="renamed from My Cars to My Favourite Cars"]
    User -> MySection_0 [label="Removed"]
    User -> MySection_3 [label="Added"]
}

Mistral 7B - does produce some summary ...
https://huggingface.co/chat


Single Variable in variable view does not show size

Testing #203058
I'm not sure if this is intentional, but size for single variable does not show size 1.
(For example, for boolean and integer does not show size at all)
Do we want to have size 1 instead of blank space?

that is the extension's view, no plans to update that one.


WIP: Add webtransport

Hi friends:
@ten3roberts and I are taking on adding this feature, we are not sure if we will keep it here or move it to a separate crate, but this works!!
I already added webtransport support to web apps written in rust via wasm-bindgen: https://github.com/rustwasm/wasm-bindgen/pull/3344
Reddit demanded it: https://www.reddit.com/r/rust/comments/11rfes0/comment/jc8kyax/?utm_source=share&utm_medium=web2x&context=3
Work left

[x] Move webtransport into its own crate
[x]  Server initiated Datagrams
[x]  client initiated Datagrams
[x]  Better api for incoming bi streams
[ ]  Session termination
[x]  Server initiated uni streams
[x]  Server initiated bi streams
[ ] Request pass through (possibly as part of incoming bi streams)
[ ] Rebase onto latest changes

Hi again.
We were just in a discussion about forking and implementing webtransport per #71 here over at https://github.com/AmbientRun
What are your plans moving forwards and for the API?
I would like to help with this.
Dropping the webtransport protocol draft for good measure
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
Furthermore, there is an implementation in python and go already, so may serve as inspiration.
python sample: https://github.com/GoogleChrome/samples/blob/gh-pages/webtransport/webtransport_server.py
go: https://github.com/adriancable/webtransport-go-example

Hey @ten3roberts !!!
Let's do this!
I am familiar with aioquic, I came from that lib but had to abandon it because I encountered many leaks, but you are right, as of now it is kind of the "reference" implementation for server side webtransport.
So how about this:
Implement the bare minimal changes in this MR so that we end up with a webtransport server that works as an echo server and we can call from https://security-union.github.io/yew-webtransport/ Yew WebTransport client.
Right now I am looking at the new frame types that we have to add, tonight (Eastern time) I will break this down into tasks, we can tag team this project if you are interested 😄

Thanks for starting this effort! I haven't kept track of the spec, so I wanted to ask: how much if it is a protocol on top of http3? Is it like websockets? Where it just uses some generic mechanism and otherwise is implemented on top (and this could be a separate library)? Maybe just a new setting, like we did with "extended connect" in h2? Or does it need a lot of integration?

Hey @seanmonstar it is extremely similar to websockets.
regarding settings, yes!! there are a couple new settings that the standard introduces

My idea is to have a WebTransportSession type which is constructed using an h3::Connection and established the wt negotiation, similar to the go example listed earlier.
After awaiting the WebTransportSession it is used to await incoming streams, datagrams, and open new streams, very much like a quinn::Connection
Thoughts?
@darioalessandro I could work on the uni and bi streams of the protocol. Are you going to add me as a contributor to your fork or what is the best way to go about it?

On a further note: Should we expose a Config struct similar to what quiche does https://docs.rs/quiche/latest/quiche/h3/struct.Config.html to make the webtransport support optional, as all servers using h3 don't want to automatically broadcast and respond that yes, webtransport is indeed supported by the server.
This goes on with my previous comment about the session struct, rather than baking *WebTransport` events into the other existing http/3 events such as requests.

@ten3roberts I added you as maintainer.

Regarding config: how about adding a second parameter to h3::server::Connection::new with the config struct (to your point, similar to quiche), right now, it just takes que quinn connection: https://github.com/hyperium/h3/blob/3bb88ab369df5cd1fe0c2b498f772bc556d47ccb/h3-quinn/src/lib.rs#L40
Do you want to get started with this? how should we divy up the work?

Thanks, you too.

That would be a very good idea, since the builder way to create a connection is less obvious/hidden, and being clear about what exists is usually good.

I could work with anything really. We will need support for both the server and client part of the things. What do you think about my WebTransportSession type proposal, making a webtransport opt in? First order of business would be establishing a session on either side.

PS: My timezone is Z+0200 and will be working days between roughly 9am-5am
I'll fix the merge conflicts on my PR and then you can merge the PR and we can work on the same branch

@ten3roberts

move forward with the WebTransportSession approach sounds good to me.
With regards to the client, you can test with my ui https://security-union.github.io/yew-webtransport/ it is not perfect so do keep the console open (sometimes it does not show all errors)

Hi,
I don't want to mix everything up here, but I would like to share my thoughts.
I think it would be best to only implement http/3 in the h3 crate itself without extensions and only implement necessary parts to support extensions implemented in a separate crate (maybe extended connect I think @eagr started working on this in #159 but I don't know what the status is).
And to provide a API in order to be able to implement extensions to the protocol like WebTransport ontop.
Maybe some functionality to send Settings, Streams, etc. that the h3 don’t know and a way to receive these unknown types.
For WebTransport there are 2 Protocols needed. Http-Datagrams and WebTransport itself. I think both could be in a separate crate each.
I didn’t thought about this too much, so I maybe didn’t see some obvious problems with this proposal or there might be a better solution.

Well, I think if there's another protocol upcoming, then that's the time we'd separate things and make a general extension mechanism. For now it's ok to include WebTransport but maybe behind a feature flag.

Hey @Ruben2424 @inflation !!
Thank you so much for your feedback.
I discussed with @ten3roberts and we are happy to move this to a different crate after we get it to work and just including the bare minimal in this repo.
also, thank you for mentioning #159 !

@ten3roberts got the connect to work by adding the appropriate headers to the response, now we need to listen to inbound datagrams, bidirectional and unidirectional streams.
I had to switch to the sample webtransport client because the error handling is better than in my yew-webtransport and I can actually see the errors in the browser as opposed to weird wasm traces:
https://webtransport.day/

@ten3roberts I had to hardcode a few things and break encapsulation to get the thing to work, but it is done.
Now we can polish it with a nice architecture!!
https://user-images.githubusercontent.com/1176339/229327195-d6a7f8b8-1e6a-4bf4-a375-c98959f0cd72.mov

Attempting to cut through some of the noise in this thread caused by my comments.
@seanmonstar is it ok if I add the pin-project crate as a dependency.
I need to create some stateful futures which hold their own internal state, rather than mutating state inside the "parent" like connection. This makes poll_ style functions harder to write as they do not retain intermediate state and are thus lossy for some use cases.
I also plan on reverting the pub(crate) I added to the Connection by instead adding the appropriate methods and abstractions rather than reaching into the internals to grab what we need, which is a dirty trick.

is it ok if I add the pin-project crate as a dependency?

Is it possible to use pin-project-lite? It works for most of the cases, and compiles much faster.

Should the webtransport::RecvStream and coming webtransport::SendStream implement futures_io::AsyncRead/futures_util::AsyncWrite, or should only quic::RecvStream be implemented, and reading/integration with buffered readers be left as an exercise to the user using RecvStream::poll_data?

@ten3roberts what's left?
Can you please create a list? I would like to help too :)

It course

[ ] Better api for incoming bi streams
[ ] Session termination
[ ] Server initiated uni streams
[ ] Server initiated bi streams
[ ] Request pass through (possibly as part of incoming bi streams)
[ ] Rebase onto latest changes

For maintainers
I implemented the proposed API change in #78 which allows sending raw bytes rather than just encoded frames which was required for streaming data in the streams, rather than sending complete frames. Frame encoding is still supported as WriteBuf implements Buf, so the same functionally but more composable.
I also lowered the trait generic of the stream into the poll_send method which made the whole api a lot easier to use and less cluttery with bounds and PhantomData. This was already half way done as the previous send method was also generic over the Into<WriteBuf>, but as said, is now more flexible in terms of what you can use to send your data.
See the commit message of https://github.com/hyperium/h3/commit/16eead4aa95551087cd60ac1da1e1f00fc2c99b4 for more details.
Please do let me know what you think of that decision, of it there is any other way to go around it

@ten3roberts receiving unidirectional streams works great.
I think there's an issue with bi-directional streams, seems like the server reads only the first chunk.

Alright will look into it.
We also may need to add a webtransport Client, though I am not sure if it is in the scope for this PR, most of the groundwork is there as it shares a lot with the server

The test tests::connection::control_close_send_error fails on master and persists to this day on d7a237f539b4c153318004283d776ff6724db830.
Is this something you are aware of?

Alright will look into it.
We also may need to add a webtransport Client, though I am not sure if it is in the scope for this PR, most of the groundwork is there as it shares a lot with the server

I think that by adding a test webtransport client we could add some sweet integration tests!!!

The test tests::connection::control_close_send_error fails on master and persists to this day on d7a237f.
Is this something you are aware of?

@Ruben2424 do you know the answer to this?

The test tests::connection::control_close_send_error fails on master and persists to this day on d7a237f.
Is this something you are aware of?

It's a known error that only happens on macOS #101. I don't have a clear answer about why it happens.

@ten3roberts I'll take on:
Server initiated uni streams
Server initiated bi streams
today

Fantastic.
I've already started a bit on the bi streams. The uni streams should be almost identical except the type.
Opening is a lot easier than incoming since you don't need to do partial framed decoding.

Hey @ten3roberts it's been a pretty frustrating session for me.
Here's the progress:

I stabilized the webtransport_server.rs script, I commented server initiated uni streams for now because somehow that cause the connection to close.

I added receiving server initiated uni and bidi streams on the web client: https://github.com/security-union/yew-webtransport/pull/6

If you want to use yew-webtransport make sure to checkout the readme.

I seem to be able to send the server initiated uni stream to the client here:
https://github.com/hyperium/h3/blob/1d8339df9b9abf029b9cfa21a34865f6ab4c54b5/examples/webtransport_server.rs#L273-L276

But the client never receives the uni_stream here:
https://github.com/security-union/yew-webtransport/blob/2b2182d2341cf152b34401a0a23881f3c06448c4/src/webtransport.rs#L163
I use this same pattern for datagrams, so I have no idea why this is not working for unistreams:
https://github.com/security-union/yew-webtransport/blob/2b2182d2341cf152b34401a0a23881f3c06448c4/src/webtransport.rs#L203
Let me know what you think.

I am confident that I am missing the stream type and session id:

Stealing from quiche: https://github.com/security-union/webtransport-quiche/blob/05d7d3a2b5ea8d512f00ea719259353c84bbeb4f/src/lib.rs#L249-L271

@ten3roberts you can scratch server initiated bi streams!!! those work now!

Feedback welcome in this discussion about where the code should live: https://github.com/hyperium/h3/discussions/189

@ten3roberts I reverted multi session for now, and moved web transport to its own crate, please feel free to continue to move things out of the h3 crate and into webtransport, right now it seems to me that h3 and webtransport are tightly coupled.

Zooming out a little, I'd like to suggest some targets for what h3 would expose:

As little change as possible to h3::quic traits. If the existing traits currently prevent something webtransport needs, we can discuss.
Expose as little of the h3 internals as possible. Ideally, the only public modules would be client, server, and quic. Maybe another module is needed for extensions?
The exported type from h3 that is basically a webtransport could potentially just have inherent methods, and then h3-webtransport uses them directly. Then h3 doesn't have to pick which traits to implement for its exported types, and h3-webtransport doesn't care either.

Of course, those are generalities. We can be flexible if there's need to be.
Does that help get across what I was commenting on in my previous review?

@seanmonstar @Ruben2424 i think that @ten3roberts adjusted the code a bit.
Can we have another PR review?
Please feel free to do some of the code changes so that this PR better fits your crate.
I am worried that this is getting stale and I would really like to see it in prod.
🙌🙌👍🤗🤗

Yes, I did change the code according to the comments, most notably restore the quic trait and break out the unframed sending.
As Dario said: feel free to change or suggest things for the code to better align with h3's vision.

Hi @darioalessandro ,
I hope you're doing well. I want to thank you and @ten3roberts for the effort you've put into this.
I want to assure you that I haven't forgotten about the work. Unfortunately, I didn't have time to review it in the past few weeks. However, I'm very excited about this feature, and I hope to find some time soon to take a closer look.

Firefox decided to ship WebTransport in v114 and enabled it on nightly by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1818754.
Would be nice if this is also tested against Firefox, just to get more coverage.

@Ruben2424 are there any features or traits, such as futures::AsyncRead that should be placed behind feature flags, or is it good as is?

@Ruben2424 are there any features or traits, such as futures::AsyncRead that should be placed behind feature flags, or is it good as is?

I can't thing of a reason to put traits behind a feature flag. But I do not have much experience with those traits so I might missed something. What do you think @seanmonstar

@Ruben2424 I have now fixed all of your suggestions, moved config to a separate file, and fixed the msrv.
Can we re-run the CI?
Is there anything more or could this be merged? I am going to be available going onwards and will be able to fix and submit PR if any issue arises.

Getting an error about section-3.1 not exiting in the duvet report, but the link works.
Not sure if I've missed anything, I tried adding the link to the rfc in the ci/compliance/extract.sh but it didn't help

It seems to be as the link is not an RFC editor link. I removed the only offending section link for now.
The CI should now be all green

@Ruben2424 or @seanmonstar
Could we get a final CI and review? Is there anything more to address that I have missed?

Btw, if you have a specific recommendation to keep imports as private as possible let me know.
I am also happy to keep webtransport as a module within h3 until we figure out how to split it.
@Ruben2424 @seanmonstar

Btw, if you have a specific recommendation to keep imports as private as possible let me know.

I have some early ideas about creating one or multiple Extention traits. Then for Example the h3 Connection struct could hold a struct whicht impls the trait. H3 could call methods on this struct on specific events for example when the peer opens a stream.
Then only the traits and parameter types would need to be public and all of the internal structure could be private.
But that are just some early ideas from my side that might not work well.
In my opinion this should be explored after this PR was merged.

Sgtm let's go 🙌🙌🙌

I migrated my project to this PR and it works great. I was using a quiche fork, but things started to get hairy without async support. Thank you for the hard work!
One problem I'm running into is access to the underlying QUIC library. I'd like to use SendStream.set_priority and eventually Connection.congestion_state. These are both implementation-specific, so I don't think adding them to the h3::quic traits makes sense. Any suggestions?

One problem I'm running into is access to the underlying QUIC library. I'd like to use SendStream.set_priority and eventually Connection.congestion_state. Any suggestions?

Hi @kixelated , You can try to clone() the quinn::Connection before constructing the h3::Connection and then call  Connection.congestion_state on the clone.
I have no idea for the SendStream.set_priority right now. But fell free to open a issue to further discuss this.

Hey @Ruben2424, thanks for the tip. I'll make an issue for set_priority after this gets merged.

Hey @Ruben2424 what can we do to move this PR forward, seems like @seanmonstar is MIA

@seanmonstar I have now addressed your thoughts, could we run the CI once more?
Let me know what you think


[FEATURE REQUEST] - Put all lyrics in one js file

Is your feature request related to a problem? Please describe.
No, I just thought that we could enhance the idea of #11 and set it so that all the lyrics which are currently in the songs respective folder should go in a file called lyrics.js and with that, instead of JS files in every lyric folder.

@TechStudent11 I made a attempt doing this in #33. Do you know how this can be done?

If not, I'll close this.

It's possible

Ok. Please try and let me know.
On Thu, 23 Dec 2021 at 23:28, TechStudent10 @.***>
wrote:

It's possible
—
Reply to this email directly, view it on GitHub
https://github.com/KendallDoesCoding/mogul-christmas/issues/32#issuecomment-1000452181,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUGJUTPOIHO6BYCHRBQHVWTUSNPKRANCNFSM5KU7KQUQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were assigned.Message ID:
@.***>

It's possible

Did you find anything useful for us to be able to do this? I've kept the fix#32 branch open, if you find anything useful please let me know urgently, or I'll close it.
Thanks!

@KendallDoesCoding sorry it's just that I was out all yesterday and couldn't check GitHub.

@KendallDoesCoding sorry it's just that I was out all yesterday and couldn't check GitHub.

No issues! Same here. It was christmas so that's completely fine :)

Hey, Do you mind if I have a go on it?

@aliraza944 Sure!

So you want all the songs lyrics to a single file as strings and then update the  tags on the run time?

@aliraza944 I think any implementation doesn't matter just as long as they're all in the same file.


Unable to load module with latest version of Highcharts

The following error is thrown on initialization:
Uncaught TypeError: Cannot read properties of undefined (reading 'drawRectangle')
Coming from this line in the module:
https://github.com/blacklabel/multicolor_series/blob/master/js/multicolor_series.js#L657
It seems that LegendSymbolMixin is deprecated or removed in the latest version of Highcharts?  I am using 9.2.2
Is this line still needed?

Getting

Uncaught TypeError: Cannot read properties of undefined (reading 'drawRectangle')


Layout: add support for "img" with object or ArrayBuffer Graphics object

Rendering these already worked, because we simply pass l.src() to g.drawImage(), so we just need to determine the correct size.
I guess the minified version also needs to be updated, which minifier should I use for that? (Because it would be nice if running it again on the repo code produces the same result ;-)

Thanks! Right now I just copy the unminified version across to .min.js. It seems there might be an interpreter issue that gets hit when the minified+pretokenised code for the module is executed, which I still need to look at


Fixes for selection list

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/37295
$ https://github.com/Expensify/App/issues/37511
$ https://github.com/Expensify/App/issues/37599
PROPOSAL: https://github.com/Expensify/App/issues/37295#issuecomment-1966906216
Tests

Test 1:

Go to Workspace settings
Select a workspace
Go to Members
Click on Member and Role
Verify that Member and Role should are not clickable, only the checkbox is clickable.

Test 2:

Precondition: User is admin of Collect workspace that has categories.
Go to workspace settings.
Select the Collect workspace.
Click Settings.
Click Categories.
Click outside near the right side of checkbox.
Verify that the checkbox will not be clickable outside the checkbox.

Test 3:

Click on FAB > Start Chat > Room
Create a new room
Open room details
Click on Members
Verify that all members are selected when you click on "Select all" text in the right of the checkbox

[x] Verify that no errors appear in the JS console

Offline tests

N/A
QA Steps

Same as tests above.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/77965000/c0d4574b-2f09-4ac5-b4e9-f289c4cefdf4

Android: mWeb Chrome

https://github.com/Expensify/App/assets/77965000/96f903fc-b866-48fd-8377-d7fe9b2efa8a

iOS: Native

https://github.com/Expensify/App/assets/77965000/77c37c0f-d72d-4192-9802-36a465cc7008

iOS: mWeb Safari

https://github.com/Expensify/App/assets/77965000/d215cba8-2c88-42d3-b219-adac3334172c

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/77965000/dc838f2b-6267-4c84-86a8-c1c3b5d88848

MacOS: Desktop

https://github.com/Expensify/App/assets/77965000/e552ff4f-16a6-40d3-ad2a-efdd9fd043c3

@Expensify/design which one is better when no custom header?

I'd say title and checkbox should be clickable. So option 2.
Also just confirming that we want the checkboxes to line up as well :)

I'd say title and checkbox should be clickable. So option 2.

I agree—I think that when the label is Select all it's directly related to the checkbox/select action, so it really needs to be clickable. But when it's a custom header (Members) it's not necessarily reinforcing the select all action and we probably want to reserve clicking that header for sorting and stuff.

Also just confirming that we want the checkboxes to line up as well :)

Please! 🙏

Yup, agree with all of that too.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/bondydaa in version: 1.4.56-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/yuwenmemon in version: 1.4.56-8 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Cannot Open Lottie File in skAnimatedImage

Nothing happens though I've verified that it's a valid lottie file by uploading it to apps.lottiefiles.com... here's the link.
https://app.lottiefiles.com/share/4cd64609-b1c4-4343-9b1e-ff56aca7b1d8
and I've attached the JSON...
time point bounce.zip
Any guidance you can give me would be great...!

Hi!
In Adobe After Effects, with the Bodymovin plugin, you can view lotties with two different libs, Lottie Web (Airbnb, in javascript) and Skottie (Skia, C++).
I opened this lottie and see the result:
In the Browser library (Airbnb lottie web, left) it worked but in Skottie (Skia, right) it didn't.
https://user-images.githubusercontent.com/11139086/193916805-49859672-d34f-4bae-a482-f41407229e24.mp4
As the issue is not related to our code I will close this topic, but I advise you to open the issue on the Skia bug page: https://bugs.chromium.org/p/skia/issues/list?q=skottie&can= two

Okay, thanks for the effort.  I've posted the bug report on the skia site as you suggested.


Support dependency filters when packing a buildpack offline

Describe the Enhancement
Currently when you package a buildpack offline with Jam, it will include all dependencies. With libpak you can use --dependency-filter multiple times to provide regular expressions that match dependencies to include.
Additionally you can use --strict-filters so that the regular expression needs to match the dependency ID as well as the Version. This allows users to provide a filter of (jre|^17.*) to only include that dependency for a specific version.
Possible Solution
The same functionality as libpak create-package. See above.
Motivation
Packaging offline buildpacks will often include many more dependencies than you know you will need and creates huge images that need to be pulled at build time.

Hey @braunsonm this is a good idea. We're open to contribution if you want this feature ASAP, or we'll try to get to it when we can


Rebase upstream changes

@justingrant I've noticed a couple backwards-compat issues with some of our tests:

earlier versions of Node don't have Intl.supportedValuesOf. I made some changes (see the latest commit) to the Demitasse tests to work around this - are those right?
It seems one of these test cases fails on earlier versions of Node because of the America/Port-au-Prince IANA identifier. Any ideas on what to do here? This doesn't repro on later versions of Node, so does it count as "too new" similar to the existing carve-out in the test, or should something else happen here? https://github.com/js-temporal/temporal-polyfill/actions/runs/7675453088/job/20921701127?pr=274

@12wrigja I'll take a look later this week. Thanks!

earlier versions of Node don't have Intl.supportedValuesOf. I made some changes (see the latest commit) to the Demitasse tests to work around this - are those right?

IMO these tests should be skipped instead of just returning success. For example, we can use something like itOrSkip function from this commit.
const itOrSkip = (id) => ((id === 'chinese' || id === 'dangi') && hasOutdatedChineseIcuData ? it.skip : it);

one of these test cases fails on earlier versions of Node because of the America/Port-au-Prince IANA identifier.

I think the fix would be to add this time zone as a special case in GetAvailableNamedTimeZoneIdentifier. Specifically, add this line:
    Dar_Es_Salaam: 'Dar_es_Salaam',
    Port_Of_Spain: 'Port_of_Spain',
    'Port-Au-Prince': 'Port-au-Prince',  // add this line
    Isle_Of_Man: 'Isle_of_Man',
    Comodrivadavia: 'ComodRivadavia',

This is not Node-version-dependent... it should work in all Node versions. If not, let me know!

Thanks Justin.
The addition to GetAvailableNamedTimeZoneIdentifier worked perfectly - thanks. I also added the itOrSkip-like function to disable the two new test-cases for older Node runtimes.


Gulp fetching (GET) of files is really slow compared in Git Bash

Your Windows build number:  Microsoft Windows [Version 10.0.16188.1000]

What you're doing and what's happening:

This is just happening now. Fetching files after gulp serve (files are not minified and compiled)  is really slow compared to Git Bash.
Before, fetching of files just goes zoooom. It's raining GET file/path/ *.*ms. But now fetching of files is really really slow. Literally slow.
I thought it's because I'm using ConEmu64 so I tried the Bash for Windows Terminal only but then still the same. So I tried Git Bash and it works. I also tried running Git Bash in ConEmu64 and it's also fine.
So I think it's safe to say the problem is with Bash on Windows.
Gulp Version: 3.8.10

What's wrong / what should be happening instead:

Getting of files after gulp serve should go zoooom.
Videos showing the difference
Bash on Windows https://youtu.be/I87j_kt0JfM
Git Bash https://youtu.be/6h5n5M1D0jI

Tried in a Microsoft Windows [Version 10.0.15063] works fine.
Weird.


Update dependency of Knockout to <IP_ADDRESS>

Need to update the knockoutJS version to <IP_ADDRESS>

BTW if i can contribute i would do it

@randavidovitz: I missed the big Knockout 2.0 release party, I guess!
I've just upgraded, ran the tests, and pushed.
If you have ideas for other contributions, I'd be more than happy to discuss them with you.


Final Setup Dialog not always showing

On some fresh installs the dialog with the option to copy the blockchain from another device is not shown. Check again the condition maybe change to always show.

To recheck on SSH on v1.8.1 and then ro revisit of such an option should be considered also from the WebUI Sync-Screen as an "speed up" option.

SSH dialog is now triggered whe blockchain data is below 250GB - see: https://github.com/rootzoll/raspiblitz/blob/b589b57215b57a0a1a97153d354a35716c4669fa/home.admin/setup.scripts/controlFinalDialog.sh#L41
For the WegUI options puishing this to v1.10


Avoid passing token when using http

Bearer token is required on kubelet secure port that uses HTTPS. Sending
token to insecure port can pose security risk.
/cc @kawych

/ok-to-test


Add new LookupController & Tests

This should provide lookup codes for document.

Hold off on this one, seeing some docker issues

Tested in docker - I hit the swagger page for lookups - seemed to work


Creating an API Endpoint to edit tags, coordinates, and authors for an article

Finalize the API Endpoint to allow users to contribute additional MeSH descriptor tags for a given article, table coordinates for a given experiment, and authors for any given article (optional).

Still need to create JSON endpoint to add/delete descriptors. (Descriptors should be for experiments, rather than for the whole article.)

It would be important to keep track of the original MeSH descriptors (those created by the NCBI and available through pubmed), and maybe distinguish them from the user-contributed ones.
In each article there are these two levels: the article level and the experiment level. MeSH descriptors are for the moment article-level only, and Cognitive atlas tasks, Cognitive atlas domains and Brainmap domains are experiment-level only. Ideally, the API should be able to handle both levels, and arbitrary ontologies. As a simplification, in brainspell-arche, the article-level is "experiment 0" and the experiment-level have numbers >0.


Redundant whitespace when executing "gradle --version" (windows only)

I noticed that this bug exists only if I execute gradle --version on Windows. The first line (before Gradle word) with ---- has a whitespace at begin of the line  ----.
Expected Behavior
$ gradlew --version
------------------------------------------------------------
Gradle <version>
------------------------------------------------------------

Current Behavior
 ------------------------------------------------------------
Gradle 3.3
------------------------------------------------------------

Build time:   2017-01-03 15:31:04 UTC
Revision:     075893a3d0798c0c1f322899b41ceca82e4e134b

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_73 (Oracle Corporation 25.73-b02)
OS:           Windows 7 6.1 amd64

Perhaps better with screenshot

Context
On my Linux CI server it looks good with the same version of Gradle. And first time I saw this in 3.2 release (I think).
Steps to Reproduce (for bugs)

Open cmd.exe on Windows
Execute gradlew --version

Good eyes @nerro! Would you mind looking into it to find the cause and provide a PR? As this is purely cosmetic, this issue would be extremely low on our priority list. Your help on this issue would be greatly appreciated.

Sure, it's nice-to-have :smile:
Shame on me, I looked already in CommandLineActionFactory.java#154, but found nothing. Could it be a start *bat script? Because there is no issue for Linux systems.

I suspect an issue in AnsiConsole. However, it may actually be in JAnsi which have really specific code for Windows. We are currently changing lots of code in AnsiConsole. You could build parallel-console branch from source and give it a try on Windows to see if we fixed the issue by mistake. If our recent work didn't fix the issue, you will have to dig around the logging project and jansi to find the problem. Thanks for helping out.

Thanks for tips. I will keep you informed about my progress.

Small update from my side. The issue still exists in parallel-console branch. I'm "digging" further.
$ ./gradle --version
 ------------------------------------------------------------
Gradle 3.5-20170209144620+0000
------------------------------------------------------------

Build time:   2017-02-09 14:46:20 UTC
Revision:     a8a777ceffaadac143fcacf89ed4112ea72675cf

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_73 (Oracle Corporation 25.73-b02)
OS:           Windows 7 6.1 amd64

I've done a little digging, not sure how much it will help, but here it is.
In org.gradle.launcher.cli.CommandLineActionFactory.ShowVersionAction.run() there's this line:
sb.append(":\n:------------------------------------------------------------\nGradle ");

The two colons I've added for testing and this is the result:
C:\gradle-tmp>bin\gradle.bat --version
:
  :------------------------------------------------------------
Gradle 3.5-snapshot-1
------------------------------------------------------------

Notice that now there're 2 spaces.
It does not happen though when the output is redirected to a file.
It looks like that the windows console does not handle well the first \n line break whereas has no problem with succeeding ones.
However on windows, windows style EOL should be used I guess. It looks like that using %n instead of \n in combination with String.format() the issue is gone.

Great work @fejese and well-written explanation. Also thanks @nerro for getting the ball rolling on this and opening an issue.

:+1:  for @fejese. I hope my GitLab logs will look pretty again.

@nerro, I hope so too :)
@lacasseio, thanks, I'll work on the integration test as @bmuschko requested

Based on the commit history it looks to me as if the change made into 3.5 already in February. Closing the issue.


Add a local flag that can prevent the adapter from publishing the emi…

…t to the server

Works with this pull request:
https://github.com/socketio/socket.io/pull/2628

@tal-beja hi! May I ask what your use case is please?

When several insrances of a server recieve the same even from a third party (not from a client), each server instance broadcast the event to all his clients.
If I use the redis adapter each server publish to redis about the event and thus each client recieve the same event times the number of the server instances.
With the local flag, and the change in the redis adapter, each server instance send the event only to his client, so each client recieve only one uniqe event.

@tal-beja sorry for the delay. Could you please rebase and add some tests please?
Also, is the redis version bump mandatory for this to work? Do you know what the impact is? (the changelog seems huge, especially towards the pub/sub mechanism)

bump

+1 @tal-beja

Merged as https://github.com/socketio/socket.io-redis/commit/c38e32304d0837834a10cf30e86c3557f111424f. Thanks!


Roadmap

I'm still using this provider, but given DNN has forked this provider, what is the plan here moving forward?
Are there any benefits this provider has over DNN's?

Sorry but really exist no road map at the moment. I really don't have any free time. At the moment i only can try to fix bugs.

okay, and where will these bug fix releases be available, here or codeplex?
I notice new check-ins here, but no release since 2016 at codeplex.

I moved the source repository to github. The last release was 4 month ago and will continue on CodePlex and also on GitHub. I fixed today most of the open issues. So the next bug fix release will be released in the next weeks.
Is there anything you need, or you ask in general?

Since Codeplex is shutting down, what's the release plan now?

Well nothing will change except no more releases on codeplex and all projects i need to move to GitHub. I already imported the CKEditor Dokumentation to GitHub https://github.com/w8tcha/dnnckeditor/wiki


Freeswitch 1.8

Motivation for this change
Upgrade to latest FreeSWITCH; make it easier to configure which modules are built.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build freeswitch

@pmahoney thanks; please consider adding yourself as a maintainer.


Question: Would you consider Views.Shell as a special case for MVVM?

Views.Shell, as we already know, is a special view which is hosting the HamburgerMenu and, once loaded,  it stays for the lifetime of the app. It can also conveniently host other app-wide views, for instance, as shown in Samples with Search and Login utilities thru a ModalDialog control.
The MVVM purist approach tells me that I shouldn't reference anything in a view class from a ViewModel, but I see no strong reason for doing so for the special case of Views.Shell. I find it convenient (but see no pressing downside) to refer to methods and properties in Views.Shell from other ViewModels, for instance for timed logout management (e.g., login dialog from Views.Shell  displayed on idle timeout; authenticated flag conveniently provided as a property with a login dialog, and so on). I am not suggesting a loose approach to Views.Shell but the use cases are usually limited to ViewModels for MainPage (for startup config) and SettingsPage (for user option setting).
Saying all that, I can avoid Views.Shell altogether but at a cost of code-bloat, and ask myself, why when View.Shell is in situ for the lifetime of the app?
What do you think? Should I avoid Views.Shell from ViewModels, and if so why?

At the risk of stumbling into a political/religious debate here... I believe a certain degree of pragmatism is often called for when building non-trivial apps. Is the maintainability of an app truly enhanced by creating a ShellService abstraction which brokers shell oriented functions between a ViewModel and the Views/Shell instance? Does Shell.Instance.ShowBusy() really impact your app and it's maintenance? The key here is to consider your scenario, not a purist abstraction for a theoretical app. If, in your app, you are aiming for significant test coverage, the need to inject mock Shell instances to test responses to signals, etc. then the service abstraction is essential and you get a gold star for purist architecture. If, however, YAGNI (you ain't gonna need it) then why suffer the code bloat and inherent maintenance? I often allow some view references to creep into my ViewModels unless I have a compelling reason not to. Elements such as the MapControl, are unfriendly to simple integration activities from the ViewModel so pragmatism and a desire to solve the problem at hand, rather than to perform an exercise in architecture, lead me to reference the MapControl in the ViewModel. Could I solve it through abstraction? Yes - but I have yet to find a compelling need to do so. YMMV :)

Exactly my thoughts @darenm and thank you for taking the time to share your thoughts
I am encouraged by Views.Shell being loaded throughout the app lifetime (in contrast to other pages getting loaded and unloaded, may be cached but ...) and as you indicate with your own MapControl  example, I see numerous similar features easily implemented in Views.Shell, for instance, status bar message display, login control, search, etc. It just feels less than unconvincing to abstract the interaction between Views.Shell and ViewModels for the sake of adhering to the ideal MVVM with little or no tangible gain than a more pragmatist approach.


[ISSUE #7166] Optimize the display format of admin

Fixes #7166, optimize the display format of admin.

Codecov Report

Merging #7210 (313d357) into develop (72d796f) will decrease coverage by 0.04%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             develop    #7210      +/-   ##
=============================================
- Coverage      42.46%   42.43%   -0.04%
+ Complexity      9353     9347       -6
=============================================
  Files           1149     1149
  Lines          82111    82111
  Branches       10703    10703
=============================================
- Hits           34868    34843      -25
- Misses         42882    42899      +17
- Partials        4361     4369       +8

Files Changed
Coverage Δ

.../apache/rocketmq/tools/command/MQAdminStartup.java
0.00% <0.00%> (ø)

...and/acl/ClusterAclConfigVersionListSubCommand.java
20.40% <0.00%> (ø)

...ools/command/acl/DeleteAccessConfigSubCommand.java
31.70% <0.00%> (ø)

...q/tools/command/acl/GetAccessConfigSubCommand.java
19.60% <0.00%> (ø)

...ools/command/acl/UpdateAccessConfigSubCommand.java
39.53% <0.00%> (ø)

...s/command/acl/UpdateGlobalWhiteAddrSubCommand.java
36.36% <0.00%> (ø)

...ls/command/broker/BrokerConsumeStatsSubCommad.java
40.27% <0.00%> (ø)

...q/tools/command/broker/BrokerStatusSubCommand.java
50.00% <0.00%> (ø)

...ommand/broker/CommitLogSetReadAheadSubCommand.java
0.00% <0.00%> (ø)

...mmand/broker/DeleteExpiredCommitLogSubCommand.java
65.62% <0.00%> (ø)

... and 49 more

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

LGTM


Streaming data reader

This isn't yet a complete solution to #115 and #99.
The lowest level support for reading TDS packets as stream and tokenising them lazily is implemented with all tests passing. I've also restructured AseDataReader to use an enumerator internally.
Would appreciate thoughts on how to restructure InternalConnection.InternalExecuteAsync(...) so that results can evaluated lazily.

I've backed out the AseDataReader aspects - and some of the changes to InternalConnection. @senseibaka please review.
I think it would be wise to re-run the performance benchmarks, but I'm not convinced my rig is the place to do it. The tests have been taking a long time (hours) and I'm not sure why. Could you run through the benchmark tests before this goes to master?

Having a look, tests seem to run fine on my computer (takes a couple of minutes, not hours). Only one fails: ConnectionTests.OpenConnection_ToNonExistantServer_ThrowsAseException, but only in .net core v1.1


fonts and google

Would it be a welcome change to serve the fonts locally instead of requesting them from Google?
Individuals can certainly already disable remote font loading within their own browsers, but I think it would be nice if cocreate didn't make any external requests in the course of normal operation.  I think as of right now, it looks like the only external requests are from loading the fonts from Google.
An alternative approach would be simply to change the CSS so that it uses system fonts instead of trying to load a custom font at all.  Given the small amount of text in the coauthor interface, is there really a reason to care if it's rendered in Roboto?
(sorry for the flood of posts here, just trying to get things written down while I'm thinking of them)

Generally, Google Fonts server will have much higher performance (thanks to CDN) than a Meteor server, so this is intentional. It is easy enough to include the fonts in the distribution, but I'm not sure I see the motivation... are you imagining Cocreate running in a LAN environment without Internet access? I guess I could see trying Google, and falling back on a local copy on failure...
Fixing the font helps with layout issues. And stylistically, I like being in control of the font. There isn't much text now, but there will be, especially with #7 (text tool), which is probably the most requested feature at the moment.


Line about Isaac and his run-in with pirates

and my entanglement with pirates

dude watch out for those guys...


pkg/trace/watchdog: fix CPU times retrieval

The previous code would not find the PID and would not report CPU times under many scenarios which was annoying. The new code uses the same module as our process agent which seems to be working much better.

Closing this because the new code gets the CPU for the entire machine, not just the process.


WebSocket connections maxing out at 150

I'm developing a simulator that requires connecting back to the server to launch simulation software using a Python script, which is instantiated with websocketd. The simulator works by taking inputs to a simulated device from the user via the webpage, creating a WebSocket back to the server and sending those inputs. Those inputs are received by my simulation software script, passed to the simulation software, which will give real-time outputs (so new outputs get passed back regardless of inputs from the user). Those outputs are sent by my script back to the webpage through the WebSocket.
It works beautifully - up to around 152 concurrent simulations, and then any new simulations will simply not connect. The new WebSocket connections initiated by the JavaScript remain in the CONNECTING state. The page loads, but the simulation never starts because websocketd doesn't seem to be able to accept the 153rd incoming WebSocket. I find it odd that it happens exactly at 152 connections, regardless of if I use Chrome or Firefox.
I understand from this that websocketd isn't production-ready, but it also mentions this:

However, the nature of the kind of WebSocket systems I typically deal with tend to have 1000s of concurrent long lived connections to lightweight handlers, which is an ideal fit for websocketd.

The data I transmit back and forth is around 2 KB, with an in-between added transmission delay of 40 ms, so I assume my connections are lightweight. Is there a specific option I have to enable to allow more connections? Open new ports? Spawn a new websocketd when I hit my limit? Or is there something I'm missing?

Could you explain how you test that? What OS server is running? Is there firewall?
Are clients and server talk all the time or they sit idle after connect?
I have suspicion that connections become idle once some data is exchanged and go has some limits on idle connections that I need to raise.

I tested it by writing a script that would open up hundreds of tabs on a browser (tried both Chrome and Firefox), navigating to the page and starting the simulation (therefore opening the websocket).
Apache serves the site over HTTPS. I didn't want to open a port just for WebSockets, so I installed a proxy module that allows routing WebSocket connections through port 443 on the router to an internal secret port on which websocketd runs. The connection looks something like:
wss://mysimulator.com/wss --> ws://localhost:1234
I haven't set any rules on the firewall, and there's nothing affecting these ports from what I can see.
The idle time depends on what's happening in the simulation. There could be a constant stream of outputs from the server simulation software to the client's webpage, or nothing at all. In my tests, however, I made sure to run a simulation that would constantly receive output data from the server.

I have suspicion that connections become idle once some data is exchanged and go has some limits on idle connections that I need to raise.

I don't think this is the issue for me. My testing involves constantly receiving data from the server simulation, so it definitely isn't idle. Is there some kind of limit on the number of concurrent connections it can support?

I did a test with a Node.js websocket server and I found that the limit was still 150. I realized the issue was with [Apache's own limit on concurrent connections, which is apparently 150](https://oxpedia.org/wiki/index.php?title=Tune_apache2_for_more_concurrent_connections). It looks like the issue isn't with websocketd.


Migration RN Alert Dialog to androidx

Summary:
Migrates the AlertFragment from android.app.AlertDialog to androidx.appcompat.app.AlertDialog. This backports tons of fixes that have gone into the AlertDialog component over the years, including proper line wrapping of button text, alignment of buttons, etc.
For consideration

Alert dialog themes may no longer need the android namespace, meaning themes can now be specified as alertDialogTheme rather than android:alertDialogTheme.
This change requires all implementing activities to have a theme that inherits from Theme.AppCompat. Creation of any activities which do not have a descendant of this style will result in an IllegalStateException: https://www.internalfb.com/intern/signalinfra/exception_owners/?mid=5ee93f6ecd59f3d8ad82a78c213ea016&result_id=16044073705339118.281475102518721.1715097866

Differential Revision: D57019423

Closing in favor of #44495


remove statements as requested

@azaroth42 weird, I ran this against the datacache and it compiled 100% successfully.

I did not come up with this entirely on my own (used the internet to help), but it works (mapped the datacache fine)


Improve Google Analytics conditional loading

The current logic for condtionally including the GA snippet is confusing (see #1232, #1188 and here) and bit inconsistent. In development you would see logging when the snippet wasn't included but this wouldn't happen if you were a logged in admin.
Now there's only two cases:

Production non admin user: GA snippet is loaded.
Anything else (development or admin user): log output

FYI GA goes right before the end of the head tag. Analytics.js is non-blocking.

/cc @QWp6t literally just noticed you proposed the exact same change.

👍

Yeah, I'm down with that. The only thing worth noting is what I said in #1232:

The problem with this, however, is that you're now loading that helper function in production for all admins, something that it wasn't intended to be for.

In my view, that logger is something that should only be exposed to developers. The reason I have it only showing to admins in non-production is because typically only clients and the developer would be viewing the site in non-production. Clients would be non-admins, and developers would be admins.
Like I said, I'm down with the change, though. It's just not the initial reason I added the logger.

BTW: A naked console.log like that will break all versions of Internet explorer below 10 and any old browsers that don't expose a console property on window. This will cause trouble for people trying to browser test on dev and staging and such.

@QWp6t how many non-developers will be looking at the console though? I agree with your reasoning but I think that would be so uncommon that it's fine as is.

Bit busy to sort a pull request at the moment but noticed the GA snippet that it suggests you use has changed slightly now:
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');