Persistent crosshair selection

It would be beneficial to be able to keep the same crosshair settings (maybe add a lock option or something), as when switching HUDs I think the majority of people keep the same crosshair. It also seems that each HUD uses similar crosshair options, so I think this may be possible.

Implemented in 8321e4c45c63a1f6ee21084556011bd12b4d648b and 0a5e58f3e20131be63f269767687e39b16c33438.
The feature, which will be enabled via a toggle in the options menu - will remember the crosshair toggle, size, style and primary colors between HUDs that use the same features.


Debian extras

mirror mode sync flag
publication mode

I trust it has been tested both for Deb and rest ;-)

Only affects Debian tasks, tested on ubuntu


YOUTUBE CLONE

Issue Type:

[x] Feature Request

Describe the bug
Adding a youtube clone
Possible solution
A youtube clone using HTML5, CSS3 & JS
Screenshots

If applicable, add screenshots to help explain your problem.

@arpit456jain and @VidhiBhatt01 please assign this issue to me.

@arpit456jain and @VidhiBhatt01 please assign this issue to me.

@arpit456jain and @VidhiBhatt01 please assign this issue to me asap.

This repo is not for templates/clones


Adding onGrant callback typing for RSA

Issue #, if available:
N/A
Description of changes:
Adding onGrant callback typing for RSA
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

LGTM


Two out of four new units fail to report three sensor states

Hi there,
Thanks for your great work on this.
I had four new units installed today; a AP25VGD, AP35VGD, AP50VGD and a MPEAD 71. All units are connected to the Mitsi WiFi app and working and each unit has been configured for Echonetlite. As you'll see from the picture below though, two of the units; the AP25 and the AP50 are not reporting three sensor states thus:
sensor.device_name_measured_value_of_room_temperature
sensor.device_name_measured_outdoor_air_temperature
sensor.device_name_measured_cumulative_power_consumption

Any tips on how I debug that and get the unavailable sensors working?

ECHONETLite version is 3.4.9
HA Core version is 2022.5.3
The WiFi modules in the three 'AP' units (one working, two not) are all MAC-578IF2-E

Given you have 4 entirely different units the most likely answer is that those sensors in question are simply not available for the units in question. In my own case I have no power consumption sensor of my own. Other units may or may not sense the outdoor temp. As for the room temp, I have noticed a number of units will only report the temp when the system is actually running.  If you turn on debug logging on the custom component the logs should return what attributes your air conditioners support or not. I will provide example debug logging later when I am back in front of a computer.

Thanks for the reply. Is it done like this? custom_components.echonetlite_homeassistant: debug

Sorted. Here are the logs. One of the problem units is 1.204 shown in the log.
2022-05-10 15:41:54 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['Off', 'auto', 'auto-vert', 'not-used', 'upper', 'center', 'heat', 17, 21, 18, 7600]
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['Off', 'auto', 'auto-vert', 'horiz', 'upper', 'invalid_setting', 'auto', 22, 21, 18, 0]
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] Polling ECHONET Instance host <IP_ADDRESS> timed out. Retry 1 of 3
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] Number of missed ECHONETLite msssages since reboot is 0
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['Off', 'auto', 'auto-vert', 'horiz', 'upper', 'invalid_setting', 'auto', 22, 21, 18, 0]
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] Polling ECHONET Instance host <IP_ADDRESS> timed out. Retry 2 of 3
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] Number of missed ECHONETLite msssages since reboot is 0
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['Off', 'auto', 'auto-vert', 'horiz', 'upper', 'invalid_setting', 'auto', 22, 21, 18, 0]
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] Polling ECHONET Instance host <IP_ADDRESS> timed out. Retry 3 of 3
2022-05-10 15:41:55 DEBUG (MainThread) [custom_components.echonetlite] Number of missed ECHONETLite msssages since reboot is 0

can you grab the debug logs at the very start of HA booting up, should provide more detail as to what is supported or not

Does this work? Devices are <IP_ADDRESS>, 202, 203 and 204.
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['Off', 'auto', 'auto-vert', 'not-used', 'upper', 'center', 'heat', 17, 21, 18, 7700]
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite] Plaform entry data - {'instances': [{'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe317ec7013001', 'manufacturer': 'Mitsubishi Electric'}]}
2022-05-10 15:50:04 WARNING (MainThread) [alexapy.alexalogin] No access token found; falling back to credential login instead of oauth.
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite.sensor] Configuring ECHONETLite sensor {'instance': {'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe317ec7013001', 'manufacturer': 'Mitsubishi Electric'}, 'echonetlite': <custom_components.echonetlite.ECHONETConnector object at 0x7f4526b4c3a0>}
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite.sensor] Update flags for this sensor are [128, 160, 161, 163, 164, 165, 176, 179, 187, 190, 133]
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite.sensor] This is an ECHONET climate device so not all sensors will be configured.
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite.light] Number of light devices to be added: 0
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['Off', 'auto', 'auto-vert', 'horiz', 'upper', 'invalid_setting', 'auto', 22, 21, 18, 0]
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite] Polling ECHONET Instance host <IP_ADDRESS> timed out. Retry 1 of 3
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite] Number of missed ECHONETLite msssages since reboot is 1
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['On', 'auto', 'auto-vert', 'not-used', 'upper', 'center', 'auto', 24, 19, 18, 0]
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite] Polling ECHONET Instance host <IP_ADDRESS> timed out. Retry 2 of 3
2022-05-10 15:50:04 DEBUG (MainThread) [custom_components.echonetlite] Number of missed ECHONETLite msssages since reboot is 1
2022-05-10 15:50:04 INFO (MainThread) [pydeconz.websocket] Connected to deCONZ (core-deconz)
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['On', 'auto', 'auto-vert', 'not-used', 'upper', 'center', 'auto', 24, 19, 18, 0]
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite] Polling ECHONET Instance host <IP_ADDRESS> timed out. Retry 3 of 3
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite] Number of missed ECHONETLite msssages since reboot is 0
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite] Plaform entry data - {'instances': [{'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe2ebb3d013001', 'manufacturer': 'Mitsubishi Electric'}]}
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['Off', 'auto', 'auto-vert', 'horiz', 'upper', 'invalid_setting', 'auto', 22, 21, 18, 0]
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite] Polling ECHONET Instance host <IP_ADDRESS> timed out. Retry 2 of 3
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite] Number of missed ECHONETLite msssages since reboot is 0
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite.sensor] Configuring ECHONETLite sensor {'instance': {'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe2ebb3d013001', 'manufacturer': 'Mitsubishi Electric'}, 'echonetlite': <custom_components.echonetlite.ECHONETConnector object at 0x7f4526b4c070>}
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite.sensor] Update flags for this sensor are [128, 160, 161, 163, 164, 165, 176, 179, 187, 190, 133]
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite.sensor] This is an ECHONET climate device so not all sensors will be configured.
2022-05-10 15:50:05 DEBUG (MainThread) [custom_components.echonetlite.light] Number of light devices to be added: 0
2022-05-10 15:50:06 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['Off', 'auto', 'auto-vert', 'horiz', 'upper', 'invalid_setting', 'auto', 22, 21, 18, 0]
2022-05-10 15:50:06 DEBUG (MainThread) [custom_components.echonetlite] Polling ECHONET Instance host <IP_ADDRESS> timed out. Retry 3 of 3
2022-05-10 15:50:06 DEBUG (MainThread) [custom_components.echonetlite] Number of missed ECHONETLite msssages since reboot is 0
2022-05-10 15:50:06 DEBUG (MainThread) [custom_components.echonetlite] Plaform entry data - {'instances': [{'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe319353013001', 'manufacturer': 'Mitsubishi Electric'}]}
2022-05-10 15:50:06 DEBUG (MainThread) [custom_components.echonetlite.sensor] Configuring ECHONETLite sensor {'instance': {'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe319353013001', 'manufacturer': 'Mitsubishi Electric'}, 'echonetlite': <custom_components.echonetlite.ECHONETConnector object at 0x7f4526b4c6d0>}
2022-05-10 15:50:06 DEBUG (MainThread) [custom_components.echonetlite.sensor] Update flags for this sensor are [128, 160, 161, 163, 164, 165, 176, 179, 187, 190, 133]
2022-05-10 15:50:06 DEBUG (MainThread) [custom_components.echonetlite.sensor] This is an ECHONET climate device so not all sensors will be configured.
2022-05-10 15:50:06 DEBUG (MainThread) [custom_components.echonetlite.light] Number of light devices to be added: 0

is the climate entity working? only issue is with the sensors?

The climate entity does not work as the room temperature is missing. No feedback loop.

Apologies, I can actually call Climate: Turn on and Climate: Turn off for the units the don't report room temp.

Can you please power on all units and let me know if any changes to debug logs

Deleted the log, turned on all units and restarted Home Assistant .
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] pychonet version 2.2.1
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite HomeAirConditioner instance at <IP_ADDRESS>
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] ECHONET instance UID is<PHONE_NUMBER>d01769fffec59b1c013001
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] pychonet version 2.2.1
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] {'6459053f6fa1019c8c03dd9a8d2013ad': [], 'api': <pychonet.echonetapiclient.ECHONETAPIClient object at 0x7fd378a17b80>} is already running.
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite HomeAirConditioner instance at <IP_ADDRESS>
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] ECHONET instance UID is<PHONE_NUMBER>7061befffe2ebb3d013001
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] pychonet version 2.2.1
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] {'6459053f6fa1019c8c03dd9a8d2013ad': [], 'api': <pychonet.echonetapiclient.ECHONETAPIClient object at 0x7fd378a17b80>, 'c389411d2e729a2e4eb10ffa74aeb144': []} is already running.
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite HomeAirConditioner instance at <IP_ADDRESS>
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] ECHONET instance UID is<PHONE_NUMBER>7061befffe317ec7013001
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] pychonet version 2.2.1
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] {'6459053f6fa1019c8c03dd9a8d2013ad': [], 'api': <pychonet.echonetapiclient.ECHONETAPIClient object at 0x7fd378a17b80>, 'c389411d2e729a2e4eb10ffa74aeb144': [], '94b99303925f1f6853791d4aafaa78fa': []} is already running.
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite HomeAirConditioner instance at <IP_ADDRESS>
2022-05-10 17:01:36 DEBUG (MainThread) [custom_components.echonetlite] ECHONET instance UID is<PHONE_NUMBER>7061befffe319353013001

