nrf52_i2c: add support for I2C_M_NOSTOP and I2C_M_NOSTART flags

Summary
Add support for I2C_M_NOSTOP and I2C_M_NOSTART flags.
NRF52 hardware doesn't allow direct control of START/STOP bits, so the only solution is to combine messages into one.
Impact
Testing
Tested with SSD1306 and XX24XX EEPROM

I don't think that this solution is very good, doing this kind of allocation and copy can be quite wasteful depending on message size. I think it is possible to do this by using "list mode" DMA (see SPI implementation on how this is used to transfer arbitrarily sized data in chunks, as one large transaction). For reference see p309 of nRF52832 PS.

I don't think that this solution is very good, doing this kind of allocation and copy can be quite wasteful depending on message size. I think it is possible to do this by using "list mode" DMA (see SPI implementation on how this is used to transfer arbitrarily sized data in chunks, as one large transaction). For reference see p309 of nRF52832 PS.

I don't see how "list mode" can help in this case.
Each TASKS_STARTTX trigger causes a START byte to be sent. EasyDMA can only update the data pointer (TXD.PTR), but we still need to trigger TASKS_START to send data.
We need contiguous buffer in memory to send it with a single TASKS_STARTTX to prevent HW from sending multiple START bytes between messages.
Agree it looks bad but unfortunately I haven't found any other working solution.

I don't see how "list mode" can help in this case.
Each TASKS_STARTTX trigger causes a START byte to be sent. EasyDMA can only update the data pointer (TXD.PTR), but we still need to trigger TASKS_START to send data.
We need contiguous buffer in memory to send it with a single TASKS_STARTTX to prevent HW from sending multiple START bytes between messages.
Agree it looks bad but unfortunately I haven't found any other working solution.

So a repeated start is not sufficient in general?
In that case, I would at least put this behind a config flag (disabled by default), otherwise a performance penalty will be paid even when not really necessary.

So a repeated start is not sufficient in general?
In that case, I would at least put this behind a config flag (disabled by default), otherwise a performance penalty will be paid even when not really necessary.

Repeated stop must be specified in the flags that is the configuration feature we should not be hiding this behind more flags. If we detect that there is not repeated start then we should be able to just use the DMA list feature correct?

Repeated stop must be specified in the flags that is the configuration feature we should not be hiding this behind more flags. If we detect that there is not repeated start then we should be able to just use the DMA list feature correct?

In practices none of the drivers in tree use continued messages that do not expect repeated start so I would not expect to see this memcopy flow hit.

In practices none of the drivers in tree use continued messages that do not expect repeated start so I would not expect to see this memcopy flow hit.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start? From the i2c header file a repeated start requires a NOSTOP on previous message and a zero flag on following one, so that would be the case of repeated starts, right? The change enables the copy on both cases so I think most drivers will see the copy when they could actually have repeated start in most cases.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start? From the i2c header file a repeated start requires a NOSTOP on previous message and a zero flag on following one, so that would be the case of repeated starts, right? The change enables the copy on both cases so I think most drivers will see the copy when they could actually have repeated start in most cases.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start?

It doesn't expect a repeated start.  NOSTART just means that the next chunk is a continuation of the old data.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start?

It doesn't expect a repeated start.  NOSTART just means that the next chunk is a continuation of the old data.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start?

It doesn't expect a repeated start. NOSTART just means that the next chunk is a continuation of the old data.

Right, that is what I meant. I was referring to Brennan's comment regarding that none of the drivers used this feature, but I see they actually do so they would all use the memcpy() implementation.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start?

It doesn't expect a repeated start. NOSTART just means that the next chunk is a continuation of the old data.

Right, that is what I meant. I was referring to Brennan's comment regarding that none of the drivers used this feature, but I see they actually do so they would all use the memcpy() implementation.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start? From the i2c header file a repeated start requires a NOSTOP on previous message and a zero flag on following one, so that would be the case of repeated starts, right? The change enables the copy on both cases so I think most drivers will see the copy when they could actually have repeated start in most cases.

Sorry yes I was remembering wrong on this.  I had to handling this on another i2c master, my point remains though that in this case this should just be treated as a single transfer and that should be fully supported by using the EasyDMA List feature.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start? From the i2c header file a repeated start requires a NOSTOP on previous message and a zero flag on following one, so that would be the case of repeated starts, right? The change enables the copy on both cases so I think most drivers will see the copy when they could actually have repeated start in most cases.

Sorry yes I was remembering wrong on this.  I had to handling this on another i2c master, my point remains though that in this case this should just be treated as a single transfer and that should be fully supported by using the EasyDMA List feature.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start?

It doesn't expect a repeated start. NOSTART just means that the next chunk is a continuation of the old data.

Right, that is what I meant. I was referring to Brennan's comment regarding that none of the drivers used this feature, but I see they actually do so they would all use the memcpy() implementation.

Ah ok.  Regarding the NOSTOP flag, yes, that's what makes the driver send a repeated start.  However, if my recolation is right some drivers (stm32?) do send a repeated start without the NOSTOP flag.  The PIC32MZ driver needs NOSTOP to send a rpeated start.
That said not all drivers use a repeated start, most of them do a stop (completely relinquish the bus) then a start again.
An example of drivers using NOSTOP: https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/mcp794xx.c#L298

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start?

It doesn't expect a repeated start. NOSTART just means that the next chunk is a continuation of the old data.

Right, that is what I meant. I was referring to Brennan's comment regarding that none of the drivers used this feature, but I see they actually do so they would all use the memcpy() implementation.

Ah ok.  Regarding the NOSTOP flag, yes, that's what makes the driver send a repeated start.  However, if my recolation is right some drivers (stm32?) do send a repeated start without the NOSTOP flag.  The PIC32MZ driver needs NOSTOP to send a rpeated start.
That said not all drivers use a repeated start, most of them do a stop (completely relinquish the bus) then a start again.
An example of drivers using NOSTOP: https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/mcp794xx.c#L298

In that case, I would at least put this behind a config flag (disabled by default), otherwise a performance penalty will be paid even when not really necessary.

This is a standard feature of the OS so it should be enabled by default. But configuration option to disable additional code is OK.

If we detect that there is not repeated start then we should be able to just use the DMA list feature correct?

DMA requires TASKS_STARTTX=1 to send the chunks of data, which also sends a START/RESTART byte between chunks, so thise doesn't solve the problem.

In that case, I would at least put this behind a config flag (disabled by default), otherwise a performance penalty will be paid even when not really necessary.

This is a standard feature of the OS so it should be enabled by default. But configuration option to disable additional code is OK.

If we detect that there is not repeated start then we should be able to just use the DMA list feature correct?

DMA requires TASKS_STARTTX=1 to send the chunks of data, which also sends a START/RESTART byte between chunks, so thise doesn't solve the problem.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start?

It doesn't expect a repeated start. NOSTART just means that the next chunk is a continuation of the old data.

Right, that is what I meant. I was referring to Brennan's comment regarding that none of the drivers used this feature, but I see they actually do so they would all use the memcpy() implementation.

Ah ok.  Regarding the NOSTOP flag, yes, that's what makes the driver send a repeated start.  However, if my recolation is right some drivers (stm32 I believe) do send a repeated start when necessary without the NOSTOP flag.  The PIC32MZ driver needs NOSTOP to send a repeated start.
That said not all drivers use a repeated start, most of them do a stop (completely relinquish the bus) then a start again.
An example of drivers using NOSTOP: https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/mcp794xx.c#L298

That driver looks a little suspect to me usually you so not want a STOP in the register read.
NOSTOP is implied in the first message if the NOSTART flag is set on the second one. Drivers are inconsistent about it they set that flag on the first message or leave it 0 but this is what our interface contract says.

I see NOSTART used in various drivers, does that not expect a message without a (repeated) start?

It doesn't expect a repeated start. NOSTART just means that the next chunk is a continuation of the old data.

Right, that is what I meant. I was referring to Brennan's comment regarding that none of the drivers used this feature, but I see they actually do so they would all use the memcpy() implementation.

Ah ok.  Regarding the NOSTOP flag, yes, that's what makes the driver send a repeated start.  However, if my recolation is right some drivers (stm32 I believe) do send a repeated start when necessary without the NOSTOP flag.  The PIC32MZ driver needs NOSTOP to send a repeated start.
That said not all drivers use a repeated start, most of them do a stop (completely relinquish the bus) then a start again.
An example of drivers using NOSTOP: https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/mcp794xx.c#L298

That driver looks a little suspect to me usually you so not want a STOP in the register read.
NOSTOP is implied in the first message if the NOSTART flag is set on the second one. Drivers are inconsistent about it they set that flag on the first message or leave it 0 but this is what our interface contract says.

Taking another look here
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Ftwim.html
It looks like this can be implemented by hooking into SUSPEND which would give full control of start/stop.
The EasyDMA is not clear to me that you would get the stop start since it says the prt and maxcnt are double buffered and updated soon as RX/TXSTARTED

Taking another look here
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Ftwim.html
It looks like this can be implemented by hooking into SUSPEND which would give full control of start/stop.
The EasyDMA is not clear to me that you would get the stop start since it says the prt and maxcnt are double buffered and updated soon as RX/TXSTARTED

That driver looks a little suspect to me usually you so not want a STOP in the register read.

That's not a STOP, that's a repeated start.  The chain is: start - write (set reg to read from) in this case - repeated start - read - stop.

NOSTOP is implied in the first message if the NOSTART flag is set on the second one. Drivers are inconsistent about it they set that flag on the first message or leave it 0 but this is what our interface contract says.

If by NOSTOP you mean repeated start then no, NOSTART just means that the following message(s) are a continuation.  There is no need to reconfigure and no need to send a repeated start.  It's just a bunch of bytes read or written one after the other.
(getting a bit out of topic for this PR, sorry!)

That driver looks a little suspect to me usually you so not want a STOP in the register read.

That's not a STOP, that's a repeated start.  The chain is: start - write (set reg to read from) in this case - repeated start - read - stop.

NOSTOP is implied in the first message if the NOSTART flag is set on the second one. Drivers are inconsistent about it they set that flag on the first message or leave it 0 but this is what our interface contract says.

If by NOSTOP you mean repeated start then no, NOSTART just means that the following message(s) are a continuation.  There is no need to reconfigure and no need to send a repeated start.  It's just a bunch of bytes read or written one after the other.
(getting a bit out of topic for this PR, sorry!)

NOSTOP is implied in the first message if the NOSTART flag is set on the second one. Drivers are inconsistent about it they set that flag on the first message or leave it 0 but this is what our interface contract says.

