Gowin BSRAM inference -- We need B suffix (such as DPB instead of current DP)

Version
35
On which OS did this happen?
Linux
Reproduction Steps
https://github.com/YosysHQ/apicula/issues/208#issuecomment-1872635263
Expected Behavior
It's been a while since Gowin has added B suffix to their BSRAM primitives, to differentiate them from S(hadow) SRAM.
nextpnr-gowin (project Apicula) has updated the naming. However, Yosys seems to still be using the original nomenclature, creating a disconnect.
We need BSRAM to be inferred as DPB, not DP.
Actual Behavior
BSRAM is inferred as DP instead of DPB.

A patch that purely mechanically corrects memory synthesis. Now there will be less swearing when creating images, but this should not make them work.
b.path.txt
A good image is with direct use of the DPB primitive.
https://github.com/YosysHQ/yosys/assets/6075465/6746b0c4-dba3-40c1-9d1a-c1f99a81ebbe
Not a very good image - when we infer.
https://github.com/YosysHQ/yosys/assets/6075465/200afeaa-22e3-4b53-a685-7002d40971cb
And now a little of my stupid reasoning as a newbie.
When we use a primitive directly, we set its parameters (data width, address width, write mode, read mode, etc.), and also explicitly connect signals to the inputs of the primitive - that is, we decide what to connect to ClockEnable and what to WriteEnable.
    DPB mem(
        .DOB({dummy, read_data}),
        .DIA({{8{gnd}}, write_data}),
        .DIB({16{gnd}}),
        .ADA({write_ad, gnd, gnd, gnd}),
        .ADB({ read_ad, gnd, gnd, gnd}),
        .CLKA(write_clk),
        .CLKB(clk),
        .OCEA(vcc),
        .OCEB(vcc),
        .CEA(write_ce),
        .CEB(vcc),
        .WREA(vcc),
        .WREB(read_wre),
        .BLKSELA(3'b000),
        .BLKSELB(3'b000),
        .RESETA(write_reset),
        .RESETB(reset)
    );
    defparam mem.READ_MODE0 = 1'b1;
    defparam mem.READ_MODE1 = 1'b1;
    defparam mem.WRITE_MODE0 = 2'b01;
    defparam mem.WRITE_MODE1 = 2'b01;
    defparam mem.BIT_WIDTH_0 = 8;
    defparam mem.BIT_WIDTH_1 = 8;
    defparam mem.BLK_SEL_0 = 3'b000;
    defparam mem.BLK_SEL_1 = 3'b000;
    defparam mem.RESET_MODE = "SYNC";

In the case of inferring, yosys selects the primitive, parameters and used ports based on an analysis of memory usage. The Gowin documentation has a list of boilerplate pieces of code that lead to the generation of certain primitives. This is SUG550-1.6E_GowinSynthesis User Guide.pdf
Here's a typical snippet from there:

Instructions on how to select a primitive during inferring are in the files: techlibs/gowin/brams.txt and techlibs/gowin/brams_map.v
You can see what yosys chose for each case in the logs (with the -g switch) and in the output .json file after synthesis.
This is how I tried to get yosys to generate DPB for the goblin faces above.
    (* ram_style = "block" *) reg [7:0] mem[10:0];

    always @(posedge clk or posedge reset) begin
        if (reset) begin
            read_data <= 0;
        end else begin
            read_data <= mem[read_ad];
        end
    end

    always @(posedge write_clk) begin
        if (write_ce) begin
            mem[write_ad] <= write_data;
        end
    end

That's what yosys did:
        "vmem.mem.0.0": {
          "hide_name": 0,
          "type": "DPX9B",
          "parameters": {
            "BIT_WIDTH_0": "00000000000000000000000000001001",
            "BIT_WIDTH_1": "00000000000000000000000000001001",
            "BLK_SEL_0": "000",
            "BLK_SEL_1": "000",
            "READ_MODE0": "0",
            "READ_MODE1": "0",
            "RESET_MODE": "ASYNC",
            "WRITE_MODE0": "00000000000000000000000000000010",
            "WRITE_MODE1": "00000000000000000000000000000010"
          },
          "attributes": {
            "module_not_derived": "00000000000000000000000000000001",
            "src": "/usr/local/bin/../share/yosys/gowin/brams_map.v:282.4-303.3"
          },
          "port_directions": {
            "ADA": "input",
            "ADB": "input",
            "BLKSELA": "input",
            "BLKSELB": "input",
            "CEA": "input",
            "CEB": "input",
            "CLKA": "input",
            "CLKB": "input",
            "DIA": "input",
            "DIB": "input",
            "DOA": "output",
            "DOB": "output",
            "OCEA": "input",
            "OCEB": "input",
            "RESETA": "input",
            "RESETB": "input",
            "WREA": "input",
            "WREB": "input"
          },
          "connections": {
            "ADA": [ 45, 45, 45, 804, 805, 806, 807, 45, 45, 45, 45, 45, 45, 45 ],
            "ADB": [ 45, 45, 45, 885, 884, 883, 882, 45, 45, 45, 45, 45, 45, 45 ],
            "BLKSELA": [ 45, 45, 45 ],
            "BLKSELB": [ 45, 45, 45 ],
            "CEA": [ 66 ],
            "CEB": [ 66 ],
            "CLKA": [ 880 ],
            "CLKB": [ 30 ],
            "DIA": [ 886, 887, 888, 889, 890, 891, 892, 893, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45 ],
            "DIB": [ 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45, 45 ],
            "DOA": [ 894, 895, 896, 897, 898, 899, 900, 901, 902, 903, 904, 905, 906, 907, 908, 909, 910, 911 ],
            "DOB": [ 761, 728, 694, 660, 425, 794, 912, 913, 914, 915, 916, 917, 918, 919, 920, 921, 922, 923 ],
            "OCEA": [ 45 ],
            "OCEB": [ 45 ],
            "RESETA": [ 45 ],
            "RESETB": [ 196 ],
            "WREA": [ 66 ],
            "WREB": [ 45 ]
          }
        },

Considering that wires 45 are GND, and 66 are VCC, it is already clear why there is garbage on the screen (partially): the WREA and CEA signals are always VCC, which means writing is always going on, although I clearly indicated that writing needs to be done only at certain moments.
And that’s not all that is not entirely correct with the parameters and ports.
To summarize: if for a guru it’s immediately obvious what little things need to be corrected for proper synthesis, then for me it’s a dark forest. Dual Port is too complex for inferring to understand and I plan to start experimenting with ROM and gradually move towards more complex options. And it doesn’t help matters that BSRAM in Tangnano9k may behave differently than in the documentation.

The bit order (reading from the "connection" entry) seems to be reversed in the inferred version. Could this be part of the problem?

Thank you, at this stage any advice is useful to me.
But I think that in JSON, after synthesis, the low-order bits of the buses are located on the left. Well, at least when using the primitive explicitly, I get:
            "BLKSELA": [ 39, 39, 39 ],
            "BLKSELB": [ 39, 39, 39 ],
            "CEA": [ 66 ],
            "CEB": [ 66 ],
            "CLKA": [ 843 ],
            "CLKB": [ 30 ],
            "DIA": [ 904, 905, 906, 907, 908, 909, 910, 911, 39, 39, 39, 39, 39, 39, 39, 39 ],
            "DIB": [ 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39 ],
            "DOB": [ 724, 691, 657, 623, 392, 757, 912, 913, 914, 915, 916, 917, 918, 919, 920, 921 ],
            "OCEA": [ 66 ],
            "OCEB": [ 66 ],

However, your observation made me reconsider my examples and I found a couple of errors. Thanks!
:)

I'm happy to hear that, and glad to help however I can. I'll keep looking to see if I observe any other differences. Is there any chance you could share your examples?

This is just a simplified example from the apicula distribution: https://github.com/YosysHQ/apicula/tree/master/examples/himbaechel
bsram.ZIP
Here are two directories that are copies except for the DPB-video-ram.v file.
If you applied the yosys patch (see previous posts) and have himbaechel nextpnr installed (see https://github.com/YosysHQ/apicula/issues/220#issuecomment-1876682997) then everything should compile.
The build goes like this:
make -f Makefile.himbaechel bsram-DPB-tangnano9k.fs

And yes, I know that I use an 8-bit primitive, and yosys makes 9-bit, but at the moment this is unimportant: as long as inferring ignores CE and WRE for writing, there will be garbage on the screen.

Corrected version (I had to regenerate the JSON) now infer the WRE port as connected to the network. This is not CE, but it will also do.

The picture, however, is still garbage, so we think further about what’s going on here: did I screw it up in the top-level code or is it still not good to use a 9-bit primitive for 8-bit memory
https://github.com/YosysHQ/yosys/assets/6075465/440e219a-b166-4fb7-8f2e-719b90b8c0b1

Something interesting. I wonder what I wrote incorrectly in the top-level code that yosys decided that 4 bits for the address is enough?
The upper JSON is inferring, the lower one is manual use of the DPB primitive.
@Seyviour You have all the source codes, can you tell me where I managed to turn the address [10:0] into [3:0]?

This is just a simplified example from the apicula distribution: https://github.com/YosysHQ/apicula/tree/master/examples/himbaechel
bsram.ZIP
Here are two directories that are copies except for the DPB-video-ram.v file.
If you applied the yosys patch (see previous posts) and have himbaechel nextpnr installed (see https://github.com/YosysHQ/apicula/issues/220#issuecomment-1876682997) then everything should compile.
The build goes like this:
make -f Makefile.himbaechel bsram-DPB-tangnano9k.fs

And yes, I know that I use an 8-bit primitive, and yosys makes 9-bit, but at the moment this is unimportant: as long as inferring ignores CE and WRE for writing, there will be garbage on the screen.

Thank you for sharing! Would a Yosys build from source (without the patch) work as well?

@yrabbit
As I understand it, since the array has 11 elements ([10:0]), only 4 bits are required to represent any index into the array (log2(11)).
For a memory with a 11-bit address, the declaration would be something like: reg [7:0] mem [2**11-1 :0]

Thank you for sharing! Would a Yosys build from source (without the patch) work as well?

No. but you can avoid compiling yosys if after installation you find where the brams.txt and brams_map.v files are located in your system and correct it right there.

@yrabbit
As I understand it, since the array has 11 elements ([10:0]), only 4 bits are required to represent any index into the array (log2(11)).
For a memory with a 11-bit address, the declaration would be something like: reg [7:0] mem [2**11-1 :0]

I told that I'm very bad at verilog :)
And thanks to @Seyviour  we have working memory!!!
https://github.com/YosysHQ/yosys/assets/6075465/5747448e-229c-4150-ba4f-32fa8606e79c
It works like crap, but still! Here is a reference video from a manual primitive
https://github.com/YosysHQ/yosys/assets/6075465/368e60eb-9ff1-424b-b2cf-939c1d9c4173

This is amazing, @yrabbit. Thank you very much!
I'm currently trying to figure out SDRAM for the GW2A chips; do you have any tips on how I could go about getting that to work?

Well, the happy ending is still far away - the picture should be the same as that of a hand-made primitive.
As for SDRAM, sorry, I've never done this. Is this something external to the FPGA? Not primitive?

... this is a unique trait of Gowin devices which have SDRAM chiplet connected to FPGA die within package (SIP).
This SDRAM is essentially external to FPGA and not a primitive. However, it is also "loosely internal", because it is consuming FPGA pins which are therefore not externally visible.
Those pins in Gowin proprietary tools don't have pin numbers. They have specific pin names which tool recognizes as "internal connections" to then, under the hood, translate to the actual FPGA pin number. RTL tapping into this in-the-package SDRAM has to use the exact pin names that Gowin tool recognizes. For back-and-forth RTL porting, opensource tools should adhere to the same naming convention.
For more, see: https://github.com/nand2mario/nestang/blob/master/src/sdram.v

For the preassigned SDRAM pin names, see: https://github.com/nand2mario/nestang/blob/master/src/nestang_top.sv

// SDRAM
// For Primer 25K: https://github.com/MiSTer-devel/Hardware_MiSTer/blob/master/releases/sdram_xsds_3.0.pdf
// For Nano 20K: 8MB 32-bit SDRAM
output O_sdram_clk,
output O_sdram_cke,
output O_sdram_cs_n,            // chip select
output O_sdram_cas_n,           // columns address select
output O_sdram_ras_n,           // row address select
output O_sdram_wen_n,           // write enable
inout [SDRAM_DATA_WIDTH-1:0]    IO_sdram_dq,      // bidirectional data bus
output [SDRAM_ROW_WIDTH-1:0] O_sdram_addr,     // multiplexed address bus
output [1:0] O_sdram_ba,        // two banks
output [SDRAM_DATA_WIDTH/8-1:0]   O_sdram_dqm,

If we slightly adjust the JSON that is obtained at the output of the inferring version, namely, turn on reading mode 1 and enable the output of the output register built into the memory by applying VCC to the OCEB input, then we will get a perfect match of the pictures.
Which, naturally, suggests an idea, I don’t know what yet.
Something in the code generated by yosys stretches the pixels by half horizontally. It is logical to assume that it is the address, but no - this would not be cured by turning on the register at the output. Hmm... unclear...

https://github.com/YosysHQ/yosys/assets/6075465/43600b1a-bd2e-499b-b51c-76fd29a22d8d

I noticed one more thing - the infer and primitive versions start differently - the primitive normally handles the initial memory filling, while the infer version has a black screen.
Let's deal with this first.

Infer version start:
https://github.com/YosysHQ/yosys/assets/6075465/deb3b1e0-a198-4310-9555-1c5ab40fd4b1
Infer version with READ_MODE=1 start:
https://github.com/YosysHQ/yosys/assets/6075465/d2241891-6c30-41ce-9c2a-8760bc5a624d
The lower video especially shows how the horizontal resolution improves dramatically when the version with READ_MODE=1 is loaded and launched into the FPGA.
It seems that with READ_MODE=0 we somehow manage to use one byte from memory to output two adjacent points, while with READ_MODE=1 each point uses its own byte from memory.
But this is not a property of this parameter - it just shifts the byte output by one clock cycle. No ideas yet :(

Thank you, @chili-chips for your comments on the SDRAM.
My apologies to you, @yrabbit for taking this long to respond; @chili-chips comments pretty much sum it up. I'd like to find the location and (hidden) pins that map to the SDRAM and figure out routing to those pins. It's probably more something to be done in Nextpnr rather than in Yosys.

Ah. I also noticed that the pixels were getting repeated along the horizontal but I thought it was the writes that were failing because the instantiated version used the clock enable of the BRAM, unlike the version inferred by Yosys. Evidently, I was wrong about that :) I'll look at the timing diagram from the Gowin manual to see if I find anything that might be useful.
@yrabbit, it seems we don't have an equivalent of the ````include "img-video-ram.vh"statement that initializes the ram for the primitive version. I'll try to initialize viareadmemh``` and report what I find.

I'd like to find the location and (hidden) pins that map to the SDRAM and figure out routing to those pins. It's probably more something to be done in Nextpnr rather than in Yosys.

That's right. We recommend diving into the depths of the final bit-file for this example:
https://wiki.sipeed.com/hardware/en/tang/tang-nano-20k/example/unbox.html

I was in a hurry. Apparently I'm still doing something wrong. This is how I initialize the memory:
    (* ram_style = "block" *) reg [7:0] mem[2**11-1:0];
    always @(posedge clk or posedge reset) begin
        if (reset) begin
            read_data <= 0;
        end else begin
            read_data <= mem[read_ad];
        end
    end

    always @(posedge write_clk) begin
        if (write_ce) begin
            mem[write_ad] <= write_data;
        end
    end
    initial begin
        $readmemh("img0.hex", mem);
    end

Here is the very beginning of the data file:
04
14
54
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00

Here is the entire data file:
img0.hex.txt
And this is what happens in JSON after synthesis:
        "vmem.mem.0.0": {
          "hide_name": 0,
          "type": "SPX9",
          "parameters": {
            "BIT_WIDTH": "00000000000000000000000000001001",
            "BLK_SEL": "000",
            "INIT_RAM_00": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000110100000010100000000100",
            "INIT_RAM_01": "000001001000001001000001001000001010000001010000001011000001100000001100000001101000001101000001110000001110000001110000001110000001111000001111000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",

Of course, yosys chose a 9-bit primitive, but even the 9-bit initialization line looks strange: already from the third byte there was a discrepancy with the data file:
...000110100000010100000000100 -> 0 0011 0100 0 0001 0100 0 0000 0100 = 34 14 04

How can 34 come out of 54? I messed something up.

Changed the initial memory initialization bytes to
00
04
08
0C
10
14
18
1C
20
24
28
2C
30
34
38
3C
00
00
00
00
00

Result on the address inputs of the primitive and display pins (! this is important) in the READ_MODE=1 option

The Clock, the least significant three bits of the address, and all the green channel bits are shown.
An enlarged piece, where you can see after how many clock cycles and on which edge the data is changed after the address change:

Why is it important that the data is taken from the display pins - between the memory outputs and the display pins there are several LUTs and MUXes (which, for now, we will assume that they do not introduce delay) and one DFF, which can have some effect.
And I made a repository so as not to constantly pack these files: https://github.com/yrabbit/bram-infer

And here’s what happens with READ_MODE_0, again on the display pins:

Some thought is floating in the air, something opaque... maybe it’s all about this DFF that we have in front of the display? What if we get rid of it and just say that we already have DFF inside the primitive? I do not know yet...

Given the impact of the register (as dictated by the read_mode), perhaps we should consider that the design somehow doesn't meet timing when READ_MODE is 0.
Maybe you can check how the instantiated  version performs when it has READ_MODE=0 :thinking:

I'll try to rework the address generation so that it happens on the preceding posedge rather than a negedge to see if that helps.

This is what I propose. Forgive the weird naming and formatting here :)
        reg 		[15:0] __pixel_count;
	reg	        [15:0] __line_count;
	reg 		[7:0] __vmem_start_col;
	reg 		[7:0] __vmem_start_row;

	always @(*) begin
		if (pixel_count == PixelForHS) begin
                        __pixel_count      =  16'b0;
                       __line_count       =  line_count + 1'b1;
                end
                else if (line_count == LineForVS) begin
                       __line_count       =  16'b0;
                       __pixel_count      =  16'b0;
                end
                else begin
                       __pixel_count      =  pixel_count + 1'b1;
                end

		      __vmem_start_col = __pixel_count - `START_X;
		      __vmem_start_row = __line_count - `START_Y;
	end

	reg           [7:0] vmem_start_col;
	reg           [7:0] vmem_start_row;

	always @(posedge pixel_clk or negedge rst)begin
        if (!rst) begin
                         line_count           <=  16'b0;
                        pixel_count           <=  16'b0;
			vmem_start_col	 <=  0 - `START_X;
			vmem_start_row	 <=  0 - `START_Y;
            end
        else begin
			pixel_count 	         <= __pixel_count;
			line_count 		 <= __line_count;
			vmem_start_col	 <= __vmem_start_col;
			vmem_start_row	 <= __vmem_start_col;
		end
	end

I'll create a PR on the repo you created

Maybe you can check how the instantiated version performs when it has READ_MODE=0 🤔

Well, I play with it exclusively - I don’t touch the version with the primitive.
The last pictures with both READ_MODE=1 and READ_MODE=0 refer to it.

I'll create a PR on the repo you created

I'm waiting:)

Done :)

I'll create a PR on the repo you created

I'm waiting:)

Done :)

mmm... this is not good - I can't orient the logic analyzer because there are so many overlays on the screen. and the goblin disappeared :(

пропробую с READ_MODE=1

I'll create a PR on the repo you created

I'm waiting:)

Done :)

mmm... this is not good - I can't orient the logic analyzer because there are so many overlays on the screen. and the goblin disappeared :(
I'll try with READ_MODE=1

I must have got something wrong. I'll double check and send an update.

nope, still

I think I found my mistake:
  vmem_start_row	 <= __vmem_start_col;

I've submitted a new PR

READ_MODE=1
https://github.com/YosysHQ/yosys/assets/6075465/1beab2b9-c76a-4312-8b31-e6dcb8ac73d8

READ_MODE=1
https://github.com/YosysHQ/yosys/assets/6075465/96ef1fe2-3d3d-4317-8149-91a84858064c

I recognize by the eyes when there are byte gaps and when there are not: if the eyes consist of three horizontal dots, then there is no gap :)
And it looks like you removed the check that prohibited drawing the goblin outside the central square, now his ghosts are everywhere :)

Oh my. Did I affect the color of the goblins too? :)
I'll keep looking to see what I got wrong.

So, I can say with absolute confidence that the green color is connected directly to the memory output, there are no DFFs, LUTs or MUXs between the memory and the pin.

In light of this we have:
Let me remind you that the values 0h, 4h, 8h, Ch, 10h, 14h, 18h and so on are written from address 0.
The option with READ_MODE_1 is a good picture, bytes are not thrown out, edges are shown when address 1 is set and when the number 4h stored there is output:

And now the option with READ_MODE=0
Let me remind you that I only change the line with the READ_MODE parameter in JSON, so no routes or anything else changes. The addresses are set identically along the same edges, maintained for the same number of clock cycles, but the output is who knows what.
Still a mystery.

So, I can say with absolute confidence that the green color is connected directly to the memory output, there are no DFFs, LUTs or MUXs between the memory and the pin.
In light of this we have: Let me remind you that the values 0h, 4h, 8h, Ch, 10h, 14h, 18h and so on are written from address 0. The option with READ_MODE_1 is a good picture, bytes are not thrown out, edges are shown when address 1 is set and when the number 4h stored there is output:
And now the option with READ_MODE=0 Let me remind you that I only change the line with the READ_MODE parameter in JSON, so no routes or anything else changes. The addresses are set identically along the same edges, maintained for the same number of clock cycles, but the output is who knows what. Still a mystery.

Is this connection the same for READ_MODE=0 and READ_MODE=1? I guess that might make sense since/if the output register is internal to the RAM?
Also, I'm trying to find any code that references the READ_MODE and I did not find anything particularly useful across yosys, apicula, and nextpnr. From brams.txt, I can see WRITE_MODE, but no READ_MODE.
Do you have any pointers on where I might find the code that decides READ_MODE  or handles it? Maybe the answer is not in yosys :tired_face:

@yrabbit. This might be worth trying: With READ_MODE=0, left shift or right shift the address by 1-bit to see what happens. Probably, things get worse, but there's a small chance we observe something interesting.

Is this connection the same for READ_MODE=0 and READ_MODE=1? I guess that might make sense since/if the output register is internal to the RAM?

Of course it’s the same: I change READ_MODE directly in JSON after synthesis, so routing and so on are exactly the same ;)

Also, I'm trying to find any code that references the READ_MODE and I did not find anything particularly useful across yosys, apicula, and nextpnr. From brams.txt, I can see WRITE_MODE, but no READ_MODE.
Do you have any pointers on where I might find the code that decides READ_MODE or handles it? Maybe the answer is not in yosys 😫

Yeah, I think that it is not processed anywhere, but is simply set as 0 once and for all.
And this is just funny - if mode 1 had been set there, then we would not have noticed this problem in real life - everything would have worked (well, with a delay of one clock, but it would have looked correct) :wink:
https://github.com/YosysHQ/yosys/blob/242ae4ef017a60c0e9231ed466e0431fc43dcfc9/techlibs/gowin/brams_map.v#L349

@yrabbit. This might be worth trying: With READ_MODE=0, left shift or right shift the address by 1-bit to see what happens. Probably, things get worse, but there's a small chance we observe something interesting.

Yes, it may be something related to the input lines, today I will read how this primitive is encoded into bits. I couldn’t make a cardinal mistake - in this case, not a single primitive would work at all - but I could have missed some rare feature.

I found it :smile: When READ_MODE=0, the OCEx inputs must be set to 1.
Now the data is spit out on the next clock cycle after the address is set and no bytes are skipped.
Time to brush up on PR.

Congratulations!!! Now no more half-eyed goblins :) And thanks for the shout-out on the PR :pray:
I think there might be one more thing to consider:

As I understand things, the idea for the 'bypass' mode is that the read operation should be combinational, in the sense that the output should be available before the next rising edge, and the timing diagram from the manual seems to support this. How do we test that this is the case?

Fixed by https://github.com/YosysHQ/yosys/pull/4137

I think there might be one more thing to consider:

As I understand things, the idea for the 'bypass' mode is that the read operation should be combinational, in the sense that the output should be available before the next rising edge, and the timing diagram from the manual seems to support this. How do we test that this is the case?

Well, it doesn't work like that. I made a repository with an example for Gowin IDE (https://github.com/yrabbit/gw-bsram-infer). It uses SDPB with READ_MODE=0, the outputs of the primitive are connected directly to pins without intermediate pieces. Launch result:

You can compile the project, but I think it’s enough to look at the intermediate verilog: https://github.com/yrabbit/gw-bsram-infer/blob/master/impl/gwsynthesis/bram-infer-gw.vg
There you can see that the exits go straight to OBUF.
So I think we won't dig any further if their own IDE doesn't do what the documentation says :wink:

Ah. I see. Their IDE should be the final source of truth. Thanks for looking into it!! :rocket:

Well, yeah, images generated by the vendor’s IDE are the last resort, and not because they are true - there may be a lot of errors in IDE - but because no one will give us internal documentation :smile:


How to run chime on google colab?

No idea! I suppose you tried and it didn't work? I'll add a todo to take a look, but not sure it's possible because it's a remote computer.


useSoftInputShown hook did not remove listener on first screen.

Environment
Library version: YES
OS version: SUMSUNG A53 5G ( ANDROID 13 )
Affected platforms

[X] Android
[ ] iOS

Current behavior
I've two screens first login 2nd forgot password.
when I enter in login it's working fine then I go to forgot password it's breaking the screen.
I'm using Sticky footer recipe example in app.
https://github.com/mateusz1913/react-native-avoid-softinput/assets/132438054/2c7a58b2-a149-42b6-bd0f-a4d9d5b9b6f5
Expected behavior
expected behavior should be same as shown in Sticky footer recipe example
Reproduction
https://github.com/mateusz1913/react-native-avoid-softinput/blob/main/packages/app/src/screens/StickyFooterExample.tsx

👋 @danish5454 please provide a snack or GH link to the minimal reproduction of the app shown in the recording (putting the link to StickyFooterExample is not enough, as it doesn't have any navigation to next screen, like forgot password in your case)

Closing as there's no repro link provided and no activity under the issue


Adding SQL DW

@TwoUnder : Thanks for your contribution to the Azure documentation! The author, @rothja, has been notified to review your proposed change.

@TwoUnder Thanks for the added section. FYI, @barbkess. #sign-off


How to use gfx-rs correctly and what about GLFW and Vulkan?

Hello everyone,
I've recently switched from C++ to Rust for game development. I'm recreating my engine and so far I'm pretty happy with Rust and it's wonderful community. Back in C++ I used bgfx https://github.com/bkaradzic/bgfx as a rendering abstraction library. Now I want to use gfx-rs. But I'm a little confused:  at the docs https://docs.rs/gfx/0.18.2/gfx/ they write about Factory and Device in the crate gfx. But at the gfx examples (in this repo) they never use them. They also always use "hal" instead of "gfx" so what up with that? What is the current correct way to use this library? Also I've seen gfx-window-glfw uses an OpenGL Device - but is it still possible to use Vulkan then?
Thanks in advance and sorry for this dump question!
Best Regards,
Mario

Hi!
You are looking at the wrong crate. Check out the readme, it has links to gfx-hal crate as well as a section explaning what gfx crate was.
Another thing is - published version is not the same as the master version, the latter is always a bit ahead, so examples would have slightly different code too. If you are looking for the example code for the last published version, you need to see the hal-0.5 branch.
Finally, if you are used to bgfx, I recommend looking at https://github.com/gfx-rs/wgpu-rs instead. gfx-hal is extremely low level and unsafe, it would be a difficult thing to grasp right off the bat.

Hey,
I apologize for that - didn't see it!
I know gfx-hal is low level but I recently started to learn Vulkan so it's okay.
Just by the way to you know any examples with gfx-hal wich are using 3D meshes? Like a cube or triangle example? I wasn't able to find any!
Thank you,
Mario

@MarioSieg the most complex example using gfx-hal directly is https://github.com/gfx-rs/gfx-ocean
Other things go through wgpu-rs or Rendy, e.g. https://github.com/termhn/rendy-pbr


Repo sync for protected CLA branch

The pull request is created from master637600668716800158 to master to fix git push error for protected CLA branch

@Taojunshen : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Dependabot

move the dependency to another directory

Codecov Report

Merging #22 (a823e52) into master (92ca082) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master       #22   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           38        38
  Lines          867       867
=========================================
  Hits           867       867

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 92ca082...a823e52. Read the comment docs.


Update feat/dana to dev branch for Trio and DanaKit

I thought it better to leave the .gitmodules pointing to bastiaanv repository for now.
One less indirection as Basiaan adds improvements to his repository
This PR brings this feat/dev branch up to date with dev as of today.
There are a lot of commits, but the file diffs should be appropriate

% git diff dev update_feat/dana --name-status
M       .gitmodules
M       CGMBLEKit
A       DanaKit
M       FreeAPS.xcodeproj/xcshareddata/xcschemes/Trio.xcscheme
M       FreeAPS/Sources/APS/DeviceDataManager.swift
M       FreeAPS/Sources/Modules/PumpConfig/PumpConfigDataFlow.swift
M       FreeAPS/Sources/Modules/PumpConfig/View/PumpConfigRootView.swift
M       FreeAPS/Sources/Modules/PumpConfig/View/PumpSetupView.swift
M       LoopKit
M       MinimedKit
M       Trio.xcworkspace/contents.xcworkspacedata
M       scripts/swiftformat.sh

Summary - Mac-Xcode

build using this branch with Mac and Xcode
this PR includes the modifications from PR #329
successful build and install on test phone.

Summary - Browser Build

build using GitHub actions
successful build and install on test phone

I've been using the Dana driver for a while now and I can say that it's stable enough for me. The only drawback is the missing heartbeat. Because of the "silent ton enabled", I have to recharge my iPhone 14 Pro once a day. Normally the battery easily lasts the whole day. Otherwise I'm very satisfied.😀 Thanks to Bastiaan. 🙏

The DanaKit submodule is synced to the correct and stable version of the driver. I cannot speak about the other changes, but they are looking good!


boards: arm: Add support for the VBLUno51 board

VBLUno51 board
nRF51822
Bluetooth Low Energy
DAPLink interface
UNO pinout
4 power

Wiki: https://vngiotlab.github.io/vbluno/

The following samples were tested:
hello_world
basic/button
basic/blinky
bluetooth/peripheral_hr
bluetooth/beacon

Signed-off-by: Nam Do<EMAIL_ADDRESS>

@galak  @cvinayak : I closed the old PR and create new PR.
I am really sorry about this inconvenience.

@iotvietmember you should prefix your commit with "boards:". Something like:
boards: Add support for the VBLUno51 board

@galak, @dbkinder, @carlescufi : I have just fixed the recommended problems. Many thanks

Nit picking here, but commit message should be (mostly picking on the space after ':'):
board: arm: Add support for the VBLUno51 board

@dbkinder look good?

Hi @dbkinder, I have just fixed the recommended problems. Many thanks for your help.

@dbkinder, thanks for your help

Many thanks


Where is texture_img_train.pkl?

When running the training code, the following error occurs:
FileNotFoundError: [Errno 2] No such file or directory: '../data_texture/texture_img_train.pkl'
Where can I find texture_img_train.pkl, or how can I create it?

When running the training code, the following error occurs: FileNotFoundError: [Errno 2] No such file or directory: '../data_texture/texture_img_train.pkl' Where can I find texture_img_train.pkl, or how can I create it?

Have you solved this problem?


Moonshot does NOT support Function Calling

Contrary to the current docs claims the Moonshot Chat model doesn't support Function Calling.
Adding the attache function calling integration tests lead to messages like this:
Expecting actual:
  "As an AI, I don't have real-time access to current data such as weather. However, I can guide you on how to find this information.

1. **San Francisco**: You can check the weather by searching "San Francisco weather" on a search engine like Google or using a weather app on your smartphone. The temperature will usually be displayed in Fahrenheit, but you can often switch to Celsius.

2. **Tokyo**: Similar to San Francisco, search "Tokyo weather" on a search engine or use a weather app. Tokyo's temperature is generally displayed in Celsius.

3. **Paris**: Again, search "Paris weather" or use a weather app. Paris' temperature is typically displayed in Celsius.

Remember, the temperature can vary throughout the day, so it's a good idea to check the weather forecast for the time you're interested in."
to contain:
  ["30", "10", "15"]
but could not find:
  ["30", "10", "15"]

Archive.zip

fix this in the PR https://github.com/spring-projects/spring-ai/pull/1114


Fix some packages not upgrading in Debian

Only mongodb-org and mongodb-org-server are upgrading, the rest are left in current state. This is because when installing multiple packages we need to specify version for each one of them using array notation, otherwise only the first package is being checked against specified version number. In this case it was mongodb-org-server, which is why it was successfully upgraded. Ultimately, it's easier to just run install for each package individually, which is what this change does.
Reference: https://docs.chef.io/resource_package.html#multiple-packages.

I guess this is not needed anymore since https://github.com/sous-chefs/mongodb/pull/222 has been merged instead.


Nothing happen when call to executeSql

Sometime in Android device, txn.executeSql not return anything, ( even error or success functions are not triggering ) .  this is my code.
namespace DbConnection {
    export function getInstance() {
        return SQLite.openDatabase('test.db', '1.0', 'Test DB', 200000);
    }
}

class AdsDB {

    adsQueue: AdsQueue;

    constructor() {

    }

    successCB() {
        alert('DONE');
    }

    openCB() {
        // alert('DB Opened');
    }

    errorCB(error) {
        alert(JSON.stringify(error));
        return false;
    }

    getNextTrack(round: number, callback: (error: any, response?: any) => void) {
        DbConnection.getInstance().transaction((txn) => {

        -------------> GETTING TO HERE

            txn.executeSql(`SELECT * FROM PlayList WHERE round=:round AND playing_status=:playing_status
            AND played_count <= max_playable_count ORDER BY priority limit 1`, [round, 'PENDING'], (tx, res) => {

                ------------>  NOT GETTING TO HERE ..

                callback(undefined, res.rows.item(0));
            }, (error) => {
                ------------>  NOT GETTING TO HERE AS WELL ..
                callback(error);
            });
        });
    }
}

Please provide me enough information to reproduce it.
You can reuse the test code here: https://github.com/craftzdog/react-native-sqlite-2/blob/master/test/app.js
Don't forget to put your android version.

Try change the name of database within ".db".
{
name: 'Database',
createFromLocation: '~/www/Database.db',
}

not work for me

not work for me

Did anyone ever figure this bug out? I'm hitting this exact same problem and it's super annoying. Works perfectly every single time on Android simulator, but never once works or fires either the success callback or the error callback on my physical android device.


[router] 4.14 Enforce a recommended minimum number of required confirmations

Fixes #161
Blocked by https://github.com/connext/chaindata/pull/29

Current error in integration
[app] [1629353763330] ERROR (0xDc150c5Db2cD1d1d8e505F824aBd90aEF887caC6/17073 on DESKTOP-9VH1R8A): Error in auction request
[app]     requestContext: {
[app]       "id": "jOv8W7wOQL+iJO/HaWnsJQ/0",
[app]       "origin": "subscribeToAuctionRequest"
[app]     }
[app]     err: {
[app]       "message": "No provider was found for chain 1337! Make sure this chain's providers are configured.",
[app]       "context": {},
[app]       "type": "NxtpError",
[app]       "stack":
[app]           Error: No provider was found for chain 1337! Make sure this chain's providers are configured.
[app]               at TransactionService.getProvider (/home/jakekidd/nxtp/packages/txservice/dist/txservice.js:273:19)
[app]                   -> /home/jakekidd/nxtp/packages/txservice/src/txservice.ts:327:13
[app]               at TransactionService.getDecimalsForAsset (/home/jakekidd/nxtp/packages/txservice/dist/txservice.js:188:35)
[app]                   -> /home/jakekidd/nxtp/packages/txservice/src/txservice.ts:224:31
[app]               at newAuction (/home/jakekidd/nxtp/packages/router/dist/lib/operations/auction.js:70:19)
[app]                   -> /home/jakekidd/nxtp/packages/router/src/lib/operations/auction.ts:106:15
[app]               at Object.auctionRequestBinding (/home/jakekidd/nxtp/packages/router/dist/bindings/messaging/auctionRequest.js:17:41)
[app]                   -> /home/jakekidd/nxtp/packages/router/src/bindings/messaging/auctionRequest.ts:21:39
[app]               at /home/jakekidd/nxtp/packages/router/dist/bindings/messaging/index.js:15:36
[app]                   -> /home/jakekidd/nxtp/packages/router/src/bindings/messaging/index.ts:17:13
[app]               at /home/jakekidd/nxtp/packages/utils/dist/messaging.js:381:20
[app]                   -> /home/jakekidd/nxtp/packages/utils/src/messaging.ts:487:16
[app]               at /home/jakekidd/nxtp/packages/utils/dist/messaging.js:363:20
[app]                   -> /home/jakekidd/nxtp/packages/utils/src/messaging.ts:465:14
[app]               at /home/jakekidd/nxtp/packages/utils/dist/messaging.js:200:13
[app]                   -> /home/jakekidd/nxtp/packages/utils/src/messaging.ts:231:7
[app]               at Object.callback (/home/jakekidd/nxtp/node_modules/ts-natsutil/dist/cjs/nats.js:133:115)
[app]                   -> /home/jakekidd/nxtp/node_modules/ts-natsutil/src/nats.ts:131:59
[app]               at ProtocolHandler.processMsg (/home/jakekidd/nxtp/node_modules/ts-nats/lib/protocolhandler.js:874:25)
[app]                   -> /home/jakekidd/nxtp/node_modules/src/protocolhandler.ts:951:25
[app]     }


Image description: Miniopterus fuliginosus 1.jpg

Which image is this for?
Miniopterus fuliginosus 1.jpg
What is your suggested image description?
A plump bat with glossy chocolate-brown fur, wings folded, clinging to a wall with its back feet.

Thanks for contributing this description! It's been added to the data set without modification.


Debug flaky integration tests

[ ] I created a issue to discuss the problem I am trying to solve or there is already a open issue.
[ ] I added a new entry to CHANGELOG.md
[ ] I updated documentation if applicable (docs folder)

To help myself think about this problem and to document progress, I'm going to give a quick report.
I've added logging at several layers. I'm currently focused on an exception that is showing up in the logs. The problem with this exception is that though it could potentially describe the behavior of the flaky tests (though not explain it), it happens within some newly enabled logging code. So, there's a chance that the exception I'm seeing is actually a bug in that logging code, and isn't the same as what's causing the tests to fail.
Anyway, let me explain what I see in the logs in a bit more detail. I have the server's i/o routed through tees that log what's coming in from stdin or going to stdout. (Each one does its work in a separate thread.)
(tee-system-in system-in)
returns is, which server can read from, such that
                       |-> is -> server
                 /---> os
system-in -> buffer -> logger

(tee-system-out system-out)
returns os, which server can write to, such that
server -> os
          |-> is -> buffer -> system-out
                        \---> log

This means that instead of holding System/in and System/out, the server holds proxy stream objects, is, and os. A request comes in from the client. The server generates a response and writes it to the out stream, os. This gets teed off into a log and written to system-out. The output thread then loops, reading from its internal is again.
Occasionally this read throws an error. The exact error is:
                              java.lang.Thread.run              Thread.java:  750
java.util.concurrent.ThreadPoolExecutor$Worker.run  ThreadPoolExecutor.java:  624
 java.util.concurrent.ThreadPoolExecutor.runWorker  ThreadPoolExecutor.java: 1149
                                               ...
                 clojure.core.async/thread-call/fn                async.clj:  484
                    lsp4clj.core/tee-system-out/fn                 core.clj:  365
                     java.io.PipedInputStream.read    PipedInputStream.java:  377
                     java.io.PipedInputStream.read    PipedInputStream.java:  310
java.io.IOException: Write end dead

I'm still reading up on what this error means. I don't think it's the same as having os closed. In fact, I think if os were closed, then (read is ...) would return -1, which our code handles gracefully. Instead, I think this is saying that the JVM somehow knows that the os that the server holds can't be written to anymore, and so reads from the paired is are futile. (Does the JVM track all the threads that could potentially write to os, and this exception happens when they're all dead?)
Anyway, the story isn't quite over after this exception is thrown. Before it died, the tee-system-out thread succeeded in putting the last message on System/out.
The client reads off of this, puts the results in the appropriate atom, lsp/request!  stops looping and the (clojure.test/is ...) passes. The client goes on to send another message to the server's System/in, which goes through the tee-system-in thread where it is logged, and then into clojure-lsp via the server's is input stream. The server processes this message and prints the result to its os. But, the thread that pulls data off os and forwards it to System/out is dead, and so the client never gets a response.
The tests now hang, as the client is waiting for a server response that will never come. This is the same way that the tests fail when we don't have all this extra logging turned on. The server has sent a response to its output stream, but the client never receives it. I'm not convinced that they have the same underlying process (a Write end dead exception has been thrown, hidden in some thread somewhere) but it's the best lead I have right now.
Other things I've noticed:

The integration tests almost always fail now, though at a somewhat random spot (often in the definition tests). I'm suspicious that the extra logging is making them extra fragile. I'm worried that I'm going to end up finding a bug in the logging code, but not the flaky test code—it's hard to know.
The way we use integration.lsp/client-request-id looks racy. Probably wouldn't hurt to re-work how this id is passed around, so we don't read the wrong write.

I was watching the logs during one failure, I thought I saw it paused with two requests made before receiving first response, but later I couldn't find any logs that looked ike that.

The Content-Length header doesn't look like it has the right value. Or rather, the one that our test client produces matches what I'd expect, but the one from within lsp4j seems off by one character. I'm checking these string length numbers by copying out of the logs, so perhaps I'm copying some invisible characters. Haven't researched this one much. Doesn't seem like it's likely to be the problem, since real clients don't seem to mind.
The tee-system-out code doesn't handle 0 bytes read. That could be a bug.


rtl8822ce: init at v<IP_ADDRESS>b

This is already available on newer kernels like zen.
Note: build fails on newer kernels due to crc32, but either way never kernels should already have this.

Motivation for this change
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Reviewed points

[X] package path fits guidelines
[X] package name fits guidelines
[X] package version fits guidelines
[ ] package build on ARCHITECTURE
[ ] executables tested on ARCHITECTURE
[X] meta.description is set and fits guidelines
[X] meta.license fits upstream license
[X] meta.platforms is set
[X] meta.maintainers is set
[X] build time only dependencies are declared in nativeBuildInputs
[X] source is fetched using the appropriate function
[X] phases are respected
[ ] patches that are remotely available are fetched with fetchpatch

Possible improvements
Comments
I do not have the relevant hardware, and realized anything I'm going to test this on is running a newer kernel.  This otherwise looks ok to me.

Perhaps if there is any way to know which kernel version this stops being compatible with?  Is it possible to prevent this in nix from being built with those kernels?

For instance: is there a way to limit it to the known-buildable kernels?
2 packages marked as broken and skipped:
linuxPackages_hardkernel_4_14.rtl8822ce linuxPackages_hardkernel_latest.rtl8822ce
8 packages failed to build:
linuxPackages_5_8.rtl8822ce linuxPackages_5_9.rtl8822ce linuxPackages_latest-libre.rtl8822ce linuxPackages_latest_hardened.rtl8822ce linuxPackages_latest_xen_dom0.rtl8822ce linuxPackages_latest_xen_dom0_hardened.rtl8822ce linuxPackages_testing_bcachefs.rtl8822ce linuxPackages_zen.rtl8822ce
9 packages built:
linuxPackages-libre.rtl8822ce linuxPackages.rtl8822ce linuxPackages_4_14.rtl8822ce linuxPackages_4_19.rtl8822ce linuxPackages_4_4.rtl8822ce linuxPackages_4_9.rtl8822ce linuxPackages_hardened.rtl8822ce linuxPackages_xen_dom0.rtl8822ce linuxPackages_xen_dom0_hardened.rtl8822ce

I am not quite sure what is known but I know that zen kernel already have it. Maybe we can just limit it to those that already failed in CI?

Perhaps if there is any way to know which kernel version this stops being compatible with? Is it possible to prevent this in nix from being built with those kernels?

Definitely it's possible - you just need to assert before mkDerivation that the version is old enough and throw a proper message otherwise. @pickfire please use lib.asserts.assertMsg (https://nixos.org/manual/nixpkgs/stable/#sec-functions-library) and lib.strings.versionOlder

I am not using nixos anymore and for this one just use one of those kernels to fix it. Closing it.


Feature/3443 score card playground

Changes proposed in this Pull Request:

Add scorecard playground

Working fine.


[MM-47669] - Apply changes recommended by Lighthouse audit

Summary
As part of our performance improvement OKR I have applied the most reported changes from the audit on the client side here. The largest improvement however would come from the server change, as our images are the thing to affect performance the most.
Ticket Link
https://mattermost.atlassian.net/browse/MM-49389
-->
NONE

@M-ZubairAhmed i identified two more areas of improvement, even if the current performance is technically optimised by 20% tht i want to push

We are fetching the preview images only for thumbnails and want to refactor this
potentially we can split the utils.tsx file but it might be its own separate ticket or even open source worthy.

After the first change is implemented i will ping you for a review.

@M-ZubairAhmed i wanted to increase the number of test runs for more accuracy but github actions adds extra miliseconds for each test run, so bringing it back down a bit to see if we get numbers similar to local.

@hmhealey @M-ZubairAhmed the pipeline is running with cache from the old values in this PR, confirmed this by creating a new branch and running here with @yasserfaraazkhan https://github.com/mattermost/mattermost-webapp/compare/master...MM-47669-test#diff-3f3e8610fb41f9ab225bacf92f8b9eedf8c4d536f50c7c54dcf3baccc2d806c1R35
We would probably need to merge to master to see the accurate values.

Which part of that workflow is being cached? Do you mean that it's using an old version of the web app code?


[BUG] Dark mode makes the pop-up messages from the admin interface unreadable.

When the Django-CMS admin run in dark mode, the pop messages are unreadable. The text is dark on a dark background.  I also think they should not disappear so fast. In case of an error, you have not enough time to read it.

Fixed in #7739 and #7740


Structs with variable length inline arrays MUST be blittable

An array that contains a variable length inline array (e.g. RTM_ENTITY_EXPORT_METHODS) must be blittable because custom memory management is the only way to handle it.
We should recognize this and emit a blittable (non-marshaled) version even when AllowMarshaling is set to true.
If that same struct contains other fields that require marshaling, perhaps we just error out when emitting because it's an impossible thing to properly support.

With #292 fixed, we have the tools necessary to recognize and require that a struct be unmanaged (i.e. blittable). For this issue then, we should recognize that the structs identified in this issue are among those that trigger the blittable requirement.
We could change our IsManaged test to return false for these structs since a managed version will never be emitted, thereby avoiding the suffix that would otherwise be appended to it.


No GitHub pages

The GitHub pages link doesn't work...

I forgot to update the link when I changed my username, it should now work.

Don't worry, I downloaded it on my computer.
lundi 30 avril 2018 à 22:37 +0200 de<EMAIL_ADDRESS><EMAIL_ADDRESS>
I forgot to update the link when I changed my username, it should now work.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub (https://github.com/devakira/xor/issues/14#issuecomment-385521154), or mute the thread (https://github.com/notifications/unsubscribe-auth/Aj6CPzhFHkR-5Hv36R42xXb1HA1KI6CKks5tt3YMgaJpZM4Tsyca).


I don't understand how to validate the turnstile

Plugin Hello and thank you for your
I'm testing it and I'm having trouble understanding how it works.
I got the key and the secret hey.
Front side integration works. Finally, it always tells me "success"
I don't understand how validation works.
I have integrated validation this way in my ContactRequest file
<?php
public function rules()
    {
        return [
            'name'                  =>  'required|max:255',
            'email'                 =>  'required|email|max:255',
            'subject'               =>  'required',
            'content'               =>  'required',
            'phone'                 =>  'nullable|phone:FR',
            'cf-turnstile-response' => ['required', 'string', new TurnstileCaptcha()]
        ];
    }
    ?>

At the validation of my form, my postContact action is called.
That's when I don't understand how it works.
I tested with the following code which returns me "The CAPTCHA response parameter is invalid or has expired."
My action postContact:
<?php
   public function postcontact(ContactRequest $request)
    {
        $validator = new Validator();
        $response = $validator->validate('input-token');
        if ($response->isValid()) {
            return true;
        }

        echo $response->getMessage();
?>

Could you tell me how it works because I don't understand.
Thanks again for this find.

The rule itself ('cf-turnstile-response' => ['required', 'string', new TurnstileCaptcha()]) is enough to validate the CAPTCHA.
I've only added the "Manual validation" part to the README in case somebody doesn't want to use the included validation rule.
So in the end, the first code snippet is enough to make it work


Under Linux alt not working for favorite

OS: Linux Mint Mate
Game Versions: Current and earlier 0.217.25
Mod Version Current and earlier 1.4.2
Problem: can't alt click items to prevent having things get auto put away. (left alt)
Work around: I assigned it to t, and it's working.  can play around more later.
"Linux Mint 20.3"
Linux  5.15.0-84-generic #93~20.04.1-Ubuntu SMP Wed Sep 6 16:15:40 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

I'm using the default unity engine KeyboardShortcut function. there isn't anything I can do differently. does your alt key work when you use it in other mods?


FEAT: Add Icicle GPU-Accelleration to Plonk Prover behind build tag

Description
This PR adds experimental support for Icicle GPU acceleration library for Plonk backend and the BN254 curve.
Type of change
[X] New feature (non-breaking change which adds functionality)
How has this been tested?
[X] Using the circuits in gnark/examples/plonk/main.go

Follow the instructions for setting up Icicle in the linked repository above
From gnark run go run examples/plonk/main.go

[X] Using Ingonyama's fork of Succinct Lab's Gnark-Plonky2-Verifier

From Gnark-Plonky2-Verifier run go run benchmarks.go --icicle

How has this been benchmarked?
Benchmarks ran on Gnark-Plonky2-Verifier using AWS: g5.8xlarge A10g 32 core 128GB.
Benchmarks can be seen here.
Note
These benchmarks are not final.  We are still updating our Go Cuda bindings which will provide a significant speed-up to the NTT.  Also note our Compute Quotient Polynomial is actively being refined to increase speed.  The current implementation is ~20s slower than the ideal implementation due to the need to run CUDA processes synchronously.  This will be updated when solved.
Dependencies
This merge requests depends on modifications to the following two repositories.

IcicleGnark - Pull Request
Gnark-Crypto - Pull Request

Checklist:

[X ] I have performed a self-review of my code
[ X] I have commented my code, particularly in hard-to-understand areas
[ X] I have made corresponding changes to the documentation
[ X] I have added tests that prove my fix is effective or that my feature works
[ X] I did not modify files generated from templates
[ X] golangci-lint does not output errors locally
[ X] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: jeremyfelder:white_check_mark: ivokub:x: bigsky77You have signed the CLA already but the status is still pending? Let us recheck it.


Please, add screenshots of this widget

One of the most important things when building this type of components is to show how it looks like. The fact that I have to install and run in order for me to "see" it, it is a deterrent.

It visually doesn't look like anything. It is just a wrapper component that has some built in functions for changing the currently viewable component.


Revert "Enable the Code Editor, with new apply-text-edits algo. (#9055)"

This reverts commit c811a5ae8ba4a512eb74ece2f9f6cb332c3bcdd4.
Pull Request Description

Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[ ] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[ ] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[ ] Unit tests have been written where possible.
[ ] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

This is an enormouse PR that you are trying to revert. It might be worth to try to address the issue instead first.

Since the original issue was successfully fixed and merged, this revert is no longer necessary.


YARN-9851: Make execution type check compatiable

During upgrade from 2.6 to 3.1, we encountered a problem:
2019-09-23,19:29:05,303 WARN org.apache.hadoop.yarn.server.resourcemanager.rmnode.RMNodeImpl: Lost container container_e35_1568719110875_6460_08_000001, status: RUNNING, execution type: null 2019-09-23,19:29:05,303 WARN org.apache.hadoop.yarn.server.resourcemanager.rmnode.RMNodeImpl: Lost container container_e35_1568886618758_11172_01_000062, status: RUNNING, execution type: null 2019-09-23,19:29:05,303 WARN org.apache.hadoop.yarn.server.resourcemanager.rmnode.RMNodeImpl: Lost container container_e35_1568886618758_11172_01_000063, status: RUNNING, execution type: null 2019-09-23,19:29:05,303 WARN org.apache.hadoop.yarn.server.resourcemanager.rmnode.RMNodeImpl: Lost container container_e35_1568886618758_11172_01_000064, status: RUNNING, execution type: null 2019-09-23,19:29:05,303 WARN org.apache.hadoop.yarn.server.resourcemanager.rmnode.RMNodeImpl: Lost container container_e35_1568886618758_30617_01_000006, status: RUNNING, execution type: null
for (ContainerStatus remoteContainer : containerStatuses) {
  if (remoteContainer.getState() == ContainerState.RUNNING
      && remoteContainer.getExecutionType() == ExecutionType.GUARANTEED) {
    nodeContainers.add(remoteContainer.getContainerId());
  } else {
    LOG.warn("Lost container " + remoteContainer.getContainerId()
            + ", status: " + remoteContainer.getState()
            + ", execution type: " + remoteContainer.getExecutionType());
  }
}

The cause is that we has nm with version 2.6, which do not have executionType for container status.
We should make the check more compatiable.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
1367
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
1
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
1258
trunk passed

+1
compile
51
trunk passed

+1
checkstyle
44
trunk passed

+1
mvnsite
49
trunk passed

+1
shadedclient
910
branch has no errors when building and testing our client artifacts.

+1
javadoc
33
trunk passed

0
spotbugs
110
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
108
trunk passed

_ Patch Compile Tests _

+1
mvninstall
44
the patch passed

+1
compile
40
the patch passed

+1
javac
40
the patch passed

-0
checkstyle
30
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager: The patch generated 1 new + 27 unchanged - 0 fixed = 28 total (was 27)

+1
mvnsite
42
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
859
patch has no errors when building and testing our client artifacts.

+1
javadoc
28
the patch passed

+1
findbugs
104
the patch passed

_ Other Tests _

-1
unit
4987
hadoop-yarn-server-resourcemanager in the patch failed.

+1
asflicense
28
The patch does not generate ASF License warnings.

10043

Reason
Tests

Failed junit tests
hadoop.yarn.server.resourcemanager.scheduler.fair.TestFairSchedulerOvercommit

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1502/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1502

JIRA Issue
YARN-9851

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 9f8d1f7121d2 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / aa664d7

Default Java
1.8.0_222

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1502/1/artifact/out/diff-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1502/1/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1502/1/testReport/

Max. process+thread count
815 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1502/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.


⚠ WinePass has degraded performance

In b849702, WinePass (https://www.winepass.com.ar) experienced degraded performance:

HTTP code: 200
Response time: 13484 ms

Resolved: WinePass performance has improved in 74eb9bb.


fixed shield enchantments

added option to add or remove weapon part of shield (aka spikes)
Apparently there were some edits while I was coding. Hopefully it can be merged.

Oh, one thing I noticed: Shield must be re-equipped to apply new armor values. Probably also true for other armor (didn't check). Also removing permanent enchantments reappear, when re-equipping items (which was expected).


How do I configure external routing

How do I configure external routing in the new Docker 1.9 libnetwork with calico?
The particular problem I run into is that I can get packets into the container, but not out again.
I'll demonstrate.
I create a network called 'netalphabeta', and add a calico rule for inbound ICMP:
[trinity10] Executing task 'create_networks'
[trinity10] run: docker network create --driver=calico --subnet <IP_ADDRESS>/24 netalphabeta
[trinity10] out: d40eea57e99baac50e57c2dc7159eac0378f13d849de8e31c98db1cc12cdc1f1
[trinity10] out:

[trinity10] run: docker network ls
[trinity10] out: NETWORK ID          NAME                DRIVER
[trinity10] out: 6a080db420ef        netsolr             calico
[trinity10] out: d40eea57e99b        netalphabeta        calico
[trinity10] out: 13fd5c86b05f        none                null
[trinity10] out: 87b139f81899        host                host
[trinity10] out: bfcd754ecf23        bridge              bridge
[trinity10] out:

[trinity10] Executing task 'configure_network_profiles'
[trinity10] run: docker network ls
[trinity10] out: NETWORK ID          NAME                DRIVER
[trinity10] out: 6a080db420ef        netsolr             calico
[trinity10] out: d40eea57e99b        netalphabeta        calico
[trinity10] out: 13fd5c86b05f        none                null
[trinity10] out: 87b139f81899        host                host
[trinity10] out: bfcd754ecf23        bridge              bridge
[trinity10] out:

[trinity10] run: ./calicoctl profile show
[trinity10] out: +------------------------------------------------------------------+
[trinity10] out: |                               Name                               |
[trinity10] out: +------------------------------------------------------------------+
[trinity10] out: | 6a080db420efe11b19c3812f394236549ac7eab1b8c62b42fdc4959c03ec6ba5 |
[trinity10] out: | d40eea57e99baac50e57c2dc7159eac0378f13d849de8e31c98db1cc12cdc1f1 |
[trinity10] out: +------------------------------------------------------------------+
[trinity10] out:

[trinity10] run: ./calicoctl profile d40eea57e99baac50e57c2dc7159eac0378f13d849de8e31c98db1cc12cdc1f1 rule add inbound allow icmp
[trinity10] run: docker network ls
[trinity10] out: NETWORK ID          NAME                DRIVER
[trinity10] out: 6a080db420ef        netsolr             calico
[trinity10] out: d40eea57e99b        netalphabeta        calico
[trinity10] out: bfcd754ecf23        bridge              bridge
[trinity10] out: 13fd5c86b05f        none                null
[trinity10] out: 87b139f81899        host                host
[trinity10] out:

My physical LAN network layout is:
[macbook <IP_ADDRESS>] -- [router1 <IP_ADDRESS>,<IP_ADDRESS>] -- [router2 <IP_ADDRESS>,<IP_ADDRESS>] -- [docker host trinity10 <IP_ADDRESS>].

My router1 has a static route for <IP_ADDRESS>/24 to <IP_ADDRESS>.
My router2 receives routes from Calico, so it has a dynamic route for my containers on trinity10.
Next I run a container on that network, with tcpdump listening for pings on cali0, and try to ping to it from my macbook.
mak@trinity10:~/tcpdump$ docker run --privileged --net netalphabeta -it makuk66/docker-tcpdump /bin/bash -c 'ip addr list; ip route list; sudo tcpdump -i cali0 -n icmp'
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
278: cali0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 scope global cali0
       valid_lft forever preferred_lft forever
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link tentative
       valid_lft forever preferred_lft forever
280: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 02:42:ac:12:00:05 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/16 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe12:5/64 scope link tentative
       valid_lft forever preferred_lft forever
default via <IP_ADDRESS> dev eth1
<IP_ADDRESS>/16 dev eth1  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/24 dev cali0  proto kernel  scope link  src <IP_ADDRESS>
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cali0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:54:40.758298 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 46974, seq 0, length 64
11:54:41.762171 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 46974, seq 1, length 64
11:54:42.766340 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 46974, seq 2, length 64
^C

mak@crab 513 ~ $ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C

So the echo requests go into the container, but there are no replies.
Looking at the links and routes, we see a cali0 and eth1, with the default route going to eth1.
If I tcpdump eth1, I don't see any ICMP either.
If I add a specific route, I can make this work:
mak@trinity10:~/tcpdump$ docker run --privileged --net netalphabeta -it makuk66/docker-tcpdump /bin/bash -c 'sudo ip route add <IP_ADDRESS>/24 dev cali0; ip addr list; ip route list; tcpdump -i cali0 -n icmp'
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
282: cali0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 scope global cali0
       valid_lft forever preferred_lft forever
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link tentative
       valid_lft forever preferred_lft forever
284: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 02:42:ac:12:00:05 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/16 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe12:5/64 scope link tentative
       valid_lft forever preferred_lft forever
default via <IP_ADDRESS> dev eth1
<IP_ADDRESS>/16 dev eth1  proto kernel  scope link  src <IP_ADDRESS>
<IP_ADDRESS>/24 dev cali0  scope link
<IP_ADDRESS>/24 dev cali0  proto kernel  scope link  src <IP_ADDRESS>
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cali0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:56:08.632703 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 60798, seq 0, length 64
11:56:08.632768 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 60798, seq 0, length 64
11:56:09.636184 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 60798, seq 1, length 64
11:56:09.636218 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo reply, id 60798, seq 1, length 64
^C

PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: icmp_seq=0 ttl=61 time=0.794 ms
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=61 time=0.740 ms
^C

When I tried this back in July, the container would get a single calic0 device, with a default route to that, and it just worked. See for example the second output in calico-docker issue 341.
How can I make make this work with the latest?
Further version details:
[trinity10] Executing task 'info'
[trinity10] run: cat /etc/lsb-release
[trinity10] out: DISTRIB_ID=Ubuntu
[trinity10] out: DISTRIB_RELEASE=14.04
[trinity10] out: DISTRIB_CODENAME=trusty
[trinity10] out: DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
[trinity10] out:

[trinity10] Executing task 'docker_version'
[trinity10] run: docker version
[trinity10] out: Client:
[trinity10] out:  Version:      1.9.0
[trinity10] out:  API version:  1.21
[trinity10] out:  Go version:   go1.4.2
[trinity10] out:  Git commit:   76d6bc9
[trinity10] out:  Built:        Tue Nov  3 17:43:42 UTC 2015
[trinity10] out:  OS/Arch:      linux/amd64
[trinity10] out:
[trinity10] out: Server:
[trinity10] out:  Version:      1.9.0
[trinity10] out:  API version:  1.21
[trinity10] out:  Go version:   go1.4.2
[trinity10] out:  Git commit:   76d6bc9
[trinity10] out:  Built:        Tue Nov  3 17:43:42 UTC 2015
[trinity10] out:  OS/Arch:      linux/amd64
[trinity10] out:

Back in June we were taking a slightly different approach to networking with libentwork. back then we assigned a /32 address to the cali0 interface in the container and didn't have an extra interface for the docker bridge. We had a default route to the the calico vrouter (as the default gateway). This approach works well with Calico but relies on using a BGP router for getting traffic to/from the calico network.
With the changes that docker introduced when they added their IPAM driver we could no longer take this approach. Their IPAM provides an IP on a subnet so it was much easier to just accept the libnetwork model of networking. This means Calico works in a similar way to their overlay driver. The "network" created with libnetwork has a subnet and an IP from that subnet is assigned to the container. A route is added only for that subnet to the Calico vrouter. They also added the feature to add a second interface which provides traffic in/out of the Calico network. This is convenient for people who don't have a BGP router but breaks things for people like you that do.
Going forward, I think there's two obvious options here

Move to using "calicoctl container add/remove" rather than libnetwork. Not great since it's not easy to ensure that networking is in place before the container starts. But this sticks with the /32 address and the default route.
Wait until we've written a Calico IPAM plugin for libnetwork. We're working on this now, but it's going to be a week or two before we have this ready.

There could be a 3rd option - using the existing Calico network driver and libnetwork IPAM driver, but programming different routes into the container. I can't imediately see how to do this, but I think something might be possible so I'll give it some more thought. Suggestions are of course welcome!

The docker libnetwork will create a bridge network "docker_gwbridge" for provding  default gateway for the containers if none of the container's endpoints  have GW set by the driver.
Atfer trace, I think calico driver provide the gw in function CreateEndpoint, but libnetwork driver api only set mac address  and ip. https://github.com/docker/libnetwork/blob/master/driverapi/driverapi.go
I try to provide the gw in function Join, and it works.
And I made a pull request for this change.  https://github.com/projectcalico/libnetwork-plugin/pull/22
Hope this is a correct way.

In v0.12.0 of calicoctl, we now use the latest blibnetwork-plugin which contains a Calico IPAM driver.
@maku66, If you use Calico IPAM, we revert to the old behavior of routing everything through the Calico vRouter.  Let me know if this resolves things for you.

I tested 0.12.0; seems to work: I can ping my containers from outside, and the containers have a cali0 interface only. Thanks!

And thanks for the helpful docs on https://github.com/projectcalico/calico-docker/blob/master/docs/getting-started/libnetwork/Demonstration.md


Improve handling of complex alleles

The complexity of the allele parsing algorithm that converted a read into a series of alleles made it easy for us to introduce a number of bugs, the ultimate result of which was an elimination of certain kinds of complex alleles. These commits rewrite the allele parsing logic to be simpler and easier to maintain, and resolve the underlying problem. They also resolve a number of other minor issues, such as a problem with reported depth in some contexts.

CC @chapmanb @mlin : This commit could use some third-party automated testing. As far as I can tell from my testing this is only improving things. However, I haven't scaled the tests up and if either of you have a push-button way to do so that'd be very helpful.

Erik -- I'd be happy to test this. Would it be possible to synchronize with @walaj and get the latest version of SeqLib included in the main branch? I believe this would take an update of #338 to fix conflicts. This would be very helpful for builds since the recent SeqLib uses htslib 1.5, which would synchronize us with samtools and bcftools requirements. That SeqLib improvement/update PR has been languishing for a while but is really useful so would be great to get in.

Erik -- thanks for the SeqLib merge and update. This now builds cleanly with htslib 1.5 and I'll do some validation runs. Much appreciated.

Erik -- thanks again for all the fixes and updates. The latest HEAD is running great and validations look good compared to the previous versions:
https://github.com/bcbio/bcbio_validations/tree/master/freebayes#11044
Thanks for the code cleanup and improvements. I'll build a new bioconda package to make this version available and we'll switch over to using it in bcbio. Thanks again.


Error on Epic games cities skylines

Describe the problem
When i run the game this error appears
Method not found: 'NetSegment.GetLeftAndRightLanes'. [System.MissingMethodException]
Details:
No details

https://github.com/CitiesSkylinesMods/TMPE#support-policy


Fix README.txt: wrong link to c3po repo and dir name for hss

Fix:

wrong link to c3po repo (gerrit -> github)
wrong dir in hss instructions (mme -> hss)

resolve #24, #25

retest this please

retest this please

LGTM

@omec-project/c3po-maintainers ping


Do not always chomp output

This bunch of commits does some refactoring and adds a way to optionally disable chomping the output of commands.
This fixes #347 in respect to the #show method.  Other methods may need similar adjustment.

@jcouball I rebased these changes on top of master.


Bugfix [v3] delete format image svg

Codecov Report
Patch and project coverage have no change.

Comparison is base (18a1acc) 0.00% compared to head (c5b65bd) 0.00%.
 Consider uploading reports for the commit 5ddf248 to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@     Coverage Diff      @@
##   main   #1014   +/-   ##
============================
============================

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Templates: import DataQuery from @grafana/schema instead of @grafana/data

What this PR does / why we need it:
The import of DataQuery from @grafana/data is marked as deprecated.
This PR imports it from @grafana/schema instead, which is the suggested solution.
This removes a warning from the code editor.
Which issue(s) this PR fixes:
Fixes #389
Special notes for your reviewer:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you @academo for the review!
I added a commit to make sure it gets included for each plugin type, which can be useful.


azure/governance: Fixes #1015: Added ability to configure azure disk encryption on key vault

This PR is in reference to this open issue: https://github.com/XenitAB/terraform-modules/issues/1015
Background
If Azure Disk Encryption (ADE) has been enabled on a key vault, running the governance module will attempt to disable this setting. Whilst you could run terraform and manually enable it again in the portal it is not a great solution.
Fix
I have adjusted the module slightly and have followed all the steps in the contribution guide as well as tested my branch against the environment where I have had the issue with success. I can confirm that this allowed me to configure the ADE settings to my liking without affecting other settings or other key vaults.

Changes required for consumer:
Update the variable resource_group_configs in variables.tf
variable "resource_group_configs" {
  description = "Resource group configuration"
  type = list(
    object({
      common_name                        = string
      delegate_aks                       = bool # Delegate aks permissions
      delegate_key_vault                 = bool # Delegate KeyVault creation
      delegate_service_endpoint          = bool # Delegate Service Endpoint permissions
      delegate_service_principal         = bool # Delegate Service Principal
      lock_resource_group                = bool # Adds management_lock (CanNotDelete) to the resource group
      disable_unique_suffix              = bool # Disable unique_suffix on resource names
      key_vault_purge_protection_enabled = optional(bool, false)
      enabled_for_disk_encryption        = optional(bool, false)
      tags                               = map(string)
    })
  )
}

Update common.tfvars
resource_group_configs = [
  {
    common_name                        = "core",
    delegate_aks                       = false,
    delegate_key_vault                 = true,
    delegate_service_endpoint          = false,
    delegate_service_principal         = false,
    lock_resource_group                = false,
    disable_unique_suffix              = false,
    key_vault_purge_protection_enabled = false,
    enabled_for_disk_encryption        = true,
    tags = {
      "description" = "Core infrastructure"
    }
  },
]

@carlzxc71 is there any cost associated with enabling enabled_for_disk_encryption. If the answer is no I would suggest just always having it enabled.

I want to keep the configuration as simple as possible, it should not be an configuration if there is no need to disable it. Change the PR to just hard code this parameter and I will approve it.

@phillebaba - Updated.


Fix type parameter in AvroIO.Write

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[x] Each commit in the pull request should have a meaningful subject line and body.
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

R: @reuvenlax

@reuvenlax can you or anyone else take a look?

Coverage increased (+0.003%) to 69.509% when pulling f595eb4984df9fc4322c693fa26e1c8c1c47196c on nevillelyh:patch-1 into 50532f0a92d7ce8dbbdc6c3179ab7b9efde6a746 on apache:master.

Can you please file a JIRA, and change the title of this PR per the policy?

Fixed. Thanks.
https://issues.apache.org/jira/browse/BEAM-2960

Ping @reuvenlax

retest this please.

Coverage increased (+0.1%) to 69.604% when pulling f595eb4984df9fc4322c693fa26e1c8c1c47196c on nevillelyh:patch-1 into 50532f0a92d7ce8dbbdc6c3179ab7b9efde6a746 on apache:master.


WIP revert DefaultIvyArtifactName changes

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.


Change narrow char load_file() interface to assume UTF-8 on Windows.

Narrow-char interface on Windows is useless because it automatically makes its users Unicode-broken.
This would enable supporting Unicode seamlessly in portable code.
Would let us open XMLs referenced from another XML document, external databases or configuration files (all UTF-8), without platform dependent re-encoding logic.
See how SQLite does it. I had never ever worried about Unicode with SQLite, because of this.

Using utf-8 instantly breaks compatibility with any CRT functions.
For example, on Windows, in a portable program, you can do doc.load_file(argv[1]). And it would instantly fail for any file name that contains localized characters. Without UTF-8 conversion (aka 'right now') it would succeed for any file name that contains characters in the system locale - which is worse than supporting any file name but better than nothing.
In general it's extremely surprising to have the function that loads/saves the file behave differently from the two mechanisms available for that in C++ (fopen and std::fstream). When I get reports of load_file() returning file_not_found but the file being there, I ask to use fopen to show that the issue is not with pugixml but with the calling environment.
Having an option of loading a file by UTF-8 path makes sense. You can use doc.load_file(pugi::as_wide(...).c_str()) right now, but this is of course a bit more cumbersome than doc.load_file_utf8() or some equivalent.

Yes, this is true. But for main() or fopen(), solutions do exist. Using as_wide(...) manually is a pain, because I want it to work this way on Windows, but on Unixes it is the wrong thing to do. Today I always work with a patched version of pugixml on Windows.
I am aware of the compatibility problems with existing code. Personally I say that such code is broken anyway -- what's the difference of being 99.9% broken or 99.7% broken?
Yet, from pugi's POV, it would be enough to have it as a non-default compile time switch (i.e. load_file() assumes legacy broken ANSI versus UTF-8). I appreciate your interest of keeping this functionality as a defensive measure against people who don't understand encodings, but keep in mind that some libraries are capable to manage it anyway.

on Unixes it is the wrong thing to do

Why? as_wide will work on Unixes as well.

Personally I say that such code is broken anyway -- what's the difference of being 99.9% broken or 99.7% broken

I disagree with this. The amount of applications that use Windows ANSI facilities is staggering. A lot of them also work "good enough" for actual users wrt file encoding. pugixml takes a stance on being practical and solving issues that people encounter as opposed to spearheading UTF8 (I would love for UTF8 to be the C++ encoding, believe me).

Why? as_wide will work on Unixes as well.

The problem is not in as_wide. It's just that Unix treats filenames as blobs. See Boost.Nowide FAQ or this blog about Python v3 Unicode fail.

I disagree with this. The amount of applications that use Windows ANSI facilities is staggering. A lot of them also work "good enough" for actual users wrt file encoding.

It is true that there is simply a lot of broken code. But the reason this code works "good enough" is because it is fed with ASCII most of the time. Give it a directory of  eBooks and it will fail. And with load_file as UTF-8 it will continue working with ASCII as before.

pugixml takes a stance on being practical and solving issues that people encounter as opposed to spearheading UTF8 (I would love for UTF8 to be the C++ encoding, believe me).

How helping those who use UTF-8 for narrow strings in C++ isn't practical? Besides you gave none arguments against supporting this as a compile-time flag.
I also would like to add that the argument that load_file would behave differently from fopen is weak. Note that current pugixml, when compiled with narrow chars, uses UTF-8 for almost all of its interfaces (the exceptions are filenames and the parsing which detects the encoding). So in some sense this code
cout << n.child_value();
fopen(n.child_value(), "rb");

suffers from the same compatibility with CRT problems as you claim load_file would. And, btw, compiling for wide-chars and using wcout won't solve the above.

It's just that Unix treats filenames as blobs.

Right. But then load_file won't work on UTF-8! Right now the contract is "it takes the file name in whatever encoding the underlying system uses". Which is not UTF-8 on Unix systems (hopefully it's a superset) and not UTF-8 on Windows. The question is what's of more practical use, have default load/save functions behave as all other file access functions do or try to have a UTF-8 superset on all platforms.

But the reason this code works "good enough" is because it is fed with ASCII most of the time.

Most of the files that users will create will use their default locale. This is not true for some cases but this is overwhelmingly true. This of course is not an argument over Windows ANSI over UTF-8 - this is just to say that this is a reasonable compromise given the history of those APIs.

So in some sense this code suffers from the same compatibility with CRT problems as you claim load_file would.

If you use pugixml you can either know about the issues that Unicode brings or ignore them.
If you open any files without using pugixml in the same program, the difference will become apparent.
Sure, fopen on n.child_value() will fail to open localized paths if the document is encoded using UTF-8 (some users use pugixml to decode ANSI-encoded documents, but the majority probably sticks to UTF-8). But so will doc.load_file. And getting the filename through any other means will fail in the same manner. Essentially, narrow-char load_file is as "broken" as any other file opening API in C++.
Now, if you want to solve this problem, you must know you have it. You would not use fopen or std::fstream to open files. Maybe you'd use Boost or some other library or home-grown conversion primitives - regardless, if you know about this problem it's easy to see why load_file won't work - hey, no other API does!
If you don't know anything about these problems however, I'm not sure that making load_file take UTF-8 paths solves any issues for you. Because if you open any other files they may not work. So sure, if your XML file contains a reference to an XML file, that would work. But if it contains a reference to a .PNG file that you have to decode or a .log file that is opened separately, that won't. Which would force you to learn about the problems of file access anyway.
Right now it feels that the approach of transparently handling file access as UTF-8 just introduces extra incompatibilities. Are you aware of any libraries other than SQlite (and of course Boost.NoWide which is a different case - when you use that you solve that exact problem) that use UTF8-encoded paths on Windows?

Right. But then load_file won't work on UTF-8! [...]

It would work on UTF-8 on Windows, because no native narrow encoding on Windows is capable of representing all valid filenames supported by that same system. For other systems it simply does not matter as much, because it's user's choice to use something that isn't Unicode compatible.

[...] Which would force you to learn about the problems of file access anyway.

Yes. But after you learnt, what's next? You would have to reinvent the wheel and hope for the best.

Are you aware of any libraries other than SQlite [...] that use UTF8-encoded paths on Windows?

GDAL, say.
Sure, most libraries out there simply write standard C and don't provide any Windows support at all. We have to patch them manually or, if they're closed source, revert to other hacks.

Yes. But after you learnt, what's next? You would have to reinvent the wheel and hope for the best.

You use as_wide. The fact that it can't open some valid paths on Unix seems irrelevant since the XML should only contain Unicode data anyway.
I want to think about this more. I also created a SO question http://stackoverflow.com/questions/31092351/should-the-file-opening-interface-in-a-c-library-use-utf-8-on-windows to gather more opinions.

I'm going to close this because this can now be done without changing pugixml source code: when using Windows 10, the application manifest can specify that the application is UTF-8 aware and the defaults will automatically change. I think relying on this is more consistent within the Windows ecosystem than making a decision about the encoding of the file paths; obviously this requires that the application in question doesn't care about this on Windows 7, but both 7 and 8 are out of support.


feat: configureChains & API Providers

Description
This PR introduces the configureChains function and the concept of "API Providers".
The configureChains function allows you to configure your chains with API providers such as: Alchemy, Infura, or something else. This means you don't need to worry about defining RPC URLs and chain configuration in your connector or provider. This is managed internally by wagmi.
This PR also deprecates the use of providing connectors with a function to createClient. Now, the connectors option on createClient should be a static array of connectors. This fixes the issue where switching chains will make the active connector stale.
Check out the docs for configureChains here: https://wagmi-lcp3docvd-zoo.vercel.app/docs/api-providers/configuring-chains

🎉🙏


Automated cherry pick of #2477: fix: use policy match weight to override less specific policy

Cherry pick of #2477 on release/2.10.0.
#2477: fix: use policy match weight to override less specific policy

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.10.0@1ae85bb). Click here to learn what that means.
The diff coverage is 70.87%.

@@               Coverage Diff                @@
##             release/2.10.0   #2532   +/-   ##
================================================
  Coverage                  ?   7.66%
================================================
  Files                     ?     411
  Lines                     ?   64254
  Branches                  ?       0
================================================
  Hits                      ?    4923
  Misses                    ?   58908
  Partials                  ?     423

Flag
Coverage Δ

#aFlag
7.66% <70.87%> (?)

Impacted Files
Coverage Δ

pkg/util/stringutils2/sortedstrings.go
52.52% <0%> (ø)

pkg/cloudcommon/policy/policy.go
1.54% <0%> (ø)

pkg/util/rbacutils/rbac.go
53.15% <81.57%> (ø)

pkg/util/rbacutils/reduce.go
86.36% <86.36%> (ø)

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 1ae85bb...bae9b29. Read the comment docs.

/lgtm

/approve


New release?

I use AstroNvim, which pins it's dependency on nvim-notify to ^3.
I was browsing the docs for notify and I saw the wrapped-compact renderer and though this looked quite nice. However since AstroNvim pins it's releases and wrapped-compact wasn't in a new release yet I wasted a bunch of time trying to figure out why it was missing and notify was saying it couldn't find the rendered.
It was only when I saw that wrapped-compact was merged 2 months ago and the 3.12 was released in Jun that I realised it's because I don't track master...

Hadn't noticed but fixed the pipeline and a new release has been created :smile:


The PSNR problem of HAT_SRx4.pth

I use the provided HAT_SRx4.pth and Set5 datasets, and run the
python hat/test.py -opt ./options/test/HAT_SRx4.yml
The results are follows:
`
2023-02-15 10:15:58,541 INFO: Loading HAT model from ./experiments/pretrained_models/HAT_SRx4.pth, with param key: [params_ema].
2023-02-15 10:15:58,767 INFO: Model [HATModel] is created.
2023-02-15 10:15:58,767 INFO: Testing Set5...
2023-02-15 10:16:00,483 INFO: Validation Set5
     # psnr: 28.6280        Best: 28.6280 @ HAT_SRx4 iter

     # ssim: 0.8403 Best: 0.8403 @ HAT_SRx4 iter

`
The PSNR is much lower than the  results reported in the paper.
So how to reproduce the inference accuracy with the pretrained models

@Ironteen You may check the correctness of your data. Torch 1.8 may also cause abnormal performance.

@Ironteen You may check the correctness of your data. Torch 1.8 may also cause abnormal performance.

Thanks, I get the right results with torch 1.7. Is torch 1.9 or higher not available?

@Ironteen Only torch 1.8 has this problem from my experience.

I am using 1.7.1+cu101, and I got the following which is lower than the paper result.
# psnr: 31.0627	Best: 31.0627 @ HAT_x4_SR_baseline_Set5 iter
# ssim: 0.9060	Best: 0.9060 @ HAT_x4_SR_baseline_Set5 iter


Scale up MIT Open Opensearch

Description
Updating the configuration of the MIT Open opensearch cluster to improve performance during indexing events.
Motivation and Context
There are some concerns about search performance during indexing events. This should help address that.
How Has This Been Tested?

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Enhancement (improves on existing behavior)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] My code follows the code style of this project. (Did you install and run the pre-commit hooks?)
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

:+1:


Fix physical server and topology access rights for EvmRole-operator

Gives EvmRole-operator the rights to access physical server and physical infra topology pages.
Fixes issues:

https://bugzilla.redhat.com/show_bug.cgi?id=1505618.
https://bugzilla.redhat.com/show_bug.cgi?id=1530680.

I think this is ok. These lines are missing in my previous PR.
@h-kataria @rodneyhbrown7 Who can take a look on this?

Gaprindashvili backport details:
$ git log -1
commit e1d30e1a544e79f1888c2f9701142582a76e7953
Author: Harpreet Kataria<EMAIL_ADDRESS>Date:   Tue Feb 6 09:29:53 2018 -0500

    Merge pull request #16958 from Sanmoo/fix_1505618

    Fix physical server and topology access rights for EvmRole-operator
    (cherry picked from commit 03f19ed7b30d4e7256826acc883614b9b98f481c)

    https://bugzilla.redhat.com/show_bug.cgi?id=1530680


Support object refs

Add support for React.createRef()

Hi @jossmac. Can you please add a test for this functionality?