Device Request - Radar sensor ceiling model - _TZE204_sxm7l9xa / TS0601

Hi,
Thanks for your great job!
I have the test version on my Homey Pro and saw that radar sensor : https://fr.aliexpress.com/item/1005005477612297.html has driver in your app.
I thought that ceiling mount and wall mount were similar in firmware but it doesn't seems to be.
Please check below informations about this device:

Could you add this device to the driver list in your app? It would be wonderful :)
Thanks a lot!
Brand: Loginovo
ManufacturerName: _TZE204_sxm7l9xé
Product ID: TS0601
Device ID: a4:c1:38:21:d0:d2:a3:62
Profile ID:
Interview : below
Image: https://ae01.alicdn.com/kf/S6b18bbdfc28944109bd0e16eb7eb460d7/Smart-Life-Zigbee-D-tecteur-de-Pr-sence-Humaine-Tuya-Wifi-MmWave-Radar-Capteur-de-Montion.jpg_640x640.jpg
Product Name: Human radar sensor

Just a comment, with _TZE204_sxm7l9xa it's also ZY-M100-S
ZY-M100-S: ZigBee based, wall-mounted version
ZY-M100-L: ZigBee based, ceiling-mounted version

@shaarkys not recognized by my homey with last test version unfortunately, this is why I opened this topic 😉

Yep I know, just saying, it looks like with the same Manufacturer / ModelID, it looks like there are two different products (eg. could be confusing for pairing for some users)

Any news on this one? Frustrating that the device is added allready, but just not with this manufacturer..

FYI, it has been added in the most recent version, unfortunately reports only Lx @JohanBendz
Diag : 3c072755-96be-43dc-a16c-66610752c5dc
Just in case, actual interview :
  "ids": {     "modelId": "TS0601",     "manufacturerName": "_TZE204_sxm7l9xa"   },   "endpoints": {     "ieeeAddress": "a4:c1:38:d7:d3:26:58:b2",     "networkAddress": 10606,     "modelId": "TS0601",     "manufacturerName": "_TZE204_sxm7l9xa",     "endpointDescriptors": [       {         "status": "SUCCESS",         "nwkAddrOfInterest": 10606,         "_reserved": 20,         "endpointId": 1,         "applicationProfileId": 260,         "applicationDeviceId": 81,         "applicationDeviceVersion": 0,         "_reserved1": 1,         "inputClusters": [           4,           5,           61184,           0         ],         "outputClusters": [           25,           10         ]       },       {         "status": "SUCCESS",         "nwkAddrOfInterest": 10606,         "_reserved": 10,         "endpointId": 242,         "applicationProfileId": 41440,         "applicationDeviceId": 97,         "applicationDeviceVersion": 0,         "_reserved1": 0,         "inputClusters": [],         "outputClusters": [           33         ]       }     ],     "deviceType": "router",     "receiveWhenIdle": true,     "capabilities": {       "alternatePANCoordinator": false,       "deviceType": true,       "powerSourceMains": true,       "receiveWhenIdle": true,       "security": false,       "allocateAddress": true     },     "extendedEndpointDescriptors": {       "1": {         "clusters": {           "groups": {             "attributes": [               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 0,                 "name": "nameSupport",                 "value": {                   "type": "Buffer",                   "data": [                     0                   ]                 },                 "reportingConfiguration": {                   "status": "NOT_FOUND",                   "direction": "reported"                 }               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 65533,                 "name": "clusterRevision",                 "value": 2,                 "reportingConfiguration": {                   "status": "NOT_FOUND",                   "direction": "reported"                 }               }             ]           },           "scenes": {             "attributes": [               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 0,                 "reportingConfiguration": {                   "status": "NOT_FOUND",                   "direction": "reported"                 }               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 1,                 "reportingConfiguration": {                   "status": "NOT_FOUND",                   "direction": "reported"                 }               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 2,                 "reportingConfiguration": {                   "status": "NOT_FOUND",                   "direction": "reported"                 }               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 3,                 "reportingConfiguration": {                   "status": "NOT_FOUND",                   "direction": "reported"                 }               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 4,                 "reportingConfiguration": {                   "status": "NOT_FOUND",                   "direction": "reported"                 }               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 65533,                 "name": "clusterRevision",                 "value": 2,                 "reportingConfiguration": {                   "status": "NOT_FOUND",                   "direction": "reported"                 }               }             ]           },           "basic": {             "attributes": [               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 0,                 "name": "zclVersion",                 "value": 3               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 1,                 "name": "appVersion",                 "value": 74               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 2,                 "name": "stackVersion",                 "value": 0               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 3,                 "name": "hwVersion",                 "value": 1               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 4,                 "name": "manufacturerName",                 "value": "_TZE204_sxm7l9xa"               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 5,                 "name": "modelId",                 "value": "TS0601"               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 6,                 "name": "dateCode",                 "value": ""               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 7,                 "name": "powerSource",                 "value": "mains"               },               {                 "acl": [                   "readable",                   "writable",                   "reportable"                 ],                 "id": 65502               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 65533,                 "name": "clusterRevision",                 "value": 2               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 65534,                 "name": "attributeReportingStatus",                 "value": "PENDING"               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 65506               },               {                 "acl": [                   "readable",                   "reportable"                 ],                 "id": 65507               }             ]           }         },         "bindings": {           "ota": {},           "time": {             "attributes": [               {                 "acl": [                   "readable"                 ],                 "id": 65533,                 "name": "clusterRevision",                 "value": 1               }             ]           }         }       },       "242": {         "clusters": {},         "bindings": {}       }     }   }

@JohanBendz possibly interesting and related conversation for _TZE204_sxm7l9xa :
    tuyaDatapoints: [
            [105, 'presence', tuya.valueConverter.trueFalse1],
            [104, 'illuminance_lux', tuya.valueConverter.raw],
            [106, 'radar_sensitivity', tuya.valueConverter.raw],
            [109, 'distance', tuya.valueConverter.divideBy100],
            [110, 'fading_time', tuya.valueConverter.divideBy10],
            [107, 'far_detection', tuya.valueConverter.divideBy100],
            [108, 'near_detection', tuya.valueConverter.divideBy100],
            [111, 'detection_delay', tuya.valueConverter.divideBy10],
        ]

https://www.zigbee2mqtt.io/advanced/support-new-devices/02_support_new_tuya_devices.html#_3-understanding-tuya-datapoints
https://github.com/Koenkk/zigbee2mqtt/issues/17483
Probably nothing you don't know already...

Same problem here. Only reporting lux. @JohanBendz is this something you can fix?

I have fix already, working on update...

I have fix already, working on update...

Thats great! Thanks

@powermarcel10  @nides34 FYI - https://github.com/JohanBendz/com.tuya.zigbee/pull/743/commits/ac206c8c460c6d558901b492108f6f4784325663

Same problem here. Only reporting lux. @JohanBendz is this something you can fix?

Same problem here.
Thanks @shaarkys waiting for your update 🙂👍

Hi @shaarkys , @JohanBendz
Do you found any solution to fix radar sensor occupancy state?
Thanks :)

Thanks for your reply :)
I don't know how to perform this CLI install :(

I found the way ; but got an error with ac208c8 version:
Command failed: npm ls --parseable --all --only=prod
npm WARN config only Use --omit=dev to omit dev dependencies from the install.
npm ERR! code ELSPROBLEMS
npm ERR! extraneous<EMAIL_ADDRESS>D:\tuya\node_modules\almost-equal
npm ERR! extraneous<EMAIL_ADDRESS>D:\tuya\node_modules\hsluv
npm ERR! extraneous<EMAIL_ADDRESS>D:\tuya\node_modules\mumath
npm ERR! invalid<EMAIL_ADDRESS>D:\tuya\node_modules\color-space
I thinks I'll wait Johan official update to avoid any crash :)

https://community.homey.app/t/how-to-cli-install-method/198
Also prior homey app install run npm install in the directory, where you downloaded and unpacked version, which you can take from : https://github.com/shaarkys/com.tuya.zigbee  ... or, simply wait ;-) johan is working on major update, eg. latest update 4 days ago.

That's great! Missing npm install before, now that's good, thanks for you perfect help!
I will test that this everning when I'll be back home :)

Perfect, it runs! Many many thanks!

@JohanBendz Can you please add this to the app?


logs about node Energy is confusing

I0207 01:18:49.668971       1 metric_collector.go:130] node energy (mJ):
        ePkg: 0 (eCore: 0 eDram: 0 eUncore: 0) eGPU: 0 eOther: 0

# HELP kepler_node_core_joules_total Aggregated RAPL value in core in joules
# TYPE kepler_node_core_joules_total counter
kepler_node_core_joules_total{instance="jitest42.novalocal",mode="dynamic",package="0",source="rapl"} 0.07
kepler_node_core_joules_total{instance="jitest42.novalocal",mode="idle",package="0",source="rapl"} 0.17
# HELP kepler_node_dram_joules_total Aggregated RAPL value in dram in joules
# TYPE kepler_node_dram_joules_total counter
kepler_node_dram_joules_total{instance="jitest42.novalocal",mode="dynamic",package="0",source="rapl"} 685.851
kepler_node_dram_joules_total{instance="jitest42.novalocal",mode="idle",package="0",source="rapl"} 13.043
# HELP kepler_node_energy_stat Several labeled node metrics
# TYPE kepler_node_energy_stat counter
kepler_node_energy_stat{cpu_architecture="Haswell",node_block_devices_used="0",node_curr_bytes_read="0",node_curr_bytes_writes="0",node_curr_cache_miss="0",node_curr_container_cpu_usage_seconds_total="0",node_curr_container_memory_working_set_bytes="0",node_curr_cpu_cycles="0",node_curr_cpu_instr="0",node_curr_cpu_time="0",node_curr_energy_in_core_joule="0",node_curr_energy_in_dram_joule="0",node_curr_energy_in_gpu_joule="0",node_curr_energy_in_other_joule="0",node_curr_energy_in_pkg_joule="0",node_curr_energy_in_uncore_joule="0",node_name="jitest42.novalocal"} 0
# HELP kepler_node_nodeInfo Labeled node information
# TYPE kepler_node_nodeInfo counter
kepler_node_nodeInfo{cpu_architecture="Haswell"} 1
# HELP kepler_node_other_host_components_joules_total Aggregated RAPL value in other components (platform - package - dram) in joules
# TYPE kepler_node_other_host_components_joules_total counter
kepler_node_other_host_components_joules_total{instance="jitest42.novalocal",mode="dynamic"} 0
kepler_node_other_host_components_joules_total{instance="jitest42.novalocal",mode="idle"} 0
# HELP kepler_node_package_energy_millijoule Aggregated RAPL value in package (socket) in milijoules (deprecated)
# TYPE kepler_node_package_energy_millijoule counter
kepler_node_package_energy_millijoule{core="1",dram="121",instance="jitest42.novalocal",pkg_id="0",uncore="0"} 1
# HELP kepler_node_package_joules_total Aggregated RAPL value in package (socket) in joules
# TYPE kepler_node_package_joules_total counter
kepler_node_package_joules_total{instance="jitest42.novalocal",mode="dynamic",package="0",source="rapl"} 0.07
kepler_node_package_joules_total{instance="jitest42.novalocal",mode="idle",package="0",source="rapl"} 0.17
# HELP kepler_node_platform_joules_total Aggregated RAPL value in platform (entire node) in joules
# TYPE kepler_node_platform_joules_total counter
kepler_node_platform_joules_total{instance="jitest42.novalocal",mode="dynamic",source="acpi"} 0
kepler_node_platform_joules_total{instance="jitest42.novalocal",mode="idle",source="acpi"} 0
# HELP kepler_node_uncore_joules_total Aggregated RAPL value in uncore in joules
# TYPE kepler_node_uncore_joules_total counter
kepler_node_uncore_joules_total{instance="jitest42.novalocal",mode="dynamic",package="0",source="rapl"} 0
kepler_node_uncore_joules_total{instance="jitest42.novalocal",mode="idle",package="0",source="rapl"} 0

