Connectivity to a SARA-R520M10 from an external MCU nRF52840 DK

Hello @RobMeades
Appreciate support over this issue.
Been working with @Steve.Brown.
He recommended to reach out to you.
We have a uBlox devKit (base board and ADP with SARA-R520M10 mounted on it)
We are trying to connect to it via AT commands over UART1 from an external MCU nRF52840 DK
The base board is powered with a 9V power supply, the switch in on
The shunt on the UART switch on the ADP board has been removed per instructions from Steve
The power to the modem is on (verified by issuing AT commands through USB port J201)
Obtained wiring instructions from this User Guide document, adn verified with Steve
https://content.u-blox.com/sites/default/files/documents/EVK-SARA-R52_UserGuide_UBX-23006467.pdf
Section 5.5 on page 18 describes the pin out for the board to board connectors J103 and J104
RTS                        J104 pin 14
CTS                        J104 pin 13
TXD                        J104 pin 16
RXD                       J104 pin 15
Plus
GND                      J104 pin 10
PWR_ON            J104 pin 30
RESET_N             J103 pin 25
V_INT                 J104 pin 35
On the host controller side, using Zephyr 3.5.99
we have the UART1 TX and RX configured through the device tree as P1.1 and P1.2 respectively
The PWR_ON, RESET, and V_INT are configured on P1.6, P1,7, and P1.8 through the CMakeList.txt as follows
Compile definitions needed for UBXLIB.
target_compile_definitions(app PRIVATE
U_CFG_APP_CELL_UART=1
U_CFG_CELL_MODULE_TYPE=1
U_CFG_APP_PIN_CELL_PWR_ON=38                            ==> should correspond to P1.6
U_CFG_CELL_DISABLE_UART_POWER_SAVING=0
U_CFG_APP_PIN_CELL_RESET=39                                 ==> P1.7
U_CFG_APP_PIN_CELL_VINT=40                                   ==> P1.8
)
Additional wire connecting the GND on both ends.
Troubleshooting the power up sequence, we hit an error with u_cell.c / addDevice() when trying to set the PWR_ON pin LOW
uPortGpioSet returns -5
uPortLog copy / paste below
Note the call to uCellPwrOn comes a bit later
uart:~$ modem_ctrl power_up
Cell Modem Power Up
uart:~$ U_CELL: initialising with enable power pin not connected, PWR_ON pin 38 (0x26) (and is toggled from 1 to 0) and VInt pin 40 (0x28) (and is 1 when module is on).
U_CELL: uPortGpioSet() for PWR_ON pin 38 (0x26) returned error code -5.
QUESTIONS:
1-Any missing hardware configuration on either sides?
2-Through the ADP J201, I read AT+USIO? as 2.2,
Does that need to change?
3-Could there be a port configuration issue with this facility pUPortPrivateGetGpioDevice? (it returns -5 when error)
4-Any other hints appreciated...
PLEASE NOTE:
Previously we used the same Application code / device tree configuration to interface the same exact controller host to a Sparkfun board with the SARA-R410M mounted. The only key difference is that the Sparkfun comes with a compatible Arduino interface that plugs in directly onto the nRF52840 devKit
On that hardware configuration, the call to ubxlib uDeviceOpen() completes error free
--log copy/paste below...
uart:~$ system_ctrl version
Build Revisions:
Zephyr  Kernel: 3 3 99
Build Revision: V00.01.08 (DEBUG)
Build DateTime: Sep  5 2024   14:13:40
uart:~$
uart:~$ modem_ctrl  power_up
Cell Modem Power Up
uart:~$ U_CELL: initialising with enable power pin not connected, PWR_ON pin 38 (0x26) (and is toggled from 1 to 0) and VInt pin not connected.
AT
AT
AT
AT
uart:~$ AT
U_CELL_PWR: powering on.
AT
AT
AT
AT
AT
AT
AT
AT
AT
OK
OK
ATE0
OK
AT+CMEE=2
OK
AT+UDCONF=1,0
OK
ATI9
L<IP_ADDRESS>.05.12,A.02.21
OK
AT&C1
OK
AT&D0
OK
AT+UCGED=5
OK
AT&K0
OK
AT+UPSV=0
OK
AT+CPSMS?
+CME ERROR: SIM failure
AT+CEDRXS?
+CME ERROR: SIM failure
AT+UMNOPROF?
+UMNOPROF: 100
OK
AT+UGPRF?
+UGPRF: 2,0,""
OK
AT+CFUN=4
OK
AT+CGSN
350857124811117
OK
U_CELL_INFO: IMEI is<PHONE_NUMBER>11117.
HANLDE 1 ea7beef
[00:01:02.433,746]  CellModem: Modem power up and ready to be configured
[00:01:02.433,776]  CellModem: MODEM_POWERING_UP->MODEM_POWERED_UP
[00:01:02.433,807]  CellModem: uartHandle 1
[00:01:02.583,923]  CellModem: subTopic messages/350857124811117/devicebound/
[00:01:02.583,984]  CellModem: httpPath /350857124811117.html
[00:01:02.584,075]  CellModem: Callback modem message 2 MODEM_MSG_POWER_UP_ACK
[00:01:02.584,136]  Device: k_msgq_get event type 6 state DEVICE_INITIALIZATION
[00:01:02.584,167]  Device: Modem Power Up Complete

HI Jamal.
For uPortGpioSet() on the Zephyr platform to return error code -5 (U_ERROR_COMMON_INVALID_PARAMETER), as you have seen, pUPortPrivateGetGpioDevice(pin) must have returned NULL.  For the nrf52840dk board, as defined by Zephyr, the possible GPIO ports are gpio0 and gpio1.  Both of these have a default status of okay in the nrf52840dk_nrf52840.dts file so, unless they have been marked as not OK in an .overlay file, that should not be a problem.
pUPortPrivateGetGpioDevice(pin) also calls uPortPrivateGetGpioPortMaxPins(), to get the value of "32" back in this case, which I'd have thought is unlikely to go wrong.  Of course we test nRF52840 operation, and in fact we happen to use pin 38 in our testing, so there can't be anything fundamental wrong here.
If I were you I'd put some debug prints into the functions above to confirm that uPortPrivateGetGpioPortMaxPins() is returning 32, that pUPortPrivateGetGpioDevice(pin) is receiving the value 38 and where in the cascade of if()s it is ending up.  Specifically, for the case of pin 38, we are expecting it to end up here:

pDev should be a valid (non-NULL) pointer after line 593 for the case where pin is 38.

Hello Rob,
Appreciate the feedback
I have added several calls to uPortLog inside uPortGpioSet, but I could not get them to print anything. Weird!
Stepping through with the debugger instead, I have verified that
uPortSetGpio is called with 38 and 1
but that  uPortPrivateGetGpioPortMaxPins() is returning -1 <<< PROBLEM
so inside pUPortPrivateGetGpioDevice(), portNo is getting the value -38
therefore pDev remains at NULL
PS
I have also verified in the .dts file that
&gpio1 {
status = "okay";
gpio-line-names = "", "D0", "D1", "D2", "D3", "D4", "D5", "D6",
"D7", "", "D8", "D9", "D10", "D11", "D12", "D13";
};
and that is not altered in the .overlay
PS2
One key difference I remember now between the Sparfun/SARA-R410 and the SARA-R520 projects
for the former I was using nRF Connect 2.4.2
for the latter I am using 2.6.1
No sure if that matters at all, but thought I'd mention it
PS3
I made the change to U_CFG_CELL_MODULE_TYPE at 9 instead of 1. Good catch, thank you.
Compile definitions needed for UBXLIB.
target_compile_definitions(app PRIVATE
U_CFG_APP_CELL_UART=1
U_CFG_CELL_MODULE_TYPE=9
U_CFG_APP_PIN_CELL_PWR_ON=38
U_CFG_CELL_DISABLE_UART_POWER_SAVING=0
U_CFG_APP_PIN_CELL_RESET=39
U_CFG_APP_PIN_CELL_VINT=40
)

I have added several calls to uPortLog inside uPortGpioSet, but I could not get them to print anything. Weird!

Ah, yes, see advice here, should have mentioned that, sorry.

but that uPortPrivateGetGpioPortMaxPins() is returning -1 <<< PROBLEM

Oh!  Then we're hitting this case:
https://github.com/u-blox/ubxlib/blob/2896142106fe596fb289748c68ba4afd8c1e717b/port/platform/zephyr/src/u_port_private.c#L712-L719
We test with nRFConnect version 2.5.0, you are using nRFConnect version 2.6.1, but the gpio_driver_config structure in Zephyr, which is what matters here, remains unchanged:

If you are able to run under a debugger, all I can suggest is that you single step very carefully through uPortPrivateGetGpioPortMaxPins(), the first time it is called, to see how it is managing to not get  value of 32 for the number of pins per port.

Oh! Then we're hitting this case:
if (gGpioNumPinsPerPort == 0) {
gGpioNumPinsPerPort = -1;
}
Yes, definitely the case, the debugger stops at line 718
The comment about then the Zephyr platform is broken),
is worrisome
From the debugger, it's hard to single step through that function uPortPrivateGetGpioPortMaxPins() as if some of that code is optimized out
I am going to try to Manage west workspace back to 2.5.0 to match your setting,
and re-test...
Not sure how much impact it will have given your comment about [gpio_driver_config] being unchanged, but maybe worth a try...

@RobMeades
That was my best guess as well, gGpioNumPinsPerPort  comes out at -1 from this loop inside uPortPrivateGetGpioPortMaxPins()
    for (int32_t x = 0; (x < 64) && (gGpioNumPinsPerPort < 0); x++) {
        if ((pCfg->port_pin_mask & (1UL << x)) == 0) {
            gGpioNumPinsPerPort = x;
        }
    }

Now an interesting update:
It took forever for West Update to downgrade to 2.5.0 (thinking next time, I would just delete the entire Zephyr folder first)

But the issue with uPortGpioSet() / PWR_ON line has self resolved!
The power up sequence has moved ahead inside uCellPwrPrivateOn()
It is now stumbling into getting a response for AT command --log below
uart:~$ modem_ctrl power_up
Cell Modem Power Up
uart:~$ U_CELL: initialising with enable power pin not connected, PWR_ON pin 38 (0x26) (and is toggled from 1 to 0) and VInt pin 40 (0x28) (and is 1 when module is on).
U_CELL_PWR: powering on.
AT
AT
AT
[00:06:58.180,053]  CellModem: Opening a modem device instance...
uart:~$ AT
AT
AT
...
...
AT
AT
AT
U_CELL_PWR: powering on, module is alive.
ATE0
ATE0
ATE0
[00:08:12.090,240]  CellModem: Failed to initiate the modem: -257

I have already tried both combination of RX TX lines
on the uBlox devKit
TXD J104 pin 16
RXD J104 pin 15
on the Nordic DK / host controller
UART1 TX and RX P1.1 (Arduino D0) and P1.2 (Arduino D1) respectively
Wondering now if I am missing a key configuration on the uBlox devKit?!?
Interestingly, I can communicate with the uBlox devKit through the USB port on the main board
--but not through the USB port J201 that is on the ADP daughter board!?
[14:09:09:171] at
[14:09:09:415] OK
[14:09:09:811] at
[14:09:09:977] OK
[14:09:10:491] ati
[14:09:11:252] SARA-R520M10-02B-00
[14:09:11:252]
[14:09:11:252] OK
[14:09:19:156] at+CGSN
[14:09:21:412]<PHONE_NUMBER>15806
[14:09:21:413]
[14:09:21:413] OK
[14:09:25:002] at+CGMR
[14:09:26:916] 05.09
[14:09:26:916]
[14:09:26:916] OK
[14:09:48:420] at+CMEE?
[14:09:52:915] +CMEE: 0
[14:09:52:915]
[14:09:52:915] OK
[14:10:00:116] ati9
[14:10:01:299] 05.09,A00.01
[14:10:01:305]
[14:10:01:305] OK
[14:10:12:307] at+ucged?
[14:10:15:764] +UCGED: 2
[14:10:15:764] 6,2,310,260
[14:10:15:783] 750,2,50,50,7bde,105950d,96,00000000,ffff,ff,51,1
8,14.87,1,255,255,50,255,255,0,255,255,0,0
[14:10:15:784]
[14:10:15:785] OK
[14:10:26:073] at+upsv?
[14:10:28:740] +UPSV: 0
[14:10:28:740]
[14:10:28:741] OK
[14:10:39:054] at+CGSN
[14:10:41:475]<PHONE_NUMBER>15806
[14:10:41:491]
[14:10:41:492] OK
[14:13:03:986] at+usio?
[14:13:06:600] +USIO: 2,*2
[14:13:06:620]
[14:13:06:621] OK