If by NOSTOP you mean repeated start then no, NOSTART just means that the following message(s) are a continuation. There is no need to reconfigure and no need to send a repeated start.

What I am saying is this:
 *   msg[n].flags  msg[n+1].flags Behavior
 *   ------------ --------------- -----------------------------------------
 *   0            0                Two normal, separate messages with STOP
 *                                 on msg[n] then START on msg[n+1]
 *   0*           I2C_M_NOSTART    Continuation of the same transfer (must
 *                                 be the same direction).  See NOTE below.
 *   NO_STOP      0                No STOP on msg[n]; repeated START on
 *                                 msg[n+1].
 *
 * * NOTE: NO_STOP is implied in this case and may or not be explicitly
 *   included in the msg[n] flags
 */

Drivers are not consistent about NO_STOP in the first message (which is fine), but it is implied as is called out in that note and we need to respect that.

NOSTOP is implied in the first message if the NOSTART flag is set on the second one. Drivers are inconsistent about it they set that flag on the first message or leave it 0 but this is what our interface contract says.

If by NOSTOP you mean repeated start then no, NOSTART just means that the following message(s) are a continuation. There is no need to reconfigure and no need to send a repeated start.

What I am saying is this:
 *   msg[n].flags  msg[n+1].flags Behavior
 *   ------------ --------------- -----------------------------------------
 *   0            0                Two normal, separate messages with STOP
 *                                 on msg[n] then START on msg[n+1]
 *   0*           I2C_M_NOSTART    Continuation of the same transfer (must
 *                                 be the same direction).  See NOTE below.
 *   NO_STOP      0                No STOP on msg[n]; repeated START on
 *                                 msg[n+1].
 *
 * * NOTE: NO_STOP is implied in this case and may or not be explicitly
 *   included in the msg[n] flags
 */

Drivers are not consistent about NO_STOP in the first message (which is fine), but it is implied as is called out in that note and we need to respect that.

It looks like this can be implemented by hooking into SUSPEND which would give full control of start/stop.
I also tried this approach but without success :)

You can stretch the transmission with SUSPEND/RESUME without emitting a START byte, but this works only for currently processed data chunk. If you try to update PTR or MAXCNT after SUSPENDED event, you have to call STARTTX and emit a START byte again.

It looks like this can be implemented by hooking into SUSPEND which would give full control of start/stop.
I also tried this approach but without success :)

You can stretch the transmission with SUSPEND/RESUME without emitting a START byte, but this works only for currently processed data chunk. If you try to update PTR or MAXCNT after SUSPENDED event, you have to call STARTTX and emit a START byte again.

So, to sum it up I believe the situation is as follows:

we should support repeated start using list feature (this is also good in terms of using DMA for large transfers)
for transmissions involving multiple messages where no stop nor repeated start should be sent, copying everything to one chunk only seems possible.

I don't really like to do 2. under the hood as it could involve a lot of data being allocated copied without user knowledge. what if we simply don't support this considering it as a hardware limitation? As discussed I think this is rarely required as in most cases the correct approach is to use a repeated start. This may require looking at existing drivers to see if they actually need to be changed to use a repeated start (assuming the device supports it) instead of just expecting one whole transaction.
I think either way 1. could be separately addressed as it may touch a bunch of code. @raiden00pl would you be interested in doing that? I'm currently using I2C device on nRF52 so I could give it a try if not.

So, to sum it up I believe the situation is as follows:

we should support repeated start using list feature (this is also good in terms of using DMA for large transfers)
for transmissions involving multiple messages where no stop nor repeated start should be sent, copying everything to one chunk only seems possible.

I don't really like to do 2. under the hood as it could involve a lot of data being allocated copied without user knowledge. what if we simply don't support this considering it as a hardware limitation? As discussed I think this is rarely required as in most cases the correct approach is to use a repeated start. This may require looking at existing drivers to see if they actually need to be changed to use a repeated start (assuming the device supports it) instead of just expecting one whole transaction.
I think either way 1. could be separately addressed as it may touch a bunch of code. @raiden00pl would you be interested in doing that? I'm currently using I2C device on nRF52 so I could give it a try if not.

Would be good for places where are doing the repeated start.  Happy to test this on my hardware.
Would we just assert as not supported in this case? I guess if we can cover all the normal cases maybe we can just have this mode be a default off option, that would give you a low performance escape hatch if needed, but you would be aware.  I was trying to remember why this sounded familiar and its because the i2c driver I wrote for the sim under Linux has the same limitation where you end up having to assemble a single buffer for these.

Would be good for places where are doing the repeated start.  Happy to test this on my hardware.
Would we just assert as not supported in this case? I guess if we can cover all the normal cases maybe we can just have this mode be a default off option, that would give you a low performance escape hatch if needed, but you would be aware.  I was trying to remember why this sounded familiar and its because the i2c driver I wrote for the sim under Linux has the same limitation where you end up having to assemble a single buffer for these.

I still don't get why we should use the DMA list anywhere. Repeated start works by default and there is no problem with that. We trigger STARTTX for each I2C message, so new START is sent. The DMA list can be useful when all outgoing messages have the same length. But that is not our case.
Anyway, what this DMA mode does is just automatic data PTR incrementing, nothing more.

In my experience, this is not a rarely required feature, but quite the opposite. We should be careful with making decisions based on our subjective experiences as they can vary greatly.
This feature should be supported in some way. Getting rid of it completely is the worst option.

I still think it should be on by default, but I won't insist. My reasoning is as follows.

The NOSTART/NOSTOP flags are the basic functionality required by the I2C interface from the I2C lower-half implementation.
Disabling support for them is only an additional optimization of the system.
Basic system features should be enabled by default.
Additional system optimizations should be disabled by default.

I still don't get why we should use the DMA list anywhere. Repeated start works by default and there is no problem with that. We trigger STARTTX for each I2C message, so new START is sent. The DMA list can be useful when all outgoing messages have the same length. But that is not our case.
Anyway, what this DMA mode does is just automatic data PTR incrementing, nothing more.

In my experience, this is not a rarely required feature, but quite the opposite. We should be careful with making decisions based on our subjective experiences as they can vary greatly.
This feature should be supported in some way. Getting rid of it completely is the worst option.

I still think it should be on by default, but I won't insist. My reasoning is as follows.

The NOSTART/NOSTOP flags are the basic functionality required by the I2C interface from the I2C lower-half implementation.
Disabling support for them is only an additional optimization of the system.
Basic system features should be enabled by default.
Additional system optimizations should be disabled by default.

In my experience, this is not a rarely required feature, but quite the opposite. We should be careful with making decisions based on our subjective experiences as they can vary greatly.

Most of the I2C device drivers hit use this for reading registers, so we have a byte in msg 1 and then the read buffer. I'm trying to understand how this works today, are we doing a repeated start? Devices are certainly working today on i2c with the nrf52 and I recall the signal looking correct for the transfer.

In my experience, this is not a rarely required feature, but quite the opposite. We should be careful with making decisions based on our subjective experiences as they can vary greatly.

Most of the I2C device drivers hit use this for reading registers, so we have a byte in msg 1 and then the read buffer. I'm trying to understand how this works today, are we doing a repeated start? Devices are certainly working today on i2c with the nrf52 and I recall the signal looking correct for the transfer.

This is what the write buffer for SSD1306 looks like with the current master:

This is what the write buffer with NOSTART flag supported looks like:

This is what the write buffer for SSD1306 looks like with the current master:

This is what the write buffer with NOSTART flag supported looks like:

1. I still don't get why we should use the DMA list anywhere. Repeated start works by default and there is no problem with that. We trigger STARTTX for each I2C message, so new START is sent. The DMA list can be useful when all outgoing messages have the same length. But that is not our case.
   Anyway, what this DMA mode does is just automatic data PTR incrementing, nothing more.

I looked at TWI (not TWIM) docs and indeed repeated starts are supported (I understood from the conversation that this wasn't supported by TWI). So you're right we don't need DMA for this, although it would be nice to have. I don't think there's a limitation on message length since the pointer and data size can be updated on the fly.

I also tried this approach but without success :)
You can stretch the transmission with SUSPEND/RESUME without emitting a START byte, but this works only for currently processed data chunk. If you try to update PTR or MAXCNT after SUSPENDED event, you have to call STARTTX and emit a START byte again.

I think that is actually the point about using TWIM with its DMA features since they explicitly state that you can update the PTR and MAXCNT as they are double buffered. So to avoid the STOP you would suspend transmission as suggested, update pointer and then resume:

There's actually an example for repeated starts where it shows how to update the PTR/MAXCNT in between:

I think that simply not doing the STARTRX/TX would not send the repeated start.

1. I still don't get why we should use the DMA list anywhere. Repeated start works by default and there is no problem with that. We trigger STARTTX for each I2C message, so new START is sent. The DMA list can be useful when all outgoing messages have the same length. But that is not our case.
   Anyway, what this DMA mode does is just automatic data PTR incrementing, nothing more.

I looked at TWI (not TWIM) docs and indeed repeated starts are supported (I understood from the conversation that this wasn't supported by TWI). So you're right we don't need DMA for this, although it would be nice to have. I don't think there's a limitation on message length since the pointer and data size can be updated on the fly.

I also tried this approach but without success :)
You can stretch the transmission with SUSPEND/RESUME without emitting a START byte, but this works only for currently processed data chunk. If you try to update PTR or MAXCNT after SUSPENDED event, you have to call STARTTX and emit a START byte again.

I think that is actually the point about using TWIM with its DMA features since they explicitly state that you can update the PTR and MAXCNT as they are double buffered. So to avoid the STOP you would suspend transmission as suggested, update pointer and then resume:

There's actually an example for repeated starts where it shows how to update the PTR/MAXCNT in between:

I think that simply not doing the STARTRX/TX would not send the repeated start.

