LOG4J2-2858: More flexible configuration of WaitStrategy of Disruptor

LOG4J2-2858: added additional properties for setting sleepTimeNs and retries parameters of SleepingWaitStrategy

I put some comments on the mechanics of the proposed changes, but I actually have a bigger question:
what problem are we trying to solve?
Can you explain the use case where it would help to be able to fine-tune sleep time and number of retries?

What I want to achieve is to log messages with low resource consumption and at the same time garbage free (since I have low latency code in the same JVM with no gc pauses allowed). Currently, I dont see an option that satisfies these requeirements. If I use BlockingWaitStrategy or TimeoutBlockingWaitStrategy then I have garbage. If I use SleepingWaitStrategy with default parameters, YieldingWaitStrategy or BusyspinWaitStrategy then logging consumes resources that I dont want to allocate there.
If you have any other suggestions on how to handle my use case, I would be happy to use your approach.

Understood, thanks for the clarification!

Thanks for making those changes.
The system properties used in Log4j2 are documented in this section in the Configuration page of the manual: https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/configuration.adoc#system-properties
Please document the additional system properties for both the AsyncLogger prefix and  the AsyncLoggerConfig prefix, to follow the convention of the existing docs.

Thanks for making those changes.
The system properties used in Log4j2 are documented in this section in the Configuration page of the manual: https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/configuration.adoc#system-properties
Please document the additional system properties for both the AsyncLogger prefix and the AsyncLoggerConfig prefix, to follow the convention of the existing docs.

Thanks for reviewing! Documentation is added to correspondent sections

