New object model seems to break all examples in main branch

'sd_card_t' {aka 'struct sd_card_t'} has no member named 'spi_if'; did you mean 'spi_if_p'
Changed examples to reflect that but got more problems and left it...

This seemed to work:
static spi_t spis[] = {  // One for each SPI.
    {
        .hw_inst = spi1,  // SPI component
        .miso_gpio = 12,  // GPIO number (not Pico pin number)
        .mosi_gpio = 11,
        .sck_gpio = 10,

        // .baud_rate = 1000 * 1000
        .baud_rate = 12500 * 1000
        // .baud_rate = 25 * 1000 * 1000 // Actual frequency: 20833333.
    }};

static sd_spi_if_t spi_ifs[] = {
    {
        .spi = &spis[0],  // Pointer to the SPI driving this card
        .ss_gpio = 15
        }                   // Slave select for this SD card
};

// Hardware Configuration of the SD Card "objects"
static sd_card_t sd_cards[] = {  // One for each SD card
    {
        .pcName = "0:",          // Name used to mount device
        .type = SD_IF_SPI,
        .spi_if_p = &spi_ifs[0],
        //.spi_if.spi = &spis[0],  // Pointer to the SPI driving this card
    //    .spi_if_p.ss_gpio = 15,     // The SPI slave select GPIO for this SD card

        .use_card_detect = false,
        .card_detect_gpio = 13,  // Card detect
        .card_detected_true = 1  // What the GPIO read returns when a card is
                                 // present.
    }
};

I need to fix up the examples. The command_line example and its various config files should be OK.
The reason for this change is in order to support multiple SDIO-attached cards sdio_if objects now carry a lot of state information, including things like data buffers. The union of two types has the size of the larger type, so the spi_if was much larger than necessary. I solved this by moving the _if objects out of sd_card_t and replacing them with pointers.

Carl, Command Line has similar problem, but changing it to use the config above worked in SPI mode. Unfortunately switching to SDIO mode does not. I get an assertion assertion "0 == gpio_get(sd_card_p->spi_if_p->ss_gpio)" failed if I add another card to the array. If I remove the first card and only use one SDIO the assertion doesn't fail, but I get a timeout.
It's possible it's the hardware as it's a new card I have, but flagging this. It's also possible I'm not using the configuration correctly (would value your input).
I think you've done a lot of very good work that I'd like to reuse. Ian.
// Hardware Configuration of SPI "objects"
// Note: multiple SD cards can be driven by one SPI if they use different slave
// selects.
static spi_t spis[] = {  // One for each SPI.
    {
        .hw_inst = spi1,  // SPI component
        .miso_gpio = 12,  // GPIO number (not Pico pin number)
        .mosi_gpio = 11,
        .sck_gpio = 10,
        .set_drive_strength = true,
        .mosi_gpio_drive_strength = GPIO_DRIVE_STRENGTH_4MA,
        .sck_gpio_drive_strength = GPIO_DRIVE_STRENGTH_2MA,
        .no_miso_gpio_pull_up = true,

        // .baud_rate = 1000 * 1000
        .baud_rate = 12500 * 1000
        // .baud_rate = 25 * 1000 * 1000 // Actual frequency: 20833333.
    }
};

static sd_spi_if_t spi_ifs[] = {
    {
        .spi = &spis[0],  // Pointer to the SPI driving this card
        .ss_gpio = 15
        }
};

static sd_sdio_if_t sdio_ifs[] = {
    /*
        Pins CLK_gpio, D1_gpio, D2_gpio, and D3_gpio are at offsets from pin D0_gpio.
        The offsets are determined by sd_driver\SDIO\rp2040_sdio.pio.
            CLK_gpio = (D0_gpio + SDIO_CLK_PIN_D0_OFFSET) % 32;
            As of this writing, SDIO_CLK_PIN_D0_OFFSET is 30,
              which is -2 in mod32 arithmetic, so:
            CLK_gpio = D0_gpio -2.
            D1_gpio = D0_gpio + 1;
            D2_gpio = D0_gpio + 2;
            D3_gpio = D0_gpio + 3;
     */
    {
        .CMD_gpio = 11,
        .D0_gpio = 12,
        .SDIO_PIO = pio0,
        .DMA_IRQ_num = DMA_IRQ_0
    }                   // Slave select for this SD card
};

// Hardware Configuration of the SD Card "objects"
static sd_card_t sd_cards[] = {  // One for each SD card
    {
        .pcName = "0:",          // Name used to mount device
        .type = SD_IF_SPI,
        .spi_if_p = &spi_ifs[0],
        .use_card_detect = false,
        // .card_detect_gpio = 13,  // Card detect
        // .card_detected_true = 1  // What the GPIO read returns when a card is
        //                          // present.
    },
    {        // Socket sd0 SDIO
        .pcName = "1:",  // Name used to mount device
        .type = SD_IF_SDIO,
        .sdio_if_p = &sdio_ifs[0],
        .use_card_detect = false

        // SD Card detect:

        // .card_detect_gpio = 9,
        // .card_detected_true = 0, // What the GPIO read returns when a card is
        //                          // present.
        // .card_detect_use_pull = true,
        // .card_detect_pull_hi = true
    }

    // assertion "0 == gpio_get(sd_card_p->spi_if_p->ss_gpio)" failed

};

Ah, I checked in all the other config files, but I didn't check in hw_config.c. I change that one all the time for various tests, so I generally do not check that one in.

Thanks ! I'll give it a try.

Regarding your configuration above, you can't drive the same card with SPI and SPIO simultaneously. It has to be one or the other. The SD specification says that once a card is switched to SPI mode, the only way to return to the SD mode is by entering the power cycle. However, I think it is possible to switch from SDIO to SPI without cycling power.  ZuluSCSI does something like this in panic situations; it falls back to SPI mode to take a dump, I think. Currently, this library doesn't directly support that, though. For a static configuration, it's not going to work if you use the same pins in an spi_t  definition and an sd_sdio_if_t definition.

Yes, I thought that was probably the case but right now I only have one adapter and wanted to run separate tests SPI vs SDIO. I'll remove one at a time instead. Thanks.

In theory, you can't get that "No SD card detected!" message unless somewhere, somehow, the use_card_detect filed of the sd_card_t struct is getting set to true. If the card detect switch is "NC", then you'd want false, obviously.

Could you attach your hw_config?

Here it is attached...
On Wednesday, October 4, 2023 at 07:37:42 PM PDT, Carl J Kugler III @.***> wrote:
Could you attach your hw_config?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Hmmm, I'm not seeing it

I've pasted here:
/* hw_config.cCopyright 2021 Carl John Kugler III
Licensed under the Apache License, Version 2.0 (the License); you may not usethis file except in compliance with the License. You may obtain a copy of theLicense at
http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, software distributedunder the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES ORCONDITIONS OF ANY KIND, either express or implied. See the License for thespecific language governing permissions and limitations under the License.//
This file should be tailored to match the hardware design.
There should be one element of the spi[] array for each hardware SPI used.
There should be one element of the sd_cards[] array for each SD card slot.The name is should correspond to the FatFs "logical drive" identifier.(See http://elm-chan.org/fsw/ff/doc/filename.html#vol)In general, this should correspond to the (zero origin) array index.The rest of the constants will depend on the type ofsocket, which SPI it is driven by, and how it is wired.
/
#include <string.h>//#include "my_debug.h"//#include "hw_config.h"//#include "ff.h" / Obtains integer types ///#include "diskio.h" / Declarations of disk functions /
/ See https://docs.google.com/spreadsheets/d/1BrzLWTyifongf_VQCc2IpJqXWtsrjmG7KnIbSBy-CPU/edit?usp=sharing,tab "Monster", for pin assignments assumed in this configuration file./
/ Tested 0: SPI: OK, 12 MHz only SDIO: OK at 31.25 MHz 1: SPI: OK at 20.8 MHz 2: SPI: OK at 20.8 MHz 3: SDIO: OK at 20.8 MHz (not at 31.25 MHz) 4: SDIO: OK at 20.8 MHz (not at 31.25 MHz)/
// SD Card Pins on S1 board/
SPI SDIO GPIOCLK CLK 10SI CMD 11 MOSISO D0 12 MISO D1 13 D2 14CS D3 15  CD NC
/
// Hardware Configuration of SPI "objects"// Note: multiple SD cards can be driven by one SPI if they use different slave// selects.static spi_t spis[] = { // One for each SPI. { .hw_inst = spi1, // SPI component .miso_gpio = 12, // GPIO number (not Pico pin number) .mosi_gpio = 11, .sck_gpio = 10, .set_drive_strength = true, .mosi_gpio_drive_strength = GPIO_DRIVE_STRENGTH_4MA, .sck_gpio_drive_strength = GPIO_DRIVE_STRENGTH_2MA, .no_miso_gpio_pull_up = true,
// .baud_rate = 1000 * 1000 .baud_rate = 12500 * 1000 // .baud_rate = 25 * 1000 * 1000 // Actual frequency: 20833333. }};
/ SPI Interfaces /// static sd_spi_if_t spi_ifs[] = {// { // spi_ifs[0]// .spi = &spis[0], // Pointer to the SPI driving this card// .ss_gpio = 15, // The SPI slave select GPIO for this SD card// .set_drive_strength = true,// .ss_gpio_drive_strength = GPIO_DRIVE_STRENGTH_4MA// }// };
static sd_sdio_if_t sdio_ifs[] = { / Pins CLK_gpio, D1_gpio, D2_gpio, and D3_gpio are at offsets from pin D0_gpio. The offsets are determined by sd_driver\SDIO\rp2040_sdio.pio. CLK_gpio = (D0_gpio + SDIO_CLK_PIN_D0_OFFSET) % 32; As of this writing, SDIO_CLK_PIN_D0_OFFSET is 30, which is -2 in mod32 arithmetic, so: CLK_gpio = D0_gpio -2. D1_gpio = D0_gpio + 1; D2_gpio = D0_gpio + 2; D3_gpio = D0_gpio + 3; / // SD Card Pins on S1 board /
SPI SDIO GPIO CLK CLK 10 SI CMD 11 MOSI SO D0 12 MISO D1 13 D2 14 CS D3 15  CD NC
/ { .CMD_gpio = 10, .D0_gpio = 12, .SDIO_PIO = pio1, .DMA_IRQ_num = DMA_IRQ_1, .baud_rate = 15 * 1000 * 1000 // 15 MHz } };
// static sd_card_t sd_cards[] = { // One for each SD card// { // sd_cards[0]: Socket sd0// .pcName = "0:", // Name used to mount device// .type = SD_IF_SPI,// .spi_if_p = &spi_ifs[0], // Pointer to the SPI interface driving this card// // SD Card detect:// .use_card_detect = false, // }// };
// Hardware Configuration of the SD Card "objects"// static sd_card_t sd_cards[] = { // One for each SD cardstatic sd_card_t sd_cards[] = { // One for each SD card { // sd_cards[0]: Socket sd0 { // Socket sd0 SDIO .pcName = "1:", // Name used to mount device .type = SD_IF_SDIO, .sdio_if_p = &sdio_ifs[0], .use_card_detect = false,
// SD Card detect:  // .card_detect_gpio = 9,  // .card_detected_true = 0, // What the GPIO read returns when a card is // // present. // .card_detect_use_pull = true, // .card_detect_pull_hi = true }
// assertion "0 == gpio_get(sd_card_p->spi_if_p->ss_gpio)" failed
};
/ ********************************************************************** */size_t sd_get_num() { return count_of(sd_cards); }sd_card_t *sd_get_by_num(size_t num) { if (num <= sd_get_num()) { return &sd_cards[num]; } else { return NULL; }}size_t spi_get_num() { return count_of(spis); }spi_t spi_get_by_num(size_t num) { if (num <= spi_get_num()) { return &spis[num]; } else { return NULL; }}
/ [] END OF FILE */
On Wednesday, October 4, 2023 at 08:53:25 PM PDT, Carl J Kugler III<EMAIL_ADDRESS>wrote:

Hmmm, I'm not seeing it
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Sorry, but I cannot make sense of that formatting.

Sorry, it was late and forgot to put code tag around it. Anyway I did get it working on a different card. I did though have an interesting failure when I used PIO1. PIO0 was fine, but with PIO1 there seems to besome interaction with the Wi-Fi - that is supposed to claim unused PIO but in this case it seems to be using PIO1 at the same time as I am. Could be because I am running under FreeRTOS and have not yet got a mutex around the file system calls?

I did though have an interesting failure when I used PIO1. PIO0 was fine, but with PIO1 there seems to besome interaction with the Wi-Fi - that is supposed to claim unused PIO but in this case it seems to be using PIO1 at the same time as I am.

I don't think the SDK provides a way to claim unused PIO. Do you mean pio_claim_unused_sm? That is, claim unused State Machine in a PIO block? The author of the ZuluSCSI implementation (that I stole), "jpa-", said "As a downside, my implementation uses more PIO program space than the pico-extras code, so nothing else will fit on the same PIO block."
Also, have you git pulled the latest code? 5 days ago I checked in a fix for a bug in initialization of PIO0, but maybe it is related? See https://github.com/carlk3/no-OS-FatFS-SD-SDIO-SPI-RPi-Pico/pull/7/commits/08e186ce23f307022845578a57c673dc4a25bffa

Could be because I am running under FreeRTOS and have not yet got a mutex around the file system calls?

If you're running FreeRTOS, you might consider using FreeRTOS-FAT-CLI-for-RPi-Pico instead. That is designed from the ground up for FreeRTOS. I haven't yet ported the SDIO driver to that repository, but it should be easy to do.

I don't think the SDK provides a way to claim unused PIO. Do you mean pio_claim_unused_sm? That is, claim unused State Machine in a PIO block? The author of the ZuluSCSI implementation (that I stole), "jpa-", said "As a downside, my implementation uses more PIO program space than the pico-extras code, so nothing else will fit on the same PIO block."

Yes, I meant state machine.

Also, have you git pulled the latest code? 5 days ago I checked in a fix for a bug in initialization of PIO0, but maybe it is related? See 08e186c

Yes, I have. That's when I made better progress. I deleted entire repo and recloned. Got command line working and then my own stuff.

If you're running FreeRTOS, you might consider using FreeRTOS-FAT-CLI-for-RPi-Pico instead. That is designed from the ground up for FreeRTOS. I haven't yet ported the SDIO driver to that repository, but it should be easy to do.

Yes, I saw that repo but hard to give up five times faster reads, especially as I am using it as part of a webserver implementation. Are you planning to offer a OS-FatFS-SD-SDIO-SPI-RPi-Pico for FreeRTOS in the near future?

Are you planning to offer a OS-FatFS-SD-SDIO-SPI-RPi-Pico for FreeRTOS in the near future?

I'm not sure when I'll have time to port the SDIO driver over. That will require migrating to the new configuration model, too. I would stick to Lab-Project-FreeRTOS-FAT instead of FatFs for that. FatFs does not have sufficient concurrency controls. With SDIO and FreeRTOS SMP the performance should be excellent for multi-threaded applications.

OK sounds like I should switch to FreeRTOS-FAT-CLI-for-RPi-Pico so it plays nicely with FreeRTOS and hope that you eventually do the SDIO port to get the performance! Thanks very much for your help.

While FatFS has some support for “re-entrancy” or thread safety (where "thread" == "task", in FreeRTOS terminology), it is limited to operations such as:

f_read
f_write
f_sync
f_close
f_lseek
f_closedir
f_readdir
f_truncate