I looked at TWI (not TWIM) docs and indeed repeated starts are supported (I understood from the conversation that this wasn't supported by TWI). So you're right we don't need DMA for this, although it would be nice to have. I don't think there's a limitation on message length since the pointer and data size can be updated on the fly.

Please note that we are using the TWIM interface, not the TWI interface.
TWIM always uses EasyDMA. So the question is not if we need EasyDMA but if we need EasyDMA array list (TXD.LIST=1). My point is, we don't need EasyDMA list because it doesn't give us anything.

I looked at TWI (not TWIM) docs and indeed repeated starts are supported (I understood from the conversation that this wasn't supported by TWI). So you're right we don't need DMA for this, although it would be nice to have. I don't think there's a limitation on message length since the pointer and data size can be updated on the fly.

Please note that we are using the TWIM interface, not the TWI interface.
TWIM always uses EasyDMA. So the question is not if we need EasyDMA but if we need EasyDMA array list (TXD.LIST=1). My point is, we don't need EasyDMA list because it doesn't give us anything.

But my point still stands, we should be able to update the pointer/size and use suspend/resume to achieve the desired effect of not sending the stop/start.

But my point still stands, we should be able to update the pointer/size and use suspend/resume to achieve the desired effect of not sending the stop/start.

But my point still stands, we should be able to update the pointer/size and use suspend/resume to achieve the desired effect of not sending the stop/start.

As I said before it doesn't work that way.
Here, someone had a similar problem for the nRF52 SDK:
https://devzone.nordicsemi.com/f/nordic-q-a/66992/resume-suspended-twim-transmission-on-nrf52
The only option is to combine the messages into a single buffer and there's not much we can do about it.

But my point still stands, we should be able to update the pointer/size and use suspend/resume to achieve the desired effect of not sending the stop/start.

As I said before it doesn't work that way.
Here, someone had a similar problem for the nRF52 SDK:
https://devzone.nordicsemi.com/f/nordic-q-a/66992/resume-suspended-twim-transmission-on-nrf52
The only option is to combine the messages into a single buffer and there's not much we can do about it.

Ok, thanks for that link. It seems it is a limitation that is not evident from the documentation. I suppose that we will have to live with this copy.
Still, I'm not sure if the condition (either NOSTART or NOSTOP) is correct, as I think the case that we need to condition it on is only NOSTART. NOSTOP without NOSTART should generate a repeated start and would thus not require the copy.

Ok, thanks for that link. It seems it is a limitation that is not evident from the documentation. I suppose that we will have to live with this copy.
Still, I'm not sure if the condition (either NOSTART or NOSTOP) is correct, as I think the case that we need to condition it on is only NOSTART. NOSTOP without NOSTART should generate a repeated start and would thus not require the copy.

Still, I'm not sure if the condition (either NOSTART or NOSTOP) is correct, as I think the case that we need to condition it on is only NOSTART. NOSTOP without NOSTART should generate a repeated start and would thus not require the copy.

I agree. NOSTART on the second message should be the only case for copying.
I fixed it and added an option to disable I2C_M_NOSTOP flag support.

Still, I'm not sure if the condition (either NOSTART or NOSTOP) is correct, as I think the case that we need to condition it on is only NOSTART. NOSTOP without NOSTART should generate a repeated start and would thus not require the copy.

I agree. NOSTART on the second message should be the only case for copying.
I fixed it and added an option to disable I2C_M_NOSTOP flag support.

Great, thanks.
BTW, did these two devices not work prior to your change? If so, have you tried changing them to use repeated start?

Great, thanks.
BTW, did these two devices not work prior to your change? If so, have you tried changing them to use repeated start?

Unfortunately, they did not work and it took me a lot of nerves to find the cause ;)

Unfortunately, they did not work and it took me a lot of nerves to find the cause ;)

Ill give this a test today.
I am wondering if it would be worth keeping a small buffer around 2-4 bytes that we could use instead of malloc free all of the time. This would save a lot of overhead for small transfers.

Ill give this a test today.
I am wondering if it would be worth keeping a small buffer around 2-4 bytes that we could use instead of malloc free all of the time. This would save a lot of overhead for small transfers.

I am wondering if it would be worth keeping a small buffer around 2-4 bytes that we could use instead of malloc free all of the time. This would save a lot of overhead for small transfers.

I was thinking about something similar.
For NRF52832 we could even keep a buffer with the maxium supported length = 255.
But for NRF52840 it doesn't make sene because the maximum length of sent data can be 65535.
Another option is a buffer with a user-configurable length, and I think that's a pretty reasonable solution.

I am wondering if it would be worth keeping a small buffer around 2-4 bytes that we could use instead of malloc free all of the time. This would save a lot of overhead for small transfers.

I was thinking about something similar.
For NRF52832 we could even keep a buffer with the maxium supported length = 255.
But for NRF52840 it doesn't make sene because the maximum length of sent data can be 65535.
Another option is a buffer with a user-configurable length, and I think that's a pretty reasonable solution.

Ill give this a test today.

I just remembered there is something wrong with sending large packets of data for I2C with IRQs enabled (I2C_POLLED=n). After some time, I2C freezes. I haven't diagnosed the problem yet, but I'll let you know if you come across something similar. Polled I2C works fine for me.

Ill give this a test today.

I just remembered there is something wrong with sending large packets of data for I2C with IRQs enabled (I2C_POLLED=n). After some time, I2C freezes. I haven't diagnosed the problem yet, but I'll let you know if you come across something similar. Polled I2C works fine for me.

I am wondering if it would be worth keeping a small buffer around 2-4 bytes that we could use instead of malloc free all of the time. This would save a lot of overhead for small transfers.

I was thinking about something similar.
For NRF52832 we could even keep a buffer with the maxium supported length = 255.
But for NRF52840 it doesn't make sene because the maximum length of sent data can be 65535.
Another option is a buffer with a user-configurable length, and I think that's a pretty reasonable solution.

I was thinking we keep it short because I would expect the large writes are usually going to be constrained to displays and memory devices which are already going to be slow on i2c and also tend to use more ram than say a small sensor.  But I would be fine making it configurable with a default around 4 bytes which would cover 2 byte reads to a 16bit "address".  Do you want me to create a PR for this after we merge this?

I am wondering if it would be worth keeping a small buffer around 2-4 bytes that we could use instead of malloc free all of the time. This would save a lot of overhead for small transfers.

I was thinking about something similar.
For NRF52832 we could even keep a buffer with the maxium supported length = 255.
But for NRF52840 it doesn't make sene because the maximum length of sent data can be 65535.
Another option is a buffer with a user-configurable length, and I think that's a pretty reasonable solution.

I was thinking we keep it short because I would expect the large writes are usually going to be constrained to displays and memory devices which are already going to be slow on i2c and also tend to use more ram than say a small sensor.  But I would be fine making it configurable with a default around 4 bytes which would cover 2 byte reads to a 16bit "address".  Do you want me to create a PR for this after we merge this?


Rename wrong words

def_excel 😃

HA, excellent catch - thank you! I'll merge this tomorrow, @runningzyp - and don't forget to add yourself to contributors in the README too!


Is it possible to use websocket for transport and noise for encryption?

Is it possible to use websocket for transport and noise for encryption?
Originally posted by @fernvenue in https://github.com/rapiz1/rathole/issues/290#issuecomment-1742034945

No. You have to change the code and somehow stack the transport layer,
which I think should be doable. But I wonder why not websocket with tls?
On Sun, Oct 1, 2023, 18:58 fernvenue @.***> wrote:

Is it possible to use websocket for transport and noise for encryption?
Originally posted by @fernvenue https://github.com/fernvenue in #290
(comment)
https://github.com/rapiz1/rathole/pull/290#issuecomment-1742034945
—
Reply to this email directly, view it on GitHub
https://github.com/rapiz1/rathole/issues/293, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZMOZIPYJGVLUFZEMVACRLX5FED5ANCNFSM6AAAAAA5OHTBCY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi @rapiz1, I just discussed this with @rucciva in https://github.com/rapiz1/rathole/pull/290.
At start, I thought we might can use websocket to get better performance, but TLS is a little bit complex sometimes than noise, so I wondering that can we use websocket with noise :)
Then @rucciva suggests that I should do a benchmark, here I did, and the answer is that we should keep using TCP as protocol if we want best performance for both bandwidth and latency.
So, if anyone else have the same question, check the benchmark test, and I'm gonna close this issue for now.


Make contributing page up to date

Remove mention of (retired) bitcoin-discuss list
Remove mention of bitcoin-core-dev list under "discussion", as it has been changed into an announcements list and there was never any discussion there in the first place
Add mention of other relevant IRC channels

This fails tests because translated pages still use the old bitcoin-discuss link:
## Check for broken Markdown reference-style links that are displayed in text unchanged, e.g. [broken][broken link]
! find _site/ -name '*.html' | xargs grep ']\[' | grep -v skip-test | grep .
_site/zh_CN/contribute/index.html:比特币协议讨论区 bitcoin-dev 和一个普通比特币讨论区 [bitcoin-discuss][].

_site/ja/contribute/index.html:
Bitcoin Coreに関する議論の大部分は、irc.freenode.netの#bitcoin-core-dev IRCチャネルもしくはbitcoin-core-devメーリングリストで行われます。Bitcoinプロトコルについて議論するbitcoin-devや一般的なBitcoinの議論をする[bitcoin-discuss][]などのメーリングリストもあります。

Makefile:20: recipe for target 'test-fast' failed

Options are:

Try to edit the translated pages
Restore the [bitcoin-discuss] link to the references.md file and increment the version header in the 2016-01-01-contribute.md file; this will unbreak the links and let translators know their pages need to be updated.

Sorry for the extra work.

I don't feel comfortable editing Chinese and Japanese here as it doesn't seem to be clearly separable (like an enumeration item). So went with [2].

Tested ACK ebca57c3fd831aab3fdf5b1bc213f4604e55019c .  Built a preview, clicked the IRC channel links, and made sure they matched what's in my IRC client.  Also reviewed diff.  Thanks!


Rework project repository clone

Fix git clone waiting for interactive input when trying to clone private or non-existing GitHub repository.
Add timeout for git commands.
The git_hash project field is now read only.

Resolves: https://issues.redhat.com/browse/AAP-4833
Resolves: https://issues.redhat.com/browse/AAP-6185

Note: Further refactoring is needed and will be done in subsequent PRs.


Add exceptions

Throw exceptions in config manager, on init sdl and other places when error can be.
Find proper way to handle exceptions

refactored error handling, added exceptions


[Question] lifecycle callback beforeCreate() with createEach()

Sails version: v1.1.0
Node version: v10.12.0
NPM version: v6.9.0
DB adapter name: N/A
DB adapter version: N/A
Operating system: macOS

The documentation on lifecycle callbacks of a model states [Link]:
beforeCreate() is not run on bulk inserts of data using createEach.

But, I am seeing opposite behavior. beforeCreate() is run for each insert of createEach.
Is it an old functionality that will be removed in later versions, or is it a new functionality but the documentation isn't updated.
My implementation will change depending on scenario. Please advise.

