text:
RPI3 Disconnects

I tested a simple simple to connect to a BLE device, but i almost all the times receive a disconnect before connecting... Cant figure out why.
The same script on MacOS works as expected.
var noble   = require('noble');

noble.on('stateChange', function(state) {
  if (state === 'poweredOn') {
    noble.startScanning(['180d']);
  } else {
    noble.stopScanning();
  }
});

noble.on('discover', function(peripheral) {
  console.log(peripheral.advertisement.localName);

  peripheral.on('disconnect', function() {
    console.log("disconnected", peripheral.advertisement.localName)
  });

  peripheral.connect(function(error) {
    peripheral.discoverSomeServicesAndCharacteristics(['180d'], ['2a37'], function(error, services, characteristics){
      var service = services[0];
      var characteristic = characteristics[0];

      console.log(characteristic);
    });
  });

});

node index2.js
Polar H7 B861C114
discovered Polar H7 B861C114
disconnected Polar H7 B861C114

Here the output of hcidump:
HCI sniffer - Bluetooth packet analyzer ver 5.23
device: hci0 snap_len: 1500 filter: 0xffffffff
2016-09-18 17:40:55.894473 > HCI Event: Command Complete (0x0e) plen 4
    Set Event Mask (0x03|0x0001) ncmd 1
    status 0x00
2016-09-18 17:40:55.895041 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Event Mask (0x08|0x0001) ncmd 1
    status 0x00
2016-09-18 17:40:55.895551 > HCI Event: Command Complete (0x0e) plen 12
    Read Local Version Information (0x04|0x0001) ncmd 1
    status 0x00
    HCI Version: 4.1 (0x7) HCI Revision: 0xb6
    LMP Version: 4.1 (0x7) LMP Subversion: 0x2209
    Manufacturer: Broadcom Corporation (15)
2016-09-18 17:40:55.895955 > HCI Event: Command Complete (0x0e) plen 4
    Write LE Host Supported (0x03|0x006d) ncmd 1
    00
2016-09-18 17:40:55.896361 > HCI Event: Command Complete (0x0e) plen 6
    Read LE Host Supported (0x03|0x006c) ncmd 1
    00 01 00
2016-09-18 17:40:55.896915 > HCI Event: Command Complete (0x0e) plen 10
    Read BD ADDR (0x04|0x0009) ncmd 1
    status 0x00 bdaddr B8:27:EB:07:A3:EF
2016-09-18 17:40:55.906495 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x0c
    Error: Command Disallowed
2016-09-18 17:40:55.906922 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
2016-09-18 17:40:55.912280 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2016-09-18 17:40:57.319102 > HCI Event: Command Status (0x0f) plen 4
    LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
2016-09-18 17:40:57.771967 > HCI Event: Command Status (0x0f) plen 4
    LE Read Remote Used Features (0x08|0x0016) status 0x00 ncmd 1
2016-09-18 17:40:57.773726 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2016-09-18 17:40:57.876261 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 64 reason 0x3e
    Reason: Connection Failed to be Established
2016-09-18 17:41:00.207559 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x0c
    Error: Command Disallowed

What's the value of the error arg in the connect callback?
From the HCI dump the connection is failing:
2016-09-18 17:40:57.319102 > HCI Event: Command Status (0x0f) plen 4
    LE Create Connection (0x08|0x000d) status 0x00 cmd 1

....

2016-09-18 17:40:57.876261 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 64 reason 0x3e
    Reason: Connection Failed to be Established

Also, can you run with sudo hcidump -t -x next time? Which version of noble are you using?

I'm experiencing this same issue on a Raspberry Pi 3. When connecting to a peripheral about 50% of the time the device connects and then immediately disconnect. The other 50% the connection success with no problems. I'm running the exact same code on my Mac (OS X 10.11.4) and the connections succeed 100%
When the connection fails:

$ sudo hcidump -t -x
HCI sniffer - Bluetooth packet analyzer ver 5.23
device: hci0 snap_len: 1500 filter: 0xffffffff
2016-09-30 16:59:16.458302 < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x01 (scanning enabled)
    filter duplicates 0x01 (enabled)
2016-09-30 16:59:16.458837 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2016-09-30 16:59:18.388824 > HCI Event: LE Meta Event (0x3e) plen 42
    LE Advertising Report
      ADV_IND - Connectable undirected advertising (0)
      bdaddr CB:AC:05:9E:71:9E (Public)
      Flags: 0x06
      Complete local name: 'Sense01'
      Unknown type 0x06 with 16 bytes data
      RSSI: -46
2016-09-30 16:59:18.418575 > HCI Event: LE Meta Event (0x3e) plen 21
    LE Advertising Report
      SCAN_RSP - Scan Response (4)
      bdaddr CB:AC:05:9E:71:9E (Public)
      Unknown type 0x1b with 7 bytes data
      RSSI: -62
2016-09-30 16:59:20.785048 < HCI Command: LE Create Connection (0x08|0x000d) plen 25
    bdaddr CB:AC:05:9E:71:9E type 0
    interval 96 window 48 initiator_filter 0
    own_bdaddr_type 0 min_interval 6 max_interval 12
    latency 0 supervision_to 200 min_ce 4 max_ce 6
2016-09-30 16:59:20.787814 > HCI Event: Command Status (0x0f) plen 4
    LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
2016-09-30 16:59:20.800756 > HCI Event: LE Meta Event (0x3e) plen 19
    LE Connection Complete
      status 0x00 handle 64, role master
      bdaddr CB:AC:05:9E:71:9E (Public)
2016-09-30 16:59:20.800982 < HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2
  40 00
2016-09-30 16:59:20.802029 > HCI Event: Command Status (0x0f) plen 4
    LE Read Remote Used Features (0x08|0x0016) status 0x00 ncmd 1
2016-09-30 16:59:20.802081 < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x00 (scanning disabled)
    filter duplicates 0x00 (disabled)
2016-09-30 16:59:20.803718 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2016-09-30 16:59:20.904464 > HCI Event: LE Meta Event (0x3e) plen 12
    LE Read Remote Used Features Complete
      status 0x3e handle 64
      Error: Connection Failed to be Established
2016-09-30 16:59:20.904998 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 64 reason 0x3e
    Reason: Connection Failed to be Established
2016-09-30 16:59:20.970692 < ACL data: handle 64 flags 0x00 dlen 7
    ATT: MTU req (0x02)
      client rx mtu 256
2016-09-30 16:59:21.168153 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 64 packets 1
2016-09-30 16:59:36.440391 < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x00 (scanning disabled)
    filter duplicates 0x01 (enabled)
2016-09-30 16:59:36.441116 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x0c
    Error: Command Disallowed

When the connection succeeds:
$ sudo hcidump -t -x
HCI sniffer - Bluetooth packet analyzer ver 5.23
device: hci0 snap_len: 1500 filter: 0xffffffff
2016-09-30 17:02:59.439319 < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x01 (scanning enabled)
    filter duplicates 0x01 (enabled)
2016-09-30 17:02:59.440395 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2016-09-30 17:03:01.022537 > HCI Event: LE Meta Event (0x3e) plen 42
    LE Advertising Report
      ADV_IND - Connectable undirected advertising (0)
      bdaddr CB:AC:05:9E:71:9E (Public)
      Flags: 0x06
      Complete local name: 'Sense01'
      Unknown type 0x06 with 16 bytes data
      RSSI: -48
2016-09-30 17:03:01.052313 > HCI Event: LE Meta Event (0x3e) plen 21
    LE Advertising Report
      SCAN_RSP - Scan Response (4)
      bdaddr CB:AC:05:9E:71:9E (Public)
      Unknown type 0x1b with 7 bytes data
      RSSI: -66
2016-09-30 17:03:02.536673 < HCI Command: LE Create Connection (0x08|0x000d) plen 25
    bdaddr CB:AC:05:9E:71:9E type 0
    interval 96 window 48 initiator_filter 0
    own_bdaddr_type 0 min_interval 6 max_interval 12
    latency 0 supervision_to 200 min_ce 4 max_ce 6
2016-09-30 17:03:02.539609 > HCI Event: Command Status (0x0f) plen 4
    LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
2016-09-30 17:03:02.585033 > HCI Event: LE Meta Event (0x3e) plen 19
    LE Connection Complete
      status 0x00 handle 64, role master
      bdaddr CB:AC:05:9E:71:9E (Public)
2016-09-30 17:03:02.585227 < HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2
  40 00
2016-09-30 17:03:02.586591 > HCI Event: Command Status (0x0f) plen 4
    LE Read Remote Used Features (0x08|0x0016) status 0x00 ncmd 1
2016-09-30 17:03:02.586642 < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x00 (scanning disabled)
    filter duplicates 0x00 (disabled)
2016-09-30 17:03:02.587406 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2016-09-30 17:03:02.632572 > HCI Event: LE Meta Event (0x3e) plen 12
    LE Read Remote Used Features Complete
      status 0x00 handle 64
      Features: 0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x00
2016-09-30 17:03:02.639655 < ACL data: handle 64 flags 0x00 dlen 7
    ATT: MTU req (0x02)
      client rx mtu 256
2016-09-30 17:03:02.662428 > ACL data: handle 64 flags 0x02 dlen 7
    ATT: MTU resp (0x03)
      server rx mtu 256
2016-09-30 17:03:02.792640 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 64 packets 1

Sorry for not answering with the full log.. i digged a lot into this issue and my findings points towards node-bluetooth-hci-socket issues... When using gattool everything works as expected 100% of the time.
I played around the Hci.prototype.setSocketFilter that is executed, and this made things work a little bit in terms of connection, whenever i removed some of the masks used.
Another finding that i made, about behaviour, is that on MacOS if i lose connection of the bluetooth peripheral (because of range) and then the peripheral get in range again, i can listen to this and reconnect again. On the other hand, in raspberry, if i lose connection i will never receive callback for that peripheral again. The only option is to stop and start scanning again.
Its seems that this project, although all the credits and kudos for the work done, have really underterministic behaviours depending on the system it executes.
I moved away to python bindings for now..

@ddxtreme which bindings did you use?  Are they working?  And are you still using the Noble library and using custom bindings?

