Consider changing BFP not to wrap around new field in result

As instruction BFP is currently defined, the bit field it overlays in the rs1 value may wrap around to span both the high (most-significant) and low (least-significant) ends of the result,  For example, this sequence,
li t0,12<<24|26<<16|0xABCD
bfp t1,zero,t0

for RV32, leaves t1 with the value 0x340002AF, because the 16-bit value 0xABCD shifted left 26 bits (without clipping) is 0x2AF34000000, and this value wraps around from high bits to low bits in the result.
Are there expected advantages to this wrapping?  My analysis indicates that the hardware for BFP (and for the B extension generally) can be a little reduced by not defining BFP to wrap around this way.  The basic reason is because BFP requires the hardware to separately create a mask in addition to shifting (or rotating) rs2[15:0], and forcing this mask to wrap around adds a little extra circuitry.
I can imagine some applications might benefit from wrapping around, while others benefit more from not wrapping around.  If there are good reasons to prefer wrap-around, I suggest adding an explanation of that choice to the document.  If not, I propose modifying the specified behavior to use shifts instead of rotations, like so:
uint_xlen_t bfp(uint_xlen_t rs1, uint_xlen_t rs2)
{
    int len = (rs2 >> 24) & 15;
    int off = (rs2 >> 16) & (XLEN-1);
    len = len ? len : 16;
    uint_xlen_t mask = slo(0, len) << off;
    uint_xlen_t data = rs2 << off;
    return (data & mask) | (rs1 & ~mask);
}