But the issue with uPortGpioSet() / PWR_ON line has self resolved!

Interesting, we should try updating to nRFConnect 2.6.x ourselves to find out what it is doing.

It is now stumbling into getting a response for AT command

OK, so now you need to monitor HW to find out what is going on as something, somewhere is not connected quite right.  Usual things to check:

the MCU UART Tx line must be connected to the TXD line of the EVK, not the RXD line, this is the DCE convention), similarly MCU UART Rx line to the RXD line of the EVK,
the EVK is 1V8 logic and the nRF52840 board is 3V3 logic so you must have a level shifter in the way (e.g. https://www.sparkfun.com/products/12009) for both the UART RX and UART TX lines (you can power the 1V8 side from the VINT output pin on the ADP),
these bi-directional level shifters will NOT work with UART flow control lines, hence you can only work without UART HW flow control; you will need to ground the RTS and DTR lines on the cellular side for it to talk,
note that no level shifter is required for the PWR_ON connection as that is just pull-down and will just float up to whatever level it likes,
ubxlib has pulled the PWR_ON pin low, check if the VINT output of the module goes high; this would indicate that the module is, indeed, on, but the UART comms are what is failing,
you need to have the DIP switches in the right position to use the ADP UART lines instead of the USB port on the base-board, like this:

the jumper on the ADP of the SARA-R52 board needs to be disconnected (i.e. not on the UART or on the USB connection, just disconnected).

OK, a lot of good items to check for, but I believe the key one I am missing is the level shifter 3V3 to 1V8
Plus ground DTS and DTR
Otherwise the jumper on the ADP is disconnected
regarding the DIP switches,
I have them in the ON position, with the exception of DB9, this is in the OFF position, with the associated green light on.
Does that match what is on the picture
Thank you

The DIP switch positions we always use (I can't recall now which one is significant and which one is not) is that the DIP switch nearest the main power toggle switch of the entire EVK (let's call this DIP switch 1) has its slider closest to the main power toggle switch (let's call this "up").  The positions of all of the switches are then:
1 Up
2 Down
3 Up
4 Down
5 Down
6 Down

@RobMeades Thanks so much for detailed feedback
I take back my comments about the need of level shifters!!
I flipped the DIP switches as recommended above
and more importantly,
connected both RTS and DTR to GND on the ADP J104 connector as recommended in earlier note
Now I can complete the power up and power down sequence successfully (invoking uDeviceOpen and uDeviceClose respectively)
In the power up state, I can measure
the PWR_ON line at 3.4V on J104 / 30
and the V_INT line at 1.8V on J104 / 35
(by the way I had this V_INT line wrongly connected to pin 33 on J104, but it did not seem to matter?!?)
Next week, I shall attempt cellular registration, MQTT, GNSS fix, etc...
but I should have most of the application code ready to validate based on past experiments with the SparkFun and OpenCpu configurations
In between, I will be very curious about your Team findings with nRF Connect 2.6.x
Thank you
PS
Below is Host Controller debug console log...
uart:~$ modem_ctrl  power_up
Cell Modem Power Up
uart:~$ U_CELL: initialising with enable power pin not connected, PWR_ON pin 38 (0x26) (and is toggled from 1 to 0) and VInt pin not connected.
AT
AT
AT
AT
[00:02:35.160,186]  CellModem: Opening a modem device instance...
[00:02:35.160,247]  CellModem: MODEM_POWERED_DOWN->MODEM_POWERING_UP
uart:~$ AT
U_CELL_PWR: powering on.
AT
AT
AT
AT
AT
AT
OK
U_CELL_PWR: powering on, module is alive.
ATE0
ATE0
OK
AT+CMEE=2
OK
AT+UDCONF=1,0
OK
ATI9
05.09,A00.01
OK
AT&C1
OK
AT&D0
OK
AT&K0
OK
AT+UPSV=0
OK
AT+UPSMR=1
OK
AT+CPSMS?
+CPSMS: 0,,,"10000101","00000011"
OK
AT+UMNOPROF?
+UMNOPROF: 90
OK
AT+UGPRF?
+UGPRF: 2,0,""
OK
AT+CFUN=4
OK
[00:02:41.734,741]  CellModem: Modem power up and ready to be configured
[00:02:41.734,802]  CellModem: MODEM_POWERING_UP->MODEM_POWERED_UP
[00:02:41.734,832]  CellModem: uartHandle 1
uart:~$ modem_ctrl  power_down
U_CELL_PWR: powering off with AT command.
Cell Modem Power Down
uart:~$ AT+CPWROFF
[00:02:48.192,077]  CellModem: MODEM_POWERED_UP->MODEM_POWERING_DOWN
[00:02:48.192,108]  CellModem: Closing an open device instance...
uart:~$
OK
AT
[00:02:53.894,439]  CellModem: MODEM_POWERING_DOWN->MODEM_POWERED_DOWN
uart:~$

That's excellent news @jamal-mouline, well done!  Of course, you will be driving the 1V8 UART pins of the module with 3V3, which I guess works but probably isn't what we'd recommend.  Since this is just a test jig I guess that if it works, it works, so all is good.
Internally we will make a note to look at the pulling in the latest release of nRFConnect and see what problems that brings with it.  It's a bit strange because we are already using the native Zephyr release 3.7, which I think is later, or at least as late as, the Zephyr version underneath nRFConnect 2.6, but of course we will be using that with other MCUs (ST, NXP), so if something has been changed in a Nordic driver we wouldn't notice.
Will update this issue when we know more.

Thanks for the additional feedback @RobMeades
I will be looking further into the 3.3 to 1.8, but will need to be at the lab with a scope to monitor the UART lines
I still observe some intermittent power up failure depending on the sequence of powering up both DKs
Regarding nRFConnect / Zephyr version, my debug console is reporting this
nRFConnect 2.6.1 is using Zephyr Kernel 3.5.99
nRFConnect  2.5.0 is using Zephyr Kernel 3.4.99
as in
uint32_t ver = sys_kernel_version_get();
LOG_INF("%s %d.%d.%d", SYS_KERNEL_VER, SYS_KERNEL_VER_MAJOR(ver), SYS_KERNEL_VER_MINOR(ver), SYS_KERNEL_VER_PATCHLEVEL(ver));
Further update:
When all good with modem power up,
I am now able to register to AT&T using a "hologram" SIM card
Log from Shell console attached below...
Takes about ~18 second the first time, then just couple second for subsequent registrations...
uart:~$ modem_ctrl
modem_ctrl - Modem Control
Subcommands:
q_test        :Basic Q Test
power_up      :Cell Modem Power Up
network_up    :Cell Modem Network Register
mqtt_test     :Cell Modem Mqtt Test
location      :Cell Modem Gnss Location
network_down  :Cell Modem Network de-Register
power_down    :Cell Modem Power Down
uart:~$ modem_ctrl   network_up
Cell Modem Register
uart:~$ AT+UMNOPROF?
+UMNOPROF: 90
OK
U_CELL_CFG: MNO profile is 90.
AT+UMNOPROF=100
OK
U_CELL_CFG: MNO profile set to 100.
MNO profile has been changed from 90 to 100.
Re-booting the module to apply MNO profile change...
U_CELL_PWR: rebooting.
AT+CFUN=16
OK
AT
AT
OK
ATE0
ATE0
OK
AT+CMEE=2
OK
AT+UDCONF=1,0
OK
ATI9
05.09,A00.01
OK
AT&C1
OK
AT&D0
OK
AT&K0
OK
AT+UPSV=0
OK
AT+UPSMR=1
OK
AT+CPSMS?
+CPSMS: 0,,,"00010011","00000011"
OK
AT+UMNOPROF?
+UMNOPROF: 100
OK
AT+UGPRF?
+UGPRF: 2,0,""
OK
AT+CFUN=4
OK
AT+URAT?
+URAT: 7
OK
U_CELL_CFG: RATs are:
rank[0]: 10 (in module terms 7).
rank[1]: 0 (in module terms -1).
rank[2]: 0 (in module terms -1).
RAT[0] is 10 - CAT-M1.
Unable to read RAT uCellCfgGetRat() return -5
U_CELL_CFG: getting band mask for RAT 10 (in module terms 0).
AT+UBANDMASK?
+UBANDMASK: 0,524421,0,1,524420,0
OK
U_CELL_CFG: band mask for RAT 10 (in module terms 7) is 0x0000000000000000<PHONE_NUMBER>080085.
Band mask for RAT CAT-M1 is 0x0000000000000000<PHONE_NUMBER>080085.
Setting band mask for RAT CAT-M1 to 0x0000000000000000<PHONE_NUMBER>00181a...
U_CELL_CFG: setting band mask for RAT 10 (in module terms 0) to 0x0000000000000000<PHONE_NUMBER>00181a.
AT+UBANDMASK=0,6170,0
OK
Re-booting the module to apply RF band changes...
U_CELL_PWR: rebooting.
[00:04:40.187,469]  CellModem: size of table 3 1
uart:~$ AT+CFUN=16
OK
AT
AT
OK
ATE0
ATE0
OK
AT+CMEE=2
OK
AT+UDCONF=1,0
OK
ATI9
05.09,A00.01
OK
AT&C1
OK
AT&D0
OK
AT&K0
OK
AT+UPSV=0
OK
AT+UPSMR=1
OK
AT+CPSMS?
+CPSMS: 0,,,"00010011","00000011"
OK
AT+UMNOPROF?
+UMNOPROF: 100
OK
AT+UGPRF?
+UGPRF: 2,0,""
OK
AT+CFUN=4
OK
U_CELL_NET: preparing to register/connect...
AT+CREG=2
OK
AT+CGREG=2
OK
AT+CEREG=4
OK
AT+CIMI
234500007895849
OK
U_CELL_NET: user-specified APN is "hologram".
AT+CGDCONT=1,"IP","hologram"
OK
AT+UAUTHREQ=1,0,"",""
OK
U_CELL_NET: setting automatic network selection mode...
AT+COPS?
+COPS: 0
OK
[00:04:59.575,866]  CellModem: Bringing up the network interface...
uart:~$ AT+CFUN=1
OK
...
AT+CGREG?
+CGREG: 2,4
OK
-1: OoC
AT+CEREG?
+CEREG: 4,0
OK
-1: NReg
AT+CREG?
+CREG: 2,0
OK
-1: NReg
+CREG: 7,"2709","0bbce811",7
+CEREG: 5,"2709","0bbce811",7
7: RegS
7: RegR
AT+COPS=3,0
OK
AT+COPS?
+COPS: 0,0,"AT&T",7
OK
AT+CGATT?
+CGATT: 1
OK
AT+CGACT?
+CGACT: 1,1
OK
AT+CEER
+CEER: "EMM cause",0,"No cause information available",fff,fff
OK
U_CELL_NET: connected after 18 second(s).
AT+CGACT?
+CGACT: 1,1
OK
AT+CGPADDR=1
+CGPADDR: 1,"<IP_ADDRESS>"
OK
U_CELL_NET: IP address "<IP_ADDRESS>".
AT+CGCONTRDP=1
+CGCONTRDP: 1,5,"hologram.mnc050.mcc234.gprs","<IP_ADDRESS>.<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>","","",0,0,1500,0,0
OK
U_CELL_NET: primary DNS address:   "<IP_ADDRESS>".
U_CELL_NET: secondary DNS address: "<IP_ADDRESS>".
[00:05:18.976,745]  CellModem: MODEM_POWERED_UP->MODEM_NETWORK_REGISTERED
uart:~$

All good as well with MQTT Publish to Mosquitto
Mosquitto Console:
AzureAD+JamalMouline@DESKTOP-6N00H8P /cygdrive/c/Toolchains/mosquitto-2.0.8
$ mosquitto_sub  -h    test.mosquitto.org -t<PHONE_NUMBER>15806  -v
350428920015806 HelloWorld
350428920015806 HelloMqttWorld_SARA-R520M10
Nordic Console:
uart:~$ modem_ctrl   mqtt_test    HelloMqttWorld_SARA-R520M10
Mqtt test HelloMqttWorld_SARA-R520M10
uart:~$ AT+UMQTT=2,"test.mosquitto.org"
OK
AT+CGSN
350428920015806
OK
AT+UMQTT=0,"350428920015806"
OK
U_CELL_MQTT: trying to connect...
AT+UMQTTC=1
OK
U_CELL_MQTT: waiting for response for up to 120 second(s)...
+UUMQTTC: 1,1
U_CELL_MQTT: connected after 1 second(s).
AT+UMQTTC=4,1,"messages/350428920015806/devicebound/"
OK
+UUMQTTC: 4,1,1,"messages/350428920015806/devicebound/"
AT+UMQTTC=9,1,0,"350428920015806",27

HelloMqttWorld_SARA-R520M10
OK

+UUMQTTC: 9,1
AT
OK
U_CELL_MQTT: trying to disconnect...
AT+UMQTTC=0
OK
+UUMQTTC: 0,1
U_CELL_MQTT: waiting for response for up to 120 second(s)...
[00:08:28.826,324]  CellModem: Disconnect MQTT session
uart:~$ U_CELL_MQTT: disconnected after 1 second(s).
[00:08:29.887,847]  CellModem: Close MQTT Client session
uart:~$

Hi Jamal: so that I have the right context here, you have an EVK with a SARA-R520M10 mounted on it and you are trying to use the M10 GNSS device that is inside the cellular module?

First question: is this the correct/expected setup?

Yes, that is fine.

During the location request, a RED LED is turned on the ADP DS160, Is that normal / expected?

I've no idea I'm afraid.  Which red LED is this?

Both U_CFG_APP_CELL_PIN_GNSS_POWER and U_CFG_APP_CELL_PIN_GNSS_DATA_READY are defaulted to -1

Yes, that is correct.  Those are only required if the GNSS device is external to the cellular module, which is not the case here.  You might need to have the cellular GNSS detach switch [SW304] in the opposite position to the “GNSS” position, to make sure that the other GNSS device on the EVK is not the one that is in play.
From your log, the cellular device is definitely talking to a GNSS chip, you can see the UBX messages being exchanged with it; the GNSS chip is unable to get a location fix but it is able to establish the time so it is seeing satellites, just not enough of them.  I guess you are using the active antenna that likely came with the EVK and it is in a location where it can see open sky?

Hi @RobMeades
What I meant by my first question was related to
AT+UGPS=1,15,295
OK
Thanks for confirming about
U_CFG_APP_CELL_PIN_GNSS_POWER and U_CFG_APP_CELL_PIN_GNSS_DATA_READY are defaulted to -1
RE:  I guess you are using the active antenna that likely came with the EVK and it is in a location where it can see open sky?
That is correct
To address your question about the context, yes I am trying to use the M10 GNSS that is inside the cellular module, which itself is populated on the ADP board, which is plugged on the EVK on ports J100 and J101
Will attach a picture shortly, showing also the RED LED...

AT+UGPS=1,15,295
OK

Yes, this is fine.
It is worth making sure that the DIP switch labelled "GNSS" is in the "detach" position, just in case that otherwise makes the module use the external GNSS chip on the EVK rather than its internal one.

Open Sky View

Will attach a picture shortly, showing also the RED LED...

Also Verified the GNSS red switch, the fourth from the man power switch is in the DETACH position --also shown on the above pic

I enquired internally about DS160 (apologies, hadn't spotted that you'd mentioned the label DS160 before, I'd searched the EVK document for DS160 and it didn't appear so I assumed it was a mis-type).  Apparently it was mounted by mistake on some ADP boards, hence it not being documented.  It is connected to the TXD_GNSS line of the module, so it would make sense that it lights up since the GNSS module will, by default, be sending NMEA messages over that UART line.
How long are you waiting for a fix?  Checking the log of UBX, messages, right at the very end, it finds a 2D-only fix, seeing only 3 satellites though.  I've no idea why it should take this long but of course it is starting from absolutely nothing, no knowledge of time at the outset, and no stored ephemeris data.  You might just have to wait longer.
                        The "2" here indicates a 2D-only fix |
              This indicates the number of satellites used in the fix |
                                                             V        V
20 dd 7f 14 e8 07 09 0b 17 1f 2e 37 2e 03 00 00 d2 b3 04 00 00 00 26 00 d0 57 f7 d0 95 93 43 15 89 22 01 00 e5 a7 01 00 2d 12 08 00 28 6c 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9e 1d 5f 01 5e 3d 00 00 12 55 43 00 0f 27 00 00 5c 40 56 2f 00 00 00 00 00 00 00 00
08 e1 7f 14 e8 07 09 0b 17 1f 2f 37 da 01 00 00 b8 ba 04 00 02 00 26 03 ea 57 f9 d0 ac 3f 44 15 5c 26 01 00 c4 ab 01 00 ef ce 03 00 e2 d8 00 00 05 c6 00 00 e5 fc ff ff 00 00 00 00 0c c6 00 00 0c f2 23 02 c2 3d 00 00 cb 37 11 00 b9 01 00 00 5c 40 56 2f 00 00 00 00 00 00 00 00
f0 e4 7f 14 e8 07 09 0b 17 1f 30 37 a2 01 00 00 c1 b9 04 00 02 00 26 03 9b 59 f9 d0 50 52 44 15 1a 27 01 00 82 ac 01 00 3d 62 03 00 8d 6a 01 00 93 cc 00 00 75 02 00 00 d3 fc ff ff 97 cc 00 00 00 0d 01 00 f9 36 00 00 25 d2 0e 00 b9 01 00 00 5c 40 56 2f 00 00 00 00 00 00 00 00
d8 e8 7f 14 e8 07 09 0b 17 1f 31 37 21 01 00 00 cd b8 04 00 02 00 26 03 bf 59 f9 d0 83 64 44 15 86 28 01 00 ee ad 01 00 51 cb 02 00 7c 3e 01 00 07 c7 00 00 e5 fc ff ff e2 ff ff ff 0e c7 00 00 cc f3 23 02 b2 25 00 00 34 e1 0a 00 b9 01 00 00 5c 40 56 2f 00 00 00 00 00 00 00 00
d0 13 80 14 e8 07 09 0b 17 20 00 37 af 00 00 00 b6 b0 04 00 02 00 26 03 81 8a f9 d0 7d bd 45 15 3e f7 00 00 a7 7c 01 00 7e b6 01 00 b3 45 01 00 b1 e0 00 00 4e f4 ff ff 6e 02 00 00 ff e0 00 00 ec c4 20 02 10 0f 00 00 ce 48 07 00 30 01 00 00 5c 40 56 2f 00 00 00 00 00 00 00 00

Thanks for the additional information on DS160, that makes sense now, so no red flag there, thank you
Re: How long are you waiting for a fix?
I don't seem to have control on that parameter, or did I miss it?
Please see a snapshot of my code copy/paste below
is there a way to configure the GNSS chip / wait time before calling uLocationGet()?!?
Tracing down the call to uLocation() to ... to posGet() within ubxlib,
it seems to use a fixed timeout value of 4 minute U_GNSS_POS_TIMEOUT_SECONDS == 240
Right?
Unless you want to hard code that value to twice that much and retry?
Thank you
int32_t returnCode = U_ERROR_COMMON_SUCCESS;
// Bring up the GNSS network layer on the cellular device.
LOG_INF("Bringing up GNSS...");
returnCode = uNetworkInterfaceUp(pObj->deviceHandle, U_NETWORK_TYPE_GNSS, &gNetworkCfg);
if (returnCode == U_ERROR_COMMON_SUCCESS)
{
LOG_INF("Get a location fix");
returnCode = uLocationGet(pObj->deviceHandle, U_LOCATION_TYPE_GNSS, NULL, NULL, pLocation, NULL);

You can take control of the timeout by passing a pKeepGoingCalback parameter into uLocationGet(), i.e, rather than the last parameter being NULL, have it point to a function of the following form:
static bool keepGoingCallback(uDeviceHandle_t devHandle)
{
    return true;
}

While keepGoingCallback() returns true uLocationGet() should wait, as soon as keepGoingCallback() returns false it will exit.

I just tried doubling up the value of U_GNSS_POS_TIMEOUT_SECONDS in the CMake file,
But no impact, still timing out with no fix!
Will try the callback suggestion next...
Compile definitions needed for UBXLIB.
target_compile_definitions(app PRIVATE
U_CFG_APP_CELL_UART=1
U_CFG_CELL_MODULE_TYPE=9 # uCellModuleType_t
U_CFG_APP_PIN_CELL_PWR_ON=38
U_CFG_CELL_DISABLE_UART_POWER_SAVING=0
U_CFG_APP_PIN_CELL_RESET=39
U_GNSS_POS_TIMEOUT_SECONDS=480
)

While I will help as much as I can, I'm really the wrong person to be talking to about this; there's nothing of significance that ubxlib configures in the GNSS chip in order to obtain a fix, the GNSS chip just does its thing.  Only being able to see 3 satellites with an active antenna plugged into the GNSS antenna port of the ADP is just weird: likely you need someone who knows something about the HW at this point...?

The callback approach did not make much difference either!
Agreed that missing some HW setup is more likely than a ubxlib issue.
ubxlib worked well when we tried it last in the OpenCpu environement
From what I remember a 4th satellite is needed to get a fix.
Will keep you posted if/when I find something else...
Thank you for all the good suggestions anyway.
PS
In between, I would like to keep this ticket open to get your feedback when regressing ubxlib against a later version of nRFConnect SDK (a later version than 2.5.0), so I may upgrade to the same version as well
Thank you

From what I remember a 4th satellite is needed to get a fix.

Correct, but you should see loads of satellites: we usually see between 20 and 40 here (with a roof-top antenna); I would expect at least double figures.

In between, I would like to keep this ticket open to get your feedback when regressing ubxlib against a later version of  RFConnect SDK (a later version than 2.5.0), so I may upgrade to the same version as well

Of course.

Hi @RobMeades
Good news, I am now able to get a fix through ubxlib pretty quickly.
Long story short, I only had to extend my antenna ~5-6 outside my window for better open sky view.
With that, I see about 7-8 satellites. Nothing close to 20 but much better than before.
On a related subject, does ubxlib offer an interface to configure the at+UGPS parameters?
By default it is always sending AT+UGPS=1,15,295
Thanks,
PS
On the subject of nRF Connect / Zephyr association, here is what I got back from Nordic
nRF 2.5.0 > Zephyr 3.4.99 <<< this is the currently working version
nRF 2.6.1 > Zephyr 3.5.99 <<< this version had problems as documented above
nRF 2.7.0 > Zephyr 3.6.99 <<< this is available, planning to try it next...
nRF 2.8.0 > Zephyr 3.7.99 (on the roadmap for early November 24)

Good stuff.

On a related subject, does ubxlib offer an interface to configure the at+UGPS parameters?
By default it is always sending AT+UGPS=1,15,295

By default we always set all of the supported system types at the outset.  If you are obtaining location through the Cell Locate API (which will use any attached GNSS chip) you can set the system types used by CellLocate with uCellLocSetSystem().
If you are obtaining position from the GNSS chip, rather than via CellLocate (which I think is your case), then, for an M9 or M10 device, you just need to use the right configuration ID to set or unset the system types using the uGnssCfg API, i.e. one of U_GNSS_CFG_VAL_KEY_ID_SIGNAL_XXX, most simply following the kind of pattern in this example, so something like:
if (U_GNSS_CFG_SET_VAL_RAM(devHandle, U_GNSS_CFG_VAL_KEY_ID_SIGNAL_BDS_ENA_L, 0) == 0) {
    printf("Beidou has been disabled.\n");
} else {
    printf("Unable to disable Beidou!\n");
}

Hi @RobMeades
Thanks for the feedback
I initially tried uCellLocSetSystem(), which did not work, so understand the reason now
Following your suggestion, I have inserted few of these type of calls in an attempt to disable some system types
U_GNSS_CFG_SET_VAL_RAM(pObj->deviceHandle, SIGNAL_GAL_ENA_L, 0);
U_GNSS_CFG_SET_VAL_RAM(pObj->deviceHandle, SIGNAL_BDS_ENA_L, 0);
U_GNSS_CFG_SET_VAL_RAM(pObj->deviceHandle, SIGNAL_QZSS_L1S_ENA_L, 0);
just before bringing up GNSS (call to uNetworkInterfaceUp())
but I still end up with the default setup
any idea whether I am missing another step?
thanks,
AT+UGPS=1,15,295
OK

but I still end up with the default setup

Yes, you will still get AT+UGPS=1,15,295, that default will remain unchanged, you just need to put the U_GNSS_CFG_SET_VAL_RAM... lines after uNetworkInterfaceUp() and that will remove the satellite systems you don't need.

Also how to force the aiding type parameter?
I tried to redefine U_CELL_LOC_GNSS_AIDING_TYPES from default to 1, but still ended up with 15

Remember that the aiding types is to do with the way Cell Locate works, and you are not using Cell Locate as far as I am aware, so you can ignore it.  If I've misunderstood and you are using CellLocate then you will see from the code here:
#ifndef U_CELL_LOC_GNSS_AIDING_TYPES
/** The aiding types to request when switching-on a GNSS
 * chip attached to a cellular module (all of them).
 */
# define U_CELL_LOC_GNSS_AIDING_TYPES 15
#endif

...that if you define U_CELL_LOC_GNSS_AIDING_TYPES when you build the ubxlib code to be, say, 1, then that definition will override the one in u_cell_loc.h.  How are you #defining the value of U_CELL_LOC_GNSS_AIDING_TYPES in your build system?

Awesome!
I do see now the impact in the log of inserting those suggested Macros between uNetworkInterfaceUp and uLocationGet
In bold in the log snapshot below
Also seems to reduce the number of used satellites
AT+UGPS?
+UGPS: 0
OK
AT+UGPS=1,15,295
OK
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 22 00 31 10 00 fe 97.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 0d 00 31 10 00 e9 2e.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 0f 00 31 10 00 eb 38.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 14 00 31 10 00 f0 51.
U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
[00:03:06.599,792]  CellModem: Get a location fix

Now that I understand better how to configure the system types, I decided to stay with the default setting as is
--but good to know in case I need to revisit in the future for some sort of optimization
Regarding your earlier question
Re: How are you #defining the value of U_CELL_LOC_GNSS_AIDING_TYPES in your build system?
I was re-defining it in the CMakeList.txt file
But now that I understand CellLocate is not used in the SARA-520M10, I also left it to its default mask value at 15, as you suggested

Next week, I plan to re-evaluate the modem power up sequence using the latest available nRF 2.7.0 > Zephyr 3.6.99
and keep you posted here...

Update regarding evaluation of nRF 2.7.0 / Zephyr 3.6.99
I got this link error from u_port_os.c
C:/GitAV/AutoVentive/external/modules/lib/ubxlib/port/platform/zephyr/src/u_port_os.c:172:30: warning: implicit declaration of function 'Z_KERNEL_STACK_LEN'; did you mean 'K_KERNEL_STACK_LEN'? [-Wimplicit-function-declaration]
172 |             stackAllocSize = Z_KERNEL_STACK_LEN(stackSizeBytes);
|                              ^~~~~~~~~~~~~~~~~~
|                              K_KERNEL_STACK_LEN
the associated code is copy/paste below
#if KERNEL_VERSION_NUMBER >= ZEPHYR_VERSION(3,7,0)
stackAllocSize = K_KERNEL_STACK_LEN(stackSizeBytes);
#else
stackAllocSize = Z_KERNEL_STACK_LEN(stackSizeBytes);
#endif
@RobMeades
is there a known fix/patch to resolve this?
thank you

That's a bit strange.  Z_KERNEL_STACK_LEN became K_KERNEL_STACK_LEN at Zephyr release tag 3.7.0, you can see that here:
https://github.com/zephyrproject-rtos/zephyr/commit/f05111dea048814ef312eb664aaa87e9eda3844c
So, if you have Zephyr version 3.6.99, Z_KERNEL_STACK_LEN must surely be the thing?
Can you look through the nRFConnect SDK code you have ended up with in version 2.7.0 and verify (a) what zephyr/include/zephyr/kernel/thread_stack.h has as the definition for THING_KERNEL_STACK_LEN and (b) what zephyr/version.h contains?

@RobMeades
to your first questions
zephyr/version.h has been modified by Nordic and contains the following
VERSION_MAJOR = 3
VERSION_MINOR = 6
PATCHLEVEL = 99
VERSION_TWEAK = 0
EXTRAVERSION =
zephyr/include/zephyr/kernel/thread_stack.h has a K definition K_KERNEL_STACK_LEN as you had mentioned and not a Z
#define K_KERNEL_STACK_LEN(size)
ROUND_UP(Z_KERNEL_STACK_SIZE_ADJUST(size), Z_KERNEL_STACK_OBJ_ALIGN)

@RobMeades
Taking your hint account, I made the following patch into u_port_os.c
and it sure builds now
What would be the proper way to move forward with this?
Thank you
#if KERNEL_VERSION_NUMBER >= ZEPHYR_VERSION(3,6,99)
stackAllocSize = K_KERNEL_STACK_LEN(stackSizeBytes);
#else
stackAllocSize = Z_KERNEL_STACK_LEN(stackSizeBytes);
#endif

Good stuff; I will change the >=  3.7.0 Zephyr version check to be >= 3.6.99 instead.

Now that the build completes error free with nRF Connect 2.7.0
I was hopeful the previous error related to
_uPortGpioSet() returning error code -5 ... Nordic's GPIO driver is not initializing the port_pin_mask ... etc
would be resolved
Unfortunately, the error is still there, therefore I am forced to go back to safety 2.5.0
Going forward,
what would be the plan to resolve the issue with Nordic in order to be able to use their latest available nRF Connect SDK
Is there a roadmap for ubxlib to test/validate with the later nRF Connect SDKs?
Thank you

Understood, I thought that might be the case.  I doubt it will be a complicated problem to resolve but I must leave the answer to @Daniel-Herlestam-ublox, @m-abubakar and @sakrubx to resolve as I retire from u-blox tomorrow.  You can, of course, always find me on the internet, but they are now "the guys" (and they do very much know what they are doing) :-).
I will assign this issue over to @m-abubakar to avoid confusion.
Good to talk to you @jamal-mouline!

Hello @RobMeades
It was a pleasure working with you over the ~ past year or so
Best wishes for your future endeavors
Jamal

@jamal-mouline: you can find the change to Zephyr version conditional compilation in commit 556a048469cd52b9f91f6f916de69111c57f0a15.

General question I had in the back of my mind --non urgent
Does ubxlib maintain some sort of versioning numbers that the application could query?
Would be useful when reporting issues... I could say I am using ubxlib version MM.mm.pp
Thank you

@m-abubakar Hi,
Kindly checking on updates for this ticket
Plus this additional question regarding the UART power saving feature
There is #define associated for this feature, but it seems it has a reverse logic. I could be wrong though!
What is your recommendation to disable UART power saving
U_CFG_CELL_DISABLE_UART_POWER_SAVING=1
or
U_CFG_CELL_DISABLE_UART_POWER_SAVING=0
From my experiments, it seems to work better with the latter >> AT+UPSV=0
Please advise...

Hello @Daniel-Herlestam-ublox and @sakrubx
Just checking if this ticket is still being supported...
Thank you

Hi @jamal-mouline,
Sorry for the delay. We are working on your queries and will respond shortly. Thank you for understanding.

Hi @jamal-mouline,
Thank you so much for your patience. Yes, it involves a bit of reverse logic. Setting U_CFG_CELL_DISABLE_UART_POWER_SAVING=1 effectively means you're opting not to use the power-saving feature—in other words, you are disabling UART power saving (i.e., AT+UPSV=0).
To enable power saving, it is recommended not to define U_CFG_CELL_DISABLE_UART_POWER_SAVING. Additionally, E-DRX and 3GPP power-saving features should work as expected if you don't define this configuration.
Thank you.

Hi @m-abubakar
Appreciate the feedback
It does make sense that defining
U_CFG_CELL_DISABLE_UART_POWER_SAVING=1
disables power saving >> AT+UPSV=0
What looked counter-intuitive was that
U_CFG_CELL_DISABLE_UART_POWER_SAVING=0
had the same exact effect.
My conclusion is that all it matters is whether the feature U_CFG_CELL_DISABLE_UART_POWER_SAVING is defined or not, regardless of its assigned value 0 or 1
This issue is better understood now.
So we could move on to the previous questions:
1-Versioning of ubxlib commit being used?
2-Roadmap for compatible ubxlib version with latest nRF Connect 2.7.0 / Zephyr 3.6.99
Thank you

Hi @jamal-mouline,
Regarding the version information, if I understood your query correctly, you're asking if there's an API call that returns this information. Unfortunately, at this time, ubxlib does not provide an API to query the version of the library in use.
I am currently working on the second matter and will keep you updated as soon as I make any progress.
Thank you.

Hello @m-abubakar
Thank you for the update

Hi @m-abubakar
Checking whether you have any high level information about
https://github.com/u-blox/ubxlib/issues/285
and whether it is assigned to somebody in the ubxlib team?
Thank you


Module error when installing

manjaro-deepin
steps:
-cloned the repo
-cd roguehostapd/
-python setup.py install
-got the error below:
Traceback (most recent call last):
File "setup.py", line 15, in
from roguehostapd.config.hostapdconfig import WHITE, RED
File "/opt/roguehostapd/roguehostapd/config/hostapdconfig.py", line 9, in
from ConfigParser import SafeConfigParser
ModuleNotFoundError: No module named 'ConfigParser'

do you use python3 to install roguehostapd?
can you post the output of python --version?

Python 3.6.4

Ok currently roguehostapd only support python2. You may install it by
pip2 install roguehostapd

thank you very much :+1:


Link does not end with '.'

Fix link hash #

It prints to the console, such as vscode , and can't scroll to the anchored location after clicking the link.


Regular Expression Matching

Leetcode Question no. - 10
Problem name -  Regular Expression Matching
Instructions

Create a new folder for your script and file/folder name should be appropriate.
Create a README.md in your folder for program Instructions
add requirements.txt if needed

Programming Language

[x] Python

Happy Coding

Hey @pawangeek, can I work on this issue.

Sure do it, add folder with number '0010'

Can you help me, when I do git push it shows an error  " remote: Permission to python-geeks/Leetcode-scripts.git denied to kapshar."


Sync non-spring code to spring boot 3 branch

Description
Sync non-spring code to spring boot 3 branch
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.

/azp run java - spring - tests


need createRange / dom Ranges support

To test Sencha Touch apps with Zombie, this will be a requirement. I may look into adding it, but filing an issue for now.
It's Level2 DOM

Agreed

+1

Any news on this? I also found myself needing support for createRange.

Rolling in to #317.


Port the Python implementation to PHP

This PR ports the python implementation into PHP

Thanks a lot for your contribution! I updated the PHP example slightly to make it more in line with the previous Python example. I also added a composer.json file to make the example easier to run for anyone wanting to do so. We already had a requirements.txt file for the Python example so it made sense to have something similar here.


Fix: bug in Telemetry; update cmake build tests target name; update CI test step

Description

Fix bug in telemetry due to the missed update after the spinner change
update cmake build tests target name from tests to tests_build
update CI from running check -> tests_build && test
provide better logging, as it displays progress

LGTM


bug: After opening python files directly, K still triggers vim.lsp.buf.hover() even though disabled in lsp keymap setting

Did you check docs and existing issues?

[X] I have read all the LazyVim docs
[X] I have updated the plugin to the latest version before submitting this issue
[X] I have searched the existing issues of LazyVim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
NVIM v0.10.1
Operating system/version
Garuda Linux (arch-based)
Describe the bug
I disabled K keymap in lua/plugins/lsp.lua according to the doc:
{
  "neovim/nvim-lspconfig",
  opts = function()
    local keys = require("lazyvim.plugins.lsp.keymaps").get()
    -- disable a keymap
    keys[#keys + 1] = { "K", false }
  end,
},

which proves effective most of the time. However, after opening a python file with nvim filename.py, K is still bound to vim.lsp.buf.hover(), which can be seen when searching keymap:

Curiously, opening other file types (tried lua/rust/markdown, all with lsp enabled) doesn't yield this issue. Opening a python file with nvim first and selecting the file from neo-tree doesn't produce this bug as well. I suspect that there are some special settings for opening a python file directly, which add the additional vim.lsp.buf.hover() thing to K. Another evidence for this conjecture is that if uncomment my custom lsp keymap setting, the K key by default has a description "Hover", as set in the default config:

Steps To Reproduce

Enable the python extra package
add the following lines to lua/plugin/lsp.lua:

return {
  {
    "neovim/nvim-lspconfig",
    opts = function()
      local keys = require("lazyvim.plugins.lsp.keymaps").get()
      -- disable a keymap
      keys[#keys + 1] = { "K", false }
    end,
  },
}

Open a python file directly with nvim filename.py
K is still bounded to vim.lsp.buf.hover(), as can be seen in <leader>sk.

Expected Behavior
K should escape the default setting.
Repro
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
    { "LazyVim/LazyVim", import = "lazyvim.plugins" },
    { import = "lazyvim.plugins.extras.lang.python" },
  },
})

Since Neovim 0.10 :h lsp-defaults

|K| is mapped to |vim.lsp.buf.hover()| unless |'keywordprg'| is customized or
a custom keymap for K exists.


Add scale method to BoundingVolume trait

What problem does this solve or what need does it fill?
The BoundingVolume trait has grow and shrink method to change its size. In some case, it would be more convenient to introduce scale method to do this.
What solution would you like?
Add scale method to BoundingVolume trait and add implementation for Aabb2d, Aabb3d, BoundingCircle, BoundingSphere.
What alternative(s) have you considered?
Do not change BoundingVolume trait but add scale method to each volume instead.

Hi, could I work on this as my first issue?

Hi, could I work on this as my first issue?

Yes

This actually isn't that trivial in terms of what the scaling should do. It's not the same as grow and shrink, as the common use cases are quite different. See my comment here: https://github.com/bevyengine/bevy/pull/12142#issuecomment-1966098088

I further clarify the problem in issue title and description. @Jondolf

Fixed by https://github.com/bevyengine/bevy/pull/12142


feat: [Command] add options for spark optimize command

Description
To make this command more flexible. This PR provides options to allow us to easily enable or disable cache configuration.
Usage
protected $usage = 'optimize [-c] [-l] [-r]';

Options
protected $options = [
    'c' => 'Enable config cache',
    'l' => 'Enable locator cache',
    'r' => 'Restore default cache settings',
];

Example
// Enable configCache and locatorCache.
php spark optimize

// Enable configCache only and ignore the others.
php spark optimize -c

// Enable locatorCache only and ignore the others.
php spark optimize -l

// Restore to default cache settings
php spark optimize -r

Checklist:

[x] Securely signed commits
[x] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

I think it would be easier to understand the options if we use long options names, like --config-only.

-r is also a bit difficult to understand. --disable or -d may be better?

Using long options names i think would take extra time to write it. it's better if we keep it simple.
Or we can create additional options as aliases for each option?

@kenjis -d I think is much better.

Or we can create additional options as aliases for each option?

There is no commands that having a short and long options for one action.
So, use short options or use long options.

What if you specify all options spark optimize -c -l -r?

Please fix coding style, and add test code to prove this works fine.

Good PR, every person to run actions.

spark optimize -d does  not reinstall dev packages.

Can you guys run the workflow again. It seems everything is fine now.

Hey @warcooft - if you're still interested in this PR will you find the time to fulfill the final suggestions?


Adds ML query optimization example

Query optimization code to accompany blog post. This contains also
submission preparation for MS MARCO Document ranking tasks.

@davidkyle @Winterflower Would be good to get some 👀 on this before merging. Nothing too detailed, just to make sure it's sane 😄

@joshdevins roger that, checking it over right now


sse4.2: added the implementation for mm_cmpestra

sse4.2: added the implementation for mm_cmpestra
I have created this PR from a new branch as old branch's commit history became very messy.
The implementation is same as old branch.
I am trying to add tests in such a way that each block(case) of code is tested for 2 different values of imm8 and also for both size=8 and size=16 variants.
So for cmpestra there would be 14 cases as written in a comment in the tests file.
I have named the test cases functions to indicate which block of code they would be surely testing.
I have only implemented 4/14 for now, I will implement the rest after getting feedback.
I can also merge different cases in one big test function but I think it looks cleaner this way, if anything needs to be changed please inform me.
Thank You
PS: I am using generator code :)