2022-05-10 17:01:37 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite polling update data - ['On', 'low', 'auto', 20, 20]
2022-05-10 17:01:37 DEBUG (MainThread) [custom_components.echonetlite] Plaform entry data - {'instances': [{'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 130, 131, 179, 134, 136, 137, 138, 187, 157, 158, 143, 159], 'setmap': [128, 129, 143, 160, 176, 179], 'uid': '0000060104d01769fffec59b1c013001', 'manufacturer': 'Mitsubishi Electric'}]}

2022-05-10 17:01:38 DEBUG (MainThread) [custom_components.echonetlite.sensor] Configuring ECHONETLite sensor {'instance': {'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 130, 131, 179, 134, 136, 137, 138, 187, 157, 158, 143, 159], 'setmap': [128, 129, 143, 160, 176, 179], 'uid': '0000060104d01769fffec59b1c013001', 'manufacturer': 'Mitsubishi Electric'}, 'echonetlite': <custom_components.echonetlite.ECHONETConnector object at 0x7fd37448eb80>}
2022-05-10 17:01:38 DEBUG (MainThread) [custom_components.echonetlite.sensor] Update flags for this sensor are [128, 160, 176, 179, 187]
2022-05-10 17:01:38 DEBUG (MainThread) [custom_components.echonetlite.sensor] This is an ECHONET climate device so not all sensors will be configured.
2022-05-10 17:01:38 DEBUG (MainThread) [custom_components.echonetlite.light] Number of light devices to be added: 0

Oddly, both problem units report the indoor and outdoor temp in the app.

yeah its very odd. there may be some strangeness to do with one particular value being returned as 0. I need to get in front of my lab at home to figure out what to do next.

I could actually see in the logs the correct values for outdoor temp but for reasons not yet know that is not correctly updating in Home Assistant

Appreciate your help. Let me know if I can assist further. P.S I did remove all devices, restart HA and re-add them as a test but same deal.

I have some of these devices, and the outside temp is only available when the pump is running / a short time afterwards. Could that be the case here?

@khcnz I've left all devices on for sometime and restarted HA on many occasions but the AP25 will not report the room temp so the climate entity does not work. Oddly, the AP50 that was in the same state just came right on its own so now I only have one device not reporting.

There is an issue with the way I handle non-responses. I am currently expecting “False” for when a packet is missed, which is causing issues when any EPC is returning 0. I need to fix the behaviour, so it returns ‘None’ rather then false. I am just struggling for time at the moment
Get Outlook for iOShttps://aka.ms/o0ukef

From: xbmcnut @.>
Sent: Thursday, May 12, 2022 4:37:19 PM
To: scottyphillips/echonetlite_homeassistant @.>
Cc: Scott Phillips @.>; Comment @.>
Subject: Re: [scottyphillips/echonetlite_homeassistant] Two out of four new units fail to report three sensor states (Issue #72)
@khcnzhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkhcnz&data=05|01||0aa66ed227aa4868fec508da33e1dd53|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637879342438421270|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=tDzARnxc7aJa90sbov%2BEHUKJDo2cP5cnwjiJGGlxCvI%3D&reserved=0 I've left all devices on for sometime and restarted HA on many occasions but the AP25 will not report the room temp so the climate entity does not work. Oddly, the AP50 that was in the same state just came right on its own so now I only have one device not reporting.
—
Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fscottyphillips%2Fechonetlite_homeassistant%2Fissues%2F72%23issuecomment-1124585023&data=05|01||0aa66ed227aa4868fec508da33e1dd53|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637879342438421270|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=HIuszrRjGNHilIVDOI3YycAdPQBlFXAoazATsaLCHiI%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGHQNDHLIMU6OSOGLJSRLRTVJSRJ7ANCNFSM5VP633VA&data=05|01||0aa66ed227aa4868fec508da33e1dd53|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637879342438421270|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=K6IdoVQQE%2BOQtLrrTehGUR1fRNVC5x11jbbrP2uiRm4%3D&reserved=0.
You are receiving this because you commented.Message ID: @.***>

Awesome that you've found the problem Scotty. Well done. No hurry at my end just nice to know I'm not going mad! :)

FYI, all four units are now reporting. Don't know why but very happy.

I think it’s probably a case that the data returned does not contain any zeros and that was enough to start the sensors and the climate entities. I am sorry that it isn’t working as expected; I have a plan to fix it hopefully this weekend.
Get Outlook for iOShttps://aka.ms/o0ukef

From: xbmcnut @.>
Sent: Friday, May 13, 2022 3:24:08 PM
To: scottyphillips/echonetlite_homeassistant @.>
Cc: Scott Phillips @.>; Comment @.>
Subject: Re: [scottyphillips/echonetlite_homeassistant] Two out of four new units fail to report three sensor states (Issue #72)
FYI, all four units are now reporting. Don't know why but very happy.
[image]https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F1492137%2F168216564-af75d0ce-4298-424c-a5ea-3798d4d3f5bb.png&data=05|01||52f3ea87300645915e6e08da34a0ce8f|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637880162531438717|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=KueLyWEUI7JWocM%2BlT3Q4ZNHTDhQ0ERvJaUWuCBPlos%3D&reserved=0
—
Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fscottyphillips%2Fechonetlite_homeassistant%2Fissues%2F72%23issuecomment-1125668372&data=05|01||52f3ea87300645915e6e08da34a0ce8f|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637880162531438717|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=LiexDTQlKR078CAjo7P36mfoKMFZi627A0LpTCGtacE%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGHQNDHYGNZ27FXOC7R7MYLVJXRPRANCNFSM5VP633VA&data=05|01||52f3ea87300645915e6e08da34a0ce8f|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637880162531438717|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=OqdjAfZQ9VXBRD35kRAUHwSUP2TcfcQq%2F%2F6k3acxA8c%3D&reserved=0.
You are receiving this because you commented.Message ID: @.***>

Whoops, spoke too soon. Although the Office unit (far left) it reporting temp now, I just turned it on and the state does not update.

Hi, can you download 3.5.0 and let me know if it fixes the issues? I have sorted out the False vs None nonsense.

Already done. Testing now. Will report back a little later. Thank you so much. Can you advise how I edit your page to add the models I have or would you like to do it?

If you are git savvy, you can always put in a PR, but I am happy to update it myself.
AP25VGD, AP35VGD, AP50VGD and a MPEAD 71?
MAC-578IF2-E?
Thanks you for using my integration!

You might find its still broken I discovered a bug in a separate issue, can you update 3.5.1 if you switch on logging.

Hi Scotty. I'm pleased to report that everything seems to be discovered first time now under 3.5.1. I removed all devices, restarted HA then added them back in, restarted HA again and captured the log on boot below. Great work so thank you so much for this. Awesome integration with weeks of yaml coding ahead of me now!!
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] Starting up ECHONETlite platform..
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] pychonet version is 2.2.2
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite HomeAirConditioner instance at <IP_ADDRESS>
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] UID for ECHONETLite instance at <IP_ADDRESS>  is<PHONE_NUMBER>d01769fffec59b1c013001.
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite platform is already started.
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite HomeAirConditioner instance at <IP_ADDRESS>
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] UID for ECHONETLite instance at <IP_ADDRESS>  is<PHONE_NUMBER>7061befffe2ebb3d013001.
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite platform is already started.
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite HomeAirConditioner instance at <IP_ADDRESS>
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] UID for ECHONETLite instance at <IP_ADDRESS>  is<PHONE_NUMBER>7061befffe317ec7013001.
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] ECHONETlite platform is already started.
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] Starting ECHONETLite HomeAirConditioner instance at <IP_ADDRESS>
2022-05-15 14:32:08 DEBUG (MainThread) [custom_components.echonetlite] UID for ECHONETLite instance at <IP_ADDRESS>  is<PHONE_NUMBER>7061befffe319353013001.
2022-05-15 14:32:10 DEBUG (MainThread) [custom_components.echonetlite]
ECHONETlite polling update data:
 - Operation status (0x80): Off
 - Operation status (0x80): Off
 - Air flow rate setting (0xa0): low
 - Operation mode setting (0xb0): heat
 - Set temperature value (0xb3): 22
 - Measured value of room temperature (0xbb): 19