@shobhitsinghal624 just tried it out myself and it looks like the docs are just out of date. (Although afterCreate definitely doesn't run for .createEach(), so bear that in mind.)
I updated that doc page here: https://github.com/balderdashy/sails-docs/commit/ad53ec5b62b83eded89d058865b833899985f71a


Optimize Type::HashValue

Hello - this is 2/N, please see PR#4705 for context
This change is the result of seeing Type::HashValue was ~7.5% of our runtime when compiling shaders.  These changes get it down to < .5%.
First, we compute the hash incrementally instead of gathering the "words" into a std::vector, inserting them into a u32string, and then hashing that string.  This avoids two series of [re]allocations, and avoids making three total passes over the hashed data.
Next, instead of using a std::unordered_set to avoid processing duplicates, we use a std::vector -- the unordered_set requires an alloc/free when inserting/removing, and has a larger constant-factor than a linear search through a small, dense, cache coherent vector.  I've never seen the vector contain more than a few items.
Last, swap out the std::vector for a utils::SmallVector to avoid Type::HashValue making any allocations at all in the common case.

Ready for review.

Puzzling through the gcc thing in godbolt...

I will go back to godbolt for the mac/ndk failures.  Seem the same root cause... I apologize for all this.  Will try to get to it this evening.

Looks like this is after I tried including , where hash should be defined.  My only thought is that "AppleClang 11.0" doesn't implement hashing for enum types (as expected by the language?).  I couldn't reproduce this on Godbolt with any clang version.  Absent coming up with more ideas I will cast these enums to uint32_ts.

Looks like this is after I tried including , where hash should be defined. My only thought is that "AppleClang 11.0" doesn't implement hashing for enum types (as expected by the language?). I couldn't reproduce this on Godbolt with any clang version. Absent coming up with more ideas I will cast these enums to uint32_ts.

I would trying casting to an int as well.  I can't figure out what else might be missing.


Releases: automate alpha releases for every merge

Currently, it makes no sense holding back releases—every PR merged should equal a new release on NPM so anyone can just download the latest package.
Once we approach a stable beta, we can remove this action as we'd want a more nuanced release approach.

Won't do this anymore—we've reached feature parity.


Zero-ize secrets

By @koraa in https://github.com/stv0g/go-rosenpass/issues/27#issuecomment-1604344997
Severity: 3 (Dangerous): No zeroization is attempted.
https://github.com/golang/go/issues/21865

This is difficult to some degree as liboqs-go as well as circl to allocate []byte-slices for storing secrets themselves:

liboqs: https://pkg.go.dev/github.com/open-quantum-safe/liboqs-go/oqs#KeyEncapsulation.GenerateKeyPair

Related to #1


Does this work for MiBand 4?

I was testing this for MiBand4 but it was not able to scan and find this device. Could you provide more documentation on how to access the data?

it does not support miBand 4 and higher versions


Improve the sidenav

I'm submitting a ...

[ ] bug report
[x] feature request

Current behaviour:
Currently the sidenav only closes when the toggle button is clicked. And it is translucent.
Expected behaviour:
When sidenav is open, clicking anywhere on the page except for the sidenav should close it. And it should be made opaque.

i would like to work on this. Can i get some more details as to which files are concerned with this feature??

@abhanshgiri21, the JS for the feature is present in public/js/index.js and the html is in views/partials/adminheader.hbs

i am on it.
i will make the background of sidenav white and opaque.
would try to add the functionality that sidenav closes when we click anywhere else on page.
i am doing this right now so please be active as if i need any more help i will comment right away. i would love a fast reply.
thanks

i did it. the sidenav is now opaque with white background and it disappears if its open when clicked anywhere else on page. please close this issue.

Submit your commit referencing this issue.

i downloaded the zip and made the changes on my local machine. unfortunately this is my first time contributing to a open source project. Can you tell me how to make the pull request. I have edited files on my local machine. What do i do now?

nevermind , i figured it out and made a commit.

@abhanshgiri21  nice work. Please have a  look at some other issues or create a new issue if you find one.


[#6187, #6222] Fixing the GeoShapes GeoHash and GeoTile Aggregations Integration tests to make them more robust.

Description
Fixing the GeoShapes GeoHash and GeoTile Aggregations Integration tests to make them more robust.
Signed-off-by: Navneet Verma<EMAIL_ADDRESS>The issue was happening few random seeds. For GeoHash aggregations on shape we are getting ArrayIndexOut of bounds exception because we were not resetting the values of SortedNumericDocs leading to access of memory area not initialized by the vectors.
Issues Resolved
#6187, #6222
Testing
Done using the failed gradle flows in the issues.
(base) 12:03 /Volumes/workplace/OpenSearch main$ ./gradlew ':modules:geo:internalClusterTest' --tests "org.opensearch.geo.search.aggregations.bucket.GeoHashGridIT.testGeoShapes" -Dtests.seed=58EEE2632DEE6DD -Dtests.security.manager=true -Dtests.jvm.argline="-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=64m" -Dtests.locale=ar-OM -Dtests.timezone=Europe/Madrid
Picked up JAVA_TOOL_OPTIONS: -Dlog4j2.formatMsgNoLookups=true

> Configure project :qa:os
Cannot add task 'destructiveDistroTest.docker' as a task with that name already exists.
=======================================
OpenSearch Build Hamster says Hello!
  Gradle Version        : 7.6
  OS Info               : Mac OS X 12.6.3 (x86_64)
  JDK Version           : 11 (Eclipse Temurin JDK)
  JAVA_HOME             : /Users/navneev/.sdkman/candidates/java/11.0.16-tem
  Random Testing Seed   : 58EEE2632DEE6DD
  In FIPS 140 mode      : false
=======================================

> Task :libs:opensearch-x-content:compileJava
Picked up JAVA_TOOL_OPTIONS: -Dlog4j2.formatMsgNoLookups=true
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

> Task :server:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :modules:geo:compileJava
Note: /Volumes/workplace/OpenSearch/modules/geo/src/main/java/org/opensearch/geo/GeoModulePlugin.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :test:framework:compileJava
Picked up JAVA_TOOL_OPTIONS: -Dlog4j2.formatMsgNoLookups=true
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :modules:geo:compileTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :modules:geo:compileInternalClusterTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

> Task :modules:geo:internalClusterTest
Picked up JAVA_TOOL_OPTIONS: -Dlog4j2.formatMsgNoLookups=true
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by org.opensearch.bootstrap.BootstrapForTesting (file:/Volumes/workplace/OpenSearch/test/framework/build/distributions/framework-3.0.0-SNAPSHOT.jar)
WARNING: Please consider reporting this to the maintainers of org.opensearch.bootstrap.BootstrapForTesting
WARNING: System::setSecurityManager will be removed in a future release
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by org.gradle.api.internal.tasks.testing.worker.TestWorker (file:/Users/navneev/.gradle/wrapper/dists/gradle-7.6-all/9f832ih6bniajn45pbmqhk2cw/gradle-7.6/lib/plugins/gradle-testing-base-7.6.jar)
WARNING: Please consider reporting this to the maintainers of org.gradle.api.internal.tasks.testing.worker.TestWorker
WARNING: System::setSecurityManager will be removed in a future release

BUILD SUCCESSFUL in 3m 21s
48 actionable tasks: 10 executed, 38 up-to-date
<-------------> 0% WAITING
> IDLE
> IDLE
> IDLE
> IDLE
> IDLE
> IDLE
> IDLE
(base) 12:18 /Volumes/workplace/OpenSearch main$ ./gradlew ':modules:geo:internalClusterTest' --tests "org.opensearch.geo.search.aggregations.bucket.GeoTileGridIT.testGeoShapes" -Dtests.seed=EC3F504EF22998E0
Picked up JAVA_TOOL_OPTIONS: -Dlog4j2.formatMsgNoLookups=true

> Configure project :qa:os
Cannot add task 'destructiveDistroTest.docker' as a task with that name already exists.
=======================================
OpenSearch Build Hamster says Hello!
  Gradle Version        : 7.6
  OS Info               : Mac OS X 12.6.3 (x86_64)
  JDK Version           : 11 (Eclipse Temurin JDK)
  JAVA_HOME             : /Users/navneev/.sdkman/candidates/java/11.0.16-tem
  Random Testing Seed   : EC3F504EF22998E0
  In FIPS 140 mode      : false
=======================================

> Task :modules:geo:internalClusterTest
Picked up JAVA_TOOL_OPTIONS: -Dlog4j2.formatMsgNoLookups=true
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by org.opensearch.bootstrap.BootstrapForTesting (file:/Volumes/workplace/OpenSearch/test/framework/build/distributions/framework-3.0.0-SNAPSHOT.jar)
WARNING: Please consider reporting this to the maintainers of org.opensearch.bootstrap.BootstrapForTesting
WARNING: System::setSecurityManager will be removed in a future release
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by org.gradle.api.internal.tasks.testing.worker.TestWorker (file:/Users/navneev/.gradle/wrapper/dists/gradle-7.6-all/9f832ih6bniajn45pbmqhk2cw/gradle-7.6/lib/plugins/gradle-testing-base-7.6.jar)
WARNING: Please consider reporting this to the maintainers of org.gradle.api.internal.tasks.testing.worker.TestWorker
WARNING: System::setSecurityManager will be removed in a future release

BUILD SUCCESSFUL in 17s
48 actionable tasks: 1 executed, 47 up-to-date

Check List

[X] New functionality includes testing.

[X] All tests pass

[X] New functionality has been documented.

[X] New functionality has javadoc added

[X] Commits are signed per the DCO using --signoff
[X] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@nknize @andrross can you please take a look at this PR.

Gradle Check (Jenkins) Run Completed with:

RESULT: FAILURE ❌
URL: https://build.ci.opensearch.org/job/gradle-check/10869/
CommitID: 77a1f0e
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
Is the failure a flaky test unrelated to your change?

Fixing these tests.


docs(managing-workflow): document all available environment variables

closes deis/controller#570
closes deis/charts#223

@bacongobbler does this PR depend on https://github.com/deis/charts/pull/268? you referred to it in as you mentioned in https://github.com/deis/charts/pull/268#issuecomment-220688258, so just wondering

yes this would rely on deis/charts#268. :)

Whoops, I missed that https://github.com/deis/workflow/pull/141 relied on this ticket to be merged beforehand.  Docs currently not building as it now looks for the file added in this PR.
ping @arschles and @mboersma on whether or not this is ready to go...

Lemme get on real quick and rebase against the comments

Removing my LGTM until this updates the GUNICORN_WORKERS text.

@mboersma I've updated the gunicorn text and rebased this PR.


data race in Server.Stop (unprotected write to srv.Timeout)

it is also accessed in Server.shutdown

How to reproduce?

https://github.com/tylerb/graceful/pull/51 (test only. can send a fix separately)


[BUG] SQL extendedAuditingSettings not available

Describe the bug
Unable to query a SQL server's extendedAuditingSettings to get info about this state here:

Expected behavior
Via PowerShell I can do Get-AzSqlServerAudit -resourcegroupname <> -servername <> -debug and that shows me that it's querying /subscriptions/{subscriptionId}/providers/Microsoft.Sql/servers/{serverName}/extendedAuditingSettings/default?api-version=2019-06-01.
Actual behavior (include Exception or Stack Trace)
I can't find the extendedAuditingSettings anywhere in the documentation.

Could Sql team take a look whether the requested API exists in swagger api?


[Maxwell2D] Determination of the return path for matrix definition

How to define the return path for a 2D (XY) coil turn when using assign_matrix?
The function itself has no corresponding property.

An example ist:
from pyaedt import Maxwell2d
#% Definition von Variablen in mm!
mx = 10     # magnet length in x-direction
my = 3      # magnet length in y-direction
p = 24      # phase length - distance between center of 3 magents
dist = 5  # distance between two magnets in z-direction
cx = 8      # coil length in x-direction
cy = 3   # coil length in y-direction
pc = 18     # phase length - distance between center of 3 coil
dx = 0      # displacement of coils
m_num = 2   # number of magnets per line
c_num = 2   # number of coil strand
m2d = Maxwell2d(solution_type="MagnetostaticXY")
#% Create Variables
exec('m2d["mx"] = "'+str(mx)+'mm"')
exec('m2d["my"] = "'+str(my)+'mm"')
exec('m2d["p"] = "'+str(p)+'mm"')
exec('m2d["dist"] = "'+str(dist)+'mm"')
exec('m2d["cx"] = "'+str(cx)+'mm"')
exec('m2d["cy"] = "'+str(cy)+'mm"')
exec('m2d["pc"] = "'+str(pc)+'mm"')
exec('m2d["dx"] = "'+str(dx)+'mm"')
exec('m2d["m_num"] = "'+str(m_num)+'"')
exec('m2d["c_num"] = "'+str(c_num)+'"')
Create magnetic materials in Maxwell
Hc = -840000 # coercitivity in A/m
m2d.materials.checkifmaterialexists("NdFe30")
mat1 = m2d.materials.duplicate_material("NdFe30", "ndfe_py")
mat1.set_magnetic_coercitivity(Hc,0,1,0)
mat1.update()
mat2 = m2d.materials.duplicate_material("NdFe30", "ndfe_ny")
mat2.set_magnetic_coercitivity(Hc,0,-1,0)
mat2.update()
#% Create Magnet --> [x size, y size]
for n in range(0, m_num):
mat = "ndfe_ny" if n % 2 == 0 else "ndfe_py" # change of magnetization direction
for nn in range(-1,2,2):
mag_name = "Magnet_"+str(n+1) if nn ==1 else "Magnet_m"+str(n+1)
m2d.modeler.primitives.create_rectangle(["-(m_num-1)*p/4-mx/2+"+str(n)+"*p/2", str(nn)+"*dist/2", 0], ["mx", str(nn)+"*my"],is_covered=True, name=mag_name, matname=mat)
for n in range(0, c_num):
coil_name = "Coil_"+str(n+1)
coil = m2d.modeler.primitives.create_rectangle(["-(c_num-1)*pc/4-cx/2+"+str(n)+"*pc/2+dx", "-cy/2", 0], ["cx", cy"],is_covered=True, name=coil_name, matname="vacuum")
#% Create Air Region
region = m2d.modeler.primitives.create_region([100,300,100,300])
#% Create Boundaries
m2d.assign_balloon(region.edges, bound_name = "Balloon")
#% Assign current on the coils (direction: true -> positive, false -> negative)
m2d.assign_current("Coil_1", amplitude=1, swap_direction=False, name="Current1")
m2d.assign_current("Coil_2", amplitude=1, swap_direction=True, name="Current2")
I want to calculate the inductance:

I tried something like:
L = m2d.assign_matrix('Current1', matrix_name='Matrix')
L.props['ReturnPath' = 'Current2
But L has no attribute 'props'.

Hi,
It is not still implemented in pyAEDT, but you could use AEDT API to perform this operation:
m2d.o_maxwell_parameters.EditMatrix(L, ["NAME:Matrix",["NAME:MatrixEntry",["NAME:MatrixEntry", "Source:=", "Current1", "NumberOfTurns:=", "2","ReturnPath:=", "Current2"]],["NAME:MatrixGroup"]])
Let me know if it works.
Regards,
Samuel

Hello,
thank you very much, this solution also works.

But is there already a way to pass matrix solutions to Python directly, via a get command?
Or is it mandatory to go via create_report and export_report_to_file and then read the file?


NFDIV-2216 - AOS SOT not displayed

Change description

To migrate Application::applicant2StatementOfTruth field to AOS::statementOfTruth.
Always show the AOS::statementOfTruth in the AOS field.
Only apply this in AAT for now.

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/NFDIV-2216
Before merging a pull request make sure that:

[ ] tests have been updated / new tests has been added (if needed)
[ ] README and other documentation has been updated / added (if needed)

If this ticket will have any visible impact on users and is not behind a feature toggle, make sure that:

[ ] this ticket been reviewed by QA
[ ] the user story been signed off by the PO

Note that bug fixes, dependency updates and technical tasks do not directly impact the user experience and can be merged without QA and PO review.
If this user story cannot be immediately merged find a way to put it behind a feature toggle and get it merged.

other than the conversation we had, its LGTM


Menu flickering inside shadow dom

Current behavior
The  component's submenus flicker when used inside shadow dom. Which makes it hard to select a submenu item.
https://github.com/ariakit/ariakit/assets/30146019/64c978af-15d5-49a0-a310-5d102bd84ac1
Steps to reproduce the bug

Open sandbox: https://stackblitz.com/edit/ondrbq?file=app%2Fpage.tsx
Open the menu and mouse the cursor over the items with a submenu.

In the example above is the same as the default demo, expect that I've wrapped the menu example in ShadowRoot.div to render it inside shadow dom, and (optional) moved the styles inside the shadow dom, so the menu looks presentable.
This is not related to react-shadow, this can be reproduced also by manually creating a shadow dom and rendering the menu there.
Expected behavior
The menu should work without flickering.
Workaround
https://github.com/ariakit/ariakit/issues/2983#issuecomment-1775092916
Possible solutions
https://github.com/ariakit/ariakit/issues/2983#issuecomment-1775092916

The Menu component, which uses Hovercard at its core, currently doesn't account for shadow roots.
You can mitigate this issue by implementing a custom hideOnHoverOutside logic that reads the event target from event.composedPath() rather than event.target.
<Ariakit.Menu
  // TODO: Remove when https://github.com/ariakit/ariakit/issues/2983 is fixed
  hideOnHoverOutside={(event) => {
    if (!menu.parent) return false;
    const { contentElement, anchorElement } = menu.getState();
    const [target] = event.composedPath() as Node[];
    if (!target) return false;
    const activeElement = target.ownerDocument?.activeElement;
    if (anchorElement?.contains(target)) return false;
    if (contentElement?.contains(target)) return false;
    if (activeElement && target.contains(activeElement)) return false;
    return true;
  }}
>

A possible solution within the library involves refining this line:
https://github.com/ariakit/ariakit/blob/6c695e868a4225b584dad634042f5a73d1ca9209/packages/ariakit-react-core/src/hovercard/hovercard.tsx#L171

Thank you for quickly providing a workaround @diegohaz , it works perfectly!
I'll see if I can find time and hopefully open a PR with a fix.


include sass files used to generate bulma.css files

can you please include sass files used to generate bulma.css with variable so i can create it using bulma from original repo

@badalsurana When I get a chance, I will add it and a few new templates.

Thank you for making these templates.
Any chance you will still commit the sass files?


FancyZones Space around windows when their shouldn't be

Microsoft PowerToys version
0.64.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
FancyZones
Steps to reproduce
Have an update of PowerToys, it finishes.
Hover on the PowerToys icon on the hidden part of the taskbar.
Relaunch PowerToys.
Using FancyZones's shift drag to snap a window, it shows the zones but also a gutter.
When released, there is a gutter around the window.
✔ Expected Behavior
Their shouldn't be a gutter, in my layout editor "space around zones" is disabled and the preview doesn't show a gutter. I try to edit my layout, change some positions, enable and redisable the space around window, then save, their is still the space around the windows when I retry to snap a window.
❌ Actual Behavior
Their is space around the windows. It happens for most updates.
Other Software
No response

The toggle switch to disable zone spacing doesn't seem to work anymore. The set distance is kept, even if the switch is diabled. As a workaround one has to set the spacing to 0 px.

Already logged I think: https://github.com/microsoft/PowerToys/issues/21630

/dup of https://github.com/microsoft/PowerToys/issues/21630


Issues with binder env

I don't think this will work with binderbot because you are not pointing to a proper binder repo here:
https://github.com/xgcm/xgcm-examples/blob/0fbaaf1ec7f4e694accd3de181919238b84ab0b7/binder-gallery.yaml#L7-L8
Can you try using the default binder?
https://github.com/pangeo-gallery/example-gallery/blob/315eb264ebfb94651ee336ea1e7babe48b22fd1c/binder-gallery.yaml#L8-L9
That will also fix your build, because the image is already built.

Thanks @rabernat
I think I just pasted this on the wrong line. Apologies...
Admittedly I am flying a bit blind here. I think it might be good to show an example of 'what to replace' in the Remove the dummy content and add your content. bullet?
I used some of the existing gallery repos to 'visually diff' the changes necessary, but clearly, I got confused in the process.

Agree it is currently super confusing. Would love suggestions on how to improve.

This sentence ("Sometimes, the GitHub Action to add your repo as a submodule will fail. We can work with you to identify and fix issues. Sometimes, making a new issue in the same way as above is necessary to correctly reload new settings from your gallery repo.") is great advice, but I think it would be good to show the user what a 'success' looks like beforehand.

E.g. Before the sentence say: "If your request was successful, you will see an automated response like this:"

I think the user then needs some more info about what will happen next and if they need to do anything except for wait for the gallery maintainers to merge?

@rabernat Should I paste these suggestions in another issue, so we can close this one?


Broken in Mura 5.5?

What it says in the title: when doing a search via Solr in Mura 5.5.4665, no results are displayed.

Can you explain this further? I don't quite understand.

My apologies - I've found what the problem was.
For some reason, I'd managed to omit the "display=search" form parameter. All working as expected now!


[capture] Thread protect for create wrappers and remove wrappers

VulkanStateTableBase::mutex_ on  InsertEntry and RemoveEntry can't protect wrappers.  The thread protect need more wide. Because DestroyBuffer and RemoveWrapper are different functions. CreateBuffer and CreateWrappedHandle could happen between DestoryBuffer and RemoveWrapper.

Process

GetDeviceTable(device)->DestroyBuffer(device, buffer, pAllocator)
CreateBuffer -> Another thread. Create a duplicated handle value.
CreateWrappedHandle -> The new wrapper can't be added to the map because the old one hadn't removed from the map. It prints a warning, like Create a duplicated Handle:<PHONE_NUMBER>664. This wrapper can't be written into VulkanStateHandleTable.
DestroyWrappedHandle(buffer)

Now, the map doesn't have the new wrapper. It could get a warning, like GetWrappedId() couldn't find Handle:<PHONE_NUMBER>664's wrapper. It might have been destroyed in the following process.

The thread protect should cover between DestroyBuffer and RemoveWrapper, not only RemoveEntry.
CreateBuffer also need protect to ensurn BufferWrapper is alive.
Here is a sample code:
Using vkcube to run CreateBuffer and DestroyBuffer 10k times on different threads.
https://github.com/locke-lunarg/Vulkan-Tools/tree/thread
Thread protect for CreateBuffer and DestroyBuffer. We won't see the warning and crashes. If you remove two std::unique_lock<std::mutex> lock(buffer_wrapper_lock_), you will see the warning or crashes. You might also see   InsertEntry Buffer:<PHONE_NUMBER>408, time:<PHONE_NUMBER>657 is before RemoveEntry Buffer:<PHONE_NUMBER>408, time:<PHONE_NUMBER>657.
https://github.com/locke-lunarg/gfxreconstruct/tree/test-thread

We could use GFXRECON_FORCE_COMMAND_SERIALIZATION to fix it before we fix this issue.


using resource package from fabric8-common

This commit utilizes the resource package which outside of the wit
repo into it's own libs repo. The repo is under
https://github.com/surajssd/osiolibs my account, but we can move
to this repo under this org.
Also this could be the start of moving all the library like code
into a separate repo. This would also help in it's utilization
in other repos like tenant.

Codecov Report

Merging #2096 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2096   +/-   ##
=======================================
  Coverage   67.45%   67.45%
=======================================
  Files         158      158
  Lines       14668    14668
=======================================
  Hits         9894     9894
  Misses       3820     3820
  Partials      954      954

Continue to review full report at Codecov.

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

I agree with @kwk. Stripping down some existing repo (fabric8-wit or auth) will be better then copying the source code without the git history.  This is why we stripped fabric8-wit to fabric8-auth in the first place. To keep the git history.

@kwk @alexeykazakov ok, that makes sense. Let me rebuild fabric8-common while preserving the git history from the various source repositories, then.

@kwk  @xcoulon this PR is updated PTAL!

@xcoulon is the common repo in a good shape to be used and partially replace the pieces in WIT?

@xcoulon is the common repo in a good shape to be used and partially replace the pieces in WIT?

@kwk yes, we should start using it, IMO.

@kwk yes, we should start using it, IMO.

@xcoulon we're in the middle of rewriting our errors package. I guess we should do it after we've started using this repo, right?


[WMGv2] Share Link Tissue Id vs. Tissue Name? Breaking change or bug?

Context:

V2 share link uses tissue name in params, however, currently WMGv2 expects tissue in share link param to be IDs

E.g.,
Doesn't work: https://localhost:3000/gene-expression?compare=disease&sexes=PATO%3A0000383&tissues=blood%2Clung&genes=DPM1%2CTNMD%2CTSPAN6&ver=2
Does work:
https://localhost:3000/gene-expression?compare=disease&sexes=PATO%3A0000383&tissues=UBERON%3A0000178%2CUBERON%3A0002048&genes=DPM1%2CTNMD%2CTSPAN6&ver=2
Figure out:

Is share link tissue param now expects ID or still name
If it now expects ID, we need to bump the share link version to v3 and keep v2 link backward compatible

CC: @signechambers1 @dsadgat this one needs Signe's input
Thank you!

@tihuan im confused, the share link functionality works properly for me on prod right now. are you saying old share links will not work? (ie share
links that were generated pre-v2)?

Sorry for the confusion!
Currently we have two types of v2 link:

Old v2 link has tissue names in the share link
New v2 link has tissue ids in the share link

Right now old v2 links don't work, since the latest WMG expects tissue ids instead
If this share link breaking change is expected (tissue names to tissue ids), we should bump the new v2 link to v3, and in the code support v2 links, so the old v2 links continue to work
However, if this change was unintentional, we'll just fix this bug lol

Thanks @tihuan! I'm not sure if this was intentional but is it possible this change was made due to the new tissue filter? checking with @seve although he is OOO.
Either way I'd like the v2 links to work and the code to support the new tissue filter, so whatever you think the best way of doing that would be is fine with me from the product perspective.
cc @niknak33 since I am OOO next week. Thank you!!

Got it 👌 Thanks, Signe!
In that case, I think we can just modify the code to support tissue share link to expect either id or name and keep the version as v2. This way we'll continue to support both types of v2 share links!
I'll update the description on Monday!
One last thing is assigning priority, so I'll wait for @niknak33 to let us know on Monday
Enjoy your time off, Signe!!

Assigned as P1 @tihuan @signechambers1

Awesome thanks, @niknak33 !

CC @dsadgat for a sprint later 🙏 Thank you!


FPS/Widescreen issues after 1.05 patch.

Just updated Elden Ring with latest patch, and I seem to have lost the widescreen support and my framerate is back to being locked @ 30.
Just seeing if anyone has seen anything like this after patch?

Sorry, I realized my Nvidia driver was causing the issue.


OfficeOnlineServerInstall: Resource does not handle exit code 3010 (ERROR_SUCCESS_REBOOT_REQUIRED) properly

Details of the scenario you tried and the problem that is occurring
The setup can exit with exit code 3010 (ERROR_SUCCESS_REBOOT_REQUIRED). The SPInstall resource does not handle this exit code properly: It throws an error instead of initiating a reboot.
Verbose logs showing the problem
Suggested solution to the issue
Add exit code 3010 to the list of exit codes and initiate the reboot.
The DSC configuration that is used to reproduce the issue (as detailed as possible)
N/A
The operating system the target node is running
Windows Server 2016
Version and build of PowerShell the target node is running
v5.1
Version of the DSC module that was used ('dev' if using current dev branch)
dev

Will submit a PR shortly


Handle Panic when Assignee is nil in Backport util

When the assignee is nil in the given issue to be backported, backport throws a panic as the pointer is referenced but is nil.

Completel.


doc: fix docstring for bidnings where rhs can be false

The right hand side of bindings can be false to disable core bindings. This resolves that in the type definitions

Thanks for the fix!


Problem in testing my own video

Hi @akanazawa  First of all thanks for your this kind work. It's really helpful. I'm facing following problem...

This work is working fine with your provided videos using pre-trained weights. But when I run it on random video (single person), all the process runs successfully till PoseFlow successfully ran! but it stuck on Processing frames.
I checked the demo_output folder --> video_folder and I found that there are only two folders inside it, one is AlphaPose_output and other one is video_frames. so no other folders like hmmr_output and hmmr_output_crop.
In AlphaPose_output folder there are images frames of video along with json files.
When I run it with your videos images frames are not stored within AlphaPose_output folder and all files are in separate folders as specified in project code. I'm unable to understand that what is problem with any wild video.  Code it ok this problem is just with new video.
5: Moreover I checked json files generated by your videos and my video... Json files seem to be ok.

Hi,
I suspect the issue might result from a lack of person detections in the first frame. The easiest way to debug this though is by uploading the video you are trying to test on.
Best,
Jason

@jasonyzhang  Hi thanks for your reply. Person detection in video is fine. Alphapose is working fine. I checked my video with AlphasPose and it seems to be ok. Did you check any wild video with this project? If yes then results are ok?  If possible then can you provide me any video I just want to compare frames.

Yes, we've tested on in-the-wild videos. Most of the demo videos are scraped from Instagram. Could you upload the video that you are having trouble with?

@jasonyzhang Hi Jason, I tested with TikTok and YouTube videos. I've sent you an email with tested videos and related problem. Kindly check your email and suggest some solutions. It will be more good if you will test my videos by yourself in your project.


[BUG] Performance issue with setNull(Types.DECIMAL) on a decimal column

Driver version
7.2.2.jre8, 7.2.2.jre11, 7.3.1-preview.jre11
SQL Server version
SQL Server 2014 Standard Edition 12.00.5571.0.v1 on Amazon RDS (db.m5.xlarge)
SQL Server 2014 Enterprise Edition 12.00.5571.0.v1 on Amazon RDS (db.m5.4xlarge)
Client Operating System
Amazon Linux 2 AMI 2.0.20190313 x86_64 HVM gp2 (t3.medium)
JAVA/JVM version
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode)

Table schema
See reproducer
Problem description
Usage of java.sql.PreparedStatement.setNull(int parameterIndex, int sqlType) with java.sql.Types.DECIMAL instead of java.sql.Types.DOUBLE to set a null value on a column of SQL type decimal leads to poor JDBC batch insert performance and constant drop of throughput over time.
We observed that performing massive inserts always setting the decimal column to null, the performance was nominal.
The performance impact would only kick in if column was sometime populated with null, sometime with a double using java.sql.PreparedStatement.setDouble(int parameterIndex, double x).
Some figures, collected in the environment described above, measured from the Java side (see reproducer) attempting to insert 3 millions rows in batches of 250 rows:

Usage of setNull(Types.DOUBLE) alone
Stable at 83k / seconds
Usage of setNull(Types.DOUBLE) mixed with calls to setDouble()
Stable at 83k / seconds
Usage of setNull(Types.DECIMAL) alone
Stable at 83k / seconds
Usage of setNull(Types.DECIMAL) mixed with calls to setDouble()
unstable (variations from one batch to the next) with at most 17k/s at the beginning of the run, rapidly dropping towards 10k/s and below

JDBC trace logs
Changing log level is not an option because they would affect performance
Reproduction code
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.Statement;
import java.sql.Types;
import java.time.Duration;
import java.time.Instant;
import java.util.Random;
import java.util.function.Consumer;

public class Main {
  public static void main(String[] args) {
    // example program arguments : jdbc:sqlserver://host:1433;databaseName=foo;user=bar;password=donut 10000 500
    for (String arg : args) {
      System.out.println(arg);
    }

    String jdbc_url = args[0];
    Long targetSize = Long.valueOf(args[1]);
    Long batchSize = Long.valueOf(args[2]);

    getDbConnection(jdbc_url, connection -> {
      try {
        execute(connection, targetSize, batchSize);
      } catch (SQLException e) {
        e.printStackTrace();
      }
    });
  }

  private static void getDbConnection(String jdbc_url, Consumer<Connection> connectionConsumer) {
    try {
      Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
    } catch (ClassNotFoundException e) {
      e.printStackTrace();
    }
    try (Connection conn = DriverManager.getConnection(jdbc_url)) {
      if (conn != null) {
        conn.setAutoCommit(false);
        DatabaseMetaData metaObj = conn.getMetaData();
        System.out.println("Driver Name?= " + metaObj.getDriverName() + ", Driver Version?= " + metaObj.getDriverVersion() + ", Product Name?= " + metaObj.getDatabaseProductName()
            + ", Product Version?= " + metaObj.getDatabaseProductVersion());
      }
      connectionConsumer.accept(conn);
    } catch (Exception sqlException) {
      sqlException.printStackTrace();
    }
  }

  private static void execute(Connection conn, Long targetSize, Long batchSize) throws SQLException {
    try (Statement stmt = conn.createStatement()) {
      stmt.execute("IF OBJECT_ID('test', 'U') IS NOT NULL drop TABLE test;");
    }

    String create = "CREATE TABLE test (value decimal(38,20) NULL)";
    try (Statement stmt = conn.createStatement()) {
      stmt.execute(create);
    }

    Random rand = new Random();

    String insert = "INSERT INTO test (value) VALUES(?)";
    try (PreparedStatement preparedStatement = conn.prepareStatement(insert)) {

      Instant start = Instant.now();
      Instant batchStart = Instant.now();
      for (int i = 1; i <= targetSize; i++) {
        // *** uncomment a single line of the 4 methods call below to each of the 4 cases
//        onlySetNullDecimal(preparedStatement);
        mixWithSetNullDecimal(preparedStatement, rand);
//        onlySetNullDouble(preparedStatement);
//        mixWithSetNullDouble(preparedStatement, rand);

        preparedStatement.addBatch();

        if (i % batchSize == 0) {
          preparedStatement.executeBatch();
          conn.commit();
          long duration = Duration.between(batchStart, Instant.now()).toMillis();
          System.out.println("rate " + (int) (batchSize / (duration / 1000d)) + " insert/s. progress " + i + "/" + targetSize);
          batchStart = Instant.now();
        }

      }
      long duration = Duration.between(start, Instant.now()).toMillis();
      System.out.println("total duration " + duration + "ms");
      System.out.println("final rate " + (int) (targetSize / (duration / 1000d)) + " insert/s");
    }
  }

  private static void onlySetNullDecimal(PreparedStatement preparedStatement) throws SQLException {
    preparedStatement.setNull(1, Types.DECIMAL);
  }

  private static void mixWithSetNullDecimal(PreparedStatement preparedStatement, Random random) throws SQLException {
    if (random.nextBoolean()) {
      preparedStatement.setNull(1, Types.DECIMAL);
    } else {
      preparedStatement.setDouble(1, (double) Math.abs(random.nextInt()));
    }
  }

  private static void onlySetNullDouble(PreparedStatement preparedStatement) throws SQLException {
    preparedStatement.setNull(1, Types.DOUBLE);
  }

  private static void mixWithSetNullDouble(PreparedStatement preparedStatement, Random random) throws SQLException {
    if (random.nextBoolean()) {
      preparedStatement.setNull(1, Types.DOUBLE);
    } else {
      preparedStatement.setDouble(1, (double) Math.abs(random.nextInt()));
    }
  }

}

Hi @sns-seb, thanks for letting us know. The team will look into this. What SQL Server version was used here? 12.0.x can refer to SQL Azure or 2014.

Hi @rene-ye, it was SQL Server 2014. I'll update the description

Hi @sns-seb, the performance "degradation" in this issue has to do with how the driver prepares stored procedures. The image below is an example of the driver calls to the server when calling executeBatch() repeatedly with the same datatypes:

As you can see, the driver calls sp_prepexec on the second batch, and proceeds to execute the rest of the batch with sp_execute. This is a performance improvement largely discussed in #166. When datatypes are switched (as in the case above where the test is interchaning between Decimal and Double), the driver will constantly re-prepare statements:

We can enable statement pooling to resolve this issue. Adding disableStatementPooling=false;statementPoolingCacheSize=5; to the connection string greatly improves the performance and brings the test case's run time down to the expected run times of the other cases (notice the sp_execute 2...):

If you have any more questions regarding this behavior please feel free to ask.

thanks for the detailed and clear explanation @rene-ye
I guess this issue can be closed, then?
I'm wondering whether a warning (or even an error) would make sense in this case, though.
I can't imagine a case where changing the datatype constantly for a given parameter of a given PreparedStatement would be valid and made on purpose.

I'd assume there would be cases where frameworks are changing underlying datatypes. Regardless, I see your point, we'll think about adding a warning.


zigbee2mqtt: 1.16.2 -> 1.20.0

Motivation for this change
4.8M derivation size :man_shrugging:
https://github.com/NixOS/nixpkgs/pull/108130#issuecomment-753606579
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Yeah, I was just dabbling with the size of the derivation. I'm still hesitant to merge this for well-known reasons.

@mweinelt So the derivation size is holding this back?

Superseded by #147985.

@mweinelt
Did the backported patch (https://github.com/NixOS/nixpkgs/pull/142319) not solve the derivation size issue?
Or was there another reason for closing this pr?

See https://github.com/NixOS/nixpkgs/pull/147792.


Remove atomified <-state, optimizations

This MR removes the Atomified wrapper returned by <-state. It implements a couple of new features:

<-state returns a tuple [state set-state]
set-state will prevent re-renders triggered by structurally equivalent state objects
set-state can be used with multiple arguments like swap!: (set-state assoc :new-key "new-value")
Adds a new <-value hook that can be used to optimize <-effect, <-memo, etc.

Will take a longer look soon, but after a quick glance, one thing that bothers (if I can say so) is the = check. Are you assuming that the value is a js object or a CLJ data structure? I'm saying this because I've been bitten by a similar thing in Citrus, where we had a long vector of nested maps coming from the backend and only the last item was different, so this = was taking a lot of time and blocking the UI. Should it be better to leave the check out by default and let React do its check (I know the rules documented somewhere), and offer an option to actually do the check?
I haven't looked at the other changes yet in the PR.

Perhaps you're right. We have an issue over at https://github.com/facebook/react/issues/15154 where we're trying to figure out if there's some extra optimizations we can do w.r.t. state updates.
I think that in practice, the chance that a state operation returns a structurally equivalent but referentially different value is rare. So might be good to keep the hot path clear of that.

I've always thought that the user should be able to supply their own comparison function, because they're best positioned to know what kind of data structures they use on a case-by-case basis.
So I think an API could look like so:
[foo set-foo] (<-state 0) ;; fall back to whatever React is doing with Object.is
[foo set-foo] (<-state :foo keyword-identical?) ;; only going to use keywords
[foo set-foo] (<-state {:some "thing"} =) ;; small maps with big ramifications
[foo set-foo] (<-state {:some "thing"} identical?) ;; big maps, prefer to re-render

(the last case could be omitted as identical? is just ===).

I would go further and provide nothing. The user can just do the custom comparison him/herself before calling set-foo (this is what we ended up doing in our case). The good thing with this solution is that this code doesn't even have to be in hx at all, easy to do outside.

I think that you will want to be able to do it in the state computation, so that you can accommodate state changes occurring between when you call set-foo and when the computation you dispatched actually occurs. This doesn't happen now, but will in Concurrent mode.
Another option for users is to use <-reducer instead, like the React team has suggested for most non-toy situations.


Feature Request: Dock Always Visible in Desktop Mode

Hello! I am absolutely loving what you guys have done with ChimeraOS lately! As the title suggests, It would make it much easier for folks like me coming from other distros if there were at least an option to enable "Dock Always Visible". Otherwise maybe i can get used to it since it is so polished feeling now... Thanks again!

You probably can do this with a gnome extension. Just download Extension Manager from the software store.

We are not including extensions in the base image becasue they tend to break easily and is a burden on us to test them all. The best solution would be to install Extension Manager from flatpak (available in the GNOME Software Center) and install Dash-to-dock extension. That will allow for any configuration of the dock you want.
Closing.


Fix a small typo in the README

Just a minor typo I noticed; thanks!

@5outh Thanks for contributing

Fastest PR merge I've ever seen! Thanks @maxiloc

:+1: #millisecondsmatter


Calculating uv coordinates from 3d vertices

Required Info

Camera Model
L515

Operating System & Version
Win (10) / Linux (CentOS)

Platform
PC

SDK Version
2.0

Language
C++

Issue Description
I was wondering if someone could help me in calculating the uv coordinates of 3d vertex points. I know its possible to get the uvs from the camera but I'm applying my own decimation and smoothing to the points and need to recalculate the uv coordinates.
Thanks in advance.

Hi @factify
We would point you to our camera capabilities with regards to UV mapping feature.  Were you able to find other suggestions?
*If we don’t hear from you in 7 days, this issue will be closed.

Hi @factify
We would point you to our camera capabilities with regards to UV mapping feature.  Were you able to find other suggestions?
*If we don’t hear from you in 7 days, this issue will be closed.


Be able to pass in kubectl params to helm install

So for some reason the daemonset I have been working on requires me to pass in -validate=false for it to work.
That got me thinking that we might want to accept kubectl params into helm install. Or at the very least determine if there are certain params we should include into helm install.

I was running into this yesterday with a nodePort validation.  It is a bug in Kubernetes that missing values in manifest are not initializing.
As for passing params during helm install, we should determine if there are chart-specific options.  A field could be added to the chartfile for passing opts to kubectl

I like @adamreese's idea here. That would remove the need for the user to know exactly what they need to add.

I would like to add this to 0.3 milestone, but I'm not sure I have a clear enough idea of how we'd build this.


Fixed typo: "" is missing for parameter method in get_thumbnail method

Obviously, "thumbnail" should be passed to get_thumbnail instead of a thumbnail variable
Pull Request Checklist

[ ] Privileged views and APIs are guarded by proper permission checks.
[ ] All visible strings are translated with proper context.
[ ] All data-formatting is locale-aware (dates, numbers, and so on).
[ ] Database queries are optimized and the number of queries is constant.
[ ] The changes are tested.
[ ] The code is documented (docstrings, project documentation).
[ ] GraphQL schema and type definitions are up to date.

Thanks for contributing!


typeScript error

VSCode Version: Code 1.9.1 (f9d0c687ff2ea7aabd85fb9a43129117c0ecf519, 2017-02-09T00:26:45.394Z)
OS Version: Windows_NT ia32 10.0.14393
Extensions:

Extension
Author
Version

Steps to Reproduce:

Please provide information about the issue you are seeing


Azure storage explorer unable to connect to Subscription

Preflight Checklist

[X] I have installed the latest version of Storage Explorer.
[X] I have checked existing resources, including the troubleshooting guide and the release notes.
[X] I have searched for similar issues.

Storage Explorer Version
1.27.0
Regression From
No response
Architecture
i86
Storage Explorer Build Number
20221201.1
Platform
All
OS Version
No response
Bug Description
{
"message": ""{\n  \"message\": \"\\\"AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '797f4846-ba00-4fd7-ba43-dac1f8f63013'.\\\\r\\\\nTrace ID: 934d3927-730f-4394-bfd4-e57f9eeb6a00\\\\r\\\\nCorrelation ID: c4a94a1b-fb9a-46aa-bf45-a8ff08356657\\\\r\\\\nTimestamp: 2022-12-15 18:38:41Z\\\"\"\n}""
}
Steps to Reproduce
Nothing is visible in blob or file share . Not connected to cloud
Actual Experience
Unable to coonect to storage account from laptop
Expected Experience
Smoth sync with cloud storage
Additional Context
Conect to azure cloud is needed from local storage explorer

Problem solved by selecting open Storage Explorer in Azure Portal


traefik-mesh proxy error

level=error msg="Provider connection error cannot decode configuration data: weighted cannot be a standalone element (type *dynamic.WeightedRoundRobin), retrying in 526.171314ms" providerName=http

Hello @kanouken and thanks for your interest in Traefik Mesh,
Can you update your issue to follow the bug report template?
In order to help us identify the problem, can you give us more context (what you are trying to achieve, the version used) and if possible a reproducible test case?


errors: cover required metadata error cases

Coverage decreased (-0.8%) to 79.021% when pulling ab57e6a0177177c6dd967d9798cf7ecce4985c13 on fenekku:127_errors into 41b17e8eb92dce1ffbfb5faae5a9159e7176c216 on inveniosoftware:master.


add password config for routerLogin account

Codecov Report

Merging #63 (847aef5) into dev (6b41a2a) will increase coverage by 0.09%.
The diff coverage is 42.85%.

@@             Coverage Diff              @@
##                dev      #63      +/-   ##
============================================
+ Coverage     26.75%   26.84%   +0.09%
- Complexity      136      137       +1
============================================
  Files            54       54
  Lines          1955     1963       +8
  Branches        135      135
============================================
+ Hits            523      527       +4
- Misses         1392     1396       +4
  Partials         40       40

Impacted Files
Coverage Δ

...ank/wecross/account/service/ServiceController.java
0.60% <0.00%> (ø)

...ross/account/service/config/ApplicationConfig.java
49.23% <50.00%> (+0.03%)
:arrow_up:

Continue to review full report at Codecov.

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


Layers Issue while transfer learning for image classification

ValueError: You are trying to load a weight file containing 242 layers into a model with 241 layers.
This shows up when I try to do transfer learning for image classification. I tried Inceptionet and densenet and both show the same error

I have the same issue. It also shows up with resnet. Is there another posibility to do transfer learning at the moment?

Same issue, just different layers. Tried with Resnet and Mobilenet

Any update, the transfer model layer issues for those 4 models.


(fix) Add gateway URI to deploy.yaml template on interface

I've found that when creating a new interface from the template there was a missing config that didn't allow me to deploy.
I've added the new config parameter and the required step on the README.

LGTM! Nice catch!
Are we pushing this into 0.10-dev too? smile

Sure! I can create another PR for the 0.10, but i guess it depends on the gitflow you using. Normally once the 0.9-dev gets deployed, the 0.9 could be merged into the 0.10-dev to bring all the fixes that have been deployed there.


process_executor.py example on Windows 7 orphans the multiprocess kernels

Hi,
Running the process_executor.py example in windows, does indeed create the parallel process, as evidenced by TaskManager, but the processes do not close on their own.
[Tested using PyCharm, on a Windows7 install, 64-bit OS)
Have I misconfigured, or am I missing something, or is this a limitation?
I can indeed see running the example creates the processes...

I would have thought each of the processes would have been closed/terminated after they completed.
*edit
Thinking/just realized: the onus is on me to set unsync.process_executor = None, isn't it?
(The benefit then, is that the processingPool is setup and ready to go again, if it needs to be used, right?)
p.s. Thank you for sharing your excellent work.

Yeah you're right on all accounts. The processes stay alive because there is relatively high overhead to start them. On my machine it takes 170ms to start the process pool and 30ms to close it.
My advice in general is to just leave the processes running, I don't think there's really a downside to them being idle. That said, the trick you described of setting unsync.process_executor = None seems to work if you prefer to stop them and don't mind the start/stop overhead.


Support log4j 2

What steps will reproduce the problem?
1.Attempt to open any Log4j 2 XML file in regular or tail mode.

What is the expected output? What do you see instead?
Otros doesn't recognize the file as a log file and can't load it.

What version of the product are you using? On what operating system?
2013-05-15-SNAPSHOT, OS N/A

Please provide any additional information below.
This issue should have type of Enhancement, but submitters can't set type.
Log4j 2 will soon be the main active version of Log4j. See
http://logging.apache.org/log4j/2.x/ .

Tip:
You can easily make Otros support Lo4j 2 XML files by just modifying the Log4j
1 XML parser to allow the existing element base words to begin with capital
letters.  E.g. check for "<log4j:LocationInfo..." in addition to
"<log4j:locationInfo...".

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 23 Nov 2013 at 11:17

Any hope to see this implemented on the near future?

OtrosLogViewer 1.4.8 will be supporting Log4j2 JSON format. Is this helping you?

I've since embraced logback; however this new feature might have me reconsider. Thanks ;)


creating unwanted quote

somehow it creates quote around  'on'. But it works fine for another path like "$.resources[(@.length)]"
This one works totally fine.

 changes: |
            {
              ".github/workflows/worker-production-build.yml":{
                "$.on.workflow_dispatch.inputs.project.options[(@.length)]": "${{ env.PROJ_PATH }}"
              }
            }

I figured out. I need noCompatMode: true
https://github.com/nodeca/js-yaml/blob/0d3ca7a27b03a6c974790a30a89e456007d62976/test/issues/0266.js#L16
Should we just set it as true? or create an option for it?

It's fine for me to just enable it. Do you want to open a PR?

@maxisam I had to add an input for it because of first issues in existing workflows. You can just enabled it with noCompatMode set to true


Implemented dragging feature, added comments

Implemented dragging feature, so that the user, when adding calendar manually, does not have to individually click all the time slots. Dragging over already-allocated time slots will remove the time slot.
Also added comments to improve the readability of the codes

LGTM! Very nice usability feature


is tsconfig include supported?

my project relies on include to bring in some typings from a shared folder:
"include": [
    "../typings/tsd.d.ts",
    "../../../test/typings/tsd.d.ts",
    "**/*"
],

this works just fine in tsc or in webpack but blows up in Atom, saying that all the typings in both tsd.d.ts files cannot be found. it would seem that atom-typescript is simply ignoring the include option so those two extra files are never included in the build. yet every other typescript environment respects this flag, and it's part of the 2.0 standard.

oddly enough, renaming include to filesGlob in the above example causes Atom to work again (but of course totally dies in webpack, so not sustainable).

I've had a quick look at this, as I need include too.
The filesGlob support is currently all in https://github.com/TypeStrong/tsconfig, a dependency. Unfortunately though, this project depends on v2.2.0 of tsconfig, which is now at version v5.0.3. It no longer has the API this package calls (parseFileSync ), and all the filesGlob & exclude handling logic this plugin depends on has been removed, which makes this tricky.
I would really use this too and it clearly needs adding, since everybody else already supports it and afaict it's the standard way of specifying your build files now. It's a reasonable sized chunk of work to get this working with the new tsconfig and to work out how to add include to that too though, sadly.
@blakeembrey - is there a plan for how these two packages are going to be reunited? Should tsconfig include/exclude parsing be readded to this package, or readded to tsconfig, or put somewhere else?

I would prefer that support for filesGlob goes away and you rely directly on the TypeScript compiler to do this instead. That's the reason I killed support for it in tsconfig too (the only support remaining is searching for files and resolving, because TypeScript is buggy with this still). This is the function you should use for this: https://github.com/TypeStrong/ts-node/blob/master/src/index.ts#L445.


std.numeric: Always use Stein's algorithm for integral gcd()

Whatever tests/observations were done in #4940 no longer apply when I run benchmarks locally:
ubyte_euclid: 10 secs, 741 ms, 853 μs, and 9 hnsecs
ubyte_stein: 6 secs, 98 ms, 939 μs, and 7 hnsecs
ushort_euclid: 13 secs, 442 ms, 495 μs, and 6 hnsecs
ushort_stein: 9 secs, 266 ms, 581 μs, and 2 hnsecs
uint_euclid: 13 secs, 285 ms, 480 μs, and 4 hnsecs
uint_stein: 9 secs, 173 ms, 414 μs, and 8 hnsecs
ulong_euclid: 20 secs, 227 ms, 886 μs, and 2 hnsecs
ulong_stein: 9 secs, 181 ms, 300 μs, and 8 hnsecs

@thewilsonator - Reverted the document change, as Euclid's algorithm is still used in the BigInt overload (tested with CrippledInt).


matches = truths[best_truth_idx]

Damn. Is there any one who can clearly explain below two lines???
link
matches = truths[best_truth_idx]          # Shape: [num_priors,4]
conf = labels[best_truth_idx] + 1         # Shape: [num_priors]

@DonghunP The +1 is probably because the class indices are zero-indexed, while at the same time, the output of the neural network has the background at index zero.

@DonghunP
First line is to find out what ground truth of each prior box belong to
For example, if you have two objects (2 ground truth), and 3 prior boxes, your best_truth_ids = [0, 1, 1].
It means that first prior box best matching with first ground truth, second prior box best match with second ground truth, and so third prior box.
For second line, it return what classes of each prior box represents, +1 is due to we have one additional background label.