[7/94] gcc-10 -Itest/x86/40b6604@@simde-tests-x86-emul@sta -Itest/x86 -I../test/x86 -I. -I.. -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -g -march=native -DSIMDE_ENABLE_NATIVE_ALIASES -DSIMDE_NATIVE_ALIASES_TESTING -fPIC -fopenmp-simd -DSIMDE_ENABLE_OPENMP -Wno-psabi -DSIMDE_NO_NATIVE -MD -MQ 'test/x86/40b6604<EMAIL_ADDRESS>-MF 'test/x86/40b6604<EMAIL_ADDRESS>-o 'test/x86/40b6604<EMAIL_ADDRESS>-c ../test/x86/sse4.2.c
../test/x86/sse4.2.c: In function ‘test_simde_mm_cmpestra_equalany_8’:
../test/x86/sse4.2.c:150:11: warning: implicit declaration of function ‘_mm_cmpestra_8_’; did you mean ‘_mm_cmpestra’? [-Wimplicit-function-declaration]
  150 |       r = _mm_cmpestra_8_(test_vec[i].a, test_vec[i].la, test_vec[i].b, test_vec[i].lb, 122);
      |           ^~~~~~~~~~~~~~~
      |           _mm_cmpestra
../test/x86/sse4.2.c: In function ‘test_simde_mm_cmpestra_equalany_16’:
../test/x86/sse4.2.c:231:11: warning: implicit declaration of function ‘_mm_cmpestra_16_’; did you mean ‘_mm_cmpestra’? [-Wimplicit-function-declaration]
  231 |       r = _mm_cmpestra_16_(test_vec[i].a, test_vec[i].la, test_vec[i].b, test_vec[i].lb, 123);
      |           ^~~~~~~~~~~~~~~~