2022-05-15 14:32:10 DEBUG (MainThread) [custom_components.echonetlite] Plaform entry data - {'instances': [{'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 130, 131, 179, 134, 136, 137, 138, 187, 157, 158, 143, 159], 'setmap': [128, 129, 143, 160, 176, 179], 'uid': '0000060104d01769fffec59b1c013001', 'manufacturer': 'Mitsubishi Electric'}]}
2022-05-15 14:32:10 DEBUG (MainThread) [custom_components.echonetlite.sensor] Configuring ECHONETLite sensor {'instance': {'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 130, 131, 179, 134, 136, 137, 138, 187, 157, 158, 143, 159], 'setmap': [128, 129, 143, 160, 176, 179], 'uid': '0000060104d01769fffec59b1c013001', 'manufacturer': 'Mitsubishi Electric'}, 'echonetlite': <custom_components.echonetlite.ECHONETConnector object at 0x7f8b0c5f3130>}
2022-05-15 14:32:10 DEBUG (MainThread) [custom_components.echonetlite.sensor] Update flags for this sensor are [128, 160, 176, 179, 187]
2022-05-15 14:32:10 DEBUG (MainThread) [custom_components.echonetlite.sensor] This is an ECHONET climate device so not all sensors will be configured.
2022-05-15 14:32:10 DEBUG (MainThread) [custom_components.echonetlite.light] Number of light devices to be added: 0
2022-05-15 14:32:10 DEBUG (MainThread) [custom_components.echonetlite]
ECHONETlite polling update data:
 - Operation status (0x80): Off
 - Operation status (0x80): Off
 - Air flow rate setting (0xa0): auto
 - Automatic control of air flow direction setting (0xa1): auto-vert
 - Automatic swing of air flow setting (0xa3): not-used
 - Air flow direction (vertical) setting (0xa4): upper
 - Air flow direction (horizontal) setting (0xa5): center
 - Operation mode setting (0xb0): heat
 - Set temperature value (0xb3): 23
 - Measured value of room temperature (0xbb): 19
 - Measured outdoor air temperature (0xbe): 20
 - Measured cumulative power consumption (0x85): 100

2022-05-15 14:32:10 DEBUG (MainThread) [custom_components.echonetlite] Plaform entry data - {'instances': [{'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe2ebb3d013001', 'manufacturer': 'Mitsubishi Electric'}]}
2022-05-15 14:32:11 WARNING (MainThread) [alexapy.alexalogin] No access token found; falling back to credential login instead of oauth.
2022-05-15 14:32:11 WARNING (MainThread) [homeassistant.components.generic.camera] Loading generic IP camera via configuration.yaml is deprecated, it will be automatically imported.  Once you have confirmed correct operation, please remove 'generic' (IP camera) section(s) from configuration.yaml
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] Configuring ECHONETLite sensor {'instance': {'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe2ebb3d013001', 'manufacturer': 'Mitsubishi Electric'}, 'echonetlite': <custom_components.echonetlite.ECHONETConnector object at 0x7f8b0c5f33d0>}
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] Update flags for this sensor are [128, 160, 161, 163, 164, 165, 176, 179, 187, 190, 133]
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] This is an ECHONET climate device so not all sensors will be configured.
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.light] Number of light devices to be added: 0
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite]
ECHONETlite polling update data:
 - Operation status (0x80): Off
 - Operation status (0x80): Off
 - Air flow rate setting (0xa0): auto
 - Automatic control of air flow direction setting (0xa1): auto-vert
 - Automatic swing of air flow setting (0xa3): not-used
 - Air flow direction (vertical) setting (0xa4): upper
 - Air flow direction (horizontal) setting (0xa5): center
 - Operation mode setting (0xb0): heat
 - Set temperature value (0xb3): 23
 - Measured value of room temperature (0xbb): 21
 - Measured outdoor air temperature (0xbe): 20
 - Measured cumulative power consumption (0x85): 69400

2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite] Plaform entry data - {'instances': [{'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe317ec7013001', 'manufacturer': 'Mitsubishi Electric'}]}
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite]
ECHONETlite polling update data:
 - Operation status (0x80): Off
 - Operation status (0x80): Off
 - Air flow rate setting (0xa0): auto
 - Automatic control of air flow direction setting (0xa1): auto-vert
 - Automatic swing of air flow setting (0xa3): horiz
 - Air flow direction (vertical) setting (0xa4): upper
 - Air flow direction (horizontal) setting (0xa5): invalid_setting
 - Operation mode setting (0xb0): heat
 - Set temperature value (0xb3): 24
 - Measured value of room temperature (0xbb): 20
 - Measured outdoor air temperature (0xbe): 20
 - Measured cumulative power consumption (0x85): 300

2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite] Plaform entry data - {'instances': [{'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe319353013001', 'manufacturer': 'Mitsubishi Electric'}]}
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] Configuring ECHONETLite sensor {'instance': {'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe317ec7013001', 'manufacturer': 'Mitsubishi Electric'}, 'echonetlite': <custom_components.echonetlite.ECHONETConnector object at 0x7f8b0c5f36a0>}
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] Update flags for this sensor are [128, 160, 161, 163, 164, 165, 176, 179, 187, 190, 133]
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] This is an ECHONET climate device so not all sensors will be configured.
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.light] Number of light devices to be added: 0
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] Configuring ECHONETLite sensor {'instance': {'host': '<IP_ADDRESS>', 'eojgc': 1, 'eojcc': 48, 'eojci': 1, 'getmap': [128, 160, 176, 129, 161, 130, 131, 163, 179, 164, 133, 165, 134, 136, 137, 138, 154, 139, 171, 187, 157, 158, 190, 143, 159], 'setmap': [128, 129, 143, 147, 160, 161, 163, 164, 165, 176, 179, 208], 'uid': '00000601057061befffe319353013001', 'manufacturer': 'Mitsubishi Electric'}, 'echonetlite': <custom_components.echonetlite.ECHONETConnector object at 0x7f8b0c5f39a0>}
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] Update flags for this sensor are [128, 160, 161, 163, 164, 165, 176, 179, 187, 190, 133]
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.sensor] This is an ECHONET climate device so not all sensors will be configured.
2022-05-15 14:32:11 DEBUG (MainThread) [custom_components.echonetlite.light] Number of light devices to be added: 0


Is't possible to use Clarity without Angular? if yes, how?

Is't possible to use Clarity without Angular? if yes, how?

It is, and there is a stack overflow topic on it that may help!
https://stackoverflow.com/questions/47165860/can-one-use-clarity-without-angular

Only Angular2+?

@biapar
You can use Clarity's HTML and CSS in any application. You can also use Clarity's Icon library in any application (even a static website).
The only thing you would not be able to use are the heavily interactive and stateful components like datagrid. Most of our components can be added to an application by bringing in the CSS file and putting the expected HTML in your website or application.


LD A (HL-) implementation and test

Coverage increased (+0.01%) to 99.234% when pulling 1e83d89b43505d7995d076c4d4660f185a8ac87b on ldahlpdechl-implementation into 46e839c1cf13a6df645f7304f09fdf9e43bdd87b on master.


paramErrorMessage will be deleted permanently from schema after first validation if schema is not recreated on every new request

In scenario where schema is not recreated on every request paramErrorMessage will be permanently deleted from schema. To me it seems perfectly valid scenario to use predefined schemas instead of recreating schemas over and over again on each request. In following example only first ever request will have expected param error message "msg": "a must be integer greater or equal to 1", all following requests will return "msg": "Invalid param". This is caused by line number: 343 in https://github.com/ctavan/express-validator/blob/master/lib/express_validator.js. Please check end of answer for proposal how this can easily be solved. Example:
// schemas/index.js
'use strict'

exports.somethingSchema = {
  a: {
    isInt: {
      options: [{ min: 1}]
    },
    errorMessage: 'a must be integer greater or equal to 1'
  }
}

// test.js
const test = (req, res, next) => {
  req.checkBody(schemas.somethingSchema)
  const errors = req.validationErrors()

  if (errors) {
    return res.status(422).json({
      type: 'validation-error',
      message: 'Constraint violation',
      errors
    })
  }
  return next()
}

app.post('/something', test, (req, res, next) => {
  res.send('ok')
})

How it can be solved: Clearly intention with using delete is that errorMessage not ends like methodName in for (var methodName in schema[param]) {...}. Instead delete this can be solved in more safer way with if (methodName === 'in' || methodName === 'errorMessage') { ... continue; }
One more reason why i would vote against delete is that you never know how schema will be used after validation, what if application that is using your library later in request is using paramErrorMessage...

Should be fixed in 2.20.8


Fix SetMuteGenshin(BOOL) Resources Leak