I am using a VM seems we have multiple values but not sure why logs report all 0 though..

the other domain is from power meter, and uncore domain is for intel gpu, it is not a surprise to see they are 0

but ePkg: 0 (eCore: 0 eDram: 0 eUncore: 0)  this seems incorrect to me ..

The log message might come from rapl reading (which is absent on VMs), the value in the metrics are from model based estimate.

ok, but previously it's not in the exact same env I am using ..
will check more and see whether I can see any clue

One clue to investigate is: prometheus shows aggregated values and the logs are probably the delta values.


[USERSNAP] I have not had any success getting my wallet to connect and show proper balance.  I have registered multiple times as a Drep and it never holds.  Today I cannot reregister because it shows UTXO balance insufficient

Sender: None
Taken at: https://sanchogov.tools/dashboard
Fields:

Add a comment: I have not had any success getting my wallet to connect and show proper balance.  I have registered multiple times as a Drep and it never holds.  Today I cannot reregister because it shows UTXO balance insufficient

Browser: Chrome 122 (macOS Catalina)
Screen size: 1440x900
Open #44 in Usersnap
Powered by Usersnap.

@kickloop I can do nothing here. Why is this assigned to me?


Update README.md

This is a comment Template
when sending a createComment request and passing parameters in the json request at run-time these values will be replaced with the content of the given values
{
  "owner": "scalecube",
  "repo": "status-checks",
  "issue_number": 1,
  "template_url": "https://raw.githubusercontent.com/scalecube/github-gateway/test1/src/examples/comment-template.md",
  "a-param": "some value"
}

here is example a-param value: some value

This is a comment Template
when sending a createComment request and passing parameters in the json request at run-time these values will be replaced with the content of the given values
{
  "owner":"scalecube",
  "repo":"github-gateway",
  "issue_number":1,

  "a-param":"some value",

  "path":"src/examples/comment-template.md",
  "url":"https://raw.githubusercontent.com/scalecube/github-gateway/test1/src/examples/comment-template.md",
  "data":"comment data example some value"
}

here is example a-param value: ${a-param}

This is a comment Template
when sending a createComment request and passing parameters in the json request at run-time these values will be replaced with the content of the given values
{
  "owner":"scalecube",
  "repo":"github-gateway",
  "issue_number":1,

  "a-param":"some value",

  "path":"src/examples/comment-template.md",
  "url":"https://raw.githubusercontent.com/scalecube/github-gateway/test1/src/examples/comment-template.md",
  "data":"comment data example some value"
}

here is example a-param value: ${a-param}

This is a comment Template
when sending a createComment request and passing parameters in the json request at run-time these values will be replaced with the content of the given values
{
  "owner":"scalecube",
  "repo":"github-gateway",
  "issue_number":1,

  "a-param":"some value",

  "path":"src/examples/comment-template.md",
  "url":"https://raw.githubusercontent.com/scalecube/github-gateway/test1/src/examples/comment-template.md",
  "data":"comment data example some value"
}

here is example a-param value: ${a-param}


[SPARK-44496][SQL][CONNECT] Move Interfaces needed by SCSC to sql/api

What changes were proposed in this pull request?

This PR moves some interfaces and utils that are needed by scala client to sql/api.
Why are the changes needed?

So that scala client does not need to depend on Spark.
Does this PR introduce any user-facing change?

No
How was this patch tested?

UT

LGTM cc @bogao007 We need to do the same for Streaming. I recall you put a few in connect-common, we shall move them out too.

Sure, will do the same, thanks!

Merging!


ISPN-8222 Jenkins should archive all logs

https://issues.jboss.org/browse/ISPN-8222

Just some numbers for comparison:

PR-5390 archive takes 18 MB
this PR takes 19 MB

So we should be good in terms of disk space. @danberindei Good job with xz compression!

Integrated, thanks Sebastian!


MLHR-1748 Created concrete input and output operators for Redis Store

Added test cases for the same.

Please close this pull request and create a new one against 3.1.0

Addressed all the review comments. Will open a pull request against v3.1.9. Closing this one.


bumped Gradle wrapper version to 6.2

close this PR due to similar changes have been applied in https://github.com/streem/react-native-select-contact/pull/27


common api changes

Changes

pinpoint_add_clues
pinpoint_add_clue
pinpoint_set_context_key

key, must not start-with ":"
api https://github.com/pinpoint-apm/pinpoint-c-agent/blob/dev/common/include/common.h.in

close as done


function calls mismatched dict names

I have been reproduced your code and it failed here and I find that the code below is mismatched in dict names
from collections import defaultdict

# keys are interests, values are lists of user_ids with that interest
user_ids_by_interest = defaultdict(list)

for user_id, interest in interests:
    user_ids_by_interest[interest].append(user_id)

# keys are user_ids, values are lists of interests for that user_id
interests_by_user_id = defaultdict(list)

for user_id, interest in interests:
    interests_by_user_id[user_id].append(interest)

def most_common_interests_with(user_id):
    return Counter(interested_user_id
        for interest in interests_by_user["user_id"]
        for interested_user_id in users_by_interest[interest]
        if interested_user_id != user_id)

Generally, the problem happens in function most_common_interests_with(user_id)
and when  most_common_interests_with(user_id) calls dict above it shoulbe be user_ids_by_interest  not  users_by_interest and interests_by_user_id  not interests_by_user.
But even if I have rewritten the code the code above produce no results

The output is like this:
most_common_interests_with(1)
Out[88]: Counter()

Which is quit strange!

Indeed， the right code should be the following format:
def most_common_interests_with(user_id):
    return Counter(interested_user_id
        for interest in interests_by_user_id[user_id]
        for interested_user_id in user_ids_by_interest[interest]
        if interested_user_id != user_id)


Wifi disconnect after 17f01eb

This happens at about the same test sequence when #1588 used to happen,
but beginning with commit 17f01eb the symptom changed to a wifi connectivity loss:
I (650152) wifi: bcn_timout,ap_probe_send_start
I (652652) wifi: ap_probe_send over, resett wifi status to disassoc
I (652652) wifi: state: run -> init (1)
I (652652) wifi: pm stop, total sleep time: 0/649197264

I (652652) wifi: n:2 0, o:2 1, ap:255 255, sta:2 1, prof:1
I (652662) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (655082) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (657492) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (659902) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (662322) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (664732) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (664852) wifi: n:2 1, o:2 0, ap:255 255, sta:2 1, prof:1
I (664852) wifi: state: init -> auth (b0)
I (664862) wifi: state: auth -> assoc (0)
I (664862) wifi: state: assoc -> run (10)
I (664862) wifi: connected with TP-LINK_FF3107, channel 2
I (664872) event: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
I (664872) OPC: SYSTEM_EVENT_STA_GOT_IP
I (664882) OPC: got ip:<IP_ADDRESS>

I (667862) wifi: pm start, type:0

I (671752) wifi: bcn_timout,ap_probe_send_start
I (674252) wifi: ap_probe_send over, resett wifi status to disassoc
I (674252) wifi: state: run -> init (1)
I (674252) wifi: pm stop, total sleep time: 0/6392380

I (674252) wifi: n:2 0, o:2 1, ap:255 255, sta:2 1, prof:1
I (674262) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (676682) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (679092) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (681512) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (683922) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (686332) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (688752) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (691162) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (693572) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (695992) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (698402) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (700812) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (703222) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (705642) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (708052) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (710462) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (712882) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (715292) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (717702) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (720112) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (722532) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (724942) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (727352) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (727482) wifi: n:2 1, o:2 0, ap:255 255, sta:2 1, prof:1
I (727482) wifi: state: init -> auth (b0)
I (727482) wifi: state: auth -> assoc (0)
I (727482) wifi: state: assoc -> run (10)
I (727492) wifi: connected with TP-LINK_FF3107, channel 2
I (727492) event: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
I (727492) OPC: SYSTEM_EVENT_STA_GOT_IP
I (727502) OPC: got ip:<IP_ADDRESS>

I (730492) wifi: pm start, type:0

I (749282) wifi: bcn_timout,ap_probe_send_start
I (751782) wifi: ap_probe_send over, resett wifi status to disassoc
I (751782) wifi: state: run -> init (1)
I (751782) wifi: pm stop, total sleep time: 0/21294281

I (751782) wifi: n:2 0, o:2 1, ap:255 255, sta:2 1, prof:1
I (751792) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (754212) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (756622) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (759032) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (761442) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (763862) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (766272) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (768682) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (771102) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (772472) event: station ip lost
I (773512) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (775922) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (778332) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (780752) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (783162) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (785572) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (787992) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (790402) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (792812) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (795222) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (797642) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (800052) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (802462) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (804882) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (807292) OPC: SYSTEM_EVENT_STA_DISCONNECTED
I (807412) wifi: n:2 1, o:2 0, ap:255 255, sta:2 1, prof:1
I (807412) wifi: state: init -> auth (b0)
I (807422) wifi: state: auth -> assoc (0)
I (807422) wifi: state: assoc -> run (10)
I (807432) wifi: connected with TP-LINK_FF3107, channel 2
I (807432) event: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
I (807432) OPC: SYSTEM_EVENT_STA_GOT_IP
I (807432) OPC: got ip:<IP_ADDRESS>

I (810432) wifi: pm start, type:0

The Messages with OPC are from my code:
static const char *TAG = "OPC";
static esp_err_t event_handler(void *ctx, system_event_t *event)
{
    switch(event->event_id) {
    case SYSTEM_EVENT_STA_START:
        ESP_LOGI(TAG, "SYSTEM_EVENT_STA_START");
        ESP_ERROR_CHECK(esp_wifi_connect());
        break;
    case SYSTEM_EVENT_STA_GOT_IP:
        ESP_LOGI(TAG, "SYSTEM_EVENT_STA_GOT_IP");
        ESP_LOGI(TAG, "got ip:%s\n",
                ip4addr_ntoa(&event->event_info.got_ip.ip_info.ip));
        break;
    case SYSTEM_EVENT_STA_DISCONNECTED:
        ESP_LOGI(TAG, "SYSTEM_EVENT_STA_DISCONNECTED");
        ESP_ERROR_CHECK(esp_wifi_connect());
        break;
    default:
        break;
    }
    return ESP_OK;
}
...
ESP_ERROR_CHECK(esp_event_loop_init(event_handler, NULL));