https://github.com/nemequ/simde/pull/295/checks?check_run_id=680612596#step:7:10

With regards to https://github.com/nemequ/simde/pull/295/checks?check_run_id=680612576#step:6:15 , was that supposed to be a negative test? @nemequ do you want negative (should fail to compile) tests?

With regards to https://github.com/nemequ/simde/pull/295/checks?check_run_id=680612576#step:6:15 , was that supposed to be a negative test? @nemequ do you want negative (should fail to compile) tests?

It would be nice, but it would require some work to get it such tests to work, I don't know that it's worth the effort.  I can't remember if µnit supports negative tests or not, but for this type of thing that wouldn't be enough anyways; you'd need support in the build system.
I think this was just a bug that CI caught.

sse4.2: added the implementation for mm_cmpestra
I have created this PR from a new branch as old branch's commit history became very messy.
The implementation is same as old branch.

FWIW, you can force push to the branch to update the PR.  The PR on GitHub will look a bit messy, but I really don't care about that.  The history in the git repo will be nice and clean, and that's all I care about :)
If you don't know how to do that just let me know, I can walk you through it.

Looks good, I think you're on the right track here.
Just make sure you don't throw away your test case generator code accidentally! You might want to push it to a branch just in case.
Sincerely,
Someone who has accidentally trashed code on many, many occasions