There does not appear to be sufficient FAT and directory locking in FatFS to make operations like f_mkdir, f_chdir and f_getcwd thread safe. If your application has a static directory tree, it should be OK in a multi-tasking application with FatFS. Otherwise, you probably need to add some additional locking.
Then, there are the primitives (if that's the right word) used for mutual exclusion and various ways of waiting (delay, wait for interrupt, etc.). This library uses the Pico SDK primitives (which are really oriented to multi-processing on the two cores), but FreeRTOS-FAT-CLI-for-RPi-Pico uses the FreeRTOS primitives, which put the waiting task into a Blocked state, allowing other, Ready tasks to run.
FreeRTOS-FAT-CLI-for-RPi-Pico is designed to maximize parallelism. So, if you have two cores and multiple SD card buses (SPI or SDIO), multiple FreeRTOS tasks can keep them all busy simultaneously.

Thanks. I got the FreeRTOS version working thank you. Note that in SDK 1.5 spi.h does not include pico/time.h (whereas 1.4 did) so build fails with missing timer functions. I added #include pico/time.h to sd_spi.c (but maybe better in sd_spi.h where I noticed you had the other pico includes) to get it to link cleanly.

I meant spi.h for the best place to include the header.

Thanks. I got the FreeRTOS version working thank you. Note that in SDK 1.5 spi.h does not include pico/time.h (whereas 1.4 did) so build fails with missing timer functions.

Ah. That repository is definitely due for some maintenance, as well as enhancement (SDIO).


[Feature] Add service account name to MariaDB spec

Is your feature request related to a problem? Please describe.
I believe we should allow users to define their own service accounts. Additionally, in clusters prior to version 1.25 with Pod Security Policies (PSPs) where running as root is restricted, defining a custom service account for MariaDB will be beneficial
Describe the solution you'd like
Add serviceAccountName in MariaDBSpec
Environment details:

mariadb-operator version: 0.0.24
Install method: helm

I think it should be completed now, PR #339 implements a serviceAccountName parameter.

Supported in the following PR:

https://github.com/mariadb-operator/mariadb-operator/pull/339


Progress bar for non interactive environments

🚀 Feature
I'd like to request a progress bar for non-terminal, non-interactive environments, like for example Amazon CloudWatch. The TQDM and Rich progress bars are not ideal for tracking progress in these more simple logging environments.
Additionally, I'd like to request the ability to automatically adapt to a known-length or an unknown length iterable dataset, by displaying percentage based progress in the former case, and simply iteration count in the latter case. (It appears that the default TQDM progress bar produced errors for me with an unknown length iterable dataset.)
Motivation
I'm training on both EC2 and Amazon SageMaker, and neither the TQDM nor the Rich progress bars seem appropriate for monitoring progress in CloudWatch. I asked on slack if a more appropriate alternative or configuration setting was available, and was advised that there's not anything currently, but I should create a GitHub issue for one.
Pitch
At the most basic level, the progress indicator would print something like this on rank 0:
[Epoch 0 | Iteration 100] train_loss: 0.01, val_acc: 0.74
Another useful feature would be optionally passing a logger to use instead of print, so for example if you pass a logger that writes to stdout:
LoggerName - INFO - [Epoch 0 | Iteration 100] train_loss: 0.01, val_acc: 0.74
If the epoch has a known total number of batches, additional information on the completion percentage would be nice. For example:
[Epoch 0 | Iteration 100/450 (22.22% complete)] train_loss: 0.01, val_acc: 0.74
Alternatives
I guess whenever anyone needs more simple progress tracking they could write their own custom progress meter based on ProgressBarBase.

from my experience with cloudwatch, one needs to push a print statement/log to track something. I used to do a simple print, but my use-case of non-ml related.
we should investigate if there's any open source project doing it and think of integrating within lightning or possible solutions to build one of our own by investigating possible ways to log to cloud watch or some other monitoring space.


[GLTF] Validation Tests

BabylonJS list of validation tests here : https://github.com/BabylonJS/Babylon.js/blob/master/tests/validation/config.json

[x] GLTF Normals
[x] GLTF Animation Node
[x] GLTF Animation Node Misc
[x] GLTF Animation Skin (0)
[x] GLTF Animation Skin (1)
[x] GLTF Animation Skin Type
[x] GLTF Buffer Interleaved
[x] GLTF Material
[x] GLTF Material Alpha Blend
[x] GLTF Material Alpha Mask
[x] GLTF Material Double Sided (Front)
[x] GLTF Material Double Sided (Back)
[x] GLTF Material Metallic Roughness (0)
[x] GLTF Material Metallic Roughness (1)
[x] GLTF Material Mixed
[x] GLTF Material Specular Glossiness (0)
[x] GLTF Material Specular Glossiness (1)
[x] GLTF Mesh Primitive Attribute
[x] GLTF Mesh Primitive Mode (0)
[x] GLTF Mesh Primitive Mode (1)
[x] GLTF Mesh Primitive Vertex Color
[x] GLTF Mesh Primitives
[x] GLTF Mesh Primitives UV (0)
[x] GLTF Mesh Primitives UV (1)
[x] GLTF Node Attribute (0)
[x] GLTF Node Attribute (1)
[x] GLTF Node NegativeScale (0)
[x] GLTF Node NegativeScale (1)
[x] GLTF Texture Sampler (0)
[x] GLTF Texture Sampler (1)
[x] GLTF Sheen
[x] GLTF ClearCoat
[x] GLTF Alpha Blend
[ ] GLTF Buggy with Draco Mesh Compression
[ ] GLTF Buggy with Meshopt Compression
[x]  GLTF BoomBox with Unlit Material
[x] GLTF Extension KHR_texture_transform
[ ] GLTF Extension KHR_materials_volume
[x] GLTF Extension KHR_materials_volume with attenuation
[x] GLTF Extension KHR_materials_specular
[x] GLTF Texture Linear Interpolation Test
[ ] GLTF Mesh Primitive Attribute Test
[x] GLTF Extension EXT_mesh_gpu_instancing
[x] GLTF Extension KHR_materials_variants
[x] GLTF ext MSFT_LOD
[x] Iridescence
- [ ] GLTF Serializer with Negative World Matrix
- [ ] GLTF Serializer with Negative World Matrix (Right Handed)
- [ ] GLTF Serializer Skinning and Animation
- [ ] GLTF Serializer Skinning and Animation (Right Handed)
- [ ] GLTF Serializer Morph Target Animation
- [ ] GLTF Serializer Morph Target Animation Group
- [ ] GLTF Serializer KHR materials clearcoat

4 tests added with this PR : https://github.com/BabylonJS/BabylonNative/pull/812

4 more : https://github.com/BabylonJS/BabylonNative/pull/815

2 more tests with https://github.com/BabylonJS/BabylonNative/pull/1344

For the WebAssembly ones, we are probably only going to support in V8 or engines that already have WebAssembly support.

Closing since everything not done is represented by other issues now.


Allow overriding default .meta() and .getMeta() data types.

Hello, Emil! Please consider approach that allows to define default metadata interface and also allows to override .meta() argument type and .getMeta() return type by using generics!

Hello, Emil! Please consider approach that allows to define default metadata interface and also allows to override .meta() argument type and .getMeta() return type by using generics!

Updated #2, please, check again.
Can you give me an example use case for overwriting IMeta? I want to try an keep it as open as possible. Typing specific keys is probably fine as long as they are not required and are possibly undefined in the return type.

Hello, Emil! Please consider approach that allows to define default metadata interface and also allows to override .meta() argument type and .getMeta() return type by using generics!

Updated #2, please, check again.
Can you give me an example use case for overwriting IMeta? I want to try an keep it as open as possible. Typing specific keys is probably fine as long as they are not required and are possibly undefined in the return type.

Ok, use case.
For example, I use zod for validation in controllers and also want to have some openApi related data stored inside every instance of ZodType:
const Input = z.object({
	page: z.number().meta({ example: 5 }),
	perPage: z.number().meta({ example: 50 }),
});

And I want to have autocompletion when I call .getMeta().<VALID_FIELDS_AUTOCOMPLETION>, or when I call .meta({<VALID_FIELDS_AUTOCOMPLETION>}).
In most of cases within a single project all metadata will have that type, so it is possible to be defined as a default data type.
But in some rare cases I will store in meta some data having another data structure, like { firstName?: string, lastName?: string }. In these cases I can do the following steps:

Define interface ICustomMeta { firstName?: string, lastName?: string }

Call z.object().meta<ICustomMeta>({ firstName: John, lastName: Doe })

Call z.object().getMeta<ICustomMeta>()?.lastName

I see. You may want to follow these issues then:
https://github.com/colinhacks/zod/pull/2042
https://github.com/asteasolutions/zod-to-openapi/issues/99
One problem with the example meta example is that the example value must be of the type of the schema output, e.g. string for z.string() and number for z.number. So, you'll end up typing it as example: string | number | any-other-type-you-need.
zod-to-openapi solves this and adds other utility, so you may want to check it out if you haven't.
To be honest, the only property I needed is the OpenAPI refId, so my only use case is probably something like
z.object({ firstName: ..., lastName: ... })
  .meta({ [Symbol.for('openpi:refId')]:  'User' })

Let me know if #2 is doing it for you.

@IvanovES if you want to be my guinea pig I rewrote zod-to-openapi to support auto registering schemas: https://github.com/samchungy/zod-openapi. Very similar API but I went with a different approach

@IvanovES if you want to be my guinea pig I rewrote zod-to-openapi to support auto registering schemas: https://github.com/samchungy/zod-openapi. Very similar API but I went with a different approach

This is exactly what I hoped for when I first discovered zod-to-openapi!
Though, please remove createDocumentJson and createDocumentYaml. Without these your library does one thing and it does it well. Don't couple it with serialization. I don't need yaml, you don't need yaml, let's not have yaml in our dependencies. And whether or not it's json or yaml you don't want to pick the serialization library - yaml is not the only one nor is JSON.stringify - https://www.npmjs.com/package/fast-json-stable-stringify.

@IvanovES if you want to be my guinea pig I rewrote zod-to-openapi to support auto registering schemas: https://github.com/samchungy/zod-openapi. Very similar API but I went with a different approach

@samchungy This is exactly what I hoped for when I first discovered zod-to-openapi!
Though, please remove createDocumentJson and createDocumentYaml. Without these your library does one thing and it does it well. Don't couple it with serialization. I don't need yaml, you don't need yaml, let's not have yaml in our dependencies. And whether or not it's json or yaml you don't want to pick the serialization library - yaml is not the only one nor is JSON.stringify - https://www.npmjs.com/package/fast-json-stable-stringify.
PS. I may have spoken too soon. You may still be able to have your yaml cake you can declare it as an optional peer dependency.
Anyway, good job!

Good feedback. I'll have a look at removing it


Editing and listing fix

Edited the new content that came in with the fix for issue 1511.
Also fixed a code listing for JAX-RS. (The tags were misplaced,
and the additional characters broke the listing. I also had to
replace the tab characters with tabs.)

Apparently, moving the tags fixes the document but breaks a test.

Done via https://github.com/spring-cloud/spring-cloud-contract/commit/6e951e60fdda57f5e7eec22178415a282390aa4c


REST endpoints fail with non-default RPC port assigned

Summary of Bug
When running strided with a non default RPC port (26657) all REST endpoints fail with this error:
{
  "error": "post failed: Post \"http://localhost:26657\": dial tcp <IP_ADDRESS>:26657: connect: connection refused"
}

Version
v4.0.2
Steps to Reproduce
Edit config.toml and change RPC port to non-default value:
#######################################################
###       RPC Server Configuration Options          ###
#######################################################
[rpc]

# TCP or UNIX socket address for the RPC server to listen on
laddr = "tcp://<IP_ADDRESS>:36657"

Additional context
app.toml API value:
###############################################################################
###                           API Configuration                             ###
###############################################################################

[api]

# Enable defines if the API server should be enabled.
enable = true

# Swagger defines if swagger documentation should automatically be registered.
swagger = true

# Address defines the API server to listen on.
address = "tcp://<IP_ADDRESS>:22301"

Check any REST endpoint - curl http://localhost:22301/node_info | jq .
If using a non-default RPC port this fails but if using 26657 as RPC port then REST endpoints work as expected.

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

+1
Do we know if this's been solved in the future versions or is still there?

I solved this problem:

Change the RPC port at the config.toml (1805 for example)
Change the RPC section at .stride/config/client.toml

: to Tendermint RPC interface for this chain
node = "tcp://localhost:1805"
3. Start your node

Thanks for this @SergeyMitk, unfortunately my node is already running on a different port than the default one for all endpoints. I guess my issue is a different one than the OP's. Thanks anyway for your time and comment.


DataGrid with Fluent theme does not update when changing theme mode

Describe the bug
When using a DataGrid in an application that uses Fluent theme, changing the theme mode from light to dark or vice versa does not update the grid theme.
To Reproduce
Steps to reproduce the behavior:

Create an application that uses Fluent theme and DataGrid
Add a datagrid to the main window
Add button or other input method to change the fluent theme mode
Grid header does not change

Expected behavior
The datagrid should change themes just like built-in controls.
Screenshots

Desktop (please complete the following information):

OS: Windows 10
Version 0.10.18

Additional context
Restarting the application and having the theme applied from the start works as expected.
I included the DataGrid fluent theme in my App.axaml:
<Application.Styles>
    <FluentTheme Mode="Light"/>
    <StyleInclude Source="avares://Avalonia.Controls.DataGrid/Themes/Fluent.xaml"/>
</Application.Styles>

The DataGrid control does not use custom styles or templates.
I'm changing the theme like this:
if (Application.Current!.Styles[0] is FluentTheme theme)
{
    theme.Mode = FluentThemeMode.Light; //FluentThemeMode.Dark;
}

See https://github.com/AvaloniaUI/Avalonia/issues/7659
Also it was fixed in 11.0 I think https://github.com/AvaloniaUI/Avalonia/pull/8163/files

Thanks, 11.0.0-preview3 works properly.

Cannot confirm. With 11.0.0-preview5, workaround is still needed. Without, it looks like this:

@Sputnik24 I don't think it's the same issue. The appereance is similar, however now even the white background is there if you start with dark theme applied. If no issue for this is open, please open a new one.

Not the same issue, but observable problem and workaround are the same.

I can confirm that it was working fine without workaround in preview 4 (I havent used any earlier preview versions). In preview 5 its broken (again?).

I cannot get the "workaround" to work. But there is also no code snippet, maybe I'm doing something wrong. What's more weird is that if I remove Datagrid style from App.xaml and add it in code after changing to dark mode, the Datagrid Column Headers are still white:

Before I've tried (the order of removing and adding seems to be unrelated. I tried removing / adding before and after changing to dark without any difference):

Can someone please post the mentioned workaround or tell me what I'm doing wrong?


useForm API: Improve correctness of JS terminology

I think that useForm() accepts only one optional argument and the things listed in the example are its properties.

thanks 🙏


Fix timeout, untimeout, ban and unban not working from other threads

Pull request checklist:

[x] CHANGELOG.md was updated, if applicable
[x] Documentation in docs/ or install-docs/ was updated, if applicable
[ ] I have tested all changes

Would appreciate if you could test this @pajlada 🤗

I have tested the changes! :heavy_check_mark:


Update DashioESP.cpp

Fix code for NimBLE 2.0.0 support

Hi Earl. Thanks for your pull request. We've found a few other issues with NimBLE 2.0.0, particularly around advertising and we're working on. those. We will include your changes as we work through the issues.

@craigt543nz  7 hours ago Nim-BLE 2.1.0 was released with a full description of all the changes.. they are very large-scale.
I ask you to pay attention to this. The current implementation of DashioESP for BLE is extremely unstable. especially at the moment of the first connection (and device search)

@EarlVadim we released V1.2.3 a couple of days ago with the changes required for NimBLE 2.0.0 sorted - or so we thought. Apparently NimBLE 2.0.0 was a flawed release and has been pulled. With the release of NimBLE 2.1.0 we found an issue with downloading layout (config) information, which is due to the way NimBLE 2.X.X behaves when compared with NimBLE 1.X.X. Hopefully we have solved the major issues with the latest release of dashioESP V1.2.4.

ahaha.. )))
https://github.com/h2zero/NimBLE-Arduino/releases/tag/2.1.1

Nice bug find. My Arduino IDE compiler didn't find that, even with all warnings on. What are you compiling in? Maybe PlatformIO?
I've tried to reproduce the "Reconnect" issue on a number of test boards, but I haven't been able to reproduce it. I'll keep looking. What specific ESP board are you using?

Nice bug find. My Arduino IDE compiler didn't find that, even with all warnings on. What are you compiling in? Maybe PlatformIO?
I've tried to reproduce the "Reconnect" issue on a number of test boards, but I haven't been able to reproduce it. I'll keep looking. What specific ESP board are you using?

ArduinoIDE 2.3.4 + arduinoesp32 3.0.7
Chip ESP32-S3 8N1


Learning path listing for DP-100

There is a mismatch in the information displayed in the Self-paced learning path for the DP-100 exam.
In the Spanish version we have different learning paths available to prepare for the certification.
When we go to the English version, only one element appears.

Fixed.


Accept paths via STDIN

I'm no so sure about this anymore. This isn't really supported by things like rm.

As rm does not do this, trash will not as well (for the time being)

As rm does not do this, trash will not as well (for the time being)


Update terminology from master/child to principal/dependent

In DU1 we're making this terminology change.
This PR updates:

Any mentions within other topics to the new terminology (let me know if I missed anything!)
The former child-normal page converter to use the new terminology in its labels

Note that the field IDs still reflect the old terms because this it how it is in the code base
I also updated a mention of Skuid Platform to Skuid NLX here