Interesting program (tho' Paimon is pretty cute). Add a patch to release mmdeviceapi interfaces after we finish using them in each loop.

Thanks!


Question: Haskell integration questions and freeform discussion

Hi! I'm very interested in dream2nix as a current Haskell.nix user.
I have some issues with Haskell.nix currently, and was about to start trying to contribute fixes for it.
I learned about dream2nix and see that perhaps the best way forward for me could be adding cabal.project.freeze support to dream2nix.
Here are some rambling thoughts about why and questions you migth be able to help with. Ideally some of these things can serve as useful discussion points for future dream2nix Haskell integration as well.
So recently I had to workaround haskell.nix not supporting tarballs in https://github.com/mlabs-haskell/haskell-nix-extra-hackage/pull/6 and this made me wonder how dream2nix currently supports local tarballs or would plan to support it without IFDs.
Reading the docs on the Haskell subsystem I see that cabal.project.freeze support is awaiting implementation.
Does this mean that implementing that allows us to use the cabal.project as a source of truth? It was my understanding (hopefully misunderstanding) that doing such a thing required IFD's the way that haskell.nix uses them.
If implementing support for cabal.project.freeze gets me cabal.project as a source of truth better than Haskell.nix currently provides that I'm very interested in helping out in the development of that. Especially if I get to avoid IFDs, hit more caches, and avoid building GHC's :laughing:
It seems kind of like cabal.project as source of truth and integrate better with the nixos.org infrastructure are fundamentally at odds.
cabal.project as source of truth makes Nix adoption for Haskell easiest.
Better integration with nix makes the exxperience of using Haskell easier.

Also all nix integration currently has the downside of build-tools not working if you use cabal-v2 and it's the default. Here's a discussion you might want to weigh in on about it:
https://github.com/haskell/cabal/issues/8434

I learned about dream2nix and see that perhaps the best way forward for me could be adding cabal.project.freeze support to dream2nix.

I have a branch for cabal freeze at https://github.com/leungbk/dream2nix/tree/cabal-freeze. I haven't touched it in a while since I'm waiting for something like https://github.com/nix-community/dream2nix/pull/257 to be merged.

this made me wonder how dream2nix currently supports local tarballs or would plan to support it without IFDs.

We already do IFD to parse the .cabal file. We use cabal2json inside an IFD, then parse the JSON with nix. This does not necessarily mean that performance is going to be horrible. We try to minimize the number of IFD operations and their complexity.
Currently there is no support for tarballs as sources. Concerning IFD usage, if the tarball is part of one of your flake inputs, or contained in your specified source, using it as a package's source would not trigger an extra IFD. We can also fetch remote tarballs via FOD without triggering IFD.
The question is just, can we generate the derivation without looking inside the tarball, or does the tarball contain information that we need to inspect before starting the build. If the latter is the case, we would have to extract and parse files from the tarball, which would trigger another IFD.

I'm very interested in helping out in the development of that. Especially if I get to avoid IFDs, hit more caches, and avoid building GHC's laughing

As long as parsing .cabal files in pure nix is not possible, we have to use at least some IFD.
If you want to help the development, your efforts would be much appreciated.
Hitting the caches issue is unrelated to the IFD problem. If we manage to implement a mechanism that allows re-using the GHC's from nixpkgs instead of building our own ones, the caching issues should be improved a lot.

It seems kind of like cabal.project as source of truth and integrate better with the nixos.org infrastructure are fundamentally at odds.

I don't see why this would be the case. We don't have to integrate our whole mechanism with nixos.org. We just need to make sure that all the expensive to build components like compilers are maintained in nixpkgs for example.

As long as parsing .cabal files in pure nix is not possible, we have to use at least some IFD.
If you want to help the development, your efforts would be much appreciated.

Am I correct in thinking this is due to nix having no support built in for yaml parsing?

Am I correct in thinking this is due to nix having no support built in for yaml parsing?
.cabal uses its own language. Yaml support would not help for that. But it would simplify parsing stack.yaml and stack.yaml.lock files.

As long as parsing .cabal files in pure nix is not possible, we have to use at least some IFD.

Yesterday I remembered you saying this when I ran into https://github.com/input-output-hk/haskell.nix/issues/1097#issuecomment-825655919 trying to write a github action for a Haskell flake that uses nixbuild.net.
I'm assuming that dream2nix probably builds for multiple platforms by default, but if that's not true maybe it's not affected here.
Not sure if you are familiar with this issue, but it seems like something you or I could definitely run into more.
Here are two solutions I found if that is the case:

self-described hacky solution
https://github.com/Plutonomicon/plutarch-plutus/blob/f8b7eb06184112ae2bebdec5a8156010141a05d5/flake.nix#L600

Also, I'm not sure if you find this discussion/issue useful or not. I'm fine with just closing if not.
I find it useful primarily to help me understand the future of Haskell/Nix in general and also to evaluate how much time I can justify potentially switching to dream2nix or contributing.

Thanks for pointing this out. It seems like the nix flake check issue is nothing we can fix in dream2nix. We'll have to wait for the upstream fix. Anyways, we currently do not export checks via our builders and therefore won't run into these issues via our standard flake.
Though nix flake show can be fixed, as it only evaluates name and type attributes of the derivation and will be fine as long as those attributes are not computed via IFD.
The goal for dream2nix is to never run into issue with nix flake show. We can achieve this via some slight changes to the current haskell translators.

Can this issue be closed?


Custom acme ca not working

We are using a custom acme server with preconfigured eab_kid and eab_hmac_key files in the compose file. It seems that the /app/letsencrypt_service can only create a config_file with pre determent key files when the acme_ca_uri = https://acme.zerossl.com/v2/DV90 (on line 240).  All the other methods are trying to fetch key files on the acme server. But that is not allowed on our custom server.
When I swap the hard-coded acme URL on line 240 with our custom acme server, all is good.
So I guess I need some sort of detection, or a new ENV setting / boolean like "Do not fetch key files". Or do not try to fetch the files when the keys are configured. idk
Bottom line: our custom server behaves like the zerossl server and (I think) there is no way to configure it like this except the URL swap in the code.
I created a Docker file with the following:
FROM  nginxproxy/acme-companion
USER root
RUN sed -i 's+https://acme.zerossl.com/v2/DV90+https://acme.****.com/v2/OV+g' /app/letsencrypt_service

Far from ideal.
Edit:
So further reading the code, when the URL is not zerossl the account file is created on line 290 without a check for an existing EAB like in the zerossl code:
Zerossl:
if [[ -n "${eab_kid}" && -n "${eab_hmac_key}" ]]; then
                # Register the ACME account with the per container EAB credentials.
                params_register_arr+=(--eab-kid "$eab_kid" --eab-hmac-key "$eab_hmac_key")

Non zero ssl account creation:
 if [[ ! -f "$account_file" ]]; then
        params_register_arr=("${params_base_arr[@]}" "${params_register_arr[@]}")
        [[ "$DEBUG" == 1 ]] && echo "Calling acme.sh --register-account with the following parameters : ${params_register_arr[*]}"
        acme.sh --register-account "${params_register_arr[@]}"

Edit 2:
So a possible fix would be something like (line 290)
 # Account registration and update if required
    if [[ ! -f "$account_file" ]]; then
        local -n eab_kid="ACME_${cid}_EAB_KID"
        local -n eab_hmac_key="ACME_${cid}_EAB_HMAC_KEY"
        if [[ -n "${eab_kid}" && -n "${eab_hmac_key}" ]]; then
                # Register the ACME account with the per container EAB credentials.
                params_register_arr+=(--eab-kid "$eab_kid" --eab-hmac-key "$eab_hmac_key")
        elif
        params_register_arr=("${params_base_arr[@]}" "${params_register_arr[@]}")
        [[ "$DEBUG" == 1 ]] && echo "Calling acme.sh --register-account with the following parameters : ${params_register_arr[*]}"
        acme.sh --register-account "${params_register_arr[@]}"
        fi
    fi

Edit 3: did some more reading and created a PR.

@a1ad I actually completely forgot that I already did some work on that, here is a PR, could you test it ? https://github.com/nginx-proxy/acme-companion/pull/981

Yeah sure, I ll try to test it somewhere next week.

Ok, great. I'll test it tomorrow.

@buchdag, just tested the eab image successfully.


⚠ Mobitopup has degraded performance

In 466d6f1, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4352 ms

Resolved: Mobitopup performance has improved in 39974be.


Tooltips for line, scatter, bar and pie charts

This new feature use the TooltipMixin to show a tooltip  when onMouseOver event is triggered. The charts that use this mixin (LineChart, ScatterChart, BarChart and PieChart) now support two new props: showTooltip (determines whether to use the tooltip) and tooltipFormat (a function that determines the tooltip text).

:+1:

@jfcaiceo / @MatthewHerbst  couple of inputs -

As the onMouseOver event is added on path as well (https://github.com/esbullington/react-d3/blob/master/src/linechart/VoronoiCircle.jsx#L21-L22) - the co-ordinates being shown for tooltip are not exactly what we might want

It would be better if we support having xLabel and yLabel in front of tool tips - it would be needed in case of multiple elements in series (Multiple y lines etc.)

@akshaymohite:

That's not a problem because I always get the coordinates of the circle inside the path: https://github.com/jfcaiceo/react-d3/blob/master/src/linechart/VoronoiCircleContainer.jsx#L56
I don't understand your point. You are talking about having the series name in the tooltip?

@jfcaiceo:

That's not a problem because I always get the coordinates of the circle inside the path: https://github.com/jfcaiceo/react-d3/blob/master/src/linechart/VoronoiCircleContainer.jsx#L56

:+1:

I don't understand your point. You are talking about having the series name in the tooltip?

Yes, series name and xLabel as well if possible.

LGTM ! Code looks good to me. Just one thing, theres is a todo. Are you going to solve it before I merge?

When the tooltip is near the right edge of the chart, it would be good to change the orientation of the tooltip to the left and always were inside the chart. That's the todo. I don't think that's a required feature to this pull request. But... what do you think @yang-wei?

Thanks, this is very useful. However, for the tooltip divs, might be better to only define minimal styles inline and instead add classes for easy customization?
Also, +1 for passing the series name into the tooltip.
Finally, maybe consider officially supporting custom tooltip components, this sort of works already with a tooltipFormat function that returns a component, e.g:
tooltipFormat={v => (<div>{"Hello " + v.xValue + ", " + v.yValue}</div>)}

@BigDataSamuli:

However, for the tooltip divs, might be better to only define minimal styles inline and instead add classes for easy customization?

That's the best option I think, but now the library is clean of stylesheets... that's good too. I tried to keep it clean of other assets with this change.

Also, +1 for passing the series name into the tooltip.

:+1: changed

Finally, maybe consider officially supporting custom tooltip components, this sort of works already with a tooltipFormat function that returns a component

That's true. I changed the text prop, for a child prop ( that can be a string, number or react element) to support custom tooltips. https://github.com/jfcaiceo/react-d3/blob/master/src/common/Tooltip.jsx#L10

@jfcaiceo:

That's the best option I think, but now the library is clean of stylesheets... that's good too. I tried to keep it clean of other assets with this change.

Yeah, I was thinking you could take most of the inline styles out and the tooltip would still be somewhat usable even without any external stylesheets. In any case, you could add the classes so that one can at least easily override the styles with !important.
Also, new browsers support a CSS property "pointer-events: none", which would be useful here to keep the tooptip itself from interfering with the mouseover events.

I don't think that's a required feature to this pull request. But... what do you think

Yeah no problem for me.

How to use toolTip?There are some problems when I add showTooltip and tooltipFormat.It seems doesnt work.my code
<LineChart 		  legend={true} 		  data={lineData} 		  width={'100%'} 		  height={400} 		  viewBoxObject={{ 		    x: 0, 		    y: 0, 		    width: 1000, 		    height: 400 		  }} 		  xAxisTickInterval={{unit: 'day', interval: xInteral}} 		  xAxisFormatter={(val)=>Common.getTime_ymd_hms("date",val)} 		  showTooltip={true} 		  tooltipFormat={()=>"like"} 		  gridHorizontal={true} 		/>


Adding an abbreviation to title

@KrishMunot
sorry but this doesn't look so well. I prefer the title without the abbreviation :sweat_smile:


Support Mutation Testing use case

We want to support node-tap for mutation testing with StrykerJS, see the issue on our side: https://github.com/stryker-mutator/stryker-js/issues/325.
During mutation testing, the test suite is executed 1000s of times. I know we can simply import any test file and let the tests be executed, but that is bad for performance. In fact, this would already be supported with the command test runner.
In order to improve performance, we need a programmable API that looks something like this:
// Code below is pseudo-code to illustrate our needed API.
const { Tap } = require('node-tap');

const tap = new Tap();

// runInBand in order to share global variables with the test environment
await tap.readConfig({ overrides: 'here', runInBand: true, concurrency: 1 });

// register global hook: beforeEach, needed to determine coverage per test. We can also say a test file is a test instead (and use the filename as test name).
tap.beforeEach((test) => {
  global.__stryker__.currentTest = test.name;
});

// Load the test files without running the tests. Or run the test once, but be able to rerun them without reloading the files
await tap.loadFiles();
const results = await tap.run();
// Results include the test names or test filenames including the test results (passed or failed).

// Grab coverage from a global variable
const { mutationCoverage } = global.__stryker__;
// Determine test coverage per mutation.

// Test mutant 1:
global.__stryker__.activeMutation = 1;
const resultMutantOne = await tap.run({ testFilter: ['..array of test names to run for mutant 1'] });

// Test mutant 2:
global.__stryker__.activeMutation = 2;
const resultMutantOne = await tap.run({ testFilter: ['..array of test names to run for mutant 2'] });

Is there something that exists for this? Or is it something you guys would like to support? Thanks in advance.

I did some more research. This is what I came up with. Please let me know if I am mistaken.

Tests can only be identified by filename.
There is no way to run "in-band" other than importing the files yourself,
When we would import all test files in a single process ourselves, it is impossible to know exactly which tests executed which code (code coverage per test wouldn't be possible), since tests can run async and start running as soon as a file is imported.
When we would import all test files ourselves, we would also need to take care of stuff the tap cli takes care of. Like handling --before and --after, transpiling with ts-node or babel, selecting test files, etc.
It seems to be impossible to rerun tests after they've been executed since the process that ran the tests is already closed.

Yeah, I think "import tests instead of running in subprocs" is sort of a non-starter, tbh.  You also run into the issue that parallelizing tests gets tricky.  I've looked into this, somehow mocking out the process object and running in a Worker thread, but it would be a tremendous amount of work, especially to get all the stuff right with istanbul/nyc.

When we would import all test files in a single process ourselves, it is impossible to know exactly which tests executed which code (code coverage per test wouldn't be possible), since tests can run async and start running as soon as a file is imported.

You can get coverage per-test by digging into the .nyc_info/processinfo.json data, that's how tap does tap --changed and such.  But yeah, if from NYC's pov it's all one big process, then... idk.  Seems like a lot of stuff to refactor there.

When we would import all test files ourselves, we would also need to take care of stuff the tap cli takes care of. Like handling --before and --after, transpiling with ts-node or babel, selecting test files, etc.

What's worse, all those things assume that they're running in separate processes, can make changes to the filesystem, globals will be cleaned up, etc.

It seems to be impossible to rerun tests after they've been executed since the process that ran the tests is already closed.

It's even worse than that.  Consider this perfectly valid tap test:
const t = require('./')
t.plan(1)
const fs = require('fs')
fs.statSync('file-that-must-be-present')
t.pass('the file is there')

$ node f.js
TAP version 13
1..1
not ok 1 - ENOENT: no such file or directory, stat 'file-that-must-be-present'
  ---
  at:
    line: 1538
    column: 3
    file: node:fs
    function: Object.statSync
  stack: |
    Object.<anonymous> (f.js:4:4)
  errno: -2
  syscall: stat
  code: ENOENT
  path: file-that-must-be-present
  tapCaught: uncaughtException
  test: TAP
  ...

# failed 1 test
# time=14.29ms

$ touch file-that-must-be-present

$ node f.js
TAP version 13
1..1
ok 1 - the file is there
# time=1.427ms

Even knowing what to "re-run" is nontrivial.
Assuming you leave aside any concept of coverage, which tests ran which code, etc., I think maybe you could do this by:

Emulating process in a Worker thread.  (Wildly nontrivial.)
Using these emulated "worker as subprocess" environments to run each test.
Wrap the test code in something liket.test(filename, t => {
  global.__stryker__.childTap = t
  t = undefined
  /* mock require here so require('tap') returns stryker's childTap */
  /* also define exports, module, global, process, ... so those work */
  ${testFileContents}
})

To get to "which test ran which code", you'd also need to make NYC aware of these fake subprocess things.  Which means that in your worker-mocked subprocs, you'll also need to patch child_process.ChildProcess so that any spawn(node, ...) calls get opened in one of these memory sandboxed worker-mock subprocs.
You begin to see why I have backed away from this every time I considered it.  It would be a performance improvement even if you aren't running tests 1000s of times, but just... oof.  So complicated.  And child processes give you all of this for free, any of which we'd be bound to screw up at some point: completely clean slate memory, exactly the same runtime env as running node test.js, a process.pid and process.env that match the actual environment, optimized crash isolation and memory protection via the kernel, and because "run a child process" is the first-class way to do things, that means you can run other tests or programs in child processes and coverage and everything will keep being tracked, making tap nearly ideal for testing cli applications end to end.
It's kind of tap's killer feature, tbh.  People run into these footguns with other "faster" test platforms and then come to tap because it's safer and easier to reason about.
I'd recommend looking into the way that NYC is integrated with tap.  See if you can get by with just a -r argument to node, and dumping out some data into a folder.  Then just go ahead and run the test processes 1000s of times, see how bad it is.  This is the "shallow integration" approach that might work.
But, you really don't have to mutate the tests, right?  Just the code that they're loading.  So another alternative, is that we integrate it deeper, and instead of just $ stryker npm test, we do something like this:
// age-check.js
module.exports = (age, minAge) => {
  if (age < minAge) {
    return false
  }
  if (age > minAge) {
    return true
  }
  // untracked mutant bug at age === minAge
}

const t = require('tap')

// if you set some config, then we do the mutation stuff, running
// up to the configured number of times.
// the first run, we go straight through as normal, test failure stops the mutant hunt
// on subsequent runs, we apply mutations to any files loaded via t.mock()
// and ensure that running the test file _fails_ (if it passes, that's a live mutant)
t.test('sentinel', { mutationIterations: 1000 }, async t => {
  const ageCheck = t.mock('./age-check.js')
  t.equal(ageCheck(16), false)
  t.equal(ageCheck(25), true)
})

The downside is that mutation tracking would depend on using t.mock() to load modules, and making other edits to the tests themselves, instead of just running the process with the stryker cli.  But on the upside, we're already loading the mocked modules by reading the code and executing it, and then throwing it away when we're done, so all you have to add is the mutating transpiler.

Oh! Also, if we did the deep integration, you could maybe set defaults for these configs via environment vars, and then $ stryker tap test.js could just set those envs and run as normal.
One question remains though, since the root TAP object is also a TAP.Test, you can do this:
const t = require('tap')
const foo = t.mock('../foo.js')
t.equal(foo.bar(), 'true')

I'd probably say that if the root tap object tries to do a mutating mock() load, we just throw, say "sorry, that's not allowed, put it in a child test", or something.
Also a question:
t.beforeEach(cleanup)
t.test('foo', { strykerBlahBlah }, t => {
  makeItDirty()
})

Do we run the cleanup before each stryker iteration?  I think we do.

Thanks a lot, @isaacs . This is all very useful. Really appreciate you taking the time to answer my questions.
All in all, I think I want to step away from the idea of running tests in the same process and take the performance hit of multiple processes. But I think we can still use the "coverage per test" idea on a test file level. I will outline my plan, but first, let me explain how Stryker works on a high level.
High level Stryker workings
Step 1: code instrumentation
When you run Stryker on your project, Stryker will first load the files to be mutated. It will mutate those files, placing all mutations into the code at once. But Stryker is smart about it.
This:
function add(a, b) {
  return a + b;
}

Becomes (simplified):
function cover(id) {
  if (global.__stryker__.activeTest) {
    global.__stryker__.mutantCoverage.perTest[global.__stryker__.activeTest][id]++;
  }
  else {
    global.__stryker__.mutantCoverage.static.[id]++;
  }
}

function add(a, b) {
  if (global.__stryker__.activeMutant === 0) {
    // 👾
  } else {
    cover(0);
    return global.__stryker__.activeMutant === 1
      ? a - b // 👽
      : (cover(1), a + b);
  }
}

This is called mutant schemata (or mutation switching). All mutants are in the code, but only one can be active at once. This allows performance optimization like compiling only once and running tests in the same process (for other test runners).
As you can see, we don't rely on Istanbul code coverage. Instead, we instrument the mutant coverage directly into the source file.
Step 2: dry run
During this step, Stryker tries to run the code without mutations active. Tests should pass here. It validates that we didn't break anything, as well as allows us to determine the code coverage per test (also some other things, but that's not important here).
Normally, we would want to hook into the test framework's beforeEach hook, so that we can switch the global.__stryker__.activeTest, to record mutant coverage per test. But that won't work for node-tap as you've clearly outlined.
Step 3: mutation testing
During this step, we want to run the tests that cover a particular mutant while it is active. This is done in parallel for speed (also using worker processes, indeed, worker threads are a hassle).
After that, it generates a nice mutation test report you can open in a browser.
My plan
One of the biggest performance benefits Stryker brings is its mutant coverage per test. A mutant that isn't covered at all is directly reported as Survived (via NoCoverage). If a mutant is covered by 1 test, only that test is run for that mutant. Etc.
I think we can do that for node-tap too, at least on file level.
dry run plan
During the dry run, I'm thinking to run the tests with tap --node-arg "--require" --node-arg "./record-coverage.js" --no-cov --bail -r ./stryker-reporter.js . The record-coverage magic looks a bit like this:
// record-coverage.js
const fs = require('fs');
global.__stryker__ = global.__stryker__  || {};
const currentFile = process.argv.slice(-1)[0]; // current file seems to be passed last by node-tap
global.__stryker__.activeTest = currentFile;
process.on('exit', () => {
  const covFile = `${currentFile}.json`;
  fs.writeFileSync(covFile, JSON.stringify(global.__stryker__.mutantCoverage));
});

As you can see, when the child process exits, it neatly writes the coverage info to a json file (we could also try process.send instead, TBD). From the test runner plugin, we can then scrape up those files and report the full coverage back to Stryker, together with the test results we can find using our own using our custom stryker-reporter.js
mutation testing plan
During mutation testing, I'm thinking to run the tests with __STRYKER_ACTIVE_MUTATION__=1 tap --jobs 1 --no-cov --bail -r ./stryker-reporter.js test-that-covers-mutant-1.js other-file-that-covers-mutant-1.js . The active mutant is switched on using the __STRYKER_ACTIVE_MUTATION__ env variable, which is an alternative for the global.__stryker__.activeMutant. We use --jobs 1 here, because StrykerJS already uses parallel workers during mutation testing.
All in all, I think this is pretty simple to implement. How it will perform remains to be seen. Not very well I think, but then again, how many big node-tap projects are there?
@isaacs do you see any problems with this approach?
Another question: would you be open to opening up the node-tap CLI for programmatic use? That would save us the hassle of calling tap in a child process, instead we could do something like this:
const { runCli } = require('tap/cli');
await runCli(['--jobs', '1', '--no-cov', '--bail', '-r', './stryker-reporter.js', 'test-that-covers-mutant-1.js', 'other-file-that-covers-mutant-1.js'])

It would also make it easier to communicate with the Stryker reporter instance since it is run in the host process.

const currentFile = process.argv.slice(-1)[0]; // current file seems to be passed last by node-tap

You can run into trouble if you provide test-arg options.
$ cat args.js
console.error(process.argv)

$ cat require.js
console.error('i got required')

$ tap --test-arg=foo args.js --node-arg=--require --node-arg="./require.js" -C --no-cov
TAP version 13
i got required
[ '/usr/local/bin/node', '/Users/isaacs/dev/tapjs/tap/args.js', 'foo' ]
ok 1 - args.js # SKIP no tests found {
    1..0 # no tests found
}

1..1
# skip: 1
# time=41.206ms

I think what you really want is just process.argv[1].

Not very well I think, but then again, how many big node-tap projects are there?

I can think of a few 😝

@isaacs do you see any problems with this approach?

Mostly just performance.  Losing parallel testing will be a pretty big hit.

would you be open to opening up the node-tap CLI for programmatic use?

Not opposed in principle, but it's not really designed to be used that way.  I would expect to have to refactor out some assumptions where we expect that it owns the process.
It might be worth exploring taking over the runner entirely, and interfacing with libtap?

Thanks for your reaction @isaacs

I think what you really want is just process.argv[1]

Great! Didn't know the main file is always the first argument. Thanks for pointing that out to me.

Mostly just performance. Losing parallel testing will be a pretty big hit.

I don't think so. Say we need to test 100 mutants and thus run the tests 100 times. It doesn't matter if StrykerJS spins up 1 tap test runner with --jobs 8 or 8 test runners with --jobs 1, right? The gross time should be about the same.

Not opposed in principle, but it's not really designed to be used that way. I would expect to have to refactor out some assumptions where we expect that it owns the process.

Yes. I tried creating a runCli function, but it is very hard. The bin/run.js file is pretty big, with a lot of process.env and process.on magic. I don't know where to begin honestly.

It might be worth exploring taking over the runner entirely, and interfacing with libtap?

How would that look exactly? End users import directly from tap right? How could i interface with libtap?

I can think of a few 😝

Yeah... I see your point 😊
I'm now thinking to maybe make a bare bones runner that simply runs the test files in isolated child processes without the use of node-tap. One of the design goals of node-tap is to be able to simply to run the test file directly, right? It feels like a waste to not use that to our advantage. If users want to JIT transpile files with ts-node or something, we can still allow to do that by let you configure a --require for it, basically mimic a bare bones node-tap, but without a lot of the bells and whistles. We could educate users to transpile their code only once by using a --buildCommand to improve performance.
@isaacs do you see problems with this approach?

🎉 We've implemented tap runner support using the design I outlined in my previous comment.
You can review the docs here: https://stryker-mutator.io/docs/stryker-js/tap-runner/. A blog article about this release will be published next Monday.
@isaacs thanks again for all the help!
As proof it works, here is a report of rimraf: rimraf-report.zip
I'm pretty happy with the performance, taking ~3 minutes on --concurrency 8. If you want I could add a PR to run mutation testing on rimraf in a CI pipeline.


Resource pack bug??

i've got a custom resource pack.. but euhh it's a little bit buggy, it makes my items in my hand really big :p idk what that is.. http://imgur.com/IMW4AM7

we can't fix this sadly, the way they are formatted changed but it looks hilarious haha

It's not a really big problem XD and yes it looks hilarious :P


mav_comm: 3.3.2-0 in 'indigo/distribution.yaml' [bloom]

Increasing version of package(s) in repository mav_comm to 3.3.2-0:

upstream repository: https://github.com/ethz-asl/mav_comm.git
release repository: https://github.com/ethz-asl/mav_comm-release.git
distro file: indigo/distribution.yaml
bloom version: 0.6.6
previous version for package: 3.3.1-0

mav_comm
* Fix indigo eigen3 compatibility.

mav_msgs
* Fix indigo eigen3 compatibility.

mav_planning_msgs
* Fix indigo eigen3 compatibility.

holding for indigo sync

merging this to fix last indigo regression


FUCK!!!
YOU!!!!

ok

Don't your computer have a recycle bin?


Spike/real device

After more than 30h and over more than a week, with lots of attempts and many different changes I think I got real device to work.
See https://github.com/oskarth/mopro/issues/1
I'll factor out more minimal diffs from this to make it more usable. The key diff seems to be using a wasmer memory patch.
This PR is also sketching out dylib use, which might not be 100% needed, but is something we might want down the line.
Screenshot from real device

Minimal diff for wasmer only https://github.com/oskarth/mopro/pull/8
I'll separate out the dylib stuff at some point as I think we want it

Rust dylib and wasmer stuff integrated. The PR still has some Xcode/script updates that could be useful, so leaving it open for now.

Out of date with recent work


look and say recursion algorithm integrated

📥 Pull Request
Description
Integrated look and say algorithm which contain Introduction Problem Statement Approach Pseudo Code Algorithm
Implementation in C++
Fixes #311
Type of change

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

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

@ajay-dhangar please review my pr

@ajay-dhangar i have corrected it please review


Adds logic to deidentify the patient age if over the age of 89

This PR adds logic to do deidentification on the patient age if the patient is 89 or older, per the HIPAA Safe Harbor rules referenced in #5412.
The logic for this calculates the patient age thusly:
     if patient_age is a number :
          if patient_age >= 89:
              return 0
         else:
              return patient_age
    else:
        if specimen_collection_date - patient_dob >= 89 or current_date - patient_dob >= 89:
            return 0
       else
            return null

Test Steps:

gradle test testIntegration
./prime test
Generate a file and route it to a receiver that has deidentify = true. Validate that the patient age data has been deidentified

Changes

Added new method to rewrite the patient age column when deidentifying
Refactored deidentification function and other minor updates
Unit tests

Testing

[x] Tested locally?
[x] Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?
[ ] (For Changes to /frontend-react/...) Ran npm run lint:write?
[x] Added tests?

Linked Issues

Closes #5412

Pull reviewers stats
Stats for the last 30 days:

User
Total reviews
Time to review
Total comments

MauriceReeves-usds
19
15h 4m
3

jeremy-page
18
1h 31m
0

clediggins-usds
12
14h 22m
16

kevinhaube
11
1h 53m
28

carlosfelix2
11
17h 17m
32

jorg3lopez
7
2h 30m
0

jbiskie
7
1h 5m
0

ahay-agile6
6
2h
2

TomNUSDS
5
25m
13

doug-s-nava
5
1h 40m
31

oslynn
4
6h 47m
0

TurkeyFried
3
25m
0

brick-green
3
18h 44m
0

bgantick
2
13h 34m
1

JosiahSiegel
2
25m
0

sethdarragile6
2
40m
2

jimduff-usds
1
12h 26m
0

BerniXiongA6
1
27m
2

snesm
1
39m
0

PatriciaPerozoUSDS
1
4m
0

A few things that I noticed while testing this PR:

Converting the patient's age to zero when equals to or greater than 89 works but it doesn't appear on hl7 message
patient_age has pii = false, I'm not sure if this has any unintended results
patient_age_units has pii = false, as well
OBX-6 which is the patient's age units is blank instead of showing zero. Or should the age appear on OBX-5 which is currently being populated by test_result
Below is a code snippet of where OBX-6 is populated:

Great job refactoring the deidentified logic, it looks a lot cleaner. I'm not sure where the zero gets blanked out, this is the only thing that I think needs further investigation as this might be related to how the code base works, and not the deidentifying logic for the patient's age.

I ran a message through for the receiver water.giang and the patientAge field had a value on output. Is that expected?


Replace manual miniredis setup with statestore testing utility code

Expose a statestore util function for testing purpose and replace repetitive miniredis manual setup this function.

Closed as #462 resolved most of the issues in this PR.


Library symbols can't be found

After attempting to link the 434 and 751 libraries/add API includes to a project, the linker complains that symbols can't be found.
I can see the symbol by running strings on the library, still investigating deeper.
target_include_directories(client
    PUBLIC
    ../deps/PQCrypto-SIDH/src
    ${CMAKE_BINARY_DIR}/proto)

target_link_libraries(client
    PUBLIC
    ${PROTOBUF_LIBRARIES}
    ${CMAKE_BINARY_DIR}/proto/libsockproto.a
    ${CMAKE_BINARY_DIR}/../deps/PQCrypto-SIDH/lib434/libsidh.a)

[ 52%] Linking CXX executable client
/usr/bin/ld: CMakeFiles/client.dir/client.cc.o: in function `sockpuppet::client::exchange_keys()':
/home/jonesy/git/sockpuppet/include/sockpuppet/client.h:150: undefined reference to `random_mod_order_A_SIDHp434(unsigned char*)'
/usr/bin/ld: /home/jonesy/git/sockpuppet/include/sockpuppet/client.h:152: undefined reference to `EphemeralKeyGeneration_A_SIDHp434(unsigned char const*, unsigned char*)'
/usr/bin/ld: /home/jonesy/git/sockpuppet/include/sockpuppet/client.h:159: undefined reference to `EphemeralSecretAgreement_A_SIDHp434(unsigned char const*, unsigned char const*, unsigned char*)'
collect2: error: ld returned 1 exit status
make[2]: *** [example/CMakeFiles/client.dir/build.make:106: example/client] Error 1
make[1]: *** [CMakeFiles/Makefile2:261: example/CMakeFiles/client.dir/all] Error 2

Even manually linking is erroring.
$ g++ -std=c++20 client.cc -I../include -I../deps/PQCrypto-SIDH/src -I../build/proto -lprotobuf -L../deps/PQCrypto-SIDH/lib751comp -lsidh -L../build/proto -lsockproto -lpthread -o client
/usr/bin/ld: /tmp/ccd00KH1.o: in function `sockpuppet::client::exchange_keys()':
client.cc:(.text._ZN10sockpuppet6client13exchange_keysEv[_ZN10sockpuppet6client13exchange_keysEv]+0x29): undefined reference to `random_mod_order_A_SIDHp751(unsigned char*)'
/usr/bin/ld: client.cc:(.text._ZN10sockpuppet6client13exchange_keysEv[_ZN10sockpuppet6client13exchange_keysEv]+0x55): undefined reference to `EphemeralKeyGeneration_A_SIDHp751_Compressed(unsigned char const*, unsigned char*)'
/usr/bin/ld: client.cc:(.text._ZN10sockpuppet6client13exchange_keysEv[_ZN10sockpuppet6client13exchange_keysEv]+0xa6): undefined reference to `EphemeralSecretAgreement_A_SIDHp751_Compressed(unsigned char const*, unsigned char const*, unsigned char*)'
collect2: error: ld returned 1 exit status

Does it work if you only include one of the two options (434 or 751)? The problem might be that some symbols are redefined for each parameter set. You can look at the integration strategy in the open-quantum safe project, where all the SIKE parameter sets co-exist (see this directory).

Does it work if you only include one of the two options (434 or 751)? The problem might be that some symbols are redefined for each parameter set. You can look at the integration strategy in the open-quantum safe project, where all the SIKE parameter sets co-exist (see this directory).

Unfortunately not, I had tried them individually. I'll poke around and see if I come out with found symbols.


Rooms Tab: Update Room Directory wording

[x] The header should be presented as an iOS settings:
Network                  	Freenode 	>
[x] Also: there is a bug: when selecting Matrix, it should display Matrix, not matrix.org
[x]  Matrix .org wording should be “All rooms on matrix.org server” (if it fits) in the list. Matrix.org on the room list
[x] Matrix.org icon should be a Matrix logo in the list
[x] The wording for “Matrix” in the list of networks should be “Native Matrix rooms” (displayed as “Matrix” in the room)

What has been decided for the collision between the chevron in "Network Freenode >" and the chevron ⌄ used for collapsing a section ?

The answer of my prev comment:

@giomfo @manuroe So we don't display the little picto "#" for example, like riot-web ?


Error fetching media

Description
I can not access media.

Steps to reproduce
Repo: https://github.com/huco95/raquel-nogal-next

Clone repo
Publish to vercel (as this only happens on production not on local dev server)

Expected result
Media panel should be opened to upload images.
Actual result

Environment
Vercel deployment.
Tinacms Package Versions
"@tinacms/cli": "^0.61.20"
"tinacms": "^0.69.14"

Can you provide more information on what actions you are taking? Are you just opening the media manager and getting this error or doing something else? The reason I ask is because the url in the log doesn't really make sense: /list//blog/images/?limit=20
I think you would need to navigate into a subfolder (/blog/images/) in order for that url to be requested

Can you provide more information on what actions you are taking? Are you just opening the media manager and getting this error or doing something else? The reason I ask is because the url in the log doesn't really make sense: /list//blog/images/?limit=20
I think you would need to navigate into a subfolder (/blog/images/) in order for that url to be requested

I just open the media manager and get this error. This is working fine on localhost, so I think the schema configuration is correct.

I forked your repo and deployed it to vercel and I'm currently unable to reproduce this.
@logan-anderson any idea why his media manager would be attempting to list /blog/images/ when it first opens?

This is the behavior when I am trying to create a new post:

This from the Media Manager:

Great, that helps a lot. This line is the problem: https://github.com/kldavis4/raquel-nogal-next/blob/main/.tina/schema.js#L46
Remove that uploadDir prop and I think it will resolve the issue.

It looks like there is a bug that is causing this. Fix should be released in the next day or two (or you can use the tinacms@beta version)

It looks like there is a bug that is causing this. Fix should be released in the next day or two (or you can use the tinacms@beta version)

Great! Thanks for the quick fix! ❤


Implement DataViews for Seq and Tuple

Implemented in new chisel3.experimental.conversions package. Includes:

Implementations of DataProduct
Implementations of DataView from Seq to Vec and Tuple to HWTuple
Implicit conversions from Seq to Vec and Tuple to HWTuple

Examples are buried in the tests, but this makes it possible to write stuff like:
import chisel3._
import chisel3.experimental.conversions._
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val w, x, y, z = IO(Output(UInt(8.W)))
  ((w, x), (y, z)) := ((a, b), (c, d))
}

and
import chisel3._
import chisel3.experimental.conversions._
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val out = IO(Output(Vec(4, UInt(8.W)))
  out := Seq(a, b, c, d)
}

I still haven't implemented more than just Tuple2, I intend to do several, maybe up to like Tuple7 or something.
Opening this before finishing it because I'd like feedback on the approach.
Questions
Do we like the implicit conversions?
They feel natural but I know folks are generally skeptical of implicit conversions.
An alternative is to provide .asData as an extension method, something like:
implicit class CanConvertToData[A : DataProduct](a: A) {
  def asData[B <: Data](implicit dataview: DataView[A, B]): B = a.viewAs[B]
}

This would change the above examples slightly:
import chisel3._
import chisel3.experimental.conversions._
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val w, x, y, z = IO(Output(UInt(8.W)))
  ((w, x), (y, z)).asData := ((a, b), (c, d)).asData
}