My Setup uses spi ram, and a non-encrypted WiFi AP for simplicity.
This seems to happen at about the same time when previously #1588 used to happen.

Hi @jack0c,
I just noticed that your commit 3756e0c from yesterday appears to have fixed the
WiFi disconnects that I had observed previously.
That means, up to 35de8d7 this was still reproducible.
From the commit message it is not clear if this expected:
"esp32: fix esp_wifi_deinit causes assert"
I did not programmatically shut down the WiFi connection at all.
Just start it, and use if for a while.

@bernd-edlinger Thank you for updating. @TimXia please follow to find the root cause after Chinese New Year.

Hi @bernd-edlinger  what do you mean by saying "Just start it, and use if for a while"? Do you call esp_wifi_deinit in your application?

@bernd-edlinger How often does the issue happen? Will it happen if your device connects to other routers?

Do you call esp_wifi_deinit in your application?

No, never.
This is the initalization code I call only once on startup:
/*init wifi as sta and set scan method*/
static void wifi_init(void)
{
    tcpip_adapter_init();
    ESP_ERROR_CHECK(tcpip_adapter_dhcpc_stop(ESP_IF_WIFI_STA));
    tcpip_adapter_ip_info_t ip_config;
    IP4_ADDR (&ip_config.ip, 192, 168, 1, 100);
    IP4_ADDR (&ip_config.netmask, 255, 255, 255, 0);
    IP4_ADDR (&ip_config.gw, 192, 168, 1, 1);
    ESP_ERROR_CHECK(tcpip_adapter_set_ip_info(ESP_IF_WIFI_STA, &ip_config));
    ESP_ERROR_CHECK(esp_event_loop_init(event_handler, NULL));

    wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
    ESP_ERROR_CHECK(esp_wifi_init(&cfg));
    wifi_config_t wifi_config = {
        .sta = {
            .ssid = CONFIG_WIFI_SSID,
            .password = CONFIG_WIFI_PASSWORD,
            .scan_method = WIFI_FAST_SCAN,
            .sort_method = WIFI_CONNECT_AP_BY_SIGNAL,
            .threshold.rssi = -127,
            .threshold.authmode = WIFI_AUTH_OPEN,
        },
    };
    ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA));
    ESP_ERROR_CHECK(esp_wifi_set_config(ESP_IF_WIFI_STA, &wifi_config));
    ESP_ERROR_CHECK(esp_wifi_start());
}

Except that I also initiallize NVS storage for calibration data,
intialize the fat file system, and write some data to it,
set the system time, and use mbed crypto functions.
Enable H/W support for mbed (RSA, SHA, AES)
Set the CPU speed to 240 MHz, Compile with -Os.
My application just initializes and then it uses TCP for OPC/UA.
The failure happens right in the middle of my test sequence,
at a time where a lot of short-lived tcp sockets enter time-wait2
state, at which point the low memory is used up, and the external
memory is about to be used for the first time.
This most interesting thing is that without the fix for #1588 in place
the WiFi connection breakdown prevents the other bug.
My application opens a file after each connection attempt,
and #1588 made the open function crash when the internal
mutex was allocated from ext memory.
So I assume some memory was allocated for WiFi from the
external memory instead of internal memory which made the
WiFi connectivity break down.

How often does the issue happen? Will it happen if your device connects to other routers?

Unfortunately I have no other access points to try it out.
I used a "TP-LINK TL-WA701ND 150Mbps Wireless Lite N Access point"
Right out of the box, that means I did not change anything from the factory configuration
including the SSID, it was configured to "TP-LINK_FF3107" by the factory.

Hi @bernd-edlinger, just investigate this issue again, I think 3756e0c should be the solution for this issue. In 17f01eb a new issue is introduced, the WiFi driver allocates all frame buffer from internal memory, but it should allocate RX buffer from external memory firstly if external memory feature is enabled. Because of this, the internal memory may not enough for WiFi connection, 3756e0c fix s this issue.  Need you help to confirm that commit 3756e0c do solve your problem, otherwise we need to further investigate it.

No, that's fine, my tests indicated the same. I just wanted to make sure the issue was actually
solved and understood, and not only hidden by an unrelated change, so it won't pop up again.


nni Kubeflow/trial keeper err

Short summary about the issue/question:

Trial keeper takes around 10 minutes to exit after the trial is finished.
Outputting logs in trial makes the trial 6X slower than the one that does not output logs.
The error message (at TLSWrap.onStreamRead)

Brief what process you are following:
run nni in kubeflow

How to reproduce it:

nni Environment:

nni version: 0.8
nni mode(local|pai|remote): kubeflow
OS: Linux
python version: 3
is conda or virtualenv used?:
is running in docker?:

need to update document(yes/no):
Anything else we need to know:

issue 1: unable to replay
issue 2: what does it mean 'add log in trial' ?

issue 3 : same with #1261

fixed by disable logCollection by default.


[rt.openssl.org #3881] [PATCH] Instrument OpenSSL buffer heap memory usage

Migrated from rt.openssl.org#3881 (status was 'new')
Requestors:

<EMAIL_ADDRESS>
Attachments:

0022-Instrument-OpenSSL-buffer-heap-memory-usage.patch
0021-RT3881-Instrument-OpenSSL-buffer-heap-memory-usage.patch
ATT00001.htm

From<EMAIL_ADDRESS>on 2015-05-30 07:47:58:
Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description:  Instrument OpenSSL buffer heap memory usage

Added function to register callbacks to allocate and free data buffers.

These callbacks can then allocate and free the memory as needed, while
also recording buffer allocations.

This permits a user-definable implementation of FREE_BUFLIST, which has been removed.

(Yes, documentation is lacking at this point).

Github link:

https://github.com/akamai/openssl/commit/4a6d71bbd2f4fe38ebcbe2f9917a1c7fedd117f8

And attachment.

Thank you.
--
-Todd Short
//<EMAIL_ADDRESS>// âOne if by land, two if by sea, three if by the Internet.â

From<EMAIL_ADDRESS>on 2015-06-18 13:10:36:
Updates to the buffer heap memory usage patch:
Updated documentation.

Github link:
https://github.com/akamai/openssl/commit/222f0d2d94be8b92c306c062320fd15b59a9000a

And attached file.

Thank you,

--
-Todd Short
// tshort<EMAIL_ADDRESS>// "One if by land, two if by sea, three if by the Internet."

On May 30, 2015, at 3:48 AM, Joy Tu via RT <rt<EMAIL_ADDRESS>wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description:  Instrument OpenSSL buffer heap memory usage

Added function to register callbacks to allocate and free data buffers.

These callbacks can then allocate and free the memory as needed, while
also recording buffer allocations.

This permits a user-definable implementation of FREE_BUFLIST, which has been removed.

(Yes, documentation is lacking at this point).

Github link:

https://github.com/akamai/openssl/commit/4a6d71bbd2f4fe38ebcbe2f9917a1c7fedd117f8

And attachment.

Thank you.
--
-Todd Short
//<EMAIL_ADDRESS>// âOne if by land, two if by sea, three if by the Internet.â

<0022-Instrument-OpenSSL-buffer-heap-memory-usage.patch>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

closing this; @tmshort if you are still interested, consider making a PR.


GitMaintenanceStep: delete commit-graphs folder before rewriting

If "git commit-graph verify" fails, we call the method
LogErrorAndRewritecommitGraph(). This is supposed to get us
into a better state. It appears that it is not doing that
when we have an issue around our incremental commit-graph
format.
Fix that by deleting the commit-graphs folder in addition to
the commit-graph file. Report the status of the call, so we
know if we had such a folder.

/azp run GitHub VFSForGit Mac Functional Tests

/azp run GitHub VFSForGit Mac Functional Tests

/azp run GitHub VFSForGit Mac Functional Tests


Fix web api wrapper

The Web api wrapper is not generic at all and any new features require adding lots of parameters to its methods. It should instead be identical to the flask app, but operate on a path instead.

See if flask's instance_path is what we want...

import flask
from werkzeug.wsgi import DispatcherMiddleware
from werkzeug.serving import run_simple
main_app = flask.Flask(__name__)

aggregated_app = DispatcherMiddleware(main_app,
    { module.base_path: flask.Flask(module.name) for module in modules }
)

run_simple('<IP_ADDRESS>', '8080', aggregated_app)

This does exactly what we need and allows removing a ton of dumb code


Create X-YZ decomposer for quantify-scheduler

Quantify-scheduler's gate library supports RZ and RXY. This last gate can represent any bloch sphere rotation of any angle provided the axis is in the plan (X, Y).
Currently we use the ZYZ decomposition to decompose gates for quantify-scheduler. This requires 3 gates.
But since QS supports RXY, it is possible that in a lot (all?) cases, only 2 of those gates are required to describe an arbitrary single-qubit unitary.
Goal of this issue:

investigate is there exists a mathematical unitary decomposition for 2x2 unitaries into either RZ.RXY or RXY.RZ
implement corresponding decomposer and use it for quantify-scheduler

There is ZX decomposition which may be interesting https://arxiv.org/pdf/1602.04744.pdf

This requires a defined RXY gate in the gate definitions

OK, but we can leave that out at the moment as an implementation detail.
I would focus on the first bullet: investigate if there exists a mathematical unitary decomposition for 2x2 unitaries into either RZ.RXY or RXY.RZ.


Use LongAdder or volatile long to replace AtomicLong in some scenarios

Proposed changes
This PR is to use LongAdder or volatile long to replace AtomicLong in some scenarios.
In the statistical summation scenario, LongAdder(introduced by jdk1.8) has better performance than AtomicLong in high concurrency update scenario. And if we just want to keep get and set operation for variable to be atomic, just add volatile at the front of the variable is enough, use AtomicLong is a little heavy.
Types of changes
What types of changes does your code introduce to Doris?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have create an issue on #4132 , and have described the bug/feature there in detail
[ ] Commit messages in my PR start with the related issues ID, like "#4071 Add pull request template to doris project"
[x] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If this change need a document change, I have updated the document
[ ] Any dependent changes have been merged

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

for #4132

@caiconghui Hi，how many performance improvement this PR will get?

@caiconghui Hi，how many performance improvement this PR will get?
@kangkaisen
for single AtomicLong value and single LongAdder value, i test increment opertion with 30 threads in 2 seconds in my macbook, and I find the Throughput increased by about 60%  when i used LongAdder instead of AtomicLong.

as for volatile long and AtomicLong, the performance is almost same, but if volatile can be enough to ensure thread-safe, then we should take a more lightweight solution.

@caiconghui Hi，how many performance improvement this PR will get?
@kangkaisen
for single AtomicLong value and single LongAdder value, i test increment opertion with 30 threads in 2 seconds in my macbook, and I find the Throughput increased by about 60%  when i used LongAdder instead of AtomicLong.

as for volatile long and AtomicLong, the performance is almost same, but if volatile can be enough to ensure thread-safe, then we should take a more lightweight solution.

OK


Spurious warning: division by zero is undefined on K_THREAD_DEFINE when building with clang

Describe the bug
Hi, bumped into this compiler warning on K_THREAD_DEFINE since https://github.com/zephyrproject-rtos/zephyr/pull/62900 got merged. One of our project that is building for an stm32 with LLVM started failing with a compiler warning:
/mnt/host/source/src/platform/ec/zephyr/shim/src/tasks.c:51:1251: error: division by zero is undefined [-Werror,-Wdivision-by-zero]
 struct z_thread_stack_element __attribute__((section("." "noinit" "." "\"EC_BASE/ec/zephyr/shim/src/tasks.c\"" "." "21"))) __attribute__((__aligned__(((((0x40) > (0)) ? (0x40) : (0)))))) _k_thread_stack_RWSIG[(((((unsigned long)(1536) + ((unsigned long)(8) - 1)) / (unsigned long)(8)) * (unsigned long)(8)) + ((size_t)0x40))]; struct k_thread _k_thread_obj_RWSIG; __attribute__((__aligned__(__alignof(struct _static_thread_data)))) struct _static_thread_data _k_thread_data_RWSIG __attribute__((section("." "__static_thread_data" "." "static" "." "_k_thread_data_RWSIG_"))) __attribute__((__used__)) = { .init_thread = (&_k_thread_obj_RWSIG), .init_stack = (_k_thread_stack_RWSIG), .init_stack_size = (1536), .init_entry = (k_thread_entry_t)rwsig_task, .init_p1 = (void *)0, .init_p2 = (void *)((void*)0), .init_p3 = (void *)((void*)0), .init_prio = ((EC_TASK_PRIO_COUNT - EC_TASK_RWSIG_PRIO - 1)), .init_options = (0), .init_delay = ((k_timeout_t) { .ticks = (((-1)) == (-1) ? ((k_ticks_t) -1) : ((k_ticks_t)((1) ? ( ((10000) == (1000)) ? (uint64_t) (((((-1)) > (0)) ? ((-1)) : (0))) : ((1000) > (10000) && (1000) % (10000) == 0U) ? ((uint64_t) (((((-1)) > (0)) ? ((-1)) : (0))) + ((0) ? ((1000) / (10000)) / 2 : (1) ? ((1000) / (10000)) - 1 : 0)) / ((1000) / (10000)) : ((10000) > (1000) && (10000) % (1000) == 0U) ? (uint64_t) (((((-1)) > (0)) ? ((-1)) : (0)))*((10000) / (1000)) : ((((((365 * 24ULL * 3600ULL * 1000) +<PHONE_NUMBER>U) - 1) /<PHONE_NUMBER>U)) * 10000) <=<PHONE_NUMBER>U) ? (((uint64_t) (((((-1)) > (0)) ? ((-1)) : (0)))*(10000) + ((0) ? (1000) / 2 : (1) ? (1000) - 1 : 0)) / (1000)) : (((uint64_t) (((((-1)) > (0)) ? ((-1)) : (0))) / (1000))*(10000) + (((uint64_t) (((((-1)) > (0)) ? ((-1)) : (0))) % (1000))*(10000) + ((0) ? (1000) / 2 : (1) ? (1000) - 1 : 0)) / (1000))) ) : (((uint64_t) (((((-1)) > (0)) ? ((-1)) : (0))) / (1000))*(10000) + (((uint64_t) (((((-1)) > (0)) ? ((-1)) : (0))) % (1000))*(10000) + ((0) ? (1000) / 2 : (1) ? (1000) - 1 : 0)) / (1000)) ))) }), .init_name = "RWSIG", }; const k_tid_t RWSIG = (k_tid_t)&_k_thread_obj_RWSIG;
                                                                                ^ ~~~~~~~~~~~~~~~~~~