Once approved, let's hold merging until DU1 GA so the links to latest docs work

I don't think the JSON files are necessary for the experiment.  It would only be folks using a CLI tool to push these pages into a new org that would use these files.  And that seems really rare.
It would be good to come back and clean up these pages - (a bit of padding,  more accurate language, a header) but that's outside the scope of what's required here.  So other than the Readme Changes - I think we are good.

@Rnhatch Good point. I removed the JSON files for now. If we need to we can put them back in later if CLI gets more use.
Definitely would like to come back and enhance the styling (and filtering) here
Let me know if there are any other changes you see!


Create PHP.md

#19

Added curated list of resources for learning mastering PHP.

@mintunitish It seems like this has been copied from somewhere and does not adhere to the template


delta([1d]) unexpected result when target switched from server1 to server2

What did you do?
delta(job:node_filesystem_usage_percent_cmdb:by_mountpoint{cmdb_service_name="xxxxxxxxx",instance="xxxxx:9100"}[1d]) * 100

What did you expect to see?
during this changing period, there should not have any value
What did you see instead? Under which circumstances?
on prometheus server 1 there not have datapoint older than June 7 12:30 but  still have delta till June 8 12:30
on prometheus server 2 there not have datapoint earlier than June 7 12:30 but still have delta before June 8 12:30
Environment

System information:
Linux 4.15.0-42-shopee-generic x86_64

Prometheus version:
prometheus, version 2.19.3 (branch: HEAD, revision: 657ba532e42f1db8d7c77bf802378643da0d3118)
build user:       root@b99e50bced7c
build date:       20200724-12:20:53
go version:       go1.14.6

Prometheus configuration file:

# global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.

  # scrape_timeout is set to the global default (10s).
  scrape_timeout:      14s

  external_labels:
      datacenter: "sg"
      prom_cluster: "main"
      prom_role: "raw"
      group: "2"
      replica: "0"

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  - "/etc/prometheus/rules_*.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:

- job_name: "icmp"
  metrics_path: "/probe"
  params:
    module: ["icmp_check"]
  file_sd_configs:
    - files: ["/etc/prometheus/targets_icmp.json"]
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: <IP_ADDRESS>:9115
- job_name: "tcp"
  metrics_path: "/probe"
  params:
    module: ["tcp_check"]
  file_sd_configs:
    - files: ["/etc/prometheus/targets_tcp.json"]
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: <IP_ADDRESS>:9115
- job_name: "dns"
  metrics_path: "/probe"
  params:
    module: ["dns_check"]
  file_sd_configs:
    - files: ["/etc/prometheus/targets_dns.json"]
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: <IP_ADDRESS>:9115

- job_name: 'default'
  # metrics_path defaults to '/metrics'
  # scheme defaults to 'http'.
  metric_relabel_configs:
    - source_labels: [job,tracking_id]
      regex: 'core;\S+'
      action: 'drop'
  file_sd_configs:
    - files: ["/etc/prometheus/targets.json"]
- job_name: 'spex'
  # metrics_path defaults to '/metrics'
  # scheme defaults to 'http'.
  metrics_path: '/metrics2'
  honor_labels: true
  file_sd_configs:
    - files: ["/etc/prometheus/targets_spex.json"]
- job_name: 'interval_60s'
  scrape_interval: 60s
  scrape_timeout: 59s
  file_sd_configs:
    - files: ["/etc/prometheus/targets_60s.json"]
- job_name: 'targets_proxy'
  file_sd_configs:
    - files: ["/etc/prometheus/targets_proxy.json"]

- job_name: 15s:http:/metrics
  honor_labels: true
  honor_timestamps: true
  scrape_interval: 15s
  scrape_timeout: 15s
  metrics_path: /metrics
  scheme: http
  file_sd_configs:
  - files:
    - /etc/prometheus/targets_15s_http__metrics.yml
    refresh_interval: 30s
  tls_config:
    insecure_skip_verify: true
  metric_relabel_configs:
  - source_labels: [__name__]
    separator: ;
    regex: sp_xxxx_distr_(client|service)_rpc_flow(in|out)_h_bucket
    replacement: $1
    action: drop
- job_name: 15s:http:/metrics2
  honor_labels: true
  honor_timestamps: true
  scrape_interval: 15s
  scrape_timeout: 15s
  metrics_path: /metrics2
  scheme: http
  file_sd_configs:
  - files:
    - /etc/prometheus/targets_15s_http__metrics2.yml
    refresh_interval: 30s
  tls_config:
    insecure_skip_verify: true
  metric_relabel_configs:
  - source_labels: [__name__]
    separator: ;
    regex: sp_xxx_distr_(client|service)_rpc_flow(in|out)_h_bucket
    replacement: $1
    action: drop

# Alerting configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - xxxxxxxxxxxx:9093

# "disalbe remote-write temp,if want enable, can delete env condition"
# remote write
remote_write:
  - url: http://localhost:19211/api/v1/receive
    write_relabel_configs:
    - source_labels: [__name__]
      regex: ^job:.+$
      action: drop
    remote_timeout: 90s
    queue_config:
      capacity: 100000
      max_shards: 120
      min_shards: 60 # some new workers loads are very lower, if this value set too large, will delay
      max_samples_per_send: 40000 # if increase will get spikes on latency
      batch_send_deadline: 10s
      min_backoff: 100ms
      max_backoff: 1000ms

Thanks for your report. It looks as if this is actually a question about usage and not development.
It makes more sense to ask questions like this on the prometheus-users mailing list or our forums rather than in a GitHub issue. In our community channels, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

@roidelapluie  i think you should think more about the issue, this is not a question about the usage
From what I understand delta is a-b
but when a or b is N/A  what is your behavior need me to list the code here?

i am 100% sure this is an issue not, the user does not know how to use Prometheus.

vs := ms.VectorSelector.(*parser.VectorSelector) in https://github.com/prometheus/prometheus/blob/39d79c3cfb86c47d6bc06a9e9317af582f1833bb/promql/functions.go#L61
this will get a range of value but when the start or end time limit is different than the dataset oldest or newest point
it will use the :

https://github.com/prometheus/prometheus/blob/39d79c3cfb86c47d6bc06a9e9317af582f1833bb/promql/functions.go#L74
this is not that nature for user to understand and is not users' expected answer

This is a usage question. When you run delta(metric[1d]), prometheus will take the first and last point in 1d. Even if they are at 7h30 and 7h31, you would get result up to one day later.
The query you are looking for is metric - metric offset 1d.

well for all means thanks your help but cannot agree with this so called delta

I agree with you that this result is not what users can expect, however it is not related to delta. Instead, it is an underlying design behaviour of the PromQL language. I will create another issue to discuss this.

https://github.com/prometheus/prometheus/issues/8906


Link SPIRV-Cross instead of using SDL_LoadObject

Partially resolves #44
We can probably stop vendoring spirv_cross_c.h and spirv.h now that we're linking SPIRV-Cross directly.

I added spirv-cross as a git submodule instead of using cmake's FetchContent to do this. I believe this keeps complexity low.
The following CMake options are relevant:

SDLGPUSHADERCROSS_SHARED: build shared SDL3_gpu_sharedcross library
SDLGPUSHADERCROSS_STATIC: build static SDL3_gpu_sharedcross library
SDLGPUSHADERCROSS_VENDORED: use vendored spirv-cross
SDLGPUSHADERCROSS_LINK_STATIC: link to static spirv-cross

I also added -Werror when building the shadercross cli util, which errors now.

Thanks, I'll look into that. While I'm at it do you have any insight on the best way to link DirectXShaderCompiler?

Thanks, I'll look into that. While I'm at it do you have any insight on the best way to link DirectXShaderCompiler?

SDLGPUSHADERCROSS_VENDORED assumes the sources of spirv-cross are already available (checked out as a git submodule).
I think we can do something similar here.
For dependencies that don't provide CMake support (ignore pkg-config because that is not available by default on Windows), I usually write custom FindXXX.cmake modules.
Building it as a subproject is probably out of the question (LLVM is not fast to build).
Let's create a (cmake) script that downloads the prebuilt .so/dll binaries from the release binaries to a known location (e.g. external/dxcompiler)
Then by building with SDLGPUSHADERCROSS_VENDORED=ON, we will look in external/dxcompiler for the binaries.
If SDLGPUSHADERCROSS_VENDORED=OFF, then CMake will look in the default locations (and fail if it cannot find any).

I created a poc at https://github.com/madebr/SDL_gpu_shadercross/commit/e0df3340d5b626e17efc4274251c3393ea7d4b12 if you want to try things out.

Awesome, I will check that out shortly.

-Werror issue is fixed, it looks like verifying CMake files fails for SLR though.

Final note, I simply added the current main branch of spirv-cross as a submodule.
For SDL_image and SDL_mixer we use a libsdl-org fork of a tagged release.

I think it's safe to use spirv-cross main, they don't do ABI breaking changes and main branch is generally bugfixes and improvements.

Adding it as a submodule "freezes" it though. So you might want to regularly update it to get latest bugfixes.


I suggest adding an "Accuracy" property to DiagnosticRecord.

Suggestion
Add an "Accuracy" property to DiagnosticRecord that will state the probability of the diagnostic being correct.
Benefits for the Users
Users can filter and sort diagnostics based on their accuracy.
    invoke-scriptanalyzer |
        where {$_.accuracy -gt 0.75} |
        sort rulename, accuracy -descending

Benefits for the Rule Writers
Rule writers can introduce new rules sooner by introducing rules with a low accuracy, and then later increase the accuracy as the rule is refined.
For example, the "UseShouldProcessForStateChangingFunctions" rule right now is based only on the function name, so the rule can be assigned with an accuracy of, let's say, 0.25. If the rule is improved with better heuristics, then its accuracy can be increased. If the default of Invoke-ScriptAnalyzer doesn't show diagnostics with an accuracy of less than 0.50, then users won't have to suppress the "UseShouldProcessForStateChangingFunctions" while the rule is still in its initial stages.
This allows rule writers to get feedback on their rules while the rules are still being refined without adding noise to Invoke-ScriptAnalyzer results.
Benefits for the Rules
The rules can have multiple diagnostic accuracies.
For example, the "PossibleIncorrectComparisonWithNull" will be more useful if it can output diagnostics with different accuracies based on context.
A line such as:
    if ($a -ne $null)

should output a diagnostic for this rule with a high accuracy because "$a -ne $null" is very likely to be a compare operation instead of a filter operation.
However, a line such as:
    $a = $b -ne $null

should output a diagnostic for this rule with a low accuracy because "$b -ne $null" can either be a compare operation or a filter operation, and it will be very difficult to assert that the user violated the rule.
Now, the rule doesn't have to be hardcoded with the compromise of when to generate diagnostics because it can generate all diagnostics with different accuracy levels.