You can see the total impact of this change on existing tests in this diff: https://gist.github.com/jackkoenig/ae5d20b18b4df2871aa174f0a38551a0
Do we like the package?
import chisel3.experimental.conversions._

They could live directly chisel3.experimental.dataview, or it could be a subpackage of dataview. I think the DataProducts and the DataViews should live together but it's not clear if the implicit conversions (assuming we keep them) should live in the same package.
Contributor Checklist

[ ] Did you add Scaladoc to every public function/method?
[ ] Did you add at least one test demonstrating the PR?
[ ] Did you delete any extraneous printlns/debugging code?
[ ] Did you specify the type of improvement?
[ ] Did you add appropriate documentation in docs/src?
[ ] Did you state the API impact?
[ ] Did you specify the code generation impact?
[ ] Did you request a desired merge strategy?
[ ] Did you add text to be included in the Release Notes for this change?

Type of Improvement

API Impact

Backend Code Generation Impact

Desired Merge Strategy

Release Notes

Reviewer Checklist (only modified by reviewer)

[ ] Did you add the appropriate labels?
[ ] Did you mark the proper milestone (Bug fix: 3.3.x, [small] API extension: 3.4.x, API modification or big change: 3.5.0)?
[ ] Did you review?
[ ] Did you check whether all relevant Contributor checkboxes have been checked?
[ ] Did you mark as Please Merge?