Yes, I should push it in a branch, just in case.

sse4.2: added the implementation for mm_cmpestra
I have created this PR from a new branch as old branch's commit history became very messy.
The implementation is same as old branch.

FWIW, you can force push to the branch to update the PR. The PR on GitHub will look a bit messy, but I really don't care about that. The history in the git repo will be nice and clean, and that's all I care about :)
If you don't know how to do that just let me know, I can walk you through it.

I will remember that, thanks. I have been using force push for a while now.

I think I did some mistakes while generating test or there is some bug in my code, so some test functions are failing, I will try to fix it now.

I think everything is fine now, couple of jobs are failing in travis ci, but I think it is not related to PR, I shall quickly implement all the tests.
This is the generater code I am using with some changes for each test : Link

The clang -Wsign-conversion diagnostic on the OpenMP pragma is interesting.  I've filed LLVM bug #45959.  To work around it in SIMDe we can use something like:
diff --git a/simde/simde-common.h b/simde/simde-common.h
index 1f40c3a..7247011 100644
--- a/simde/simde-common.h
+++ b/simde/simde-common.h
@@ -690,6 +690,7 @@ typedef SIMDE_FLOAT64_TYPE simde_float64;
 #    if defined(SIMDE_ARCH_AARCH64)
 #      define SIMDE_BUG_CLANG_45541
 #    endif
+#    define SIMDE_BUG_CLANG_45959
 #  endif
 #  if defined(HEDLEY_EMSCRIPTEN_VERSION)
 #    define SIMDE_BUG_EMSCRIPTEN_MISSING_IMPL /* Placeholder for (as yet) unfiled issues. */
diff --git a/simde/x86/sse4.2.h b/simde/x86/sse4.2.h
index 6299cd5..e3ceb7c 100644
--- a/simde/x86/sse4.2.h
+++ b/simde/x86/sse4.2.h
@@ -167,11 +167,16 @@ simde_mm_cmpestra_8_(simde__m128i a, int la, simde__m128i b, int lb, const int i
       int_res_1 = 0xff;
       for(int i = 0 ; i < upper_bound ; i++){
         int k = i;
+        HEDLEY_DIAGNOSTIC_PUSH
+        #if defined(SIMDE_BUG_CLANG_45959)
+          #pragma clang diagnostic ignored "-Wsign-conversion"
+        #endif
         SIMDE_VECTORIZE_REDUCTION(&:int_res_1)
         for(int j = 0 ; j < (upper_bound-i) ; j++){
           int_res_1 &=  (((bool_res_.i8[k] >> j) & 1 ) << i) ;
           k += 1;
         }
+        HEDLEY_DIAGNOSTIC_POP
       }
       break;
   }
@@ -272,11 +277,16 @@ simde_mm_cmpestra_16_(simde__m128i a, int la, simde__m128i b, int lb, const int
       int_res_1 = 0xffff;
       for(int i = 0 ; i < upper_bound ; i++){
         int k = i;
+        HEDLEY_DIAGNOSTIC_PUSH
+        #if defined(SIMDE_BUG_CLANG_45959)
+          #pragma clang diagnostic ignored "-Wsign-conversion"
+        #endif
         SIMDE_VECTORIZE_REDUCTION(&:int_res_1)
         for(int j = 0 ; j < (upper_bound-i) ; j++){
           int_res_1 &= (((bool_res_.i16[k] >> j) & 1) << i) ;
           k += 1;
         }
+        HEDLEY_DIAGNOSTIC_POP
       }
       break;
   }

I'm more concerned with the other errors on the native cases.  I can reproduce them locally with CFLAGS='-sse4.2' CXXFLAGS='-sse4.2' cmake .. && make -j && ./run-tests /x86/sse4_2/mm_cmpestra.  It looks like the native versions generate a different result for some tests.
Also, you should probably tweak your test case generation code to occasionally generate a 0 in the inputs.  Hitting the end of the string is a common case, there should be tests for it.

Also, you should probably tweak your test case generation code to occasionally generate a 0 in the inputs. Hitting the end of the string is a common case, there should be tests for it.

I will insert include those cases.

It looks like the native versions generate a different result for some tests.

I am concerned with this, what can be the reason for this? Is there anything wrong with the implementation. I feel like the code does what is given in the IIG, but is there something that I am missing?