@cscholze i stop using noble, i went using bluepy for python. As i didnt depend on nodejs and after several hours trying to understand the problem i switched as soon as my findings points towards node-bluetooth-hci-socket malfunction with RP3. As there is any other library for node for bluetooth, i switched.
Now i already overcome that issue with bluepy

@ddxtreme @TheCbac @cscholze
Can you please try out https://github.com/sandeepmistry/node-bluetooth-hci-socket/pull/39 and provide your feedback?
cd <some patch/noble
cd node_modules
rm -rf bluetooth-hci-socket
npm install sandeepmistry/node-bluetooth-hci-socket#rework-kernel-workarounds

Then try your noble app ...

I've run into probably the same issue.
Here is what iot-sensor-tag/publish/sensor-tag.js  outputs with the patches branch:
   iot-sensor-tag/publish $ sudo node sensor-tag.js
   Device MAC Address: b827ebXXXXXX
   The device MAC address does not match the ID in the configuration file.
   Make sure the Sensor Tag is on!
   MQTT client connected to IBM IoT Cloud.
   Discovered device with UUID: bc6a29ab67ef  (cc2540)
   Connected To Sensor Tag
   noble warning: unknown peripheral bc6a29ab67ef
   noble: unknown peripheral null connected!
   noble: unknown peripheral null connected!
   noble: unknown peripheral null connected!
   [... repeated ...]

Sorry, I have very little Linux / Node / Raspberry knowledge - just wanted to push a bunch of humidity data in the cloud for analysis...

@sandeepmistry Thanks, I'll try this out later this week.
In the mean time, I noticed that all of the issues went away when switching to ethernet, instead of wifi and turning off wifi with:
$ sudo ifdown wlan0