The cause seems to be the introduction of SYS_TIMEOUT_MS in Z_THREAD_INITIALIZER, the macro eventually expands into some call of z_tmcvt_64 which includes a / (Z_HZ_ms / Z_HZ_cyc), that becomes a / 0 in most tickless setups since Z_HZ_ms = 1000 and Z_HZ_cyc = CONFIG_SYS_CLOCK_TICKS_PER_SEC = 10000. The ternary picks the valid value and GCC is happy with that, but clang seems to be firing a warning.
I managed to reproduce this with this example:
#include <stdio.h>

int ticks = 0 ? 1 / 0 : 0 ;

int main(int argc, char **argv)
{
        printf("%d\n", ticks);
}

$ gcc -Wall -o test test.c
$ clang -Wall -o test test.c
test.c:3:19: warning: division by zero is undefined [-Wdivision-by-zero]
int ticks = 0 ? 1 / 0 : 0 ;
                  ^ ~
1 warning generated.

Note that for some reason the warning does not fire if the condition is moved inside the function.
The CI did not catch it because the clang build that we run is all for native_posix and runs with SYS_CLOCK_TICKS_PER_SEC = 100, but this can be reproduced upstream fairly easily with:
$ export ZEPHYR_TOOLCHAIN_VARIANT=llvm
$ west build -p -b native_posix_64 samples/basic/threads -DCONFIG_SYS_CLOCK_TICKS_PER_SEC=10000
...
/usr/local/google/home/fabiobaltieri/zephyrproject/zephyr/samples/basic/threads/src/main.c:111:1: warning: division by zero is undefined [-Wdivision-by-zero]
K_THREAD_DEFINE(blink0_id, STACKSIZE, blink0, NULL, NULL, NULL,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

To get around this in our application we ended up selectively disabling the warning (https://chromium-review.googlesource.com/4907933), but that's obviously not a scalable workaround. Unfortunately the way our CI is setup does not give us much visibility into it, but there's probably many users compling with clang for tickless systems and I think this should be looked into before the release.
I tried to look into the https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/sys/time_units.h definitions but can't quite see a decent workaround, looking for more ideas around this.
To Reproduce
$ export ZEPHYR_TOOLCHAIN_VARIANT=llvm
$ west build -p -b native_posix_64 samples/basic/threads -DCONFIG_SYS_CLOCK_TICKS_PER_SEC=10000

Expected behavior
No warning
Impact
Build fail if warning as treated as errors.
Environment (please complete the following information):

OS: Linux
Toolchain: clang 14.0.6 and 17.0.0

cc @keith-packard @andyross @nashif @ceolin @dcpleung @peter-mitsis @cfriedt

I would suggest reverting for now. Can respond after the release

I would suggest reverting for now. Can respond after the release

It's certainly an option but let's hear what the author and reviewers think about it, if can come up with a workaround before RC2 I think we should give it a go.

Maybe we can just cap that fraction result to a minimum of 1?
--- a/include/zephyr/sys/time_units.h
+++ b/include/zephyr/sys/time_units.h
@@ -175,7 +175,7 @@ static TIME_CONSTEXPR inline int sys_clock_hw_cycles_per_sec(void)
 #define z_tmcvt_int_div_64(__t, __from_hz, __to_hz, __round_up, __round_off) \
        ((uint64_t) (__t) + z_tmcvt_off_div(__from_hz, __to_hz,         \
                                            __round_up, __round_off)) / \
-       ((__from_hz) / (__to_hz))
+       (MAX((__from_hz) / (__to_hz), 1))

 /* Integer multiplcation 64-bit conversion */
 #define z_tmcvt_int_mul_64(__t, __from_hz, __to_hz)    \

I'll open a PR see if that would pass CI.

The logic should be using a multiply instead of divide for this case -- * (Z_HZ_cyc / Z_HZ_ms) instead of / (Z_HZ_ms / Z_HZ_cyc). Sounds like it should also be fairly easy to fix once I figure out why it did the wrong thing :-)

Ok it looks like there's more into it -- I closed https://github.com/zephyrproject-rtos/zephyr/pull/63580, will let you come up with the right fix before I mess things up even more. :-)

once I figure out why it did the wrong thing :-)

@keith-packard I think it does the right thing, the problem seems to be a compiler artifact as the nice example @fabiobaltieri constructed shows:

int ticks = 0 ? 1 / 0 : 0 ;

Found https://stackoverflow.com/questions/26923182/how-to-eliminate-divide-by-0-error-in-template-code - maybe related?
I agree this should be easy to fix this. Already started experimenting...

As far as I can determine, the compiler is complaining about a divide-by-zero in a branch which will not be taken.
Take a look at this code:
int i = (10 > 100 ? (20 / (10 / 100)) : (20 * (100 / 10)));

$ clang -c -O2 -Wall -Wextra foo.c
foo.c:1:25: warning: division by zero is undefined [-Wdivision-by-zero]
int i = (10 > 100 ? (20 / (10 / 100)) : (20 * (100 / 10)));
                        ^ ~~~~~~~~~~
1 warning generated.

I've submitted a PR which works around the warning by using 1 when the value would be zero. It cannot affect the result
because this code is in a conditional branch where from_hz (1000) is strictly greater than to_hz (10000).

As far as I can determine, the compiler is complaining about a divide-by-zero in a branch which will not be taken.

Yes that is the case in my tests (the build fails with a different error if that branch is taken), and from my understanding the condition it cannot be taken in any case.

As far as I can determine, the compiler is complaining about a divide-by-zero in a branch which will not be taken.

Exactly!
To me this looks like a bug in CLang: See https://stackoverflow.com/questions/18385020/can-code-that-will-never-be-executed-invoke-undefined-behavior

To me this looks like a bug in CLang: See https://stackoverflow.com/questions/18385020/can-code-that-will-never-be-executed-invoke-undefined-behavior

Yeah, thinking about this again, the C 'short circuit' rules apply to the conditional operator which means that the undefined operation (divide by zero) will not happen, and hence the program is not invoking undefined behavior.
It's no different from using an if statement to protect the division operation.

It's no different from using an if statement to protect the division operation.

Haha, my example in https://github.com/llvm/llvm-project/issues/68339

It's no different from using an if statement to protect the division operation.

Haha, my example in llvm/llvm-project#68339 - first time ever I open a bug against a compiler, probably quite ingenuous on my part. Let's see whether they laugh at me...

I'd bet they'll come back with chapter-and-verse from the standard explaining why the compiler should work this way. That's the usual result of filing compiler issues.

I'd bet they'll come back with chapter-and-verse from the standard

Nope - we just earned a "confirmed" label - see https://github.com/llvm/llvm-project/issues/68339
Nice.

The warning is back. Bigger hammer submitted:

https://github.com/zephyrproject-rtos/zephyr/pull/65953


Fix version 2.1 release note regarding TF_DETERMINISTIC_OPS

This current pull request is intentionally aimed at the r2.1 branch.
This current pull request is a follow-up to PR 34887. Unfortunately, I didn't review the rendered markdown for those changes before submitting the PR.
This PR:

Changes the indent of the note about TF_DETERMINISTIC_OPS so that it doesn't appear to be related to TensorRT.
Escapes the use of * twice in the markdown, which was previously interpreted as intending to signal emphasis.
Adds some improvements to clarity.

Requesting review by @sanjoy, who reviewed the original PR.

This PR has been ready to merge for 9 days. Please will someone merge it?

Apologies, we didn't merge any PRs on the branch this week as we were debugging several segfaults caused by scipy/scipy#11237
We will start merging PRs in a while, when we finish this debugging process

@duncanriach sorry for the delay in merging the PR's. we have been debugging seg fault issues with scipy and hence the delay. Should be merged in soon.

@goldiegadde, thanks for the update and thanks for the merge.


Define controller as service

I have method "UpdateStateToPaymentProgress" inside controller
public function UpdateStateToPaymentProgress(Cart $cart, $state)
    {
        $dm = $this->getDocumentManager();
        $cart->setState($state);
        $dm->persist($cart);
        $dm->flush();
    }

This is my config file
(...)
transitions:
            create:
                from: [new]
                to: created
            payment:
                from: [created]
                to:   progressPayment
(...)
callbacks:
            # will be called after applying a transition
            after:
                progress_pay_cart:
                    on:   'payment'
                    do<EMAIL_ADDRESS>'UpdateStateToPaymentProgress']
                    args: ['object', '"progressPayment"']

i define controller as service in service.yml
services:
    application.cart.checkout:
        class:     Application\CartBundle\Controller\CheckoutController

the problem is when i call method $cartSM->apply('payment') , the entity dont change state, and the bundle dnt call method of controller.

Hi,
On which object are you applying the payment transition? It seems it is on your $cart, but I don't see why you use this callback that just updates the state: the SM will update the state itself!


Bug: Hardcoded pingone.com address in multiple files.  Repo will not work for EU, AP, CA regions

Files containing pingone.com:

/davinci-api-registration-pkg/davinci-api-registration-sample-app/dashboard.html
/davinci-api-registration-pkg/davinci-api-registration-sample-app/index.html
/davinci-api-registration-pkg/terraform/davinci.tf
/davinci-api-risk-pkg/davinci-api-risk-sample-app/dashboard.html
/davinci-api-risk-pkg/davinci-api-risk-sample-app/index.html
/davinci-api-risk-pkg/terraform/davinci.tf
/davinci-registration-pkg/davinci-registration-sample-app/dashboard.html
/davinci-registration-pkg/davinci-registration-sample-app/index.html
/davinci-registration-pkg/terraform/davinci.tf
/davinci-sso-protect-pkg/davinci-sso-protect-sample-app/dashboard.html
/davinci-sso-protect-pkg/davinci-sso-protect-sample-app/index.html
/davinci-sso-protect-pkg/terraform/data.tf
/davinci-sso-protect-pkg/terraform/davinci-sso-protect-flow.json
/davinci-sso-protect-pkg/terraform/davinci.tf
/oidc-sdk-pkg/oidc-sdk-sample-app/dashboard.html
/oidc-sdk-pkg/oidc-sdk-sample-app/index.html
/oidc-sdk-pkg/terraform/data.tf
/ping-one-protect-pkg/ping-one-protect-sample-app/public/index.html
/ping-one-protect-pkg/ping-one-protect-sample-app/server.js
/ping-one-protect-pkg/terraform/data.tf

@patrickcping this is being resolved today so we can get it into the Thursday release. #186124060. @zhannaavanesova  is working it.

This issue was resolved with our latest release v1.4.0.


ci: support test coverage

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[ ] N
[X] Y

fix #4

2. What is the scope of this PR (e.g. component or file name):
support test coverage in ci

Makefile
.github/workflows/main_linux.yml

3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[X] Other

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

[X] N
[ ] Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[X] Other

the CI  pipeline itself

6. Release note

Please refer to Release Notes Language Style Guide to write a quality release note.
None

this is a pure Go project, the makefile must be simple or be deleted.

Makefile simplified, ptal


Display the coverage only for main project targets

This adds an option which being set ignores the targets of auxiliary projects in a workspace.
For example, by setting --only_project_targets, xcov will ignore Pods targets.

Hi @thelvis4 :wave:
Great stuff! I'll take a deeper look today :)

Hi again @thelvis4 👋
After checking the PR I've realized that it's pretty similar to what @tapi implements on #46. I think we should go for his solution as it requires one less gem dependency and it doesn't rely on the assumption that the current folder matches the project root folder. What do you think?
Thanks once again for the contributions 🍻

Hi @nakiostudio
I have to admit that I developed this without looking at #46. 🙈
But I checked @tapi's solution now and seems like we try to solve the same issue in different ways.
Let's say we have this project structure:
Workspace

    Project
        AppTarget
        FrameworkTarget

    DependencyProject
        DependencyFramework

    Pods
        Alamofire
        GoogleAnalytics

With #46, you have to explicitly specify the targets you want to include. For example, you can have the coverage for AppTarget and for DependencyFramework and other targets will be ignored.
With this (#49) solution, you don't have to specify the targets and it gives you the coverage for all the targets from the project defined by the scheme.
For example, if scheme aims Project, you'll receive the coverage for AppTarget and FrameworkTarget. Other targets will be ignored.
Although #46 gives a more grained control over the included targets, it's pretty difficult to get use of it when you have to deal with multiple (and different) projects or when you want to make xcov part of a more complex and generalized script (like in my case :grin:).
This solution can serve as an alternative for this kind of scenarios.
I believe we can have both solutions (with some adaptations), as they are applicable for different scenarios. Probably, we'll have to add a conflicting_options clause to only_project_targets, because it makes sense to use just one of these solutions.
Notes:

it doesn't rely on the assumption that the current folder matches the project root folder.

Once the workspace and the scheme are provided, the (main) project path is taken from Build Settings (PROJECT_FILE_PATH). It doesn't rely on any assumption. The project can be located anywhere.

it requires one less gem dependency

Yeah, that's true. First, I tried to adapt fastlane_core so that we could get the targets using project.rb, but that breaks the flow fastlane_core depends on. 😞
So, I decided to use xcodeproj gem, which made easy to get needed information.

@nakiostudio I've rebased this so that it could be merged into upstream repository if you find it appropriate. ☺

@nakiostudio Now, that we depend on fastlane and fastlane depends on xcodeproj, I think we could merge this (after adding the conflicting_options clause).
What do you think?

@nakiostudio Ready to be merged! :shipit: 😊


Uploading flags image lead to 404 error

Hi guys could you please check link for image
https://res.cloudinary.com/dvbuhh0bl/image/upload/c_scale,h_15,w_15/v1495279723/default_tmey2r.png
HTTP ERROR 404
looks like something broken on server side. Thanks.

See here

If anyone wants to use a stable & maintained version.Flag issue is also fixed here. Please use this library
https://www.npmjs.com/package/ng-phone-number


Add support for custom headers

Fixes #8
This adds in a kwargs column_headers in various places to allow the headers in the output CSV to vary from the column names. The number of column headers must match the number of columns.
In addition to the tests I have updated the admin demo:

Default:

first_name
last_name
email
is_staff

Hugo
RB
<EMAIL_ADDRESS>True

Custom header:

given name
family name
email
is_staff

Hugo
RB
<EMAIL_ADDRESS>True

@tim-mccurrach with this in place we can replace custom_field_1 with whatever the actual field names are on a user-by-user basis.


Enable max length for textarea field

Issue: silverstripe/silverstripe-framework#7549

This should go against 4 branch as this is a new feature

@dhensby Thanks :) I'll move this to https://github.com/silverstripe/silverstripe-framework/pull/7677


Sashes are not available some times

Testing #117250

Move panel to right and adjust the width of the panel

🐛 Sashes are not available

Just like every splitview: sashes are not enabled because all views are at maximum size, since there's no capacity in the container to fit them all. Real issue is https://github.com/microsoft/vscode/issues/117049.


Update network-observability-managed-cli.md

The prometheus-config configmap contains CRLF instead of LF which issues in loading the configmap changes in deployment. Have replaced the CRLF with LF and committed the changes.
Previous configmap had CRLF which led to unsuccessful load of configmap and cilium Grafana dashboard had no metric, also cilium pods were not showing up Prometheus UP in targets, here is how the configmap looks when described:

Had to clean the configmap using the following command to convert CRLF to LF:
sed -i -E 's/[[:space:]]+$//g' prometheus-config
Post this the CRLF got removed from the configmap and led to successful load of configmap, here is how the configmap look when described subsequently:

After this the metrics are correctly populated in Grafana dashboard:

@asudbring
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

@pratiksharma-dev @asudbring - removing the indents causes the code to display outside the block... can you re-do this?

#hold-off

I'm going to review this with the PM and make changes in another PR.
#please-close


The docs link to github needs updating

In the readthedocs page - eg https://ipycanvas.readthedocs.io/en/latest/api.html?highlight=measure text#ipycanvas.canvas.Canvas.font, there is a link on the top right to the GitHub repository for the project.
This currently still refers to the old repository with the "This repository has been moved" note. Perhaps update this to the current project location?

Looking at https://github.com/jupyter-widgets-contrib/ipycanvas/blob/master/docs/conf.py - this appears to have the right path. Have the docs not been regenerated since that?

I presume this was the last build - https://readthedocs.org/projects/ipycanvas/builds/21398944/. Following the link back to github, it should have the right link - https://github.com/jupyter-widgets-contrib/ipycanvas/commit/b5cf121bc7bae9c8909dbb3e18a61c2591461d51#diff-85933aa74a2d66c3e4dcdf7a9ad8397f5a7971080d34ef1108296a7c6b69e7e3

This doc from the build - https://ipycanvas.readthedocs.io/en/master/ - has the right link. Ah - so latest is likely based on https://github.com/jupyter-widgets-contrib/ipycanvas/releases/tag/0.13.1? Releasing at some point would I presume make that the latest, and show the correct link. Fixing this requires a release only.

yeah, ran into that too
it'd help to have the default entry in readthedocs show the right link :)

This should now be fixed, thanks!


TST: CI reproducer for SkylakeX issue

Adds a CI reproducer for SciPy + OpenBLAS SkylakeX AVX linear algebra issue reported upstream in NumPy: https://github.com/numpy/numpy/issues/13401
This likely causes wheels linalg failures for NumPy 1.2.x and 1.3.x series on that particular architecture at the moment, so the purpose of the PR is to demonstrate that the failure happens under Intel SDE emulation of SkylakeX, and then demonstrate a fix by bumping OpenBLAS to the appropriate commit hash.
This mirrors my similar effort in NumPy, where the issue did indeed seem to be resolved by a more recent OpenBLAS--see there for more detailed discussion: https://github.com/numpy/numpy/pull/13466
Whether this ultimately belongs in SciPy repo or somewhere else in ecosystem is up to others to decide. There are some pertinent discussions / issues upstream in OpenBLAS as well.