Suggestion Amendment
The values for the "Accuracy" property should not be numbers, but words like "Low", "Medium", and "High".
Since the accuracy of a diagnostic will be very subjective (made up by the rule writer, voted on by the community, etc.) using numbers will make the property seem objective when it is not. That could lead to pointless arguments, such as "that diagnostic should have an accuracy of 0.75612, not 0.75611!"
Also, using a small set of values will prevent the "race" between the users who want to work around the tool and the tool makers who want to prevent the users from working around the tool. For example, users who want to work around the tool may only display diagnostics with an accuracy higher than, say, 0.75. Tool makers who do not want their diagnostics ignored will increase the accuracy of their diagnostics to 0.76. And the race begins. However, with a small set of values, the race ends before it can even begin.
Core idea
The main idea of this suggestion is just to give users and rule makers the ability to distinguish between diagnostics that are likely to be correct and diagnostics that can sometimes be wrong.
This way, there is less of a need to suppress or compromise the rules.

I don't like this idea personally.  Accuracy works for something like OCR where there is a very high amount of randomness to the data and as a result very large margin for error.  In the case of rules in this tool though, the margin for error is not that large.  Rules either have bugs that need to be fixed or rules are identified as unnecessary and become candidates for removal.  Trying to add accuracy to these rules is only going to over-complicate things IMHO.

@KirkMunro

Rules either have bugs that need to be fixed or rules are identified as unnecessary and become candidates for removal. Trying to add accuracy to these rules is only going to over-complicate things IMHO.

There's a big difference between the rules and the diagnostics, and this suggestion is about the diagnostics.
Examples
Here are a few examples that demonstrates where I'm coming from.
Bad Rule, Good Diagnostics
I think we both agree that the way the "ProvideVerboseMessage" rule is written right now is bad. It's a bad rule because it just encourages everyone to write verbose messages for all advanced functions.
However, the diagnostic for this rule is very good. There are no false positives. If you see a diagnostic for this rule, you know that there is an advanced function that does not have a verbose message.
However, the rule is still bad.
Good Rule, Bad Diagnostics
The "UseShouldProcessForStateChangingFunctions" is a good rule because it gives users of functions that change system state the chance to do -WhatIf.
However, the diagnostic for this rule is really bad. It generates many false positives because it only looks at the name of the function (the verb in particular) in order to determine that the function changes state. Since the name doesn't determine whether or not the function changes system state, the diagnostic is wrong a lot of times.
However, the rule is still good.
Buggy/Unnecessary Rules
I completely agree that buggy rules should be fixed and that unnecessary rules need to be removed.
This suggestion is only for the diagnostics of rules that are deemed worthwhile.
False Positives are Unavoidable
I think false positives can never be eliminated from this tool because this fully automated tool deals with the subjective topic of Best Practices for a language that was not designed for static analysis.
If this tool only deals with things like indentation and aliases, then yes, we can get rid of false positives. However, it will also make the tool completely useless because those things are already handled by the ISE and scripts/tools that automatically formats scripts.
The interesting problems, like state changing functions, or comparison vs. filtering operations, or even functions accidentally returning unintended objects, are real problems that cannot have diagnostics that are always 100% correct because those things require a little bit of mind reading. Some of those problems require more mind reading than others and will have diagnostics that are less accurate than others.
The Only Human in the System
Years from now, after the rules have been written and this tool is used by many people, the only thinking human in the system will be the one who has to deal with the diagnostics.
Automatic Prioritization of Work
An "Accuracy" property on the diagnostics, or something similar, will give that person another piece of information that he/she can use to automatically prioritize work. That person can do something like:
    $analyzerResults | where {$_.accuracy -eq 'high'}

and have some confidence that he/she will not be chasing dead ends.
Defense
More importantly, an "Accuracy" property on the diagnostics can give that person a reason for disagreeing with a diagnostic without fear of being labeled as a rebellious cowboy.
For example, the scripter can say something like:

I'm not following this diagnostic because it doesn't make sense in this case. You can even see that the diagnostic has a low accuracy. I follow it when I can, but for this case, it's just wrong.

Without such a property, how can anyone disagree with a tool created by Microsoft in an open source project that is based on Best Practices created by PowerShell experts?
Even if a scripter gathers up the nerve to tell their non-technical peers and bosses (both with and without pointy hairs) that he/she will not follow the diagnostics from this tool, how can the scripter convincingly explain why he/she is right and the tool is wrong?
If the accuracy of the diagnostic is right there in the output, then the scripter can just point in the screen and say, "this is one of those times where the diagnostic is wrong." Without that, he/she just risks being branded as a rebellious, irresponsible, cowboy.

The values for the "Accuracy" property should not be numbers, but words like "Low", "Medium", and "High".

I like this tweak and I kind of like the notion overall.  Not a must have for me but I can see the value.


Compile a list of all builtins actually used by nixpkgs

It's possible this may include some features not exercised by the language tests.
The symbolic evaluator should be good example of writing a custom grep-style tool for doing pointed queries like this, since it can take with and let bindings into account.

Comparing this with what we have in Builtins.hs, we are missing at least these functions
currentTime
div
fetchurl
filterSource
genericClosure
hasContext
langVersion
max
min
nixPath
nixVersion
storeDir
storePath
toFile
trace

Thanks @mightybyte! I've converted your last comment into a work list.

I wonder how nixPath differs from __nixPath...

These are all broken out into separate issues now.


where is the portugueese version?

im trying to make a portugueese version, but i stuck on phonemizer. I saw some references on ES phonemizer about portugueese(br), so, theres a pt version or something ?

They probably had no plan.


Kernighan's Algorithm | Count Set Bits in an Integer | Bit Manipulation

Greetings sir/Mam,
I would like to contribute the code for this issue in C++/CPP.
The code is ready. I have added the code , along with proper explanation of the algorithm , test cases , time complexity and space complexity of the same, as per the guidelines.
Kindly assign it to me.
This is regarding GSSOC'21.
Regards,
Hitain Kakkar

Issue present at #44


issue #969 : named configuration loaded correctly with a program, but the name is then forgotten

gui.configuration.conf in guiState.model.js always remains an empty string.
So, whenever function configurationToBricklyWorkspace(xml) is called this line
var name = xml == GUISTATE_C.getConfigurationConf() ? GUISTATE_C.getRobotGroup().toUpperCase() + "basis" : ''; makes the name = '' and sets the configurationName as ' '.
I didn't get why gui.configuration.conf is needed. If mistaken please correct me.

Thank you very much for this pull request, in general your solution is correct, but we forgot to explain it a bit more in detail, there is a third option needed

[x] the name, if it is a named configuration
[x] [robot]basic, if it is a standard configuration
[ ] empty or "", if it is a custom (modified standard) configuration

Please look in the issue again, we will write a comment there

OK I will look into it. Can you assign me this issue.

I have made some changes to the server-side. Please check if it's correct or not.

Thank you very much! Well done, this pull request is accepted here 27b84dc5f1460c68874625f7e6cbda91ea5a7ed8 and here 0fb503910c9fd0545ad931f3e9f4f5599984359b. We will have another internal review soon and then the bug fix will be released. One small issue, please try to install and use our formatters (see wiki) for further commits.


QAOA benchmark

Benchmark object for qaoa

[x] Qaoa Benchmark object
[x] decide the import
[x] Create reference object
[x] Run method for benchmarked object and reference
[x] When running the benchmark it evaluates the points such that at each round there is more resolution
[x] Plot method for results
[x] Difference property between benchmarked values and reference
[x] Mean difference property
[x] Notebook
[x] Tests

For examples read notebook 14 (new), here is a simple example:
from openqaoa import QAOA, create_device, QAOABenchmark
from openqaoa.problems import QUBO

qaoa = QAOA()
qaoa.set_device(create_device(name='qiskit.shot_simulator', location='local'))
qaoa.compile(QUBO.random_instance(5))
benchmark = QAOABenchmark(qaoa)
benchmark.run(n_points_axis=2**4, ranges=[(0,1),(0,1)], plot=True)

@shahidee44, @vishal-ph Which import do you think is appropriate for this object?
now is: from openqaoa.algorithms.qaoa import QAOABenchmark

now is: from openqaoa.algorithms.qaoa import QAOABenchmark

I think it can easily be
from openqaoa import QAOABenchmark

@raulconchello, sorry if I missed the discussion, but why is this PR going into dev_evaluate_circuit?

NOTE: run black formatter before merging


Add DB connection strings as AWS secrets

Fixes #9
Describe your changes
Add DB connection strings for DEV and STAGING databases from AWS secrets into task definitions

Codecov Report

Merging #72 (67bee14) into dev (4f67b37) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev      #72   +/-   ##
=======================================
  Coverage   62.66%   62.66%
=======================================
  Files          31       31
  Lines        1058     1058
  Branches       98       98
=======================================
  Hits          663      663
  Misses        383      383
  Partials       12       12

Flag
Coverage Δ

backend
67.15% <ø> (ø)

dev
62.66% <ø> (?)

frontend
16.12% <ø> (ø)

staging
?

unit
62.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Fix for not setting Gofig global/user dirs

This patch fixes the issue where the Gofig's global (/etc) and user ($HOME) directories were not set, resulting in the default config files not being loaded.

Hi @clintonskitson,
Please test this to see if it fixes the issue you identified last night regarding the configuration files not being loaded properly. Thanks!


Prepare for v0.1.0

Update usage section base on model change

[x] README
[x] Generation
[ ] SFT
[x] Other packages? vllm?

[x] Sync LICENSE change
Make sure models are updated

[x] HuggingFace
[x] ModelScope
[x] Wisemodel
[ ] Selfhost Tar

[ ] Update transformers version in dependency.


Use another augmented assignment statement

:eyes: Some source code analysis tools can help to find opportunities for improving software components.
:thought_balloon: I propose to increase the usage of augmented assignment statements accordingly.
diff --git a/nameko/log_helpers.py b/nameko/log_helpers.py
index a2b65bd..2ec0a8e 100644
--- a/nameko/log_helpers.py
+++ b/nameko/log_helpers.py
@@ -30,7 +30,7 @@ def make_timing_logger(logger, precision=3, level=logging.DEBUG):
         finally:
             message = "{} in %0.{}fs".format(msg, precision)
             duration = time.time() - start_time
-            args = args + (duration,)
+            args += (duration,)
             logger.log(level, message, *args)

     return log_time

PRs welcome ;-)


Square brackets instead of _("") for path segments

_("foo") for a path segment is non-obvious, so we should really allow ["foo"] for a path segment instead.

fixed in #81


Added validate binary search tree

Program to check whether a binary tree is a BST or not.

Excellent work @naveenbudhwal Thanks a lot for making this PR.


Boilerplate code?

Hi
I am coming from webpack-dev-server and wondering if anyone has some boilerplate code on how to get up and running.
I am just using in my package.json I am have this line
"start": "webpack-dev-server --mode development --open --hot --history-api-fallback",
and in my webpack.config I got
  devServer: {
    historyApiFallback: true
  }

How can I get the same functionality?

Sad panda 🐼 😢  You removed the issue template, so we have to close your issue as invalid. Please don't ignore Issue or Pull Request templates.
Boilerplate is not needed for webpack-serve.

👉🏽 Need support, advice, or help? Don't open an issue.
Head to StackOverflow or https://gitter.im/webpack/webpack.

I've already responded on gitter and offered to help you get set up. Please connect there for further help, the issues here are not the place for support.


[Kubernetes] Max number of frontend IPs