Hi,
I am experiencing the same problems referenced in this issue (and #453, #474, #480) aswell.
At a random time the connection will immediately be disconnected after connecting.
This causes the next hci call to produce the following hci error requiring a hciconfig hci0 reset to get noble working again:
Bluetooth: hci0 link tx timeout
Bluetooth: hci0 killing stalled connection b1:d6:4b:0d:ac:e6

After a lot of debugging i've not come much closer to finding a fix. I tried to only call noble function sequentially and add a delay of 100ms between all calls that go to noble. This did not fix the issue but did cause less hci0 tx timeout errors which made it possible for my code to start a new connection that did not immediately disconnect (until hci0 does crash).
I've got a hcidump but it is an .cap file so you will need to open it in wireshark. The problem occurs at 183 sec of the dump. The calls that were done at that time were:
time        execution time   call
0248.3270 : 7                connect
0248.3380 : 110              discoverServices
0248.4600 : 125              discoverCharacteristics
0248.5910 : 1004             write
0253.6000 : 33               disconnect
0257.3440 : 65               connect
0257.4140 : timeout          discoverServices

I tested my code on linux kernel 4.1 and 4.7 and this did not resolve the issue.
I am using a BCM4330 based sdio module and used the wifi and bluetooth firmware that shipped with the hummingboard. I suspect this problem is firmware related since the raspberry pi 3 uses a similar module (BCM43430).
Maybe @arend has time to look whether this is firmware related?
Regards,
Bas

@TheCbac you said that using a wired connection got rid of the disconnect issue.  Is that still the case?  I tried it and it worked for a little bit, but then started disconnected again.

@BasKiers @cscholze what peripheral devices are you using? Maybe the noble connection parameter are used need to be adjusted?
@BasKiers have you tried to see if gatttool exhibits similar behaviour?

@cscholze Since I switched to a wired connection I haven't experienced the issue at all. This is on multiple Pi's and over 10's of hours. The wired connection uses a static IP and wlan0 down.

yes i am experiencing the same problem. I am using the Intel Edison.
about 50% of the time, when i connect, it immediately disconnects. And after i try about 2-5 times, it eventually connects. However this is causing some lag because of the retries.

I had an 100% reproducible immediate disconnect with an Ti Sensortag - until updating bluez from the Jessie-supplied 5.23 to 5.42. Then I had 6h continuous uptime until an disconnect for a different reason...

For what it is worth I've got the debug log of when this issue occures:
Mon, 24 Oct 2016 14:58:12 GMT hci set scan enabled - writing: 010c20020001
Mon, 24 Oct 2016 14:58:12 GMT hci onSocketData: 040e04010c200c
Mon, 24 Oct 2016 14:58:12 GMT hci       event type = 4
Mon, 24 Oct 2016 14:58:12 GMT hci       sub event type = 14
Mon, 24 Oct 2016 14:58:12 GMT hci               cmd = 8204
Mon, 24 Oct 2016 14:58:12 GMT hci               status = 12
Mon, 24 Oct 2016 14:58:12 GMT hci               result =
Mon, 24 Oct 2016 14:58:12 GMT hci create le conn - writing: 010d201960003000000068af644c99b40006000c000000c80004000600
Mon, 24 Oct 2016 14:58:12 GMT hci onSocketData: 040f0400010d20
Mon, 24 Oct 2016 14:58:12 GMT hci       event type = 4
Mon, 24 Oct 2016 14:58:12 GMT hci       sub event type = 15
Mon, 24 Oct 2016 14:58:12 GMT hci               status = 0
Mon, 24 Oct 2016 14:58:12 GMT hci               cmd = 8205
Mon, 24 Oct 2016 14:58:12 GMT hci onSocketData: 043e1301004000000068af644c99b40c000000c80005
Mon, 24 Oct 2016 14:58:12 GMT hci       event type = 4
Mon, 24 Oct 2016 14:58:12 GMT hci       sub event type = 62
Mon, 24 Oct 2016 14:58:12 GMT hci               LE meta event type = 1
Mon, 24 Oct 2016 14:58:12 GMT hci               LE meta event status = 0
Mon, 24 Oct 2016 14:58:12 GMT hci               LE meta event data = 4000000068af644c99b40c000000c80005
Mon, 24 Oct 2016 14:58:12 GMT hci                       handle = 64
Mon, 24 Oct 2016 14:58:12 GMT hci                       role = 0
Mon, 24 Oct 2016 14:58:12 GMT hci                       address type = public
Mon, 24 Oct 2016 14:58:12 GMT hci                       address = b4:99:4c:64:af:68
Mon, 24 Oct 2016 14:58:12 GMT hci                       interval = 15
Mon, 24 Oct 2016 14:58:12 GMT hci                       latency = 0
Mon, 24 Oct 2016 14:58:12 GMT hci                       supervision timeout = 2000
Mon, 24 Oct 2016 14:58:12 GMT hci                       master clock accuracy = 5
@@@@@@ LE CONN COMPLETE b4994c64af68
Mon, 24 Oct 2016 14:58:12 GMT att b4:99:4c:64:af:68: write: 020001
Mon, 24 Oct 2016 14:58:12 GMT hci write acl data pkt - writing: 024000070003000400020001
Mon, 24 Oct 2016 14:58:12 GMT hci onSocketData: 011620024000
Mon, 24 Oct 2016 14:58:12 GMT hci       event type = 1
Mon, 24 Oct 2016 14:58:12 GMT hci               cmd = 8214
Mon, 24 Oct 2016 14:58:12 GMT hci               data len = 2
Mon, 24 Oct 2016 14:58:12 GMT hci onSocketData: 040f0400011620
Mon, 24 Oct 2016 14:58:12 GMT hci       event type = 4
Mon, 24 Oct 2016 14:58:12 GMT hci       sub event type = 15
Mon, 24 Oct 2016 14:58:12 GMT hci               status = 0
Mon, 24 Oct 2016 14:58:12 GMT hci               cmd = 8214
Mon, 24 Oct 2016 14:58:12 GMT hci onSocketData: 043e0c043e40000100000000000000
Mon, 24 Oct 2016 14:58:12 GMT hci       event type = 4
Mon, 24 Oct 2016 14:58:12 GMT hci       sub event type = 62
Mon, 24 Oct 2016 14:58:12 GMT hci               LE meta event type = 4
Mon, 24 Oct 2016 14:58:12 GMT hci               LE meta event status = 62
Mon, 24 Oct 2016 14:58:12 GMT hci               LE meta event data = 40000100000000000000
Mon, 24 Oct 2016 14:58:12 GMT hci onSocketData: 0405040040003e
Mon, 24 Oct 2016 14:58:12 GMT hci       event type = 4
Mon, 24 Oct 2016 14:58:12 GMT hci       sub event type = 5
Mon, 24 Oct 2016 14:58:12 GMT hci               handle = 64
Mon, 24 Oct 2016 14:58:12 GMT hci               reason = 62
@@@@@@ LE DISCONN COMPLETE b4994c64af68
@@@@@CONNECTION CORRUPT DETECTED after  33ms

@sandeepmistry We are using RPI3 for central and iOS devices for the peripherals

Hi,
small update.
I've added the following measures and my ble connection is now much more stable, only occasional unexpected behaviour (corrupt connections) for which I have a hacky workaround aswell.
Things I did to try to improve stability:
Added a function queue to ensure only 1 call is done to noble at the same time.
This is done for all noble calls and I've added a hardcoded delay of 100ms between all calls (Will need to investigate if this delay can be removed and/or some noble calls can be done asynchronously).
Stop scanning before calling connect and disconnect
Added timeout logic to all noble calls, also moved the registering of the callback listener to my code because then I can remove the listener when a timeout occurs (before this would result in listener memory leak detected warnings)
Removing device from noble cache when connect returns an error or times out
Added logic to retry a call after it timed out (this does rarely fix the problem after the other fixes so I will probably remove this)
Use the kernel workarounds branch of node-bluetooth-hci-socket (https://github.com/sandeepmistry/node-bluetooth-hci-socket/tree/rework-kernel-workarounds). Although I do not have much test data to support it I do think this increased the stability for me. Maybe I can provide you with more definite data for this soon.
My problems were:
After a device get's lost and I clear it from noble (probably shouldn't do this but I want to be able to clear devices from noble when they are not available anymore) I am unable to find it again.
This was caused by the check if the advertisement message had type === 0x04.
Fixed this issue by setting process.env.NOBLE_REPORT_ALL_HCI_EVENTS and calling this.noble._bindings._hci.reset() before starting discovery (need to test if the latter is really necessary)
After connecting to a device sometimes a disconnect would immediately be called.
Fixed this by setting a timeout of 500 ms and if a disconnect event is received within this window I know the correction is corrupt. When this happens hci0 needs to be reset before I can get connections again so I disconnect from all devices, then call hciconfig hci0 reset from my code and then retry the connection.
I am currently testing the stability and fixing some bugs in my own code. My test setup consists of 2 Mipow Milight devices (one bulb and one candle) which I turn on and off in different intervals disconnecting and reconnecting between each write that has an interval higher than 3000 ms. After 10 minutes the program will disconnect and pause for 5 minutes and after that continue the loop. The longest stable test I've done till now (due to a bug in my code) was 8.5 hours and I am pretty confident that the noble part is stable. I do not use subscribe/unsubscribe since I think this will break when I do a hci reset so this is something I will need to test.

Hi
Great update.
I created #487 as I am receiving disconnect supervisory timeouts.
Could you explain to me how you were able to increase the timeout value.
I having been trying to debug this over weekend without any joy as I am not getting or I don't think I am getting errors but the devices seem to be gracefully disconnecting due to the supervisory timeout value. This is strange as I getting this on two different devices at random intervals.
Would like to try and increase the supervisory timeout and test to see if this gives me more stable results.

hmm so is there any resolution for this?

@benjaminhon could you please try #514?

Hello Sandeep,
Thank you for a great set of libraries!
We have a related issue using noble-device that this patch has  fixed. Are you planning to merge it to the master?
Running the following cycle, we never got connected to a peripheral two ice.….
discoverAll
stopDiscoverAll
connectAndSetUp
readStringCharacteristic
stopDiscoverAll
...
Thanks & Best

Not sure if this already known here, but RPi3 BL & Wifi are on the same chip. Using BL when connected to Wifi will interfere with Wifi, causing disconnects and eventually hangups. To solve this disable Wifi and go with a wired solution, or get an external BL adapter.
Just sharing this, just in case...

Hi, I'm also dealing with many of the issues @BasKiers illustrated. I'm using a wifi dongle so that the RPi 3's wifi/bluetooth chip doesn't experience interference between the two services as per @cryptocake's most recent comment.
I have a crude workaround for this using @BasKiers solution to set a timeout that checks for an immediate disconnect. If this has happened, I manually force the peripheral to disconnect again. Can anyone explain what exactly is happening under the hood? The problem seems to occur more often when I advertise 10+ BLE signals from device B while device A holds a connection with the RPi3.
I have also noticed this immediate 'disconnect' is not a disconnect at all (this is why I force a peripheral.disconnect() upon checking if a 'disconnect' has occurred immediately after a connect). Both the pi and device tell me (using hcitool) that the connection is still on-going. Noble believes it has disconnected, tries to connect again, then fails with a 0x0c command disallowed status upon trying to retrieve characteristics.

I wish I read this thread weeks ago... not only random disconnects (both on Rpi3 and Rpi4) but there is data loss on notifications (on Rpi3, did not experience it on Rpi4) as well when I try to receive bulk data from a device.

@javiermelendezc just switch to the abandonware edition.

I am having the same issue on Ubuntu 18.04

authors: BasKiers Jaftem Murvi TheCbac benjaminhon carlosamtech cryptocake cscholze ddxtreme ediogodias endrelovas komorebi-san sandeepmistry tengelmeier

repo: sandeepmistry/noble


text:
Receive UUID and peripheral ID in callbacks

Hi,
When reading a characteristic (and receiving notifications) from a peripheral, I'm surprised that read callback does not get the peripheral ID and the characteristic UUID passed in as parameters. I have multiple BLE peripherals connected simultaneously and need to know which device generated the callback. I.e. I'm looking for:
characteristic.read([callback(error, data, peripheralId, uuid)]);
I have a local one line hack for this in characteristic.js:
Characteristic.prototype.read = function(callback) {
  if (callback) {
    this.once('read', function(data) {
      // callback(null, data);
      callback(null, data, this._peripheralId, this.uuid);
    });
  }

  this._noble.read(
    this._peripheralId,
    this._serviceUuid,
    this.uuid
  );
};

Is there a reason that all of the callbacks don't pass the device and characteristic that generated them? I'm I missing something?
Thanks for this great package!
Craig

Hi @TheCbac,
Thanks for the feedback!
I don't think the extra args are needed. For more, complex cases I would suggest you use noble-device to create wrapper objects for peripherals and services.
Alternatively you can use bind:
characteristic.read(function(peripherald, characteristicUuid, error, data) {
  // ...
}.bind(this, peripheral.id, characteristic.uuid));

source: gharchive/issue

authors: TheCbac sandeepmistry

license: mit

license_type: permissive

license_source: bigquery


text:
Add FreeBSD support

Depends on tessel/node-usb#154.
I've been able to discover my Pebble Time from my Raspberry Pi running FreeBSD using the example in noble! :) A noble PR is coming as well.
The LE discovery example here doesn't seem to actually discover anything though.
When testing to make sure the example fails on a Linux VM as well (and indeed it does), I also had to change:
var binding_path = binary.find(path.resolve(path.join(__dirname,'./package.json')));

to
var binding_path = binary.find(path.resolve(path.join(__dirname,'../package.json')));

in lib/native.js.

@myfreeweb awesome!

source: gharchive/pull-request

authors: myfreeweb sandeepmistry

repo: sandeepmistry/node-bluetooth-hci-socket


text:
Update compilerplugin, scalapb-runtime to 0.11.14

About this PR
📦 Updates

com.thesamet.scalapb:compilerplugin
com.thesamet.scalapb:scalapb-runtime

from 0.11.13 to 0.11.14
📜 GitHub Release Notes - Changelog - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.thesamet.scalapb" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.thesamet.scalapb" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #296.

repo: sangria-graphql/sangria-federated

license_source: github-api


text:
Update scalafmt-core to 3.7.6

About this PR
📦 Updates org.scalameta:scalafmt-core from 3.5.9 to 3.7.6
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scalameta", artifactId = "scalafmt-core" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #174.

repo: sangria-graphql/sangria-jackson


text:
Balloons are not floating to the top

I added the ReactFloatingBalloons component to the mainsite of my application and the balloons start floating but were removed and restartet around the half of screenheight. Looks like that the component is rerendered.
<ReactFloatingBalloons
  count={3}
  msgText=""
/>

Any ideas how to investigate this issue further?
Thanks!

You need to set hangOnTop to true and loop to false for that. Please read documentation more carefully to understand.

authors: buhln sanishkr

repo: sanishkr/react-floating-balloons

license: MIT


text:
Build error

Hi, I've been trying to build the newest version of robyn (v0.12.1) for distributing in conda-forge, but I've been getting this error during the build process:
  error[E0308]: mismatched types
     --> src/server.rs:160:33
      |
  160 |                 .client_timeout(0)
      |                                 ^ expected struct `std::time::Duration`, found integer

I've tried conforming to the rust version in the CI to no avail. Does anyone have any advice?

Hi @thewchan .
I will be happy to help. Can you please tell me the exact steps you took in the build process?

@thewchan , I can see that one of the library functions is deprecated in the error log, which is probably why the resulting error. Can you confirm if you get the same error in the latest version, i.e. 0.13.0 . If yes, I will make a new release with the updated dependencies.

Thanks so much @sansyrox, really appreciate it. Hope this works!

Hi @thewchan , I just released v0.13.1. It is working well on my Pipeline. Can you please check if this works for you too?

Thanks, I'll give it a try and report back!

@sansyrox It built correctly now; thanks so much!

My Please @thewchan :D
Does this mean that robyn can also be installed via conda now?

Indeed; earlier versions (0.10 I think) are already available via conda install -c conda-forge robyn
v0.13.1 will take a bit for the CI to go through completely

authors: sansyrox thewchan

repo: sansyrox/robyn


text:
Team leaves tournament activity message is wrong

set team as actor of the activity

looks good

deployed.

authors: rjourde santiaago

repo: santiaago/gonawin

license: isc


text:
Issue #1

Tildar mi nombre (Agustina Serra) e incluir mi Repositorio en README.md

bárbaro @Agustinaa01, ya hice el merge a development. Bien resuelto el conflicto!


text:
🛑 KONGA_KONG_GUI_URL is down

In 6c16fca, KONGA_KONG_GUI_URL ($KONGA_KONG_GUI_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: KONGA_KONG_GUI_URL is back up in 70644c8 after 49 minutes.

repo: santomaharaj/upp


text:
🛑 KUBERNETES_DASHBOARD_URL is down

In 104b62b, KUBERNETES_DASHBOARD_URL ($KUBERNETES_DASHBOARD_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: KUBERNETES_DASHBOARD_URL is back up in ab3e078 after 51 minutes.


text:
Simulator charging station remote start request getting rejected by the ev-server

Hello team
i am trying to run ev-simulator to test
but getting the following error

logs

what may be the possible reason ?

When you do a remote start, the simulator should send an Authorize OCPP message to the backend to check the RFID card.
Is there any other logs?

repo: sap-labs-france/ev-server


text:
Investigate Bun

Bun is a JS runtime that claims to be a (near?) drop-in replacement for Node, but with faster performance.
Investigate the extent of the performance benefit to this project. If it is as fast as they claim, find out what, if anything, must be done to support it.

Seems like at least superficially, bun run index.js works seamlessly as a drop-in replacement for Node.js, as-is.
However, while Bun may have a 100ms speed advantage on spinning up the client, the difference in response performance according to wrk seems to be equivalent within margin of error / slightly worse;
node index
Running 30s test @ http://127.0.0.1:4000
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   116.77ms   15.91ms 276.52ms   91.44%
    Req/Sec   174.41     82.85   333.00     66.75%
  61820 requests in 30.09s, 673.05MB read
  Socket errors: connect 155, read 220, write 0, timeout 0
Requests/sec:   2054.44
Transfer/sec:     22.37MB

Running 30s test @ http://127.0.0.1:4000/data/updates
  12 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   159.77ms   21.25ms 374.55ms   92.27%
    Req/Sec   110.67     44.26   161.00     53.68%
  36033 requests in 30.10s, 345.10MB read
  Socket errors: connect 0, read 81, write 0, timeout 0
Requests/sec:   1197.02
Transfer/sec:     11.46MB

bun run index.js
Running 30s test @ http://127.0.0.1:3000
  12 threads and 400 connectiit ons
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   122.75ms   21.82ms 360.02ms   92.76%
    Req/Sec   165.20     80.58   333.00     72.30%
  58789 requests in 30.10s, 640.61MB read
  Socket errors: connect 155, read 101, write 0, timeout 0
Requests/sec:   1953.20
Transfer/sec:     21.28MB

Running 30s test @ http://127.0.0.1:3000/data/updates
  12 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   165.74ms   21.95ms 357.85ms   92.46%
    Req/Sec   105.26     46.23   161.00     56.71%
  34720 requests in 30.10s, 332.23MB read
  Socket errors: connect 0, read 84, write 0, timeout 0
Requests/sec:   1153.45
Transfer/sec:     11.04MB

I tried to create a bundle to see if it improved things any, but the bun bun app.js command just seemed to hang indefinitely.
In conclusion, seems like no work is needed to support Bun for users who wish to use it, but there doesn't seem to be any immediately obvious low-hanging performance advantage for us here.
Closing the issue for now - but open to reopening if there is new info in the future.

repo: saplingjs/sapling


text:
Follow-up to #1: requestBodies

I only just noticed that only part of #1 was implemented - enum names are now shown in parameter descriptions for regular GET params, but not for request body fields.

When not expanded, it shows things like "Default value" under the description:

Could the plugin add list of available variants to the same place too?

repo: sapphi-red/swagger-ui-plugin-enum-names


text:
The automated release is failing 🚨

:rotating_light: The automated release from the master branch failed. :rotating_light:
I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here is some links that can help you:

Usage documentation
Frequently Asked Questions
Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.
The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.
If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.
Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨
Your semantic-release bot :package::rocket:

:rotating_light: The automated release from the master branch failed. :rotating_light:
I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here is some links that can help you:

Usage documentation
Frequently Asked Questions
Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.
The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.
If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.
Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨
Your semantic-release bot :package::rocket:


text:
error code 150

in new oppo or vivo device it show error code 150

true , this error causes too many problems. please find a solution

sarbagyastha dear friend error code 150 and oppo rano 2F show black screen and panasonic show processing only not playing video.
please resolve drear friend as soon as possible plz plz.

plz sir rply me i m waiting ....

Please try with youtube_player_iframe.

@sarbagyastha We can't get the current video position in youtube_player_iframe  ? controller.value.position returns null.

With me, the problem was that I lowered all case on the video id, and it's case sensitive. Instead of YE7VzlLtp-4, I was sending ye7vzlltp-4.

authors: edgarfroes itssidhere prashantspandey sarbagyastha shailendra-rajpoot


text:
🛑 Tian is down

In 4f63d0a, Tian (https://www.tianaix.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Tian is back up in cf04b5e after 37 minutes.

repo: sarpaykent/uptime


text:
Which Course are are doing for simulating this algorithm?

Hi, how do you check the correctness of this algorithm? Is there a MOOC available that has an environment to run simulations of this algorithm?
Are you using any hardware to run your code?

This is a ROS workspace for checking the correctness of the obstacle avoidance algorithm you have used, for the step see README.


text:
Install multiple bindings

Is it possible to install bindings for multiple OSs? We're running into an issue where we might yarn install on a host MacOS and then run node-sass in an ubuntu VM. I searched through the issues, but didn't see a way to hint to the installer that we'd like to have bindings for multiple OSs.

Yes, you can have multiple directories in vendor with all the binding files you needed.

Awesome. I did see that I have two directories in vendor. Did I miss the flag for getting both of them at install time on a single OS?

There are no flags for this. If you do additional npm install and do not clean the build, you will accumulate bindings there. Just copy bindings manually around and you will have a full set. Remember to regency/rebuild them on node upgrade.

Great, thanks for the help

Glad to help :)

authors: greggb saper

repo: sass/node-sass


text:
Error while patching : java.io.IOException: This archive contains unclosed entries.

?? Patching /opt/sas/sashome/SASEnvironmentManager/2.5/installs/hypericsvr_lax_2.5_M3_HFE8M004/SASHome/xx/SASEnvironmentManager/2.5/server-5.8.0.tar.gz::server-5.8.0-EE/hqapi1-client-6.0.2/lib/log4j-core-2.11.1.jar
? null
? null
? null
? null
? null
? null
? null
? null
? null
? null
ERROR: Error while patching : java.io.IOException: This archive contains unclosed entries.
at org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.finish(TarArchiveOutputStream.java:291)
at com.sas.vulnerabilities.utils.ArchiveCompressUtils.compressArchive(ArchiveCompressUtils.java:108)
at com.sas.vulnerabilities.patcher.SequentialPatcher.packageNextArchive(SequentialPatcher.java:38)
at com.sas.vulnerabilities.patcher.SequentialPatcher.packageNextArchive(SequentialPatcher.java:41)
at com.sas.vulnerabilities.patcher.SequentialPatcher.patchSingleCVE(SequentialPatcher.java:58)
at com.sas.vulnerabilities.patcher.SequentialPatcherInventoryTask.runSingleCveInventoryPath(SequentialPatcherInventoryTask.java:68)
at com.sas.vulnerabilities.patcher.SequentialPatcherInventoryTask.run(SequentialPatcherInventoryTask.java:93)
at lukfor.progress.tasks.Task.call(Task.java:39)
at lukfor.progress.tasks.Task.call(Task.java:1)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519)
at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)

@boemska-nik is there any update?

What OS / version is this with, and what was the full command line you ran & with what user?

Hi @sridharamirneni,
Coming back to this. We weren't able to replicate this issue, but it could be resolved by the 3.2.0 release because of the changes that were made to the repacker. Are you able to test this release and let us know if you still face this issue?

authors: boemska-nik sridharamirneni

repo: sassoftware/loguccino


text:
Added custom steps for text classifers

Please include answers to these questions as part of your pull request
In the GitHub webUI, use the Write tab to modify the Markdown text that is part of the pull request. For each question simply place an X inside the square brackets, [X], that represents your answer. Make sure there are no blanks inside the brackets, otherwise MarkDown doesn't render properly. Using the Preview tab while editing this form, you can see the formatted/rendered version of the message.

Q1: Confirm that you have the right to submit the code that is being contributed. Please consider the origin of your code and confirm you have the appropriate rights to make the submission subject to the Apache 2.0 license that applies to everything in this repository of custom steps. If so, follow the instructions for the Contributor Agreement (which is based on the industry-standard Developer Certificate of Origin (DCO)).

[X] Yes, I have the right to submit the contributed code on behalf of myself, my company, or any other owner of the code. I have also attached my signed copy of the DCO to this message.
[ ] No

Q2: Confirm that your contribution does not include any personally identifiable information (PII), for example, in any examples used in your README file.

[X] My contribution does NOT include PII data
[ ] My contribution includes PII data

Q3: Confirm your contribution does not include any encryption or other export-controlled technology.

[X] My contribution does NOT contain encryption or other export-controlled technology
[ ] My contribution includes encryption or other export-controlled technology

ContributorAgreement.txt

Hi @snlwih , I have addressed feedback sent via email.  In brief,

Used official SAS product names in README and about
"bullets in section Output table specifications and Documentation are rendered as a numeric list. Could you fix this?" : it's still likely that I have not grasped what exactly you asked for here.  If you don't mind making a correction directly (in case I did something different)?  Thanks.
Additional code block to account for gpuEnabled (the check box) being checked or not, and handling numDevices subsequently
Macro to check for the caslib engine of the libref being provided, and handling code accordingly.  Note, a future improvement may help us decide exactly on the type of abort / exit statement we may need to implement.  For now, I have relied only on essential input tables (the training table for the training step, and the input table for the scoring step).

SAS Internal Due Diligence Review - COMPLETED on 27MAR2023

authors: SundareshSankaran snlwih

repo: sassoftware/sas-studio-custom-steps


text:
Hotfix master - Fix Sass syntax issue with placeholder-in-extend rule

placeholder-in-extend rule doesn't work with Sass syntax. This fixes that issue.
Fixes #199
DCO 1.1 Signed-off-by: Ben Griffith gt11687@gmail.com

Oh damn mistakenly merged develop - closing!

repo: sasstools/sass-lint


text:
dataset ?

Hi can you provide link of the dataset you used? thank you

Hello
The dataset used is multispectral images from LandSat8 satellite, it is publicly available


text:
Solution for the problem A tic-tac-toe where X wins in the first attempt!

Please provide how can one create a tic tac toe with correct pythonic way.
https://github.com/satwikkansal/wtfpython#-a-tic-tac-toe-where-x-wins-in-the-first-attempt

Done :smile:

repo: satwikkansal/wtfpython

license: WTFPL


text:
Locale persistence + minor bugfixes

Closes #313

On web it works great. Url to nl is preserved. Some mixing text but that's prob cuz there aren't translations for it yet.
Mobile designs seemed to have been affected though. Sizing isn't correct.

On web it works great. Url to nl is preserved. Some mixing text but that's prob cuz there aren't translations for it yet.
Mobile designs seemed to have been affected though. Sizing isn't correct.

I think this is unrelated to this PR as the same behavior is visible on the live website - https://savingsatoshi.com/nl/chapters/chapter-1/intro-2 (might be due to the missing translation)

Yes there are some missing translations for nl currently.

authors: afterburn benalleng ecurrencyhodler vinayaksh42

repo: saving-satoshi/saving-satoshi


text:
🛑 cubeent is down

In c58c9b2, cubeent (http://www.cubeent.co.kr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cubeent is back up in 3d97503 after 11 minutes.

repo: savorfamily/upptime


text:
🛑 cubeent is down

In a896058, cubeent (http://www.cubeent.co.kr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cubeent is back up in ca2e445 after 10 minutes.


text:
The 'elm-make' compiler is not available.

I get this error every time I save a file, however it does build...
On Mac, OSx

I also get this if I change the "elm.makeCommand": "elm-make" setting. I wanted to have warnings ("elm.makeCommand": "elm-make --warn") and that gives me the same error you mentioned.

I also have this error, Arch Linux. I cannot build either, though.
Elm and related things such as elm-make are available in my $PATH.

In my case, using Ubuntu 16.04, I solved it by setting the path in the .bash_profile file. It seems that vscode uses it. If you set it only in your .bashrc you may see it in your path when using the terminal but vscode will miss the path and you'll get the error.

This can be fixed either by adding elm-make to $PATH or by setting elm.makeCommand

Somehow elm-format and elm-make are not visible in vscode, even though are in $PATH.
I needed specify full paths in settings:
{
    "elm.formatCommand": "/Users/user/bin/elm-format",
    "elm.makeCommand": "/usr/local/bin/elm-make"
}

authors: Krzysztof-Cieslak Xananax chalmagean robertohuertasm rofrol tjbo

repo: sbrink/vscode-elm


text:
crossTarget should be "scala-${scalaVersion}" when CrossVersion.full

steps
sbt version: 1.3.0
 > show scalaVersion
[info] 2.12.8
 > show crossTarget
[info] /Users/kenji/some-project/target/scala-2.12
 > set crossVersion := CrossVersion.full
 > show crossTarget
[info] /Users/kenji/some-project/target/scala-2.12

problem
crossTarget is target/scala-2.12 when crossVersion := CrossVersion.full
expectation
crossTarget should be target/scala-2.12.8 when crossVersion := CrossVersion.full 🤔
I think these should not share any *.class file caches.
notes

https://github.com/sbt/sbt/blob/v1.3.0/main/src/main/scala/sbt/Defaults.scala#L483-L489
https://github.com/sbt/sbt/blob/v1.3.0/main/src/main/scala/sbt/Defaults.scala#L536-L539

workaround
  crossTarget := {
    target.value / s"scala-${scalaVersion.value}"
  }

If scalaBinaryVersion is supposed to denote the binary compatibility, in theory, that setting should also be changed but it's probably too late for that. I am fine with just changing crossTarget or any other things of this nature.

@eed3si9n with the crossTarget workaround and a simple project like:
lazy val root = (project in file(".")).settings(
  inThisBuild(
    List(
      organization := "com.example",
      scalaVersion := "2.12.10"
    )
  ),
  name := "scalatest-example",
  crossTarget := target.value / s"scala-${scalaVersion.value}",
  crossVersion := CrossVersion.full,
  crossScalaVersions := Seq("2.12.9", "2.12.10")
)

when doing:
++2.12.9
compile
++2.12.10
compile

The second compile will remove the classes under 2.12.9 directory. Any idea how to solve that? It causes a lot of additional recompiles.

The second compile will remove the classes under 2.12.9 directory. Any idea how to solve that? It causes a lot of additional recompiles.

We want all of them to recompile if Scala version changes (I think), so it's working as designed.

@eed3si9n  Shouldn't it be the same situation as with different binary versions?
If I change to 2.11.12, recompile, change back to 2.12.10, not recompilation is done.
However, if I change to 2.12.9 and back, the code is always compiled.
The target directories are totally separate, so what would be the reason to remove one belonging to a different Scala version? The only common thing here is the input source files, the same as with different binary versions.

The second compile will remove the classes under 2.12.9 directory. Any idea how to solve that? It causes a lot of additional recompiles.

@tgodzik Sorry I didn't read your description carefully earlier. I agree that we need to improve the behavior around transaction class manager, assuming that's doing the deletion.

@eed3si9n I can try to have this fixed if you point me at the direction? :smiley:

The classfile manager code is here -
https://github.com/sbt/sbt/blob/v1.3.8/main/src/main/scala/sbt/Defaults.scala#L652-L665, which looks ok.
Maybe the culprit is the Analysis file name https://github.com/sbt/sbt/blob/v1.3.8/main/src/main/scala/sbt/Defaults.scala#L606-L614
you could try defining a scripted test scenario like https://github.com/sbt/sbt/tree/develop/sbt/src/sbt-test/actions/cross-incremental, and then maybe try changing the Analysis file name to include the full Scala version.

Thanks! Will try to look

@eed3si9n Sorry I haven't managed to take a look at it, but... It's fixed in 1.4.1! So I think we can close it :rainbow:

Some aspects of Zinc may have improved because of virutalization, but overall I think this bug still stands because it's about changing the crossTarget directory.

Right, but we do change crossTarget directory and it seems that the directories are no longer needlessly removed, so it does look like fixed. How else would this bug show up?

The original issue is that sbt should use target.value / s"scala-${scalaVersion.value}" out of box when cross is full?

In sbt 2.x target contains full Scala version, so we can probably call this done.

authors: eed3si9n tgodzik xuwei-k

repo: sbt/sbt


text:
Bump up to lm X11

Which replaces SbtExclusionRule with ExclusionRule.

s/util/lm/.

I will do a syntactic rewrite for this in sbt-migration-rewrites. I think this is ready to merge. Mind having a look @dwijnand ?


text:
Replace olafurpg/setup-scala with actions/setup-java

https://github.com/olafurpg/setup-scala/releases/tag/v14 is deprecated and migration to actions/setup-java is encouraged. That action is already used in ci.yml

Hi @mzuehlke,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
https://www.lightbend.com/contribute/cla

Should I create dedicated pull-requests to address the 1.8.x and develop branch. Or are you just merging / cherry-picking commits to the other branches.
I don't know what is best.

authors: lightbend-cla-validator mzuehlke


text:
add ip_address to search fields, add db index

I need to search ip address and improve search performance.

@scailer Please check this.

repo: scailer/django-user-activity-log


text:
Bug with java.util.LinkedList.size when larger than Int.MAX_VALUE.

If the size of the LinkedList is larger than Int.MAX_VALUE the then size should return Int.MAX_VALUE.
The current implementation uses a var _size: Int to track the size and updates it with _size += 1 which loops back to Int.MIN_VALUE when the list grows to a size of Int.MAX_VALUE + 1.

It seams that LinkedList does not require constant time size computation.
I would propose to change every if (_size <= 0) ... with if (isEmpty) ..., remove the field private var _size along with all updates to it and redefine the size as:
override def size(): Int =
  iterator().take(Int.MAX_VALUE).size

the javadocs refer to limit on sizes explicitly for throwing exceptions:
http://docs.oracle.com/javase/7/docs/api/java/util/LinkedList.html#add(int, E)
so in LinkedList the use of _size is correct

maybe the bug must be fixed only on ConcurrentLinkedQueue, and I'm going to do that!

The problems are with the other add (as well as addFirst and addLast), the ones that do not take an index.

And that exception is for the input index, not for the size.

My previous solution is quite inefficient because it requires recomputing the size each time. The new approach is to convert the _size to a Double.
private var _size: Double = 0.0
...
override def size(): Int =
  _size.toInt

and replace the if (_size <= 0) by if (isEmpty)

actually addLast and addFirst doesn't make any check on size...
btw I will check which number generates my jvm on int overloads

btw I will check which number generates my jvm on int overloads

If it doesn't give Int.MinValue for Int.MaxValue + 1, your JVM is buggy ;-) This is part of the JVM specification, the Java Language Specification, as such also of the Scala Language Specification, and even true in the Scala.js Semantics.

I obviously mean what will happens into a java.util.LinkedList when adding an element over MaxValue

Just to satisfy that:
http://docs.oracle.com/javase/7/docs/api/java/util/Collection.html#size()
I will check that every increment of _size will not do anything if _size == Int.MaxValue

That doesn't work, because you can first add MaxValue elements, which brings, _size to MaxValue. Then add an element--_size remains MaxValue--then remove an element -> _size decreases to MaxValue - 1 but there are MaxValue elements in the collection.
I believe the Double solution is the best one. Doubles are only marginally slower than Ints in Scala.js, and have full precision until 2^53.

Why is this labeled "missing javalib"? I think this is misleading. (I'd consider "missing javalib" as a replacement for "enhancement" for missing java libraries).

authors: andreaTP gzm0 nicolasstucki sjrd

repo: scala-js/scala-js


text:
Fix #2734: Allow @JSExportTopLevel on classes and objects.

This commit implements the Proposal #2734. The annotation @JSExportTopLevel can now be used on static classes and objects (both Scala classes/objects and Scala.js-defined JS classes/objects) to export them at the top-level.
For objects, the difference wrt. @JSExport is that the module instance itself is exported, rather than the module accessor.
For classes, this is equivalent to exporting them via @JSExport. We include the possibility to be consistent with objects, and with the prospect of deprecating and removing @JSExport on classes and objects altogether.

Review by @gzm0

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3644/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4806/
Test PASSed.

Since #2720 was rejected, this should be updated to also allow @JSExportTopLevel on Scala classes and objects.

Updated.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3656/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4822/
Test PASSed.

Updated with a few more details in Scaladoc.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3660/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4833/
Test FAILed.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3661/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4835/
Test FAILed.

Dear Jenkins, retest this please

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3662/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4836/
Test FAILed.

Dear Jenkins, retest this please

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3663/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4838/
Test FAILed.

I think we have a deterministic JVM OOM on the bootstrap test + Node.js 6 that was installed on CI breaks other stuff.
The OOM seems to be simply that the test suite passed a critical size that makes optimizing it and the tools in fullOpt require too much memory. We should try giving more memory to that process.
The Node.js 6 stuff I'll investigate next week, when I'm back from vacation.

Testing with 4G given to sbt on the CI config.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3665/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/4842/
Test PASSed.

authors: gzm0 scala-jenkins sjrd


text:
suspicious scala-xml dependencies

are these outdated scala-xml dependencies in common.conf actually necessary? they aren't commented, so they have the look of something that just got kept by accident. we'd have to investigate
in two places:
commands += "set libraryDependencies += \"org.scala-lang.modules\" %% \"scala-xml\" % \"1.0.0-RC6\""

the browse one is eliminated in my draft changes addressing https://github.com/scala/community-builds/issues/300

and the scalatest one got fixed in the 2.12 build when we moved to ScalaTest 3.0.

repo: scala/community-builds


text:
generated example for objects is wrong

Description
We are using Hono for the API, and Hono Zod Openapi to generate the OpenAPI specs.
When creating a field that is a Record<string, unknown>, Scalar generates an example with the shape: field: {}.
However, when creating a field that is a Record<string, string>, Scalar generates an example with the shape: field: ""

In the second case, the example is not valid since the field is not a string.
Expected behavior
It would be useful to have examples of keys and values when an object is defined. Also, maybe an empty object as an example could be confusing, since in most of the cases an empty object would not be a valid input and the field could be nullable.
Redoc (example)

Does it make sense?

Steps to reproduce

Add @scalar/hono-api-reference to the project;
Add OpenAPI fields to the OpenAPI json schema.

Package version
{
    "@scalar/hono-api-reference": "^0.3.56",
}

OpenAPI fields
{
  "additionalAttributes": {
        "type": "object",
        "nullable": true,
        "additionalProperties": {
            "nullable": true
        },
        "description": "Atributos adicionais do item segurado. **O campo será removido futuramente, utilize o campo metadata**.",
        "deprecated": true
    },
    "metadata": {
        "type": "object",
        "nullable": true,
        "additionalProperties": {
            "type": "string",
            "minLength": 1,
            "maxLength": 500
        },
        "description": "Metadados do item segurado: você pode especificar até 50 chaves, com nomes de até 40 caracteres e valores de até 500 caracteres.",
        "maxItems": 50
    },
}

Originally posted by @Amorim33 in https://github.com/scalar/scalar/discussions/1051

@Amorim33 wants to work on this ✌

repo: scalar/scalar


text:
chore: remove @scalar/use-modal package

Removes the @scalar/use-modal package and migrate all usages to ScalarModal in @scalar/components.
@hanspagel has already deprecated the NPM package.
There's a couple issues still with scrolling the search modal and history modals but I think those should be fixed in #2015.
This is at least an improvement since the modals actually render on screen again.

LGTM lets go

authors: geoffgscott hwkr


text:
Turn off invitation creation routes

I'm currently writing a system with 3 separate user types/tables. These roles allow type1 to invite types1,2,3 and type2 to invite types2,3.
I'd like for them all to be able to accept invites still, but I've created separate invite actions / controllers to limit everything down, so I'd like to turn off the default routes for creating invitations on devise_for :patients
Any ideas how to turn off creating invitations there but still allowing invitations to be accepted?
Thanks!

Probably you will have to add invitations routes by yourself, using:
devise_scope :patient do
  get :edit, :path => 'accept', :as => :accept
  put :update
  get :destroy, :path => 'remove', :as => :remove
end

I was afraid of that. Thanks for the tips.

For some reason Rails didn't like that pathing information, so I ended up with this verbose nastyness:
get 'patients/invitation/accept', to: 'devise/invitations#edit', as: :accept_patient_invitation
put 'patients/invitation', to: 'devise/invitations#update', as: :update_patient_invitation
get 'patients/invitation/remove', to: 'devise/invitations#destroy', as: :remove_patient_invitation

Maybe path is only valid inside a resources block, I guess devise_for process path or use a resources block.

I'm trying to achieve something similar, I know that I can add the routes manually as described above, but how do I then disable the invitation routes that are created by default?

@fredkelly I believe it's the same way as turning off devise paths:
devise_for :users, :skip => [:registrations]

Perfect, thanks Dan!

authors: fredkelly scambra toobulkeh


text:
testing new git account

Test using private GitHub account

.

authors: mmexvr theJohnnyMe

repo: scania-digital-design-system/sdds


text:
Move the Docker configuration to docs/ directory.

I just find it weird that there are now docker and docker-compose files in the root of Tasks, which don't actually run or build Tasks (or Obsidian). Would it make more sense to move the docker stuff into the ./docs directory?

Originally posted by @schemar in https://github.com/schemar/obsidian-tasks/issues/645#issuecomment-1120172926

I tried to move them to the docs dir - and after 5 or 10 minutes of experimenting, I could not get a working server that showed the content, so sorry, as relative Docker and Jekyll novice, I gave up.
I’d love it if someone else could fix that.
It would mean:

Moving Dockerfile and docker-compose.yml to the docs/ dub-directory
Updating them so that they serve the site correctly
Updating  the docker-compose up docs in docs/README.md for the new location.

repo: schemar/obsidian-tasks


text:
Update README.md

test

/azp help

/azp help


text:
Allow duplicate rescanning

Setting for timeout between duplicates (e.g. 5 seconds)

Fixed with de7b9e33b9429e5b9b2e8fa0632f1209552f6d19.

repo: schmich/instascan


text:
Implement private class gui::views::ControlView::_CtrlTarget (cpp)

This is a sub-task of #237 .

Partially implemented; Compiles.
Still to be completed then tested.

repo: schmouk/ArcheryVideoTraining


text:
Basic Implementation of Lazy Modules, Plugins

At long last, here it is: plugins as I originally envisioned them.
In order to achieve this, I had to also add "lazy modules" as a concept. That is, modules who defer lookups on their contents until they are accessed. Currently such modules can only be implemented in plugins,  but that is an accident of the implementation. I tried to make sure the concept could be extended later if it was useful.
The way I integrated "lazy modules" into the existing module code is rather ugly. Suggestions or cleanup fixes afterwords are welcome (so long as my one new test does not break).

I've made some comments into the code.  The No.1 suggest I can make is not to separate the two module types, but to unify them, if it is possible at all.  For example, make normal modules a subset of a super Module type - they just eager-load instead of lazy load.  The user, and the rest of the program, doesn't really need to care.  This way, it provides maximum flexibility to the future.
If the two module types cannot be merged (I don't see why we can't), then at least merge them into one single Union type.  Then you avoid most of the duplicated code in the rest of the program.  For example:
enum SuperModule {
    EagerModule(Module),
    LazyModule(LazyLoadedModule)
}

Union::Module(SuperModule)

This way, the code can be simplified as:
let module = scope.get_module(index)........

match module {
    Dynamic(Union::Module(EagerModule(m))) => { ... }
    Dynamic(Union::Module(LazyModule(m))) => { ... }
}

Please look at https://github.com/schungx/rhai/pull/13
That PR adds an abstraction NativeCallable which you can then implement for your lazy-loaded functions to hook directly into the function calling mechanism.

I finally have time to get back to this.
I have just rebased onto #13, and will make the two changes you suggest soon.

The No.1 suggestion I can make is not to separate the two module types, but to unify them, if it is possible at all.

I agree, but I created the implementation separately, because the current API provided by modules is too complex to merge.

The hashes are returned to other parts of the engine, as part of the public API of the Module struct.
There is not only set_fn, but then set_fn_1 and set_fn_1_mut.
There are a ton of utility functions like contains_fn and index_all_modules, which rely on everything being dynamic.

I would like to bridge the two implementations by making Module into a trait, but that seems tricky. I can only imagine something like:
enum LookupResult {
    StaticallyLoaded(u64), // statically loaded, the hash used for lookups
    DynamicallyLoaded // return code meaning: call lazily instead
}

trait Module {
    // the lookup functions
    fn lookup_var(name: &str) -> Option<&Dynamic>;
    fn lookup_fn(name: &str, args: Iterator) -> Option<LookupResult>;
    fn lookup_recv_fn(name: &str, first_arg: &mut Dynamic, args: Iterator) -> Option<LookupResult>;

    // the dynamic invocation functions. non-lazy modules may return None
    fn call_fn(name: &str, args: Iterator) -> Option<Result<Dynamic, EvalAltResult>>;
    fn call_recv_fn(name: &str, first_arg: &mut Dynamic, args: Iterator) -> Option<Result<Dynamic, EvalAltResult>>;

    // return a table of static items. dynamic modules return an empty one
    fn get_static_items(&self) -> &HashMap<u64, Box<dyn NativeCallable>>;
}

Achieving that is a lot more rework than I think I could achieve. I have not dug far enough into the way modules work, except to see that it's really complex and code across multiple places.
What do you think? Do you have extra groundwork you can do to help me? Or should I take another approach to unifying them?

Oh, and NativeCallable doesn't help me, because that is just a return type for the lookup functions. I need a trait for the actual looking up that wraps/abstracts the entire lookup process, including the hashing.

I did read your other thread, where you said:

Aside from being simpler for me to understand, having a code-based lookup -- call this function, don't worry about what it does -- allows better flexibility and options for optimization in the future.
This is a great idea. We can simply modify FnAny to be a struct that implements that trait and have all module functions return a trait object. [...] The more I think about this, the more this is beautiful.

So I'm presuming that this means you don't want hashing to be part of the public API for module-like items, even if (as you say there), lazy-loaded modules still do that. Or is this incorrect?
If it is, then I worry I don't have enough bandwidth to get much further on this without more guidance...

That's right.  I consider hashing an internal implementation details to speed up lookup's of loaded functions.  It is an internal indexing step.
The plugin writer really should not care about the hashes.  They should provide the normal information to the engine: function name, list of parameter types, and the ABI type.  The engine should load the plugin file, index all the functions internally using this information.
So I'd expect your plugins API to expose those data instead of directly hashing them.  The engine can hash.
Or, alternatively, I can provide a standard black-box API function to do the hashing and return a key for the plugin function.  But I still think it is best to keep the hashing internal to the engine, as we can then have plugins compiled for different versions of Rhai.

That makes sense. However, the current modules implementation is difficult for me to understand.
If I understand correctly, you are thinking a trait like this could be used by the engine:
trait Module {
    /// Iterate over the functions inside this module known at load time.
    ///
    /// Some modules may be lazily loaded, so not all functions in a module may be returned.
    fn static_fns<'s>(&'s self) -> Box<Iterator<Item=NativeCallable> + 's>;

    /// Iterate over the constants inside this module known at load time.
    ///
    /// Some modules may be lazily loaded, so not all constants in a module may be returned.
    fn static_consts<'s>(&'s self) -> Box<Iterator<Item=ScopeEntry> + 's>;

    /// Look up a function dynamically.
    ///
    /// Functions may pass a first argument as a mutable receiver. If this is not done, the second argument is None.
    ///
    /// May return a callable which was not in `static_fns`, if the function was lazily loaded.
    fn lookup_fn(&self, receiver_arg: Option<&mut Dynamic>, args: &[Dynamic]) -> Option<NativeCallable>;

    /// Look up a constant dynamically.
    ///
    /// May return a callable which was not in `static_fns`, if the function was lazily loaded.
    fn lookup_fn(&self, mut_first_arg: Option<Dynamic>, args: &[Dynamic]) -> Option<NativeCallable>;
}

With this, the engine could still do the hashing in advance for static modules, and if there was no hash found, try a dynamic call before deciding, "module not found."
If that sounds good, it would really help me if you could make current modules in src/modules.rs work by implementing this trait, or something similar. I could then do the unification after a rebase.

Yeah, something like that.  However, the actual function names in the trait probably should match what already exists so the code doesn't need to change much, only changing from Module type to a trait object of dyn Module.
Also, I have removed the NativeCallable trait based on your observations.  Reintroduce it if you think it is necessary, or otherwise just return a NativeFunction type instead, which is a simple wrapper of a Boxed function pointer and an ABI type enum.
I always have difficulty understanding the 'lazy-loading" bit and why it prevents things from being pre-generated and pre-compiled.  Rust is a compiled language, so when the "lazy-load" module is loaded, it already contains all the function implementations.  There really is nothing to "lazy-load", except for the module library file itself.
I think I consistently fail to understand why handles cannot simply be pre-generated (or generated once during module loading time) for all functions in the module.  You just need to avoid having your proc macro generate a large match statement on function names and argument types, but instead generate code to hash the function, then insert it into a HashMap.  A simple implementation is to use a Vec to hold all the macro-generated functions.  The "handle" in this case is simply the Vec offset.   When I load your module for the first time, pass me a reference to that Vec and I can index everything in one go.

Yeah, something like that. However, the actual function names in the trait probably should match what already exists so the code doesn't need to change much, only changing from Module type to a trait object of dyn Module.
Also, I have removed the NativeCallable trait based on your observations. Reintroduce it if you think it is necessary, or otherwise just return a NativeFunction type instead, which is a simple wrapper of a Boxed function pointer and an ABI type enum.
I always have difficulty understanding the 'lazy-loading" bit and why it prevents things from being pre-generated and pre-compiled. Rust is a compiled language, so when the "lazy-load" module is loaded, it already contains all the function implementations. There really is nothing to "lazy-load", except for the module library file itself.
I think I consistently fail to understand why handles cannot simply be pre-generated (or generated once during module loading time) for all functions in the module. You just need to avoid having your proc macro generate a large match statement on function names and argument types, but instead generate code to hash the function, then insert it into a HashMap. A simple implementation is to use a Vec to hold all the macro-generated functions. The "handle" in this case is simply the Vec offset. When I load your module for the first time, pass me a reference to that Vec and I can index everything in one go.   Something like:

trait Module {
    :
   fn get_functions(&self) -> Box<dyn Iterator<Item = FnSpec>>;
    :
}

So, a restructure will first introduce a Module trait.
Then the existing Module type will be split into separate types:

ScriptModule for modules with script code.
NativeModule for current code in packages loaded into the global namespace - replace with your plugin later on, essentially loading the plugin under the global namespace
PluginModule for your plugins in native code, loaded into modules namespace

This will unify everything very nicely, and a single call_fn method on the trait.  When I do a function call, I just scan through the list of modules one by one, calling call_fn on each, until one returns a result.  This way, I no longer need to care about where the function comes from.

I always have difficulty understanding the 'lazy-loading" bit and why it prevents things from being pre-generated and pre-compiled.

I am sorry for imprecision in my language. It is difficult to know what to focus on with my naming and word choice, given our sprawling and meandering conversation.
The laziness was not for loading, but for looking up names. That was not a strict requirement, so much as a "I can't figure out how to deal with all this hashing stuff and heap allocated stuff" requirement for me to get it working.
To try and refocus a bit, let me go back to the original test plugin in my PR:
// A simple custom plugin. This should not usually be done with hand-written code.
#[derive(Copy, Clone)]
struct AddOffsetPlugin(INT);

impl AddOffsetPlugin {
    fn add_offset(&self, x: INT) -> Dynamic {
        Dynamic::from(x + self.0)
    }
}

impl Plugin for AddOffsetPlugin {
    fn register_contents(self, engine: &mut Engine) -> (String, Box<dyn LazyModuleDispatcher>) {
        engine.register_fn("get_mystic_number", || { 42 as INT });
        (format!("Add Offset::{}", self.0), Box::new(self))
    }
}

impl LazyModuleDispatcher for AddOffsetPlugin {
    fn call<'e>(&'e self,
            fn_name: &str,
            mut args: Box<dyn Iterator<Item=Dynamic> + 'e>
    ) -> Option<Result<Dynamic, EvalAltResult>> {
        if fn_name == "add_offset" {
            if let Some(x) = args.next().and_then(|b| b.try_cast::<INT>()) {
                Some(Ok(self.add_offset(x)))
            } else {
                None
            }
        } else {
            None
        }
    }
    fn clone_boxed(&self) -> Box<dyn LazyModuleDispatcher> {
        Box::new(*self)
    }
}

This is the structure I want to achieve:

A trait in Rhai to define a plugin
User code as regular Rust functions, and later perhaps types
Procedural macro code to generate AddOffsetPlugin, a type which implements the trait and pastes in calls to the user code.

So:

I think I consistently fail to understand why handles cannot simply be pre-generated (or generated once during module loading time) for all functions in the module. You just need to avoid having your proc macro generate a large match statement on function names and argument types, but instead generate code to hash the function, then insert it into a HashMap.

The answer is purely: I couldn't figure it out. If you can re-write it so that:

A HashMap is kept in the plugin struct
The register_contents will hash everything before returning itself
The call impl will look at the hash map instead of a switch

I would be fine with that, if the test passes. I just can't do it.

The sprawl and volume of our conversations is also why I am having trouble with the other thread. I feel like we are getting further away from what I have in mind, rather than closer.
I'll probably stick to this one for a while.

The laziness was not for loading, but for looking up names.

This is the exact place where I fail to understand.  Looking up a function by name is always necessary, because Rhai is a dynamic language and not statically linked.  In this definition, all function calls in Rhai are lazy.  The hashing is simply a means to speed up the lookup process by avoiding massive string comparisons (because you'll need to compare the parameter types also).

if fn_name == "add_offset" {

This is exactly the lookup that hashing is trying to prevent.  Essentially what you're doing is, for every single function call, scan through the entire plugins space (all those that are loaded).  Then match strings one by one until you find one that matches.  Repeat.
I'll propose a slight modification to your scheme below.

This is a slightly modified version of LayModuleDispatcher:
// A simple custom plugin. This should not usually be done with hand-written code.
#[derive(Copy, Clone)]
struct AddOffsetPlugin(INT);

impl AddOffsetPlugin {
    fn add_offset(&self, x: INT) -> Dynamic {
        Dynamic::from(x + self.0)
    }
}

impl Plugin for AddOffsetPlugin {
    fn register_contents(self, engine: &mut Engine) -> (String, Box<dyn LazyModuleDispatcher>) {
        engine.register_fn("get_mystic_number", || { 42 as INT }); // plugins can have side effects too
        (format!("Add Offset::{}", self.0), Box::new(self))
    }
}

use crate::utils::some_magic_fn_provided_by_rhai;

impl LazyModuleDispatcher for AddOffsetPlugin {
    fn make_key(&self) -> u64 {
        // Use the function name and parameter types list to generate a key
        some_magic_fn_provided_by_rhai("add_offset", &[TypeId::of::<INT>()])
    }

    // Just return result.  When it gets to this point, the function call is already correct.
    fn call<'e>(&'e self,
            fn_name: &str,
            mut args: Box<dyn Iterator<Item=Dynamic> + 'e>
    ) -> Result<Dynamic, Box<EvalAltResult>> {    // Box the error to make return footprint small
            if let Some(x) = args.next().and_then(|b| b.try_cast::<INT>()) {
                Ok(self.add_offset(x))
            } else {
                Err(...)
            }
    }
    fn clone_boxed(&self) -> Box<dyn LazyModuleDispatcher> {
        Box::new(*self)
    }
}

Thanks for the clarification, and the re-design! That actually helps a lot! And, the resulting form looks like something I know how to generate procedural macro code for. Exporting an entire Rust type might be trickier, but I'll deal with that when I get there.
I will happily re-write my PR to look like that, renaming LazyModuleDispatcher to PluginFunction. I should be able to do some merging as you suggest afterwards.
By the way, the plugins branch seems to have a different set of changes on it than I was expecting (e.g. in the other pull request to master). Could you make sure it's up to date, so I can build my PR on top of it?

By the way, the plugins branch seems to have a different set of changes on it than I was expecting (e.g. in the other pull request to master). Could you make sure it's up to date, so I can build my PR on top of it?

OK!

I've tried to do a little merging, but did not get too far. Partly due to implementation, partly due to uncertainty about direction. I have updated my PR with a non-functional WIP.
This version has a unit test which illustrates two different approaches for a Plugin to register a function.

For euclidian_distance, I wrapped the native function in an Rc<Any> closure which does the type conversions. While this would probably work within your current framework and is a small change, I find it less ergonomic and more repetitive. In particular, despite declaring all the TypeIds of the arguments, the closure has to cast them all anyway.

A native function with the new PluginFunction trait. I added a new method is_varadic just to demonstrate what power I think this could have to really expand the language. You can't write a varadic function in Rhai, but with an engine tweak or two, you possibly could.

Also note: I've had to hack the visibility of a number of items in order to get this working. I think that will need to be rearranged in order to allow plugins to be written outside of Rhai itself.
What do you think? I think option 2 will be lower overhead in the end if it could be added to modules (that's the part I'm stuck on), but I will give up on it and go with 1 if you don't have an easy fix.

Let me read thru your examples first.  If at all possible, let's do No.2 which I believe will be faster in terms of implementation.
My idea is to eventually replace all modules/packages code with your plugins system, thus everything is a plugin.  Right now, packages are already implemented as modules, and the modules code is isolated so that I can replace it with an interface to your plugin later.

I think it is quite fine, actually!  Some catches:
Firstly, a function accepting variant types.  This is going to be against the entire Rhai architecture, otherwise Rhai can support generics without having to manually register implementations.  The core of Rhai's function-calling mechanism is detecting the actual types of parameters (wrapped in Dynamic) and call the correct function.
Secondly, variable number of arguments.  This can probably be done easier, as I can simply do some magic on the parser side to convert an arguments list into a &[ Dynamic ].  Functions are already called this way, except that right now the individual arguments are extracted and passed by position.  There needs to be a setting marking a function as variadic, and simply omit this unwrapping.
So, if we make variadic functions always taking &[ Dynamic ], this will solve your problem.
However, in your example, I still think it'll be faster if the user registers multiple copies of the same generic function with supported types (in your example you supports INT and FLOAT).  Instead of dynamically switching between the two inside the same function, which is going to be slow, register two versions of a single generic function.

Hmm. I was thinking of particular int/float promotion behavior when I wrote it, which is why I did it that way... but really, varadic functions are actually a secondary concern. I was really hoping to demnostrate that plugins could do things that Rhai itself did not support (with minimal core improvement).
Based on your comments, I will put sum aside for the moment, re-write euclidean_distance into Option 2 format, and finish up the module and engine work needed to make that work.
The next version will be a bit messy, but should be merge ready (or at least pretty close). In particular, I hope once it merges, it will be enough for you to start migrating internal things to use plugins.

I was thinking of particular int/float promotion behavior when I wrote it

Ah.  Now I understand.  That's a good thought.
Right now, one of the pain points of Rhai is supporting only one integer type and one floating point type, with no automatic conversions between the two, and no automatic upcasts for other integer types.
This is not at all uncommon in scripting languages.  For most modern scripting languages, there is only one number type - floating point.  Rhai is unusual in that it supports two...
On the other hand, bringing automatic up-conversion for number types will require an expansion of the manual (i.e. the README) and reduce speed of most numeric operations because the engine always needs to do type checks every time.

I have updated my WIP. Now my problem is, the hashing does not cause my function to be found.
When I put in debug statements for the hashing and the lookups, it seems that the hashes never appeared anywhere the engine was looking.
This is admittedly a pretty simple implementation, but the hashing infrastructure made me think I didn't need anything else. Do you have any idea what I missed?

<snip>

[src/module.rs:274] (&name, hash_fn) = (
    "trim",
    13367664171665135343,
)
[src/module.rs:274] (&name, hash_fn) = (
    "get_mystic_number",
    2080782379631061082,
)
[src/module.rs:274] (&name, hash_fn) = (
    "euclidean_distance",
    5861223951096452991,
)
[src/module.rs:529] (name, hash_fn_native) = (
    "euclidian_distance",
    12541146500469585741,
)
[src/module.rs:530] self.all_functions.keys().collect::<Vec<_>>() = [
    10908691540684989219,
]
[src/module.rs:529] (name, hash_fn_native) = (
    "euclidian_distance",
    4519245633418098358,
)
[src/module.rs:530] self.all_functions.keys().collect::<Vec<_>>() = [
    10908691540684989219,
]
Error: ErrorFunctionNotFound("euclidian_distance", 0:0)

There is one mega hashing function instead of different ones for different occasions, so you'll have to pass in the correct parameters.
calc_hash_fn( None, fn_name, num_args, Iterator<TypeId>)

This is what you'll want to pass in for a straight function with known number and types of arguments.

There is one mega hashing function instead of different ones for different occasions, so you'll have to pass in the correct parameters.

I just called set_fn; isn't that the correct parameters?
pub fn set_fn(&mut self, name: String, access: FnAccess, params: &[TypeId], func: CF) -> u64 {
    let hash_fn = calc_fn_hash(empty(), &name, params.len(), params.iter().cloned());
[...]
    hash_fn
}

Yesh, the code looks right to me, except that it is not finding your function.  Let me take a closer look.

Both of your other changes were fixed.

Can you try euclidian_distance without the get_mystic_number() call?

m.set_fn("euclidean_distance".to_string(), FnAccess::Public,
math::euclidian_distance
Are you sure you didn't make a typo?

Are you sure you didn't make a typo?

Where is that Captain Picard facepalm gif...
Thanks. Now it panics, and I know why. I'll keep working on it.

I just pushed a version where the unit test passes! :tada:
Once I clean up some types, and make it work with all the other feature flag combinations, it will be ready for final review.

But, based on your logs, it seems that get_qualified_fn is called twice. I'll need to find out why.

OK, that's normal.  Once to check scripted functions, once to check native functions.

I'll catch up plugins with latest.

I have updated my PR.
Instead of my own feature gate, I put everything behind the no_module feature gate to avoid interactions. It is now also compatible with the `sync feature gate, which was not true before.
It is ready to merge, after (I hope) one final review.

Looks good.  I would suggest removing the no_module gates because when we re-implement the basic library as plugins we'd need it anyway.  Just avoid exposing public plugin API's is enough.

Done!

Just some minor suggestions and I think this can be merged in.
However, I am thinking of keeping the no_module feature to disable loading custom modules only.  That means removing most no_module feature gates as in your PR, but keeping it to remove the public module API's (e.g. loading modules into scope).
I'll start doing this removal on the master branch to keep the plugins branch in sync.

@jhwgh1968   can you rebase this PR on the latest?  This will ensure a smooth merge.  I've also removed many no_module gates in master to prepare for eventual merging plugins back to master.
However, pls keep the no_module feature for the time being.  In the latest, it only affects public-facing API's.

@jhwgh1968   can you rebase this PR on the latest?  This will ensure a smooth merge.  I've also removed many no_module gates in master to prepare for eventual merging plugins back to master.
However, pls keep the no_module feature for the time being.  In the latest, it only affects public-facing API's.

Sorry, I took your "remove it" a little too literally! I have rebased and fixed that, so it should be good now.

A couple of comments:

I have a few comments on removing multiple versions of code based on the sync gate.

For most of the remaining no_module gates you need to keep them there (i.e. undelete them).  In some places they're necessary otherwise it won't compile with no_module.  In other places they restrict the public module API's.

I'll merge this in once you take care of them.

For most of the remaining no_module gates you need to keep them there (i.e. undelete them).

Done.

I have a few comments on removing multiple versions of code based on the sync gate.

Where are they? I didn't see a full review be opened. I'd be happy to fix them.

Where are they? I didn't see a full review be opened. I'd be happy to fix them.

Well...  I just commented them directly into the changed files...  Not sure about this code review thing...

All resolved comments are now fixed, the rest replied to.

Thanks for the merge, @schungx! I'll open a new PR for the next step, and clean up the plugin export a bit as well.

Thanks!

I'll sync it up with master.

repo: schungx/rhai


text:
Improve Cartfile support

Comment lines were crashing the tool, now no more.
Cheers

Can you provide an example Cartfile for this?
I believe these issues might be already fixed in my develop branch

Didn't get an example that shows this in action. Closing.

authors: dulaccc schwa

repo: schwa/punic


text:
Good user interface to explore available libraries

We currently generate libs.md from data (#57). The motivation for generating libs.md from data is to enable better user interfaces for exploring that data. This issue collects ideas & experiments.
To get started with the data in a REPL:
(require '[clojure.edn :as edn])

(-> "https://scicloj.github.io/docs/resources/model.edn"
    slurp
    edn/read-string)

Feel free to post more links + screenshots here! Help & ideas very much welcome.

Plain HTML table with scittle: https://play.teod.eu/scicloj-libraries/ (source)

@teodorlu this is fantastic.
Would you find it useful to wrap this with DataTables UI?
I got that working with Scittle in the Clay project.
Would you find it helpful if I write a draft demonstrating that with your table?

Would you find it useful to wrap this with DataTables UI?

Yup!
I tried a bit, but got stuck on the combination of reagent generating the DOM and DataTables also wanting to control the dom. Plain javascript might be easier than Scittle / Clojurescript.
Perhaps we can use react-data-table-component.

Cool, I'll try in the coming days following the experience with Scittle in Clay.

react-data-table-component

Interesting! Didn't know about that.

authors: daslu teodorlu


text:
Error when requiring: Execution error (UnsatisfiedLinkError) at java.lang.ClassLoader$NativeLibrary/load0 (ClassLoader.java:-2).

(require '[tablecloth.api :as tc])

Execution error (UnsatisfiedLinkError) at java.lang.ClassLoader$NativeLibrary/load0 (ClassLoader.java:-2).
/Users/endrebakkenstovner/Library/Caches/JNA/temp/jna18113207169571984508.tmp: dlopen(/Users/endrebakkenstovner/Library/Caches/JNA/temp/jna18113207169571984508.tmp, 1): no suitable image found.  Did find:
	/Users/endrebakkenstovner/Library/Caches/JNA/temp/jna18113207169571984508.tmp: no matching architecture in universal wrapper
	/Users/endrebakkenstovner/Library/Caches/JNA/temp/jna18113207169571984508.tmp: no matching architecture in universal wrapper

I'm using [org.clojure/clojure "1.10.3"] and [scicloj/tablecloth "4.04"]

It's very old version. I recommend to use the latest one, ie. 6.076.

authors: endrebak genmeblog

repo: scicloj/tablecloth


text:
🛑 Email sender API is down

In a03802a, Email sender API ($EMAIL_ENDPOINT) was down:

HTTP code: 500
Response time: 490 ms

Resolved: Email sender API is back up in 9af82dd after 11 minutes.

repo: scidroid/status


text:
Address a few more places that used the old spelling

xref: https://github.com/scientific-python/lazy-loader/issues/107

Thank you!

authors: hmaarrfk stefanv

repo: scientific-python/lazy-loader


text:
find-prereview-reviews failed, their API seems to be down

@hdrury to contact PREreview.

it's not down, but it's possible that azure's being kind of sluggish. @Hannah Drury do you know specifically which API queries you're doing so I can do some troubleshooting?

This is the request we are making:
$ curl -v -H "Accept: application/json" https://www.prereview.org/api/v2/preprints

After about a minute, this eventually returns:
< HTTP/1.1 500 Internal Server Error
< Content-Length: 109
< Content-Type: application/json; charset=utf-8
< Vary: Origin
< X-Request-Id: 400d05cb-9161-417c-8799-1b964c97bac0
< Date: Wed, 21 Apr 2021 08:21:13 GMT
<
{
  "statusCode": 500,
  "error": "Internal Server Error",
  "message": "An internal server error occurred"
}

We suspect we have to use pagination?

Response from PREreview:

thanks for the additional context @Hannah Drury! Yes, you could definitely use pagination (we use limit and offset query parameters for that, for instance to fetch 10 preprints starting from the 20th preprint you'd add ?limit=10&offset=20 to your query). However there's definitely a new performance issue with the query that didn't exist previously, which I'm trying to track down. So I also wouldn't characterize what you're seeing as expected behavior and we hope to have a fix soon.

repo: sciety/sciety


text:
Extend and append methods added

Flushing is still inefficient and a little buggy - Will be fixed very soon.
TTree writing documentation added.

If you do any more work on this, open a new PR.

authors: jpivarski reikdas

repo: scikit-hep/uproot