This is why we have tests, and why it's so important that they be exhaustive.  I didn't see anything wrong with the code on my previous reviews, either.

I am concerned with this, what can be the reason for this? Is there anything wrong with the implementation.

If the native tests don't match the emul tests, there is either a problem with the test cases or the implementation.  SIMDe should always match what the instructions actually do, which may not be exactly what the IIG shows.
In the past, the IIG has been a somewhat dubious source.  My understanding is that the latest version of the IIG is actually verified against Intel's implementation or internal specifications, so it should be accurate.  The only real exception is when an 8-bit immediate arugment is outside the expected range.
I spent a bit of time investigating this.  The first thing I did was figure out exactly which test was failing.  For /x86/sse4_2/mm_cmpestra_equalordered_8, it's the 7th one.  Decoding the flags, I get SIMDE_SIDD_SBYTE_OPS | SIMDE_SIDD_MASKED_NEGATIVE_POLARITY | SIMDE_SIDD_LEAST_SIGNIFICANT.  So now I know which cases to take a closer look at.
Byte vs. word seemed okay.  I verified that it was being dispatched to the correct function; you can just add a quick printf in the code, which is what I did.  If you define SIMDE_NO_INLINE SIMDe functions won't be inlined and you should be able to set a break point in you debugger, but I usually don't resort to that for something as simple as this.
So, next was to look at the polarity.  Taking a closer look, the problem jumped right out.  The code looks like:
    if (polarity & 1) {
      if ((polarity >> 1) & 1) {

So, first we check if the least significant bit is set.  If it is, we then right shift by one bit and see if the least significant bit is set (or, to put it another way, see if the second least siginificant bit is set).
But that's not right.  Those two bits are used for the _OPS flags.  We need the the 5th and 6th bits (4th and 5th if we're counting from 0).  If we change the code to
    if (polarity) {
      if (polarity & SIMDE_SIDD_MASKED_POSITIVE_POLARITY) {

It works.  We've already masked off the irrelevant bits when you set polarity at the beginning of the function, so all we need to do for the first check is see if polarity is non-zero.  For the second test, we don't need to bother with a shift, or hard-code values.  Per the IIG, we're only trying to see if imm8[5] is set.  imm8[5] maps to _SIDD_MASKED_POSITIVE_POLARITY, so just test polarity & SIMDE_SIDD_MASKED_POSITIVE_POLARITY.
Once you've fixed this (in both the 8 and 16 bit versions), you'll need to regenerate the test cases.  I strongly suggest that you always make sure you're generating test cases using the native implementations, and make sure that you enable the relevant ISA extension during development (in this case, add -msse4.2 to your CFLAGS and CXXFLAGS).

It works. We've already masked off the irrelevant bits when you set polarity at the beginning of the function, so all we need to do for the first check is see if polarity is non-zero. For the second test, we don't need to bother with a shift, or hard-code values. Per the IIG, we're only trying to see if imm8[5] is set. imm8[5] maps to _SIDD_MASKED_POSITIVE_POLARITY, so just test polarity & SIMDE_SIDD_MASKED_POSITIVE_POLARITY.

It seems so obvious now I see it, I should have been more rigorous in finding the bug. As I had already found one bug and couldn't spot more I was biased into thinking that the cause of error is something too complex. Clearly, I was wrong. Thank You for finding the bug.

Once you've fixed this (in both the 8 and 16 bit versions), you'll need to regenerate the test cases. I strongly suggest that you always make sure you're generating test cases using the native implementations, and make sure that you enable the relevant ISA extension during development (in this case, add -msse4.2 to your CFLAGS and CXXFLAGS).

I will do that and make sure to use output of native implementations for test cases.

These things often seem obvious in hindsight; I've spent hours on bugs simpler than this.  Often you just need a fresh set of eyes; another person is great, but usually just starting fresh the next day or even just stepping away for a few hours is enough.

Also, you should probably tweak your test case generation code to occasionally generate a 0 in the inputs. Hitting the end of the string is a common case, there should be tests for it.

I will include those cases.

I am confused about this again, isn't hitting the end of the string in mm_cmpestra is decided by la and lb, why we need to have 0 in the input?

I am confused about this again, isn't hitting the end of the string in mm_cmpestra is decided by la and lb, why we need to have 0 in the input?

You're right, sorry.  I was thinking there would be a case in the code for handling a null terminating string regardless of la/lb, but there isn't.
So I guess it's just a matter of fixing the polarity thing, then this can be merged.

I have spotted more errors, I realised that setting a bit of a number is different from assigning it.

I have spotted more errors, I realised that setting a bit of a number is different from assigning it.  I have also made a mistake in limit of for loops, I am actually surprised by the number of errors I have found on looking carefully. I hope it is right after this.

Regarding the ranges, this would be a good opportunity to improve the test cases to cover these cases.  Maybe after you set a and b to random values you could do something like (untested, but hopefully you get the idea):
int matching_chars = munit_rand_int_range(0, sizeof(a.i8) / sizeof(a.i8[0]));
for (int j = 0 ; j < matching_chars ; j++) {
  b.i8[j] = a.i8[j];
}

That way we have tests where the vectors match, either partially or fully.  If you want to increase the number of elements test_vec to increase coverage feel free; 8 is just an arbitrary choice that is sufficient for most functions… it's much better to have too many tests than too few.

I have a few doubts here. I have added a single test which is giving 0 as output on native but 1 on emul. But I am not able to figure out why.  Most probably this part is the problem.
case SIMDE_SIDD_CMP_RANGES:       for(int i = 0 ; i <= upper_bound ; i++){         SIMDE_VECTORIZE_REDUCTION(|:int_res_1)         for(int j = 0 ; j <= upper_bound ; j++){           int_res_1 |= ((((bool_res_.i8[i] >> j) & 1) & ((bool_res_.i8[i] >> (j + 1)) & 1)) << i);           j += 2;         }       }
Apart from this I feel there are some things which logically don't make sense to me from the intrinisics guide, for example how should we handle a_invalid and b_invalid. If we go by IIG it will be like what I have done in 8-bit version, but what I have done in 16-bit makes more sense.

I'm not seeing the error either.  I even threw together a quick implementation from scratch, and I'm getting the same results, so either the IIG is wrong or we're both misreading it in the same way.  I'll play around with this a bit more tomorrow and see if I can narrow down the issue.
In the meantime, you could work on the CRC functions instead.  At least those are well-understood functions; they basically implement CRC-32C.  Or, of course, the AVX2 functions should all be pretty straightforward.

@masterchef2209 Can you refresh this PR ? Thanks!

@masterchef2209 Can you refresh this PR ? Thanks!

I have added the commit of this branch on top of current master.
Thank You


Added tests for project page

Added some test for the project page and extracted a variable from the list navigation tests.

CI is failing, because of the to-date-string tests.

Looks good!


One of your links is not working

On the main site, the link is broken 404: https://gitub.nated.xyz/donate/

Thanks! That site was deprecated, I now use a new one. I went ahead and made Permanent Redirects to point to the new site, any variation of that URL, with a subdomain that is, will now go to the new site with all my projects and docs: https://nateduhamell.com
Have a great night!!


Removed reviewer assignment when using #pass2ship with Dependabot

Current dependencies on/for this PR:

main

PR #1550   👈

This comment was auto-generated by Graphite.


feat: add Discord and Bitbucket providers

closes #159
authored by @afi-dev

@afi-dev I hope you won't mind, it felt wrong to combine the docs changes with Bitbucket and Discord SSOs, on the other hand it was stupid of me to keep this on ice for so long. Thanks for the contribution!


How to set a custom access token?

Hey Jeroen,
I'm really stuck with this problem. Can you please help me out?
https://stackoverflow.com/questions/56792637/is-there-a-way-to-set-a-custom-bearer-access-token-within-the-angular-oauth2-oi
Bedankt voor je hulp / thanks for you support !


App version after lng dist

Hi, I noticed that the app version on the right-bottom corner of the view is not shown (value displayed is undefined), when you run lng dist.
Running lng build, the app version is correctly shown.
SDK version: 4.1.0
CLI version: 2.4.0

This has been fixed https://github.com/rdkcentral/Lightning-CLI/commit/0cebbfbe66de00b7c58d0b9ea62cc19c5b562662


Long DropdownButton scroll animation jank (10000 menu items)

Steps to reproduce

Create a new Flutter project: flutter create dropdown_jank
Replace the contents of the lib/main.dart with the code sample below
Run the app: flutter run --profile
Press the dropdown button and quickly scroll it down using a scroll bar
Observe the jank

Code sample
Code sample
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(
          child: MyWidget(),
        ),
      ),
    );
  }
}

class MyWidget extends StatelessWidget {
  final List<DropdownMenuItem> items = [
    for (var i = 1; i <= 10000; i++)
      DropdownMenuItem(value: i, child: Text(i.toString()))
  ];

  MyWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return DropdownButton(
      items: items,
      onChanged: (_) {},
    );
  }
}

Performance profiling on master channel

[X] The issue still persists on the master channel

Timeline Traces
Timeline Traces JSON
dart_devtools_2023-12-11_16 22 03.322.json

Video demonstration

Video demonstration
[Upload media here]

What target platforms are you seeing this bug on?
Web, Linux
OS/Browser name and version | Device information

OS: Arch Linux x86_64
Kernel: 6.6.3-arch1-1
CPU: AMD Ryzen 7 5800HS
Browser: Chromium Version 119.0.6045.159

Does the problem occur on emulator/simulator as well as on physical devices?
Unknown
Is the problem only reproducible with Impeller?
N/A
Logs
Logs
>>> flutter --verbose create dropdown_jank

dropdown_jank_create.log
>>> flutter --verbose run -d linux --profile --trace-skia

dropdown_jank_run.log

Flutter Doctor output
Doctor output
[✓] Flutter (Channel master, 3.18.0-7.0.pre.57, on Arch Linux 6.6.3-arch1-1, locale en_US.UTF-8)
    • Flutter version 3.18.0-7.0.pre.57 on channel master at /opt/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 10a31934f2 (2 days ago), 2023-12-09 07:35:26 -0800
    • Engine revision fb80aafd25
    • Dart version 3.3.0 (build 3.3.0-213.0.dev)
    • DevTools version 2.30.0

[!] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /opt/android-sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /opt/android-sdk
    • ANDROID_SDK_ROOT = /opt/android-sdk
    • Java binary at: /usr/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.21+9)
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/linux#android-setup for more details.

[✓] Chrome - develop for the web
    • CHROME_EXECUTABLE = /bin/chromium

[✓] Linux toolchain - develop for Linux desktop
    • clang version 16.0.6
    • cmake version 3.27.9
    • ninja version 1.11.1
    • pkg-config version 2.0.3

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/linux#android-setup for detailed instructions).

[✓] Connected device (2 available)
    • Linux (desktop) • linux  • linux-x64      • Arch Linux 6.6.3-arch1-1
    • Chrome (web)    • chrome • web-javascript • Chromium 119.0.6045.159 Arch Linux

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 2 categories.

Hi @sashkent3
I believe this is an issue with ListView in general. I checked this with a sample code that uses ListView with 10000 items. I can also observe janks and the scrolling animation is laggy as well.
That's a known issue at https://github.com/flutter/flutter/issues/52207. Closing this issue in favor of that one, please follow up on it for updates. Thanks!

@huycozy Thanks! Upon reading #52207 I found that itemExtent or prototypeItem can be specified to mitigate the issue (I've verified that the performance is drastically better). In my use case, this is a fine solution, because all menu items should be the same height. However, I don't see the option to specify those attributes for DropdownButton or DropdownMenu. Shouldn't this be implemented?

I have verified, that passing prototypeItem to the underlying ListView fixes my particular example (I feel like Flutter should expose that attribute and itemExtent in the DropdownButton itself). I can't quite figure out how to fix DropdownMenu in the same way - which is what I want to use in my project.

However, I don't see the option to specify those attributes for DropdownButton or DropdownMenu.

I think they would be valid feature requests. Please help to open new issues for DropdownButton and DropdownMenu. You can mention this issue as a use case for them. Thanks!


Asset strategy