Testing on my fork suggests that SciPy linalg tests will pass with the OpenBLAS version bump, even when SkylakeX is emulated. So, I've now pushed the version bump commit to this PR.
If the CI still agrees with that, I'll likely proceed with bumping the OpenBLAS version for wheels repo.

The regression guard is now in place in upstream CI, which is likely the best solution anyway for fast & automatic feedback on emulated SkylakeX arch issues at the source of development.
So this has served its purpose & can be closed.


warning when use get with only one arg and assign kwargs.

get('2017-07-03', tzinfo='Asia/Shanghai') will ignore tzinfo
silently, which makes us very confused.

In [1]: from arrow.api import get

In [2]: get('2017-01-01')
Out[2]: <Arrow [2017-01-01T00:00:00+00:00]>

In [3]: get('2017-01-01', tzinfo='Asia/Shanghai')
Out[3]: <Arrow [2017-01-01T00:00:00+00:00]>  # Not what I expacted

In [4]: get('2017-01-01', 'YYYY-MM-DD', tzinfo='Asia/Shanghai')
Out[4]: <Arrow [2017-01-01T00:00:00+08:00]>

better make a warning when use like that, so user can choose weather delete tzinfo or
use get('2017-07-03').replace(tzinfo='Asia/Shanghai')

Codecov Report

Merging #444 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #444   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          14     14
  Lines        3081   3092   +11
  Branches      226    227    +1
=====================================
+ Hits         3081   3092   +11

Impacted Files
Coverage Δ

arrow/factory.py
100% <100%> (ø)
:arrow_up:

tests/factory_tests.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fd723b4...8d34fb2. Read the comment docs.

With https://github.com/crsmithdev/arrow/pull/516, tzinfo is now respected in this case.
Thanks for the PR @laixintao, and sorry for the delay.


Extract ROIs from Raster detail view

This fixes the utils/endpoints we had for extracting regions from images and adds a new interface on the raster detail view page to select an ROI within the bounds of a raster and directly download that ROI.
Some things to address:

[ ] Can we add a toast to alert the user that their ROI is outside the bounds of the raster?

If accessing a large dataset remotely, this will not be very RESTful . In the future (with the new SPA frontend), we should have this tool utilize the ProcessedImage model and do this asynchronously with polling to see if the job is done.
Demo

UI
Produced ROI

Another UX issue I noticed is that it's not possible to clear an the ROI drawing off the map after it's created, unless you create a new one.

Ah good feedback. I add a new "Clear" button that will do that:


Added demographic data notebook from databank.worldbank.org

Added enhancement for #207.

This only seems to contain USA data.   Is it possible to add demographic data from all countries?

it should have data for all countries. Did you have a look at DATABANK_DEMOGRAPHICS?


check concepts and error messages

We should check the types of errors one gets when implementing incompatible traits (or when traits are missing), and see if we can improve the compiler messages somehow...
Also, we should check that all necessary compile-time checks are done (e.g., I think currently one could define a grid of dimension 4, for instance, when point coordinates return an array of size 4...)

Closing this, this should be fine...


Fix state.count as zero

Fix state in Why we need to pass a function to setState()

Thanks for PR


bump 0.9.15-2

bump 0.9.15-2

/ok-to-test-managed provider=aws sha=48aea51

/ok-to-test-managed provider=gcp sha=48aea51

/ok-to-test-managed provider=azure sha=48aea51

/ok-to-test-managed provider=azure sha=48aea51


Custom Copiers #5: New methods for MockExpecedCall and MockActualCall

This is finally what we are aiming at.
Attempt to break up the work by @jgonzalezdr and myself (#676 and #675) into smaller, more manageable chunks.

Closing these PRs as they are no longer needed.


Worker scale up issue "Waiting for kubelet,kube-proxy to start"

Hello,
After a Kubernetes deployment, when I do a worker scale up sometime the Worker still waiting for kubelet and kubeproxy service ("Waiting for kubelet,kube-proxy to start").
It's appear that the charm don't create some config file for those services (kube-proxyconfig, args service files etc)
Here it's the file with all log generated by "cdk-field-agent" results-2018-03-23-11-32-07.tar.gz
Before the scale up, I do a scale down so it's possible that one cdk component don't really clean his config and have an issue with an IP already known.
Thanks in advance,
Valentin

Seems to be a hostname issue. If I change the hostname of worker node, it starts working

@boucherv do you happen to use MAAS?

@hansbogert Yes! The name is the same after a scale down/scale up because we keep the machine in MAAS

It looks like cdk-addons.apply isn't being run on that worker, which means the snap isn't being configured. Not sure how this ties into the hostname being the same yet. I assume these machines are wiped before being recycled?

@hyperbolic2346 I tried both with "fresh"/wiped nodes as well as with MAAS nodes that were hosting multiple services and re-used them for the k8s-worker. Both of these types of nodes failed if the node was already used for the k8s-worker service -- at least that's seems to be the distinguishing factor. I do want to stipulate my previous comment:

Seems to be related to at least the hostname. If I change the hostname of worker node, it starts working

Seems to be related to at least the hostname. If I change the hostname of worker node, it starts working

Yes, I think this is the largest clue so far. I just wanted to make sure it was the hostname and not something latent on the filesystem. Thanks for the clarification.

I ran into the similar issue, after powering off and then powering on the worker. It ran ok before. After restarting all the servers, the master status became "Waiting for kube-system pods to start", and the worker status "Waiting for kubelet to start.". The system runs on MAAS.

I got a very similar problem today https://discourse.jujucharms.com/t/waiting-for-kubelet-kube-proxy-to-start/2036 that I still haven't managed to fix.

I am experiencing this issue too today

Seems to be related to at least the hostname. If I change the hostname of worker node, it starts working

Hi @hansbogert : can you please share more details about changing the hostname here? i.e from what to what?

@hyperbolic2346 can you please help?

my environment:
kubernetes-master      1.15.3   active           2  kubernetes-master      jujucharms  724  ubuntu
kubernetes-worker      1.15.4   waiting          2  kubernetes-worker      jujucharms  571  ubuntu  exposed

$ journalctl -u snap.kubelet.daemon.service
Sep 17 09:18:28 eager-grub kubelet.daemon[14384]: I0917 09:18:28.778113   14384 client.go:75] Connecting to docker on unix:///var/run/docker.sock
Sep 17 09:18:28 eager-grub kubelet.daemon[14384]: I0917 09:18:28.778233   14384 client.go:104] Start docker client with request timeout=2m0s
Sep 17 09:18:28 eager-grub kubelet.daemon[14384]: F0917 09:18:28.779493   14384 server.go:273] failed to run Kubelet: failed to create kubelet: failed to get docker version: Cannot connect to the Docker daemon at unix:///var/run/docker.s
Sep 17 09:18:28 eager-grub systemd[1]: snap.kubelet.daemon.service: Main process exited, code=exited, status=255/n/a
Sep 17 09:18:28 eager-grub systemd[1]: snap.kubelet.daemon.service: Failed with result 'exit-code'.
Sep 17 09:18:29 eager-grub systemd[1]: snap.kubelet.daemon.service: Service hold-off time over, scheduling restart.
Sep 17 09:18:29 eager-grub systemd[1]: snap.kubelet.daemon.service: Scheduled restart job, restart counter is at 3.
Sep 17 09:18:29 eager-grub systemd[1]: Stopped Service for snap application kubelet.daemon.
Sep 17 09:18:29 eager-grub systemd[1]: Started Service for snap application kubelet.daemon.

This could be https://bugs.launchpad.net/charm-kubernetes-worker/+bug/1839704

@SDAdham as mentioned earlier, the bug I and OP was hitting was fixed. Are you at the least using MAAS/Juju? Since that was part of the underlying problem. Don't fixate too much on the exact text of "Waiting for kubelet,kube-proxy to start", it can happen for a lot of reasons.


What does the query part map to? FROM or WHERE?

As far as I can tell it maps onto FROM, which means it limits a lot of functionality to filter notes down. Is my assumption correct?

It can be answered. You use the pages function to query for notes to review. This query is a source query, which is documented here and here:

A dataview source is something that identifies a set of files, tasks, or other data. Sources are indexed internally by Dataview, so they are fast to query. The most prominent use of sources is the FROM data command. They are also used in various JavaScript API query calls.

This quote (from the last source; emphasis mine) makes it clear that it maps to FROM, which is interesting to know to see the result set that will become the note set in this plug-in.

Glad you figured it out.


Create Profile for ...Eriku christopher

Name
Eriku christopher
Languages

English (good) , - madi/lugbara (good),

Skill 1
Hardware and repair.
Qualifications for Skill 1

Severally with YEF for  community repair cafe

Skill 2
No response
Qualifications for Skill 2
No response
Skill 3
No response
Qualifications for Skill 3
No response
Skill 4
No response
Qualifications for Skill 4
No response

Whatsup number +256771022473

Facebook name :Ojjo richard

rejected @timmwille


Histoire cannot collect stories in Svelte, Vite app

Describe the bug
I'm having a problem with a project scaffolded with npm create vite@latest using Svelte as the template when scaffolding.
No Nuxt or Vue like the recently closed (but not fixed for me! issue).
The template includes a component for a button to +1, Counter.svelte, very simple so no errors, and Histoire cannot find it.
The story file is simple, looks like this:
<svelte:options tag="cobalt-counter-hst" />

<Hst.Story title="Counter">

</Hst.Story>
Histoire itself opens on localhost with the sidebar etc, just can't collect any stories.
Missig some congif or? Have followed the docs to the letter.
Ubuntu 22.10 LTS
npm: '9.6.2',
node: '18.16.0',
Reproduction
Reproduced in stackblitz.
$ npm run story:dev
to see the error.
https://stackblitz.com/edit/vitejs-vite-cycwey?file=svelte.config.js
System Info
System:
    OS: Linux 5.19 Ubuntu 22.04.2 LTS 22.04.2 LTS (Jammy Jellyfish)
    CPU: (4) x64 Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
    Memory: 1.03 GB / 7.53 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  npmPackages:
    @histoire/plugin-svelte: ^0.16.1 => 0.16.1
    histoire: ^0.16.1 => 0.16.1
    vite: ^4.2.0 => 4.2.1

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion.
[X] The provided reproduction is a minimal reproducible example of the bug.

Just realised I should have posted my "I have this issue too" comment in here instead of in the closed vue version of this issue 🙈

Any news regarding this issue ?


Invalid syntax and crash on unit struct with where-clause

Against the current master branch, 4e2f7419176f9511c8f11fbd1378a3d455c09759:
$ echo "mod m { struct S where A: B; }" | cargo run --bin rustfmt