I'm curious what users think @mwachs5, @aswaterman, @carlosedp, @ingallsj, @schoeberl, @sequencer

Do we like the implicit conversions?

One of my biggest user issues with the implicit conversions is its hard to understand why my code doesn't work when your code does. If there is a function it's easy to figure out in IDE how to include the function, but if an implicit conversion is missing, it's hard to discover.
What is the advantage of the example:
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val out = IO(Output(Vec(4, UInt(8.W)))
  out := Seq(a, b, c, d).asData
}

Is it just saving the few characters of writing VecInit, or does this change the output in some way? If the former this seems like a pattern that would again just confuse people.
The Mux example is much more compelling IMHO, can you shoudl what that woudl look like if we forced the .toData thing?
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val sel = IO(Input(Bool()))
  val y, z = IO(Output(UInt(8.W)))
  (y, z) := Mux(sel, (a, b), (c, d))
}

Do we like the implicit conversions?

One of my biggest user issues with the implicit conversions is its hard to understand why my code doesn't work when your code does. If there is a function it's easy to figure out in IDE how to include the function, but if an implicit conversion is missing, it's hard to discover.

Yeah it's a fair concern.
I should revise my proposal a bit, I think we should definitely have .asData whether or not we have the implicit conversions. Then, if something isn't working for a user, they can always use the explicit .asData. That doesn't resolve your concern, but maybe it helps.