For my example above, the value left in t1 would then be 0x34000000.
(Note that, the hardware could still quietly substitute
uint_xlen_t data = rol(rs2, off);

for computing data without changing the behavior, if that's more convenient.  The issue is just with the rotation of the mask.)

The basic reason is because BFP requires the hardware to separately create a mask in addition to shifting (or rotating) rs2[15:0], and forcing this mask to wrap around adds a little extra circuitry.

That's at least not how I built it. See https://github.com/riscv/riscv-bitmanip/blob/master/verilog/rvb_shifter/rvb_shifter.v.
In a previous discussion on the bitmanip mailing list it was concluded that in most cases (even without funnel shifts), the most efficient way of implementing the shifter would be a 2*XLEN rotate shift. So my BFP implementation is based on that: Set the 2*XLEN shift value to {111...111, din_rs2[15:0] | bfp_mask, 000...000, din_rs2[15:0] & ~bfp_mask} where bfp_mask[15:0] = 16'h FFFF << bfp_len, then rotate shift by bfp_off, then set Y = ((X | Z) & A) | (X & Z) (with A = rs1 and X and Z being the two halves of the 2*XLEN result).
I'd have to run a more detailed analysis to assess the difference in required HW for the two definitions.

Are there expected advantages to this wrapping?

Placing a bit field >=(XLEN-16) bit in the middle of a word is the same as shifting that bit field value up and then placing the "surrounding" using a wrapping BFP.

I'd have to run a more detailed analysis to assess the difference in required HW for the two definitions.

Thanks for pointing me to your specific Verilog implementation (which no doubt was there all along, but I forgot to look).  My analysis so far is built on some different assumptions, such as no support for the ternary instructions, for lack of a third register read port.  I hope to provide more feedback eventually about which BFP version is likely to be smaller in hardware.  But first, back to the motivation question:

Are there expected advantages to this wrapping?

Placing a bit field >=(XLEN-16) bit in the middle of a word is the same as shifting that bit field value up and then placing the "surrounding" using a wrapping BFP.

Could you show an example where this way of using BFP is actually beneficial?  When I try it, the effort to construct the rs2 operand for the BFP is too much work.
Assuming RV32, consider the problem of injecting a 17-bit value from a1 into bits [21:5] of a0, leaving the result in t0.  When I try to use BFP as you suggest, I get a sequence like this:
rori t0,a0,5
srli t0,t0,17
li t1,15<<24|22<<16
or t0,t1,t0
slli t1,a1,5
bfp t0,t1,t0

A more obvious sequence, using only existing RV32I instructions, is actually shorter by one instruction:
li t0,~(0x1FFFF<<5)    ; expands to 2 instructions
and t0,a0,t0
slli t1,a1,5
ori t0,t0,t1

Is there a better way to use BFP than what occurred to me?

Assuming RV32, consider the problem of injecting a 17-bit value from a1 into bits [21:5] of a0, leaving the result in t0.

Using rotates and shifts, I found I could do it in only 4 instructions:
roli t0,a0,10
slli t0,t0,17
or t0,t0,a1
roli t0,t0,5

Or, if we need to clip the value from a1, 5 instructions:
rori t0,a0,5
srli t0,t0,17
slli t1,a1,15
or t0,t0,t1
rori t0,t0,10

Note that versions of these sequences (in the same number of instructions) will work for both RV32 and RV64, for all field widths, not just widths >= XLEN - 16.  This definitely beats my attempt to use the wraparound BFP.

I wrote:

My analysis indicates that the hardware for BFP (and for the B extension generally) can be a little reduced by not defining BFP to wrap around this way. The basic reason is because BFP requires the hardware to separately create a mask in addition to shifting (or rotating) rs2[15:0], and forcing this mask to wrap around adds a little extra circuitry.

Clifford Wolf:

That's at least not how I built it.

Because your hardware implements the funnel shift ternary instructions, you have a 128-bit rotating shifter.  For BFP, you're taking advantage of the double-wide rotation to get the effect of shifting the mask "for free" (although your technique is a little more subtle than that).  However, for any implementation that doesn't have the ternary instructions, the main shifter need be only 64 bits.  In that case, supporting BFP requires also being able to generate the mask separately, as I mentioned.
I've attached a modified version of your rvb_shifter.v that I believe eliminates the wrap-around for BFP and should also be a little smaller in hardware than your current one.  Unfortunately, I haven't had time to test it, because I don't yet have the same setup as you.  But I have reasonably high confidence it will work.  If it doesn't, let me know, and I'll invest the energy to fix it.
rvb_shifter.zip

Or, if we need to clip the value from a1, 5 instructions:
rori t0,a0,5
srli t0,t0,17
slli t1,a1,15
or t0,t0,t1
rori t0,t0,10

Also 5 instructions with BFP (result in a0, so it looks like the body of a C function):
slli a1, a1, 5
rori a2, a0, 22
addi a0, zero, -234
pack a0, a2, a0
bfp a0, a1, a0

But the addi+pack+bfp sequence is a fuse-able sequence. So with macro-op fusion it's three macro-ops. (See "2.13.3 Fused *-bfp sequences" in current draft spec.)
On RV64 we would use packw instead of pack. Otherwise it's the same sequence.

My analysis so far is built on some different assumptions, such as no support for the ternary instructions, for lack of a third register read port.

I was not assuming funnel shifts or ternary instructions either. As I wrote above:

In a previous discussion on the bitmanip mailing list it was concluded that in most cases (even without funnel shifts), the most efficient way of implementing the shifter would be a 2*XLEN rotate shift.

When implementing only Zbb then it possibly would make sense to implement the shifter differently, because other implementations provide better opportunities for sharing resources with rev8, rev, and orc.b. (I have writing a small 32-bit Zbb unit that demonstrates this on my todo list.)
But I'd argue that just "Zbb" + "Zbf" is an odd combination. I think it's more likely that a core implementing "Zbb" would do that as part of "B".

I've attached a modified version of your rvb_shifter.v that I believe eliminates the wrap-around for BFP and should also be a little smaller in hardware than your current one.

Thanks. I'll have a look.

Unfortunately, I haven't had time to test it, because I don't yet have the same setup as you. But I have reasonably high confidence it will work. If it doesn't, let me know, and I'll invest the energy to fix it.

It doesn't seem to implement BFPW on RV64 in accordance to your definition of bfp.
testdata_4.hex: idx=001 insn=0x0800703b rs1=0x7d312fe94148526f rs2=0x2bb76a4d192b8f72 rs3=0x707a991048499f3c rd=0x00000000414ffa6f expected=0x00000000414b926f ERROR
Makefile:64: recipe for target 'testbench_4.ok' failed

Same for BFP on RV32:
testdata_5.hex: idx=009 insn=0x08007033 rs1=0x00000000fead627b rs2=0x000000001a214e1d rs3=0x0000000010cc4f94 rd=0x00000000fead67ff expected=0x00000000fead643b ERROR
Makefile:68: recipe for target 'testbench_5.ok' failed

Only BFP on RV64 seems to be correct.

It doesn't seem to implement BFPW on RV64 in accordance to your definition of bfp.

So sorry.  I logged on early this morning because I realized I forgot one little detail for the 32-bit case.  Try this one:
rvb_shifter.zip
Fingers crossed.

Suffice it to say, I disagree.

Do you have data / reference designs that support your position? Back when we had this discussion on the mailing list we benchmarked various designs for shifters and found that this one is the most efficient. (Don't use Yosys to benchmark this. We've found that Yosys misses some optimizations that other tools don't, causing the results to swing it the wrong direction sometimes.)

then perhaps that will be sufficient argument for making the change

The main argument for the rotating BFP behavior remains the same: 3 macro-ops for placing a field >16 bits. (see above)

Try this one: rvb_shifter.zip Fingers crossed.

BFPW on RV64:
testdata_4.hex: idx=044 insn=0x0800703b rs1=0x3a0197f21705a22d rs2=0xcb4a222d6ef770ea rs3=0x9da4637f28baf8da rd=0x000000007505a22d expected=0x000000007505a238 ERROR
Makefile:64: recipe for target 'testbench_4.ok' failed

BFP on RV32:
testdata_5.hex: idx=026 insn=0x08007033 rs1=0x00000000b74c3d2a rs2=0x0000000016ded635 rs3=0x00000000b2df0d45 rd=0x00000000774c3d2a expected=0x00000000774c3d2d ERROR
Makefile:68: recipe for target 'testbench_5.ok' failed

For those last two reported errors, it looks to me like my unit is delivering the correct result without wraparound, while the "expected" result incorrectly includes the wraparound.

Do you have data / reference designs that support your position?

I do, but not that I can share.
Let's just assume I'm wrong about that, if there's nobody to back me up.  By modifying your rvb_shifter, I'm also attempting to show that, even under your own assumptions, the non-wraparound BFP can be a little more efficient.

The main argument for the rotating BFP behavior remains the same: 3 macro-ops for placing a field >16 bits.

That's assuming a 3-instruction fusion of ADDI + PACK + BFP.  Forgive me, but I have to think machines that support that fusion will be rare at best.
As long as we're assuming aggressive fusion, why can't the competition fuse instructions too?  Let's say I solve my original example problem with this code:
lui t0,0xFFC00
addi t0,t0,0x1F
and t0,a0,t0
slli a0,a1,15
srli a0,a0,10
or a0,t0,a0

Looks to me that the first three instructions and the last three are each fuse-able sequences, giving me only 2 macro-ops, no wraparound BFP needed.
For this hypothetical RV32 machine, not only would the 6-instruction sequence above be documented as the best idiom for bit-field insertion, we could also expect the two fuse-able sequences (and some others like them) to be targeted by the compiler for other purposes, making them more generally useful than your BFP sequence, I would think.
For RV64, I can conjure a similar scheme, sometimes 2 macro-ops and sometimes 3.
Can you prove this isn't a better solution?  In my opinion, your justification for the wraparound BFP hangs on a very thin thread.

I do, but not that I can share.

That's unfortunate. Can you share what kind of shifter architecture it is? Maybe it is a kind that we did not evaluate.

That's assuming a 3-instruction fusion of ADDI + PACK + BFP. Forgive me, but I have to think machines that support that fusion will be rare at best.

The whole idea of BFP is that, instead of standardizing an 48-bit or 64-bit instruction, we standardize an instruction that can be used in either a fuse-able ADDI+PACK+BFP sequence or a fuse-able LUI+ADDI+BFP sequence, because the feedback I got from the community is that they rather fuse three instructions than decode one long instruction.
So I'm not assuming a machine here that aggressively fuses any fuse-able three instruction sequence. Just one that fuses the two sequences BFP was specifically built for.
I'm looking at the above error message now and post again when I have a reply there.

Can you prove this isn't a better solution? In my opinion, your justification for the wraparound BFP hangs on a very thin thread.

I concede that it doesn't hang on a steel wire.  :D
From a point of just instruction semantics I prefer the warp-around version because the non-wrapping version can always be emulated by setting a shorter length. So I think the resource difference must either be significant, or we must be very certain that giving up on the wrapping behavior doesn't mean giving up on a perfectly valid use-case of the wrapping version.

I must have somehow f***ed up the insn.h change for testing against your bfp semantics when I ran it yesterday. I re-ran the test today and now it's looking fine. Weird. Transistor counts:

module
unmodified
modified
rel change

rvb_shifter_xlen32_sbop0_bfp0
3036
3044
+0.26%

rvb_shifter_xlen32_sbop0_bfp1
5840
5886
+0.78%

rvb_shifter_xlen32_sbop1_bfp0
4098
4036
-1.51%

rvb_shifter_xlen32_sbop1_bfp1
7070
7048
-0.31%

rvb_shifter_xlen64_sbop0_bfp0
7484
7434
-0.66%

rvb_shifter_xlen64_sbop0_bfp1
12934
12630
-2.35%

rvb_shifter_xlen64_sbop1_bfp0
9458
9446
-0.12%

rvb_shifter_xlen64_sbop1_bfp1
15810
15166
-4.07%

As you can see the noise floor in this test is quite high. (-1.51% area change in a version that doesn't even support BFP.) But it looks like your version really is a tiny bit smaller, but only on RV64. On RV32 it's on average even a bit larger (but I would argue it's just noise either way in the RV32 case).
In your shifter architecture, with your tools, is the difference there also in that 2%-4% neighborhood, or is it larger?

From a point of pure instruction semantics I prefer the warp-around version because the non-wrapping version can always be emulated by setting a shorter length.

Yes, I had that same thought as well.  But now you also have a taste of what I'm seeing on the cost side of the ledger.  Thanks for running the experiment.
Given my different design, without funnel shifts, the baseline size of my shifter unit is smaller.  The relative delta I get for implementing the wraparound BFP is correspondingly higher,  more consistently in the 5% range, give or take.
I suspect the reason you're not seeing the same effect for XLEN = 32 is because you're having the tools optimize down the 64-bit rvb_shifter, and there's some overhead remaining from that process.  My guess is, if you created pure 32-bit versions of the same units, yours and mine, the difference would show up clearly again.

The whole idea of BFP is that, instead of standardizing an 48-bit or 64-bit instruction, we standardize an instruction that can be used in either a fuse-able ADDI+PACK+BFP sequence or a fuse-able LUI+ADDI+BFP sequence  [...]

This seems logical, but I'm afraid it may be an unintentional false promise from the developers.  Because, although they may start off with plans to implement the fusions you say, at some point during the long development process it's almost certain to occur to them that fusing other three-instruction sequences will give a bigger payoff.  So one thing I'm pretty sure of, the only machines to fuse those BFP sequences will be ones that already fuse many other three-instruction sequences.  Which leaves me expecting only a small fraction of high-end RISC-V machines (if any).
That's my take.

I've made some changes to the rvb_shifter core and now I'm at -5% for the largest version, with unchanged BFP semantics.
This is not to say that the unchanged semantics necessarily has lower area, but it shows that there is a not of noise involved in these measurements.

module
old
new
rel change

rvb_shifter_xlen32_sbop0_bfp0
3036
3030
-0.19%

rvb_shifter_xlen32_sbop0_bfp1
5840
5848
+0.13%

rvb_shifter_xlen32_sbop1_bfp0
4098
4088
-0.24%

rvb_shifter_xlen32_sbop1_bfp1
7070
7004
-0.93%

rvb_shifter_xlen64_sbop0_bfp0
7484
7338
-1.95%

rvb_shifter_xlen64_sbop0_bfp1
12934
12974
+0.30%

rvb_shifter_xlen64_sbop1_bfp0
9458
9456
-0.02%

rvb_shifter_xlen64_sbop1_bfp1
15810
14998
-5.13%

I suspect the reason you're not seeing the same effect for XLEN = 32 is because you're having the tools optimize down the 64-bit rvb_shifter, and there's some overhead remaining from that process.

I don't think so. The new version of my core now has an explicit 32-bit version of the datapath and the core size for 32 bit is virtually unchanged.
I think it's because the only real optimization in your version is that it gets rid of wire [63:0] XZ = {Z[63:32], wmode ? X[63:32] : Z[31:0]};, and that operation was free anyway for a 32 bit core because there wmode is constant 1.

This seems logical, but I'm afraid it may be an unintentional false promise from the developers. [..] So one thing I'm pretty sure of, the only machines to fuse those BFP sequences will be ones that already fuse many other three-instruction sequences. Which leaves me expecting only a small fraction of high-end RISC-V machines (if any).

Sure, no machine will add instruction fusion just for BFP. But that wasn't the argument anyway.
But I strongly disagree with the "if any" portion of your comment. RISC-V cores that fuse macro ops already exist.
I also disagree with the quantifier in "already fuse many other three-instruction sequences". I'd expect a core that can fuse any three-instruction sequence and supports BFP to also fuse the BFP sequences.
And pretty much everyone I talked to who said they support macro-op fusion or are planning on supporting macro-op fusion told me that they have macro-ops of up to three instructions in mind.

I've made some changes to the rvb_shifter core and now I'm at -5% for the largest version, with unchanged BFP semantics.

Okay, now here's my modification of your update, again changing BFP to not wrap around:
rvb_shifter-3.zip
Actually, I'm providing two versions for you to try this time.  (And as before, I'm still doing this blind, without testing, so I apologize in advance if they don't pass tests right away.)

I'd expect a core that can fuse any three-instruction sequence and supports BFP to also fuse the BFP sequences.

You mean, if a core supports BFP and can fuse any three-instruction sequence, it will fuse the three-instruction BFP sequences?  I happen to know of a core in development for which that won't be true.  (But perhaps it's an outlier; I don't know.)

Pretty much everyone I talked to who said they support macro-op fusion in their core or are planning to support macro-op fusion told me that they have macro-ops of up to three instructions in mind.

In which case maybe (or maybe not) the 2-macro-op example I gave earlier is supported, trumping the 3-macro-op BFP sequence.  The salient point being, it's hard to predict this right now.
The only example use case we have so far for wraparound BFP provides a small benefit for only a minority of bitfield insertions (width >= XLEN - 16, definitely a minority for RV64, and likely so for RV32 too) and also depends on some assumptions that may or may not pan out.  I claim I'm seeing a cost of about 5% in the size (and maybe delay) of the shifter, at least for some implementations.  For comparison, can the expected benefit even be measured with confidence, given the future unknowns involved?

(And as before, I'm still doing this blind, without testing, so I apologize in advance if they don't pass tests right away.)

I've gotten now so I can run make test within verilog/rvb_shifter.  Both of my new modified rvb_shfiter versions seemed to pass (with appropriate cproofs/insns.h, of course), so hopefully that's a good sign they will for you too.

Actually, I'm providing two versions for you to try this time.

Ok, I love the results for your 3b version.

Variant
orig
3a
3b
rel 3a
rel 3b

rvb_shifter_xlen32_sbop0_bfp0
3030
3038
3016
+0.26
-0.46

rvb_shifter_xlen32_sbop0_bfp1
5848
5718
4846
-2.22
-17.13

rvb_shifter_xlen32_sbop1_bfp0
4088
4218
4094
+3.18
+0.15

rvb_shifter_xlen32_sbop1_bfp1
7004
6620
6108
-5.48
-12.79

rvb_shifter_xlen64_sbop0_bfp0
7338
7386
7436
+0.65
+1.34

rvb_shifter_xlen64_sbop0_bfp1
12974
12898
10214
-0.59
-21.27

rvb_shifter_xlen64_sbop1_bfp0
9456
9530
9470
+0.78
+0.15

rvb_shifter_xlen64_sbop1_bfp1
14998
14970
12270
-0.19
-18.19

It's counter-intuitive to me why << bfp_off is so much more efficient than widening the main shifter by adding that Z signal. My expectation would have been that for 32-bit the Z signals adds 16+24+28+30+31 = 129 MUXes and that {din_rs2[15:0] & ~bfp_mask} << bfp_off would add 17+19+23+31+32 = 122 MUXes, almost the same. It looks like the other optimizations are making the big difference here (sharing of A&~X with sbclr, simplified bb, etc).
I will send an email to the bitmanip mailing list asking if anyone has a good objection to removing the rotate behavior from BFP.

Question (not having looked at all the detailed verilog): do the cost estimates for BFP include also handling all the other types of shifts and rotates (so, there is a single shifter/rotator that handles all the various ops)?
The example given for wrapping BFP is a bit contrived, in my opinion; I  am suspicious when one of the operands (in this case, the the immediate in bfp_mask) is a fixed value for all the useful cases.

do the cost estimates for BFP include also handling all the other types of shifts and rotates (so, there is a single shifter/rotator that handles all the various ops)?

Yes, all supported shift operations are covered by a single shifter unit.  Although in my case, only the two-input functions are supported, so the funnel shifts aren't included.  Clifford considers four different cases for both RV32 and RV64: with/without the single-bit functions (SBSET, etc.), and with/without BFP.  He always includes the funnel shifts, together with all other shift operations (SLL, SRL, SRA, etc.).

Once the rotate ops are implemented, all the other ops come almost for free
(except for reading the 3rd operand of the funnel shift).
I'm not convinced that generating a mask that wraps or doesn't  is even
significant; it just changes a high/lo mask AND into a high/lo mask XOR.
Not that I'm convinced that wraparound is necessary :-)
On Mon, Oct 21, 2019 at 12:12 PM John Hauser<EMAIL_ADDRESS>wrote:

do the cost estimates for BFP include also handling all the other types of
shifts and rotates (so, there is a single shifter/rotator that handles all
the various ops)?
Yes, all supported shift operations are covered by a single shifter unit.
Although in my case, only the two-input functions are supported, so the
funnel shifts aren't included. Clifford considers four different cases for
both RV32 and RV64: with/without the single-bit functions (SBSET, etc.),
and with/without BFP. He always includes the funnel shifts, together with
all other shift operations (SLL, SRL, SRA, etc.).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-bitmanip/issues/48?email_source=notifications&email_token=AHPXVJUXRJH64LW6SLZV6HDQPX5K5A5CNFSM4I56TXRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB3OPFY#issuecomment-544663447,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJUYF7FAOR5TRSLGIF3QPX5K5ANCNFSM4I56TXRA
.

I'm not convinced that generating a mask that wraps or doesn't is even significant; it just changes a high/lo mask AND into a high/lo mask XOR.

But it's not free, and, begging your pardon, I've given an estimate of what the cost is for me.  Show me there's a compelling reason to implement the wraparound, and I'll happily drop my objection to it.

I think we probably have a different threshold of "cost". It may be 50% or
a core, but a vanishingly small percentage of an entire SOC.
In any case, I'm perfectly happy to not have wraparound for this.
Its just that I don't think the cost should be the main focus; I think use
cases should be. Just my opinion, and note that I don't have biases
otherwise.
On Mon, Oct 21, 2019 at 1:46 PM John Hauser<EMAIL_ADDRESS>wrote:

I'm not convinced that generating a mask that wraps or doesn't is even
significant; it just changes a high/lo mask AND into a high/lo mask XOR.
But it's not free, and, begging your pardon, I've given an estimate of
what the cost is for me. Show me there's a compelling reason to implement
the wraparound, and I'll happily drop my objection to it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-bitmanip/issues/48?email_source=notifications&email_token=AHPXVJUSXXBEO22TOLZW673QPYIMDA5CNFSM4I56TXRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB3XSTY#issuecomment-544700751,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJVFH4OLPRIKXDSJ2HTQPYIMDANCNFSM4I56TXRA
.

In terms of area costs alone, I can agree.  But an accumulation of excess transistors in the wrong places can impact the maximum clock speed, which has a more global impact.  And the integer ALUs are just such a place.  The transistors you have to have, you pay the cost, but it's wise to exclude whatever you can.  It's conceivable (though not guaranteed) that a 5% savings in every critical unit could add up to a 5% faster clock speed for the core.

In my experience, ALUs are almost never  the critical path.
Branch resolution, TLB translation, and especially Cache/SRAM access,  -
lots of other functionality, but ALUs - rarely.
On Mon, Oct 21, 2019 at 2:41 PM John Hauser<EMAIL_ADDRESS>wrote:

In terms of area costs alone, I can agree. But an accumulation of excess
transistors in the wrong places can impact the maximum clock speed, which
has a more global impact. And the integer ALUs are just such a place. The
transistors you have to have, you pay the cost, but it's wise to exclude
whatever you can. It's conceivable (though not guaranteed) that a 5%
savings in every critical unit could add up to a 5% faster clock speed for
the core.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-bitmanip/issues/48?email_source=notifications&email_token=AHPXVJWDF3V3MMDC65SC4D3QPYOYBA5CNFSM4I56TXRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB34KQY#issuecomment-544720195,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJWACOCMCDNEAUIVXL3QPYOYBANCNFSM4I56TXRA
.

In any case, I'm perfectly happy to not have wraparound for this.
Its just that I don't think the cost should be the main focus; I think use
cases should be. Just my opinion, and note that I don't have biases
otherwise.

I have a hard time producing convincing usage examples for the wraparound behavior. So I'm okay with dropping it. (But I still think it is the "nicer" instruction semantic. :)
However, you raise an interesting point. The reason why even on RV64 we only allow 16-bit to be placed is to safe chip area, but supporting 32-bit does not actually add that much in terms of area. So maybe that is overly conservative and a premature optimization.
So, at least for now, I think we should go with the following definition for BFP (and new BFPW):
uint_xlen_t bfp(uint_xlen_t rs1, uint_xlen_t rs2)
{
        uint_xlen_t cfg = rs2 >> 16;
        if (XLEN > 32) {
                cfg = rs2 >> (XLEN/2);
                if ((cfg >> 30) == 2)
                        cfg = cfg >> 16;
        }
        int len = (cfg >> 8) & (XLEN/2-1);
        int off = cfg & (XLEN-1);
        len = len ? len : XLEN/2;
        uint_xlen_t mask = slo(0, len) << off;
        uint_xlen_t data = rs2 << off;
        return (data & mask) | (rs1 & ~mask);
}

The behavior on RV32 is unchanged. On RV64 this will take the config from rs2[63:48] when rs2[63:62] == 2 and from rs2[47:32] otherwise. This allows the use of LUI to construct the config for the static case, and PACKH when it comes from two registers.
Synthesis results:
rvb_shifter_xlen32_sbop0_bfp0          3024
rvb_shifter_xlen32_sbop0_bfp1          4816
rvb_shifter_xlen32_sbop1_bfp0          4048
rvb_shifter_xlen32_sbop1_bfp1          6034
rvb_shifter_xlen64_sbop0_bfp0          7362
rvb_shifter_xlen64_sbop0_bfp1         11804
rvb_shifter_xlen64_sbop1_bfp0          9502
rvb_shifter_xlen64_sbop1_bfp1         13678

This is the patch:
bfp64_diff.txt

The behavior on RV32 is unchanged.

By that I mean unchanged with respect to what @jhauser-us  is suggesting. This is still dropping the wrap-around behavior.

I have now put this in a branch of riscv-bitmanip: https://github.com/riscv/riscv-bitmanip/tree/bfp64


Bugfix for unescaped quote issue for endpoint getProfileBotJsonUnderPending

This is to resolve an issue that still persists after the bugfix PR #252.
Bugfix PR #252 didn't solve the last case from the list below:

Actions from Web UI (NATS Used)

Create : Quotes are escaped as expected with \" in the JSON/NATS message
Edit: Quotes are escaped as expected with \" in the JSON/NATS message

Actions from Sync Workflow (API Used) - provisioned-profile-bot-json

Create: No Result as Expected (Not Approved/Provisioned Yet)
Sync (Provisioned Create or Edit): Quotes are escaped as expected \" in the JSON/NATS message
Sync (Pending Edit PR Open): Create (Provisioned) JSON/NATS message returned with expected \"

Actions from Sync Pending Workflow (API Used) - under-pending-profile-bot-json

Create: Quotes are escaped as expected \" in the JSON/NATS message
Edit: Quotes are not escaped properly \\" in the JSON/NATS message

Therefore, this PR is to accommodate the last case.
Fixes #213

Thanks @j-pye for catching the issue and narrowing it down to the cause. Much appreciated.

Given the nature of the inconsistent double quote issue, there are concerns over maintaining this proposed bugfix solution going forward. It's decided to adapt a different approach:
Instead of " with \" or \\\", replace " with   .


omp.library-only with Cray OpenMP

Bug summary
Cray CCE 15.0.0 objects to how omp_get_max_threads is called at runtime with the error:
CCE OpenMP fatal error: omp_get_max_threads attempted from non-OpenMP thread
I am not sufficiently familiar with the OpenMP specification to indicate if I think this is an AdaptiveCPP bug, a Cray OpenMP bug or a disagreement over what the standard actually specifies.
The code is as follows. Note that although there are two blocks in this source the contents is identical, the error is thrown on the second block.
#include <CL/sycl.hpp>
#include <iostream>
#include <vector>

using namespace cl;

int main(int argc, char **argv){
{
  sycl::device device{};
  sycl::queue queue{device};

  std::cout << 0 << std::endl;
  queue.submit([&] (sycl::handler& h) {

    h.parallel_for(
      sycl::nd_range<1>(
        sycl::range<1>(32),
        sycl::range<1>(32)
      ),
      [=] (sycl::nd_item<1> id) {
        const size_t lid = id.get_local_linear_id();
        const size_t gid = id.get_global_linear_id();
      });
  }).wait_and_throw();

  std::cout << 1 << std::endl;
}

{
  sycl::device device{};
  sycl::queue queue{device};

  std::cout << 0 << std::endl;
  queue.submit([&] (sycl::handler& h) {

    h.parallel_for(
      sycl::nd_range<1>(
        sycl::range<1>(32),
        sycl::range<1>(32)
      ),
      [=] (sycl::nd_item<1> id) {
        const size_t lid = id.get_local_linear_id();
        const size_t gid = id.get_global_linear_id();
      });
  }).wait_and_throw();

  std::cout << 1 << std::endl;
}

  return 0;
}

To Reproduce

Cray cce15 with cray compiler envrionment (in this case Archer2):
AdaptiveCpp/Hipsycl 0.9.4

$ cc --version
Cray clang version 15.0.0  (324a8e7de6a18594c06a0ee5d8c0eda2109c6ac6)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cray/pe/cce/15.0.0/cce-clang/x86_64/share/../bin
$ syclcc --hipsycl-targets=omp.library-only main.cpp
$ OMP_NUM_THREADS=4 ./a.out
0
1
0
CCE OpenMP fatal error: omp_get_max_threads attempted from non-OpenMP thread

Steps to reproduce the behavior.
If possible, provide a minimal reproducer. The shorter the reproducing code snippet is, the easier will it be for us to debug and understand the issue.
Expected behavior
Code executes without error.
Describe your setup

Cray CCE 15 (archer2) (Cray clang version 15.0.0  (324a8e7de6a18594c06a0ee5d8c0eda2109c6ac6))
<EMAIL_ADDRESS><EMAIL_ADDRESS>omp host compiler only install
Hipsycl 0.9.4 (release commit)

Optional additional diagnostic information
HIPSYCL_DRYRUN=1 syclcc --hipsycl-targets=omp.library-only main.cpp
syclcc warning: No optimization flag was given, optimizations are disabled by default. Performance may be degraded. Compile with e.g. -O2/-O3 to enable optimizations.
/opt/cray/pe/craype/2.7.19/bin/CC -isystem /mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/hipsycl-0.9.4-trjq4ms2lolsjqgbpxax5lcmooc4eifp/bin/../include/ -D__HIPSYCL__ -std=c++17 -D__HIPSYCL_ENABLE_OMPHOST_TARGET__ -I/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/include -fopenmp -D_ENABLE_EXTENDED_ALIGNED_STORAGE main.cpp -L/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/hipsycl-0.9.4-trjq4ms2lolsjqgbpxax5lcmooc4eifp/bin/../lib/ -lhipSYCL-rt -Wl,-rpath=/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/hipsycl-0.9.4-trjq4ms2lolsjqgbpxax5lcmooc4eifp/bin/../lib/ -L/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/lib -lboost_context -lboost_fiber -Wl,-rpath=/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/lib -fopenmp

syclcc --hipsycl-version
syclcc [hipSYCL compilation driver], Copyright (C) 2018-2022 Aksel Alpay and the hipSYCL project
  hipSYCL version: 0.9.4
  Installation root: /mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/hipsycl-0.9.4-trjq4ms2lolsjqgbpxax5lcmooc4eifp
  Available runtime backends:
     librt-backend-omp.so

Full configuration [can be overriden using environment variables or command line arguments]:
    version-major: 0
    version-minor: 9
    version-patch: 4
    plugin-llvm-version-major: 0
    plugin-with-cpu-acceleration: false
    default-clang: (unconfigured)
    default-nvcxx: (unconfigured)
    default-platform: cpu
    default-cuda-path: (unconfigured)
    default-gpu-arch: (unconfigured)
    default-cpu-cxx: /opt/cray/pe/craype/2.7.19/bin/CC
    default-rocm-path: /opt/rocm
    default-use-bootstrap-mode: false
    default-is-dryrun: false
    default-use-accelerated-cpu: false
    default-clang-include-path: (unconfigured)
    default-sequential-link-line: -L/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/lib -lboost_context -lboost_fiber -Wl,-rpath=/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/lib
    default-sequential-cxx-flags: -I/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/include -D_ENABLE_EXTENDED_ALIGNED_STORAGE
    default-omp-link-line: -L/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/lib -lboost_context -lboost_fiber -Wl,-rpath=/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/lib -fopenmp
    default-omp-cxx-flags: -I/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/boost-1.82.0-hvxctqypuu3vv6bv2dfvbq75qr4symyq/include -fopenmp -D_ENABLE_EXTENDED_ALIGNED_STORAGE
    default-rocm-link-line: -Wl,-rpath=$HIPSYCL_ROCM_PATH/lib -Wl,-rpath=$HIPSYCL_ROCM_PATH/hip/lib -L/opt/rocm/lib -L/opt/rocm/hip/lib -lamdhip64
    default-rocm-cxx-flags: -isystem $HIPSYCL_PATH/include/hipSYCL/std/hiplike -isystem  -U__FLOAT128__ -U__SIZEOF_FLOAT128__ -I$HIPSYCL_ROCM_PATH/include -I$HIPSYCL_ROCM_PATH/include --rocm-device-lib-path=$HIPSYCL_ROCM_PATH/amdgcn/bitcode --rocm-path=$HIPSYCL_ROCM_PATH -fhip-new-launch-api -mllvm -amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false -D__HIP_ROCclr__
    default-cuda-link-line: -Wl,-rpath=$HIPSYCL_CUDA_LIB_PATH -L$HIPSYCL_CUDA_LIB_PATH -lcudart
    default-cuda-cxx-flags: -U__FLOAT128__ -U__SIZEOF_FLOAT128__ -isystem $HIPSYCL_PATH/include/hipSYCL/std/hiplike
    default-is-explicit-multipass: false
    default-save-temps: false

HIPSYCL_DEBUG_LEVEL=3 ./a.out
[hipSYCL Info] kernel_cache: Registering kernel ZZ4mainENK3$_0clERN7hipsycl4sycl7handlerEEUlNS1_7nd_itemILi1EEEE_
[hipSYCL Info] kernel_cache: Registering kernel ZZ4mainENK3$_1clERN7hipsycl4sycl7handlerEEUlNS1_7nd_itemILi1EEEE_
[hipSYCL Info] backend_loader: Searching path for backend libs: '"/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/hipsycl-0.9.4-trjq4ms2lolsjqgbpxax5lcmooc4eifp/bin/../lib/hipSYCL"'
[hipSYCL Info] backend_loader: Successfully opened plugin: "/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/hipsycl-0.9.4-trjq4ms2lolsjqgbpxax5lcmooc4eifp/bin/../lib/hipSYCL/librt-backend-omp.so" for backend 'omp'
[hipSYCL Info] Registering backend: 'omp'...
[hipSYCL Info] multi_queue_executor: Spawned for backend OpenMP with configuration:
[hipSYCL Info]   device 0:
[hipSYCL Info]     memcpy lane: 0
[hipSYCL Info]     kernel lane: 1
[hipSYCL Info] Discovered devices from backend 'OpenMP':
[hipSYCL Info]   device 0:
[hipSYCL Info]     vendor: the hipSYCL project
[hipSYCL Info]     name: hipSYCL OpenMP host device
[hipSYCL Info] dag_manager: DAG manager is alive!
[hipSYCL Info] runtime: ******* rt launch initiated ********
[hipSYCL Info] queue: Constructed queue with node group id 1
0
[hipSYCL Info] dag_manager: Checking DAG flush opportunity...
[hipSYCL Info] dag_manager: Submitting asynchronous flush...
[hipSYCL Info] dag_builder: DAG contains operations:
[hipSYCL Info] 0. kernel: ZZ4mainENK3$_0clERN7hipsycl4sycl7handlerEEUlNS1_7nd_itemILi1EEEE_ @node 0x27a1c0
[hipSYCL Info] dag_manager: waiting for async worker...
[hipSYCL Info] dag_manager [async]: Flushing!
[hipSYCL Info] dag_manager [async]: Submitting node to scheduler!
[hipSYCL Info] multi_queue_executor: Processing node 0x27a1c0 with 0 non-virtual requirement(s) and 0 direct requirement(s).
[hipSYCL Info] multi_queue_executor: Dispatching to lane 1: kernel: ZZ4mainENK3$_0clERN7hipsycl4sycl7handlerEEUlNS1_7nd_itemILi1EEEE_
[hipSYCL Info] inorder_executor: Processing node 0x27a1c0 with 0 non-virtual requirement(s) and 0 direct requirement(s).
[hipSYCL Info] inorder_executor: Dispatching to lane 0x27ae60: kernel: ZZ4mainENK3$_0clERN7hipsycl4sycl7handlerEEUlNS1_7nd_itemILi1EEEE_
[hipSYCL Info] omp_queue: Submitting kernel...
[hipSYCL Info] omp_queue: Inserting event into queue...
[hipSYCL Info] dag_manager [async]: DAG flush complete.
[hipSYCL Info] omp_queue [async]: Invoking kernel!
1
[hipSYCL Info] runtime: ******* rt shutdown ********
[hipSYCL Info] dag_manager: Waiting for async worker...
[hipSYCL Info] dag_manager: Submitting asynchronous flush...
[hipSYCL Info] dag_manager: Nothing to do
[hipSYCL Info] dag_manager: waiting for async worker...
[hipSYCL Info] dag_manager: Shutdown.
[hipSYCL Info] backend_loader: Searching path for backend libs: '"/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/hipsycl-0.9.4-trjq4ms2lolsjqgbpxax5lcmooc4eifp/bin/../lib/hipSYCL"'
[hipSYCL Info] backend_loader: Successfully opened plugin: "/mnt/lustre/a2fs-work2/work/e723/e723/js0259/git/spack/opt/spack/linux-sles15-zen2/cce-15.0.0/hipsycl-0.9.4-trjq4ms2lolsjqgbpxax5lcmooc4eifp/bin/../lib/hipSYCL/librt-backend-omp.so" for backend 'omp'
[hipSYCL Info] Registering backend: 'omp'...
[hipSYCL Info] multi_queue_executor: Spawned for backend OpenMP with configuration:
[hipSYCL Info]   device 0:
[hipSYCL Info]     memcpy lane: 0
[hipSYCL Info]     kernel lane: 1
[hipSYCL Info] Discovered devices from backend 'OpenMP':
[hipSYCL Info]   device 0:
[hipSYCL Info]     vendor: the hipSYCL project
[hipSYCL Info]     name: hipSYCL OpenMP host device
[hipSYCL Info] dag_manager: DAG manager is alive!
[hipSYCL Info] runtime: ******* rt launch initiated ********
[hipSYCL Info] queue: Constructed queue with node group id 2
0
[hipSYCL Info] dag_manager: Checking DAG flush opportunity...
[hipSYCL Info] dag_manager: Submitting asynchronous flush...
[hipSYCL Info] dag_builder: DAG contains operations:
[hipSYCL Info] 0. kernel: ZZ4mainENK3$_1clERN7hipsycl4sycl7handlerEEUlNS1_7nd_itemILi1EEEE_ @node 0x27a1c0
[hipSYCL Info] dag_manager: waiting for async worker...
[hipSYCL Info] dag_manager [async]: Flushing!
[hipSYCL Info] dag_manager [async]: Submitting node to scheduler!
[hipSYCL Info] multi_queue_executor: Processing node 0x27a1c0 with 0 non-virtual requirement(s) and 0 direct requirement(s).
[hipSYCL Info] multi_queue_executor: Dispatching to lane 1: kernel: ZZ4mainENK3$_1clERN7hipsycl4sycl7handlerEEUlNS1_7nd_itemILi1EEEE_
[hipSYCL Info] inorder_executor: Processing node 0x27a1c0 with 0 non-virtual requirement(s) and 0 direct requirement(s).
[hipSYCL Info] inorder_executor: Dispatching to lane 0x27ac00: kernel: ZZ4mainENK3$_1clERN7hipsycl4sycl7handlerEEUlNS1_7nd_itemILi1EEEE_
[hipSYCL Info] omp_queue: Submitting kernel...
[hipSYCL Info] omp_queue: Inserting event into queue...
[hipSYCL Info] dag_manager [async]: DAG flush complete.
[hipSYCL Info] omp_queue [async]: Invoking kernel!
CCE OpenMP fatal error: omp_get_max_threads attempted from non-OpenMP thread

hipsycl-info
=================Backend information===================
Loaded backend 0: OpenMP
  Found device: hipSYCL OpenMP host device

=================Device information===================
***************** Devices for backend OpenMP *****************
Device 0:
 General device information:
  Name: hipSYCL OpenMP host device
  Backend: OpenMP
  Vendor: the hipSYCL project
  Arch: <native-cpu>
  Driver version: 1.2
  Is CPU: 1
  Is GPU: 0
 Default executor information:
  Is in-order queue: 1
  Is out-of-order queue: 0
  Is task graph: 0
 Device support queries:
  images: 0
  error_correction: 0
  host_unified_memory: 1
  little_endian: 1
  global_mem_cache: 1
  global_mem_cache_read_only: 0
  global_mem_cache_read_write: 1
  emulated_local_memory: 1
  sub_group_independent_forward_progress: 0
  usm_device_allocations: 1
  usm_host_allocations: 1
  usm_atomic_host_allocations: 1
  usm_shared_allocations: 1
  usm_atomic_shared_allocations: 1
  usm_system_allocations: 1
  execution_timestamps: 1
 Device properties:
  max_compute_units: 256
  max_global_size0:<PHONE_NUMBER>3709551615
  max_global_size1:<PHONE_NUMBER>3709551615
  max_global_size2:<PHONE_NUMBER>3709551615
  max_group_size: 1024
  max_num_sub_groups:<PHONE_NUMBER>3709551615
  preferred_vector_width_char: 4
  preferred_vector_width_double: 1
  preferred_vector_width_float: 1
  preferred_vector_width_half: 2
  preferred_vector_width_int: 1
  preferred_vector_width_long: 1
  preferred_vector_width_short: 2
  native_vector_width_char: 4
  native_vector_width_double: 1
  native_vector_width_float: 1
  native_vector_width_half: 2
  native_vector_width_int: 1
  native_vector_width_long: 1
  native_vector_width_short: 2
  max_clock_speed: 0
  max_malloc_size:<PHONE_NUMBER>3709551615
  address_bits: 64
  max_read_image_args: 0
  max_write_image_args: 0
  image2d_max_width: 0
  image2d_max_height: 0
  image3d_max_width: 0
  image3d_max_height: 0
  image3d_max_depth: 0
  image_max_buffer_size: 0
  image_max_array_size: 0
  max_samplers: 0
  max_parameter_size:<PHONE_NUMBER>3709551615
  mem_base_addr_align: 8
  global_mem_cache_line_size: 64
  global_mem_cache_size: 1
  global_mem_size:<PHONE_NUMBER>3709551615
  max_constant_buffer_size:<PHONE_NUMBER>3709551615
  max_constant_args:<PHONE_NUMBER>3709551615
  local_mem_size:<PHONE_NUMBER>3709551615
  printf_buffer_size:<PHONE_NUMBER>3709551615
  partition_max_sub_devices: 0
  vendor_id:<PHONE_NUMBER>3709551615
  sub_group_sizes: 1

The OpenMP specification says in https://www.openmp.org/spec-html/5.0/openmpsu112.html

The omp_get_max_threads routine returns an upper bound on the number of threads that could be used to form a new team if a parallel construct without a num_threads clause were encountered after execution returns from this routine.

It only talks about future parallel constructs, not about current parallel constructs, so to me it does not sound like it is illegal to use outside of a parallel region.
Perhaps we can ask someone who knows more about OpenMP - @tomdeakin perhaps?

I agree that omp_get_max_threads should be callable outside a parallel region. I did some more digging with CCE - it very much objects to OpenMP calls in additional threads:
#include <omp.h>
#include <iostream>
#include <thread>

int main(int argc, char ** argv){

auto lambda_max = []() -> void{
  std::cout << omp_get_max_threads() << std::endl;
};

// Works
//lambda_max();
//lambda_max();

// fails
std::thread t1(lambda_max);
t1.join();
std::thread t2(lambda_max);
t2.join();

return 0;
}

Fails with:
$ OMP_NUM_THREADS=1 ./a.out
1
CCE OpenMP fatal error: omp_get_max_threads attempted from non-OpenMP thread

A parallel region is also rejected:
#include <omp.h>
#include <iostream>
#include <thread>

int main(int argc, char ** argv){

auto lambda_omp = []() -> void{
#pragma omp parallel
{
}
};

std::thread t1(lambda_omp);
t1.join();
std::thread t2(lambda_omp);
t2.join();
return 0;
}

Gives:
CCE OpenMP fatal error: OpenMP parallel attempted from non-OpenMP thread

There is one more relevant bit of the OpenMP spec which I think I think is the bit that's causing the problem. The API call says:

The value returned by omp_get_max_threads is the value of the first element of the nthreads-var ICV of the current task.

This implicitly says that an OpenMP thread must call it because there must be a current task (everything in OpenMP is a task). OpenMP bootstraps the by making an initial thread when the program starts.
So in that std::thread example, the thread calling the API routine doesn't have all the OpenMP state.
Calling the lambda works in your example above because it's the initial thread that's calling the API routine.
What thread in AdaptiveCpp is trying to call the OpenMP API functions?

Ah yes, it's the same behaviour as Will sketched out using a worker thread. I'll ask for some advice on this from our local friendly neighbourhood OpenMP runtime expert... Standby!

@tomdeakin Don't suppose there was any news on this?


fix: FieldConnector setValue race conditions

The FieldConnector currently only works correctly when the onValueChanged is triggered immediately after calling setValue. If another callback triggers a rerender (e.g. onSchemaErrorsChanged) the child component is rerendered with an outdated value. This can be potentially caused by setValue triggering a longer async function (e.g. a network connection). This gives plenty of time for another callback to fire. Also, throttling the setValue may also cause race conditions here.
This PR resolves this problem by immediately storing the value of setValue in the FieldConnector's state. That way all future rerenders triggered by any callback will always pass the correct value to the component's children. The setValue call of the FieldAPI stays throttled to not break any existing behaviour.
This PR includes a test that demonstrates the issue and fails on master.

The FieldConnector currently only works correctly when the onValueChanged is triggered immediately after calling setValue.

Wasn't this exactly how onValueChanged used to work? It would trigger even before the network call to persist the value, so you should never have this problem:

This can be potentially caused by setValue triggering a longer async function (e.g. a network connection).

I am a bit worried that if we changed the sdk behavior and callback orders change, customers' custom field editors might also start behaving buggy for no good reason. If onValueChanged really used to fire immediately after setValue then perhaps it'd be best to continue with this behavior. It'd be best if the callback order is clearly defined and predictable exactly to avoid such regressions and race conditions whenever possible.

Thank you for the elaborate summary @andipaetzold 🙇
one question:

onSchemaErrorsChanged (value A) is triggered

Since setValue (value B) was already triggered, would it make sense for the sdk to hold this callback back? Not sure what the exact consequences for the UI would be, perhaps it doesn't make any sense.

@DanweDE
If we held the callback back we might not receive intermediate errors that could be still valid (e.g. min/max length of a textfield). But it would also make sense to not emit these callbacks as they are based on outdated values.
Reality is that the callbacks are pretty certainly already queued up and are only delivered very slow. Therefore they would need to be filtered out by the App SDK. Unfortunately, there is no reference between the errors and the value-change which triggered them, so this is almost impossible.


Update to use Bootlint 0.11.0

Closes #48.

This is great since I'm on vacation and didn't bring my laptop. lol
I might need to give you permission to tag a release and use the twbs account to publish to npm.
cc @cvrebert

@zacechola While we're at it, could you please add me to the Collaborators list for this GitHub repo?

Sure thing.

Also relatedly, what do you think about moving this repo under the twbs org (as twbs/grunt-bootlint)?
I think the npm download rank/count has proven that this project is viable in terms of user/community interest, and I hope/believe the rest of the Twbs team agrees that you've passed the "is a nice person to work with" test such that we'd be happy to fully officially associate the Twbs brand with you and your project.

Yeah I think that it actually makes more sense as part of the twbs family.

Great! Just sent you an invitation to the org.

Looks like I got that email and then it was followed by a cancellation email.

Weird. Just sent another one.

Got it.

Okay, if I read the GitHub docs correctly, you should now be able to transfer this repo to twbs via its Settings page.

Ok. Done. I'm going to DisneyWorld. :rocket:

Have wonderful time! :tada:


appeal for reopening issue #740

Considering that there are so many bugs implementation in Facebook flow, I suggest to reopen #740 to support block flow suppressing to either provide proposed syntax or open up flow action state machine  so that we can start , pause , continue flow checking actions manually.

Re-opened


Polygon marker opacity

Hello, I'm trying to display polygon marker with opacity but it doesn't work. Style I use:
{ style: 'polygons', color: [1.0, 1.0, 1.0, 0.5], order: 2000, collide: false, blend: overlay }

I noticed it works for point markers and polygons within datalayers.

Hi @horvayev ,
The blending mode is a parameter of the style, when setting a marker you set the strings that corresponds to a draw rule. I would refer the documentation on how to setup a style for a specific blending mode here.
Also, I notice that collide is being used here for a polygon, this parameter only affects points and text styles.
Something that would work for you, add a style with this blend mode in the stylesheet, that inherits from the base style polygons:
styles:
    overlay_polygons:
        base: polygons
        blend: overlay

In you codebase when setting a marker styling:
map->markerSetStyling(polygonMarker, "{ style: 'overlay_polygons', color: [1.0, 1.0, 1.0, 0.5], order: 500 }");

Let us know how that goes!

It was it. Thank you @karimnaaji .


[feature] Implement "I don't have a wallet" UI flows

What problem does this new feature solve?

Provides guidance to users interacting with web3modal who do not already have a wallet of their own.

Describe the solution you'd like

Figma: https://www.figma.com/file/jjt28S7DTuKxVAYLdb8vmn/Web3Modal?node-id=3185-47113&t=BZbstyiRC1TrqUS1-0
Add "I don't have a wallet" button to the bottom of the modal
Implement new privacy policy / terms popup

Currently out of scope

social / popular wallet view shown in the Figma

cc @0xAsimetriq for context

Closing this as context around "I don't have a wallet" is changing completely in v3 / Email sign in work


Strip whitespaces when looking up LocationPolygons

Currently, 'london' searches a polygon and 'london ' searches a point.
Compare "90 jobs found near 'London '" and "134 jobs found in 'London'". The former fails to use a polygon because of the trailing whitespace.
This has also been messing up searches in Birmingham (127 counts of searching with a whitespace), Manchester, Liverpool, Sheffield, etc.
In our sample, there were 168 searches for "london " and 6376 for "london"

Reimplemented in https://github.com/DFE-Digital/teaching-vacancies/pull/2433


[CLI] Custom path to tsconfig

Given
nx workspace with Angular, Elysia and tsconfig.base.json in the root of the project.
Issue
Can't generate schema.prisma because of missing tsconfig.json.
Solutions:

Add an option like --tsConfig or --ts-config to specify the path to a custom TypeScript config.
bunx @better-auth/cli generate --config libs/core/api/src/lib/auth.ts --ts-config tsconfig.base.json

Alternatively, allow a better-auth.config.ts file in the project root to manage configurations.
// better-auth.config.ts

import { defineConfig } from '@better-auth/cli';

export default defineConfig({
  config: 'libs/core/api/src/lib/auth.ts', // or even better `@my-company/core/api`. Assuming auth is exported.
  tsConfig: 'tsconfig.base.json',
});

bunx @better-auth/cli generate would use the config defined above.

Upd. actually it does generate when the auth.ts is provided. Nevertheless it would be great to setup everything related to CLI in the auth-better.config.ts (or similar) file.

I think a config file for betterAuth would be great for real.

Upd. actually it does generate when the auth.ts is provided. Nevertheless it would be great to setup everything related to CLI in the auth-better.config.ts (or similar) file.


No module named 'datasets'

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):N/A
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):Linux Ubuntu 16.04
TensorFlow installed from (source or binary):binary by pip
TensorFlow version (use command below):1.2.0
Python version:3.6
Bazel version (if compiling from source):1.15.0
GCC/Compiler version (if compiling from source):5.5.0
CUDA/cuDNN version:8.0
GPU model and memory:5.5.10
Exact command to reproduce:N/A

Describe the problem
I want to run the command 'python mobilenet.py', but this error occurs to me. I followed some solutions, such as link1 and link2. However they don't work for me. I wonder if there is a way to solve it and how. Thank you!

Nagging Assignee @tatatodd: It has been 15 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 30 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 62 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @tatatodd: It has been 76 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Sorry to know that those solutions didn't work for you. You need to configure the PYTHONPATH correctly.
This question is better asked on StackOverflow since it is not a bug or feature request. There is also a larger community that reads questions there.
If you think we've misinterpreted a bug, please comment again with a clear explanation, as well as all of the information requested in the issue template. Thanks!


Add Makefile.am for automake projects that want to include a library.

Thanks for this handy function. I added an automake file so it can more easily be used in larger projects with autoconf/automake.

Good idea!


Refactor PhoneNumberValidatorTest

PR Checklist

[x] Read the contribution guidelines
[x] Added a brief description of these changes to the top of the changelog
[x] Changes in code meet test criteria (running mvn test returns exit code 0, without errors)

PR Type

[x] Test-related

Summary
Resolve code smell tag by sonar cloud and use @ParameterizedTest

Hi @mepox @bglamadrid,
Please check if its good


RI Savings data

[Can't the Reservation Savings data be obtained from Cost analysis "Reservations View" as well? If yes, can that be included as additional option in this page because the process mentioned with csv download from portal and processing with xlsx in this page is too manual and laborious and prone to mistakes and especially with huge data and large files. ]

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 2c449e11-8b9c-48a6-b881-cc5319fb0c9d
Version Independent ID: 94beecc3-806a-dbcd-9f24-d2b7c2a70373
Content: Calculate EA reservations cost savings - Microsoft Cost Management
Content Source: articles/cost-management-billing/reservations/calculate-ea-reservations-savings.md
Service: cost-management-billing
Sub-service: reservations
GitHub Login: @bandersmsft
Microsoft Alias: banders

@aurum1729 Hi there. If we understand correctly, the you’re looking to for reservations cost savings to appear in the “Reservations view” in  Cost analysis. Currently, Cost analysis can’t calculate cost savings because the platform doesn’t have the required datasets. The Cost Management team is actively exploring how they can build a cost savings report. However, we can’t commit to when that might get completed.
#please-close


Future updates: Rather than downloading all over again, let it be a click of a button directly from wallet

Good evening, good progress on the latest update especially the @username addition, I was wondering if it would be possible to make future update a click of the bottom directly from the wallet rather than downloading the file all over again. This would work great. Just a suggestion

I think most apps download the installer all over again because it is more difficult to create/update/delete only those files that changed between different versions. GIT or NPM is good for installing/updating on linux, but it can't do some things that Windows installers do. Some apps make the updating more streamlined by including the downloader in the app, so users don't have to go to some website, some even include the installer/updater also in the app, so it makes it look like app updates itself.
All these different updating methods are very platform specific and add complexity, so it makes more sense to focus on other features instead of developing built-in installer/updated.
I think that's why Byteball is using standard installer for installing/updating and that's why you need to manually do it every time.


Add versioning on dependencies

Hi,
I added this small dependencies on the podspec to make sure than no potential major breaking changes will actually be installed, and then break the compilation process.
Thanks for your library, very useful :)
Kevin

Great! Thank you, Kevin!


sg diff and lock filter and api

something odd going on in travis.. it looks like its reaching out on the network if its getting a session token error. running locally not reproducible even with network off.

okay, isolated to the locked api tests which are patching out request methods, the coverage / multi-process / patching seems problematic. going to


Filename with no extension

In this photo the code is trying to look for a file with no extension, it does this at every instance. you have to find and replace almost every instance of "CustomAppsList" with "CustomAppsList.txt"

It now works.

The AppsList.txt is meant to be edited by end users, the CustomAppsFile however is not intended to be used that way. That's the reason I opted to leave the file without an extension.
The file is generated automatically by the script whenever you use the app selection UI to remove apps or by running the script with the -RunAppConfigurator parameter. Allowing the script to remember and re-apply the last used settings for app removal.

The AppsList.txt is meant to be edited by end users, the CustomAppsFile however is not intended to be used that way. That's the reason I opted to leave the file without an extension. This doesn't impact functionality, it just acts as a way to show the file is not intended to be edited.
The file is generated automatically by the script whenever you use the app selection UI to remove apps or by running the script with the -RunAppConfigurator parameter. Allowing the script to remember and re-apply the last used settings for app removal.

oh okay, would it not make sense to request apps list as the custom apps file list then if it's not meant to be edited?

The AppsList.txt is meant to be edited by end users, the CustomAppsFile however is not intended to be used that way. That's the reason I opted to leave the file without an extension. This doesn't impact functionality, it just acts as a way to show the file is not intended to be edited.
The file is generated automatically by the script whenever you use the app selection UI to remove apps or by running the script with the -RunAppConfigurator parameter. Allowing the script to remember and re-apply the last used settings for app removal.

oh okay, would it not make sense to request apps list as the custom apps file list then if it's not meant to be edited?

Changing the Appslist.txt already changes the default selection of apps the script removes, if you edit that simply select the default option or run the script with -RemoveApps parameter. The CustomAppsList is intended as a way to remember the custom app selection you make using the script UI. So they serve different purposes.


Error running install.sh script: "This script uses docker, and it isn't running"

Using Linux Mint 24.04
Trying to run the script using the command provided, but gives below error:
-----------------------------------------------------------------
Welcome to the installation script for Unifi Network Application.
-----------------------------------------------------------------

This will deploy both the Unifi Network Application and MongoDB container, along with a bridge network to connect the two.

If you previously deployed containers unifi-db and unifi-network-application, they will be reinstalled.

Press enter to continue:
Enter pressed. Let's GO!

This script uses docker, and it isn't running - please start docker and try again!

But the docker is installed:

Try to add "sudo" to each docker command in the script, you've not been the only one to experience this.
I think is just a matter of different system setup, on mine I can use docker without sudo, apparently on yours you can't. In the next days I'll try to look more into it.
Thanks for your feedback! Keep me posted.

@sjpatel21 news?

I had this issue also, (raspberry pi 3b+) but I just use sudo su before running the install script and it worked.


Gradle: Task dependency issues

Currently the gradle build is reporting errors when building FVTs similar to
  - Gradle detected a problem with the following location: '/Users/jonesn/IdeaProjects/egeria/master/open-metadata-test/open-metadata-fvt/access-services-fvt/subject-area-fvt/build/classes/groovy/test'. Reason: Task ':open-metadata-test:open-metadata-fvt:access-services-fvt:subject-area-fvt:startServer' uses this output of task ':open-metadata-test:open-metadata-fvt:access-services-fvt:subject-area-fvt:compileTestGroovy' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.
  - Gradle detected a problem with the following location: '/Users/jonesn/IdeaProjects/egeria/master/open-metadata-test/open-metadata-fvt/access-services-fvt/subject-area-fvt/build/generated/sources/annotationProcessor/groovy/test'. Reason: Task ':open-metadata-test:open-metadata-fvt:access-services-fvt:subject-area-fvt:startServer' uses this output of task ':open-metadata-test:open-metadata-fvt:access-services-fvt:subject-area-fvt:compileTestGroovy' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.
  - Gradle detected a problem with the following location: '/Users/jonesn/IdeaProjects/egeria/master/open-metadata-test/open-metadata-fvt/access-services-fvt/subject-area-fvt/build/tmp/compileTestGroovy/previous-compilation-data.bin'. Reason: Task ':open-metadata-test:open-metadata-fvt:access-services-fvt:subject-area-fvt:startServer' uses this output of task ':open-metadata-test:open-metadata-fvt:access-services-fvt:subject-area-fvt:compileTestGroovy' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.

This occurs for all FVTs, though they do run, and the order is currently ok

Elaborating in more detail. When building ./gradlew build from top level of egeria, multiple warnings like this are shown:
  - Gradle detected a problem with the following location: '/Users/jonesn/IdeaProjects/egeria/master/open-metadata-test/open-metadata-fvt/access-services-fvt/asset-manager-fvt/build'.
  Reason: Task ':open-metadata-test:open-metadata-fvt:access-services-fvt:asset-manager-fvt:startServer' uses this output of task ':open-metadata-test:open-metadata-fvt:access-services-fvt:asset-manager-fvt:compileGroovy'
  without declaring an explicit or implicit dependency.
  This can lead to incorrect results being produced, depending on what order the tasks are executed.
  Please refer to https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.

(Note: I have added new lines for readability).
One example of this task can be seen at https://github.com/odpi/egeria/blob/master/open-metadata-test/open-metadata-fvt/access-services-fvt/asset-manager-fvt/build.gradle where the definition is:
// Initially we launch as an app -- though there may be a better way of running this in the existing jvm
task startServer(dependsOn: ['cleanData',':open-metadata-distribution:open-metadata-assemblies:unzip'], type: com.github.psxpaul.task.ExecFork) {
    // Start some external service
    executable = System.properties.'java.home' + '/bin/java'
    workingDir = "${buildDir}"
    args = [ "-Dserver.port=10453",
             "-Dloader.path=${distdir}/server/lib",
             "-Dspringdoc.api-docs.enabled=false",
             "-Djavax.net.ssl.trustStore=${distdir}/truststore.p12",
             "-Dserver.ssl.trust-store=${distdir}/truststore.p12",
             "-jar",
             "${distdir}/server/server-chassis-spring-${project.version}.jar" ]
    // Setting the output directories to be the same for ALL FVTs acts as a synchronization mechanism
    // - alternatively we need to ensure the server port is unique per test
    standardOutput = layout.buildDirectory.file("chassis.log")
    errorOutput = layout.buildDirectory.file("chassis-error.log")
    //stopAfter = verify
    waitForPort = 10453
    timeout = 180
    //waitForOutput = 'has started'
}

Working through this step by step:

We do explicitly depend on 'cleanData'. This is defined in the same file to simple delete the files in ${buildDir}/data' as when egeria is launched it will write there
similarly for the assemblies. This is created in another module as part of the build - and the unzip task specifically unpacks an archive including our executable jar, certificates etc into a standard distribution directory (which we call distDir here)
The task itself builds up some arguments to launch a process. This uses the installed java version. It does have the current $buildDir as it's working directory, but it's not using input from here -- these are just output files
The arguments refer to more files, like .p12, but these are all put in place by the unzip task we depend on
The standard output/error again are output files

As such I can't see where the concern of a hidden dependency comes on. Later tasks - like the configuration of the server - do depend on test code, and so accordingly have more dependencies, but this one is purely launching an executable where we have already explicitly declared a dependency on the task that creates it.
Could it be a bug in 7.4.2 ?
Will report on gradle forums.


adjust ports for yurt-manager component to 10270~10279

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind bug
/kind documentation
/kind enhancement
/kind good-first-issue
/kind feature
/kind question
/kind design
/sig ai
/sig iot
/sig network
/sig storage

/kind enhancement
What this PR does / why we need it:

native K8s components have occupied ports: 10250~10259
OpenYurt YurtHub component has occupied ports: 10260~10269
OpenYurt Yurt-Manager component has occupied ports: 10270~10279

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Does this PR introduce a user-facing change?

other Note

/lgtm


TypeError: Cannot destructure property 'header' of 'message' as it is undefined

I got this error in Next.js - Transfer SOL example.
TypeError: Cannot destructure property 'header' of 'message' as it is undefined.     at TransactionMessage.decompile (/var/task/node_modules/@solana/actions/node_modules/@solana/web3.js/lib/index.cjs.js:1985:7)     at prepareVersionedTransaction (file:///var/task/node_modules/@solana/actions/lib/esm/createPostResponse.js:40:38)     at createPostResponse (file:///var/task/node_modules/@solana/actions/lib/esm/createPostResponse.js:33:16)     at handlePost (/var/task/frontend/.next/server/pages/api/claimsri.js:166:98)     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)     at async handler (/var/task/frontend/.next/server/pages/api/claimsri.js:55:13)     at async Object.apiResolver (/var/task/node_modules/next/dist/server/api-utils/node.js:366:9)     at async NextNodeServer.runApi (/var/task/node_modules/next/dist/server/next-server.js:481:9)     at async Object.fn (/var/task/node_modules/next/dist/server/next-server.js:735:37)     at async Router.execute (/var/task/node_modules/next/dist/server/router.js:247:36)     at async NextNodeServer.run (/var/task/node_modules/next/dist/server/base-server.js:347:29)     at async NextNodeServer.handleRequest (/var/task/node_modules/next/dist/server/base-server.js:285:20)     at async Server.<anonymous> (/var/task/frontend/___next_launcher.cjs:26:5)     at async Server.<anonymous> (/opt/rust/nodejs.js:8:4243)

where do you get this error?
can you share code snippets or a repo of what you are experiencing?

This should now be resolved in the new version of the sdk. If you are still experiencing this issue, please reopen this issue or create a new one.


Add UMD file

This library is great! I'd like to use it in a few different projects, but my build system (and lots of others) is good at importing JS files and not so good at importing plain old JSON files. This PR adds a new grunt task to automatically wrap a validated, complete data.json file in a UMD structure so it's easily imported into a Node or browser environment. Simply running grunt umdify before every release and checking in the updated data.js file ensures everyone gets to use the project everywhere!

Nice addition, @jayeb!

Happy to help 👍
Could you cut a new version with this addition sometime in the next couple of days?

Done! Just published 1.3.6. :)


If we clear the database you get a redirect error

Not sure if we should fix this, but can image that a record in the future will not be found and it will result in a non working website.

I think this also occurs when the DBs of new instances are wiped right before launch.

Yeah, maybe we should add a redirect count or something and if that hits more than 2 or something we should clear the cookie.

Just hit this problem as well. Do you know where the loop happens?

Could also be solved by not redirecting and instead showing a "Invalid pass code" message.

Yes, better to show invalid passcode


Duplicate activity processing when fetching from Waze

This is due to drives being contained in multiple takeouts. It doesn't hurt and it works as expected, but can be optimized to gain some speed.

Waze takeout import is no longer included in regular import (only via -t switch), so this won't be implemented any time soon.


fetchMemberListFromServer function not returning all the joined member IDs

Description
This issue only occurs on Android, i am not getting all the member IDs of the Group when i fetch it using an Android device. i can see the ids under the Group on Agora console
Version
1.1.1
Output of npx react-native info
info Fetching system and libraries information...
System:
OS: macOS 12.6
CPU: (8) x64 Apple M1
Memory: 39.45 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 14.17.4 - /usr/local/bin/node
Yarn: Not Found
npm: 8.1.0 - /usr/local/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.11.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
Android SDK:
Android NDK: 21.4.7075529
IDEs:
Android Studio: 2020.3 AI-203.7717.56.2031.7935034
Xcode: 14.2/14C18 - /usr/bin/xcodebuild
Languages:
Java: 11.0.2 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.67.5 => 0.67.5
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Steps to reproduce

Create a chat group and join from several devices (iOS & Android)
try to to fetch members list using function fetchMemberListFromServer on Android
check if all the joined member ids are returning on Android Device

Snack, code example, screenshot, or link to a repository
export const fetchGroupMembers = async (groupId, onSuccess, onError) => {
  try {
    chatClient.groupManager.fetchMemberListFromServer(groupId, 200, null)
      .then(members => {
        onSuccess(members);
      })
      .catch(reason => {
        onError(reason);
      });
  } catch (error) {
    onError(error);
  }
};

Platform

[ ] All
[X] Android
[ ] iOS

SimulatorOrDevice

[X] All
[X] Simulator
[X] Device

iOSVersion

[ ] All
[ ] iOS Earlier than 8
[ ] iOS 8
[ ] iOS 9
[ ] iOS 10
[ ] iOS 11
[ ] iOS 12
[ ] iOS 13
[ ] iOS 14
[ ] iOS 15
[ ] iOS 16 or above
[ ] Android Earlier than API Level 23
[ ] Android API Level 23
[ ] Android API Level 24
[ ] Android API Level 25
[ ] Android API Level 26
[ ] Android API Level 27
[ ] Android API Level 28
[ ] Android API Level 29
[ ] Android API Level 30
[ ] Android API Level 31
[ ] Android API Level 32
[X] Android API Level 33 or above

"not returning all the joined member IDs" meant not include group ower/creater?
Currently, the API fetchMemberListFromServer   return ower and members(not include ower) are separated.

yes, members IDs not owner ID, owner id we can get it from owner property

@lasitha-ideabits , this works on iOS?

yes i can get all member ID on iOS device

@CarlsonYuan what's the status of this, Are you guys working on it?

758c1acbefe32da5c3824e24a8f5c5d9eaf6e240 fix this bug.
try 1.1.2-beta.0 version.

Thanks, send me beta version link

https://www.npmjs.com/package/react-native-chat-sdk

Sorry, I misunderstood the question. However, I did verify this problem today and found no problems with the android platform. Is it possible to use our testing tool to verify your question?
https://github.com/easemob/react-native-chat-sdk/blob/758c1acbefe32da5c3824e24a8f5c5d9eaf6e240/example/src/demo2/Test/QuickTestGroupData.tsx
fetchMemberListFromServer


No update of misp feed

Hello,
The misp feed seems to be empty since 3rd may 2024.
https://osint.digitalside.it/Threat-Intel/

The feed is now fully updated. Thank you !

Sorry, outage recovered


Parsing zero value

Required.js returns error when a value is numerical zero. The problem is probably because of !!value, which returns false, when value is 0

add tests for value zero

https://github.com/relekang/validator/blob/master/src/rules/required.js#L11

Thanks, should be fixed in v0.8.0 ✌


False positive with 'alert' on PHP files

Steps to reproduce

Add the following line to a PHP class

$this->logger->alert('bla');

Run testing suite

Expected result
Testing suite passses
Actual result
It fails with a 'git_blacklist' error
Additional info
There's a generic 'alert(' blacklist that should only apply to JS files I think: https://github.com/YouweGit/testing-suite/blob/master/config/magento2/grumphp.yml#L11

@viniciusfabri
Maybe we could add some regex to allow for ->alert( while disallowing alert(
Played a little bit around with this, but could not get it to work properly
I'm no regex hero, but this should be correct I think (?<![->]{2})alert( or (?<![->]{2})alert[\x28] as it seems grumphp has some issues with regxexes that needs to be defined /escaped in yaml
See also https://github.com/phpro/grumphp/blob/master/doc/tasks/git_blacklist.md
Another Idea I came up with would be to split the tasks / lists to be used per language (php/js/phtml)
Have not tested if that is a feasible option yet

New false positive:


Create VCameraTrigger.gd

Area script which enables VCamera when player etc. enters it.

Superseded by #21.


[Direct3D12] [Suggested fix] Potentially invalid use of the API in feature support check.

Describe the bug
I believe the feature check code for Direct3D12 is mis-using the API.
See the code around https://github.com/bkaradzic/bgfx/blob/0b73e8c7e22a2876a8979a4dd9b77d0686058090/src/renderer_d3d12.cpp#L1125
Starting at Options12 up to Options15, every feature check is using the D3D12_FEATURE_D3D12_OPTIONS12 enum to get the feature results. While I am not very familiar with D3D12 and could not reproduce an actual bug based on this, just looking at the API this seems wrong.
E.g. code that I believe is incorrect:
			for (D3D12_FEATURE_DATA_D3D12_OPTIONS15 options15; SUCCEEDED(m_device->CheckFeatureSupport(D3D12_FEATURE_D3D12_OPTIONS12, &options15, sizeof(options15)));)
I think the first argument of CheckFeatureSupport should be D3D12_FEATURE_DATA_D3D12_OPTIONS15 in the snippet above. And the same for the previous few checks.
If you agree this is wrong, I can send a PR to fix these few lines, however I'm not sure how to actually test such a change.

If you agree this is wrong, I can send a PR to fix these few lines, however I'm not sure how to actually test such a change.

Yes. Please send PR.


Failed Tools, can you help me?

Failed Tools, can you help me?

Bro please read readme.md or you better leave that field blank

same problem even i tried by lefting it blank , I first tried with true then with false not working in situations

same problem even i tried by lefting it blank , I first tried with true then with false not working in situations

leave all blank except api id and api hash


Orderer deploy guide edits for participation API

Change-Id: If775789bd29f767aab3647a49ee019c5b7c2a6b6
Signed-off-by: joe-alewine<EMAIL_ADDRESS>Type of change

Documentation update

Description
This doc edits the relevant sections in the orderer deployment guide to make the channel participation API process the default (and to link, where necessary, to the 2.2 version of the docs).

@Mergifyio backport release-2.3


add test case for PortUtils.findPort

Make sure that:

[x] You have read the contribution guidelines.
[x] You submit test cases (unit or integration tests) that back your changes.
[x] Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true.

blone

@VampireAchao Did you forget to submit the code?

I'm sooooooo sorry!Now the code is here.

Codecov Report

Merging #4604 (fec8a22) into master (1e678f4) will decrease coverage by 1.12%.
 Consider uploading reports for the commit 2b39d40 to get more accurate results

@@             Coverage Diff              @@
##             master    #4604      +/-   ##
============================================
- Coverage     68.72%   67.61%   -1.12%
+ Complexity     7818     7816       -2
============================================
  Files          1041     1063      +22
  Lines         30047    30542     +495
  Branches       2735     2781      +46
============================================
+ Hits          20650    20651       +1
- Misses         7769     8268     +499
+ Partials       1628     1623       -5

see 34 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Issue in import OpenAPI link in APIM.

Repro steps:

1.create New Api in API management extention for visual source code
2. importing OPENAPI as swagger.json.
Action: azureApiManagement.importOpenApiByLink
Error type: Error
Error Message: Cannot read property 'length' of undefined
Version: 0.1.5
OS: win32
Product: Visual Studio Code
Product Version: 1.49.0
Language: en

Call Stack
extension.bundle.js:262:3546870extension.bundle.js:262:3546870
a extension.bundle.js:262:3545381

Seems like an issue with the swagger.json. @pradnya984shedge : you're willing to share this file?

+1 @pradnya984shedge can you share the file?

Im getting the same issue and it doesn't happen when importing the same open api spec in the Azure Portal

@s-leonard would you be able to share the open api spec?

I found the reason it breaks. If the spec is missing the servers section it breaks. It doesn't break when you import from the portal though. I'm not actually sure why the servers section is missing on my apps service deployments. I need to check that, but the portal import handles this.
"servers": [       {         "url": "https://apilocation.com"       }     ],


[core-client-rest] New option for adding policies

Packages impacted by this PR
@azure/core-client-rest and dependents
Issues associated with this PR
#16876
Describe the problem that is addressed by this PR
https://github.com/Azure/azure-sdk-for-js/pull/19920 updated core-client, this PR applies the same change for the core-client-rest
For test purposes, to be able to add policies to any client's HTTP pipeline.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
https://github.com/Azure/azure-sdk-for-js/pull/19920  talks more
Are there test cases added in this PR? (If not, why?)
yes

@bterlson any thoughts? Are we thinking to stop exposing the pipeline in Rest Clients? Hopefully we can keep it

I'm also curious what @bterlson thinks here. For my part, I don't necessarily think we need to remove pipeline from REST clients, since they are targeted at devs comfortable with working at a lower level.

I'm fine keeping it exposed if y'all are!


utils_test failure

When running nosetests as outlined in Issue #5, I am getting the following error:
======================================================================
ERROR: Tests conversion of values into human readable format.
Traceback (most recent call last):
File "/home/tome/treadmill/tests/utils_test.py", line 233, in test_humanreadable
self.assertEquals('2,310', utils.cpu_to_readable(2310))
File "/home/tome/treadmill/lib/python/treadmill/utils.py", line 348, in cpu_to_readable
locale.setlocale(locale.LC_ALL, 'en_US')
File "/usr/lib/python2.7/locale.py", line 579, in setlocale
return _setlocale(category, locale)
Error: unsupported locale setting

Updated Issue #5 with fix - just need to manually add the en_US locale.  By default, only en_US-utf8 is installed.


remove pub from inner connection

Inner connection is being leaked, remove the pub

It was intentional, we have it on the deref target


Change "Master" Branch to "Main" Branch

Is your feature request related to a problem? Please explain.
A lot of repos are adopting the "main" branch syntax instead of "master" branch syntax. I have been wanting to do this for a while, but just wanted to actually open an issue on Javis so I don't forget.
Describe the solution you'd like
@fonsp (thanks!) described a very helpful guide here: https://discourse.julialang.org/t/renaming-master-to-main-julia-specific-experience/57723
Describe alternatives you've considered
N/A
Additional context
Succinctly summarized by @mbauman here: https://discourse.julialang.org/t/renaming-master-to-main-julia-specific-experience/57723/4

@TheCedarPrince Hi! Can I take this up?

I actually think either @TheCedarPrince or I have to do this as others don't have the needed administrative rights.

@Wikunia Didn't realize that. Perhaps, removing the "good first issue" would be nice.

Hey @paniash - did realize this was something only admins could perform. Thanks!
Also, if you are still interested in contributing to a "good first issue" - one that might be fun involving physics is doing something like this issue: https://github.com/Wikunia/Javis.jl/issues/360 - best! ~ tcp

@TheCedarPrince Thanks! I'll look into it. 😃

This is done!
Hooray!!!


Easy nodes provisioning through Kontena CLI

At the moment, Kontena installation is quite complex operation. Idea is to make it possible for users to provision Kontena Nodes on any cloud provider through cli with few simple commands.

Proposed solution:
Create cloud provider plugin architecture to support multiple cloud providers. Each plugin should implement necessary functions to:

Provision, configure and install necessary cloud resources for Kontena Server
Provision, configure and install necessary cloud resources for Kontena Node(s)
Terminate above mentioned resources

Add new abstraction layer cluster for a server and add following cli commands:

kontena cluster create [cluster_name] [provider_name] - Provision necessary resources and install Kontena Server on selected cloud provider
kontena cluster info [cluster_name] - Retrieve information about the Kontena Server.
kontena cluster login [cluster_name] - Associate cli with Kontena Server; store user credentials on local development environment
kontena cluster register [cluster_name] - Register User to Kontena Server (if supported)
kontena cluster forget [cluster_name] - Remove stored user credentials from local development environment
kontena cluster use [cluster_name] - Switch default kontena cli context to use selected server.

Finally, add nodes management to cli. E.g. kontena nodes add [provider_name] [grid_name] etc.

Why not reuse existing solutions like docker machine?

Good point, we have been checking docker machine as one possibility to provision machines. Right now kontena installation needs something more than plain server + docker provisioning. Basically we need to install deb packages that do some configuration to host machine... this is not supported by docker machine and that's why we are implementing our own lightweight tool.

I'm not sure that I understand why you depend on ubuntu. In comment https://github.com/kontena/kontena/issues/95#issuecomment-125208404, I showed how I started your existing Dockerfiles using docker-compose up. That means both the api server and the agent run in a container. Thus, from my point of view only a plain server + docker provisioning is required.
Am I missing something?

We don't directly depend on ubuntu but atm we provide packages only for ubuntu. Kontena includes something more than just plain containers, mainly etcd2 and weave. Etcd2 is included in CoreOS and Weave can be installed (or replaced with Flannel) but then agents will miss automatic node discovery and other cool stuff that's baked into ubuntu packages. If you want to port those features to CoreOS systemd (cloud-config) files, here is the ubuntu package magic:
https://github.com/kontena/kontena/tree/master/agent/packaging/ubuntu
https://github.com/kontena/kontena/tree/master/server/packaging/ubuntu

We have now provisioners for vagrant and digitalocean. Both are using coreos-stable. Should we close this?

yes. i think this issue can be closed. the current design fulfills the original idea. if we want more provisioning engines, we'll create issue for each one of them in the future.


Audio missing

Please describe your issue:
I can not get the audio to work e.i. application(s) relying on audio no longer function (freeze),
the audio was working,  then every application relying on it stopped functioning,
so I am unsure what caused this to happen.
I've tried power-washing and re-installing different targets.
Installing target audio...
Empty or invalid cras-version ().
Fetching CRAS (branch )...
--2019-10-04 05:28:20--  https://chromium.googlesource.com/chromiumos/third_party/adhd/+archive/.tar.gz
Resolving chromium.googlesource.com (chromium.googlesource.com)... <IP_ADDRESS>, 2607:f8b0:400d:c0c::52
Connecting to chromium.googlesource.com (chromium.googlesource.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-10-04 05:28:20 ERROR 404: Not Found.

Error fetching CRAS
Branch not found, falling back on master (audio might not work)...
--2019-10-04 05:28:20--  https://chromium.googlesource.com/chromiumos/third_party/adhd/+archive/master.tar.gz
Resolving chromium.googlesource.com (chromium.googlesource.com)... <IP_ADDRESS>, 2607:f8b0:400d:c0c::52
Connecting to chromium.googlesource.com (chromium.googlesource.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: '/tmp/crouton-cras.OD1csy/adhd.tar.gz'

/tmp/crouton-cras.OD1csy/adhd.tar.gz          [  <=>                                                                                ] 794.41K  2.90MB/s    in 0.3s

2019-10-04 05:28:20 (2.90 MB/s) - '/tmp/crouton-cras.OD1csy/adhd.tar.gz' saved [813471]

When launching :
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.chromium.LibCrosService was not provided by any .service files
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
Error executing command as another user: Not authorized

when trying to launch alsamixergui :
croutonwebsocket error: EError: not connected.
If known, describe the steps to reproduce the issue:
unknown.
@dhammika , @SirFireball3521, @dnschneid, @drinkcat

worked through it and got it working.

Can you tell us what you did to fix it?

Yes how did you fix the issue?


outputs LA log for deleted files with clearer exception for LDS

Codecov Report
Base: 81.79% // Head: 81.90% // Increases project coverage by +0.11% :tada:

Coverage data is based on head (4a83ed2) compared to base (2791334).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #123      +/-   ##
==========================================
+ Coverage   81.79%   81.90%   +0.11%
==========================================
  Files          54       54
  Lines        2461     2476      +15
==========================================
+ Hits         2013     2028      +15
  Misses        448      448

Impacted Files
Coverage Δ

liiatools/datasets/s903/lds_ssda903_clean/prep.py
63.41% <100.00%> (+8.86%)
:arrow_up:

tests/s903/test_prep.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Removing Project Cortex references

and replacing with Viva Topics.
Please use this template to ensure easier processing of your pull request
Category

[x] Content fix
[ ] New article
[ ] Example checked item (delete this line)

For the above list, an empty checkbox is [ ] as in [SPACE]. A checked checkbox is [x] with no space between the brackets. Use the PREVIEW tab at the top right to preview the rendering before submitting your issue.
(DELETE THIS PARAGRAPH AFTER READING)

Related issues

fixes #issuenumber
partially #issuenumber
mentioned in #issuenumber

If this fixes (should close) or references an issue, please add the issue number here. When you type the hashtag symbol (#), a list of potential issues will pop up from which you can choose. This helps those maintaining the issue list as it will (1) link the PR to the issue & (2) automatically close the issue when this PR is merged in.
(DELETE THIS PARAGRAPH AFTER READING)

Contents of the Pull Request

Please describe the changes in this PR. Try to give enough details so the person reviewing it to merge it can make a good decision about your content.
(DELETE THIS PARAGRAPH AFTER READING)

Guidance

Please update this PR information accordingly. We'll use this as part of our release notes in monthly communications.
Please target your PR to master branch. Released documents are in live branch.
(DELETE THIS PARAGRAPH AFTER READING)

Docs Build status updates of commit 15673f0:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Community/microsoft365-maturity-model--management-of-content.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Can't parse replay.game.events for most games with 'Lost Vikings' and 'Longboat Raid' talent selected

This popped up within the past few patches
Something has changed in the replay.game.events event structure, and it has to do with Lost Vikings and Longboat Raid.
It likely has to do with unit selection or movement.  I spent some time trying to find it, but wasn't too easy.  I'll look into it more in the future
For now, this means we can't parse talent selections for most replays with a 'Longboat Raid' Viking player

Fixed! :) Apparently it was an error I've always had in the replay.game.events file, but only a few patches ago seems to be causing problems

I'll push changes later :)


Allow a range of ages in AgeShape

(as defined in core/subject)
AgeShape requires a single float value, but some datasets only specify a range of ages, e.g. "21-30 days", rather than providing the precise age of each subject.

Good point. schema:maxValue and schema:minValue can be used to represent range in quantitative value (which is the shape of age value).


Support for SOCKS5 proxy

How can I get flyway running locally to send the traffic for mydb on desthost:5432 via (say) localhost:7777 (the local end of an SSH tunnel)?
Which version and edition of Flyway are you using?
7.10.0
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
CLI
Which database are you using? (Type & version)
postgres 13.3
Which operating system are you using?
Windows, Ubuntu

This is something you will have to configure on your machine outside of Flyway to redirect the traffic
If you're expecting a solution in Flyway, could you describe how you're expecting it to work? We likely won't make any changes however unless this gets further interest, so closing for now


Plugin toolbar add height limit for select element

This is very userful for mobile devices, especially when the code block has many languages.

The purpose of this PR makes a lot of sense, but I do want to push such styling configuration into css variables. In this case, a --toolbar-select-max-height on the root level would drastically simplify the implementation and will keep it consistent with the rest of the visual configs (fonts, colors, etc). It's also easier to control with media queries.
Let me know what you think.

I think both CSS and JavaScript can be used, the only difference may be that JavaScript has less code.

I added a public CSS class that lets you safely target that element through a selector. This has multiple benefits, including media queries, additional properties, etc.


Fix MSCP under older VMS

(Track,Group,Cylinder) = (1,1,1) causes some kind of overflow in older VMS (e.g. 5.5-2) on startup.
Instead, we use real drive values as gathered from DUSTAT (and as simh declares them).
Tested on a VAX 4000 Model 200 and an RA90 image of VMS 5.5-2. VMS was installed to an emulated SCSI drive attached to a CMD CQD-220A. The .img was copied from that emulator to the QBone, and run using a similar script to vms73_rd54.sh but with type and image parameters for uda0 changed.
Signed off on by @jdersch via IRC.

Merged in 3bbf434 . Thanks @j-hoppe !


making host and client software robust to user inputs (avoid device lock)

also returns tracebacks for more informative debugging

https://github.com/sparks-baird/self-driving-lab-demo/discussions/100

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 6 (66.67%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.3%) to 56.712%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/self_driving_lab_demo/core.py
4
6
66.67%

Totals

Change from base Build<PHONE_NUMBER>:
0.3%

Covered Lines:
181

Relevant Lines:
293

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-2 of 6 (66.67%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.3%) to 56.712%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/self_driving_lab_demo/core.py
4
6
66.67%

Totals

Change from base Build<PHONE_NUMBER>:
0.3%

Covered Lines:
181

Relevant Lines:
293

💛  - Coveralls