mod m {
    struct S
    mod m { struct S
    where
        A: B;
}

The output is not valid Rust syntax.
If the input is in two files, rustfmt crashes. I am hitting this in https://github.com/dtolnay/syn/pull/536.
src/lib.rs
mod m;

src/m.rs
struct A where B: C;

$ RUST_BACKTRACE=1 cargo run --bin rustfmt -- ../path/to/src/lib.rs

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:355:21
stack backtrace:
   9: <core::option::Option<T>>::unwrap
  10: rustfmt_nightly::rewrite::RewriteContext::snippet
             at src/rewrite.rs:56
  11: rustfmt_nightly::comment::rewrite_missing_comment
             at src/comment.rs:823
  12: rustfmt_nightly::items::rewrite_comments_before_after_where
             at src/items.rs:2731
  13: rustfmt_nightly::items::rewrite_where_clause_rfc_style
             at src/items.rs:2528
  14: rustfmt_nightly::items::rewrite_where_clause
             at src/items.rs:2630
  15: rustfmt_nightly::items::format_generics
             at src/items.rs:2786
  16: rustfmt_nightly::items::format_unit_struct
             at src/items.rs:1183
  17: rustfmt_nightly::items::format_struct
             at src/items.rs:991
  18: rustfmt_nightly::items::<impl rustfmt_nightly::visitor::FmtVisitor<'a>>::visit_struct
             at src/items.rs:438
  19: rustfmt_nightly::visitor::FmtVisitor::visit_item
             at src/visitor.rs:399
  20: rustfmt_nightly::reorder::<impl rustfmt_nightly::visitor::FmtVisitor<'a>>::visit_items_with_reordering
             at src/reorder.rs:281
  21: rustfmt_nightly::visitor::FmtVisitor::walk_mod_items
             at src/visitor.rs:697
  22: rustfmt_nightly::visitor::FmtVisitor::format_separate_mod
             at src/visitor.rs:781
  23: <rustfmt_nightly::formatting::FormatContext<'a, T>>::format_file
             at ./src/formatting.rs:150
  24: rustfmt_nightly::formatting::format_project
             at ./src/formatting.rs:92
  25: rustfmt_nightly::formatting::<impl rustfmt_nightly::Session<'b, T>>::format_input_inner::{{closure}}
             at ./src/formatting.rs:47
  26: <scoped_tls::ScopedKey<T>>::set
             at scoped-tls-0.1.2/src/lib.rs:155
  27: syntax::with_globals::{{closure}}
             at rustc-ap-syntax-290.0.0/lib.rs:123
  28: <scoped_tls::ScopedKey<T>>::set
             at scoped-tls-0.1.2/src/lib.rs:155
  29: syntax::with_globals
             at rustc-ap-syntax-290.0.0/lib.rs:122
  30: rustfmt_nightly::formatting::<impl rustfmt_nightly::Session<'b, T>>::format_input_inner
             at ./src/formatting.rs:31
  31: <rustfmt_nightly::Session<'b, T>>::format
             at ./src/lib.rs:531
  32: rustfmt::format_and_emit_report
             at src/bin/main.rs:300
  33: rustfmt::format::{{closure}}
             at src/bin/main.rs:272
  34: <rustfmt_nightly::Session<'b, T>>::override_config
             at ./src/lib.rs:539
  35: rustfmt::format
             at src/bin/main.rs:271
  36: rustfmt::execute
             at src/bin/main.rs:199
  37: rustfmt::main
             at src/bin/main.rs:36

With regards to the bad output, here's what I gathered.
Because there is no parameter, the span before the where clause is defined with the logic below, where span.lo() == BytePos (0). This is the start of the file I think, although from the comment (also below) it should just after struct S.
https://github.com/rust-lang-nursery/rustfmt/blob/34333bad20c89e9f6f96c5428924cd4c2f9c1315/src/items.rs#L2779-L2785
Then, comments before the where clause are extracted as follows; however, because of the wrong span earlier, the code mod m { struct S is considered to be a comment.
https://github.com/rust-lang-nursery/rustfmt/blob/34333bad20c89e9f6f96c5428924cd4c2f9c1315/src/items.rs#L2525-L2528
@dtolnay just to better understand your example, I was wondering if it is normal that the struct S is not parameterised with A, i.e., struct S<A> where A: B;. If I add it, then there is no issue. Is it intentional ?
If it is, then it seems there is something wrong with the span value of generics, isn't it ?

It is intentional that there is no generic parameter. This is legal and useful Rust syntax.

I was not aware! What is the use ? I'd appreciate any pointers ;o)
I tried this in the playground but it fails with error[E0412]: cannot find type B in this scope
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=fa1205ba785feec0af7f6d8828b2895b

For example:
pub struct Error {
    /* ... */
}

#[cfg(test)]
struct _Test where Error: Send + Sync;

This is a test that proves the Error type is Send and Sync. If you put a std::rc::Rc<()> inside the error, the test will catch that it is no longer Send and Sync.


Modified sample to use Lock

Modified sample to use Lock library and Auth0. Resolves #2 .

Thanks :)


golint: fix warnings for filter.go

Fixes the following warnings
Line 31: warning: comment on exported type LabelPrefix should be of the form "LabelPrefix ..." (with optional leading article) (golint)
Line 41: warning: exported function ParseLabelPrefix should have comment or be unexported (golint)
Line 134: warning: receiver name lpc should be consistent with previous receiver name cfg for LabelPrefixCfg (golint)
Related-to: #153 (Resolve golint warnings)

This pull request is now managed with CodeReviewHub. Refresh.

Was focusing on fixing the warnings, but maybe the comments should be reworded in a follow up?


News Vendor ** ?

In line 87 of newsvendor there is a multiplication of several items but it ends with a ** of self.lead_time.  I think that is wrong.
    purchase_cost = excess_inventory * self.cost * order_qty * \
        self.gamma ** self.lead_time

Happy to do a fix and PR if someone else can verify that is incorrect.   Thanks!

Hello,
Gamma is a discount factor that's discounted exponentially by the lead time. While we didn't enforce it in the code gamma should always be in the range: 0 < gamma <= 1.
Please let us know if you have any other questions!


refactor(ci): use cross

🤔 This is a ...

[x] Refactoring
[x] Workflow

🔗 Related issue link
https://github.com/Watfaq/clash-rs/pull/212
https://github.com/Watfaq/clash-rs/issues/210

would be nice to manage the artifacts properly here, i.e. remove the whole huge "binaries" and get other individual build published

would be nice to manage the artifacts properly here, i.e. remove the whole huge "binaries" and get other individual build published
https://github.com/Watfaq/clash-rs/actions/runs/8650063287

Strange. Why there are only two artifacts
You better check this normal one https://github.com/Watfaq/clash-rs/actions/runs/8649656339

remove the whole huge "binaries"
I will try delete it after release. Github will delete those artifacts in a few months, so i think it hardly affect anything

I will try delete it after release. Github will delete those artifacts in a few months, so i think it hardly affect anything

For now, binaries will only be kept for one day.


Weird Glitch when Navigating to a new Page

I'm trying to navigate from a login page to the home page of my app, without the user being able to go back to the login screen. To achieve this, I'm popping the login screen and then pushing the home screen but it creates a weird glitch where the screen goes back and then slides the new screen. I am using an animation but it happens without it as well. I've attached a gif of what's happening and below is my code.

Future<void> signInWithEmail() async {
    final formState = _formKey.currentState;

    if (formState.validate()) {
      formState.save();
      try {
        FirebaseUser user = await FirebaseAuth.instance
            .signInWithEmailAndPassword(email: _email, password: _password);
        Navigator.of(context)
          ..pop()
          ..pushReplacement(SlideBottomRoute(widget: HomePage(user: user)));
      } catch (error) {
        _scaffoldKey.currentState.showSnackBar(new SnackBar(
          content: Padding(
            padding: const EdgeInsets.only(top: 10.0),
            child: new Text(
              "Sorry.\nThe email and password provided don't correspond to any account.",
              style: new TextStyle(
                fontSize: 16.0,
                color: Color.fromRGBO(248, 233, 228, 1.0),
              ),
            ),
          ),
          backgroundColor: Color.fromRGBO(183, 70, 95, 1.0),
        ));
      }
    }
  }

I think it's doing what it should be there - you're telling it to pop and at the same time push a new item on top, so it doesn't really know what to do (pop and pushReplacement are both asynchronous functions and so run right away).
I assume what you're trying to do is a transition to a new screen (home) and then remove all previous routes (i.e. the login route). Would Navigator.of(context).pushAndRemoveUntil() work instead?

I think it's doing what it should be there - you're telling it to pop and at the same time push a new item on top, so it doesn't really know what to do (pop and pushReplacement are both asynchronous functions and so run right away).
I assume what you're trying to do is a transition to a new screen (home) and then remove all previous routes (i.e. the login route). Would Navigator.of(context).pushAndRemoveUntil() work instead?

Yep, that did it. Thank you so much. The specific line of how I fixed it if you're interested is:
Navigator.of(context).pushAndRemoveUntil(SlideBottomRoute(widget: HomePage(user: user)), (Route<dynamic> route) => false);


Fix suborganization creation issue due to table lock in mssql server

Purpose

During transaction operations, not being some operations being transactional cause this issue.

Related PR

https://github.com/wso2-extensions/identity-organization-management/pull/196

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/5251332236

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/5251332236
Status: success


Don't show bookmark button by default

Closes #4
Closes #5
BREAKING CHANGE: Bookmark button isn't enabled by default anymore

Great! Just for the sake of doing things right, let's add a small deprecation notice that is logged if users attempt to pass any of the legacy plugin options 🙂
It's fairly straightforward: we need to create a gatsby-node.js file and add something like this:
exports.onPreInit = ({ reporter }, options) => {
  if (options.tall || options.round) {
    reporter.warn(
      `From now on, you can use the gatsby-plugin-pinterest 'saveButton' option to show the Pinterest Save button on images. See https://github.com/robinmetral/gatsby-plugin-pinterest#usage`
    )
  }
}

Inspired by gatsby-plugin-google-analytics

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Allow revved production files on dev environment

This change allows you to run gulp --production on your development environment and have the page load properly. gulp --production on dev breaks neat features of gulp watch like browsersync and so forth. However it does permit you to test the --production output locally before deployment.

:100:

Thank you!


ENH: Add support for μ-law encoded PCM to scipy.io.wavfile.   This implementation decodes to 16-bit PCM.

Reference issue
N/A
What does this implement/fix?
Adds support for MULAW PCM formatted audio files to scipy.io.wavfile
Additional information

Oh yeah, out of curiosity, I noticed mention of a "copyright" issue in one of the commits?

@endolith can you comment?

My original commit used code from another project on GitHub.  Looking
through the overall project I couldn't find any evidence that the code was
licensed at all much less for compatibility with the Berkeley license, so I
replaced it with a simple look up table which should be faster anyway.  The
code for looking up values in that table is my own, as are the various
other added bits, but the reference wasn't to any complaint it was just
that I didn't want to wait for confirmation from the other author that I
could reuse his code, so I replaced it.
On Tue, Aug 18, 2020 at 6:59 PM Eric Larson<EMAIL_ADDRESS>wrote:

@endolith https://github.com/endolith can you comment?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/pull/12735#issuecomment-675807141, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC3SXBWXYYK4ZOOF4LJZY3SBMWWLANCNFSM4QDXRZVA
.

I don't know much about μ-law.  What bit depths are supported?  The bit depth checking will be changed to handle different formats separately in https://github.com/scipy/scipy/pull/12287/files#diff-c5c9583b55bf7580040d99e32c4f1771R429  Does this mesh well with that?

Compliant MULAW recordings are restricted to 8-bit.   The conversion back
to PCM in my code masks the values to 8-bits if they exceed that so you
could give it data in larger bit depths and it would continue to treat that
data as G.711 MULAW 8-bit representation but really the meaning is
undefined, it just doesn't throw exceptions.
On Tue, Aug 18, 2020 at 8:48 PM endolith<EMAIL_ADDRESS>wrote:

I don't know much about μ-law. What bit depths are supported? The bit
depth checking will be changed to handle different formats separately in
https://github.com/scipy/scipy/pull/12287/files#diff-c5c9583b55bf7580040d99e32c4f1771R429
Does this mesh well with that?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/pull/12735#issuecomment-675835179, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC3SXGK3CWVLQAKKFNVV6LSBNDQLANCNFSM4QDXRZVA
.

Now that #12287 is merged, can you rebase onto that?  The line if format_tag == WAVE_FORMAT.PCM or format_tag == WAVE_FORMAT.MULAW: will need to be split out into its own check, so

if PCM:

check PCM bit depths that we support

if float

check float bit depths that we support

if mulaw

check 8 bit that we support


One or more high quality DEX / Bridge services that require finality, such as cross-chain bridges, are willing to rely on Zcash’s finality.

This is satisfied just by an expert / builder / vendor for that kind of service claiming Crosslink finality is sufficient for their need.
Prerequisites:

#13
#23

Maybe we could ask Kit from Red Dev to track this issue and give us iterative feedback on if it looks like we're on the right track to satisfy Red Dev's needs. Kit previously posted a comment on our initial scoping document about that, but it would be cool if he could subscribe to this issue and we could use him as a "sample customer" for this particular issue ticket. :-)