What is the advantage of the example:
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val out = IO(Output(Vec(4, UInt(8.W)))
  out := Seq(a, b, c, d).asData
}

Is it just saving the few characters of writing VecInit, or does this change the output in some way? If the former this seems like a pattern that would again just confuse people.

In this case, it's true that VecInit(a, b, c, d) would accomplish the same thing. But if we flipped the directions of everything, DataView allows connecting to the underlying elements:
// This would work
Seq(a, b, c, d).asData := out
// This would just connect to an intermediate Wire and thus be dropped
VecInit(a, b, c, d) := out // bad! don't do this!

The Mux example is much more compelling IMHO, can you shoudl what that woudl look like if we forced the .toData thing?
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val sel = IO(Input(Bool()))
  val y, z = IO(Output(UInt(8.W)))
  (y, z) := Mux(sel, (a, b), (c, d))
}

I had it above but it would look like this:
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val sel = IO(Input(Bool()))
  val y, z = IO(Output(UInt(8.W)))
  (y, z).asData := Mux(sel, (a, b).asData, (c, d).asData)
}

This is actually the case that made me add the implicit conversion in the first place. The nice thing about the implicit conversion is that any place a user writes code that accepts Data or T <: Data, it will just work if passed Seqs or Tuples of Data. Without the implicit conversion, people can of course manually cast each thing, and method writers could of course add their own version of the method that will do the conversion. For example, in the case of Mux:
object Mux {
  // Simplified since we also have SourceInfo and CompileOptions implicits here, and a do_ macro
  def apply[T <: Data](cond: Bool, con: T, alt: T): T = ???
}

One could add the following additional methods so that it will do the conversion rather than requiring an implicit:
  def apply[A : DataProduct, T <: Data](cond: Bool, con: T, alt: T)(implicit ev: DataView[A, T]) : T =
    apply(cond, con.viewAs[T], alt.viewAs[T])

I think this is fine to do inside of Chisel itself, but I'm not super keen to suggest users do the same. Thus in practice, most user-defined APIs would require explicit .asData for non-Data-but-viewable-as-Data arguments

It's occurred to me that .asData is identical to just .viewAs except I'm stylistically leaving off the explicit [T] which works so long as T is unambiguous (as it normally is). Makes me question whether .viewAs is the right method name because the following also works:
class MyModule extends Module {
  val a, b, c, d = IO(Input(UInt(8.W)))
  val sel = IO(Input(Bool()))
  val y, z = IO(Output(UInt(8.W)))
  (y, z).viewAs := Mux(sel, (a, b). viewAs, (c, d). viewAs)
}

