ESP32-S3 I2C instability v ESP32 when using i2c_master_xxx() API (IDFGH-10122)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.0.1 (also occurs on master as at https://github.com/espressif/esp-idf/commit/54576b7528b182256c027de86eb605a172bc2821)
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
CMD
Development Kit.
ESP32-S3-DevKitC-1 v1.0
Power Supply used.
USB
What is the expected behavior?
Code written for ESP-IDF I2C i2c_master_xxx() API and runs without error on ESP32 should also run without error when compiled for ESP32-S3.
What is the actual behavior?
[A few of your customers are seeing this problem, discussed here: https://www.esp32.com/viewtopic.php?f=2&t=33583 but we need attention from an Espressif person, hence moving it here.]
We have a GNSS device connected over I2C to an ESP32 (I2C HW block 0, 100 kHz clock, no clock stretching, SDA pin 18, SCL pin 19).  Our automated test system checks that our code works perfectly all the time; the tests run for about 6 minutes.  This works flawlessly.
However, when we build for and run on ESP32-S3 in exactly the same situation, we see instability: i2c_master_cmd_begin() sometimes returns error 263 (timeout) or occasionally -1 (no ack from device); it never passes the set of test.
To illustrate the problem, see below a Saleae Logic trace of an entire test run where the red line indicates that i2c_master_cmd_begin() is running, the orange and yellow blips indicate that a timeout error has been returned by i2c_master_cmd_begin() (orange for when the ESP32-S3 is doing a "send" to the device, yellow when the ESP32-S3 is doing a "receive" from the device) and the green blips indicate that "no ack from device" has been returned by i2c_master_cmd_begin():

Zooming in on the first of these errors (.sal file also attached below):

...you can see that a write has been set up to address 0x42 and the device has acked it (at least as far as the Saleae probe can tell) but then there is no clocking for the rest of the write, which I guess results in the timeout.  All of the timeout errors on send, the yellow blips, look like this.
Zooming in on the second of these errors (.sal file also attached below):

...again, the Saleae probe believes that a read has been set up to address 0x42 and the first byte (which is all zeroes) has been received and acked but then the clock stops again and i2c_master_cmd_begin() returns timeout.  Curiously, 16 ms later, and not while i2c_master_cmd_begin() is running, the clock returns high, which the slave probably sees as a signal to get on with things and pulls the data bus low, but then the clock stays high (I guess this is some sort of error recovery thing, rather than a clock edge).  In some cases this confuses the devil out of the bus and results in a nack the next time.  All of the timeout errors on receive, the orange blips, look like this.
The failures occur randomly, there is no discernable pattern to them.
For reference, here is a zoom into the same Saleae trace of a success case for send:

...and a success case for receive:

What could be causing this behaviour?  Do we need to setup something differently to use the i2c_master_xxx() API on ESP32-S3?  We've tried setting i2c_set_timeout() to the max value of 0x1f (see post here asking why the register has shrunk in size so much for ESP32-S3 versus ESP32) but, as expected, adding such a very short delay makes no difference to the outcome.
Steps to reproduce.
The entire code can be found here: https://github.com/u-blox/ubxlib/tree/debug_esp32s3_i2c, where this is the function that opens the I2C bus, this is the function that does a send, and this is the function that does a receive.
Also find attached segments of the Saleae probe trace for the send and receive cases (including the analogue waveform, which I didn't bother including above).
esp32s3_i2c_error_send.zip
esp32s3_i2c_error_receive.zip
Debug Logs.
See Saleae logic probe snapshots and actual .sal trace segments above.  The entire Saleae logic trace is also available but is too big to attach here (261 Mbytes): let me know if you want it.
More Information.
Just out of interest, I added some code to read the configuration values (the ones we don't change, assuming the defaults are good, plus the timeout value which we set on ESP32 but don't bother setting on ESP32-S3 because its range is too small to make any difference).  Not sure if any of these matter - should we be changing them on ESP32-S3 for I2C to operate correctly?
ESP32:
clock period: high 387, low 399.
start setup time: 400, hold time 400.
stop setup time: 400, hold time 400.
data sample time: 200, hold time 200.
timeout: 800000 (we set this value, 10 ms).

ESP32-S3
clock period: high 200, low 200.
start setup time 199, hold time 200.
stop setup time 199, hold time 199.
data sample time 197, hold time 49 (tried changing this to 197, since that is closer to the ESP32 case, but it didn't help).
timeout 12 (== 150 ns, max on S3 is 31 == 386 ns).

Hello @RobMeades ,
To me the issue you are encoutnering sounds very similar to this one: https://github.com/espressif/esp-idf/issues/9777
In fact, we found a bug in the I2C HAL layer that also affected the S3, a fix was pushed on master branch and it is being backported to other branches: https://github.com/espressif/esp-idf/commit/a0f8434f9382016db6f3b102051569b5cbaea2c0
In the meanwhile, you can cherry-pick it and see if it solves your issue:
git cherry-picka0f8434f9382016db6f3b102051569b5cbaea2c0

Hi, and thanks for the swift response.  I had discounted that particular issue since there was no error on the I2C bus preceding these errors.  However, I can try just doing the same thing on headrev of your master branch and see what happens, will report here on the outcome.

Unfortunately, moving to the current master (54576b7528b182256c027de86eb605a172bc2821) does not solve the problem, it still looks the same.

In case it helps, find below a high resolution trace (with your master branch), including analogue @ 50 M samples/second, taken at the pins of the ESP32-S3 Devkit, of the parts where the errors occur.
Here is the "sending to device" case, i.e. zooming into here:

...and here is the "receiving from device" case, i.e. zooming into here:

Corresponding Saleae logic traces also attached: esp32s3_i2c_error_send_detail.zip and
esp32s3_i2c_error_receive_detail.zip.

@RobMeades Thank you for all the details and screenshots. I tried on my side with your send function, the same SDA/SCL pin, same frequency and with internal pull-ups (no external pull-ups) and a GPIO expander device, commit https://github.com/espressif/esp-idf/commit/54576b7528b182256c027de86eb605a172bc2821 but I couldn't reproduce the issue unfortunately.
In my case, the transfers are all successful, even if I execute them with tight interval:

I suspect it's a timing configuration issue because, as you said, electrically speaking it is good, the signals seem clean to me.
Where did you print/get the timing values you showed in your previous message? These ones:
ESP32-S3
clock period: high 200, low 200.
start setup time 199, hold time 200.
stop setup time 199, hold time 199.
data sample time 197, hold time 49 (tried changing this to 197, since that is closer to the ESP32 case, but it didn't help).
timeout 12 (== 150 ns, max on S3 is 31 == 386 ns).

The data sample time seems too big, may be due to the fact that you retrieved them with the older invalid commit. For comparison, and make sure we are using the same values, here are the detailed timings I am using:
scl_low: 200
scl_wait_high: 98
scl_high: 102
sda_hold: 50
sda_sample: 100
setup: 200
hold: 200
tout: 12

To get them, here is the diff to apply:
esp32s3_i2c_timings.diff.txt
Check the timings you get and make sure we have the same configuration.
If they are the same and you still get the same problem, try to isolate the issue with a small ESP-IDF example that uses the I2C API wrappers we provide, something like:
#include <stdio.h>
#include <inttypes.h>
#include "sdkconfig.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/i2c.h"

#define I2C_MASTER_PORT 0
#define DEVICE_ADDRESS 0x42 // un-shifted address!

static esp_err_t i2c_master_init(void)
{
    i2c_config_t conf = {
        .mode = I2C_MODE_MASTER,
        .sda_io_num = 18,
        .scl_io_num = 19,
        .sda_pullup_en = GPIO_PULLUP_ENABLE,
        .scl_pullup_en = GPIO_PULLUP_ENABLE,
        .master.clk_speed = 100000,
    };

    i2c_param_config(I2C_MASTER_PORT, &conf);

    return i2c_driver_install(I2C_MASTER_PORT, conf.mode, 0, 0, 0);
}

void app_main(void)
{
    uint8_t data[1] = { 0 };
    uint8_t datar[1] = { 0 };
    esp_err_t ret = ESP_OK;

    ret = i2c_master_init();
    if (ret != ESP_OK) {
        printf("Error initializing the I2C\n");
        return;
    }

    while (1) {
        ret = i2c_master_write_read_device(I2C_MASTER_PORT, DEVICE_ADDRESS, data, 1, datar, 1, 1000 / portTICK_PERIOD_MS);
        if (ret != ESP_OK) {
            printf("Error %d sending data\n", ret);
            return;
        }
        printf("Received: %x\n", *datar);

        vTaskDelay(250 / portTICK_PERIOD_MS);
    }

}

As a side note, your send and receive functions can be replaced by i2c_master_write_to_device and i2c_master_read_from_device respectively. In fact, they will even be faster because they don't perform any dynamic memory allocation.

Yes, the timing values I posted in the "More Information" section above were retrieved on the 5.0.1 release, done by issuing i2c_get_start_timing() etc.  I will try again using your exact values.
As you can see from the first trace above, the error occurs about ~20 times in what must be several thousand transactions of various types over a 6 minute period, the real scenario; without knowing the exact circumstances that cause the problem, I suspect that using a simple small example, even repeated many times, won't reproduce it (though thank you for trying!).
Is there any instrumentation I can add to the code I am running which would print out stuff of interest to you when the problem occurs?  State information, that kind of thing?
I will also look into your i2c_master_write_to_device() and i2c_master_read_from_device() functions.

Hi, @o-marshmallow just to mention that in this forum entry: https://www.esp32.com/viewtopic.php?f=2&t=33583
it is also mentioned that I2C code running fine on an ESP32 does not run on a ESP-C2 devboard. Here I have the impression that the length of the data send over I2C creates the problem.
Let me please now if we can handle this problem in this issue as well, or if I should open up a new ticket.
So far I tries all the recommendation from above and switched to 5.0.2, without any luck to solve the problem.
Thanks

Seems I was wrong: I tried your example, using i2c_master_write_read_device() just as you have, modified to read two bytes back rather than one (since that's what our device wants to do), and it fails pretty much immediately, on the first or second go around the loop.  This is still using master (https://github.com/espressif/esp-idf/commit/54576b7528b182256c027de86eb605a172bc2821).
Here is the code:
#include <stdio.h>
#include <inttypes.h>
#include "sdkconfig.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/i2c.h"
#include "driver/gpio.h"

#define I2C_MASTER_PORT 0
#define DEVICE_ADDRESS 0x42 // un-shifted address!
#define TRIGGER_PIN 12

static esp_err_t i2c_master_init(void)
{
    i2c_config_t conf = {
        .mode = I2C_MODE_MASTER,
        .sda_io_num = 18,
        .scl_io_num = 17,
        .sda_pullup_en = GPIO_PULLUP_ENABLE,
        .scl_pullup_en = GPIO_PULLUP_ENABLE,
        .master.clk_speed = 100000,
    };

    i2c_param_config(I2C_MASTER_PORT, &conf);

    return i2c_driver_install(I2C_MASTER_PORT, conf.mode, 0, 0, 0);
}

void app_main(void)
{
    uint8_t data[1] = { 0xFD };
    uint8_t datar[2] = { 0 };
    int32_t x = 0;
    esp_err_t ret = ESP_OK;
    gpio_config_t config;

    // Set up trigger pin for logic capture
    config.intr_type = GPIO_INTR_DISABLE;
    config.mode = GPIO_MODE_OUTPUT;
    config.pull_down_en = GPIO_PULLDOWN_DISABLE;
    config.pull_up_en = GPIO_PULLUP_DISABLE;
    config.pin_bit_mask = 1ULL << TRIGGER_PIN;
    ret = gpio_config(&config);
    if (ret != ESP_OK) {
        printf("Error initializing pin(s) 0x%08llx\n", config.pin_bit_mask);
        return;
    }
    gpio_set_level(TRIGGER_PIN, 0);

    ret = i2c_master_init();
    if (ret != ESP_OK) {
        printf("Error initializing the I2C\n");
        return;
    }

    while (1) {
        ret = i2c_master_write_read_device(I2C_MASTER_PORT, DEVICE_ADDRESS, data, 1, datar, 2, 1000 / portTICK_PERIOD_MS);
        if (ret != ESP_OK) {
            gpio_set_level(TRIGGER_PIN, 1);
            printf("Error %d sending data on attempt %ld\n", ret, x + 1);
            return;
        }
        x++;
        printf("Received: 0x%02x%02x\n", *datar, *(datar + 1));

        vTaskDelay(250 / portTICK_PERIOD_MS);
    }
}

...here is what it printed:
scl_low: 200
scl_wait_high: 98
scl_high: 102
sda_hold: 50
sda_sample: 100
setup: 200
hold: 200
tout: 12
Received: 0x0000
Error 263 sending data on attempt 2

...and here is what the logic analyzer shows:

Zooming-in on the first, successful case:

...that looks good, and zooming-in on the second, fail case:

...it seems to have just stopped clocking after sending the device address for the read part, even thought the Salea probe believes there has been an ack.
I tried removing my GPIO stuff, in case toggling pin 12 was somehow having an adverse effect, but that made no difference to the outcome.  On other runs I also saw it stop after sending the device address for the write:

Unh?
Find attached a ZIP file containing .sal files for the success case, the fail on read and the fail on write:
esp32s3_i2c_simple_example.zip.

Hi @RobMeades ,
I am not sure why using i2c_master_write_read_device would trigger the error more frequenctly than the former version. Maybe the fact that it is faster gives less time to the I2C controller to reset itself from unknown state?
Anyway, I am still looking at the timing configuration, checking each value. In the Technical Reference Manual, the ESP32-S3 I2C hardware component expects that scl_wait_high < sda_sample_time < scl_high period. This is actually the case with our values but it seems a bit tight, they are only one or two clock cycles apart.
I2C timing specification states that scl_wait_high equivalent must be of at most 1000 ns, so we can try making it smaller in the HAL layer, and thus delay sda_sample_time. As such, each of the data I mentioned above will be several clock cyclesa part from eachother.
Another thing that I have noticed is that i2c_stretch_protect_num is not set, and according to its description, I feel we may need it: Configures the time period to release the SCL line from stretching to avoid timing violation. Usually it should be larger than the SDA setup time. Even though we don't have clock stretching, this should "force" the SCL line to go back to high after a certain delay from what I understand.
Overall, here is the diff to apply these changes (including the esp_rom_printf previously mentionned):
i2c.diff.txt
I tested this on my end, with the new SCL pin you gave, and with more receive data, and it still works on my end:

Here is the output on init:
scl_low: 200
scl_wait_high: 64
scl_high: 136
sda_hold: 50
sda_sample: 100
setup: 200
hold: 200
tout: 12

If all of that doesn't work, the problem may not be in the configuration. How many devices have you connected to the I2C bus? Do you have any external pull-up resistors on your board? If not, can you try adding 4.7KOhm pull-up resistors on both SCL and SDA?

Thanks for continuing to try: no change with that patch I'm afraid, same failure patterns/statistics, and the output on init is:
scl_low: 200
scl_wait_high: 64
scl_high: 136
sda_hold: 50
sda_sample: 100
setup: 200
hold: 200
tout: 12

The board we are using already has 2.2K pull-ups on the SDA and SCL lines, so that shouldn't be an issue:

Anything else I can try?

Hold on a sec': since we've never tried using your i2c_master_write_read_device() functions before, I just switched back to an ESP32 (rather than ESP32-S3) board and, with this same simple example, it shows exactly the same error [and yet, of course, it shows not a single I2C error in our 6 minute long test (I retried that also with exactly the same code-base)].
Let me (a) try your most recent patch above on ESP32-S3 but with the 6 minute test (that uses the underlying I2C functions rather than the wrapper) and, if that doesn't work, (b) write a simple example using the underlying I2C functions that I know works on ESP32 (non-S3) and try that out again on ESP32-S3.

Oh, and @o-marshmallow, don't forget @AndreasKohn's question which might have been lost between my ramblings above.

Sorted things out now: the I2C device needed to be reset and allowed to settle, something our core code does and the simple example needed to be made to do.
Below is the simple example code but, of course, it runs fine, doesn't show the problem: when the GNSS chip is "just ticking over" like this there are only a few hundred bytes of data to be read every second; there is a lot more variability/loading in the 6 minutes of regression tests that we run routinely.
It seems quite likely to me that, since the error we are seeing is a timeout, and the maximum tout value has gone from more than 10 milliseconds on ESP32 (we set 10 ms) to 0.387 microseconds (i.e. ~30 times smaller) on ESP32-S3, that our problem is that there are situations where 0.387 microseconds is just not long enough, the ESP32-S3 is timing-out when the I2C device is responsive, has received the data it was sent or will send the data it was asked for, just cannot always be that fast.
Is there any way to make tout larger than 0.387 microseconds, or is this a chip limitation?
#include <stdio.h>
#include <inttypes.h>
#include "sdkconfig.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/i2c.h"
#include "driver/gpio.h"

#define I2C_MASTER_PORT 0
#define TIMEOUT_APB_TICKS 0x1f // 800000 == 10 ms
#define DEVICE_ADDRESS 0x42 // un-shifted address!
#define REGISTER_ADDRESS 0xFD
#define TRIGGER_PIN 12
#define DEVICE_RESET_BAR_PIN 19

#define ADDRESS_WRITE(__ADDRESS__) (((__ADDRESS__) << 1) | I2C_MASTER_WRITE)
#define ADDRESS_READ(__ADDRESS__) (((__ADDRESS__) << 1) | I2C_MASTER_READ)

static esp_err_t i2c_master_init(void)
{
    i2c_config_t conf = {
        .mode = I2C_MODE_MASTER,
        .sda_io_num = 18,
        .scl_io_num = 17,
        .sda_pullup_en = GPIO_PULLUP_ENABLE,
        .scl_pullup_en = GPIO_PULLUP_ENABLE,
        .master.clk_speed = 100000,
    };

    i2c_param_config(I2C_MASTER_PORT, &conf);

    return i2c_driver_install(I2C_MASTER_PORT, conf.mode, 0, 0, 0);
}

void app_main(void)
{
    uint8_t data[1] = { REGISTER_ADDRESS };
    uint8_t datar[128] = { 0 };
    int x = 0;
    int y;
    int z = 0;
    esp_err_t ret = ESP_OK;
    gpio_config_t config;

    gpio_set_level(TRIGGER_PIN, 0);
    gpio_set_level(DEVICE_RESET_BAR_PIN, 1);
    config.intr_type = GPIO_INTR_DISABLE;
    config.mode = GPIO_MODE_OUTPUT;
    config.pull_down_en = GPIO_PULLDOWN_DISABLE;
    config.pull_up_en = GPIO_PULLUP_DISABLE;
    config.pin_bit_mask = (1ULL << TRIGGER_PIN) | (1ULL << DEVICE_RESET_BAR_PIN);
    ret = gpio_config(&config);
    if (ret != ESP_OK) {
        printf("Error initializing pin(s) 0x%08llx\n", config.pin_bit_mask);
        return;
    }

    printf("Resetting i2C device...\n");
    gpio_set_level(DEVICE_RESET_BAR_PIN, 0);
    vTaskDelay(500 / portTICK_PERIOD_MS);
    gpio_set_level(DEVICE_RESET_BAR_PIN, 1);

    printf("Waiting to start...\n");
    vTaskDelay(3000 / portTICK_PERIOD_MS);

    ret = i2c_master_init();
    if (ret != ESP_OK) {
        printf("Error initializing the I2C\n");
        return;
    }

    ret = i2c_set_timeout(I2C_MASTER_PORT, TIMEOUT_APB_TICKS);
    if (ret != ESP_OK) {
        printf("WARNING: attempt to set timeout to %d APB ticks returned %d\n", TIMEOUT_APB_TICKS, ret);
    }
    ret = i2c_get_timeout(I2C_MASTER_PORT, &y);
    if (ret != ESP_OK) {
        printf("Unable to get I2C timeout\n");
        return;
    }
    printf("I2C timeout is now %d APB ticks\n", y);

    while (1) {
        // Send one byte with no stop, then receive two bytes back again, the last byte of which should be NACKed
        ret = i2c_master_write_read_device(I2C_MASTER_PORT, DEVICE_ADDRESS, data, 1, datar, 2, 1000 / portTICK_PERIOD_MS);
        if (ret != ESP_OK) {
            gpio_set_level(TRIGGER_PIN, 1);
            printf("Error %d exchanging data on attempt %d (%d byte(s) read in total)\n", ret, (x + 1), z);
            return;
        }
        z += 2;
        y = (int) ((((uint32_t) datar[0]) << 8) + datar[1]);
        if (y > 0){
            // Data bytes can now be read from address 0xFF, which the device will have auto-incremented to
            if (y > sizeof(datar)) {
                y = sizeof(datar);
            }
            ret = i2c_master_read_from_device(I2C_MASTER_PORT, DEVICE_ADDRESS, datar, y, 1000 / portTICK_PERIOD_MS);
            if (ret != ESP_OK) {
                gpio_set_level(TRIGGER_PIN, 1);
                printf("Error %d reading data on attempt %d (%d byte(s) read in total)\n", ret, (x + 1), z);
                return;
            }
            z += y;
        }
        if (x % 1000 == 0) {
            printf("Still running, %d byte(s) read in total\n", z);
        }
        x++;
    }
}

@AndreasKohn Sorry for the late reply, yes you should create a new issue (I see that you did that already, thank you!)
@RobMeades How did you calculate the 0.387 microseconds timeout?
The value set as a timeout is a power of two of SCLK clock cycles. In other words, if the timeout is set to 12, it is actually equal to 2^12 * SCLK_PERIOD, in current case, the SCLK_PERIOD is 25ns (40MHz). So the timeout is in fact equal to 102.4 microseconds.
As stated in the technical reference manual, the maximum value for timeout is 22, which is equal to 2^22 * 25ns = 104.9ms. If you want to have around 10ms of timeout, set this value to 19.

Oh!  I had read the documentation as saying that the value is in 80 MHz ABP clock cycles.  If it is in a power of 40 MHz that makes rather a large difference :-).
I have been changing a lot of things at once, and in different scenarios, over the last two days; in particular realising that the device I am talking to is a lot slower to respond in the first few seconds after power on: it is a complicated beast and I guess is booting etc. rather busily to begin with; it is around here that most of the timeouts are occurring (we power the device up an down many times during the 6 minute test).  That, and I have been tweaking many variables on the ESP32S3 side. Since I had thought the timeout value was so small as to be useless, I had left it at the default of 12.  Last night I arn with the timeout set to what I perceived to be the maximum value of to 0x1F again, having read i2c_reg.h for ESP32S3 (versus i2c_reg.h for file for ESP32); the i2c_set_timeout() function permits this value to be set: where would I find the limit of 22 in the documentation?. Anyway, I had no errors which, with your explanation above, makes a lot of sense.
Summary: I think we're nearly there, thank you for your expert attention, i would just like to make sure I have references to the bits of documentation where the value set using i2c_set_timeout() is accurately defined.

I understand the confusion about the timeout. On the ESP32, the I2C was clocked by APB indeed, which is 80MHz:

(ESP32 Technical Reference Manual page 295)
But on the ESP32-S3, the I2C SCL_FSM (responsible for the SCL signal) is clocked by the SCLK clock:

(ESP32-S3 Technical Reference Manual page 954)
That SCLK clock can be either sourced from XTAL clock (40MHz) or from the RC Fast Clock (17.5MHz). The resulted frequency is calculated as followed:

(ESP32-S3 Technical Reference Manual page 956)
In the previous examples, the divider was 1, so the SCLK frequency was the same as the source one, which was 40MHz XTAL. The divider was also calculated in i2c_ll_cal_bus_clk function.
I start wondering whether it could be your device that does clock stretching (pulls the SCL line low) in order to tell the ESP32-S3 to slow down on the transfer because it (device) is busy treating the previous command. If you are seeing this issue only when stressing the bus, I think it could make sense.

That's excellent stuff: the other critical thing here, I think, is whether the value is a multiplier of the clock or a power-of-two of the clock: I've been reading the ESP32 technical document and the ESP32S3 technical document, plus the ESP-IDF description of the i2c_xxx_timeout() functions and I think all might benefit from some clarification.  Just to keep it simple:

For the ESP32 case, is the parameter in the i2c_xxx_timeout() functions a multiplier of the 80 MHz APB clock, or a power-of-two of the 80 MHz APB clock?
For the ESP32S3 case, I understand that the parameter in the i2c_xxx_timeout() function is a power-of-two of a clock value: how do I determine, at ESP-IDF level, what the rate of that clock is?

Correct me if my link is wrong but I think I Just found the Integration manual for your device: https://content.u-blox.com/sites/default/files/MAX-M10S_IntegrationManual_UBX-20053088.pdf
It is clearly stated that the device will perform clock stretching when the inner CPU is busy servicing an interrupt:

When you perform a lot of transactions one after the other, the probability that the CPU will be servicing an interrupt while an I2C transfer occurs is very high, mainly at 100KHz (because the transfer last longer). This is why you see clock stretching and thus, get a timeout.

Indeed, so what it comes down to is that, based on my experience with ESP32, I had taken the ESP-IDF documentation literally:

On the face of it, there is no difference for ESP32S3, except that i2c_set_timeout() returns an error when I pass it the value I used with ESP32.   Checking those header files, I saw that the register had become only 5-bits wide, hence I asked this question on the forum as to why the value is now so tiny as to be useless, but there was no answer.  Even the ESP32-S3 documentation says:

The key missing phrase, I think, is "power of two"!

Perfect: last question then - is there a way to determine, at ESP-IDF level, the current rate of SCLK?

@RobMeades You guessed right, the clock is selected based on the clk_flags you pass when configuring the I2C bus. Manually selecting the source clock would cause incompatibility between IDF programs because some clocks are not available on all targets.
The flag that correpsonds to the RC clock is I2C_SCLK_SRC_FLAG_LIGHT_SLEEP, as you said, it frequency doesn't change, even in light sleep. Even though RC clock also presents I2C_SCLK_SRC_FLAG_AWARE_DFS flag, this flag is mainly used to select REF_TICK as a clock source (only supported on S2 as far as I know)

Got it, thanks again, closing this issue.


Improve contributor stats pages

- add d rocket logo
- change background color to purple
- change text color to white
- modify the title so that is more self explanatory
- add useful links to dlang.org and blog post detailing the rewarding system

cc @CyberShadow

Nice. Would you like me to review/test it or just deploy it?

@CyberShadow Is this good to go?

Ahh sorry I dropped it.
Will look at it today, thanks for the ping.

What do you think?


Plotting jada increments with AVD tools

This is a placeholder for an issue with plotting analysis increments generated by jada. The AVD team have developed visualisation software (not necessarily fully released?) for examining lfric-based files using geovista modules (which will eventually be a welcome replacement for our much-used xconv utility for UM model files). The new tool works on lfric diagnostic model files and on increment files (as created from VAR by lfric2um route) but NOT for jada-created increment files. Both sources of increment files are routinely read by IAU within lfric, but presumably there remain differences in metadata that affect the plotting interface.

Hi @RickRawlins. Is this issue still valid?


Autocert: respect federation root bundles

What would you like to be added
Deploy federation bundles alongside root CA bundle and leaf certificate into containers. Both for first cert enrollment and successive cert renewals.
Why this is needed
step already supports federation and autocert users should have the ability to take advantage of connecting across federated roots.

https://github.com/smallstep/autocert/blob/master/bootstrapper/bootstrapper.sh#L12


"Feliceni", "Alexandrița", "Arvățeni", "Cireșeni", "Forțeni", "Hoghia", "Oțeni", "Polonița", "Tăureni", "Teleac" and "Văleni" are listed in the drop-down menu

Description:
"Feliceni", "Alexandrița", "Arvățeni", "Cireșeni", "Forțeni", "Hoghia", "Oțeni", "Polonița", "Tăureni", "Teleac" and "Văleni" are listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Feliceni" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Feliceni, HARGHITA (Feliceni)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Type "Alexandrița" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Alexandrița, HARGHITA (Feliceni)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 7
Type "Cireșeni" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Cireșeni, HARGHITA (Feliceni)".

Step 8
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 9
Type "Forțeni" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Forțeni, HARGHITA (Feliceni)".

Step 11
Type "Hoghia" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Hoghia, HARGHITA (Feliceni)".

Step 13
Type "Oțeni" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Oțeni, HARGHITA (Feliceni)".

Step 14
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 15
Type "Polonița" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Polonița, HARGHITA (Feliceni)".

Step 16
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 17
Type "Tăureni" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Tăureni, HARGHITA (Feliceni)".

Step 18
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 19
Type "Teleac" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Teleac, HARGHITA (Feliceni)".

Step 20
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 21
Type "Văleni" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Văleni, HARGHITA (Feliceni)".


Using the better Spree.ready solution

Just using the suggested code from @mrbrdo : https://github.com/mrbrdo/spree_mobility/pull/3
@mrbrdo : I tested the code on Spree 4.4 and it works :-)

Thanks so much for taking the time. Merged that commit into main and released 1.3. Tested and working with 4.3.1.


Two questions for referee safeguarding question

I keep misreading this as "Not as far as I’m aware"


PHP 8 Support

I am using json5 now and hope to support php8. Thank you very much

PHP 8 support is now available via v2.2.0! :tada:


Add notification interface and refactor UI notifications

This pull request create a notification interface so that all notifications, i.e. ui, actions, webhooks, mails and etc. will only need to implement the interface. So that the code will be more easy. This is extract from #4001. It's a first step of serval pull requests from #4001. I think it will be easier to review.

Codecov Report

Merging #5085 into master will increase coverage by <.01%.
The diff coverage is 43.91%.

@@            Coverage Diff             @@
##           master    #5085      +/-   ##
==========================================
+ Coverage   37.41%   37.41%   +<.01%
==========================================
  Files         306      307       +1
  Lines       45374    45506     +132
==========================================
+ Hits        16975    17025      +50
- Misses      25945    26028      +83
+ Partials     2454     2453       -1

Impacted Files
Coverage Δ

routers/api/v1/repo/pull.go
13.2% <0%> (-0.08%)
:arrow_down:

routers/repo/pull_review.go
0% <0%> (ø)
:arrow_up:

routers/api/v1/repo/issue_comment.go
57.51% <100%> (+0.27%)
:arrow_up:

routers/repo/pull.go
33.96% <100%> (ø)
:arrow_up:

modules/notification/notification.go
29.41% <27.5%> (-49.16%)
:arrow_down:

modules/notification/ui/ui.go
64.7% <64.7%> (ø)

routers/api/v1/repo/issue.go
30.08% <66.66%> (+0.32%)
:arrow_up:

routers/repo/issue.go
32.17% <66.66%> (+0.02%)
:arrow_up:

models/repo_list.go
61.76% <0%> (-1.18%)
:arrow_down:

models/repo_indexer.go
50.84% <0%> (ø)
:arrow_up:

... and 1 more

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 0cd8cec...c6ce084. Read the comment docs.

Thank you for this PR. I think this re-factoring is really needed!

@BetaCat0 done.


iOS 13 issue. Dragging an item drags the whole view for modal views

Dragging an item, drags the whole view in iOS 13 when the view is presented as modal.
Dragging down closes the view.
dragging issue.mov.zip
A workaround is to disable iOS 13 presentation style by in the modal UIViewController implementation:
by setting the presentation style to full form.
if (@available(iOS 13, *)) {         self.modalPresentationStyle = UIModalPresentationFullScreen;     }

facing the same issues. Any other workaround?


Add citybikes platform

Description:
CityBikes is an open API platform, that provides data about bike sharing systems around the world. It allows real-time monitoring of bike availability at bike sharing stations.
This platform connects the CityBikes API to home assistant, opening up the possibilities for advanced automations, such as recommending the user a bike sharing station based on the amount of bikes available, upon leaving the house.
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#2770
Example entry for configuration.yaml (if applicable):
sensor:
  - platform: citybikes
    radius: 500

Checklist:
If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies have been added to the REQUIREMENTS variable ([example][ex-requir]).
[x] New dependencies are only imported inside functions that use them ([example][ex-import]).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

Nice component (and service), thanks! I tested out the functioning of radius and static station lists, working nicely.

@balloob,
I already have some ideas for improvements that I want to implement ASAP, and they will be breaking the current structure, so I guess there's no point in merging this just yet.
In general, I'm planning the following - let me know what you think:

Promote it into a component. Is that OK, or should I leave it as a sensor? I believe its role is different enough to justify such a promotion (like weather, for example).
Switch to direct access to CityBikes API. This will let me handle the HTTP requests, and I will be able to make the code properly async. Their API is officially open and announced to the web, so I don't think that constitutes accessing data directly instead of using standalone Python libraries. I will, however, contribute the async code to the Python library that wraps access to the data (the one I'm using currently), and once that is merged, I'll switch back to using the library.
Additionally, I want to support dynamic creation/removal of Station entities. Both to allow the component to start without errors while the Internet is down, and to support dynamic location - so that, for example, a user will always be able to see free bikes on stations around their current location (for users who use device location tracking). Are there any rules or guidelines about how to properly implement such a thing?

So, I wrote a component version (https://github.com/home-assistant/home-assistant/compare/dev...aronsky:add-citybikes-component). It's better in some ways, but not perfect - I'd like some help to develop it further. Even if the final decision will be to leave this as a platform, it was a good exercise in async development, and I'll port the appropriate changes to this pull request.
Anyway, what's the best way to discuss the component? Should I make another pull request, and once we decide which approach is better, you merge one and close the other? I don't want to spam the project, I'm sure you guys have enough on your heads.

Let's keep the discussion here. So I prefer the async version because it's async. However, I do think that:

the async code should be extracted into a lib on pypi.
I think that this should stay a sensor as you know, that's kinda what it is.

Is the upstream of the already existing python api responsive? I think it would make sense to try to integrate the async version to the already existing library (if doable with a feasible amount of work).

I already did, today (https://github.com/eskerda/python-citybikes/pull/1). You're welcome to review and comment there :) However, this breaks the compatibility with Python 2.7, so not sure it'll be accepted. For now, I'll use my commit as the requirement, and update it if the pull request gets accepted.

Don't mind the intermediate pushes to the branch, it's a WIP (I'm closing this PR for now, will re-open it once I'm done).

Can't re-open this PR due to GitHub limitations (I rebased it on an up-to-date dev commit, and GitHub doesn't see the continuity). Continued in #8202.


Support Journal Entries

See API: https://www.freshbooks.com/api/journal-entries

Supported in version 3.2.0


Migration from dump to build

Snapshot information is now read from build database; tokens and command spans are re-constructed. This makes the CLI an order of magnitude faster.
The reconstruction is tested on the whole distribution and produces identical command spans to the dump.

Good point.


Add relayState to configuration of onelogin_saml_app

Hi,
we would like to be able to maintain the relayState with the terraform verb onelogin_saml_app.
It is already possible with the API, so I hope, it is easy for you to add to the terraform provider as well. API example:
"configuration": {
"relay": "superduper",
"certificate_id": 271155,
"account_id": "9d11aa89-2033-4111-869a-e6c24e22556c",
"signature_algorithm": "SHA-1"
}
For us it is another step towards having the New Relic with organization app configured fully with terraform. In this sense #29 is related to this issue.
In our case we do use the EU region of New Relic and we would like to have users being ending up in this region right away. The app it self is able to do so (Thanks to Chris from your support team).
Thanks in advance

Hey @marcusvoss we currently support the relaystate parameter on SAML apps
I'm not certain about the newrelic app in particular, but its also likely that relay is a custom configuration parameter of the app you are defining. Is relay in fact what you wish to set here, or are you trying to specify the relaystate of such SAML app?
If I may, I'd suggest trying to set relaystate now and see if that unblocks you. If so, please comment & close the issue, otherwise, let me know and we'll get relay plugged in as well.
Thanks for reaching out!

Hey @marcusvoss we currently support the relaystate parameter on SAML apps
I'm not certain about the newrelic app in particular, but its also likely that relay is a custom configuration parameter of the app you are defining. Is relay in fact what you wish to set here, or are you trying to specify the relaystate of such SAML app?
If I may, I'd suggest trying to set relaystate now and see if that unblocks you. If so, please comment & close the issue, otherwise, let me know and we'll get relay plugged in as well.
Thanks for reaching out!

Hey @dcaponi I was confused by the line 53 in the same file. It was indicating for me that the relaystate will only work for OIDC apps.
But anyhow @tkallenberg-tw and me tried it with this code:
resource "onelogin_saml_apps" "app" {   visible              = true   allow_assumed_signin = false   connector_id         = var.connector_id   description          = var.description   name                 = var.name   notes                = "IaC: ${var.vcs_url}"   configuration = {     signature_algorithm = "SHA-512"     relaystate          = "https://one.eu.newrelic.com/"   }   provisioning = {     enabled = true   }
The result was this error:
module.onelogin_app_member.module.onelogin_app_prod.onelogin_saml_apps.app: Modifying... [id=392823] Error: error: context: [ol http service], error_message: [{"message":"Unknown parameter on configuration section: relaystate","statusCode":400,"name":"BadRequestError"}]   on ../../modules/onelogin_app/saml_app.tf line 1, in resource "onelogin_saml_apps" "app":    1: resource "onelogin_saml_apps" "app" {
Any idea what we can improve?
Cheers, Marcus

Hey @dcaponi I was confused by the line 53 in the same file. It was indicating for me that the relaystate will only work for OIDC apps.
But anyhow @tkallenberg-tw and me tried it with this code:
resource "onelogin_saml_apps" "app" {   visible              = true   allow_assumed_signin = false   connector_id         = var.connector_id   description          = var.description   name                 = var.name   notes                = "IaC: ${var.vcs_url}"   configuration = {     signature_algorithm = "SHA-512"     relaystate          = "https://one.eu.newrelic.com/"   }   provisioning = {     enabled = true   }
The result was this error:
module.onelogin_app_member.module.onelogin_app_prod.onelogin_saml_apps.app: Modifying... [id=392823] Error: error: context: [ol http service], error_message: [{"message":"Unknown parameter on configuration section: relaystate","statusCode":400,"name":"BadRequestError"}]   on ../../modules/onelogin_app/saml_app.tf line 1, in resource "onelogin_saml_apps" "app":    1: resource "onelogin_saml_apps" "app" {
Any idea what we can improve?
Cheers, Marcus

Im going to add relay as a configuration field so our provider looks out for it and manages it. You can try with v0.1.7 by setting relay = "https://one.eu.newrelic.com/" as you attempted earlier.
Please let me know the outcome @marcusvoss 😄

Im going to add relay as a configuration field so our provider looks out for it and manages it. You can try with v0.1.7 by setting relay = "https://one.eu.newrelic.com/" as you attempted earlier.
Please let me know the outcome @marcusvoss 😄

@marcusvoss Can I go ahead and close this out?

@marcusvoss Can I go ahead and close this out?

@dcaponi great it is working. Thank you :)
Sorry we had trouble on other ends and so limit test capacity.

@dcaponi great it is working. Thank you :)
Sorry we had trouble on other ends and so limit test capacity.


Adding UI for MEVN-cli

With this we plan to create a ui for MEVN-cli tool which will help developers to add packages and integrations, basically execute different commands used in cli via a ui which would be running locally.

@jamesgeorge007 can you give some ref for it?

@IsAmrish vue-cli has got a ui command which allows the user to set up their project from a web-based UI. We're gonna follow a similar approach.

its not that much simple. need complete front-end app. right?

@nasr18 yeah, it is a bit complex and requires to have collaborative effort.

What's the status on this? I'll like to contribute.

Sure, feel free.
On Sun, 20 Oct, 2019, 8:49 PM Emmanuel Raymond<EMAIL_ADDRESS>wrote:

What's the status on this? I'll like to contribute.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/madlabsinc/mevn-cli/issues/67?email_source=notifications&email_token=AGA3WHZ7U4I6QCHFUUZNVA3QPRZJ5A5CNFSM4GU3E6P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYMOEQ#issuecomment-544261906,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGA3WHYR2ZKEATBZWF74MWLQPRZJ5ANCNFSM4GU3E6PQ
.

I would like to contribute, Does anybody have any plans or ideas to start with?

Hello ! i would love to help on this task, what's the current situation of the ui part ?


Ddox: support assert to writeln rewrite

There's already some very naive support to rewrite assert's statements to writeln function calls for the ddoc build.
This just adds extend the RegExp for ddox.
This approach itself is pretty limited and of course it would be better to do this during compilation (e.g. as a plugin for ddox) and not via RegExp in Js. Moreover, the RegExp itself might catch some false positives and also doesn't support other common operations like equal or a plain assert.
So this is intended as temporary solution until someone has more time to invest into a proper solution.
Btw another reason which makes this complicated is that there are two code boxes (the editor and code highlighted produced by ddoc/ddox) and one can only edit the plain source code of the former. At the moment "reset" hides the editor and shows the original code from ddoc/ddox, but one could argue that there's no point in keeping this code box generated by ddoc/ddox

Current ddoc behavior - the pattern assert(a == b); is automatically rewritten to writeln(a); // b:
https://dlang.org/phobos-prerelease/std_algorithm_searching.html#.minElement
Corresponding ddox page:
http://dtest.thecybershadow.net/artifact/website-df837d199d2c48d73acc50a0d6ed8a372e27a872-4099e695caf15988d1389a039504cffd/web/library-prerelease/std/algorithm/searching/min_element.html

This is a bit odd. But heck let's try it.

conflicts please rebase

conflicts please rebase

rebased ;-)

conflicts please rebase
rebased ;-)

(merging as rebased and approved)


Simplify Notify configuration mechanism

Trello: https://trello.com/c/G35ncFfw/645-simplify-configuration-for-email-sending
This replaces a number of concepts that are used to configure the Notify usage of Email Alert API. This has been done to reflect how the system is used in practice, to simplify the system and to resolve a problem where most emails weren't sent in integration and staging. The variety of configuration levers have been changed to now use a single GOVUK_NOTIFY_RECIPIENTS environment variable for deciding who'll get emails by Notify, those who are permitted will be sent an email with Notify and those that won't will have their email logged. The best way to review this is commit by commit.
Concepts changed:

provider - this is now replaced by a conditional that decides whether email is sent to Notify or logged based on the value of GOVUK_NOTIFY_RECIPIENTS;
email_subject_prefix - this feature is now removed, it appeared unnecessary as the senders are prefixed and it should be fully redundant when switch integration/staging to send emails to a Google group is completed;
email_address_override - this feature wasn't used;
email_address_override_whitelist - replaced by GOVUK_NOTIFY_RECIPIENTS environment variable;
email_address_override_whitelist_only - no longer needed as an environment variable because an entry in GOVUK_NOTIFY_RECIPIENTS acts as an allowed list;
expect_status_update_callbacks - this had no effect on the application anymore.

More information in the commits.

Much better, and thanks for fixing a few other small things along the way 🎨. (Note to self: the new environment variable is already in place.)
Just a few minor comments. Also, it does seem a bit strange that the tests all send to * but the default is "". Perhaps the default should actually be *?

Do you mean for test or all environments? It makes sense to be nil for all environments by default so that sending to Notify is something that has to be turned on rather than turned off.
The default of "" on https://github.com/alphagov/email-alert-api/pull/1489/files#diff-9e30a404f2ecf5367673492e503ceaa069c7ba93d34e9743bd0593d1e55d9df8R26 is just used since it makes it simpler to do the array conversion compared to a nil.

Do you mean for test or all environments? It makes sense to be nil for all environments by default so that sending to Notify is something that has to be turned on rather than turned off.

Yeah, I'm challenging whether it really matters that much, since the Integration/Staging accounts are restricted anyway. But it's only a minor thing I noticed when comparing the tests vs. the code - not fussed if it stays as-is.

Do you mean for test or all environments? It makes sense to be nil for all environments by default so that sending to Notify is something that has to be turned on rather than turned off.

Yeah, I'm challenging whether it really matters that much, since the Integration/Staging accounts are restricted anyway. But it's only a minor thing I noticed when comparing the tests vs. the code - not fussed if it stays as-is.

Ok cool, maybe I'm missing a nuance but I think it makes more sense as-is so I'll keep it that way and get this merged. Thanks for being flexible 👍 .


Add Azure Load Testing action to health-dashboard

There are few steps to onboard any new action to health-dashboard. They include -

creating a standard set of labels in your repository for incoming issues.
Adding Issue template.
Raise a PR in the actions repo.

The above steps 👆🏻 needs to be followed for Azure load testing action to include in health-dashboard.
Please find the detailed process here.

Completed the above steps. Link to the PR https://github.com/Azure/actions/pull/128

@BALAGA-GAYATRI , can we close this?


normalize URLs

@magul
@cmwd

Current coverage is 49.57%

Merging #100 into master will not affect coverage as of 0771c6f

@@            master    #100   diff @@
======================================
  Files           10      10
  Stmts          119     119
  Branches         0       0
  Methods          0       0
======================================
  Hit             59      59
  Partial          0       0
  Missed          60      60

Review entire Coverage Diff as of 0771c6f

Powered by Codecov. Updated on successful CI builds.


[Bug] client OSerializationException -> server OIOException -> "infinite" client waiting

OrientDB Version: 3.0.21
Java Version: 1.8.0_211
OS: Windows 10
Expected behavior
Connections should be closed regardless of exceptions
Actual behavior
Connections aren't closed.
Steps to reproduce
Flow:
(1) (Client Side) I'm trying to save an entity to the database. I'm using a type orientdb can't serialize though, so it throws an exception
(2) (Server Side) The server doesn't like that, and throws an exception too. Something is messed up there too.
(3) (Client Side) Since there was an exception, I'm trying to close the connection so I can return it to the resource pool. When trying to close it though, the client seems to be waiting for the server response. The server never respond, since it has it's own exception
(4) (Client Side) now the client has an open connection, waiting for a message from the server (which will never happen), with a timeout of 1h.
On the client, I'm getting this exception:
com.orientechnologies.orient.core.exception.OSerializationException: Impossible serialize value of type class com.msh.myapp.models.MyAlbum with the Result binary serializer
	DB name="mydb"
	at com.orientechnologies.orient.core.serialization.serializer.record.binary.ORecordSerializerNetworkV37.writeEmbeddedMap(ORecordSerializerNetworkV37.java:660)
	at com.orientechnologies.orient.core.serialization.serializer.record.binary.ORecordSerializerNetworkV37.serializeValue(ORecordSerializerNetworkV37.java:596)
	at com.orientechnologies.orient.core.serialization.serializer.record.binary.ORecordSerializerNetworkV37.writeEmbeddedMap(ORecordSerializerNetworkV37.java:663)
	at com.orientechnologies.orient.core.serialization.serializer.record.binary.ORecordSerializerNetworkV37.serializeValue(ORecordSerializerNetworkV37.java:596)
	at com.orientechnologies.orient.core.serialization.serializer.record.binary.ORecordSerializerNetworkV37.serialize(ORecordSerializerNetworkV37.java:157)
	at com.orientechnologies.orient.core.serialization.serializer.record.binary.ORecordSerializerNetworkV37.toStream(ORecordSerializerNetworkV37.java:874)
	at com.orientechnologies.orient.core.record.impl.ODocument.toStream(ODocument.java:2799)
	at com.orientechnologies.orient.core.record.impl.ODocument.toStream(ODocument.java:1038)
	at com.orientechnologies.orient.client.remote.message.OMessageHelper.getRecordBytes(OMessageHelper.java:83)
	at com.orientechnologies.orient.client.remote.message.OQueryRequest.write(OQueryRequest.java:94)
	at com.orientechnologies.orient.client.remote.OStorageRemote.lambda$networkOperationRetryTimeout$2(OStorageRemote.java:231)
	at com.orientechnologies.orient.client.remote.OStorageRemote.baseNetworkOperation(OStorageRemote.java:303)
	at com.orientechnologies.orient.client.remote.OStorageRemote.networkOperationRetryTimeout(OStorageRemote.java:227)
	at com.orientechnologies.orient.client.remote.OStorageRemote.networkOperationNoRetry(OStorageRemote.java:257)
	at com.orientechnologies.orient.client.remote.OStorageRemote.command(OStorageRemote.java:942)
	at com.orientechnologies.orient.core.db.document.ODatabaseDocumentRemote.command(ODatabaseDocumentRemote.java:410)

When that happens, the server is then encountering the following exception:
2019-07-05 17:55:44:961 FINE  {db=mydb} Request id:27 type:45 [ONetworkProtocolBinary]com.orientechnologies.common.io.OIOException: Impossible to read a chunk of length:1006632960 max allowed chunk length:16777216 see NETWORK_BINARY_MAX_CONTENT_LENGTH settings
	at com.orientechnologies.orient.enterprise.channel.binary.OChannelBinary.readBytes(OChannelBinary.java:165)

Hi,
This issue should be already solved in 3.0.31, Closing.


Missing "fib" modality in rig.modalities

When I'm investigating another issue, I noticed that there are many sessions in docDB that have "fib" in data_description.modality but not in rig.modalities.  For example:
{
    "_id": "625df1c2-1b38-4875-9a5f-09bbaca0e213",
    "data_description": {
      "name": "behavior_751152_2024-10-13_16-07-35",
      "modality": [
        {
          "name": "Behavior",
          "abbreviation": "behavior"
        },
        {
          "name": "Behavior videos",
          "abbreviation": "behavior-videos"
        },
        {
          "name": "Fiber photometry",
          "abbreviation": "fib"
        }
      ]
    },
    "rig": {
      "modalities": [
        {
          "name": "Behavior",
          "abbreviation": "behavior"
        },
        {
          "name": "Behavior videos",
          "abbreviation": "behavior-videos"
        }
      ]
    }
  },
  {
    "_id": "fbb5bb77-fef3-4f3b-93f2-560a8565488d",
    "data_description": {
      "name": "behavior_764787_2024-10-15_13-07-30",
      "modality": [
        {
          "name": "Behavior",
          "abbreviation": "behavior"
        },
        {
          "name": "Behavior videos",
          "abbreviation": "behavior-videos"
        },
        {
          "name": "Fiber photometry",
          "abbreviation": "fib"
        }
      ]
    },
    "rig": {
      "modalities": [
        {
          "name": "Behavior",
          "abbreviation": "behavior"
        },
        {
          "name": "Behavior videos",
          "abbreviation": "behavior-videos"
        }
      ]
    }
  }

Here is the query  showing all sessions with this problem.
We should:

locate and fix the root cause, presumbly in how we generated rig.json. @XX-Yin @micahwoodard
correct the metadata in docDB (shall we just directly add a patch to these records? how? @dyf)
In the long run, a compatibility check should catch this kind of cross-validation problem.

see also https://github.com/AllenNeuralDynamics/dynamic-foraging-task/issues/510

@hanhou Your query of sessions with this problem are exclusively from non-FIP rigs. The FIP rigs are 1D, 2D, 3D, 6D, 7D, 8D which do not show up in the log.
So the problem is with the data_description.json, not the rig.json

@hanhou @alexpiet Previously, the session description was generated locally, and the code would exclude the fib modality if there was no fib data.  That functionality has been removed and replaced by online generation during upload, which may be the source of the problem.

Interesting! Then all make sense to me. Here may be what happened:

Prior to this PR, we incorrectly added "fib" to "data_description.modalities" of pure behavior sessions without FIP.
In the Streamlit app, to compare with pure behavior and behavior + FIP sessions in my temporary pipeline, we should have queried "behavior" from data_description.modalities, but we actually used "fib". Interestingly, two wrongs make a right: because of 1, we actually queried all behavior-including sessions. So for a long time, sessions from both pipelines seemed to match in Streamlit.
Recently, after the PR, point 1 was fixed and we started to see discrepancies in Streamlit.

I speculate that the uploading process added the fib modality to the data description by default if there is a fib folder.
@alexpiet If there is no fib data, have we already excluded the fib folder in the manifest file?

I speculate that the uploading process added the fib modality to the data description by default if there is a fib folder.
@alexpiet If there is no fib data, have we already excluded the fib folder in the manifest file?

Do you think this PR has fixed the problem?

Yes, my understanding is that PR fixed the problem. The modalities in data_description will be the modalities listed in the upload manifest. Spot checking actual manifests from this week, they correctly do NOT list FIP for behavior only sessions

The correct way of querying "FIP" sessions
Since the data_description.modality was unreliable, at this point, the correct query might be
{"session.data_streams.stream_modalities.abbreviation": "fib"}

To validate, for sessions which have "fib" as a stream, all of them have "fib" in "rig.modalities", if "rig" exists
https://api.allenneuraldynamics.org/v1/metadata_index/data_assets?filter={"session.data_streams.stream_modalities.abbreviation":"fib","rig":{"$ne":null},"rig.modalities.abbreviation":{"$ne":"fib"}}
@alexpiet @XX-Yin @rachelstephlee @hagikent  does this make sense?

related to https://github.com/AllenNeuralDynamics/foraging-behavior-browser/issues/94

Discussed in kanban meeting 11/26
David says the fix forward has been done.
David says he's volunteered for the fixes in the past. I will defer to @dyf  for how we can correct the queries.

In this plot, the red circle should be inside the green circle and overlap perfectly with the blue circle.


Connecting Mapdisptachtoprops in V6 reduxForm()

Version 5 allowed to pass in reduxForm(config:Object, mapStateToProps?, mapDispatchToProps?, mergeProps?, options?)
however the Version 6 only has reduxForm(config:Object) .
How do we pass in our Action creators to handle submit?

Using react-redux's connect HoC.

so i would export default the connect HOC rather than the reduxForm?

https://github.com/erikras/redux-form/issues/698#issuecomment-221721037
class MyForm extends Component {}
MyForm = reduxForm(config)(MyForm)
MyForm = connect(mapStateToProps, mapDispatchToProps)(MyForm)
export default MyForm

Order does not matter unless you are specifically passing some state into redux-form, as in the Initializing From State example.

This should be in the docs :heart:

Its December already and this is still not in the first example.
http://redux-form.com/6.3.1/docs/GettingStarted.md/

@jaspersorrio What, specifically, should be in the docs? The only reason for confusion was that v5 used to do the binding for you, but v6 does not, which it explicitly says in the v6 Migration Guide. It doesn't make sense to list all the things a library does not do on the Getting Started page.

I think this is a very big change that should be clearly documented...

100% needs to be in the docs........ what should of taken me 1 sec looking at the docs took me forever to figure out on my own due to lack of documentation.

PRs are welcome

Hey @erikras thanks for this library. I apologise if i may sound rude earlier. I agree with what you say. However i just wanted to highlight what @alexbahl said. It took me a day to find this information. And it made no sense for me to read the migration guide to V6 as i wasn't a V5 user.
Your new users might face the same problem if you don't make this clear.

It would also be very helpful to document somewhere that the error prop can't be overridden by this approach.

I'm working arroudn this issue using the following wrapper:
import { connect } from 'react-redux';
import { reduxForm } from 'redux-form';

const defaultFormName = config => Component =>
  reduxForm({
    form: Component.displayName || Component.name,
    ...config,
  })(Component);

const optionalConnect = (stateMap, actionMap) => Component =>
  stateMap || actionMap ? connect(stateMap, actionMap)(Component) : Component;

const connectForm = (config, stateMap, actionMap) => Component =>
  optionalConnect(stateMap, actionMap)(defaultFormName(config));

You use it as connectForm()(Component) pretty much as the v5 one mentioned in the issue description. It has some nice features:

config.form is now optional (Form name defaults to component name)
redux's connect is only used when necessary (i.e. either of the maps is defined)

const postNewPost=reduxForm({
form: 'postNew'
})(PostsNew);
function mapDispatchToProps(dispatch) {
return bindActionCreators({createPost},dispatch)
}
export default connect(null,mapDispatchToProps)(postNewPost)

It's currently July and the learner docs still haven't been updated to explain this change. Could someone get on this before this issue is a year old? Maybe save someone else 2 hours trying to figure out what they've configured wrong when it's the package itself? Would be cool.


My lint-staged takes 30s

Description

Steps to reproduce
I am using lint-staged with husky in two repos with fast speed (5s) based on the suggestion in https://github.com/okonet/lint-staged/issues/963
However, in this third repo which is a private repo I am working on, when I run git commit . -m 'some update', it takes around 30s.
This time I do avoid letting eslint running on all files by
module.exports = {
  '*.{js,ts,jsx,tsx}': 'eslint --fix',
};

However, it seems it takes same amount of time with eslint --fix . on all files.
Appreciate for any guide to help further debug! Thanks
Debug Logs

expand to view
yarn run v1.22.10
$ /my-proj/node_modules/.bin/lint-staged --debug
  lint-staged:bin Running<EMAIL_ADDRESS>+0ms
  lint-staged:bin Options parsed from command-line: {
  allowEmpty: false,
  concurrent: true,
  configPath: undefined,
  debug: true,
  maxArgLength: 131072,
  stash: true,
  quiet: false,
  relative: false,
  shell: false,
  verbose: false
} +1ms
  lint-staged Loading config using `cosmiconfig` +0ms
  lint-staged Successfully loaded config from `/my-proj/lint-staged.config.js`:
  lint-staged { '*.{js,jsx,ts,tsx}': 'eslint --fix' } +79ms
  lint-staged:cfg Validating config +0ms
Running lint-staged with the following config:
{
  '*.{js,jsx,ts,tsx}': 'eslint --fix'
}
  lint-staged Unset GIT_LITERAL_PATHSPECS (was `undefined`) +1ms
  lint-staged:run Running all linter scripts +0ms
  lint-staged:resolveGitRepo Resolving git repo from `/my-proj` +0ms
  lint-staged:resolveGitRepo Unset GIT_DIR (was `undefined`) +0ms
  lint-staged:resolveGitRepo Unset GIT_WORK_TREE (was `undefined`) +0ms
  lint-staged:git Running git command [ 'rev-parse', '--show-toplevel' ] +0ms
  lint-staged:resolveGitRepo Resolved git directory to be `/my-proj` +14ms
  lint-staged:resolveGitRepo Resolved git config directory to be `/my-proj/.git` +0ms
  lint-staged:git Running git command [ 'log', '-1' ] +14ms
  lint-staged:git Running git command [ 'diff', '--staged', '--diff-filter=ACMR', '--name-only', '-z' ] +36ms
  lint-staged:run Loaded list of staged files in git:
  lint-staged:run [
  lint-staged:run   '.husky/pre-commit',
  lint-staged:run   'app/components/a.tsx',
  lint-staged:run   'lint-staged.config.js'
  lint-staged:run ] +87ms
  lint-staged:chunkFiles Resolved an argument string length of 205 characters from 3 files +0ms
  lint-staged:chunkFiles Creating 1 chunks for maxArgLength of 131072 +0ms
  lint-staged:gen-tasks Generating linter tasks +0ms
  lint-staged:gen-tasks Generated task:
  lint-staged:gen-tasks {
  lint-staged:gen-tasks   pattern: '*.{js,jsx,ts,tsx}',
  lint-staged:gen-tasks   commands: 'eslint --fix',
  lint-staged:gen-tasks   fileList: [
  lint-staged:gen-tasks     '/my-proj/app/components/a.tsx',
  lint-staged:gen-tasks     '/my-proj/lint-staged.config.js'
  lint-staged:gen-tasks   ]
  lint-staged:gen-tasks } +3ms
  lint-staged:make-cmd-tasks Creating listr tasks for commands 'eslint --fix' +0ms
  lint-staged:task cmd: eslint +0ms
  lint-staged:task args: [ '--fix' ] +0ms
  lint-staged:task execaOptions: { preferLocal: true, reject: false, shell: false } +0ms
  lint-staged:chunkFiles Resolved an argument string length of 147 characters from 2 files +5ms
  lint-staged:chunkFiles Creating 1 chunks for maxArgLength of 131072 +0ms
[STARTED] Preparing...
  lint-staged:git Backing up original state... +0ms
  lint-staged:git Getting partially staged files... +1ms
  lint-staged:git Running git command [ 'status', '-z' ] +45ms
  lint-staged:git Found partially staged files: [] +149ms
  lint-staged:git Backing up merge state... +0ms
  lint-staged:file Reading file `/my-proj/.git/MERGE_HEAD` +0ms
  lint-staged:file Reading file `/my-proj/.git/MERGE_MODE` +0ms
  lint-staged:file Reading file `/my-proj/.git/MERGE_MSG` +0ms
  lint-staged:file File `/my-proj/.git/MERGE_HEAD` doesn't exist, ignoring... +0ms
  lint-staged:file File `/my-proj/.git/MERGE_MODE` doesn't exist, ignoring... +1ms
  lint-staged:file File `/my-proj/.git/MERGE_MSG` doesn't exist, ignoring... +0ms
  lint-staged:git Done backing up merge state! +1ms
  lint-staged:git Getting deleted files... +0ms
  lint-staged:git Running git command [ 'ls-files', '--deleted' ] +150ms
  lint-staged:git Found deleted files: [] +23ms
  lint-staged:git Running git command [ 'stash', 'create' ] +23ms
  lint-staged:git Running git command [
  'stash',
  'store',
  '--quiet',
  '--message',
  'lint-staged automatic backup',
  '518af5f320725a6fbc86c781ed5236bd4bf4a68b'
] +374ms
  lint-staged:git Done backing up original state! +401ms
[SUCCESS] Preparing...
[STARTED] Running tasks...
[STARTED] Running tasks for *.{js,jsx,ts,tsx}
[STARTED] eslint --fix
[SUCCESS] eslint --fix
[SUCCESS] Running tasks for *.{js,jsx,ts,tsx}
[SUCCESS] Running tasks...
[STARTED] Applying modifications...
  lint-staged:git Adding task modifications to index... +28s
  lint-staged:git Running git command [
  'add',
  '--',
  '/my-proj/app/components/a.tsx',
  '/my-proj/lint-staged.config.js'
] +28s
  lint-staged:git Done adding task modifications to index! +33ms
  lint-staged:git Running git command [ 'diff', '--name-only', '--cached' ] +33ms
[SUCCESS] Applying modifications...
[STARTED] Cleaning up...
  lint-staged:git Dropping backup stash... +49ms
  lint-staged:git Running git command [ 'stash', 'list' ] +49ms
  lint-staged:git Running git command [ 'stash', 'drop', '--quiet', 'refs/stash@{0}' ] +60ms
  lint-staged:git Done dropping backup stash! +105ms
[SUCCESS] Cleaning up...
  lint-staged Tasks were executed successfully! +29s
✨  Done in 30.58s.
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
warning: The last gc run reported the following. Please correct the root cause
and remove .git/gc.log.
Automatic cleanup will not be performed until the file is removed.

fatal: bad object refs/remotes/origin/HEAD
fatal: failed to run repack

[user/hongbo/MOB-5372-husky-bak 3d904d7ca] MOB-5372 perf(git hooks): husky
 3 files changed, 3 insertions(+), 3 deletions(-)
(base)

Environment

OS: macOS 11.2.3
Node.js: 14.17.0
lint-staged: 10.5.4

Can you add the --debug flag to your eslint command to see what it does? It should for example list all the files it's going to check:
eslint:file-enumerator Start to iterate files: [] +0ms
eslint:file-enumerator Complete iterating files: [] +0ms

Sorry about that! To make the output of a successful task visible via lint-staged, you don't need to use the --debug flag, but --verbose:
  -v, --verbose                      show task output even when tasks succeed; by default only
                                     failed output is shown (default: false)

So set up eslint --debug --fix like you did, and then run yarn lint-staged --verbose.

Thanks @iiroj for the info about --verbose!
I didn't get time to test this recently. I will report back for what I found.


lending: Support for flash loans

Problem
No support for flash loans
Proposed Changes
Add FlashLoan instruction:

Transfer requested amount of tokens
Invoke serialized instruction
Transfer back sent tokens + fee

Could you expand on how this would work?
Would step one be transferred to the user, then a second tx to invoke the serialized instruction then another transaction to return the funds?

ah didnt see this sysvar: https://docs.solana.com/developing/builtins/sysvars#instructions. I see how it works now. Now need to better understand that sysvar 😃

Looks like https://github.com/solana-labs/solana-program-library/pull/1444 will address this


min-width: 0 is not the same as min-width: initial

I'm using gulp-cssnano which uses this lib under the hood and I just noticed my production app is breaking in Chrome because cssnano is replacing min-width: initial with min-width: 0.
Is there a way to disable this?

Found it, need to pass cssNano({ postcssReduceInitial: false })
Feels like an odd optimisation to me.

Care to share more information? What version are you running? How does it break?

It's not a version issue, replacing min-width: initial with min-width: 0 in Google chrome shrinks the width of an element causing it to clip it's value.

can you provide a minimal test case reproducing the issue?

It's not a version issue

The reason I ask is whether the behaviour is still present in newer versions, such as the new alpha.

Sure, here is a jsfiddle. Notice how the white space in .one is respected but ignored in .two.

I did some testing. Turns out it has the same behaviour even when both <span>s have min-width: initial. Your issue isn't that the minified code is somehow different from the original code, but rather that you have no text that follows the second span.
See:
https://jsfiddle.net/cm4r0486/6/
https://jsfiddle.net/cm4r0486/7/


Can get CompanyInfo, but UserInfo not working

Hello,
I can successfully get authorization and connect my client PHP application to QuickBooks Online. However, while I can make a getCompanyInfo request and receive the results, I can't make a getUserInfo request, as it will complain about the access token object not being set yet.
While connecting to QuickBooks and getting authorization, everything seems to work - and the access token object is placed in the Session. But for some reason, it complains when I try to get the UserInfo data.
Here's the error I receive:
Fatal error:  Uncaught QuickBooksOnline\API\Exception\SdkException: [0]: Can't get OAuth 2 Access Token Object. It is not set yet.

thrown in /compiled/src/Core/OAuth/OAuth2/OAuth2LoginHelper.php on line 129

Here's how I try to get the UserInfo:
$dataService->updateOAuth2Token($accessToken);
$OAuth2LoginHelper = $dataService->getOAuth2LoginHelper();
$result = $OAuth2LoginHelper->getUserInfo();

Again, getting the CompanyInfo works without any problems.
Any idea what's going on?
apiCall.zip
Please also see my Stackoverflow question about this, that explains the issue more in-depth:
https://stackoverflow.com/questions/60138631/quickbooks-v3-php-sdk-only-working-partially-with-quickbooks-online

Following up on SF#00092238


apple-m1 compiler optimisations for aarch64-darwin?

Issue description
https://github.com/NixOS/nixpkgs/blob/dd697d414853a99d0d5f05ee23430923c6da1176/lib/systems/platforms.nix#L393-L398
adds inappropriate arch args for apple-m1. According to Apple clang, arch = "armv8.5a+fp-armv8+neon+crc+crypto+dotprod+fp16fml+ras+lse+rdm+rcpc+zcm+zcz+fullfp16+sm4+sha3+sha2+aes";.
(The string isn't even correct for apple-13 AFAICT, it's armv8.4a.)
Is there any reason against setting arch to the string above?
Secondly, is there any reason against setting cpu = "apple-m1"; once llvm12 is default? llvm11 doesn't support that cpu type; what would happen if a package's llvm was overridden to be llvm11?
cc @thefloweringash @NixOS/darwin-maintainers

The current flags come from https://github.com/NixOS/nixpkgs/pull/105026#issuecomment-774757005 by @bobrik.

Is there any reason against setting arch to the string above?

Not that I know of.

Secondly, is there any reason against setting cpu = "apple-m1"; once llvm12 is default?

That does also sound like an improvement, and might even resolve the TODO items added in 4aa95e33121c (https://github.com/NixOS/nixpkgs/pull/115235#discussion_r626226534). We could probably handle llvm11 compatibility in the cc-wrapper as a special case, if it's still needed. I don't expect there to be a large difference between llvm11 and llvm12.
Though we made a concession to llvm11 to revert the new default setting of -fno-common (c99904e11307cbade607ad855a29f07694762f37). We'd either need to make the same change in llvm12, or progress https://github.com/NixOS/nixpkgs/pull/110571.

@thefloweringash fno-common migration is merged. Does that mean we can upgrade llvm to 12 (or higher?) for aarch64-darwin?

Main blocker rn would be we can't upgrade the LLVM in the bootstraptools currently, relevant information linked from [this PR].

@thefloweringash fno-common migration is merged. Does that mean we can upgrade llvm to 12 (or higher?) for aarch64-darwin?

I don't know of any significant blockers.

Main blocker rn would be we can't upgrade the LLVM in the bootstraptools currently, relevant information linked from this PR.

Hopefully we don't have to update the bootstrap tools to update to a new version of llvm. The main part I don't know how to handle is the contents of this issue. For llvm that supports it, we want to use "apple-m1", but while bootstrapping from the older version (and presumably also for gcc) we'd need to provide a string the compiler understands.

@thefloweringash, you want to update stdenv LLVM without bumping the version in the bootstrap-tools?

@thefloweringash, you want to update stdenv LLVM without bumping the version in the bootstrap-tools?

I have seen nixpkgs use llvm v4 in bootstrap tools and llvm v7 in the stdenv. It should be possible to bootstrap llvm like this. I'm not advocating for it though, and in general I don't mind updating bootstrap tools more frequently if it makes things easier.


 The other pages appear to work. From playing around in the debugger, there is lots of data returned by self.stats.items()

The assert is removed in v0.5.1 by 8424d55. Try pip install django-debug-toolbar-line-profiler==0.5.1 and the assert failure shouldn't happen any more.
It's not clear to me what would cause the root function not to be detected correctly, and there may not be any actual output in the panel for your root page. If you have any additional details, I'd love to hear them.


IS-05 immediate activation of many resources

Hello,
I don't think my issue qualifies as a bug, It's more of a discussion / observation about the way nmos-cpp handles immediate activation(s). As far as I can tell (please correct me if I'm wrong) There seem to be two stages in nmos-cpp for all activation types (immediate, relative, absolute):

Handling of the user request.
When the user makes a PATCH request it is handled by cpprest. As far as I can see all it does in that context is some validation of the request, setup the staged API with the correct information and return the correct status code in a response. It also pushes the activation onto a resource update list and if the activation is immediate it notifies everyone about it.

Handling the activation
Another thread that is responsible for handling all activation's wakes up and handles any applicable items in the resource update list. As far as I can see it is responsible for activating resources at the correct time.

I could not find a clear definition for immediate activation's in the standard, but I did have a question about this earlier on the nmos-testing repo. There it became clear to me that for immediate activation's you need to guarantee that the activation is handled by the time the response is returned to the user (step 1). However the response is returned before the resource is activated (step 2).
You can probably get away with this if you only have a few resources and not al lot of overhead. However for me it goes wrong when trying to activate many resources (64 senders and 64 receivers) with immediate activation in short succession (like the nmos-testing tool does in IS-05-01 test 25).
So my question / point of discussion is simple. Is this the correct way of handling immediate activation's?
To add a foot note to this already long story (sorry about that). I know that it is far more practical for this use-case to use the bulk API. However I think it should also be possible to the single API. But again please correct me if I'm wrong.

Thanks for the well laid out question! Your understanding of the design of the nmos-cpp Connection API and activation implementation is absolutely spot on. The only thing you've missed is that (only) in the case of immediate activation requests the Connection API handler wakes up the activation thread and then blocks until it has done the activation. But if you're seeing something different then presumably there's a bug somewhere.

Really, But how does that work then? Because I don't see how it can wait. As far as I can see, from the staged route registration it calls handle_connection_resource_patch. Which in turn calls handle_immediate_activation_pending because it is an immediate activation. However that function doesn't wait or block. The set_reply is called immediately afterwards. Again correct me if I'm wrong :).

In fact, handle_immediate_activation_pending calls wait_activation_modified which waits for the activation object to be modified by the connection activation thread.

 It was mainly me not understanding how it worked. Thanks for the clarification!

It was mainly me not understanding how it worked.

If you have some hints for some useful documentation or code comments, let me know (actually, your initial description in this issue is probably a good start!!)


How to specify a summary that contains the current value of the preference

Hi, great library!
I am trying to specify a summary for preferences that always have the current value of the preference formatted by a custom formatter. My usecase for this is a preference that opens a dialog window with a NumberPicker. I want to be nice and show the currently set value. For consistency, I would also like to do that for everything else too, like for seekbars which would mean hiding the built-in value display.
Is it possible somehow?
Thanks!

This was implemented a while ago already and can thus be closed.


Laravel 8 compatibility

Hi,
is it possible to update the composer.json to allow for installations on laravel 8.
The illuminate/contracts requirement in this project is breaking the update to laravel 8:
"require": {
        "illuminate/contracts": "^5.5|^6.0|^7.0"
    },

Thanks

no

;)

@effem give it a few mins to get through to packagist.


LengthAwarePaginator last page has no links is blank

Say you have 152 items to paginate.
$this->lastPage = (int) ceil(152 / 10);  = 15.2
ceil 15.2 gives 16
so page 16 is blank only need 15 pages to paginate 152 items
namespace Illuminate\Pagination;
class LengthAwarePaginator extends AbstractPaginator implements ...
Line 49
$this->lastPage = (int) ceil($total / $perPage);
Line 49 change to
$this->lastPage = (int) floor($total / $perPage);

You need 16 pages to paginate 152 items, the 16 page will have 2 items, since you are showing 10 items per page.
If we change this when you have 12 items you'll get only 1 page instead of 2 pages,
12 / 10 = 1.2 floor would turn to 1 but you need 2 pages for this...

Hi Fernando,
I must be working to many hours.
You are right...
oops
Mike
On Wed, Jul 6, 2016 at 12:14 PM, Fernando Henrique Bandeira <
<EMAIL_ADDRESS>wrote:

You need 16 pages to paginate 152 items, the 16 page will have 2 items,
since you are showing 10 items per page.
If we change this when you have 12 items you'll get only 1 page instead of
2 pages,
12 / 10 = 1.2 floor would turn to 1 but you need 2 pages for this...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/laravel/framework/issues/14238#issuecomment-230875024,
or mute the thread
https://github.com/notifications/unsubscribe/AKQFZJlUh5ivNtk7H9-2hmn_HbTAwk55ks5qS_6pgaJpZM4JGZ4w
.

Cannot find out if this is trolling or not.


Added an extra tool for developing a package.

I added a link and description to a Yeoman Laravel package scaffolder I have written.

Thanks for accepting the pull request! 😁


ownable and pausable libraries

First attempt at Ownable and Pausable libraries for Solana programs.  These libraries provide traits and associated functions for ownership and operation control.

An Ownable program is one with a optional owner PublicKey.  The ownership can be initialized, transferred, or renounced.  There is also a function to validate if a program is owned by a given PubllicKey.
A Pausable program is one with an owner and a paused boolean.  The owner can pause and resume the program.  It is up to the program implementation to respect the paused state.

https://github.com/solana-labs/solana-program-library/blob/master/token-swap/proposals/Pausable.md

@skotep can you add an example of how do you see those two libraries being used with some tests using: program-test or solana-test-validator.


Error when creating list template type 109 (PictureLibrary)

Error when creating list template type 109 (PictureLibrary).
"Attachments are not allowed for this template type" translated to English. Setting property EnableAttachments="false" solves the problem, but that shouldn't be necessary.
Here's the XML for my list:
<pnp:ListInstance Title="Bildebibliotek" Description="" TemplateType="109" Url="Bildebibliotek" />
powershell.exe Information: 0 : 2015-12-03 10:25:15.3984        [List instances]        [7]     [Debug] Creating list Bildebibliotek failed: Vedlegg er ikke tillatt for dokumentbiblioteker og undersokelser. :    at Microsoft.SharePoint.Client.ClientRequest.ProcessResponseStream(Stream responseStream)
at Microsoft.SharePoint.Client.ClientRequest.ProcessResponse()
at Microsoft.SharePoint.Client.ClientContextExtensions.ExecuteQueryImplementation(ClientRuntimeContext clientContext, Int32 retryCount, Int32 delay)
at OfficeDevPnP.Core.Framework.Provisioning.ObjectHandlers.ObjectListInstance.CreateList(Web web, ListInstance list, TokenParser parser, PnPMonitoredScope scope)
at OfficeDevPnP.Core.Framework.Provisioning.ObjectHandlers.ObjectListInstance.ProvisionObjects(Web web, ProvisioningTemplate template, TokenParser parser, ProvisioningTemplateApplyingInformation applyingInformation)   1470ms  e8316878-76ec-40c5-a23f-284003f60bbe
powershell.exe Information: 0 : 2015-12-03 10:25:15.4013        [List instances]        [7]     [Debug] Code execution scope ended
1473ms  e8316878-76ec-40c5-a23f-284003f60bbe
powershell.exe Information: 0 : 2015-12-03 10:25:15.4018        [Provisioning]  [7]     [Debug] Code execution scope ended      2224ms       e8316878-76ec-40c5-a23f-284003f60bbe

Thanks Ole. Good catch. We'll get the exception handling included in the engine for Picture library for this. Can't make to December release (tomorrow), but we'll get this included in the Jan release.

Good stuff, @VesaJuvonen

Reopen for tracking purposes. Will close when implemented for the Jan 2016 release.

Ok @VesaJuvonen. I though you were adding issues to milestones.

It took a while, but the fix has finally been merged. Thank you for your patience.


Limit the number of open file descriptors

The default Jetty Server has an unbounded request queue and uses a
blocking I/O thread-per-connection Connector.
This commit switches to a non-blocking I/O connector and backports
the ExecutorThreadPool from the new Jetty to limit the number of
requests being serviced at any given time.
This Fixes issues where Exhibitor leaks file descriptors or opens a
potentially large number of file descriptors under heavy request
load.
Fixes https://dcosjira.atlassian.net/browse/DCOS-558
Supercedes https://github.com/dcos/exhibitor/pull/5

Wrong repo.


Add a website with perfect score to the showcase (docs/showcase)

What is it?

[ ] Feature / enhancement
[ ] Bug
[x] Docs / tests

Description
Hello again :) Recently I made my own website with Qwik.js and results are wonderful! I got a perfect score in both desktop and mobile versions. I would love to see this cutie in the showcase of Qwik docs :)
https://necatikcl.dev/
https://twitter.com/i/status/1621565438990901250

THank you so much!


refactor: GlobScanOperator do not block runtime!

https://github.com/Eventual-Inc/Daft/blob/7e89850b8b276a32119f2d59ccbeeb39dc009557/src/daft-scan/src/glob.rs#L141-L302
getting
thread 'tokio-runtime-worker' panicked at /Users/andrewgazelka/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.41.1/src/runtime/scheduler/multi_thread/mod.rs:86:9:
Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.
stack backtrace:
   0: rust_begin_unwind
             at /rustc/28a58f2fa7f0c46b8fab8237c02471a915924fe5/library/std/src/panicking.rs:662:5
   1: core::panicking::panic_fmt
             at /rustc/28a58f2fa7f0c46b8fab8237c02471a915924fe5/library/core/src/panicking.rs:74:14
   2: enter_runtime<tokio::runtime::scheduler::multi_thread::{impl#0}::block_on::{closure_env#0}<core::pin::Pin<alloc::boxed::Box<daft_scan::glob::run_glob::{async_block_env#0}, alloc::alloc::Global>>>, core::result::Result<core::pin::Pin<alloc::boxed::Box<(dyn futures_core::stream::Stream<Item=core::result::Result<daft_io::object_io::FileMetadata, daft_io::Error>> + core::marker::Send), alloc::alloc::Global>>, daft_io::Error>>
             at /Users/andrewgazelka/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.41.1/src/runtime/context/runtime.rs:68:5
   3: block_on<core::pin::Pin<alloc::boxed::Box<daft_scan::glob::run_glob::{async_block_env#0}, alloc::alloc::Global>>>
             at /Users/andrewgazelka/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.41.1/src/runtime/scheduler/multi_thread/mod.rs:86:9
   4: block_on_inner<core::pin::Pin<alloc::boxed::Box<daft_scan::glob::run_glob::{async_block_env#0}, alloc::alloc::Global>>>
             at /Users/andrewgazelka/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.41.1/src/runtime/runtime.rs:370:45
   5: block_on<daft_scan::glob::run_glob::{async_block_env#0}>
             at /Users/andrewgazelka/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.41.1/src/runtime/runtime.rs:340:13
   6: block_on_current_thread<daft_scan::glob::run_glob::{async_block_env#0}>
             at ./src/common/runtime/src/lib.rs:123:9
   7: run_glob
             at ./src/daft-scan/src/glob.rs:89:21
   8: try_new
             at ./src/daft-scan/src/glob.rs:164:25
   9: finish
             at ./src/daft-scan/src/builder.rs:108:33
  10: data_source
             at ./src/daft-connect/src/translation/logical_plan/read/data_source.rs:39:19
  11: read
             at ./src/daft-connect/src/translation/logical_plan/read.rs:26:13
  12: to_logical_plan
             at ./src/daft-connect/src/translation/logical_plan.rs:31:29
  13: {async_block#0}
             at ./src/daft-connect/src/op/execute/root.rs:34:28
  14: {async_block#0}
             at ./src/daft-connect/src/op/execute/root.rs:55:43

When executing from an async runtime. Can we make it so we don't block?
I'm thinking
fn try_new(...) should becomes async fn try_new(...)
This is similar to https://github.com/Eventual-Inc/Daft/pull/3378

Assigning @colin-ho  but unsure who is best suited for completing this. other contender based on blame is @jaychia

Feel free to make a refactor to unblock, I can review.
Is the canonical approach something like async fn async_try_new(...) + fn try_new(...) {block_on(async_try_new)}? I'm not entirely sure here, but that could maybe work

Feel free to make a refactor to unblock, I can review.
Is the canonical approach something like async fn async_try_new(...) + fn try_new(...) {block_on(async_try_new)}? I'm not entirely sure here, but that could maybe work

canonically you would just remove try_new and leave if you want to block up to the callee. For instance, if the callee wanted to block (as python should do) it could do block_on(try_new) where try_new is async

ok I will work on this


Unable to save post

Hi,
I set up Hubpress by following the doc. Everything works perfectly until I try to save a post, then I get the following message:
Remote save
Your post was not saved. See your browser's developer console for the cause of the error.
This occurs on Opera 28 and Chrome 41 under Mac OS X 10.10.3. Looking in my JS console I don't see any error.

Could you show me the content that you try to save?
The minimum requirement is a title, the following content should work:
= my title
M'y content

My mistake. I pasted an Asciidoc content starting with a second level titel for my test. I just changed it to level one and now it works.
Perhaps having a less general error message could help dumb newbies like me to to avoid this kind of error?
Anyway, thanks for this nice piece of software

Perhaps having a less general error message could help dumb newbies like me to to avoid this kind of error?

i must have a review of all the messages :smile:

Anyway, thanks for this nice piece of software

Thank you for giving it a try :+1:

I think the problem at the moment is that the "Check Console for
Information" message is applicable for a number of HubPress failures. It
would be better to add better granularity to the error messages so HubPress
can better detect the root cause of the issue given the specific set of
circumstances.
On Mon, Apr 13, 2015, 23:36 Anthonny Quérouil<EMAIL_ADDRESS>wrote:

Perhaps having a less general error message could help dumb newbies like
me to to avoid this kind of error?
i must have a review of all the messages [image: :smile:]
Anyway, thanks for this nice piece of software
Thank you for giving it a try [image: :+1:]
—
Reply to this email directly or view it on GitHub
https://github.com/HubPress/hubpress.io/issues/189#issuecomment-92354068
.


Fixed name of subdirectory in pybasicbayes module structure

pip install -e . would not work, not being able to find the "internals" submodule.
Changed what setup.py was looking for to find the correct "distributions" submodule.

Excellent, thank you!


Switch to Verify API for SMS Providers

All SMS providers have an API specifically for one-time-passwords (OTP):

Twilio

Must create a verification service in the portal

Nexmo
MessageBird

These APIs are used for generating, sending, and verifying single-use codes. You cannot send a custom code; the API must generate the code for you. As such, you must also call the verify API with the user submitted code to know whether the code is correct.
The benefits:

No need for brand/campaign registration (ex 10DLC)
No need for managing individual numbers (global reach)
Localization support

Cons:

More expensive
Less flexibility on message contents (cannot use custom code)

Security code prefix
Note that we currently add a numeric single-digit prefix to the security code to make it easier to identify which issuer the code came from. The prefix is derived from the hash of the issuer's address.
Generation
https://github.com/celo-org/celo-monorepo/blob/master/packages/sdk/contractkit/src/wrappers/Attestations.ts#L29
Usage in wallet
https://github.com/celo-org/wallet/blob/623a1cbdef2e7ea330f05a84491d1c80545f427f/packages/mobile/src/identity/securityCode.ts#L42

Do we know anything about how impactful this change is likely to be?
How will users figure out which issuer sent which code?

Great questions.

is difficult to say, but this essentially puts the onus on the SMS providers to optimize for the best way to send an SMS and ensure delivery. Our current suggestion to validators is to buy at least a US number for each service and a MessageBird Canadian number. But there are countries/carriers that would have a better success rate with local numbers and registered shortcodes. Many providers have long documentation per country on how to optimize for them, but it can be very expensive and complex to register some of these, so we have been hesitant to ask validators to do so without strong evidence that it's critical.

The SMS providers have already optimized for delivery in all countries with Verify API requests as they manage the sender. My sense is that it will greatly reduce the SMS delivery issues without us needing to expand with additional providers -- difference among providers will solely be based on the unique relationships they have established with cellular carriers and regulators rather than validator profile setup. Going this route also substantially reduces the complexity of validator configuration, hopefully reducing their operational load.

This is something I've put on Valora's radar. But the short answer is clients will not know which issuer sent a code. We will need to design for clients trying multiple issuers with a code (which they already do at a smaller scale; there can be collisions with the prefix indicator) or move to a synchronous flow. But with attestation services accepting up to 5 attempts to redeem a code, the former is an ok solution. Would love if you had any other ideas.

Can we estimate it, or put a ceiling on the expected improvement? e.g. if we're seeing X% of users fail to verify after selecting issuers, this feature can improve things by no more than X%.
It sounds like the issuers don't know the code themselves, which makes things trickier. Do they know the phone number that was used to send it? If not, I'm not sure I have any suggestions beyond the two that you've proposed, both of which sound acceptable to me.

Success rates by country (remain relatively consistent)
Traffic by country (US went down after campaign and other countries are steadily climbing)
This suggests reduction in verification success rate is likely due to greater globalization of usage in countries with poorer success rates than US (which is ~80%).

Deployed Verify for Twilio. Will prioritize measuring impact before supporting other providers.

Sounds good! The only reason it wasn't closed was to potentially include other SMS provider but like you said, we can just create new tix if/when we're ready.


Documentation: Keep only one markup language

Proposition to convert all the markdown files to rst, which means we can fully utilise Sphinx.

Motivation (from https://github.com/ROCmSoftwarePlatform/MIOpen/pull/1607#issuecomment-1169369839):
@v01dXYZ

It is not necessary to enforce rst. But I thought it would have been an amelioration to only have one markup language for the documentation (there are currently two). We can also enforce MyST instead which is as much as powerful as rst. I didn't take this path but actually it is the most efficient one as the api_reference files are the easiest to change.
In the two cases, GitHub won't be able to nicely render them.
The aim of the MR is to simplify as much as possible the docs:
* use only one markup language
* have an arborescence of files instead of a flat directory
* use sphinx directives to ameliorate the way the documentation is rendered.
I hope it would be helpful if new topics are added to the documentation in the future (such as documenting the assembly files in src/kernels or LLVM/MLIR for code generation with custom passes...).

use only one markup language

In the documentation, yes. But the developers would need to learn reStructuredText, while Markdown is already well known to all github users. So maybe this point is not an advantage (I am not objecting, just to note)

have an arborescence of files instead of a flat directory

This makes it easier for developers to find the right file. However, it will be necessary to come up with unambiguous criteria for placing files on one or another branch of the tree. Does this approach provide any other benefits?

You're right. My suggestions are a little bit too opinionated without strong arguments (file renaming, rst over md).
I should provide instead a small MR that converts the rst to md without anything else.

Proposition to convert all the markdown files to rst, which means we can fully utilise Sphinx.

Note that the implementation at #1612 does just the opposite. Maybe it worth to update the topmost comment.


create drunk mode

inputs are changed randomly

I created the drunk mode as part of the PlayerInput function and made a pull request.
The function I programmed takes the different choices the user is offered for a decision as an array. It presents the different choices to the user and asks him/her to decide by using numbers on the keyboard. It checks if the number typed in is valid (else, the user has to decide again) and if the user is drunk.
If the user is drunk, the decision will be made randomly and the user is informed that his decision has been changed due to him being drunk.
The validated, and maybe drunk-changed, user input is returned.
Let me know what you think!

the function was reviewed and merged!