I've just tried to add a Service of type LoadBalancer, and noticed that the service doesn't finish creating and keeps on Pending state.
The kube-controller-manager shows the following error:
2017-03-30T10:12:31.922013259Z E0330 10:12:31.921905       1 servicecontroller.go:665] External error while updating load balancer: network.LoadBalancersClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="LoadBalancerFrontendIPConfigurationCountLimitReached" Message="A load balancer cannot have more than 10 FrontendIPConfigurations." Details=[].
I checked the portal, and I indeed do have 10 IPs on the LoadBalancer that has been configured with the k8s installation. I created this using the acs-engine.
So it seems that I'm unable to create a service with a public IP because the AzureLoadbalancer is limited to 10 frontend-IPs.

Please contact support to raise the limit to 30.
Also, it would be great if you can file an upstream issue in Kubernetes and tag me in it? I want to see if we can:

determine at runtime the limit on the user's account (I doubt it)
if so, return a better error from the cloudprovider so that K8s can surface a proper error message (I don't think this will be possible, I think it will have to be an event, or we'd have to change the cloudprovider interface, but this is just off the top of my head)

Also thank you for digging into the logs and triaging this, I really appreciate it!

Closing since the limit was bumped to 30 (from https://github.com/Microsoft/azure-docs/issues/1238), and you should be hitting less often


Image prompt template

Builds on Bagatur's (#13227). See unit test for example usage (below)
def test_chat_tmpl_from_messages_multipart_image() -> None:
    base64_image = "abcd123"
    other_base64_image = "abcd123"
    template = ChatPromptTemplate.from_messages(
        [
            ("system", "You are an AI assistant named {name}."),
            (
                "human",
                [
                    {"type": "text", "text": "What's in this image?"},
                    # OAI supports all these structures today
                    {
                        "type": "image_url",
                        "image_url": "data:image/jpeg;base64,{my_image}",
                    },
                    {
                        "type": "image_url",
                        "image_url": {"url": "data:image/jpeg;base64,{my_image}"},
                    },
                    {"type": "image_url", "image_url": "{my_other_image}"},
                    {
                        "type": "image_url",
                        "image_url": {"url": "{my_other_image}", "detail": "medium"},
                    },
                    {
                        "type": "image_url",
                        "image_url": {"url": "https://www.langchain.com/image.png"},
                    },
                    {
                        "type": "image_url",
                        "image_url": {"url": "data:image/jpeg;base64,foobar"},
                    },
                ],
            ),
        ]
    )
    messages = template.format_messages(
        name="R2D2", my_image=base64_image, my_other_image=other_base64_image
    )
    expected = [
        SystemMessage(content="You are an AI assistant named R2D2."),
        HumanMessage(
            content=[
                {"type": "text", "text": "What's in this image?"},
                {
                    "type": "image_url",
                    "image_url": {"url": f"data:image/jpeg;base64,{base64_image}"},
                },
                {
                    "type": "image_url",
                    "image_url": {
                        "url": f"data:image/jpeg;base64,{other_base64_image}"
                    },
                },
                {
                    "type": "image_url",
                    "image_url": {"url": f"{other_base64_image}"},
                },
                {
                    "type": "image_url",
                    "image_url": {
                        "url": f"{other_base64_image}",
                        "detail": "medium",
                    },
                },
                {
                    "type": "image_url",
                    "image_url": {"url": "https://www.langchain.com/image.png"},
                },
                {
                    "type": "image_url",
                    "image_url": {"url": "data:image/jpeg;base64,foobar"},
                },
            ]
        ),
    ]
    assert messages == expected

this type of prompt wouldn't work anymore i take it?
prompt = ChatPromptTemplate.from_messages([
    ("system", "foo bar"),
    ("human", [
        "{question}",
        {"text": "{second_question}"},
        # image with var name 'first_image' and no preset values
        {"image_url": "{first_image}"},
        # image with var name 'second_image' and preset "detail" level
        {"image_url": {"variable_name": "second_image", "detail": "low"}},
        # constant image, not a var
        {"type": "image_url", "image_url": {"url": "https://python.langchain.com/assets/images/langchain_stack-f195a2c417953cb5828f76e5f9039c9f.png"}}]),
])

   {"image_url": {"variable_name": "second_image", "detail": "low"}},

^ this one wouldn't work right now. Is that a preferable format?


CORS fail with query v2 compatibility API

Description:
I am noticing a strange behaviour when querying InfluxDB 1.8.3 with Flux, from an Angular web app that uses @influxdata/influxdb-client. In my particular case, my web app is accessible at http://localhost:4200 while InfluxDB is hosted on another machine at http://<IP_ADDRESS>:8086.
The query request fails because of CORS policy, since this is an actual cross-origin request. But should it?
According to issue influxdata/influxdb#18391 and the consequent pull request, CORS should be correctly handled by InfluxDB and I supposedly should not be receiving this error:

In the network tab, this is the situation:

HTTP pre-flight OPTIONS requests look like this:

I also tried reverse-proxying InfluxDB through nginx to bypass CORS using this configuration: at first it seemed to work (the OPTIONS pre-flight request was successful) but any subsequent POST included duplicate Access-Control-* headers (both those returned by InfluxDB and those added by nginx).
Network tab:

Bypassed pre-flight OPTIONS request:

POST response, including duplicate Access-Control-* headers:

This tells me that CORS is indeed handled correctly by InfluxDB, if not for pre-flight requests. That is, the OPTIONS requests on /api/v2/query should not return 405 Method Not Allowed but a 2xx success response including the relevant Access-Control-* headers.
Steps to reproduce:
You could try creating an Angular web app using @influxdata/influxdb-client, but a simple web page including a script that launches an XMLHttpRequest to InfluxDB /api/v2/query should be sufficient to trigger the browser's CORS checks.
Expected behavior:
Calls to /api/v2/query should respond correctly to OPTIONS requests and not fail CORS policy checks.
Actual behavior:
OPTIONS pre-flight request to /api/v2/query responds with 405 Method Not Allowed and fails CORS policy checks.
Environment info:

System info: Linux 4.19.15-1.ph3-esx x86_64
InfluxDB version: 1.8.3, Docker image influxdb:1.8 sha256:35de8cc24dfca8ad80fc93bba1bc7125240b3e27b457a1ef529aac5fb6217eef
Other relevant environment details: Docker 18.06.1 on VMware PhotonOS 3.0

Config:
Only customization is INFLUXDB_HTTP_FLUX_ENABLED=true environment variable.

Thank you for reporting this issue, I can reproduce it locally. Your type of workaround is the right way to go now. Please try to adjust header specification in nginx configuration:
proxy_hide_header 'Access-Control-Allow-Methods';
proxy_hide_header 'Access-Control-Allow-Headers';
proxy_hide_header 'Access-Control-Allow-Origin';
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'POST, GET, OPTIONS, PUT, DELETE, PATCH';
add_header 'Access-Control-Allow-Headers' 'Accept, Content-Type, Content-Length, Accept-Encoding, Authorization, User-Agent';

The proxy_hide_header part gives full control of CORS to NGINX, the right CORS header values are taken from
https://github.com/influxdata/influxdb/blob/bc4bae373852d38557ff26a35d084a9bde6d1eb4/kit/transport/http/middleware.go#L23-L33
https://github.com/influxdata/influxdb/pull/18410 contained a fix for this in compliance with the current README.MD :
If you are looking for the 1.x line of releases, there are branches for each minor version as well as a master-1.x branch that will contain the code for the next 1.x release. The master-1.x working branch is here.

The 1.8.3 release originated in the 1.8 branch that does not contain the fix. @russorat can you please help with some clarification of where to deliver fixes for influxdb v1?

@sranka for v1, changes go into the master-1.x branch first and then get cherry-picked back to the desired release branch(es). Can you cherry-pick that change to the 1.8 branch and make a PR? We can get it merged for the 1.8.4 release. Thanks for the help with this issue.

@sranka thank you for your work.
I am now using this nginx configuration as a workaround:
if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Allow-Origin' '*';
    add_header 'Access-Control-Allow-Methods' 'DELETE, GET, OPTIONS, POST, PUT';
    add_header 'Access-Control-Allow-Headers' 'Accept, Accept-Encoding, Authorization, Content-Length, Content-Type, X-CSRF-Token, X-HTTP-Method-Override';
    add_header 'Content-Type' 'text/plain; charset=utf-8';
    add_header 'Content-Length' 0;
    return 204;
}

(header values are not the same as in your comment, I took them from here)
Always rewriting all Access-Control-* headers does not work since the main problem is a 405 response to OPTIONS requests.
By bypassing only the OPTIONS method, pre-flight requests are successful and then everything is fine (for example, POST is correctly handled by InfluxDB, as it returns Access-Control-* headers as expected, without any nginx intervention).

@LaXiS96 thank you for letting us know. Please add 'User-Agent'  to Access-Control-Allow-Headers for Safari and Firefox to work properly.

I had the same problem. I am not very experienced with nginx. But it didn't work right away. I had to add "always" to Access-Control-Allow-Origin. Then it works.
add_header 'Access-Control-Allow-Origin' '*' always;

This is already fixed in v1.9.3.


TLS functions in go/db/db.go to go/db/tls.go

This is patch 2 of https://github.com/github/orchestrator/pull/139. which moves some of the files out of db.go to a separate file. No functional change, this just moves things around a bit.

[x] contributed code is using same conventions as original code
[x] code is formatted via gofmt (please avoid goimports)
[x] code is built via ./build.sh
[x] code is tested via go test ./go/...   # well not really. They fail when run against the github master branch (TLS tests fail). Maybe we should figure out how to make them pass or my environment is not as expected. Does this work for you? $ cd go/db && go test does work for me.

closing based on @sjmudd 's comment: https://github.com/github/orchestrator/pull/242#issuecomment-317665011


Graphics artifacts in Safari 16

Originally reported in https://github.com/phetsims/geometric-optics-basics/issues/31.
@jonathanolson added a Safari-only overlay as a workaround, see https://github.com/phetsims/scenery/commit/8ebb1eb3aae93a70a746f841818228f943581bb7.  This workaround was used to move forward with RC testing of Geometric Optics: Basics.
@jonathanolson indicated that he opened bug reports with WebKit, see https://github.com/phetsims/geometric-optics-basics/issues/31#issuecomment-1317940293:

https://bugs.webkit.org/show_bug.cgi?id=248003
https://bugs.webkit.org/show_bug.cgi?id=248004
https://bugs.webkit.org/show_bug.cgi?id=248005

@jonathanolson will be doing a maintenance release, and will make an issue if needed.

We decided to transfer https://github.com/phetsims/geometric-optics-basics/issues/31 to scenery, so closing this issue.


Initializing server state for tests is unnecessarily difficult

As more tests are written, it's becoming clear that much of the code written for testing is to set up the initial server state. This makes the behavior under test more difficult to determine. Having to make manual requests to a client for setup can make it more challenging to implement common test patterns like table-driven testing. Each set of tests being written seems to have slightly different methods of setting up the initial server state, with some using helper methods with fixed test data, and others using in-line requests with case-specific test data.
Having a common method of seeding the initial server state may be beneficial. Our tests can particularly benefit from a library that makes it easy to construct a desired server state in a declarative manner.