Currently all assets imported in the frontend portion are included in the JS/CSS files as data URLs. This means that importing a single image can blow up the size of the JS to be parsed and executed to multiple MBs!
Would be great to somehow skip inlining the assets, but it doesn't appear that easy to solve, as the problematic behavior is built into Vite and not configurable:

https://vitejs.dev/config/build-options.html#build-assetsinlinelimit
https://github.com/vitejs/vite/issues/4454
https://github.com/vitejs/vite/issues/3295
https://github.com/vitejs/vite/pull/5028

Optimal would be some integrations so assets are loaded from the plugin's assets/ folder which Kirby automagically copies to the /media directory: https://getkirby.com/docs/guide/plugins/plugin-basics#plugin-assets

Kirby actually copies assets from a plugin's assets folder to the media folder already:


Is there a way to set default http IdleTimeout for sidecar inbound cluster

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
In our env, some service got a few 503 requests.
I found the reason is that user's app set http server idle timeout to 150s, and envoy has no specified idle timeout for inbound cluster, default value is 1h from envoy docs.
If the interval of two requests to this pod is 150s, user's http server will close this idle connection. And there is a very small chance that envoy is sending the second request to user's server and got connection termination error.
I want to set a global default http idle timeout(maybe 60s)  for sidecar inbound cluster to avoid this mistakes.
Describe alternatives you've considered
Create DestinationRule for each service and set idle timeout.
Affected product area (please put an X in all that apply)
[ ] Ambient
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

cc @ramaraochavali @hzxuzhonghu

I'm also trying to solve 503 errors with nodejs (express) applications where default keepAlive timeout is 5 seconds
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: fix-for-nodejs
  namespace: "${kubernetes_namespace_v1.istio_namespace.metadata[0].name}"
spec:
  configPatches:
  - applyTo: CLUSTER
    match:
      cluster:
      context: SIDECAR_OUTBOUND
    patch:
      operation: MERGE
      value:
        typed_extension_protocol_options:
          envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
            '@type': type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
            common_http_protocol_options:
              idle_timeout: 4s
            use_downstream_protocol_config:
              http2_protocol_options: {}
              http_protocol_options: {}
  - applyTo: CLUSTER
    match:
      cluster:
      context: SIDECAR_INBOUND
    patch:
      operation: MERGE
      value:
        typed_extension_protocol_options:
          envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
            '@type': type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
            common_http_protocol_options:
              idle_timeout: 4s
            use_downstream_protocol_config:
              http2_protocol_options: {}
              http_protocol_options: {}

@alt-dima Can you verify the envoyfilter config whether it will override the idletimeout in a DestinationRule?

@fatedier I will try to check now.
But! DestinationRule manages HttpProtocolOptions in the HTTP_FILTER and not in CLUSTER.
This is the first question I'm trying to understand, what the difference common_http_protocol_options in CLUSTER and in HTTP_FILTER

But! DestinationRule manages HttpProtocolOptions in the HTTP_FILTER and not in CLUSTER.
@alt-dima From my test, DestinationRule will manage idletimeout in CLUSTER for mesh-internal service.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: eample
spec:
  host: example
  trafficPolicy:
    connectionPool:
      http:
        idleTimeout: 14s

@alt-dima hello, did you manage to solve issue with 503?

@alt-dima hello, did you manage to solve issue with 503?

Hello! Which 503 errors?
I solved most of the 503 errors with EnvoyFilter: https://github.com/istio/istio/issues/41328#issuecomment-1364725396
But now I have a very few 503 sometime in time of deployment (added sleep 10 = did not help)

Sadly for me, it did not work fully :S It removed most of them but sometimes they appear for upstream services like graphql. Could you guide me on what are your upstream timeouts? Yeah, I have the same situation in that I onboard service by service to mesh and most of them are not onboarded yet.

We use nodejs/express apps with default 5s keepalive timeout

Same for us. I will share if we will find a solution ;)


Error no connection to printer

whats wrong here, what have to do ? installed at octoprint
Changing monitoring state from "Opening serial connection" to "Error: Connection error, see Terminal tab"
Changing monitoring state from "Error: Connection error, see Terminal tab" to "Offline (Error: Connection error, see Terminal tab)"
Unexpected error while connecting to serial port /dev/ttyACM0, baudrate 115200 from hook stepd: Exception: 'Step Daemon is still updating.' @ comm.py:_open_serial:3670

Same issue here:
Connecting to Step Daemon
Unexpected error while connecting to serial port /dev/ttyUSB0, baudrate 115200 from hook stepd: FileNotFoundError: '[Errno 2] No such file or directory: '/home/pi/.octoprint/data/stepd/stepd': '/home/pi/.octoprint/data/stepd/stepd'' @ comm.py:_open_serial:3670
Could not open port /dev/ttyUSB0, baudrate 115200, skipping
Changing monitoring state from "Detecting serial connection" to "Error: No more candidates to test, and no working port/baudrate combination detected."
Changing monitoring state from "Error: No more candidates to test, and no working port/baudrate combination detected." to "Offline (Error: No more candidates to test, and no working port/baudrate combination detected.)"

Here too!
Changing monitoring state from "Offline" to "Opening serial connection" Connecting to Step Daemon Changing monitoring state from "Opening serial connection" to "Error: Connection error, see Terminal tab" Changing monitoring state from "Error: Connection error, see Terminal tab" to "Offline (Error: Connection error, see Terminal tab)" Unexpected error while connecting to serial port /dev/ttyACM0, baudrate 250000 from hook stepd: FileNotFoundError: '[Errno 2] No such file or directory: '/home/openhabian/.octoprint/data/stepd/stepd': '/home/openhabian/.octoprint/data/stepd/stepd'' @ comm.py:_open_serial:3670

I deleted my .octoprint folder and gave it a fresh start. that solved the problem for me.

/home/pi/.octoprint/data/stepd/stepd seems to be missing.
Is golang installed on your Pi?
You can install it with
sudo apt install golang

Did a fresh install using pi imager. Installed Golang. Ran the zip file in the plugin installer. Did this twice. Still getting a ValueError: 'I/O operation on closed file' @ comm.py:_readline:3940 error as well.
Specifically:
Unexpected error while reading serial port, please consult octoprint.log for details: ValueError: 'I/O operation on closed file' @ comm.py:_readline:3940
Changing monitoring state from "Operational" to "Offline after error"
Connection closed, closing down monitor
It will connect, handshake/echo a reply from an M503 then pop out of connection.
Once I turn the StepDaemon plugin off, everything is fine.


[Screen Readers - Power Toys - Color Picker]: The Name property of an element contain class name like Microsoft . or Window .

Microsoft PowerToys version
"0.41.3"
Running as admin

[ ] Yes

Area(s) with issue?
ColorPicker
Steps to reproduce
Test Environment:
OS: Windows 10 Version Dev
App version: 0.41.3
App name: PowerToys
Screen Reader: Narrator
Tool: Accessibility Insight for Windows
Repro Steps:
Launch Accessibility Insights for Windows tool.
Open Power Toys Settings App.
Navigate to "Color Picker" list item and activate it.
Run Accessibility Insights for Windows tool.
Observe the issue.
User Impact -> Priority 2
When standard controls from accessible technologies are not used and if the user interface elements are not used according to specification, Assistive Technologies (AT) will not be able to gather information about, activate(or set) and keep up to date on the status of user interface controls in the content.
WCAG Reference:
https://www.w3.org/TR/WCAG21/#name-role-value

✔ Expected Behavior
The Name property of an element should not contain class name like Microsoft . or Window . as these are not usually informative.
❌ Actual Behavior
The Name property of an element contain class name like Microsoft . or Window .
Other Software
No response

Resolved with the release of v0.43.0. Thanks @niels9001!


servefiles errors

Error on every line with file=sys.stderr. After editing out the arguments I was able to run the script.

This is fixed already for the next release, and is caused by a break in Python 2 compatibility.

When will the fix be released? I went back to the old version of servefiles for now since there hasn't been an new release with the fix in a while.

The next release is waiting on a pull request to TitleDB being accepted.


Reservoir simulation using FNO and PINO

Modulus Pull Request
This PR adds example that demonstrate integrated workflow, where the finite volume fully/adaptive implicit black oil reservoir simulator is replaced by a physics informed neural operator. This approach is well suited for forward and inverse uncertainty .
Description

Checklist

[x] I am familiar with the Contributing Guidelines.
[x] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.
[x] The CHANGELOG.md is up to date with these changes.
[ ] An issue is linked to this pull request.

Dependencies

/blossom-ci

/blossom-ci

/blossom-ci


Update swagger spec

Overview
The swagger spec didn't reflect what the backend was actually doing. That was causing problems for the the python client when it couldn't pass "page" as a query parameter and when it tried to deserialize "project" as a dict instead of a string.
Checklist

~Styleguide updated, if necessary~
[x] Swagger specification updated, if necessary
~Symlinks from new migrations present or corrected for any new migrations~

Testing Instructions

Compare changes to changes in azavea/raster-foundry-python-client#4

Wait yeah this is wrong. I did something wrong here. These don't match the changes from azavea/raster-foundry-python-client#4 :man_facepalming:


Flatpicker change month

Is there anyway to change the month like the year with the dropdown selection like year does?
Cheers,

+1

This means that she also wants a drop-down list of months in the calendar. and iam +1

Closing as a duplicate of #985 - which will probably be implemented as a plugin in the near future


Zipline-reloaded v2.2 dependency on exchange-calendars <= 3.3 does not include Juneteenth holiday for XNYS

I'm getting reports of trading systems backtesting failing due to not accounting for this holiday.
From what I can tell, exchange-calendars v4.1 DOES have this holiday:
https://github.com/gerrymanoim/exchange_calendars/blob/master/exchange_calendars/exchange_calendar_xnys.py
https://github.com/gerrymanoim/exchange_calendars/blob/master/exchange_calendars/us_holidays.py
but possible v4.x might introduce other issues relating to UTC.

exchange-calendars 3.6.3 DOES have this holiday without the additional issues relating to UTC.

exchange-calendars from version 3.4 renamed several methods, that's the reason why the version was pinned down to 3.3.
In order to be able to use later versions of the library, zipline-reloaded would need to be modified extensively and would lose backward compatibility.
If the issue is just the calendar holidays, that can be easily done by modifying locally the needed exchange_calendar_<...>.py

Unfortunately this will continue to get out-of-date as holidays are changed across the world - Juneteenth in USA, Statehood holiday in Ukraine (July 28) - and Zipline's handling of missing data (due to the missing holiday) is not user friendly.
Expeditiously, it might be as simple as adding a statement like this (for exchange-calendars version of course) to handle this, and deprecate its use in say 24 months.
import zipline as zl

# ...

if zl.__version__ < '2.2.0':
    # do routines specific to versions 1.x and 2.x prior to 2.2.0 here
else:
    # do routines specific to versions 2.2.0 and above

Detail instructions on how to manually add the Juneteenth holidays to exchange_calendars (v3.3)
Navigate to your environment's folder for exchange_calendars (e.g. C:\Users\xxx\anaconda3\envs\zip38\Lib\site-packages\exchange_calendars)
Edit us_holidays.py
Add the following to the bottom of this file

USJuneteenth = Holiday(
    "Juneteenth National Independence Day",
    month=6,
    day=19,
    start_date=Timestamp("2022-01-01"),
    observance=nearest_workday
    )

Edit exchange_calendar_nys.py
add the following at line 68:
    USJuneteenth,

and add the following at line 191:
                USJuneteenth,

You can find instructions for adding new calendars to exchange_calendars which provides this functionality here.


Ability to enable for just a group of users, not for all users on the server

Select groups in the administration panel of Siencemesh and enable the app only for users of these groups.

I did find this: https://github.com/owncloud/core/blob/ab9763b2b4d27a221bf12005eddd2bb7d319d286/lib/private/App/AppManager.php#L227
That might work out-of-the-box on Nextcloud, but not on ownCloud because there we have a switch in config.php that determines whether the
server will try to use the app. So if that switch is globally set to true, and the app is then disabled for some users, it would just lead to a 'class not found' error.