This is actually the case that made me add the implicit conversion in the first place.

I agree I really like the implicit conversion in the Mux case
I think you should include your Seq/Vec example from below it is also nice and compelling.
// This would work
Seq(a, b, c, d).asData := out
// This would just connect to an intermediate Wire and thus be dropped
VecInit(a, b, c, d) := out // bad! don't do this!

Alright, after further thought, I'm going to move all of the DataProduct and DataView implementations into the companion objects of DataProduct and DataView so that they are available in the implicit scope (ie. without a specific import). The implicit conversions will remain in package chisel3.experimental.conversions (requiring the specific import) so that we can evaluate how well they work. My intuition is that they are a good thing (for these particular cases, definitely not for all cases), but we should see how it works in practice.

I checkout and tried this feature, I really like this conversation! I think implicitly conversion will be more friendly to most of newbies to Chisel.
Maybe a documentation(just copy&paste from PR description) for end user will be much better.

One of my biggest user issues with the implicit conversions is its hard to understand why my code doesn't work when your code does. If there is a function it's easy to figure out in IDE how to include the function, but if an implicit conversion is missing, it's hard to discover.

By default, I forcing users from our lab using IntelliJ IDEA, and think they are supported by Jetbrains by default(I think it really can teach them Scala, haha).
Without implicit conversion, users must understand why they should asData, which is a tough job for me to explain the magic of dataview APIs.
So as a trade-off, I think a implicit conversion should be documented and optional import by user(I only need to ask them: just import this for better user experience).

I'm all for the implicit conversions from a user perspective.
Having the casts all over will make things more complex where one will ask things like "should .asData go here... or there" making debug more confusing.
Other than that, I like the implementation making very straightforward to assign tuples/hwtuples too.

Okay I think this is ready. I've made a few minor changes but I think there's wide agreement on the approach here.
DataProducts and DataViews for Seq and Tuple2-Tuple10 are now defined in the companion objects for DataProduct and DataView. This means that users who import chisel3.experimental.dataview._ will have access to .viewAs for Seqs and Tuples with no additional import. The implicit conversions are in a new package, chisel3.experiemental.conversions such that if a user imports from that package, they will get the nice syntax for tuples and the like.
Interestingly, while the implicit conversions seem to work fantastically for Tuples, they seem to work less well for Seq, as evidenced by this test:
class MyModule extends Module {
   val a, b, c, d = IO(Input(UInt(8.W)))
   val sel = IO(Input(Bool()))
   val y, z = IO(Output(UInt(8.W)))
   // Unclear why the implicit conversion does not work in this case for Seq
   // That being said, it's easy enough to cast via `.viewAs` with or without
   Seq(y, z) := Mux(sel, Seq(a, b).viewAs, Seq(c, d).viewAs[Vec[UInt]])
 }

I do not know why this is, but I wrote this test to capture something interesting. The implicit conversion does work for the LHS, ie. := is only working here because of the implicit conversion, yet for some reason it does not work for the arguments to Mux. I then show that one can use .viewAs without explicit type parameters if there's only 1 DataView in scope (which is the normal case). You can of course, do the normally recommended thing and give type parameters.
I'm wondering if we should add .asData that is basically an alias for .viewAs but would return self if called on a Data and otherwise would do the same thing as .viewAs. Any thoughts? I do see that as a separate PR.

@jackkoenig it would be great to grab those nice examples and put them into the cookbook

@jackkoenig it would be great to grab those nice examples and put them into the cookbook

Agreed, will do in follow on PR.


cli: list generators

see https://github.com/generate/generate/issues/18#issue-164653643

Starting to think that it's not a good choice gen to have commands - or they should not be too much. How gen list will differs from generate-list on day? Also the generate-init is cool name, but it will be forbidden because the command init. Feel the conflicts?

right, they need to be externalized into generators. I mentioned that earlier.
Eventually, we won't have any built in tasks or generators.

oh, however...

How gen list will differs from generate-list on day?

Once generate-list is published, (@doowb might have that), if you installed it globally it would override the built-in list command

it would override the built-in list command

make sense, but then how user will access the real list command that list the generators ;d

like this gen defaults:list :)

keep in mind that will only happen when you intentionally override the defaults...

oh, and if you don't like doing $ gen defaults:list, then do this:
$ gen foo --macro defaults:list

Where foo is whatever name you want to save the command as. Then run $ gen foo


Dockstation doesn't work with docker-compose.override.yml

I have projects with docker-compose.yml for common and docker-compose.override.yml for custom environments. When I open my project via Dockstation in there creates containers from docker-compose.yml only.
Could you fix that and what about working with extends and custom yml-file for docker-compose?
Best regards,

Hi @imilyukov
Duplicate #47
Yes, we'll fix that.


Add advanced filtering features to Pom Editor Maven Plugin, including module filtering

Problem Description:
Currently, the Pom Editor Maven Plugin has limited filtering capabilities for elements in the POM file. For large and complex projects with many dependencies and plugins, it can be difficult to manually manage the POM without the ability to filter elements based on specific criteria. Additionally, when a project has an original POM and POM templates in each module, manual editing can be even more cumbersome.
Proposed Solution:
Add advanced filtering features to the Pom Editor Maven plugin to allow users to filter POM elements based on specific criteria, including module filtering. The advanced filtering features would allow users to edit the POM more efficiently and accurately, saving time and reducing the risk of manual errors.
CLI Examples:
Filter dependencies by group and module
 mvn pom-editor:filter -DpomFile=pom.xml -DgroupId=com.example -Dmodule=core

Filter plugins by artifact ID and module
mvn pom-editor:filter -DpomFile=pom.xml -DartifactId=maven-compiler-plugin -Dmodule=webapp

Filter dependencies by scope and module
mvn pom-editor:filter -DpomFile=pom.xml -Dscope=runtime -Dmodule=core

Benefits:
Facilitates POM editing in large and complex projects.
Reduces the risk of manual errors when filtering POM elements.
Saves time for developers, making POM editing more efficient and accurate.
Acknowledgments:
We appreciate your consideration and feedback on this idea. We look forward to hearing your opinions and suggestions

@dellamas, we are very happy you are interested in helping us and there are plenty of ways you can do so. Thanks for your interest in this project! :+1:
This proposal is very good and worthy!
I totally agree with you:

For large and complex projects with many dependencies and plugins, it can be difficult to manually manage the POM without the ability to filter elements based on specific criteria.

Right now, the plugin doesn't look for dependencies declared on parent POM files and it doesn't handle Maven multi-module projects with many POM files, but it is something that it's on the radar for sure!
What the add-dep goal does is: it will look up the matched dependency on the target POM file in order to update with the given version, classifier, type, and scope or add the given dependency if it's not declared on the target POM file.
IMHO I think the proposal should get be refined. :1st_place_medal:
Please, could you re-create this proposal by using the New Goal Proposal issue form? Try to provide all the required fields of the form in order to help us to understand the whole proposal, since the objective, requested goals syntaxes, and possible scenarios with expected results. Here's a sample of a new goal proposal created by using this issue form.
One more time, thank you for your interest in this project and for your proposal! :+1:
Will be amazing to make this proposal come true! :clap:!
Let me know if you need help.


deltachat-desktop: 1.30.1 -> 1.32.0

Description of changes
https://github.com/deltachat/deltachat-desktop/blob/v1.32.0/CHANGELOG.md
I can't use the correct version of libdeltachat because of https://github.com/deltachat/deltachat-core-rust/issues/3548.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

with this change on top, latest version 1.32.1 builds and runs fine
diff --git a/pkgs/applications/networking/instant-messengers/deltachat-desktop/default.nix b/pkgs/applications/networking/instant-messengers/deltachat-desktop/default.nix
index 7266ebde10f..391455b4b9b 100644
--- a/pkgs/applications/networking/instant-messengers/deltachat-desktop/default.nix
+++ b/pkgs/applications/networking/instant-messengers/deltachat-desktop/default.nix
@@ -50,13 +50,13 @@ let
   };
 in nodePackages.deltachat-desktop.override rec {
   pname = "deltachat-desktop";
-  version = "1.32.0";
+  version = "1.32.1";

   src = fetchFromGitHub {
     owner = "deltachat";
     repo = "deltachat-desktop";
     rev = "v${version}";
-    hash = "sha256-5eau6CLgze13rc1+fhNgdy/NEbEHBKf5/xd5K+zb4Co=";
+    hash = "sha256-DklrTMnubVSkD1wfJzPRqWsVZy65kG7EuvRVRYcCUAI=";
   };

   nativeBuildInputs = [

I tried to port it without the fix, and can't get it to work...

@rapenne-s But libdeltachat 1.91.0 still doesn't build.

@winterqt Do you still have the code that uses the recently merged https://github.com/NixOS/nixpkgs/pull/189539 for this update?

superseded by #200981


url and slider

url for sharing .ck files
slider GUI generation
both work separately but not together
https://chuck.stanford.edu/ide/?url=https://ccrma.stanford.edu/~cc/sonify/HelloSineGUI.ck#

Hi Chris! Discussing this on the chuck dev Discord. From @celestebetancur "we are changing the old generator for the one that I implemented for slork and also, I am waiting for @fenglyfe to have virtual DOM, that way we can avoid the two extra steps generating the GUI" We will keep you posted!
By the way, we'd love to have some kind of "back to school" chuck hackathon before the Fall Quarter, perhaps in late August, to fix bugs and improve things on all fronts for the Fall Quarter (220a, 256a, etc.). Will have more info soon...

This is now fixed in #6 ! Thank you Chris for testing it out!

Reopening issue after further investigation:

Bug still occurs ~10% of the time when cold loading a file.
p5js seems to be unresponsive in these instances and thus doesn't setup and draw
Further p5js framework exploration needed

@cchafe Investigated the bug further and found out that p5js doesn't like the asynchronous loading of external files. I've updated the system to handle this. For external URLs, the Generate UI button will need to be hit once the file contents are loaded. Let me know if this works!

Looking good, thanks!
Other question: What's the status of safari, ok to use? (I don't have a mac)

Yup! Safari is supported and works too (this includes Safari on iOS)