Could "initializing server state" also be expressed as "constructing a project"?
Let's consider using YAML as an external representation. See the output of "registry export yaml" for one possible YAML format - if we settle on something we can write an importer for it. Spec contents could be either included inline (base64, ugly, possibly very large) or as references to side files. We might also consider mapping the registry contents to a directory structure that matches resource names (this might require/assume-that resource lists are always ordered alphabetically by resource id).

I think it's more than just constructing a project. Most tests create other resources like APIs, versions, specs, and artifacts.
If we want to use an external representation I think YAML would be reasonable. Being able to reference other files for spec contents or creating a directory structure that can represent the resource hierarchy seems like it would trend into the territory of DSLs with the associated pros/cons. Particularly I think it would increase the difficulty of writing tests because developers would have to learn how the storage structure works and put in the effort to set it up for their needs.
What I had in mind was something closer to what is used in the server tests. Each test case can declaratively set the resource hierarchy by providing the resources they depend on. In those tests the helpers actually create parent resources that are implicitly required by the seed. You can see in those tests how many different states we might want the server to have across a suite.
Test isolation is fairly important for this to be useful, so that problem might be best to tackle first. If every test in the repo has to avoid collisions with others it becomes a burden.

To clarify my comment: "project" meant a full project with all of its child resources.


Improve documentation for contributors and how to build a DIY version

This issue is related to the CCS proposal: https://locha.io/monero
--
Identify docs and links that need work and new ones that may need to be created.

We need to repeat the step by step setup for each OS (as we did for the Windows instructions).

This README needs to be revamped: https://github.com/btcven/turpial-firmware ✓

This README needs to be revamped: https://github.com/btcven/radio-firmware ✓

Double check repos that may need to be removed from https://github.com/btcven for clarity. ✓

Add a table of comparison with all the existing mesh techs in documents or documentation.

up

PR: #120, Add Authors file

This closes #165

PR done. It will be closed if no further activity occurs


question:when to call poll method ?

in future trait,we know its required method to control IO state.but,i donnt know when to call poll.

I'll try and answer. Generally, you don't need to call poll. This is called by some other processor, like the tokio_core::reactor::Core after the future has been registered there during it's run() or turn() functions. The only case you'd need to call poll() is if you are wrapping another future and want to call that futures poll() function to track some kind of internal state.

@bluejekyll is spot on, although feel free to let me know if that doesn't answer the question at hand!


[bug] Rebuilds twice, then stops rebuilding.

After the second rebuild, modifying the same file stops triggering a rebuild.
Version: 4.3.1
Possibly related: https://github.com/rollup/rollup-watch/issues/51

rollup now comes with its own --watch flag and this repo ( and plugin ) has been deprecated. There's a similar issue posted on the main rollup repo already FYI: https://github.com/rollup/rollup/issues/1666

Ah, looks nice. I'll close this, and reopen on rollup if it happens with rollup.

Happening with Rollup too.


Dynamic Grouping Rules Update

@ehrenMSFT, should the dynamic grouping rules be updated so that they mirror the edit we made to static grouping last year?
In essence, are the rules for static and dynamic grouping identical, just performed at different points using different information (i.e. just what can be learned by static analysis vs. the additional knowledge gained from [partial] evaluation results)?

@DougKlopfenstein, @bezhan-msft
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@ehrenMSFT, should the dynamic grouping rules be updated so that they mirror the edit we made to static grouping last year?
In essence, are the rules for static and dynamic grouping identical, just performed at different points using different information (i.e. just what can be learned by static analysis vs. the additional knowledge gained from [partial] evaluation results)?

No, the logic is different. The static phase merges partitions based on their structure. The dynamic phase merges partitions based on what they actually access when evaluated. So two partitions that were kept separate during the static phase can end up getting merged in the dynamic phase.

@ehrenMSFT, should the dynamic grouping rules be updated so that they mirror the edit we made to static grouping last year?
In essence, are the rules for static and dynamic grouping identical, just performed at different points using different information (i.e. just what can be learned by static analysis vs. the additional knowledge gained from [partial] evaluation results)?

No, the logic is different. The static phase merges partitions based on their structure. The dynamic phase merges partitions based on what they actually access when evaluated. So two partitions that were kept separate during the static phase can end up getting merged in the dynamic phase.

That said, the steps you updated do seem to mirror the static phase. They just run after partitions have been trimmed using the data source info obtained during evaluation.

Hi @bgribaudo - Do you have any further thoughts or changes based on Ehren's comments?

@DougKlopfenstein> Do you have any further thoughts or changes based on Ehren's comments?
@ehrenMSFT> That said, the steps you updated do seem to mirror the static phase. They just run after partitions have been trimmed using the data source info obtained during evaluation.
@ehrenMSFT, what do you think here? Should we go with this edit so that the two mirrored sets of logic are described identically?  Or would it be better to say something "partitions are merged using the same merge rules used in the static phase"?

@DougKlopfenstein> Do you have any further thoughts or changes based on Ehren's comments?
@ehrenMSFT> That said, the steps you updated do seem to mirror the static phase. They just run after partitions have been trimmed using the data source info obtained during evaluation.
@ehrenMSFT, what do you think here? Should we go with this edit so that the two mirrored sets of logic are described identically? Or would it be better to say something "partitions are merged using the same merge rules used in the static phase"?

I think the latter would be good. Something like: "Partitions are then merged using the same rules described in the static grouping phase above."

Thanks, @ehrenMSFT. How does it look now?

#sign-off

@Court72 signed off, but rejected - Ehren has already signed off, so please merge.


IdentityServer4.Storage version

When I configure the identityserver appears the next error:
Method 'FindIdentityResourcesByScopeNameAsync' in type 'IdentityServer4.MongoDB.Stores.ResourceStore' from assembly 'IdentityServer4.Contrib.MongoDB, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null' does not have an implementation
And if I add this DI:
builder.Services.AddTransient<IClientStore, IdentityServer4.MongoDB.Stores.ClientStore>();
The error is that I need the version <IP_ADDRESS> of Identityserver4.Storage
Thanks for all!

Sorry, Now in the closed Issues I have seen the same question and it is in RC version.
Thanks and sorry


Official Savage Worlds fix for error in race drag and drop

Submission Checklist
Required

[X] The pull request title clearly contains the name of the sheet I am editing.
[X] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[X] The pull request makes changes to files in only one sub-folder.
[X] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description

Fixed an error in the handling for race drag and drop that caused the name of the race/ancestry to not populate correctly.

Character Sheet Info Roll20 Internal Use only.

@nmbradley, if you can tell me what the conflict is here, I can get it fixed, but github won't tell me what the conflict is.

Hey there @Kurohyou I believe this is an Official sheet and you may need permission from the authors to modify it (@finderski ?). Please forgive me if you already have the rights to do it, but I would rather be safe than sorry. With that said, in order to fix the conflicts, you need to rebase your fork from the public repo master by adding it as the upstream.

@Kurohyou should be on the list of pre-approved editors for this. But yeah, in essence Scott, because the file is too big to preview you will probably need to rebase from upstream.
git switch master
git remote add upstream https://github.com/Roll20/roll20-character-sheets.git
git fetch upstream
git rebase upstream/master
git push origin master

You may need to force the push on origin master by appending --force the last command.
Once that's done you can rebase your branch as normal.


Create CODEOWNERS

This configures the repo to require an approval from a member of the Timescale Observability Engineering team on PRs

bors r+


evaluate is called with the output_file for the all_entities argument

The signature of zero.utils.evaluator.evaluate is as follows:
def evaluate(args, model, fold, all_entities, output_file=None,
             return_report=False):
    ...

In zero.ner.main.run, we call it as follows:
evaluate(args, zero, "train", train_output_file)
evaluate(args, zero, "dev", dev_output_file)
evaluate(args, zero, "test", test_output_file)

where i.e. dev_output_file = os.path.join(args.output_dir, "dev_predictions.txt"). Notice how here dev_output_file and so on are actually supplied for the all_entities argument. Is this a problem?

Closed by #7.


at_c: Architecture Discussion Tracker

This is an architectural discussions tracker for tracking pending (unchecked) and completed (checked) discussions.
Discussions
[x] = Completed Discussion, (title is changed to outline work needed to be done)
[ ] = Pending, (has the word "discussion" in the title, discussion is ongoing and needs to be approved, then the title is changed or the ticket is closed if no work is deemed necessary)

[x] #284
[ ] #317
[ ] #331
[x] #336
[x] #341
[ ] #342

Added #342


Improve jdk.ThreadDump content parsing

The single large string instance obtained from the jdk.ThreadDump event has to be parsed so that we can send separate stack traces to ingest. Previously, we just simply called .split("\n\n") on this. The regex might be computationally expensive, whatever, but we definitely know that the split is allocating a lot of strings that get thrown away immediately when agent internal threads are omitted (default).
So, this creates a stateful parser to help handle this. We only create those smaller substrings in the event that we can parse a stack and pass the filters. This also adds a few more thread names to the filter list.

I think that replacing simple regex split with such complicated algorithm requires fact-based justification. Can you please add a jmh benchmark demonstrating that we actually have a noticeable improvement here?
Also, please verify and confirm that existing tests cover all branches of AgentInternalsFilter.test and ThreadDumpToStacks.

adding jmh and hitting edges.

I think that replacing simple regex split with such complicated algorithm requires fact-based justification. Can you please add a jmh benchmark demonstrating that we actually have a noticeable improvement here?
Also, please verify and confirm that existing tests cover all branches of AgentInternalsFilter.test and ThreadDumpToStacks.

Ok, it took me quite some time to get a benchmark running with jmh, and now that I have data, I either don't know how to read the results or I've just made things worse (no actual improvement).
I ran ./gradlew testing:jmh-benchmarks:clean testing:jmh-benchmarks:jmh and got this output:
Benchmark                                                                          Mode  Cnt      Score      Error   Units
ThreadDumpProcessorBenchmark.newThreadDumpProcessor                               thrpt   20  47654.113 ± 1266.723   ops/s
ThreadDumpProcessorBenchmark.newThreadDumpProcessor:·gc.alloc.rate                thrpt   20   2415.975 ±   86.159  MB/sec
ThreadDumpProcessorBenchmark.newThreadDumpProcessor:·gc.alloc.rate.norm           thrpt   20  55820.110 ±  571.208    B/op
ThreadDumpProcessorBenchmark.newThreadDumpProcessor:·gc.churn.G1_Eden_Space       thrpt   20   2418.887 ±   87.175  MB/sec
ThreadDumpProcessorBenchmark.newThreadDumpProcessor:·gc.churn.G1_Eden_Space.norm  thrpt   20  55887.646 ±  654.869    B/op
ThreadDumpProcessorBenchmark.newThreadDumpProcessor:·gc.churn.G1_Old_Gen          thrpt   20      0.007 ±    0.001  MB/sec
ThreadDumpProcessorBenchmark.newThreadDumpProcessor:·gc.churn.G1_Old_Gen.norm     thrpt   20      0.152 ±    0.027    B/op
ThreadDumpProcessorBenchmark.newThreadDumpProcessor:·gc.count                     thrpt   20   1672.000             counts
ThreadDumpProcessorBenchmark.newThreadDumpProcessor:·gc.time                      thrpt   20    818.000                 ms
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor                               thrpt   20   7104.011 ± 1856.952   ops/s
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor:·gc.alloc.rate                thrpt   20    433.509 ±  112.051  MB/sec
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor:·gc.alloc.rate.norm           thrpt   20  67276.673 ±  217.422    B/op
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor:·gc.churn.G1_Eden_Space       thrpt   20    434.048 ±  111.781  MB/sec
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor:·gc.churn.G1_Eden_Space.norm  thrpt   20  67417.861 ± 2075.981    B/op
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor:·gc.churn.G1_Old_Gen          thrpt   20      0.011 ±    0.005  MB/sec
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor:·gc.churn.G1_Old_Gen.norm     thrpt   20      1.531 ±    0.483    B/op
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor:·gc.count                     thrpt   20    300.000             counts
ThreadDumpProcessorBenchmark.oldThreadDumpProcessor:·gc.time                      thrpt   20    157.000                 ms