So this code works around the 'enabled' column in the oc_appconfig database table. You can start by adding a JSON-encoded array of group names there, and then calling the isAppEnabledForUser function inside the SciencemeshShareProviderFactory. You should see that the app is not enabled if the user is not in the group.
Once you have that confirmed on both NC and OC-10 you can add the consequence to that: if the app is not enabled, then just refer to the existing default ShareProviderFactory.

@michielbdejong is it possible to do it on ScienceMeshApp.php file instead of do this complex structure?
I found this solution:
`
// Get the user session
$userSession = \OC::$server->getUserSession();
// Get the current user's groups
$userGroups = $userSession->getGroups();
// Check if the user belongs to a restricted group
$restrictedGroup = 'restricted-group-name';
if (in_array($restrictedGroup, $userGroups)) {
// User belongs to the restricted group, disable the app
\OC::$server->getAppManager()->disableApp('myapp');
}
`

Here's the guide for having this feature on Apps in Nextcloud:
You can find it under Settings > apps

And OwnCloud:


[privacy] remove requests to fonts.googleapis.com

For privacy concerns it may be good to remove all references to fonts.googleapis.com in WebUI and to distribute (or not) fonts locally with Camlistore.

All the font files (TTF's) served by Google Fonts are now on GitHub: https://github.com/google/fonts

Knowing how such requests are logged, I'm not worried about this from a privacy point of view, but this might still be nice from a hacking-on-airplanes point of view. Maybe just an option to disable them, rather than hosting them locally even (so we don't need to include them in our already-large repo).
But I personally won't be working on this soon since I have a dozen higher priority things.

Would a PR accepted to bake them into the front-end? They're only 1kb or so, and having all your dependencies local is definitely a nice feature.

@DanielHeath, if it's only a few KB, sure.

I didn't count the actual ttf files. It comes to about 180kb with them - I think that's worthwhile given it's the only off-domain request made.


NovelRT::Maths is incorrectly presenting functions as not [[nodiscard]] when they, in fact, are.

Note: for support questions, please use the #engine-user-help channel in our Discord or create a discussion. This repository's issues are reserved for feature requests and bug reports.
Describe the issue:
A clear and concise description of what the the current behaviour is.
Methods within the NovelRT::Maths namespace that are purely designed to return a value are not marked as [[nodiscard]], and are not documented as behaving in this way. This means people using the API might have unused calls laying around, causing wasted processing time.
Please provide the steps to reproduce if possible:

Clone the repo
Switch to the main branch
Open a sample app and call one of the offending methods without assigning the result to anything
Observe the issue

Expected behaviour:
the [[nodiscard]] attribute should be correctly used, and documented within the doxygen comment.
Please tell us about your environment:
N/A
Additional context:
N/A

As i've already had my feet wet in the maths namespace of NovelRT, i think i can easily help out with this

Assigned. Have fun!


[Android] Markers flicker on State Change

Not sure how to resolve this. I am updating state every second and there are multiple pins... What's the best approach to managing pins with custom images?

I think with the latest version they have fixed this issue. Try upgrading to latest version

#728 should have fixed this but it's still in master and has not been released yet

@stephanemaillard
How do I build the latest version into production? Do I just clone it and do npm link?

You can specify it in your package.json like this :
"react-native-maps": "/airbnb/react-native-maps#master"
Or you could patch your current version by modifing some files in node modules in the same way than this pull request : https://github.com/airbnb/react-native-maps/pull/728/commits

I believe this is fixed now. Please reopen if not.


Ensure log is defined at cutlocus

In an earlier discussion (sorry, I can't find it), we'd discussed how the log map is technically not defined at the cut locus but that it made sense for our log maps to still return a valid velocity vector when mapping between a point and a point in its cut locus, but we wouldn't guarantee which vector was returned. Sphere and Rotations(2) both produced velocity vectors of 0 when mapping between points at a distance of pi. This PR fixes that. Along the way, I added the vee and hat maps for the Lie algebras so(3) and so(2), changed the convention for 2D rotation matrices to represent active rotations, sped up Rotations(2) log! by 3x, and added Rotations(3) to the benchmark.

I thought for the sphere and the rotations we added an error, but I'd be fine with a consistent deterministic vector that corresponds to one of the geodesics, too.

I thought for the sphere and the rotations we added an error, but I'd be fine with a consistent deterministic vector that corresponds to one of the geodesics, too.

No, there was no error. They just returned 0 vectors. I'd prefer a deterministic vector too. Sphere currently returns a random vector. I hadn't thought of this, but we could get a deterministic vector by returning a vector projected from the (1,0,...,0) axis and scaled accordingly unless the point is along the axis, in which case it returns the same but for the (0,1,...,0) axis. Rotations returns deterministic vectors.

As I said, I'd be fine with the (slight) inconsistency to return a deterministic vector from the set of possible vectors.

Matrix logarithm has undefined behavior near pi. When the angle is approximately pi, a valid tangent vector without a norm of pi will sometimes be returned, sometimes a 0 matrix will be returned, and sometimes the matrix will contain all NaNs. What would you all think about a standard flag for log that requires that it always return a valid velocity vector. If the flag is not set, then behavior is undefined and we don't do any checks, but if the flag is set, then checks are turned on to detect when log is undefined and return a valid vector nonetheless.

Why would anyone disable these checks? I don't think they would be particularly expensive.

Why would anyone disable these checks? I don't think they would be particularly expensive.

That's fair. I thought they'd be more expensive for Rotations, but e.g. for SO(4), the eigendecomposition takes ~3μs, while the matrix logarithm takes ~100μs. I guess I could see a possibility of having a manifold where the checks are more expensive, but we can cross that bridge when we come to it.

I think this PR is ready to merge now. Let me know if any changes are needed.

Yes, it's good, I think we can merge it.

Could you write a little more. documentation for wee and hat in general? I always work on SO(3) just with matrices, so I am not yet sure, what I can use that for, still in general, maybe in Manifolds.jl a general fallback with an error message and a proper general documentation what both functions aim for would be nice :) Does it “just” do reshapes to vectors or is there something else you aim for?
Same for  cos_angle_4d_rotation_matrix – a documentation would be great (and yes I know it's always not nice to document everything, but I like having an as complete as possible documentation).
Concerning the log – one could check for the same on the sphere.

Could you write a little more. documentation for wee and hat in general? I always work on SO(3) just with matrices, so I am not yet sure, what I can use that for, still in general, maybe in Manifolds.jl a general fallback with an error message and a proper general documentation what both functions aim for would be nice :) Does it “just” do reshapes to vectors or is there something else you aim for?

I've only encountered vee and hat on SO(n) and SE(n), though I think they could be of general use, as I've found with SU(2). For matrix manifolds, they assume some set of basis matrices that let you represent the matrix vector space with a vector. The basis matrices can be chosen so that the vector has some nice properties. For example, for SO(2), it's the angle of rotation, for SO(3), is the axis-angle representation (and with the usual basis set, SU(2)'s vee map produces the same rotation vector as SO(3) for half of SU(2)), and for SO(4), the first 3 elements represent the first plane rotation (analogous to SO(3)), and the last 3 elements in some sense represent the second plane rotation. hat makes it easy to construct a valid vector space matrix from a simple vector.
Perhaps there's also a use for these to construct vectors tangent to manifold such as Sphere, but I haven't thought about this, because how the bases at different points relate seems a bit arbitrary. It's a bit clearer with group manifolds (e.g. the vee map on the 3-sphere as a group at the identity produces the same vector as SU(2), perhaps with some scaling factor).

Same for  cos_angle_4d_rotation_matrix – a documentation would be great (and yes I know it's always not nice to document everything, but I like having an as complete as possible documentation).

Sure, I hadn't documented this because it's meant to be an internal function, but I can do that.

Concerning the log – one could check for the same on the sphere.

Check for what specifically? This PR already defines log at the antipode of the point on the sphere.

Sorry, I did not look careful enough for the sphere.
Concerning hat and vee, I was wondering, whether they have a meaning and use on arbitrary Riemannian manifolds – but I did not have the time to look for that, and will also not next week, because I am at the ICIAM in Valencia.

Concerning hat and vee, I was wondering, whether they have a meaning and use on arbitrary Riemannian manifolds...

I'll look into that and see if there's a general application.
Also, this isn't ready to merge just yet. For some reason the Travis CI builds stall on OS X for Julia 1 when testing Rotations.

I've finally identified the test that's killing the build. It's the SO(4)/SO(5) matrix exponential with StaticArray, which for Julia 1.0 on OS X for some reason takes an extremely long time to compile. We didn't see this lag before this PR because the matrices at the cut locus hit a different branch point in exp. I've filed an issue for this (see https://github.com/JuliaArrays/StaticArrays.jl/issues/631). For now, I'll convert the matrices to plain Matrix so we can actually pass the tests.

So I did some thinking about the generalization of the hat/vee maps. Given a matrix representation of a tangent space, we can construct a basis for this tangent space (while conventionally tangent vectors have raised indices, their bases have lowered indices): v^{ij} = e_k^{ij} v^k. The vector v^k is in some sense the dual of the original vector, but it's also contravariant. I'll call it a coordinate vector. One way to view the basis is that it acts on the matrix representation of the metric to produce a new matrix compatible with the coordinate vectors:
v^{ij} = v^k e_k^{ij}\\
g(v,w) = v^{ji} w^{ki} g_{jk} = v^m w^n e_m^{ji} e_n^{ki} g_{jk} = v^m w^n g_{mn}\\
g_{mn} \ doteq g(e_m, e_n)

If the basis set is orthogonal, then g_{mn} is diagonal. If the basis set is orthonormal with respect to the metric, then g_{mn} it is the identity matrix, and the norm on the vector space with respect to the metric is equivalent to the Euclidean norm on its coordinate vector.
A basis element can be converted to a cobasis element using the musical isomorphisms, and this above reasoning follows on the cotangent space.
In general, we can construct an orthogonal basis from an initial basis using Gram-Schmidt orthogonalization. This is tedious and slow, however. On Lie groups, we have an advantage, in that the basis on the Lie algebra can be brought to any tangent space via the appropriate group action. There's a bit more theory to work out here, but there are several quantities in practical use of Lie groups that rely on expression of a tangent vector as an actual vector assuming some basis set (Jacobians of exponential parameterization and adjoint matrices, for one; see https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2843106/pdf/nihms-175123.pdf, for example). Again, most of my experience is with the groups in kinematics, so I can't speak to how widely these are used.
In this perspective, the hat and vee maps are simply identification with a basis and extraction of a coordinate vector assuming a basis. I could see the benefit of having some machinery for specifying a basis on a vector space, but this is probably best considered in relation to https://github.com/JuliaNLSolvers/Manifolds.jl/pull/31. I'm fine with not exporting hat and vee and restricting it to just the kinematic groups for now to finish up this PR.

Unless anyone sees any issues, I think this PR is ready to merge.

In this perspective, the hat and vee maps are simply identification with a basis and extraction of a coordinate vector assuming a basis. I could see the benefit of having some machinery for specifying a basis on a vector space, but this is probably best considered in relation to #31. I'm fine with not exporting hat and vee and restricting it to just the kinematic groups for now to finish up this PR.

I think even a slightly more general transformation to an orthonormal basis of a vector space at a point can be useful. @kellertuer added (https://github.com/JuliaNLSolvers/Manifolds.jl/pull/27#issuecomment-511181170 ) a function that computes such bases. #31 is somewhat orthogonal to this issue as I'm not going to work on vector space bases in that PR. Charts will have much bigger impact here.

Unless anyone sees any issues, I think this PR is ready to merge.

I'd like to have the tests pass on appveyor, otherwise it's OK to merge.

The Appveyor failure is the same one documented in https://github.com/JuliaNLSolvers/Manifolds.jl/issues/29 and comes from numerical instability of geodesic numerical integration on 32-bit Windows, so it's not related to these changes. I pushed a few documentation changes to trigger a new build, but if it doesn't pass I don't see a reason to delay the merge.

Right, it's the same failure. Maybe we should just skip this test on 32-bit Windows? At least until we have a proper solution?

I'm fine with that. Do you know how to skip a test for a specific build?

The easiest way would be to surround that test by an if that checks Sys.ARCH and Sys.iswindows().