Last two builds failed in spite of the fact that my last commits were to documentation only:(

Thank you for the contribution, @stepan2271 !

Thanks, @remkop! Should I do smth to fix build? Seems like the build fails, but it is unrelated to my changes.
[INFO] Results:

[INFO]

[ERROR] Failures:

[ERROR]   TimeFilterTest.testTime:199 Time<PHONE_NUMBER>252 is not within range: start=1590915600000, end=1590919200000, timezone=America/Los_Angeles expected same:<NEUTRAL> was not:<DENY>

[INFO]

[ERROR] Tests run: 1837, Failures: 1, Errors: 0, Skipped: 12

[INFO]

Build is fixed after merge with master. @remkop could you please merge, since I don`t have write access

@carterkozak Could you also review this PR?

Sure thing, I’ll take a look tomorrow :-)

Curious if anyone has suggestions for backporting documentation to the 2.x branch? It's difficult manually transforming between adoc and rst.


Add commit comment if cannot set commit status or comment on PR

In case we don't have permissions to set commit status,
fallback to adding comment on commit
Fixes #780
Signed-off-by: Matej Focko<EMAIL_ADDRESS>TODO:

[x] Test for commit comment if cannot set commit status
[x] Refactor commenting on PRs
[x] In case we cannot comment on PR comment on commit
[x] Add test for commenting on commit

recheck


Is origin_offset_in_pixels correct?

Following up here since #14 is about something else. Using @Falcury's tool and my function to create a read_region function:
Note: This does not happen in SlideScape! Not even a minor shift. Would this be due to the calculate of the shift in um? I will implement a non-integer shift using bilinear interpolation to check
isyntax_error_t libisyntax_read_region(isyntax_t* isyntax, isyntax_cache_t* isyntax_cache, int32_t level,
                                       int64_t x, int64_t y, int64_t width, int64_t height, uint32_t** out_pixels) {

    // Get the level
    assert(level < &isyntax->images[0].level_count);
    isyntax_level_t* current_level = &isyntax->images[0].levels[level];

    int32_t level_count = isyntax->images[0].level_count;
    // Setup the origin offset
    int32_t offset = current_level->origin_offset_in_pixels;
    int PER_LEVEL_PADDING = 3;

    // int32_t offset = ((PER_LEVEL_PADDING << level_count) - PER_LEVEL_PADDING) >> level;
    x += offset + level;
    y += offset + level;

    // Check bounds
//    assert(x + width - offset <= current_level->width_in_pixels);
//    assert(y + height - offset <= current_level->height_in_pixels);

    int32_t tile_width = isyntax->tile_width;
    int32_t tile_height = isyntax->tile_height;

    int64_t start_tile_x = x / tile_width;
    int64_t end_tile_x = (x + width - 1) / tile_width;
    int64_t start_tile_y = y / tile_height;
    int64_t end_tile_y = (y + height - 1) / tile_height;

    // Allocate memory for region
    *out_pixels = (uint32_t*)malloc(width * height * sizeof(uint32_t));

    // Read tiles and copy the relevant portion of each tile to the region
    for (int64_t tile_y = start_tile_y; tile_y <= end_tile_y; ++tile_y) {
        for (int64_t tile_x = start_tile_x; tile_x <= end_tile_x; ++tile_x) {
            // Calculate the portion of the tile to be copied
            int64_t src_x = (tile_x == start_tile_x) ? x % tile_width : 0;
            int64_t src_y = (tile_y == start_tile_y) ? y % tile_height : 0;
            int64_t dest_x = (tile_x == start_tile_x) ? 0 : (tile_x - start_tile_x) * tile_width - (x % tile_width);
            int64_t dest_y = (tile_y == start_tile_y) ? 0 : (tile_y - start_tile_y) * tile_height -
                                                            (y % tile_height);
            int64_t copy_width = (tile_x == end_tile_x) ? (x + width) % tile_width : tile_width - src_x;
            int64_t copy_height = (tile_y == end_tile_y) ? (y + height) % tile_height : tile_height - src_y;

            uint32_t *pixels = NULL;

            // Check if tile exists, if not, don't use the function to read the tile and immediately return an empty
            // tile.
            int64_t tile_index = tile_y * current_level->width_in_tiles + tile_x;
            bool tile_exists = (isyntax->images[0].levels[level].tiles + tile_index)->exists;
            if (tile_exists) {
                // Read tile
                assert(libisyntax_tile_read(isyntax, isyntax_cache, level, tile_x, tile_y, &pixels) == LIBISYNTAX_OK);
                // Copy the relevant portion of the tile to the region
                for (int64_t i = 0; i < copy_height; ++i) {
                    memcpy((*out_pixels) + (dest_y + i) * width + dest_x,
                           pixels + (src_y + i) * tile_width + src_x,
                           copy_width * sizeof(uint32_t));
                }
            } else {
                // Fill up with transparent white pixels (R=255, G=255, B=255, A=0)
                for (int64_t i = 0; i < copy_height; ++i) {
                    for (int64_t j = 0; j < copy_width; ++j) {
                        (*out_pixels)[(dest_y + i) * width + dest_x + j] = 0x00FFFFFFu;
                    }
                }
            }

            // Free the tile data
            free(pixels);
        }
    }

    return LIBISYNTAX_OK;
}

Using the origin_offset_in_pixels as defined in the header, I get a big shift between level 3 and 4 (and beyond, 0, 1, 2 are fine).

If I use ((PER_LEVEL_PADDING << level_count) - PER_LEVEL_PADDING) >> level it's rather stable, but there are very minor visual shifts. You also have these shifts in level 0, 1, 2.
This is the conversion tool. If --cache-size is too small it tends to segfault, which I couldn't locate yet (I will run Valgrind, but that doesn't work on M1, so needs to wait a bit), the conversion is here: https://github.com/NKI-AI/libisyntax/blob/add-read-region/src/isyntax_to_tiff.c
The absolute offset compared to the Philips SDK is slightly annoying, because we are annotating in a platform that uses the SDK and they output absolute coordinates in level 0.

I've tried to implement bilinear interpolation, but in SlideScape it's still slowly shifting to the left across levels

isyntax_error_t libisyntax_read_region_raw(isyntax_t* isyntax, isyntax_cache_t* isyntax_cache, int32_t level,
                                       int64_t x, int64_t y, int64_t width, int64_t height, uint32_t** out_pixels) {

    // Get the level
    assert(level < &isyntax->images[0].level_count);
    isyntax_level_t* current_level = &isyntax->images[0].levels[level];

    // Check bounds
    // TODO: Figure out if the bounds are starting from x = 0 or from the offset
    assert(x + 1 <= current_level->width_in_pixels);
    assert(y + 1 <= current_level->height_in_pixels);

    int32_t tile_width = isyntax->tile_width;
    int32_t tile_height = isyntax->tile_height;

    int64_t start_tile_x = x / tile_width;
    int64_t end_tile_x = (x + width - 1) / tile_width;
    int64_t start_tile_y = y / tile_height;
    int64_t end_tile_y = (y + height - 1) / tile_height;

    // Allocate memory for region
    *out_pixels = (uint32_t*)malloc(width * height * sizeof(uint32_t));

    // Create a single empty tile when needed
    uint32_t *empty_tile = NULL;

    // Read tiles and copy the relevant portion of each tile to the region
    for (int64_t tile_y = start_tile_y; tile_y <= end_tile_y; ++tile_y) {
        for (int64_t tile_x = start_tile_x; tile_x <= end_tile_x; ++tile_x) {
            // Calculate the portion of the tile to be copied
            int64_t src_x = (tile_x == start_tile_x) ? x % tile_width : 0;
            int64_t src_y = (tile_y == start_tile_y) ? y % tile_height : 0;
            int64_t dest_x = (tile_x == start_tile_x) ? 0 : (tile_x - start_tile_x) * tile_width - (x % tile_width);
            int64_t dest_y = (tile_y == start_tile_y) ? 0 : (tile_y - start_tile_y) * tile_height -
                                                            (y % tile_height);
            int64_t copy_width = (tile_x == end_tile_x) ? (x + width) % tile_width : tile_width - src_x;
            int64_t copy_height = (tile_y == end_tile_y) ? (y + height) % tile_height : tile_height - src_y;

            uint32_t *pixels = NULL;

            // Check if tile exists, if not, don't use the function to read the tile and immediately return an empty
            // tile.
            int64_t tile_index = tile_y * current_level->width_in_tiles + tile_x;
            bool tile_exists = (isyntax->images[0].levels[level].tiles + tile_index)->exists;
            if (tile_exists) {
                // Read tile
                assert(libisyntax_tile_read(isyntax, isyntax_cache, level, tile_x, tile_y, &pixels) == LIBISYNTAX_OK);
                // Copy the relevant portion of the tile to the region
                for (int64_t i = 0; i < copy_height; ++i) {
                    memcpy((*out_pixels) + (dest_y + i) * width + dest_x,
                           pixels + (src_y + i) * tile_width + src_x,
                           copy_width * sizeof(uint32_t));
                }
            } else {
                // Fill up with transparent white pixels (R=255, G=255, B=255, A=0)
                // Create the empty tile if it doesn't exist yet
                if (empty_tile == NULL) {
                    empty_tile = (uint32_t *) calloc(tile_width * tile_height, sizeof(uint32_t));
                    for (int i = 0; i < tile_width * tile_height; ++i) {
                        empty_tile[i] = 0x00FFFFFFu; // transparent white pixels (R=255, G=255, B=255, A=0)
                    }
                }
                // Use the previously created empty tile
                pixels = empty_tile;
            }

            // Free the tile data
            if (tile_exists) {
                free(pixels);
            }
        }
    }

    return LIBISYNTAX_OK;
}

// Bilinear interpolation function
static void bilinear_interpolate(const uint32_t *src, uint32_t *dst, int64_t src_width, int64_t src_height, int64_t dst_width, int64_t dst_height) {
    float x_ratio = ((float)src_width - 1) / dst_width;
    float y_ratio = ((float)src_height - 1) / dst_height;
    for (int64_t y = 0; y < dst_height; ++y) {
        for (int64_t x = 0; x < dst_width; ++x) {
            int64_t x1 = (int64_t)(x * x_ratio);
            int64_t y1 = (int64_t)(y * y_ratio);
            int64_t x2 = x1 + 1;
            int64_t y2 = y1 + 1;

            float x_lerp = (x * x_ratio) - x1;
            float y_lerp = (y * y_ratio) - y1;

            uint32_t c11 = src[y1 * src_width + x1];
            uint32_t c12 = src[y1 * src_width + x2];
            uint32_t c21 = src[y2 * src_width + x1];
            uint32_t c22 = src[y2 * src_width + x2];

            uint32_t r11 = (c11 >> 24) & 0xFF, g11 = (c11 >> 16) & 0xFF, b11 = (c11 >> 8) & 0xFF, a11 = c11 & 0xFF;
            uint32_t r12 = (c12 >> 24) & 0xFF, g12 = (c12 >> 16) & 0xFF, b12 = (c12 >> 8) & 0xFF, a12 = c12 & 0xFF;
            uint32_t r21 = (c21 >> 24) & 0xFF, g21 = (c21 >> 16) & 0xFF, b21 = (c21 >> 8) & 0xFF, a21 = c21 & 0xFF;
            uint32_t r22 = (c22 >> 24) & 0xFF, g22 = (c22 >> 16) & 0xFF, b22 = (c22 >> 8) & 0xFF, a22 = c22 & 0xFF;

            uint32_t r = (uint32_t)((r11 * (1 - x_lerp) + r12 * x_lerp) * (1 - y_lerp) + (r21 * (1 - x_lerp) + r22 * x_lerp) * y_lerp);
            uint32_t g = (uint32_t)((g11 * (1 - x_lerp) + g12 * x_lerp) * (1 - y_lerp) + (g21 * (1 - x_lerp) + g22 * x_lerp) * y_lerp);
            uint32_t b = (uint32_t)((b11 * (1 - x_lerp) + b12 * x_lerp) * (1 - y_lerp) + (b21 * (1 - x_lerp) + b22 * x_lerp) * y_lerp);
            uint32_t a = (uint32_t)((a11 * (1 - x_lerp) + a12 * x_lerp) * (1 - y_lerp) + (a21 * (1 - x_lerp) + a22 * x_lerp) * y_lerp);

            dst[y * dst_width + x] = (r << 24) | (g << 16) | (b << 8) | a;
        }
    }
}

isyntax_error_t libisyntax_read_region_float(isyntax_t* isyntax, isyntax_cache_t* isyntax_cache, int32_t level, float offset_x, float offset_y,
                                             int64_t x, int64_t y, int64_t width, int64_t height, uint32_t** out_pixels) {
    // Calculate the required region size to perform bilinear interpolation
    int64_t req_width = width + 1;
    int64_t req_height = height + 1;

    // Call libisyntax_read_region_raw to get a region large enough
    uint32_t *raw_pixels = NULL;
    isyntax_error_t error = libisyntax_read_region_raw(isyntax, isyntax_cache, level, x - (int64_t)offset_x, y - (int64_t)offset_y,
                                                       req_width, req_height, &raw_pixels);
    if (error != LIBISYNTAX_OK) {
        return error;
    }

    // Allocate memory for the output region
    *out_pixels = (uint32_t*)malloc(width * height * sizeof(uint32_t));

    // Perform bilinear interpolation using the bilinear_interpolate function
    bilinear_interpolate(raw_pixels, *out_pixels, req_width, req_height, width, height);

    // Free the raw_pixels memory
    free(raw_pixels);

    return LIBISYNTAX_OK;
}

isyntax_error_t libisyntax_read_region(isyntax_t* isyntax, isyntax_cache_t* isyntax_cache, int32_t level,
                                       int64_t x, int64_t y, int64_t width, int64_t height, uint32_t** out_pixels) {
    isyntax_level_t* current_level = &isyntax->images[0].levels[level];
    float offset_x = current_level->origin_offset.x;
    float offset_y = current_level->origin_offset.y;
    float new_x = x + offset_x;
    float new_y = y + offset_y;

    // Call libisyntax_read_region_float with the updated x and y values
    isyntax_error_t error = libisyntax_read_region_float(isyntax, isyntax_cache, level, offset_x, offset_y,
                                                         (int64_t)new_x, (int64_t)new_y, width, height, out_pixels);

    // Return the region of size width and height
    return error;
}

Let me give an example also why I think the offset is as in the Philips description (padding_var x 2^number_of_levels) - padding_var, so 1533 for 9 levels.
This is level 1, size 4000x4000 (resized to 1000x1000) with no offset:

You can clearly see the zero-padded edge here.
This is level 1, size 4000x4000 (resized to 1000x1000) with offset 1533/2 = 766.5:

Edge is gone, to get a better idea, here is the same level but with offset 741.5:

We can do the same in level 0, but it's a bit more tricky since need a large crop, but here it is. No offset, size 8000x8000, resized to 1000x1000:

The zero-padding is there. Now, using 1533.0:

Making it slightly smaller, 1500 to see the edge:

You need to zoom in, but you see the edge.

I'd like to help test this, once I have the TIFF converter utility up and running.
@jonasteuwen I think we reading the Philips specification a bit differently though. I think you're not supposed to use the formula with the total number of levels, just the level you want to calculate the offset for. Have you tried this?
int32_t offset;
if (level == 0) {
    offset = 0;
} else {
    offset = (3 << (level - 1)) - 3;
}

@Falcury if it helps I can give you access to SlideScore, but you might have the SDK somewhere, then you wouldn’t need it?
Indeed, I have tested that, but you keep a rather large zero padded level 0. So how I understand it is that the DWT will erode the image slightly starting at level 0 which keeps eating a bit of the image if you proceed (well half of that).
The formula I use has a direct effect on cropping that in the few images I tested. The one you use shifts it slightly across levels, what I have seen, but I’ll create a few example! Is there a way to make set a location and screenshot in SlideScape so I can export them consistently? Perhaps with the console?
The only thing that remains is a fixed offset of 2048 with the three images I tested. I am trying to find something in the header that represents that. It’s worth noting though that the offset effectively crops the border, but the border is also slightly outside of the glass slide, so they might have set it that way.

This seems to keep it stable across TIFF levels. But I don't know why.
int32_t PER_LEVEL_PADDING = 3;
float offset = (float)((PER_LEVEL_PADDING << isyntax->images[0].level_count) - PER_LEVEL_PADDING) / current_level->downsample_factor;

offset -= 1.5f;

float x_float = (float)x + offset;
float y_float = (float)y + offset;

Interesting, the 1.5 pixel thing reminds be a bit of what I did in Slidescape up until recently:
https://github.com/amspath/slidescape/blob/604248f0b1f7e699db94b770c086d4a5d6b6af9b/src/isyntax/isyntax.c#L2579-L2593

Yes, it’s slightly odd, but likely a mathematical consequence of the wavelet transform used (this is definitely not the case for all wavelet transform bases). The formule I use ends up at around 5 border pixels in the lowest level. Typically you would use periodic extensions, but you don’t have that information available in gigapixels image. Symmetric padding is also an option but I suppose they used zero padding for simplicity. That can cause ringing (Gibbs phenomenon) on the borders but as they are mostly white that’s probably minor.

Yes indeed the lower values are the zero padding of the image they do to get a proper wavelet decomposition. I also don’t understand why it works you would expect it has to decrease as well…
I will test against the Philips SDK and OpenPhi.

Maybe it's a plus/minus thing, i.e. think of the formula in terms of the encoding process and doing that in reverse, instead of thinking of it in terms of the decoding process (keeping the top of the pyramid fixed) and correcting forward for each step.

Thanks for researching this so thoroughly! I have to test and try to understand what is going on using your findings, and apply the changes.
I think I may have some explanation why my incorrect formula seemed to work in Slidescape. The increasing offsets from level 0 upwards are applied in the viewer as negative offsets, which I guess works for displaying on a screen but then doesn't work for exporting as TIFF. So, I am guessing it might still be something akin to max_offset_for_level_0 - level_specific_negative_offset(level).
What I don't understand is, why are the offset differences small for level 0-1, and large for e.g. 6-7. And why are we seeing the opposite in the TIFF converted files.
Note that if I use your formula to initialize the offsets for iSyntax files, then the offsets are no longer corrected for in Slidescape.
I don't feel entirely comfortable about the floating point values, I suspect Philips' own interpretation probably also isn't using those. Maybe extracting the offsets from the coordinates of the codeblocks in the header and simply hardcoding them as a lookup could also be an option if we can't figure out the exact formula that they used.
Trying this now:
static void test_offsets(isyntax_t* isyntax, isyntax_image_t* wsi) {
	for (i32 scale = 0; scale < wsi->level_count; ++scale) {
		isyntax_level_t* level = wsi->levels + scale;
		isyntax_tile_t* tile = level->tiles;
		if (tile->exists) {
			isyntax_codeblock_t* codeblock = wsi->codeblocks + tile->codeblock_index;
			bool has_ll = codeblock->coefficient == 0;
			i32 offset;
			if (has_ll) {
				offset = get_first_valid_ll_pixel(codeblock->scale);
			} else {
				offset = get_first_valid_coef_pixel(codeblock->scale);
			}
			i32 x_adjusted = codeblock->x_coordinate - wsi->offset_x;
			i32 y_adjusted = codeblock->y_coordinate - wsi->offset_y;
			printf("level %d (tile 0,0): x=%d y=%d, offset=%d\n", scale, x_adjusted, y_adjusted, offset);
		}
	}
}

This matches the way block IDs (essentially tile_x, tile_y) are calculated from codeblock x, y coordinates.
This gives the following output on testslide.isyntax:
level 0 (tile 0,0): x=1 y=1, offset=1
level 1 (tile 0,0): x=4 y=4, offset=4
level 2 (tile 0,0): x=10 y=10, offset=10
level 3 (tile 0,0): x=22 y=22, offset=22
level 4 (tile 0,0): x=46 y=46, offset=46
level 5 (tile 0,0): x=94 y=94, offset=94
level 6 (tile 0,0): x=190 y=190, offset=190
level 7 (tile 0,0): x=510 y=510, offset=510

Also take a look at this:
per_level_padding = 3

# also see Philips' extract_block_header.py
# equivalent in isyntax.c: get_first_valid_coef_pixel()
def formula1(level):
    offset = (per_level_padding << level) - (per_level_padding - 1)
    return offset

def formula2(level, maxscale):
    offset = ((PER_LEVEL_PADDING << maxscale) - PER_LEVEL_PADDING) >> level
    return offset

num_levels = 9
offsets1 = [0] * num_levels
offsets2 = [0] * num_levels
offsets3 = [0] * num_levels
offsets4 = [0] * num_levels
for i in range(num_levels):
    offsets1[i] = formula1(i)
    offsets2[i] = formula2(i, num_levels)
    offsets3[i] = formula1(num_levels - i)
    offsets4[i] = formula2(i, num_levels) - 1.5

print(offsets1)
print(offsets2)
print(offsets3)
print(offsets4)

Output:
[1, 4, 10, 22, 46, 94, 190, 382, 766]
[1533, 766, 383, 191, 95, 47, 23, 11, 5]
[1534, 766, 382, 190, 94, 46, 22, 10, 4]
[1531.5, 764.5, 381.5, 189.5, 93.5, 45.5, 21.5, 9.5, 3.5]

Which is 'most correct'?

Thanks! We should delve deeper into it. Indeed perhaps Philips doesn’t do the conversion with interpolation, but then again they designed the format for ‘web viewing’ (following the title of their paper). So they can apply the float offset easily in the viewer, just like you did.
I do have some TIFFs converted by a converter of Philips, I can check if they remain stable across levels. Unfortunately I don’t have the original isyntax anymore.

One thing we can conclude from my findings is that the initial offset is at least approximately correct, so the offsets above are too small (maybe you need to add the offset you get from (3 << max levels) - 3 to it?

Yeah something like that. Or maybe the third option in the python code above.
In Slidescape, the following also seems to work to visually correct the iSyntax files, also seemingly fixing a remaining 0.5 pixel shift between levels 1 and 0:
float origin_offset_in_pixels = ((PER_LEVEL_PADDING << scale) - PER_LEVEL_PADDING) * 0.5f;

This would make the visual shifts for levels 0-7:
[0.0, 1.5, 4.5, 10.5, 22.5, 46.5, 94.5, 190.5, 382.5]

From this, it seems indeed that some interpolation may be needed to have it fully stable without any shifts.
For constructing a TIFF, I guess we can get away with sampling only level 0 and downsampling to reconstruct the rest of the pyramid?
But, if this is indeed what is happening, this leads to some questions on how to proceed for querying tiles in iSyntax files? Do we simply round to whole pixel coordinates, accepting that this leads to a small discrepancy between levels 0 and 1? Or do we always interpolate either level 0 or everything above?

I think we would need the interpolation otherwise you would not be able to do cell detection at different resolutions

@Falcury I see in your latest SlideScape release you mention 'fixing offsets'. Does it mean you've changed it to the above? I can test it against the SDK.

@Falcury I see in your latest SlideScape release you mention 'fixing offsets'. Does it mean you've changed it to the above? I can test it against the SDK.

If I remember correctly, I mainly changed the code in Slidescape so that it's in sync with libisyntax, which included our work on identifying the offsets. (Slidescape renders the iSyntax levels at offsetted positions.) I think I put this part on a separate line in the release notes because it's something that is noticable by the user, instead of just refactoring.

I remember you mention there might be an offset tag available in tiff?

I think you're referring to the discussing under https://github.com/amspath/libisyntax/pull/18?

Gentleman-
Hello and a very tardy comment on iSyntax tile offset.
Philips was using iSyntax wavelet compression in their Radiology products, but likely never anticipated a tiled, multi-layer format, such as WSI.
There is a caveat in their own 2014 IntelliSpace User Guide (attached) regarding high-resolution mammograms:

"After receipt of such images in IntelliSpace PACS, when the iSyntax technology is applied, the wavelet representation of the discontinuity created by the applied pixel padding value can result in the presentation of the white outline when the image is viewed at a zoom value of 50% or less. This does not occur when the image is viewed at a zoom value of greater than 50%.
This type of discontinuity can never occur in anatomy. The outline is caused by artificial pixel padding values, and appears outside of the breast tissue alongside the outer edge of the breast. The image quality is not affected by this problem. "

(https://github.com/amspath/libisyntax/files/14971752/IntelliSpace_PACS_Enterprise_with_iSyntax_User_Guide_2014.pdf)
As long as Philips restricted the use of iSyntax to tile-less images, the assumption was that the radiologist would quickly adapt to the surreptitious white padding.
Thank you for all your great work on SlideScape and libisyntax!


Support otherName SAN type

We need to support the generation of Certificates containing the otherName SAN type.
This is still used in some traditional systems to indicate unique identity, it is usually just an email UPN but we can be fairly generic.
Currently we only support the most common subset of SANs, SANs are "GeneralName" types:
   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

   EDIPartyName ::= SEQUENCE {
        nameAssigner            [0]     DirectoryString OPTIONAL,
        partyName               [1]     DirectoryString }

From https://datatracker.ietf.org/doc/html/rfc5280#section-<IP_ADDRESS>
We've currently "deconstructed" the type and offered straight array string Certificate types to represent the most common: dns, email, ip,uri are available, however some legacy systems like ldap still leverage the otherName type.
Unfortunately otherName is a complicated type in that it is an escape hatch that allows the setting of arbitrary oids:
   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

The most common use case is the UPN otherName type, meaning the type-id is set to:
<IP_ADDRESS>.4.1.3<IP_ADDRESS> UPN (which actually just means a valid rfc0822 email address..)
and the actual format type is just a string.
You might wonder why not just use email SAN (which are rfc822Names), but this is the pattern established by microsoft AD servers for LDAP: https://4sysops.com/archives/understand-the-upn-and-samaccountname-user-account-attributes/
Describe the solution you'd like
I propose we continue the tradition of decomposing the generalName attribute and keep doing these niche SANs in a case by case basis, for example we can add a Certificate field called:
otherNameSANs, we can easily get a fair bit of extensibility while hitting our use case by making that a struct of type:
type otherNameSANs []struct{
  type-id string (can be upn, or oid:some.oid.value)
  value string
}

Describe alternatives you've considered
One possible alternative would be to just add a UPN SANs field for example:
type upnSANs []string
and these could be directly encoded as otherName UPN values.. this would accomplish our objective but might be less forward compatible with any future otherName types we could require, we know at least of one other type that "exists" like DNS SRV RR otherName although we're not clear if it's still in use.
Additional context:

we've done a bit of research of the different generalNames around and came to this analysis:
otherName -> TBD: UPN

x400Address has been kind of discontinued since 2006
ediPartyName is used by US Dept of Defense smart cards (https://news.ycombinator.com/item?id=25350821)
registeredID -> ??
directoryName -> ??
We looked at the subset that ACM's api uses for example and it includes some of these obscure types:
https://docs.aws.amazon.com/privateca/latest/APIReference/API_GeneralName.html
where they do include the additional directoryName EdiPartyName registerID and otherName types but also ignore x400Address.

smallstep have built this particular generalName implementation here

/kind feature

Fixed in
https://github.com/cert-manager/cert-manager/pull/6404
https://github.com/cert-manager/cert-manager/pull/6620
The feature is documented here:
https://github.com/cert-manager/website/pull/1378


Bug in llama example

I noticed there is a bug in the llama example:
error[E0599]: no method named `head_size` found for reference `&Config` in the current scope
  --> examples/llama/mod.rs:61:36
   |
61 |             .get((cfg.seq_len, cfg.head_size() / 2), "freq_cis_real")
   |                                    ^^^^^^^^^ method not found in `&Config`

error[E0599]: no method named `head_size` found for reference `&Config` in the current scope
  --> examples/llama/mod.rs:64:36
   |
64 |             .get((cfg.seq_len, cfg.head_size() / 2), "freq_cis_imag")
   |                                    ^^^^^^^^^ method not found in `&Config`

error[E0599]: no method named `head_size` found for reference `&Config` in the current scope
  --> examples/llama/mod.rs:66:59
   |
66 |         let cos = freq_cis_real.reshape((cfg.seq_len, cfg.head_size() / 2, 1))?;
   |                                                           ^^^^^^^^^ method not found in `&Config`

error[E0599]: no method named `head_size` found for reference `&Config` in the current scope
  --> examples/llama/mod.rs:67:59
   |
67 |         let sin = freq_cis_imag.reshape((cfg.seq_len, cfg.head_size() / 2, 1))?;
   |

It appears there is no method head_size, perhaps it was removed?
Thanks!

Could this be the n_heads member instead?


HV-862 ExecutableHelper#overrides() should take visibilities into acc…

…ount
This is already working. The commit adds a test.
https://hibernate.atlassian.net/browse/HV-862

Is there some other use case to consider?

No, I think that's the one.

Thinking about it, one edge case remains: A super-type declaring a package-private method (default visibility), and a sub-type in another package specifies a method with the identical signature. This is no method overriding, but I suppose the current code would not handle this correctly.

I'll have a look

I added a commit to test the package-private use case

Rebased and applied. Thanks, @DavideD!


Dockerfile.* are outdated, using old ubi image

https://github.com/quarkus-qe/quarkus-test-framework/tree/main/quarkus-test-images/src/main/resources
Using FROM registry.access.redhat.com/ubi8/ubi-minimal:8.3 instead of 8.4
There might be more inconsistences, please check with the newer versions of Dockerfile.* generated by code.quarkus.

let's wait for 8.5, it should come with Java 17 too


@Persisted breaks EmbeddedObject lists

How frequently does the bug occur?
All the time
Description
The following program (called by Program.main()):
import Foundation
import RealmSwift

class Parent: Object {
    @objc dynamic var id: String = ""
    let children = List<Child>()

    override class func primaryKey() -> String? {
        "id"
    }
}

class Child: EmbeddedObject {
    @Persisted var name: String = "child"
}

class Program {
    static func main() {
        _ = Program()
    }

    private let realm: Realm = {
        let config = Realm.Configuration(fileURL: nil, inMemoryIdentifier: "mem", syncConfiguration: nil, encryptionKey: nil, readOnly: false, schemaVersion: 1, migrationBlock: nil, deleteRealmIfMigrationNeeded: true, shouldCompactOnLaunch: nil, objectTypes: nil)
        let realm = try! Realm(configuration: config, queue: nil)
        return realm
    }()

    private init() {
        step1()
        step2()
    }

    private func step1() {
        let parent = Parent()
        parent.id = "13"
        let child = Child()
        parent.children.append(child)
        try! realm.write {
            realm.add(parent)
        }
        print("step1: parent has \(parent.children.count) children.")
    }

    private func step2() {
        let parent = realm.object(ofType: Parent.self, forPrimaryKey: "13")!
        print("step2: parent has \(parent.children.count) children.")
    }
}

prints correctly
step1: parent has 1 children.
step2: parent has 1 children.

However, if I change the line
@objc dynamic var id: String = ""

to
@Persisted var id: String = ""

it prints
step1: parent has 1 children.
step2: parent has 0 children.

This means that a list of EmbeddedObjects is unusable if the containing object uses @Persisted properties instead of @objc dynamic properties. Note that the List itself is defined in the same way in both programs.
I could reproduce it in v10.15.1 as well as in v10.19.0.
I used an iPhone with iOS 14.8 and an iPhone with iOS 15.0.2.
(in total 4 combinations of realm-version and iOS-version)
Stacktrace & log output
No response
Can you reproduce the bug?
Yes, always
Reproduction Steps
No response
Version
10.19.0
What SDK flavour are you using?
Local Database only
Are you using encryption?
No, not using encryption
Platform OS and version(s)
iOS 14.8 and iOS 15.0.2
Build environment
Xcode version: 13.0 (13A233)
Dependency manager and version: carthage 0.38.0
iOS deployment target: 14.0
called from a SwiftUI "Hello world" app.

You need to mark both id and children with @Persisted.

So, what is the purpose of @Persisted? For me it acted as a trap to fall into. Other than that, what is the advantage of using it?

@michaelpeternell @Persisted is another way to model your data, is cleaner and easier to implement.
All properties are declared the same way, no longer having to remember that some types required @objc dynamic var and easier for declaring Optionals, and primary key (no longer overriding primaryKey() and returning a string with the name of the property which is not type safe).
We are supporting both types of data modeling for the foreseeable future, but we don't support mixing both old style and new style within the same class, so if you are migrating your Child embedded Object to the new syntax you should migrate your parent object as well.
class Parent: Object {
    @Persisted(primaryKey: true) var id: String = ""
    @Persisted var children = List<Child>()
}

class Child: EmbeddedObject {
    @Persisted var name: String = "child"
}

I close the issue as the problem is solved. If you have any further questions please open another issue here or on community forum


Getting the  CalledProcessError when running poetry install

I ran poetry install and got the following error
• Updating nbdev (1.2.8 -> 1.2.9 c151342): Failed

  CalledProcessError

  Command '['git', '--git-dir', '/home/jt/.cache/pypoetry/virtualenvs/geowrangler-U9oiUrW5-py3.9/src/nbdev/.git', '--work-tree', '/home/jt/.cache/pypoetry/virtualenvs/geowrangler-U9oiUrW5-py3.9/src/nbdev', 'checkout', 'c15134220b4d6b96dd67952e27a57a8e5c1bf4c3']' returned non-zero exit status 128.

  at ~/.poetry/lib/poetry/utils/_compat.py:217 in run
      213│                 process.wait()
      214│                 raise
      215│             retcode = process.poll()
      216│             if check and retcode:
    → 217│                 raise CalledProcessError(
      218│                     retcode, process.args, output=stdout, stderr=stderr
      219│                 )
      220│         finally:
      221│             # None because our context manager __exit__ does not use them.

This error also came up once we merged #30 to master https://github.com/thinkingmachines/geowrangler/runs/6833093902 but not  when the PR was reviewed: https://github.com/thinkingmachines/geowrangler/actions/runs/2453771035

Short term workaround is to locally revert  013ad01d via git checkout 013ad01d~ pyproject.toml poetry.lock


Add and improve peers tab address fields dev notes and tooltips

Per translator feedback in this thread: https://github.com/bitcoin-core/gui/pull/526#discussion_r809237830
"The lack of string context in Transifex is a real problem for this project, as proper context (dev notes and/or screenshots) are essential to achieve quality translations."
This pull adds developer notes for transifex translators via extracomment tags, and it improves the existing ones and their tooltips with more context, clarity and completeness for the following peer tab fields as a follow-up to #526:

address relay
addresses processed
addressed rate-limited

It looks like only six lines of diff, but they are loooong lines.
If this is the right direction, the same can be done for other fields in follow-ups.

Updated per @promag feedback (thanks!)

ACK bcd72ef
in reference to the translator comment documentation I've prepared: in 1df9daa you allude to what the value of the field is, I wonder if I should include that point as required context in the doc.

Describing the value of the field where relevant and helpful seems like a good idea.

If you retouch, and definitely not necessary, you could rename the PR to Add and improve peers tab address translator comments and tooltips and similarly update the commits to state they are updating translator comments instead of extracomment.

Done!


Readme doesn't mention if this has been merged into okhttp proper or if it's a separate thing

For beginners it's unclear what they should use for websockets, as this is a separate repo and marked as experimental.
Discussions on websockets in oktttp issues page are rather lenghty, so it would be helpful to people lending on the this repo directly if the README could clarify how this repo relates to okhttp discussions in the main repo.

Ok, I know see that (https://github.com/square/okhttp/tree/master/okhttp-ws)  is maybe not a separate repo but a separate README inside of the main http repo?
This is a bit confusing to me :)

At the moment OkHttp’s websockets are experimental. What else would you like to know?


.hljs class not getting applied to root container.

I'm using highlight.js with marked.js in a preact environment to add some syntax highlighting. It seems though that the root class of hljs is not being applied to the root node that highlight returns.

@pmkroeker, we've probably need a bit more context to see what's going on. Do you have some sample code somewhere?

I was using it with markedjs, and I think it was something with how marked was parsing things. I'll close this issue as I think its probably more of a marked thing than highlight


Add documentation for new database migrations.

As the title says. :)

First draft is available under concepts/database/migrations on the database branch in the serverpod documentation repo. Since we are still planning to change the file format that is not documented correctly yet.


Figure out the time unit in kFcitx5NotificationTimeout

In https://github.com/openvanilla/fcitx5-mcbopomofo/pull/116 we introduced a constant (of value 1000) that passed to fcitx5's Notifications::showTip. From the source ^1 the parameter doesn't seem to be used other than be logged, and it's not clear what time unit is that, though millisecond seems to be the only reasonable guess given the magnitude. Filing this as a TODO.

In showTip, parameter timeout is passed to sendNotification.
    lastTipId_ = sendNotification(
        appName, lastTipId_, appIcon, summary, body, actions, timeout,
        [this, tipId](const std::string &action) {
      ...
    }

https://github.com/fcitx/fcitx5/blob/master/src/modules/notifications/notifications.cpp#L206
Inside sendNotification, timeout is passed to the message object, with Message &Message::operator<<.
    auto message =
        bus_->createMethodCall(NOTIFICATIONS_SERVICE_NAME, NOTIFICATIONS_PATH,
                               NOTIFICATIONS_INTERFACE_NAME, "Notify");
    ...

    message << appName << replaceId << IconTheme::iconName(appIcon) << summary
            << body;
    message << actions;
    message << dbus::Container(dbus::Container::Type::Array,
                               dbus::Signature("{sv}"));
    message << dbus::ContainerEnd();
    message << timeout;

https://github.com/fcitx/fcitx5/blob/master/src/modules/notifications/notifications.cpp#L158
The operator<< is used to append the operand to dbus. Basically, this cpp file defines all kinds of operator<< to pack different types. In particular, timeout is an int32_t, hence it goes to the macro:
#define _MARSHALL_FUNC(TYPE, TYPE2)                                            \
    Message &Message::operator<<(TYPE v) {                                     \
        if (!(*this)) {                                                        \
            return *this;                                                      \
        }                                                                      \
        FCITX_D();                                                             \
        d->lastError_ = !dbus_message_iter_append_basic(                       \
            d->iterator(), DBUS_TYPE_##TYPE2, &v);                             \
        return *this;                                                          \
    }

_MARSHALL_FUNC(int32_t, INT32)

https://github.com/fcitx/fcitx5/blob/master/src/lib/fcitx-utils/dbus/libdbus/message.cpp#L284

Now, let's move our focus back to notifications.cpp
#define NOTIFICATIONS_SERVICE_NAME "org.freedesktop.Notifications"
#define NOTIFICATIONS_INTERFACE_NAME "org.freedesktop.Notifications"
#define NOTIFICATIONS_PATH "/org/freedesktop/Notifications"

    auto message =
        bus_->createMethodCall(NOTIFICATIONS_SERVICE_NAME, NOTIFICATIONS_PATH,
                               NOTIFICATIONS_INTERFACE_NAME, "Notify");

https://github.com/fcitx/fcitx5/blob/master/src/modules/notifications/notifications.cpp#L17
This leads us to the Table 6. Notify Parameters in Desktop Notifications Specification.
Table 6. Notify Parameters

expire_timeout	INT32
The timeout time in milliseconds since the display of the notification at which the notification should automatically close.

If -1, the notification's expiration time is depend

https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html
I hope this helps!

Btw, there are a few simpler examples on Arch wiki that explain how this works. The C example is quite close to what notifications.cpp and message.cpp are doing. The only difference is that fcitx encapsulated dbus message objects in messages.cpp.
https://wiki.archlinux.org/title/Desktop_notifications#C

Ah! I failed to notice that the << operator was actually used to build a message, not logging. Just added 62d07769f2c16ce93f06e87b1756d90e3055255c to clarify the time unit used, and I learned a lot from this. Thanks for such a detailed walkthrough!

No worries , this is basically a builder pattern in C++'s confusing operator overloading.


If the parameter of an anonymous function in interface is an empty object, it can match any object.

🙁 Actual behavior
    type p = { (props: {}): any; } extends { (props: { visible: boolean } ): any } ? true : false // excepted false but is true

🙂 Expected behavior
    type p = { (props: {}): any; } extends { (props: { visible: boolean } ): any } ? true : false // false

Search
This type will be false, so the {} is not extends { visible: boolean }
type e = {} extends { visible: boolean } ? true : false

This is correct because function parameters are contravariant.  If the requirement is that your function can accept a { visible: boolean } then one that accepts any object at all also works.

Likewise, ((x: number) => void) extends ((x: 1 | 2 | 3) => void) is also true even though number extends 1 | 2 | 3 is false.

@fatcerberus
Thanks.
It's may unacceptable in some condition.
I want the function must have some parameters but it can run with no parameters now. I know this is legal in Js, but I use Ts now. If this is correct it seems losing the meaning of Ts.  or may I have some methods to do the check?

If you ask me for a function that accepts an A as a parameter, I can give you one that accepts A | B.  That’s desirable and doesn’t weaken typechecking because you can still only pass As through the original reference.  Same thing here - just because you get a function that accepts {} doesn’t mean you’re allowed to call it with anything other than ( visible: boolean }.

@fatcerberus
Thanks, can you give me some advice for this condition? I have no idea how to do it = =.
I wrote a function that intend to accept React Function-Component that must have visible props as parameter.
Any other Function-Component that has no-matched parameters ts will give a type error tip, but the type of  Function-Component default is FC<{}> so ts don't show any tip for me.
type FC
 = FunctionComponent
;

interface FunctionComponent
 {
    (props: P, context?: any): ReactElement<any, any> | null;
    ...
}

function giveMeFuntionComponent<T extends { visible: boolean }>(com: FC<T>) {}

const Component: FC = props => { return

 }

giveMeFuntionComponent(Component) // no error.


BUG: PR Previews have some rough edges

There are currently 2 outstanding issues with the PR preview system:

For the coverage report preview, the report should be created only when the coverage tag is added. However, the action which makes the "publishing" of these preview possible is<EMAIL_ADDRESS>doesn't recognize the labeled action as something it needs to act upon. As such it skips the event. It generates the report after another commit is made/ the branch is force-pushed. I can see only a handful of ways to fix this:
i. Open an issue on the repository and wait for a fix. It might take a long time
ii. Fork the action and modify it ourselves. This will take time away from working on the interpreter.
iii. Somehow work around it. Currently I have no idea how.
iv. Change the coverage report to be generated if the tests directory has a modification. (Or perhaps if tests or src is modified). I talked about it with @valexandru , and I think we had a reason why we wanted it on-demand but my memory fails me right now.
If a coverage report and a requirement preview is requested at the same time, only one link will be displayed in the preview message. This is once again a limitation of the action. I can see only a handful of ways to fix this:
i. Open an issue on the repository and wait for a fix. It might take a long time
ii. Fork the action and modify it ourselves. This will take time away from working on the interpreter.
iii. Somehow work around it. Currently I have no idea how.
Only accessible through the PR. I don't know if this is a massive issue, but thought I'd mention it, as a limitation.

Problem no. 2 is still not solved.
Also, there is another issue. The main deployment mechanism seems to be failing: https://github.com/DLR-FT/wasm-interpreter/actions/workflows/pages_deploy_main.yaml
It seems to be failing  due to some sort of branch protection rule.


timeout not increasing above 34s

Hi,
I'm having issues syncing my wallet using electrs 0.9.2 - from Sparrow log I can see there is a timeout which is not increasing above 34s. I had similar issues connecting from my Dojo to electrs and I had to bump the timeout as well to make it working. Note that the timeout from Dojo to electrs was enough with electrs 0.9.0 but it seems to me 0.9.2 needs much more time. I replicated this on two devices and different installations. The only logical solution for my case seems to be increase the timeout above the 34s.
2021-11-14 15:04:17,810 WARN [Thread-232] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 8 secs
2021-11-14 15:04:36,957 WARN [Thread-236] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 16 secs
2021-11-14 15:04:55,459 WARN [Thread-235] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:06:26,182 WARN [Thread-232] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:07:02,384 WARN [Thread-233] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:07:36,435 WARN [Thread-236] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:08:12,936 WARN [Thread-235] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:08:56,537 WARN [Thread-234] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:09:33,939 WARN [Thread-232] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:10:10,141 WARN [Thread-233] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:10:44,192 WARN [Thread-236] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:11:20,694 WARN [Thread-235] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:12:04,294 WARN [Thread-234] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:12:41,702 WARN [Thread-232] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:13:17,904 WARN [Thread-233] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:13:51,955 WARN [Thread-236] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-14 15:14:28,456 WARN [Thread-235] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs

The problem with increasing timeouts beyond a certain point is that the server is already in trouble if you need to wait half a minute for it to return data from a single request. At some point Sparrow needs to give up and tell the user things haven't worked - otherwise, it appears that Sparrow itself is broken.

Note that the timeout from Dojo to electrs was enough with electrs 0.9.0 but it seems to me 0.9.2 needs much more time.

This is strange - v0.9.2 contains several optimizations that should improve performance rather than reduce it. Certainly no request should take this long - I think there is a problem there. Can you add an issue under the Electrs Github issues? @romanz

Upgraded to 0.9.3 and I still have the same issues however I noticed that even when Sparrow timeouts from electrs, electrs is still running and getting the txs. See to following timeline and take note there is an hour difference because of different TZ.
2021-11-20 15:25:04,091 WARN [Thread-344] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 8 secs
2021-11-20 15:25:17,069 WARN [Thread-347] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 16 secs
2021-11-20 15:44:48,665 WARN [Thread-11] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 8 secs
2021-11-20 15:45:00,366 WARN [Thread-14] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 16 secs
2021-11-20 15:45:40,450 WARN [Thread-11] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-20 15:46:16,651 WARN [Thread-12] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-20 15:46:53,154 WARN [Thread-14] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-20 15:47:36,756 WARN [Thread-13] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-20 15:48:10,809 WARN [Thread-16] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2021-11-20 15:48:48,211 WARN [Thread-11] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs

Killed Sparrow here, electrs continues getting the txs
[2021-11-20T14:49:31.029Z DEBUG electrs::status] 2 transactions from 2 blocks
[2021-11-20T14:49:31.124Z DEBUG electrs::status] 2 transactions from 2 blocks
[2021-11-20T14:49:31.124Z DEBUG electrs::p2p] loading 1 blocks
[2021-11-20T14:49:31.180Z DEBUG electrs::status] 2 transactions from 2 blocks
[2021-11-20T14:49:31.183Z DEBUG electrs::p2p] loading 1 blocks
[2021-11-20T14:49:31.267Z DEBUG electrs::p2p] loading 1 blocks
[2021-11-20T14:49:31.326Z DEBUG electrs::p2p] loading 1 blocks
[2021-11-20T14:49:31.404Z DEBUG electrs::status] 2 transactions from 2 blocks
[2021-11-20T14:49:31.404Z DEBUG electrs::p2p] loading 1 blocks
[2021-11-20T14:49:31.495Z DEBUG electrs::status] 2 transactions from 2 blocks
[2021-11-20T14:49:31.495Z DEBUG electrs::p2p] loading 1 blocks

I'm not sure if I understand the logs correctly but it seems to me that there's either lack of communication between client and server or Sparrow is just impatient and doesn't wait for electrs to finish.

Could you please share the following Prometheus statistics:
$ curl -s localhost:4224 | grep 'rpc_duration_sum'
$ curl -s localhost:4224 | grep 'rpc_duration_count'

Also, could you please test how much time does it take to sync the history of the xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy wallet?

rpc_duration_sum{method="blockchain.headers.subscribe"} 0.006721908
rpc_duration_sum{method="blockchain.scripthash.get_history"}<PHONE_NUMBER>309994

rpc_duration_count{method="blockchain.headers.subscribe"} 31
rpc_duration_count{method="blockchain.scripthash.get_history"} 10550

Also, could you please test how much time does it take to sync the history of the xpub6BiVtCpG9fQPxnPmHXG8PhtzQdWC2Su4qWu6XW9tpWFYhxydCLJGrWBJZ5H6qTAHdPQ7pQhtpjiYZVZARo14qHiay2fvrX996oEP42u8wZy wallet?

27 seconds, 108 txs if that's correct (you mention 109 in the link)

I think I identified the issue. Electrs can serve only one wallet at a time, right? Correct me if I'm wrong here @romanz but when I open Sparrow, all four accounts start finding transactions at once.
I tried to import just one account as an Watch Only Wallet and everything went just fine. So it seems to me when I open the wallet the usual way, all four accounts just interrupt each other until Sparrow gives up?
I found out because when I tried to import xpub in Dojo and opened Sparrow, the import process Dojo was running got interrupted.

Sparrow is just impatient and doesn't wait for electrs to finish.

This is probably true for this case, but it's also possible that certain requests never return, so having a sane timeout is important to handle connectivity errors.

Electrs can serve only one wallet at a time, right?

Electrs can serve many wallets at once - from Electrs' POV, there are no differences between one wallet and another (it just sees things like script hashes and txids as inputs). Sparrow opens one TCP connection to the server, and sends requests to Electrs sequentially in order to receive the right response for the right request.

I tried to import just one account as an Watch Only Wallet and everything went just fine.

All Whirlpool users using Sparrow are using multiple accounts (sometimes with many addresses subscribed due to large postmix accounts), so Electrs handling multiple accounts is common.
Have you observed the the process activity on the Dojo with top? Possibly there are other processes or hardware limitations causing performance issues.

I even tried to use the electrs with Sparrow when all other Nodl apps are disabled.
The only difference I'm sure of now is that syncing the postmix account alone works just fine but with the other 3 accounts it just doesn't work. Even from observing electrs logs I can tell that the postmix account is looping in circles until Sparrow gives up.

it's also possible that certain requests never return

In practice much less likely than requests taking long time.

so having a sane timeout is important to handle connectivity errors

A "sane" timeout is a function of complexity of the request. Either Sparrow should make smaller requests or it should increase timeout with the size of the request. Alternatively, if a user can set the timeout it can help users who know to have large wallets.
Or not having a timeout and letting user cancel the request can work - wallets are by their nature interactive.

Electrs can serve many wallets at once

Yes and no. It has to communicate with Bitcoin Core which is a bottleneck so some requests have to wait for other requests.

Sparrow opens one TCP connection to the server, and sends requests to Electrs sequentially in order to receive the right response for the right request.

Do the latter requests have increased timeout?

In practice much less likely than requests taking long time.

It was quite regular in the 0.8.x series that requests didn't return when several hundred addresses were subscribed. I expect this to be much better now, but Tor is still an unreliable communication layer in any event.

it should increase timeout with the size of the request

Sparrow increases the timeout with the size of the batched request, adding another 50ms for each additional item in a batched request.

Do the latter requests have increased timeout?

Not sure I follow the question. Sparrow retries requests with an incrementally increased timeout if they fail to return in time, up to a point (34 secs).

Would it be possible to make timeouts configurable (at least from a config file or command line) so that people can try different values and see what works?

Not sure I follow the question.

If Sparrow makes a request and then queues another one does the other one have timeout increased by the timeout of the previous?

Would it be possible to make timeouts configurable (at least from a config file or command line) so that people can try different values and see what works?

It would be possible yes, I'll look into this. Currently it's an array of integers for the timeouts in seconds - I think what makes the most sense is to have  a configurable additional value which can be appended onto the end of the array for a maximum timeout value.

If Sparrow makes a request and then queues another one does the other one have timeout increased by the timeout of the previous?

Ah! Yes, it does.

Implemented in 8b42399.
Sparrow's config file now contains the field maxServerTimeout which is by default set to 34s. Sparrow will still start with shorter timeouts as it currently does, but if these are breached the timeout is increased until the configured maximum, where it will remain for the duration of the connection.


NVDA doesn't announce matTooltip in IE 11

Bug, feature request, or proposal:
Bug
What is the expected behavior?
matTooltip text should be announced by screen reader when associated control is focused.
What is the current behavior?
In IE 11 matTooltip text is not read by NVDA.
What are the steps to reproduce?
https://stackblitz.com/edit/angular-5axarj
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular 6.0.9
Material 6.4.0
Browser: IE 11
Screen Reader: NVDA 2017.4

I can reproduce the issue as well. @jelbourn by the looks of it, the issue is with the AriaDescriber which has display: none and aria-hidden that cause IE not to read out the messages (for reference). We can hide the element using cdk-visually-hidden, but if we were to remove the aria-hidden, the messages will now become part of the page, which means that they'll be read out when the user uses the arrow keys. I don't see a nice way around it, aside from only adding aria-hidden on non-MS browsers.

What happens if the parent element has aria-hidden="true" and the child description has aria-hidden="false"?

The message doesn't get read out in this case either.

Yeah, this seems like a case where it makes sense to do something different for IE11 then.

Any idea when a fix for this will be merged?


508 Compliance for Okta

Problem statement
We want to be sure that we are in compliance with Section 508 of the Rehabilitation Act
What you need to know

Link to the Section 508 website
Section 508 Compliance Testing Checklist
...

Acceptance criteria

[ ] RS Section 508 Checklist

To do

[ ] Draft a checklist
[ ] Review this checklist with the team

Link to Okta compliance page on 508 regulation


Remove trailing '.' from descriptions

Blender RNA_def_property_ui_text emits warnings when the descriptions string ends with a '.'
For example:
RNA_def_property_ui_text: 'path_aov_image' '' description ends with a '.' !
RNA_def_property_ui_text: 'rmantree_choice' '' description ends with a '.' !
RNA_def_property_ui_text: 'path_display_driver_image' '' description ends with a '.' !
I have removed the trailing '.' from the descriptions to prevent polluting the blender log with these warning messages.

Sorry, I submitted this too soon. There are still many more generated descriptions that I need to find. I will close this and resubmit when it is ready.


Odd behaviour of IndexStyle() with Nullable Arrays

In IJulia using Julia 0.6.0-rc3  if I write in the first cell with a newly started kernel:
#Pkg.add("NullableArrays")
using NullableArrays
A = NullableArray([1.]);

and then in the next cell:  IndexStyle(A) I get a response:  IndexLinear()
But if I drop the semi-colon suppressing the output:
#Pkg.add("NullableArrays")
using NullableArrays
A = NullableArray([1.])

and then in the next cell:  IndexStyle(A) I get a response:  IndexCartesian()
I do not get the same behaviour in the REPL, it always returns IndexLinear()
I have gert the same behaviour on JuliaBox using Julia 0.6.0-rc2

Interesting, I can reproduce this.  @yuyichao, I'm guessing it is some kind of world-age problem, possibly a bug in Julia itself?

I also cannot get a view of a NullableArray to display in IJulia which might be related.  My amateur attempt to track down why, revealed the IndexStyle issue from inspection of the SubArray type parameters.

Seems like this issue is not reproducible these days?


android, notif: Narrow to conversation on click even if app is in bg.

Notify react about the notification when app is:

in forground and notification comes (LifecycleState = RESUMEND)
when user is using app and notification comes
in background and notification comes (LifecycleState = BEFORE_RESUME)
when user is not using app. But app is present in the recent apps.

and finally launch (bring app to foreground)
MainActivity after emiting event.
Fixes #3582

Thanks @jainkuniya !
Can you say a bit more about what you learned from debugging?
Also, this change appears to do two things:

When the lifecycleState is BEFORE_RESUME, we'd previously not emit, and would launchMainActivity. Now we'll emit, and then launchOrResumeMainActivity.
When the lifecycleState is RESUMED, we'd previously emit, and would not launchMainActivity. Now we'll emit and then also launchOrResumeMainActivity.

Is the change in the RESUMED case intentional?

Can you say a bit more about what you learned from debugging? This doesn't appear to answer that question to any greater degree than the previous version did :slightly_smiling_face:
There are a number of comments I'd make on the specifics of this implementation. But it's premature to get into the details of a solution before being clear about what we think the problem is.

Problem is:
On master, we are only emitting event to react if LifecycleState == RESUMED, which only works in one scenario, i.e user is using App and notification comes (in this case LifecycleState is RESUMED).
But what if LifecycleState is BEFORE_RESUME, i.e user was using Zulip app few minutes back and currently on other app (Zulip app is present in the recent apps). In this case we weren't notifying react. We were just launching activity, which is more sort of bringing activity to foreground (as we have set activity to have single instance).
So now I am notifying react every time except when app is in the state of BEFORE_CREATE, because in this case activity will be created and react will go in the flow of initialNotification.

Cool, thanks!
From that diagnosis, it seems like the case where we want to change the behavior is where the lifecycleState is BEFORE_RESUME. The existing behavior is correct in the other cases, right?
This branch (and the single main commit at the start of it) changes the logic rather more than that, and makes it more complex. Among other things, it duplicates the application -> host -> reactContext logic... and leaves out the if (!host.hasInstance()) condition, which according to the comment there means it's likely to crash sometimes with an assertion failure.
I think from here it may be easiest for me to go ahead and see about implementing a fix myself -- it may be simpler to demonstrate a way of structuring this code than to explain. Thanks for the work investigating this issue! It's been very helpful.


Add NavSat messages

🎉 New feature
Part of

https://github.com/ignitionrobotics/ign-sensors/issues/23

Required by

https://github.com/ignitionrobotics/ign-gazebo/pull/519
https://github.com/ignitionrobotics/ign-gazebo/pull/519

Related to

https://github.com/ignitionrobotics/sdformat/pull/453

Summary

On https://github.com/ignitionrobotics/sdformat/pull/453 we decided to use the more generic "NavSat" name for navigation satellite systems, instead of GPS, which is one specific type. This change should be reflected on the messages too.
This PR is only adding the new NavSat messages, but we should also update the sensors message to use it on Garden.
Here's the ROS 2 NavSatFix message as a reference.
I retargeted this PR from Dome to Fortress because the GPS sensor will need to use spherical coordinates (see https://github.com/ignitionrobotics/ign-gazebo/issues/981).
Test it

I'm updating the downstream PRs to use this message.
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Added example and/or tutorial
[x] Updated documentation (as needed)
[x] Updated migration guide (as needed)
[x] codecheck passed (See contributing)
[x] All tests passed (See test coverage)
[x] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge
🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

Please don't merge this until the downstream PRs are done; I want to make sure the message has everything we need before releasing.

A couple of downstream PRs have been approved, so I think this is good to go.

This pull request has been mentioned on Gazebo Community. There might be relevant details there:
https://community.gazebosim.org/t/new-ignition-releases-2022-01-10/1228/1


Styler move module attribute used in use below the first usage

Versions

Elixir: use elixir --version
Erlang/OTP 26 [erts-14.2.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]
Elixir 1.15.7 (compiled with Erlang/OTP 26)

Styler: use mix deps | grep locked | grep styler
locked at 0.11.6 (styler) 0b0b9936

Styler move a module attribute below the first usage causing an error
Example Input
    @consumer_group "channels". # defined here

    use Kafkaesque.ConsumerSupervisor,
      consumer_group_identifier: @consumer_group, # used here
      topics: ["channels.commands"],
      message_handler: ChannelsCommands.Commands.MessageHandler

    def healthcheck, do: Heartbeats.Helpers.kafka_consumer_check(@consumer_group)

Stacktrace / Current Behaviour
    use Kafkaesque.ConsumerSupervisor,
      consumer_group_identifier: @consumer_group,
      topics: ["rchannels.commands"],
      message_handler: ChannelsCommands.Commands.MessageHandler

      @consumer_group "channels" #styler moves it here

    def healthcheck, do: Heartbeats.Helpers.kafka_consumer_check(@consumer_group)

I see now that this is similar to #65

hey @dkuku, this is covered in the readme here. sorry for the inconvenience


[feature]sg scan -U should not return exit code 0 in case errors were fixed

⭐ Suggestion
Following #1708, I suggest sg scan -U not return 0 exit code if fixed were made. In fact, it should not affect the exit code that is return from running sg scan without the flag.
Using a non-zero exit code when errors are detected is common practice in other popular tools like eslint or ruff regardless if a --fix flag has been applied or not

💻 Use Cases
Frameworks like pre-commit rely on a non-zero exit code in case of errors and/or file modifications:

The hook must exit nonzero on failure or modify files.

I don't think a linter should exit with error if code is all fixed.
See ruff https://docs.astral.sh/ruff/linter/#exit-codes

The similar case applies to eslint, https://eslint.org/docs/latest/use/command-line-interface#--fix

If you need error exit code, removing the --fix flag is a common convention.

first off, thank you for taking the time to respond, I appreciate it.
I admit you raise good points, and apparently I did misread the exit code situation with ruff and eslint.
Also, I realized that for my use case the exit code of ast-grep does not actually matter, since any changes it will make will be treated as a failure by pre-commit regardless, so for all intents and purposes, this is a moot point.
Thanks again for your time and your answer! I highly appreciate it 🙏

Thank you for your understanding! 🙏


feat(deps): bump versions

Codecov Report

Merging #226 (17af1d2) into master (3cdd61d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #226   +/-   ##
=======================================
  Coverage   58.94%   58.94%
=======================================
  Files           7        7
  Lines        1023     1023
=======================================
  Hits          603      603
  Misses        353      353
  Partials       67       67


Bug: side_by_side is ignored

extensions = {
		undo = {
			side_by_side = false,
		},
	},

and yet, i still get a side-by-side view?

I can't reproduce this, can you confirm there's no error on your end (not reloaded, overwritten somewhere, delta diffs without side-by-side on cli, ...)

ah yes, I had side by side set to true in my git config, that was it. (Might wanna add this info to the readme though.)

ah yes, I had side by side set to true in my git config, that was it. (Might wanna add this info to the readme though.)

I would argue this is a bug actually since it can override the git config if the git config has side_by_side set to false but cannot override side_by_side to be false if it is true in the git config.

Well if it is I'm afraid you'd have to take it up with delta: This plugin just provides a -s (i.e. use side by side) to the delta binary if configured to do so. There is no CLI flag on delta to specify "do not use side by side" that I could pass when our config is set to false.

Ah I see, thanks for clarifying!


A tool to show what keys are pressed on-screen

Description of the new feature / enhancement
Something similar to Carnac The Magnificent (Github)
Show the pressed key on the screen or on presentation software.
Provide some customizability like, custom layout, position on the screen, what key combinations should display and what should not.
Also show a description of a specific key combination used if user has provided them in the settings page.
Multiple descriptions for same key combinations. Groups of descriptions under different names.
Display the description list the user has selected in the settings.
Like this,

Scenario when this would be used?
When recording a video or presenting something, to let viewers see the keyboard shortcuts being used.
Supporting information
Examples,
This is how Carnac The Magnificent implements this.

Some example images found on internet

Duplicate of #14061

Thanks for your suggestion! This issue is a duplicate.
I'm linking this issue to #14061 to centralize the discussion thread, please go to that thread for discussion.
Thanks for your help to make PowerToys a better piece of software!


UserManager.signinSilent() does not include the id_token_hint. Please include it.

Some authorization servers require the id_token_hint.

I can see your request, as the spec says:

When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present.

So did you open an issue for "some authorization server" to allow the absence of id_token_hint?

@brockallen Thank you for looking into the spec. I have opened an issue with OpenIddict.

I thought about this some more, and the OP should allow not passing because the client might only being using response_type of "token" (rather than "id_token token"). The only use of the client passing it is to ensure that the current session matches the id_token_hint. oidc-client-js already does this check client-side.
Also, I admit the spec is not at all definitive on who should be doing what, as the wording is self-contradictory IMO.

Also, not sure that's the right issue.

BTW, for now you can pass id_token_hint explicitly to the various signin methods.

Given that you can explicitly pass the id_token_hint for the OP you're using as a workaround, I'm not inclined to change it here. I don't like that the URL is bloated with the additional overhead (which admittedly is a minor grievance) , but really the OP/AS should allow it because the client might only be using OAuth2 (and not OIDC).

My 2 cents:

but really the OP/AS should allow it because the client might only be using OAuth2 (and not OIDC).

prompt=none is totally OpenID Connect-specific, it doesn't exist in the OAuth2 spec. Yet, response_type=token is not a "valid" response type in OIDC (though I'm pretty sure most implementations treat is a valid one for backcompat' reasons):

NOTE: While OAuth 2.0 also defines the token Response Type value for the Implicit Flow, OpenID Connect does not use this Response Type, since no ID Token would be returned.

So the chances of having a prompt=none request without any identity token seem pretty low to me.
And anyway, it doesn't change anything to the fact the client is encouraged to send an id_token_hint when it can by the OIDC specification (just like the OP should accept a request that doesn't specify it, I agree with you).

I think you understand my point -- it's legal for an OAuth2 client to use an iframe to renew the access token, thus the expectation that an OP/AS would/should accept the request without an id_token.

Sure, I do. But our point is that oidc-client should send the identity token when it knows it. Of course, this must not throw when no identity token is available, since id_token_hint is an optional parameter, which shouldn't prevent the response_type=token scenario from working.

done. 1.2.0-beta.6 pushed to npm

Thanks @brockallen! :clap:

I've upgrade to 1.2.0. After having logged in to the OP, I open a new tab and refresh the page, calling signinSilent(). The request does not include the id_token_hint. It includes the following parameters.
http://localhost:12345/connect/authorize
?client_id=Aurelia.OpenIdConnect
&redirect_uri=http%3A%2F%2Flocalhost%3A9000%2Fsignin-oidc
&response_type=id_token%20token
&scope=openid%20email%20roles%20profile
&state=10963900f9d14ed9b490968bb53f8520
&nonce=87d3d29e07d044489e3f59edde29ec62
&prompt=none

new tabs don't share state (by default) from other tabs. by default sessionStorage is used.

I am not sure then how I can keep the user signed in across tabs. Using localStorage is discouraged, and an id_token_hint is not available for prompt=none.

so do a normal authorization redirect to the OP

Hmm. That would be an unpleasant experience for the end-user. As an end-user, I expect to stay logged in to the client across windows/tabs.

so then do a silent redirect and use a OP that supports that

Thank you for the clear guidance. I think that I understand the options now.

SSO is not magic. any server-side app would do the redirect approach. you say that it's not nice for users, so JS clients have the advantage that they can easily use iframe to achieve it. get open accict to support it if that's the OP you want to use it.

any server-side app would do the redirect approach

I thought that a server-side app would store the login in a cookie, which would persist across tabs.

ok, i misunderstood about the JS clients -- i assumed you meant different clients. in different clients since they'd normally use different authN cookies, they'd then normally expect to do a redirect to signin.
so then let's focus on the same JS client run twice. web apps just work differently since they do share cookes across tabs. JS/SPA apps don't, of course. the mechanics are different. if you don't have PII issues, then use localStorage to store your data across tabs.

Got it. That makes sense. I am currently working on using localStorage instead of sessionStorage, because I feel pretty chilled about the PII stuff. It looks like we can pass it into the ctor, which seems very convenient. https://github.com/IdentityModel/oidc-client-js/blob/dev/src/WebStorageStateStore.js#L8

So there is something that I am not understanding. I am able to call the ctor of the UserManager but not of the UserManagerSettings nor of the WebStorageStateStore. Are the latter two protected in a way that the former is not?

This works for me:
var config = {
            authority: "http://localhost:1941/",
            client_id: "js_oidc",
            redirect_uri: window.location.protocol + "//" + window.location.host + "/index.html",
            post_logout_redirect_uri: window.location.protocol + "//" + window.location.host + "/index.html",

            // these two will be done dynamically from the buttons clicked, but are
            // needed if you want to use the silent_renew
            response_type: "id_token token",
            scope: "openid profile email api1 api2",

            // this will toggle if profile endpoint is used
            loadUserInfo: true,

            // silent renew will get a new access_token via an iframe
            // just prior to the old access_token expiring (60 seconds prior)
            silent_redirect_uri: window.location.protocol + "//" + window.location.host + "/silent_renew.html",
            automaticSilentRenew: false,

            // this will allow all the OIDC protocol claims to be visible in the window. normally a client app
            // wouldn't care about them or want them taking up space
            filterProtocolClaims: false,

            // use localStorage
            userStore: new Oidc.WebStorageStateStore({ store: window.localStorage })
        };

Oddly enough, the TypeScript compiler cannot find WebStorageStateStore({}) or Oidc.WebStorageStateStore({}) but it is able to cast to them.

If the .ts file needs fixing, please send a PR. Also, as a matter of github protocol, please open new issues for new issues.

Just a FYI for anyone else running into the same issue we had:
Because of the inclusion of id_token_hint in the url, depending on the length of the token, the url could exceed the 2048 url limit, which broke our site for certain users.
Even though this change was implemented as a 'minor' update, for us it was a breaking change.


Merge refs/heads/update-dependencies into alpha

Merge refs/heads/update-dependencies into alpha

This PR has been merged into alpha and tagged as 2.0.0-alpha-202308291440. Thanks for your contribution!


Handcrafting Docker Image with Content Addressable Image Layers

I'm trying to create a Docker image compatible with the upcoming version 1.10 by supplying a handcrafted Tarball suitable for docker load. This Docker image should have a base image (i.e. I can't use docker import), and I generally try to minimize the amount of transferred data between me and the Docker daemon.
Until version 1.9 it is possible quite easily to do this, since Docker allows me to import a layer with a parent image not in the tarball, but already present on the computer. Thanks to #18727 it is possible to upload a partial image, but that only solves half the problem.
How can I get the layer checksums that I have to put in the configuration file (from the manifest of the base image)? Is this supported at all?

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

@thriqon So you want to see the layer IDs for an image that Docker already uses? Currently this info is not part of docker inspect but adding it has been discussed before(for this use case and for visualizing layer sharing). Atm best possible ways are to look at config on disk, query from registry(2.3+) or docker save. But I think best way is to propose a way for adding this info to docker inspect.

Yes, I'd like to be able to ask 'What is busybox composed of?', and then the Remote API could tell me: sha:2830, sha:20282, sha:4828. Is it possible to amend docker inspect for that?

@thriqon It (kind of) does that already, really.
See the Parent field.

@cpuguy83 Parent does not help you in this case any more. It's used only for build chain/cache.

I'm closing this issue in efforts to make issues list cleaner. Feel free to open new issue.


SNIP-06

add snforge prank so that calling contract will be account contract and a demo user created via contract_address_const::<0>()

  #[test]
    fn is_valid_signature_success() {
        // private key: 70aca2a9ab722bd56a9a1aadae7f39bc747c7d6735a04d677e0bc5dbefa71d47
        // just for testing, do not use for anything else
        let public_key =
            0xd6f1cf53f9f52d876505164103b1e25811ec4226a17c7449576ea48b00578171_u256;

        let account_class = declare_account();
        let account = deploy_account(account_class, public_key);
        // TODO: cleanup

         snf::start_prank(CheatTarget::One(account.contract_address), contract_address_const::<0>());

        let account = ISRC6Dispatcher { contract_address: account.contract_address};

        let hash = 123;

        let r = 1_u256;
        let s = 2_u256;

        let mut signature = Default::default();
        r.serialize(ref signature);
        s.serialize(ref signature);

        assert!(account.is_valid_signature(hash, signature) == starknet::VALIDATED);
        snf::stop_prank(CheatTarget::One(account.contract_address));
    }

How does this fix the test?

How does this fix the test?

i use start and stop prank to changes the caller's address and contract address to execute the function on

with the test data,
bip340::verify  is returning this
 result of bip340::verify is : false

changing the hash value will fix the test

I already fixed it.

changing the hash value will fix the test

No need to use pranks here. I already fixed it.

awesome, welldone


developmentPullRequest

About this project🧑🏽🍳
The project is about a Recipe app which keeps track of all our user's recipes, ingredients, and inventory. It will allow our users to save ingredients, keep track of what they have, create recipes, and generate a shopping list based on what they have and what they are missing from a recipe. Also, since sharing recipes is an important part of cooking the app should allow our users to make them public so anyone can access them.
For it: ✅
We used Ruby gems as a software packages system.
We Installed Ruby on Rails framework.
We used controllers to handle requests and render empty views.
We used params from browser requests in a safe way.
We used preprocessed HTML file with embedded Ruby code.
We used layouts and templates for shared content.
We created database migration files to maintain database schema.
We built validations for models.
We used secure app from n+1 problems.
Between other functionalities added.
We passed the linters.
Goal: 🧑🏽🍳
The goal is to understand the usage of Rails, creating databases, and migrations files, and most of all feeling comfortable building an App like Recipe App.

Thanks alot


Align anchors with features in RPN

It seems the anchors are flattened in row-first (link), but features are flattened in column-first (link). Can you verify it?

Could you explain why https://github.com/open-mmlab/mmdetection/blob/edb03937964b583a59dd1bddf76eaba82df9e8c0/mmdet/models/anchor_heads/anchor_head.py#L163 is column-first

The default tensor for torch fop conv layers is in [N, C, H, W] format. So the permuted bbox_pred having shape of [N, H, W, C]. Then the reshape() will consider H before W.

assume N=1, H=2, W=3, then flat should be
[0, 0, 0],
[0, 0, 1],
[0, 0, 2]
[0, 1, 0],
[0, 1, 1],
[0, 1, 2]
It is row-first.

Ah. My misunderstanding in indexing and dimension. Thank you!


S3 Changes for reading from Everspan

@aurorahunter I think this PR is a new version of #1614 . I have added some comments, and will close #1614 .

@aurorahunter We have changed the way how SSM find file is cold from metastore access to XATT. It causes conflict to our previous path. I will close this PR, and merge your code to new PRs.
Thanks for your contribution. :)


Update glossary.md

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Thanks, @scjane :)


Add theme Monochrome

Thanks @kaiiiz for submitting your theme 👍 - its already live on www.themes.gohugo.io


Generate Release?

Could you possibly generate a release for the latest version? Trying to get this added to conda-forge and need a release.
@jpeddicord @mvsusp @laurenyu @nskool @akartsky @ChuyangDeng
Thanks!

Bump

Bump #2

sorry for the delayed response. what is your use case for wanting this released as a Python library? (we don't have PyPI releases for any of the sagemaker-*-container repositories.)

@laurenyu please let me know when you get a chance. thanks!

We have added two github releases: https://github.com/aws/sagemaker-pytorch-serving-container/releases
And we have released it to pypi:
https://pypi.org/project/sagemaker-pytorch-inference/


Add bin icon next to task, so user can remove it

i would like to work on this, please assign me

Hi, sure!
Go ahead :)

please assign this task to  me

#58


[DOCUMENTATION] Add license header information to all sources

closing as this project does not get enough attention


IOutputStream::FlushAsync return value

This function returns an async task that returns a bool - but the meaning of the returned bool value doesn't seem to be documented

Szczegóły dokumentu
⚠ Nie edytuj tej sekcji. Jest ona wymagana dla docs.microsoft.com ➟ Dołączanie problemu w usłudze GitHub.

ID: 92bf5a70-6962-f6a6-ecfc-3ad2123573cc
Version Independent ID: 122e3975-8d37-d648-f989-351243d3b420
Content: IOutputStream.FlushAsync Method (Windows.Storage.Streams) - Windows UWP applications
Content Source: https://cpubwin.visualstudio.com/DefaultCollection/windows-uwp/_git/winrt-api-build?path=%2fwinrt-api-build%2fwindows.storage.streams.ioutputstream.yml&version=GBlive&_a=contents
Product: uwp
Git Login: mcleanbyron
Microsoft Alias: mcleans

Reassigning as per ownership info from previous assignee.  My 2c: what’s being returned isn’t “The stream flush operation”, but rather (wording something like) “An asynchronous operation object which, on completion, contains a Boolean value that indicates [what?]”. The product team PM/dev will be able to fill in that blank. Also, while you're working in the topic, MVP feedback is that the part “It's generally recommended to avoid this method if possible” should explain when it’s possible, and what else to use when it is.

Another option:
https://stackoverflow.com/questions/14096704/what-is-the-meaning-of-ioutputstream-flushasyncs-return-value
But I am currently trying to track down the PM that owns this for a definitive answer.

This asynchronous operation, when awaited, returns a boolean value indicating whether the flush operation succeeded


Technical Document / Diagram for UCSD

Design or Research
Based on CA SME call today, we've been asked to provide a document including the results flow, endpoints, and other information that would be valuable for future reference (e.g. troubleshooting).
Tasks

[x] Create Workflow diagram of PHL to UCSD

Additional Context
Add any other context or screenshots about the work here.

LucidChart link: diagramhttps://lucid.app/lucidchart/237fde81-9f15-43a1-9901-34dc34f7c956/edit?viewport_loc=-484%2C30%2C3328%2C1546%2C0_0&invitationId=inv_fd270dfb-2206-4eef-812a-1d95ff53af0f

Update:
Jeff (UCSD) requested for us to add the endpoints to the diagram. The endpoints for RS, TI, and Epic have been added. This include the OAught2 and payload endpoints.

Update:

Jeff uses Visio and our workflow diagram is in LucidChart. We need to export the diagram in visio format so he can access it via Visio.

Minor updates made and diagram exported to https://aphlinformatics.atlassian.net/wiki/spaces/ERI/pages/2165997854/California+Documentation+Master+List


Merge pull request #108 from Bonface-Osoro/main

Merge pull request #107 from Bonface-Osoro/capacity_traffic

Upload figure


Remove duplicate function

I accidentally added a duplicate function stub in #51 (which results in a documentation warning). This PR removes that duplicate function stub & doc string.

bors r+


tgswitch: use buildGoModule

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

I have no idea why there is a /var/empty directory on macOS.

Looks like these tests use user.HomeDir other than os.UserHomeDir.

I do not think it's not worth to enable tests for now.

@aaronjheng Yeah, agree.  Probably just disable the tests and add a comment. :-)


Inference for images?

Hi,
Is there a separate inference file for easier testing?

Indeed an inference script would help a lot @woshidandan


Add help for aptible config:add

$ aptible config:add
Could not find app in current working directory, please specify with --app
$ aptible config:add --app my-app
Updating configuration and restarting app...

So without arguments, config:add restarts the app.  It would be better to have some explanatory text like "You didn't specify what you wanted to add.  Do XYZ"

Hey @justinwiley , this is certainly a bug. If no KEY=value arguments are passed, the command should exit in error with a useful message.