Maybe somebody can look at this and confirm what I'm seeing...and even better, maybe somebody can reproduce these results (they took about 15mins on my laptop).

Benchmark                                                                          Mode  Cnt      Score      Error   Units
newThreadDumpProcessor                               thrpt   20  47654.113 ± 1266.723   ops/s
oldThreadDumpProcessor                               thrpt   20   7104.011 ± 1856.952   ops/s

newThreadDumpProcessor:·gc.alloc.rate.norm           thrpt   20  55820.110 ±  571.208    B/op
oldThreadDumpProcessor:·gc.alloc.rate.norm           thrpt   20  67276.673 ±  217.422    B/op

new processor is almost 7 times faster and allocations 18% less memory :) Looks like success to me?

The non-normalized gc.alloc.rate is the other way around though.
The speed does indeed look like an improvement, but not the gc count?
I think I probably don't know how to read this output probably.

It's MB/sec, so I'm guessing that since the new algorithm allows much higher throughput more operations (= more allocations) execute in a second.


Error: Can't resolve './font-awesome-styles' when upgrading to<EMAIL_ADDRESS>

If I upgrade from webpack 1.x to 2.1.0-beta.6 I get the error
ERROR in ./~/font-awesome-webpack/index.js
Module not found: Error: Can't resolve './font-awesome-styles' in 'C:\Projects\git\AppCenter\AppCenter.WebApp\Assets\node_modules\font-awesome-webpack'
 @ ./~/font-awesome-webpack/index.js 1:0-72

The error goes away if I edit ...\node_modules\font-awesome-webpack\index.js from
require("style!css!less!./font-awesome-styles!./font-awesome.config.js");

to
require("style!css!less!./font-awesome-styles.loader!./font-awesome.config.js");

Yes, same issue for me.

Same issue for me.

Here's an entirely userspace fix (no need to edit the file in node_modules)
import 'style!css!less!font-awesome-webpack/font-awesome-styles.loader!font-awesome-webpack/font-awesome.config.js';

or
require('style!css!less!font-awesome-webpack/font-awesome-styles.loader!font-awesome-webpack/font-awesome.config.js');

Should this fix by JoeMattie be integrated into the index.js file in the source code?

Hi,
still have the issue with webpack2 too.. is it possible to fix this before the release of the stable release?

The provided fix also not working

Still have the issue with webpack2 as well

Yeah I'm having this issue still as well. The fix given by @JoeMattie did not work for me.

Release 0.0.5-beta.2 should fix this issue for you, a release 0.0.6 still needs to be made so that this is no longer an issue with normal installs of font-awesome-webpack.
Sorry for the delay in getting 0.0.6 out, I'll try to get it out soon.


Remove withXml { ... }

I forgot that withXml { ... } does not work with the embulk-plugins Gradle plugin.
It's not mandatory. Let's remove them now.

Oops, I forgot this...

Thanks!


draco 1.5.6

pdal package requires draco
Changelog: https://github.com/google/draco/releases
License: https://github.com/google/draco/blob/1.5.6/LICENSE
Requirements:

https://github.com/google/draco/blob/1.5.6/BUILDING.md
https://github.com/google/draco/blob/1.5.6/CMAKE.md
https://github.com/google/draco/blob/1.5.6/CMakeLists.txt

Actions:

Add patch to build
Use make on unix only

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_f0fe0k3hvd/clone/recipe/meta.yaml:21: patch_must_be_in_build: patch must be in build when source/patches is set.
ERROR: /tmp/abs_f0fe0k3hvd/clone/recipe/meta.yaml:22: patch_must_be_in_build: patch must be in build when source/patches is set.
Errors were found

maybe we want to have ninja but it works so, LGTM

Done!


Support for Artifactory Docker promotion API

Artifactory has a nice REST API call for promoting a docker image between repositories, allowing me the change the image tag in the process.
https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API#ArtifactoryRESTAPI-PromoteDockerImage
While I know that the jfrog-cli has support for a different workflow here where I add build info to a Docker image across build and release/promote CI stages
jfrog rt docker-pull  jfrog rt build-publish
and
jfrog rt build-promote

I tried to test this out and the build-promote failed saying it can't find the artifacts of the build. But honestly I would just prefer having a docker-promote command that calls the existing API.
jfrog rt docker-promote <repoKey> <dockerRepository>:<tag> <targetDockerRepository> [<targetTag>] [--copy]

I like being able to specify a target tag and dislike the spurious forcing of the Build feature on a workflow that doesn't really require it.

Here's the error I'm seeing with attempting to use the build-publish/build-promote workflow
$ docker pull docker.bintray.io/jfrog/jfrog-cli-go:1.35.3
1.35.3: Pulling from jfrog/jfrog-cli-go
Digest: sha256:63149fb84911280ed10a810c33bc89323b1c618cc9b0c437069c02f54881263b
Status: Image is up to date for docker.bintray.io/jfrog/jfrog-cli-go:1.35.3
docker.bintray.io/jfrog/jfrog-cli-go:1.35.3
$ docker tag docker.bintray.io/jfrog/jfrog-cli-go:1.35.3 devops-docker.repo.example.com/jfrog-cli-go:1.35.3
$ jfrog rt docker-push devops-docker.repo.example.com/jfrog-cli-go:1.35.3 devops-docker-snapshots --build-name jfrog-cli --build-number 1
WARNING! Your password will be stored unencrypted in /home/hbl4218/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
The push refers to repository [devops-docker.repo.example.com/jfrog-cli-go]
0135afc59e01: Pushed
8820917f39dd: Pushed
3fc64803ca2d: Layer already exists
1.35.3: digest: sha256:63149fb84911280ed10a810c33bc89323b1c618cc9b0c437069c02f54881263b size: 1161
[Info] Setting properties...

[Info] Build info successfully deployed. Browse it in Artifactory under https://repo.example.com/artifactory/webapp/builds/jfrog-cli/1
$ JFROG_CLI_LOG_LEVEL=ERROR jfrog rt s devops-docker --build jfrog-cli/1 | jq -r '.[].path'
devops-docker-snapshots/jfrog-cli-go/1.35.3/manifest.json
devops-docker-snapshots/jfrog-cli-go/1.35.3/sha256__5d20c808ce198565ff70b3ed23a991dd49afac45dece63474b27ce6ed036adc6
devops-docker-snapshots/jfrog-cli-go/1.35.3/sha256__475a77d520eff53794bea7b3ba4d61a23a0c33e0587b74a96a356439cc14ef41
devops-docker-snapshots/jfrog-cli-go/1.35.3/sha256__cd52e8cea908fa2be9a148d31ffcff54d1c515d1db4a6fbf2a8a3507450fc791
devops-docker-snapshots/jfrog-cli-go/1.35.3/sha256__b4f1e96eee44bd68078db7389a540f4af34d557198332542062def8275d02b8b
$ JFROG_CLI_LOG_LEVEL=DEBUG jfrog rt bpr jfrog-cli 1 devops-docker-staging
[Debug] Usage Report: Sending info...
[Info] Promoting build...
[Debug] Sending HTTP POST request to: https://repo.example.com/artifactory/api/build/promote/jfrog-cli/1
[Debug] Sending HTTP GET request to: https://repo.example.com/artifactory/api/system/version
[Debug] The Artifactory version is: 6.10.1
[Debug] Sending HTTP POST request to: https://repo.example.com/artifactory/api/system/usage
[Debug] Usage Report: Artifactory response: 200 OK
[Debug] Usage Report: Usage info sent successfully.
[Error] Artifactory response: 400 Bad Request
{
  "errors": [
    {
      "status": 400,
      "message": "Unable to find artifacts of build 'jfrog-cli' #1: aborting promotion."
    }
  ]
}

@jghal,
Thank you for reporting this issue and requesting this feature request.
Adding the new command seems like a good idea and we'll add it to our roadmap.
As for the issue you reported, we're looking into it right now and we'll report our findings here.
BTW - you can already invoke the api/docker/-repoKey-/v2/promote REST API with the jfrog rt curl command.

Thanks @eyalb4doc!
I did find the curl subcommand over the weekend and I have to say it's pretty nifty and it does unblock from using the jfrog/jfrog-cli-go Docker image in my pipelines. But I would still prefer the native subcommand because it can get pretty tricky to properly quote/escape raw JSON in a YAML file (which is the pipeline definition language du jour).

@jghal, I have created a fix for this bug https://github.com/jfrog/jfrog-cli/pull/685
Docker manifest may contain duplicate layers such as jfrog-cli-go:1.35.3 image, by promoting that image, Artifactory started to promote each layer and failed to locate the duplicate layers which exist only once.
As a result, a bad request was returned

@jghal, we released JFrog CLI v1.35.4 to resolve this issue.
Feel free to upgrade - We'll appreciate your feedback for that!

Thanks @Or-Gabay, will try it out.
Regarding the jfrog rt curl option to calling the docker promotion API, I found that it depends on there being a curl executable, and the jfrog/jfrog-cli-go Docker image lacks that (and also jq to parse json API responses), so still having a sub-command in jfrog-cli-go to call the API will be beneficial (I may file a feature request to add curl and jq to the official jfrog-cli-go Docker image too).

I appear to have long forgotten to report back here. The docker-promote command is working as desired (and also the current jfrog-cli-go Docker image has the curl executable added by now too).


Refactor force-directed graph

Extract slice and formData from visualization code.
Enable renderTrigger for props that are compatible.
Tested that it works like before.

Codecov Report

Merging #5691 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #5691      +/-   ##
==========================================
- Coverage   63.49%   63.48%   -0.02%
==========================================
  Files         360      360
  Lines       22934    22939       +5
  Branches     2555     2555
==========================================
  Hits        14562    14562
- Misses       8357     8362       +5
  Partials       15       15

Impacted Files
Coverage Δ

superset/assets/src/explore/controls.jsx
45.92% <ø> (ø)
:arrow_up:

superset/assets/src/explore/visTypes.jsx
57.14% <ø> (ø)
:arrow_up:

...perset/assets/src/visualizations/directed_force.js
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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