Improve documentation to clarify how providers obtain credentials

It's difficult to always know what the order of precedence is for what a provider will use for credentials and where credentials can be picked up from. Similarly, there aren't clear debug/troubleshooting steps for when end users have trouble authenticating or making certain API calls.

This will by-necessity need to happen at a per-provider level.


Status of COBS/R pull request

Hi @p-h-a-i-l  - just wondering on teh status of the open COBS/R pull request?
My own project has been on hold for months, I'm finally getting back to it. I have my HB running with an older version of the firmware, everything sort of works. I have a bluetooth wii remote controlling the hoverboard via a raspberry pi. Currently it's only using the ASCII protocol though. I was planning to switch to the machine protocol as I'd like a bit finer control (and to retrieve information more easily about speed etc). I saw this PR sitting there with all the protocol changes though, so don't want to implement the 'old' protocol if it's going to be replaced.
I can wing it and build off the COBS/R branch but figured if this PR is likely to be merged and used by the main firmware I could wait

merging right now :)


Remove all links to migration page and update nav page in Core docs 2.1.5 - closes #603

closes #603

Also, please fix the conflicts


Varying predictions on same files (UTMOS-demo)

Hi,
I was trying out the quick predictions using the UTMOS-demo and --mode predict_dir and noticed that when predicting the same directory multiple times with batch_size > 1, the predicted scores will vary each time. With batch_size 1, the values are consistent, but the order in the created csv file will be different each time, making it impossible to attribute a score to a specific file.
For --mode predict_file, the score is consistent.

This is due to the zero padding inserted to the input wav when making a batch. If you want a precise prediction, You should only use batch_size of 1.
Feel free to reopen the issue when needed.


create CONTRIBUTION.md file

I believe it should include:

Links to the video tutorials on my youtube channel https://www.youtube.com/watch?v=6H6jkJCVhgk&t=4s&pp=ygUKbm9hbSBnYWFzaA%3D%3D https://www.youtube.com/watch?v=jEWG7nYKk_0&t=137s https://www.youtube.com/watch?v=DWp4cwd97TI
Explanation about linting and testing
links to discord and slack
anything else comes up on your mind

I would like to work on it

Cool, thanks!

[ ] Explanation about ci and the need to check it's status.

Hi, @Tashuuuu  are you working on this issue? If you have any questions you are welcome to ask.


can't handle : in input path

It is interpreted as a separator by the docker engine:
docker: Error response from daemon: invalid bind mount spec "/vault-tina/gijs/prefactor-cwl/runs/run_2017-11-14-T14:19:29/results/out_tmpdiriJOjgW:/var/spool/cwl:rw": invalid volume specification: '/vault-tina/gijs/prefactor-cwl/runs/run_2017-11-14-T14:19:29/results/out_tmpdiriJOjgW:/var/spool/cwl:rw'

The fix for this requires Docker 17.05 or later: https://github.com/moby/moby/issues/8604#issuecomment-332685815

➤ Adam Novak commented:
This should be fixed now that we go through Docker’s API to set up our Docker executions.


Please dont use colons in file names. It will cause issues in windows!

https://github.com/av/harbor/blob/main/ollama/modelfiles/llama3.1%3A8b.Modelfile#L8

shane @ moa ❯ _repos ❯ gh repo clone shaneholloman/harbor
Cloning into 'harbor'...
remote: Enumerating objects: 2168, done.
remote: Counting objects: 100% (726/726), done.
remote: Compressing objects: 100% (447/447), done.
Rremote: Total 2168 (delta 266), reused 684 (delta 229), pack-reused 1442 (from 1)
Receiving objects: 100% (2168/2168), 6.14 MiB | 1.37 MiB/s, done.
Resolving deltas: 100% (1097/1097), done.
error: invalid path 'ollama/modelfiles/llama3.1:8b.Modelfile'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

failed to run git: exit status 128
shane @ moa ❯ _repos  ❯

Thanks for bringing this to my attention (and for the PR!), I'll keep an eye on cases like these from now on

Closing this for now, since this was resolved with your PR (thanks again!)
Please, feel free to follow-up or open a new issue if anything similar happens again.


Fix SQL selected / SQL explain for gis queries

Without this fix, pushing the 'sel' or 'explain' button for a query containing some EWKB-encoded geometry
as parameter results in this crash:
Internal Server Error: /__debug__/sql_explain/
Traceback (most recent call last):
  File "/Users/jieter/.pyenv/versions/obs/lib/python3.8/site-packages/django/db/backends/utils.py", line 86, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.InternalError_: parse error - invalid geometry
LINE 1: ...ure" IN (0, 1, 5)) AND "waarneming"."geo_point" @ 'ST_GeomFr...
                                                             ^
HINT:  "ST" <-- parse error at position 2 within geometry

I'm not sure if this is the appropriate location in the code, but with this fix, both sql_select and sql_explain
work without flaws.
Previous PR adding a similar fix: #1130
Fixes: #423

Thanks! This looks very hacky. I think I understand why this may be necessary but I fear the complexity a bit. Also, this change would definitely need a test to prevent regressions in the future.

Yes, fully agreed! I only tried to make the existing solution a bit more readable by avoiding the numerical offsets.
I just looked into adding tests, which would require another test matrix entry with DB_BACKEND=postgis. Do you mind if I add that @matthiask?

@jieter Regarding DB_BACKEND=postgis: Not at all, I think that would be great.

I've added postgis to the tests (not yet added to github actions).
I also added a test, but this still crashes with the same error, and (for as far as I can see) the same input as captured while running debug-toolbar with the fix in my development environment. I'll try to revisit this later.


add entry link

is there way to add entry link

At this stage, no.
If you wanted to write a plugin for Tiny that you want to submit to this repo, that would be cool.
To be honest, we no longer use this add-on ourselves, and use Bard fields, field sets and a page builder approach for our sites. This has given us a better built-in Statamic authoring experience for use as developers, as well as our users. We are keeping this add-on open for those who do want Tiny in Statamic.


Update qgis: matplotlib?

homebrew/science will be archived on (or shortly after) 1 Jan.
https://github.com/Homebrew/homebrew-science/issues/6365#issuecomment-350707678
matplotlib will likely not be accepted into homebrew/core.
https://github.com/Homebrew/homebrew-core/pull/21561#issuecomment-350721341
Some of the science formulas are being migrated to taps outside the Homebrew organisation but I think we should not be relying on external taps to fulfil dependancies.
The upstream for this package of qgis provides a packaged matplotlib but it also seems to require another packaged dependancy (numpy), I'm not sure if the formula numpy will satisfy this requirement. (Cask matplotlib was removed becuase of https://github.com/caskroom/homebrew-cask/issues/13359)
Related issues: (probably missed a couple)
https://github.com/caskroom/homebrew-cask/issues/15421, https://github.com/caskroom/homebrew-cask/issues/15131, https://github.com/caskroom/homebrew-cask/pull/8566, https://github.com/caskroom/homebrew-cask/pull/5179

The steps required to install this Cask without formula dependancies make it rather complicated and  difficult to provide support for if there are any issues.
Not really sure what to do with this Cask but we have a couple of weeks to decide.

Some of the science formulas are being migrated to taps outside the Homebrew organisation but I think we should not be relying on external taps to fulfil dependancies.

Agreed.

The steps required to install this Cask without formula dependancies make it rather complicated and difficult to provide support for if there are any issues.
Not really sure what to do with this Cask

I like to err on the side of removing. If people use it, they’ll complain and then we’ll then discuss a solution with the people that actually use the software. If it takes over a year for someone to complain, we’ll know it wasn’t that popular in the first place; otherwise we’ll think then about what we can do.


Modifiers

Codecov Report

Merging #85 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #85   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          46     48    +2
  Lines         255    261    +6
=====================================
+ Hits          255    261    +6

Impacted Files
Coverage Δ

src/helpers/desaturate.js
100% <100%> (ø)

src/helpers/saturate.js
100% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 85083ad...6c72e27. Read the comment docs.


one line fix for TensorBoard callback issue

Ref: https://github.com/fchollet/keras/issues/2570

One data point: it seems to work on my local machine with TensorFlow 0.8.

Tests are failing hard. Seems to be more to it.

What's the version of tensorflow on the test env ?

@jingzhehu 0.7.1

@joelthchao Thank for the info !
@fchollet, Would it be possible to bump up the tensorflow version in the test env and see if the tests fail ?
I will try to run the tests locally after I get back.

@jingzhehu probably you can use condition on tensorflow version to fix the problem.
I guess tensorflow does the same thing to maintain compatibility.

Are the tests all passing locally for you?

I also added a write_graph flag because I noticed that the log files can get quite large if the graph is included (e.g. ~500MB for a medium-sized LSTM).

We should add a conditional statement based on the TF version.

Thanks, @bnaul ! I've merged your code into the PR.

Looks good to me. You'll probably want to squash those commits into one but the code is 👍.

LGTM, thanks!