Ztso psABI atomics specification

This PR defines an optimized atomics mapping ABI for Ztso targets. It is a strengthened version of Andrea Parri's proposed Ztso mappings ("Proposed Mapping") [1]. The proposal changes were discussed by Andrea Parri and Hans Boehm on the GCC mailing list [2] and are required in order to be compatible with the RVWMO A.7 ABI (mappings with note 3 in the psABI atomics table).
[1] https://github.com/preames/public-notes/blob/master/riscv-tso-mappings.rst
[2] https://inbox.sourceware.org/gcc-patches/ZFV8pNAstwrF2qBb@andrea/T/#t

Patches:
GCC<EMAIL_ADDRESS>LLVM: https://reviews.llvm.org/D155517

@hboehm @kito-cheng @jrtc27 @ilovepi @nick-knight @asb @enh-google @daniellustig @aparri
This is atomics related and may be interesting to you.

Is there a reason to present these as an alternate mapping scheme, rather than as additional mappings that are enabled by Ztso? If not, I would prefer the latter presentation, for several reasons:

It involves less redundancy.
It makes it clear that these are compatible with the RVWMO mappings, which I think is extremely desirable.
I think it sets up a better precedent for the future. If we add more hardware support, like RCpc operations, that should be reflected here by adding mappings conditioned on that extension, not by inventing completely new mappings.
(I'm not enough of an ELF expert to be sure about this.) It makes it clear that we can indicate whether these mappings may be present by indicating in the object file which hardware extensions we rely on. I'm blindly assuming that there is a mechanism for that? If this is true, then we don't need additional atomics ABI bits for this in object files.

To be clear, are you proposing a diff-only table like this?

C/C++ Construct
Ztso Mapping
Notes

atomic_load(memory_order_acquire)
l{b|h|w|d}

atomic_load(memory_order_seq_cst)
fence rw,rw; l{b|h|w|d}

atomic_store(memory_order_release)
s{b|h|w|d}

atomic_store(memory_order_seq_cst)
s{b|h|w|d}; fence rw, rw

atomic_thread_fence(memory_order_acquire)
nop

atomic_thread_fence(memory_order_release)
nop

atomic_thread_fence(memory_order_acq_rel)
nop

C/C++ Construct
Ztso AMO Mapping
Notes

atomic_<op>(memory_order_acquire)
amo<op>.{w|d}
4

atomic_<op>(memory_order_release)
amo<op>.{w|d}
4

atomic_<op>(memory_order_acq_rel)
amo<op>.{w|d}
4

atomic_<op>(memory_order_seq_cst)
amo<op>.{w|d}
4

C/C++ Construct
Ztso LR/SC Mapping
Notes

atomic_<op>(memory_order_acquire)
loop:lr.{w|d}; <op>; sc.{w|d}; bnez loop
4

atomic_<op>(memory_order_release)
loop:lr.{w|d}; <op>; sc.{w|d}; bnez loop
4

atomic_<op>(memory_order_acq_rel)
loop:lr.{w|d}; <op>; sc.{w|d}; bnez loop
4

I did separate mappings since it made it easier for me to verify my implementations were consistent with the table.
I'm not opposed to presenting a diff-only table, but I also think there is some value in discouraging a mix-and-match approach to atomic mappings. Clear discrete "blessed" mappings can help discourage bespoke collections that misinterpreted the notes and are broken in subtle ways.
Regarding point 4: I'm also not enough of an ELF expert, but I know we have a TSO bit allocated in e_flags for Ztso binaries.

Indeed. I would prefer the "diff-only" table, noting that it can contain only additions.
In my view, mix-and-match is completely unavoidable at the whole application level, so it would be better to be explicit about that in the spec. I also think we are likely to eventually end up with too many combinations to reasonably list all of them in the spec. Compiler writers will have to pick the right combination for the specified target hardware, and for their performance expectations. And we have to convince ourselves that they all play together (with the existing disclaimers about the A.6 mappings).

I reformatted the table/reworded some of the surrounding text to make it more clear that these are additional mappings enabled by the Ztso extension.
I also changed the wording for the TSO bit to allow linking RVWMO/TSO binaries in a similar way to how RVC binaries are handled.

For the atomic flag stuffs, we will need add a TSO_ATOMIC_ABI and then allow other to merged with that (except the potential soft atomic ABI in future), and then the merge result is TSO_ATOMIC_ABI, does it make sense to you? @patrick-rivos @hboehm

The merge result still needs to be marked as A6C_ATOMIC_ABI or A6S_ATOMIC_ABI in addition to TSO since the mix-and-match allows for TSO mappings that are not A6C compatible.
Eg. atomic_<op>(memory_order_seq_cst) | loop:lr.{w\|d}.aq; <op>; sc.{w\|d}.rl; bnez loop is not A6C compatible - even with a TSO memory model.
IIUC, the TSO_ATOMIC_ABI case is already covered by the TSO bit in the e_flags and {A6C|A6S}_ATOMIC_ABI is needed in addition to that bit.

The merge result still needs to be marked as A6C_ATOMIC_ABI or A6S_ATOMIC_ABI in addition to TSO since the mix-and-match allows for TSO mappings that are not A6C compatible.

A6C_ATOMIC_ABI merged with TSO_ATOMIC_ABI is not conformance with A6C_ATOMIC_ABI and not work on the machine without TSO_ATOMIC_ABI, so I think the merge result is TSO_ATOMIC_ABI, and should be same as A6S_ATOMIC_ABI.

Eg. atomic_<op>(memory_order_seq_cst) | loop:lr.{w\|d}.aq; <op>; sc.{w\|d}.rl; bnez loop is not A6C compatible - even with a TSO memory model.
IIUC, the TSO_ATOMIC_ABI case is already covered by the TSO bit in the e_flags and {A6C|A6S}_ATOMIC_ABI is needed in addition to that bit.

My point is TSO mapping is not make sense to set either A6C_ATOMIC_ABI or A6S_ATOMIC_ABI, and set it to UNKNOWN_ATOMIC_ABI also not good idea since that will allow it can be merged with  A6C_ATOMIC_ABI or A6S_ATOMIC_ABI, and marking the object with TSO_ATOMIC_ABI can make sure that's using updated (this PR) TSO mapping.

Is the TSO bit in e_flags still useful, or is it effectively superseded by defining TSO_ATOMIC_ABI?

Is the TSO bit in e_flags still useful, or is it effectively superseded by defining TSO_ATOMIC_ABI?

It's less useful, but it provide a way to do faster check for dynamic linker/program loader if needed, and it...allocated for a while, so I tend to keep as it.

I would prefer to treat Ztso as a pure ISA extension which allows certain fences to be elided, and have object files which assume Ztso semantics for loads and stores claim conformance to the RVWMO memory models without adding additional complexity to the ATOMIC_ABI selection.

I would prefer to treat Ztso as a pure ISA extension which allows certain fences to be elided, and have object files which assume Ztso semantics for loads and stores claim conformance to the RVWMO memory models without adding additional complexity to the ATOMIC_ABI selection.

But TSO mapping (this PR) is not compatible/conformance either A6C_ATOMIC_ABI or A6S_ATOMIC_ABI?
IMO that will increase the complexity of ATOMIC_ABI since we also need to consider e_flags.EF_RISCV_TSO when interpreter which atomic mapping are using for the object/executable.

I gather there have also been discussions about 8- and 16-bit variants of the AMO operations. If those materialize, that would be another instance in which we would want to extend the mappings in the presence of an ISA extension.  I think it would be great if such a future extension could just follow the model we use for Ztso here.

I am struggling what is the right merge behavior and what's the meaning of those flags (ATOMIC_ABI and EF_RISCV_TSO), so I trying to write my understanding and enumerate the situation (w/o adding TSO_ATOMIC_ABI and w/ A7_ATOMIC_ABI), please correct me if anything you feel wrong :)
EF_RISCV_TSO means the ELF require run on the machine has Ztso extension.
ATOMIC_ABI present which atomic mapping is begin used in the object/executable, if mixed more than one mapping, try to set it as minimal conformance one.
We have few objects using different atomic mapping.
A6C.o
A6S.o
TSO.o
A7.o
ATOMIC_ABI + EF_RISCV_TSO
So when no mixing different mapping, those setting would be:

Input Objects
ATOMIC_ABI
EF_RISCV_TSO
NOTE

A6C.o
A6C_ATOMIC_ABI
0

A6S.o
A6S_ATOMIC_ABI
0

TSO.o
UNKNWON_ATOMIC_ABI
1

A7.o
A7_ATOMIC_ABI
0

OK, let combination the situation:

Input Objects
ATOMIC_ABI
EF_RISCV_TSO
NOTE

A6C.o + A6S.o
A6C_ATOMIC_ABI
0
Mixing A6C and A6S, made this won't conformance with A6S.

A6C.o + TSO.o
UNKNWON_ATOMIC_ABI
1
TSO mapping is not conformance with A6C, but it can run correctly on TSO machine, so set EF_RISCV_TSO=1 to require machine with TSO to run correctly.

A6C.o + A7.o
x
x
Report error, A6C and A7 mapping can't work together correctly.

A6S.o + TSO.o
UNKNWON_ATOMIC_ABI
1
TSO mapping is not conformance with A6S, but it can run correctly on TSO machine, so set EF_RISCV_TSO=1 to require machine with TSO to run correctly.

A6S.o + A7.o
A6S_ATOMIC_ABI
0
It conformance with A6S_ATOMIC_ABI but require Zacas.

TSO.o + A7.o
UNKNWON_ATOMIC_ABI
1
TSO mapping is not conformance with A7, and it require run on machine has TSO AND Zacas.

A6C.o + A6S.o + TSO.o
UNKNWON_ATOMIC_ABI
1
TSO mapping is not conformance with A6C and A6S, but it can run correctly on TSO machine, so set EF_RISCV_TSO=1 to require machine with TSO to run correctly.

A6C.o + A6S.o + A7.o
x
x
Report error, A6C and A7 mapping can't work together correctly.

A6S.o + A7.o + TSO.o
UNKNWON_ATOMIC_ABI
1
A6S and A7 is compatible, but TSO mapping is not conformance with A7, so it require run on machine has TSO and Zacas

ATOMIC_ABI (w/ TSO_ATOMIC_ABI) + EF_RISCV_TSO
And try to add TSO_ATOMIC_ABI

Input Objects
ATOMIC_ABI
EF_RISCV_TSO
NOTE

A6C.o + A6S.o
A6C_ATOMIC_ABI
0
Mixing A6C and A6S, made this won't conformance with A6S.

A6C.o + TSO.o
TSO_ATOMIC_ABI
1
TSO mapping is not conformance with A6C, but A6C is conformance/stronger than TSO, so result is TSO_ATOMIC_ABI

A6C.o + A7.o
x
x
Report error, A6C and A7 mapping can't work together correctly.

A6S.o + TSO.o
TSO_ATOMIC_ABI
1
TSO mapping is not conformance with A6S, but A6S is conformance/stronger than TSO, so result is TSO_ATOMIC_ABI

A6S.o + A7.o
A6S_ATOMIC_ABI
0
It conformance with A6S_ATOMIC_ABI but require Zacas.

TSO.o + A7.o
TSO_ATOMIC_ABI
1
TSO mapping is not conformance with A7, but A7 is conformance/stronger than TSO, so result is TSO_ATOMIC_ABI and it require run on machine has TSO AND Zacas.

A6C.o + A6S.o + TSO.o
TSO_ATOMIC_ABI
1
TSO mapping is not conformance with A6C and A6S, but A6C and A6S are conformance/stronger than TSO, so result is TSO_ATOMIC_ABI, so set EF_RISCV_TSO=1 to require machine with TSO to run correctly.

A6C.o + A6S.o + A7.o
x
x
Report error, A6C and A7 mapping can't work together correctly.

A6S.o + A7.o + TSO.o
TSO_ATOMIC_ABI
1
A6S and A7 is compatible, but A6S and A7 are conformance/stronger than TSO, so it require run on machine has TSO and Zacas

Two bit scheme (EF_RISCV_ATOMIC_A6/EF_RISCV_ATOMIC_A7)
And let me try to using 2 bit scheme which proposed by https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/383, and we can use similar scheme on ELF attribute if we think it's right way.
ATOMIC_A6 = EF_RISCV_ATOMIC_A6
ATOMIC_A7 = EF_RISCV_ATOMIC_A7
TSO = EF_RISCV_TSO

Input Objects
ATOMIC_A6
ATOMIC_A7
TSO
NOTE

A6C.o
1
0
0

A6S.o
1
1
0

TSO.o
0
0
1

A7.o
1
1
0

Input Objects
ATOMIC_A6
ATOMIC_A7
TSO
NOTE

A6C.o + A6S.o
1
0
0
Not compatible with A7

A6C.o + TSO.o
0
0
1
Not compatibe with either A6 or A7

A6C.o + A7.o
x
x
x
Report error, A6C and A7 mapping can't work together correctly.

A6S.o + TSO.o
0
0
1
Not compatible with either A6 or A7, but require TSO

A6S.o + A7.o
0
1
0
Compatible with A7 but require Zacas.

TSO.o + A7.o
0
0
1
Not compatible with either A6 or A7, but require TSO and Zacas

A6C.o + A6S.o + TSO.o
0
0
1
Not compatible with either A6 or A7, but require TSO

A6C.o + A6S.o + A7.o
x
x
x
Report error, A6C and A7 mapping can't work together correctly.

A6S.o + A7.o + TSO.o
0
0
1
Not compatible with either A6 or A7, but require TSO and Zacas

It may be worth noting that the only thing EF_RISCV_TSO=1 allows you to do is delete fences (and aqrl bits) that are already no-ops on Ztso implementations, which means that it will only marginally help on Ztso implementations that can delete no-ops early in the frontend.
@kito-cheng
My argument is that TSO objects should be marked with the atomic ABI they are compatible with, so for the 2-bit version TSO.o should have all of ATOMIC_A6, ATOMIC_A7, and TSO = 1; for the #385 version TSO.o should have A6S_ATOMIC_ABI and EF_RISCV_TSO=1.

I think the Two bit scheme (EF_RISCV_ATOMIC_A6/EF_RISCV_ATOMIC_A7) is the closest table you have to what I was thinking of.
The *_TSO mappings have been made with RVWMO compatibility in mind, so the TSO bit can be safely ignored when deciding compatibility (as long as the TSO bit is set if one of the inputs has the TSO bit set).
First, the compatibility between UNKNOWN, A6C, A6S, and A7.

Inputs ATOMIC_ABI
Output ATOMIC_ABI
NOTE

UNKNOWN + UNKNOWN
UNKNOWN

A6C + A6C
A6C

A6S + A6S
A6S

A7 + A7
A7

UNKNOWN + A6C
A6C
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A6S
A6S
This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A7
A7
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

A6C + A6S
A6C
Must output the least-compatible ABI of the inputs

A6C + A7
INVALID
Throw an error, A6C is incompatible with A7

A6S + A7
A7
Must output the least-compatible ABI of the inputs

Next, the behavior of TSO

Inputs EF_RISCV_TSO
Output EF_RISCV_TSO
NOTE

0 + 0
0
Both RVWMO inputs means an RVWMO output

1 + 0
1
One TSO input means TSO output

0 + 1
1
One TSO input means TSO output

1 + 1
1
Both TSO inputs means TSO output

Now, because the TSO mappings were created to have the same ABIs and be compatible with RVWMO mappings, we can just combine the two tables:

Inputs ATOMIC_ABI
Inputs EF_RISCV_TSO
Output ATOMIC_ABI
Output EF_RISCV_TSO
NOTE

UNKNOWN + UNKNOWN
0 + 0
UNKNOWN
0

A6C + A6C
0 + 0
A6C
0

A6S + A6S
0 + 0
A6S
0

A7 + A7
0 + 0
A7
0

UNKNOWN + A6C
0 + 0
A6C
0
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A6S
0 + 0
A6S
0
This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A7
0 + 0
A7
0
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

A6C + A6S
0 + 0
A6C
0
Must output the least-compatible ABI of the inputs

A6C + A7
0 + 0
INVALID
0
Throw an error, A6C is incompatible with A7

A6S + A7
0 + 0
A7
0
Must output the least-compatible ABI of the inputs

UNKNOWN + UNKNOWN
0 + 1
UNKNOWN
1
One TSO input means TSO output

A6C + A6C
0 + 1
A6C
1

A6S + A6S
0 + 1
A6S
1

A7 + A7
0 + 1
A7
1

UNKNOWN + A6C
0 + 1
A6C
1
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A6S
0 + 1
A6S
1
This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A7
0 + 1
A7
1
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

A6C + A6S
0 + 1
A6C
1
Must output the least-compatible ABI of the inputs

A6C + A7
0 + 1
INVALID
1
Throw an error, A6C is incompatible with A7

A6S + A7
0 + 1
A7
1
Must output the least-compatible ABI of the inputs

UNKNOWN + UNKNOWN
1 + 0
UNKNOWN
1
One TSO input means TSO output

A6C + A6C
1 + 0
A6C
1

A6S + A6S
1 + 0
A6S
1

A7 + A7
1 + 0
A7
1

UNKNOWN + A6C
1 + 0
A6C
1
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A6S
1 + 0
A6S
1
This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A7
1 + 0
A7
1
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

A6C + A6S
1 + 0
A6C
1
Must output the least-compatible ABI of the inputs

A6C + A7
1 + 0
INVALID
1
Throw an error, A6C is incompatible with A7

A6S + A7
1 + 0
A7
1
Must output the least-compatible ABI of the inputs

UNKNOWN + UNKNOWN
1 + 1
UNKNOWN
1
Both TSO input means TSO output

A6C + A6C
1 + 1
A6C
1

A6S + A6S
1 + 1
A6S
1

A7 + A7
1 + 1
A7
1

UNKNOWN + A6C
1 + 1
A6C
1
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A6S
1 + 1
A6S
1
This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

UNKNOWN + A7
1 + 1
A7
1
Must output the least-compatible ABI of the inputs. This doesn't guarantee the resulting binary is fully compatible (since one of the inputs ABI's is unknown), but it allows us to not error on existing binaries.

A6C + A6S
1 + 1
A6C
1
Must output the least-compatible ABI of the inputs

A6C + A7
1 + 1
INVALID
1
Throw an error, A6C is incompatible with A7

A6S + A7
1 + 1
A7
1
Must output the least-compatible ABI of the inputs

It's a bit unwieldy but shows all the 2-input states :)
Covering some 3 input cases:

Inputs ATOMIC_ABI
Inputs EF_RISCV_TSO
Output ATOMIC_ABI
Output EF_RISCV_TSO
NOTE

A6C + A6S + A6S
0 + 0 + 1
A6C
1
A TSO A6S object is compatible with an A6C RVWMO object, as long as the resulting object is run on a TSO machine.

A6C + A7 + A6S
0 + 0 + 1
INVALID
1
Report an error, A6C and A7 do not work together

A6C + A6S + A7
0 + 0 + 1
INVALID
1
Report an error, A6C and A7 do not work together (even if one of them is TSO)

A6S + A7 + A7
0 + 0 + 1
A7
1
Atomic ABIs are compatible between TSO/RVWMO, as long as the resulting object is run on a TSO machine.

A6S + A6C + A6S
0 + 0 + 1
A6C
1
Atomic ABIs are compatible between TSO/RVWMO, as long as the resulting object is run on a TSO machine.

Regarding your tables, there are a few entries that I think are incorrect.
You can implement an A7 binary today using a note 3 mapping like:
atomic_<op>(memory_order_seq_cst)|loop:lr.{w\|d}.aq; <op>; sc.{w\|d}.rl; bnez loop |3, 4
A7 doesn't require Zacas.

Input Objects
ATOMIC_ABI

A6S.o + A7.o
A6S_ATOMIC_ABI

This isn't right since A7 is the more restrictive of the two ABIs, so we should be outputting A7_ATOMIC_ABI.

I agree with Patrick.
The rules for UNKNOWN might be debatable, since UNKNOWN also applies to old gcc-generated code. But I'm OK with Patrick's argument.
If we decompose the ATOMIC_ABI value into an A6C-compatible bit and an A7-compatible bit, treating 00 as UNKNOWN,  with A6S = 11, then the ATOMIC_ABI combination rule becomes:
If either object file has tag 00 (UNKNOWN), then the result tag is the other one, otherwise
bitwise AND the two together. If the result is 0 report invalid, otherwise the AND result is the tag for the combination.
That description wins on brevity, I think, but perhaps not on clarity. Either description is fine with me.

@patrick-rivos
Thanks for expanding the table, that's really much clear to me, I think what I stuck is I am trying to define/understand ATOMIC_ABI is minimal conformance rather than compatible, so that's why I think A6S + A7 should be A6S_ATOMIC_ABI since I treat  A6S_ATOMIC_ABI is less stronger than A7_ATOMIC_ABI.
And one last thing I want to make sure is what ATOMIC_ABI should be used if compiler using this TSO mapping? does @sorear's description same as what you think?
@patrick-rivos @hboehm @sorear
It's really nice discussion here, that fix my server wrong understanding around there :)
And I tend to keep using #385 scheme, but will updated with @patrick-rivos's merge rule, the reason is I want to make sure that able to extend for future soft-atomic stuffs.

@patrick-rivos
Thanks for expanding the table, that's really much clear to me, I think what I stuck is I am trying to define/understand ATOMIC_ABI is minimal conformance rather than compatible, so that's why I think A6S + A7 should be A6S_ATOMIC_ABI since I treat A6S_ATOMIC_ABI is less stronger than A7_ATOMIC_ABI.

Glad it was helpful. The way I think about it is that A6S is a compatibility mapping, so the general flow when merging ABIs is like this:
  UNKNOWN
    /|\
  /  ↓  \
 |  A6S  |
 ↓ ↙   ↘ ↓
A6C      A7

You can never go back up a level, so merging ABIs will always move you to the lowest level of your inputs.
Feel free to ignore this if it's confusing - it's the same as the table, just different way of displaying it. Also please forgive the bad ascii art ;)

And one last thing I want to make sure is what ATOMIC_ABI should be used if compiler using this TSO mapping? does @sorear's description same as what you think?

Yes @sorear's description is the same as what I was thinking. The compiler should emit A6S_ATOMIC_ABI if no Note3 mappings are used. If Note3 mappings are used then we need to emit A7_ATOMIC_ABI.

LGTM, whether or not you accept my two minor suggestions above.

I think all the feedback has been addressed. LMK if I missed anything :)

Please tidy up the commit history

Squashed the commits and replaced C++/C\++ occurrences with {Cpp}.


Backported two changes from Go.

I took advantage of your port of testing.B to do my own (see https://github.com/phf/jb for more) so I wanted to give something back. I backported some (recent?) changes to the testing.B stuff from Go, a somewhat slower/more conservative heuristic for how to increase N over time. This also fixes a tiny "issue" where the code was checking == n instead of <= n as it should have.

Thanks! I'm happy to merge the growth rate tweaks (1.2x, and rounding to 3*base). Do you mind revising this pull request to include only those changes?
It would also be nice to stick to the existing formatting style (no whitespace around binary operators when they're nested inside a larger expression).

This also fixes a tiny "issue" where the code was checking == n instead of <= n as it should have.

Assuming rounddown10 is implemented correctly, n cannot be less than base; rounddown10 won't return a number greater than its input. If you are concerned that that might happen anyway, perhaps (in a separate patch) we should add assert(n >= base) immediately after the call to rounddown10?

Happy to revise, alas I am not 100% sure how to go about doing that. Just make a new pull request with a different set of changes? (Sorry, I may have been hanging around on github for a long time, but I didn't get my PR practice in yet.) If a new PR is easiest, I'll just do that.

Awesome. You can either just push a new commit to this branch (which is master in your fork), or you can amend the existing commit. Either way will update the PR. :)

Sorry for leaving this dangling around for so long. I've finally fixed the commit, at least I think I did. If you still want it, it's all yours. :-)

Sorry, there's now a second commit for another small-ish issue having to do with fully initializing the structs. I didn't mean to add that to this PR alas github decided to. Obviously I don't know what I am doing. The reason for the fix was to be able to use stricter warning flags to gcc and still pass.


Undefined symbols for architecture arm64:   "_glReadPixels", ld: symbol(s) not found for architecture arm64

Plugin Version or Commit ID
v0.8.10
Unity Version
2021.3.7f1
Your Host OS
macOS Monterey 12.5
Target Platform
iOS
[Windows Only] Visual Studio C++ and Windows SDK Version
No response
[Linux Only] GCC/G++ and GLIBC Version
No response
[Android Only] Android Build Tools and NDK Version
No response
[iOS Only] XCode Version
13.4.1
Command Sequences
Run exported Xcode project to build in iPhone X (iOS 15) fails to build.
Log
Getting this error:
Undefined symbols for architecture arm64:
"_glReadPixels", referenced from:
_Gl_ReadPixels_mE20D483BE5ADD7B85929FC4602F7EF734C31705D in Mediapipe.Runtime.o
_UnsafeNativeMethods_glReadPixels_mBDD92D903AFA6B21E4187F39DCED58FB56E4BB4E in Mediapipe.Runtime.o
(maybe you meant: _UnsafeNativeMethods_glReadPixels_mBDD92D903AFA6B21E4187F39DCED58FB56E4BB4E)
"_glFlush", referenced from:
_Gl_Flush_mA9D5ECA06470361D7940768395B3475EBE22FF6E in Mediapipe.Runtime.o
_UnsafeNativeMethods_glFlush_m5E5824AC4B242F7F029A8D0B1CE4A08E910BDFD7 in Mediapipe.Runtime.o
(maybe you meant: _UnsafeNativeMethods_glFlush_m5E5824AC4B242F7F029A8D0B1CE4A08E910BDFD7)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Undefined symbol: _glReadPixels
Undefined symbol: _glFlush
Additional Context
No response

If you search your error already in the Issues section you will see the fix for this here, let me know if doing this doesn't work though
https://github.com/homuler/MediaPipeUnityPlugin/issues/385#issuecomment-997788547

See https://github.com/homuler/MediaPipeUnityPlugin/wiki/Installation-Guide#undefined-symbols-for-architecture-arm64-_glreadpixels.

@homuler  @ROBYER1  I've checked what you said everything is alright as you said. Still the issue persists.

Try a fresh build of your project and in player settings > engine stripping make sure it is set to minimal rather than high

@ROBYER1  engine stripping is by default set to minimal. Also I tried by creating fresh project and import plugin there. Still it is not working.

The error is because OpenGLES dependency is missing - in Unity Editor Project View > Packages/com.github.homuler.mediapipe/Runtime/Plugins/iOS/MediaPipeUnity.framework, check that OpenGLES is ticked in dependencies and also tick Run on start if that is an option. Apply, build to a fresh folder and try again, also Clean Build in Xcode

@ROBYER1 @homuler I've done this also. Still not working. I've tried creating new project and done all of this process in that too. It's not working in that too. Please tell me what do I do to make it run my project.

@ROBYER1 thanks for your help. It ran by doing what you suggested. But, the settings were available on Packages/com.github.homuler.mediapipe/Runtime/Plugins/libmediapipe_c.dylib. I'm leaving this here if anyone gets the settings there.
@homuler thanks for making this wonderful plugin.


Update Footer.js [ Improved Footer Section in Mobile Design]

Fixes Issue
Improved Footer Section in Mobile Design
Closes #9313

Changes proposed
I have wrapped the links in a separate div and then for the paragraph "100% Open source on Github" added the whitespace-nowrap property.

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots
In Desktop view

In Mobile view

Please merge this pull request I want to work on new issues. Thank you.

Please merge this pull request I want to work on new issues. Thank you.

we require 2 maintainers to review on any issues other than profile updates.  Someone will have. a look and merge when they are able.  Thank you for your patience

Please help me. 🙏

Reviewing now

Great collaboration 💪  thank you both, merging now


Added installation of oeegr8r include to install rule

addresses #1290
Currently we are not installing oeedgr8r includes into /opt/openenclave/include/openenclave/oeedgr8r. Samples and other builds using the oeedgr8r will build within the build tree, but not outside.

as  per the comment in the issue, they are installed already from include/cmakelists.txt line 13. Strange that they are not working for you

They really, really aren't.

It would be a good thing if we installed the SDK and built the samples outside of the tree. Currently we aren't even specifying include directories in the makefiles.

I just now did a fresh install to default location (/opt/openenclave) after deleting.
The headers are installed as expected.


Support hyphen '-' in token names

The Regex used to replace token values only supports [a-zA-Z0-9.].
I'm migrating some existing scripts to dbops and we have token names contaning a -
e.g. #{app-DatabaseName}
I think it's just line 27 in internal/functions/Resolve-VariableToken.ps1 that needs to change.

I agree, hyphen should be supported in the token name. And it does seem like an easy fix, I'll PR a fix shortly.

Added in v0.6.3

Working perfectly for me, thanks for the quick response.


FUGR: Some subcreens (as part of function group) aren't imported

Hello,
My problem is that I transferred the package from one system to another (in offline mode) and most of the subscreens were not imported.
Dynpros are part of the functional group.
I can only see these dynpros in the .xml file for import, but after import only a small part of them are in the object list and then in the system.
Dynpros are not found by FM RS_SCREEN_LIST.
Thanks for any advice.

Try installing a test repo: https://github.com/abapGit-tests/FUGR_maint_view which contains a screen. Does this work properly?
Add your function group (or something similar) to https://github.com/abapGit-tests/FUGR_subscreens so we can debug.

Thank you, in my case some text elements overlap other elements (as radio buttons) on the screen. I spotted the error in FM 'RPY_DYNPRO_INSERT'. It was also mantioned in the Log, but I overlooked it. Thank you.


fixed issue #1653

fix issue #1653

Jenkins, test this please.

Jenkins CI test (for commit 82507dbcae2223f837043a21411efbe22f572e09, target branch master) succeeded!

@toslunar This pull-request is marked as to-be-backported, but the corresponding backport PR could not be found. Could you check?

Jenkins CI test (for commit 82507dbcae2223f837043a21411efbe22f572e09, target branch master) succeeded!


Can't send CTRL+,

Windows Terminal version (or Windows build number)
1.9.1942.0 (also 1.10.1933.0)
Other Software
No response
Steps to reproduce

Put
      {          "command": "unbound",          "keys": "ctrl+,"      }
into settings.json.

Type "Ctrl+," e.g., in Emacs or showkey -a

Expected Behavior
Emacs or showkey -a will receive "Ctrl+,".
Actual Behavior
Emacs and showkey -a receive "Ctrl+l" instead.

I believe there is no encoding for Ctrl+, in VT; confirming with a couple other terminal emulators:
In all below instances, I pressed Ctrl+A Ctrl+,
gnome-terminal

xterm

konsole

What are you expecting to see?

Oops, sorry, I didn't check in anything else. I guess I assumed something was wrong because Terminal chooses to send ctrl+l here, which seemed odd to me. I have used this keybinding in the past in Emacs, but I guess it was only ever Emacs in a graphical window.


Golang outpuTarget

Hi guys, I really enjoyed this project. We've been using for a while for creating java classes from protobuf.
But now we have some applications in golang that need to use the same data definition. I know I can copy the proto and generate them using a go client, but it would be nice that all code generation was done at the same time, to guarantee consistency.
Is there any reason why go is not accepted?
If you think it is possible to add and would make sense, I can give a hand and try to create a PR for you.
Let me know what you think!

I think if protoc-gen-go is installed you can simply specify
<outputTarget>
  <type>go</type>
</outputTarget>

https://developers.google.com/protocol-buffers/docs/reference/go-generated

Indeed it works! I think the first time I tried I didnt have protoc-gen-go installed!
In the outputTargets documentation it doesn't mention it.
Type options: "java", "cpp", "python", "descriptor" (default: "java"); for proto3 also: "javanano", "csharp", "objc", "ruby", "js"

In case you think the documentation should be updated.
Tks!


Remove is_urdf argument when building the model

This PR removes the is_urdf argument, as it can get automatically detected by rod. Furthermore, it enables using a rod.Sdf instance to build a JaxSimModel.

[!Warning]
Requires https://github.com/ami-iit/rod/pull/42

📚 Documentation preview 📚: https://jaxsim--238.org.readthedocs.build//238/

I just released rod v0.3.2, can you please bump the dependency? CI should pass as soon as it is deployed to PyPI (maybe in ~10 mins).

@flferretti also in environment.yml :)

I just released rod v0.3.2, can you please bump the dependency? CI should pass as soon as it is deployed to PyPI (maybe in ~10 mins).

Thanks for the release! I made the requested changes on the requirements, it should be okay now

RTD action will fail until rod==0.3.3 will be released on conda-forge. I triggered https://github.com/conda-forge/rod-feedstock/pull/12

As discussed f2f, I added the possibility to force parsing the resource as URDF.


Updated link text for Node.JS

As a best practice, we shouldn't use links that say things like "this" or "click here".

@GeekTrainer That's a perfectly valid point! Thanks.


Update documentation and fix warnings

Codecov Report

Merging #247 into master will decrease coverage by 0.06%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #247      +/-   ##
==========================================
- Coverage   99.25%   99.18%   -0.07%
==========================================
  Files          67       67
  Lines        2952     2956       +4
==========================================
+ Hits         2930     2932       +2
- Misses         12       13       +1
- Partials       10       11       +1

Flag
Coverage Δ

#dot
99.18% <66.66%> (?)

#dot_changes
100% <ø> (ø)
:arrow_up:

#dot_changes_diff
100% <ø> (ø)
:arrow_up:

#dot_changes_run
100% <ø> (ø)
:arrow_up:

#dot_changes_table
100% <ø> (ø)
:arrow_up:

#dot_changes_types
100% <ø> (ø)
:arrow_up:

#dot_example
100% <ø> (ø)
:arrow_up:

#dot_ops
98.42% <66.66%> (-0.35%)
:arrow_down:

#dot_ops_bolt
97.61% <ø> (ø)
:arrow_up:

#dot_ops_nw
98.91% <66.66%> (-1.09%)
:arrow_down:

#dot_ops_pg
97.39% <ø> (ø)
:arrow_up:

#dot_refs
100% <ø> (ø)
:arrow_up:

#dot_streams
98.95% <ø> (ø)
:arrow_up:

#dot_streams_undo
100% <ø> (ø)
:arrow_up:

#dot_test_seqtest
100% <ø> (ø)
:arrow_up:

#dot_x_dotc
93.75% <ø> (ø)
:arrow_up:

#dot_x_fold
100% <ø> (ø)
:arrow_up:

#dot_x_heap
97.82% <ø> (ø)
:arrow_up:

#dot_x_rt
100% <ø> (ø)
:arrow_up:

#dot_x_ui_collab
100% <ø> (ø)
:arrow_up:

#dot_x_ui_dom
100% <ø> (ø)
:arrow_up:

#dot_x_ui_html
100% <ø> (ø)
:arrow_up:

#dot_x_ui_input
100% <ø> (ø)
:arrow_up:

Impacted Files
Coverage Δ

ops/nw/server.go
95.12% <66.66%> (-4.88%)
:arrow_down:

Continue to review full report at Codecov.

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


Webhook template issue in receiver.yaml

I was having a problem where my github webhook was showing a 400 after a bunch of troubleshooting, I found that the values in my receiver.yaml were incorrect.
I had to make the following adjustments. Once I did this the webhook dashboard went from a red triangle to a green check.
Changed:
resources:
- apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
name: flux-system
namespace: flux-system
To:
resources:
- apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
name: flux-cluster
namespace: flux-system
also Changed:
- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
name: flux-system
namespace: flux-system
To:
- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
name: flux-cluster
namespace: flux-system

Thanks for reporting, I have update it.


chore: move sierra to casm compiler trait to dedicated file

This change is

#393
#392
#391
#390  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ArniStarkware and the rest of your teammates on  Graphite

No longer relevant.


Better Android Gradle Plugin 3.x integration

Motivation
Better integration with the Android Gradle-based build process, especially the changes introduced by the Android Gradle Plugin 3.x and AAPT2.
Fixes #16906, the android.enableAapt2=false workaround is no longer required.
Bases the task generation process on the actual application variants present in the project. The current manual process of iterating build types and product flavors could break down when more than one dimension type is present (see https://developer.android.com/studio/build/build-variants.html#flavor-dimensions).
This also exposes a very basic set of properties in the build tasks, so that other tasks can more reliably access them:
android.applicationVariants.all { variant ->
    // This is the generated task itself:
    def reactBundleTask = variant.bundleJsAndAssets
    // These are the outputs by type:
    def resFileCollection = reactBundleTask.generatedResFolders
    def assetsFileCollection = reactBundleTask.generatedAssetsFolders
}

Test Plan
I've tested various combinations of product flavors and build types (Build Variants) to make sure this is consistent. This is a port of what we're currently deploying to our CI process.
Release Notes
[ ANDROID ] [ BUGFIX ] [ react.gradle ] - Support Android Gradle Plugin 3.x and AAPT2
[ ANDROID ] [ FEATURE ] [ react.gradle ] - Expose the bundling task and its outputs via ext properties

I'm not that familiar with Gradle but this looks like fairly compatible with the directories the existing Gradle script was working with.
@hramos any objection from FB's side to landing Gradle commits?

There is also this PR https://github.com/facebook/react-native/pull/17747 that updates gradle

@ide It should be fine. We don't use Gradle internally (aside from running a test to ensure the project can be built using Gradle, to ensure CI does not break when the commit syncs out).

OK, this seems fine to me.
@facebook-github-bot shipit

Looks like we can't build from source anymore with the default gradle setup in master or 0.54.
https://facebook.github.io/react-native/docs/android-building-from-source.html

Would be great to get this released and working, been reported since June in various related issues.

What is the status of this?  Is this going to get re-merged or not?  android.enableAapt2=false is throwing warning with Android Studio 3.1.x saying that it will be removed at the end of 2018.  So that means a lot of people are going to be in a world of hurt if this doesn't get addressed.  This should be a priority.

Any news on this?
Stucked, set aapt2=false cause other problems in my project

I just tested this and build from source works well with gradle 4.4 now, we could land this again.
cc @CFKevinRef

I can resolve the conflict by effectively backing out Android - Fix Drawable v4 paths in Android Artifact Resources (Libraries) as I believe this makes it redundant, but I need to find/create a test case to be sure.

OK, up to date with master and using fallbacks for at least plugin 2.3.3.

@CFKevinRef .
 Thank you.
Is it possible to merge this PR? Thanks.

Closing since #20526 (mirror of this one) just landed!


Categorizing internal messages, limiting to one internal message type per session and removing properties from internal messages

Creating a distinct type for each internal message
Limiting each message type to one per session
Not setting any properties on internal messages

This will address #125

:shipit:

Nicely done! :shipit:


Change TryGetBestOverload to use CheckTypes only

Previously, TryGetBestOverload took a TexlBinding and called HandleCheckInvocation. This has been changed so that only CheckTypes is called, and only a CheckTypesContext is needed.

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll


Server crashed due to an unknown error | #GPR

Hi, I got this problem on my SA:MP Server. I think is from your streaming, can you check please?
[19:55:50] [debug] Server crashed due to an unknown error
[19:55:50] [debug] Native backtrace:
[19:55:50] [debug] #0 f7484e8b in _ZN10StackTraceC1EPv () from plugins/crashdetect.so
[19:55:50] [debug] #1 f747dbcf in _ZN11CrashDetect20PrintNativeBacktraceERSoPv () from plugins/crashdetect.so
[19:55:50] [debug] #2 f747edbc in _ZN11CrashDetect20PrintNativeBacktraceEPv () from plugins/crashdetect.so
[19:55:50] [debug] #3 f747f226 in _ZN11CrashDetect11OnExceptionEPv () from plugins/crashdetect.so
[19:55:50] [debug] #4 f7484adc in ?? () from plugins/crashdetect.so
[19:55:50] [debug] #5 f779f410 in ?? ()
[19:55:50] [debug] #6 f779f425 in ?? ()
[19:55:50] [debug] #7 f74d2941 in gsignal () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[19:55:50] [debug] #8 f74d5d72 in abort () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[19:55:50] [debug] #9 f750ee15 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[19:55:50] [debug] #10 f7518f01 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[19:55:50] [debug] #11 f751935a in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[19:55:50] [debug] #12 f751a6e5 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[19:55:50] [debug] #13 f751d81d in cfree () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[19:55:50] [debug] #14 f76a54bf in _ZdlPv () from /usr/lib/i386-linux-gnu/libstdc++.so.6
[19:55:50] [debug] #15 080e2239 in ?? () from samp03svr
[19:55:50] [debug] #16 f73ea7a3 in ?? () from plugins/streamer.so
[19:55:50] [debug] #17 f74466a5 in ?? () from plugins/streamer.so
[19:55:50] [debug] #18 f7448b0a in ?? () from plugins/streamer.so
[19:55:50] [debug] #19 f7449127 in ?? () from plugins/streamer.so
[19:55:50] [debug] #20 f7415cc5 in ProcessTick () from plugins/streamer.so
[19:55:50] [debug] #21 080d1ce2 in ?? () from samp03svr
[19:55:50] [debug] #22 080aef6c in ?? () from samp03svr
[19:55:50] [debug] #23 080aa13a in ?? () from samp03svr
[19:55:50] [debug] #24 f74bee46 in __libc_start_main () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
[19:55:50] [debug] #25 0804b4e1 in ?? () from samp03svr

Any ideea why!? Thank you.

UP?

Compile the streamer plugin in debug mode.
Run it with gdb if you know how.
There's not much information from what you pasted in this issue, and the only thing crashdetect has to do with it is the fact it reported the error to you.
Also compile your Pawn code with debug symbols.

What is this "streamer plugin in debug mode"... I not understand

He means that you need to build the streamer plugin from source code with debug symbols enabled. This would give more information if running under gdb, or even if just using crashdetect alone (though not as much).
Anyway, if you want further assistance you can create an issue here: https://github.com/samp-incognito/samp-streamer-plugin


Labeled repr

It may be nice to take advantage of labels to show a different, labeled repr - especially for more than 3 dimensions, I personally find the the numpy array one hard to read.
Some sample data and the current repr

In [103]: d = xr.DataArray(np.arange(200).reshape((2,5,2,10)), dims=('a', 'b', 'c', 'd'),
     ...:                  coords={'a': ['A', 'B'], 'b': ['Cat 1', 'Cat 2', 'Cat 3', 'Cat 4', 'Cat 5'],
     ...:                          'c': ['J', 'K']})

In [104]: d
Out[104]:
<xarray.DataArray (a: 2, b: 5, c: 2, d: 10)>
array([[[[  0,   1,   2,   3,   4,   5,   6,   7,   8,   9],
         [ 10,  11,  12,  13,  14,  15,  16,  17,  18,  19]],

        [[ 20,  21,  22,  23,  24,  25,  26,  27,  28,  29],
         [ 30,  31,  32,  33,  34,  35,  36,  37,  38,  39]],

        [[ 40,  41,  42,  43,  44,  45,  46,  47,  48,  49],
         [ 50,  51,  52,  53,  54,  55,  56,  57,  58,  59]],

        [[ 60,  61,  62,  63,  64,  65,  66,  67,  68,  69],
         [ 70,  71,  72,  73,  74,  75,  76,  77,  78,  79]],

        [[ 80,  81,  82,  83,  84,  85,  86,  87,  88,  89],
         [ 90,  91,  92,  93,  94,  95,  96,  97,  98,  99]]],

       [[[100, 101, 102, 103, 104, 105, 106, 107, 108, 109],
         [110, 111, 112, 113, 114, 115, 116, 117, 118, 119]],

        [[120, 121, 122, 123, 124, 125, 126, 127, 128, 129],
         [130, 131, 132, 133, 134, 135, 136, 137, 138, 139]],

        [[140, 141, 142, 143, 144, 145, 146, 147, 148, 149],
         [150, 151, 152, 153, 154, 155, 156, 157, 158, 159]],

        [[160, 161, 162, 163, 164, 165, 166, 167, 168, 169],
         [170, 171, 172, 173, 174, 175, 176, 177, 178, 179]],

        [[180, 181, 182, 183, 184, 185, 186, 187, 188, 189],
         [190, 191, 192, 193, 194, 195, 196, 197, 198, 199]]]])
Coordinates:
  * a        (a) <U1 'A' 'B'
  * b        (b) <U5 'Cat 1' 'Cat 2' 'Cat 3' 'Cat 4' 'Cat 5'
  * c        (c) <U1 'J' 'K'
  * d        (d) int64 0 1 2 3 4 5 6 7 8 9

The labeled repr could instead look something (not exactly) like this?
<xarray.DataArray (a: 2, b: 5, c: 2, d: 10)>

a: 'A'
b: 'Cat 1'
c x d:
         0   2   3   4   5   6   7   8   9  10
     J   0   1   2   3   4   5   6   7   8   9
     K  10  11  12  13  14  15  16  17  18  19

a: 'A'
b: 'Cat 2'
c x d
    <repeat>
...

Coordinates:
  * a        (a) <U1 'A' 'B'
  * b        (b) <U5 'Cat 1' 'Cat 2' 'Cat 3' 'Cat 4' 'Cat 5'
  * c        (c) <U1 'J' 'K'
  * d        (d) int64 0 1 2 3 4 5 6 7 8 9

Agreed, I'm never been really happy with our use of the NumPy repr for >2 dimensions. It's quite hard to match up the labels.
Something like this would be a meaningful improvement! I would encourage experimentation on this.

I am in favor of as few repr as possible, i.e. maybe the first few values in each dimension.

I think dupe of https://github.com/pydata/xarray/issues/680

After seeing the discussion in #680, I'm wondering if showing the firsts values of the flattened array wouldn't be enough here, e.g., something like this:
>>> d
<xarray.DataArray (a: 2, b: 5, c: 2, d: 10)>
  array          int64 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ...
Coordinates:
  * a        (a) <U1 'A' 'B'
  * b        (b) <U5 'Cat 1' 'Cat 2' 'Cat 3' 'Cat 4' 'Cat 5'
  * c        (c) <U1 'J' 'K'
  * d        (d) int64 0 1 2 3 4 5 6 7 8 9

This example is more consistent with the repr of Dataset data variables, and similarly we could customize the repr of dask arrays and lazy arrays (loaded from netcdf files) like this:
>>> d.chunk(10, 5, 5, 10)
<xarray.DataArray (a: 2, b: 5, c: 2, d: 10)>
  dask.array     int64 chunksize=(100, 5, 5, 10)
Coordinates:
  * a        (a) <U1 'A' 'B'
  * b        (b) <U5 'Cat 1' 'Cat 2' 'Cat 3' 'Cat 4' 'Cat 5'
  * c        (c) <U1 'J' 'K'
  * d        (d) int64 0 1 2 3 4 5 6 7 8 9

>>> d.name = 'myvar'
>>> d.to_netcdf('data.nc')
>>> xr.open_dataset('data.nc').myvar
<xarray.DataArray 'myvar' (a: 2, b: 5, c: 2, d: 10)>
  lazy-array     int64
Coordinates:
  * a        (a) <U1 'A' 'B'
  * b        (b) <U5 'Cat 1' 'Cat 2' 'Cat 3' 'Cat 4' 'Cat 5'
  * c        (c) <U1 'J' 'K'
  * d        (d) int64 0 1 2 3 4 5 6 7 8 9

I agree, but I see one or two cases where it could be useful to have the first few values for each dim. For example with geopotential data on pressure levels, it could be interesting to see how the data varies with height on the third dim. But this is a detail, not very important.

There could be some display options exposed to manage this - for instance I personally would not like a flat array - but see how it could make sense.
Additionally / alternative, the repr I'm talking (small slice of values laid out with coordinate labels) could called something other than __repr__ - something like pandas .head() although may be a better name to use here.

In most cases I found the DataArray repr useful for quickly checking the dimensions (both names and sizes), the attributes and the types/values of both data and labels (I mean just checking here if the values are consistent regarding their units, acceptable ranges, etc.), but rarely for in-depth checking of the data values along each dimension, hence my suggestion of a flat (subset) array.
To inspect the data of high dimensional datarrays, I've mainly used the indexing logic of xarray to extract slices of <3 dimensions. However, I admit that for quick inspection purposes I actually like your suggestion of having a specific repr method that would allow showing small data slices as labeled tables, especially if we choose to always use a flat array for the repr of Dataarray (i.e., even when the number of dimensions <3). Why not something like:
>>> d.slice_repr(a=0, b=0)
d   0   1   2   3   4   5   6   7   8   9
c
J   0   1   2   3   4   5   6   7   8   9
K  10  11  12  13  14  15  16  17  18  19

This is equivalent to
>>> dslice = d.isel(a=0, b=0)
>>> pd.DataFrame(data=dslice.data, index=dslice.c, columns=dslice.d)

Except that slice_repr() would return a string instead of a data object (or an array or a dataframe).
The name and signature of slice_repr() here may not be the best.


Upgrade webpack version from 1.* to 2.*

Webpack version 2 has very significant changes, and configuration is not backward compatible
https://blog.madewithenvy.com/getting-started-with-webpack-2-ed2b86c68783#.3tv0tylgk
We need to upgrade to webpack 2.* and rebuild our webpack.config.js

@ndcunningham Can you take care of this?

Please take a look at ng2-map, which has already upgrade to webpack 2

was busy this week, pr is coming


tf.optimizers and tf.GradientTape() not found

Hi. I'm new to TensorFlow.NET, i'm trying to recreate some basic examples.
When I tried to recreate the example in the main page I get an error that say that tensorflow doesn't contain a definition por optimizers, and it's the same with GradientTape().
I installed Tensorflow.NET and SciSharp.TensorFlow.Redist using NuGet. I tried looking in the issues for something similar but I couldn't found it, any idea what I'm doing wrong?

@DanielEliasib Please check the latest update: https://github.com/SciSharp/SciSharp-Stack-Examples/blob/master/src/TensorFlowNET.Examples/BasicModels/LogisticRegression.cs


npm start / npm run start fails due to NODE_ENV not found

Hello,
I wanted to give vortgern a try and did the following:
$ git clone https://github.com/barbar/vortigern
$ cd vortigern
$ npm run setup

everything worked so far.
Now I am getting an error when trying to start it:
$ npm start

Here is a screenshot of the console output:

I am using windows 10.
My node version is V4.4.3
My npm version is 3.8.2
I couldn't find anything on google regarding my issue. I hope you can help me. Thanks!
Cheers,
Raphael Hippe

Hey Raphael,
Can you try running NODE_ENV=development npm start while I check why it didn't falled back to the default parameters?
Thanks.

Hey Raphael,
Sorry for the inconvenience, I've just checked our start scripts and it appears it's related to Windows and how it handles setting environmental variables. I'll check on how to fix that and get back to you.
Thanks.

hi @RaphaelHippe, you can easily fix this by changing the way how env variables set in package.json and Makefile for Windows.
e.g.
this:
ENV1=value1 ENV2=value2 make build
becomes to:
SET ENV1=value1 && SET  ENV2=value2 && make build

Hey,
thanks for the very quick answers.
This worked as in it brought up new errors for me.
First I had to install make for windows (msysgit) to execute the make files.
now using the $ npm start command I am getting a ton of WARNINGS and ERRORS.
I am gonna attach some screenshots again.
Warnings

Errors

NPM Debug Log
npm-debug-log.txt
Thanks again, looking forward to hearing from you again.
Cheers

@RaphaelHippe
Hi, I've made a change which seems related to solution of your problem. Can you try with the latest version?

Hey,
your fix got rid of some Errors and all the Warnings.
Although the Errors with the CSS modules still remain. (previous provided screenshots)
Thanks

@RaphaelHippe
Happy to hear that :)
I was suspecting the NPM version (btw we all run the latest version: 6.2) but I tried to run vortigern with a fresh install on npm 4.4.4 and it was working as expected.
We will keep investigating the crux. In the meantime, please don't hesitate to ping us (or open a pull request) if you come up with an idea (or a solution!).

Hi,
Having a similar issue on Windows dev box, though I skipped the whole makefile portion and just ran the webpack commands manually for now.
both webpack commands appear to return without error:
 PS C:\Users\Joe\Documents\GitHub\vortigern> webpack --config .\config\webpack\dev.js
ts-loader: Using<EMAIL_ADDRESS>and C:\Users\Joe\Documents\GitHub\vortigern\tsconfig.json
Hash: 4fc16894fcceff0bd9b3
Version: webpack 1.13.1
Time: 3915ms
                                      Asset      Size  Chunks             Chunk Names
images/a6a8103e977275e28df8224ed8d6521e.png   16.7 kB          [emitted]
                                  js/app.js   1.25 MB       0  [emitted]  app
                           ../manifest.json  98 bytes          [emitted]
   [0] multi app 40 bytes {0} [built]
 [277] ./config/main.js 702 bytes {0} [built]
    + 313 hidden modules
PS C:\Users\Joe\Documents\GitHub\vortigern> webpack --config .\config\webpack\server.js
ts-loader: Using<EMAIL_ADDRESS>and C:\Users\Joe\Documents\GitHub\vortigern\tsconfig.json
Hash: ac874fe61cac7dd45ea6
Version: webpack 1.13.1
Time: 3292ms
                                      Asset     Size  Chunks             Chunk Names
images/a6a8103e977275e28df8224ed8d6521e.png  16.7 kB          [emitted]
                               ../server.js   680 kB       0  [emitted]  main
   [1] ./config/main.js 702 bytes {0} [built]
 [203] ./config/webpack/dev.js 2.68 kB {0} [built]
    + 210 hidden modules
PS C:\Users\Joe\Documents\GitHub\vortigern>

when i run the build/server.js though I get window is not defined. Googling around seems to indicate something about there not being a window object when targeting node / when server-side rendering.
PS C:\Users\Joe\Documents\GitHub\vortigern> node .\build\server.js
C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:19417
                        return /msie [6-9]\b/.test(window.navigator.userAgent.toLowerCase());
                                                   ^

ReferenceError: window is not defined
    at C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:19417:31
    at C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:19412:48
    at module.exports (C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:19434:69)
    at Object.<anonymous> (C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:19727:39)
    at __webpack_require__ (C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:21:30)
    at Object.<anonymous> (C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:19703:10)
    at __webpack_require__ (C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:21:30)
    at Object.<anonymous> (C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:19171:15)
    at __webpack_require__ (C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:21:30)
    at Object.<anonymous> (C:\Users\Joe\Documents\GitHub\vortigern\build\server.js:19156:21)

Just wanted to give you guys an update. @ufukomer is currently working on the Windows bugs. We've also setup a Windows VM for testing so we expect less problems with Windows in the future.
Thanks for trying out Vortigern.

Hey guys,
just wanted to let you know your changes worked for me!
Thanks for the support :)

That's perfect news @RaphaelHippe.
Please let us know any feedbacks you may have so we can make Vortigern better. :)

Glad I checked back. Did a fresh install and it works like a charm on Windows 10. Great job guys.


Split CI and PR pipelines

As CI pipeline is becoming more complex, this splits the pipelines, reducing the number of conditions in the pipeline steps.

To reduce the sizes of both, extracted inclusive lint, building analyzer and building anonymizer into templates for reuse in both CI and PR pipelines.
Made Functional tests not dependent in the services build jobs, reduces the build time from 11 to 6 minutes, ultimately releasing build agents faster which we need, yet not 'classic CI' where we run Build -> UT -> functional
Regarding CI pipeline I've currently just left the dev deployment as-is, not extracting into a template. I think that it's worth waiting for the production deployment and see what is common and what is not.

@navalev  eventually I want to move everything to /pipelines WDYT?

@SharonHart yes, agree all can go under pipelines folder. also would change the names to somthing like  ci-pipeline and pr-pipeline


Play custom scene(quick run scene) icon remains checked

The Icon is not releasing.
1.Press "Play custom scene buggy".
2.Close the window or "Open/select" scene. It is still showing icon_folder is pressed.

Is this really fixed?
1.Press "Play custom scene".
2.Press close or X it is still checked.

It's working for me in the master branch.

Ops... I forgot one line :|


Added support for customising username and icon url for slack posts

I thought it might be a nice addition to add more customisation to Slack actions. This commit lets you customise the username and icon used for Slack posts, defaulting to the current behaviour if nothing is specified.

Looks great to me, thanks. Could you squash the commits to one? Thanks for contributing to fastlane :+1:

Leave a quick comment after you're ready so that I get a notification :+1:

Sure! That should be done now

This is perfect, thank you so much for your contribution :+1:

No problem, glad to help!


python310Packages.hahomematic: 1.5.0 -> 1.5.3

Description of changes
https://github.com/danielperna84/hahomematic/releases/tag/1.5.3

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 174288 run on x86_64-linux 1

2 packages built:

python310Packages.hahomematic
python39Packages.hahomematic


Potential data loss when upgrading sub-classes of BaseLogEntry (Wagtail 2.16 -> Wagtail 3.0)

BaseLogEntry
https://docs.wagtail.org/en/stable/reference/pages/model_reference.html#baselogentry
Wagtail 3.0 Upgrade Considerations - Replaced data_json TextField with data JSONField in BaseLogEntry
https://docs.wagtail.org/en/stable/releases/3.0.html#replaced-data-json-textfield-with-data-jsonfield-in-baselogentry
Details
These entries document that these fields have changed from data_json (a TextField) to data (a JSONField).
However, if (like me) you have a sub-class of BaseLogEntry, the automatically generated migration will result in loss of the log data, because it generates the following migration operations:
    operations = [
        migrations.RemoveField(
            model_name='objectdatalogentry',
            name='data_json',
        ),
        migrations.AddField(
            model_name='objectdatalogentry',
            name='data',
            field=models.JSONField(blank=True, default=dict),
        ),

Note: this migration was automatically generated by Django 4.0.8, while upgrading from Wagtail 2.16.3 to 3.0.3. I haven't tested with other Django versions.
Similar migrations in the Wagtail core code, have migration operations like this:
eg. https://github.com/wagtail/wagtail/blob/main/wagtail/migrations/0069_log_entry_jsonfield.py#L12
    operations = [
        migrations.AlterField(
            model_name="modellogentry",
            name="data_json",
            field=models.JSONField(blank=True, default=dict),
        ),
        migrations.RenameField(
            model_name="modellogentry",
            old_name="data_json",
            new_name="data",
        ),

There is a warning against the BaseLogEntry documentation about the change in the field, but I think it would be helpful to have an additional warning suggesting the migration be carefully scrutinised, and potentially replaced with something like the example above. A similar warning in the Upgrade Considerations section pointing to this would also be useful - especially for those who are considering upgrading from 2.15 LTS to the imminent 4.1 LTS release.
I've raised this as a documentation issue, because I doubt there is anything that can be done within the Wagtail code base (or Django for that matter) to solve this problem.

I'd love to work on this

@thibaudcolas any comment on this before I proceed, please??

Hey @Dev-Liz
If you are working on this issue, I would love to work on it

Hello @Headon1729, I think I need more explanations to get started with it.
Please go ahead and fix it if you understand it better. :)

I think that's a good call. @laymonage would you be happy to add this?

Thanks for the report! PR: #9640
I assume the same could also happen with subclasses of AbstractFormSubmission and PageRevision. I added the same callout for AbstractFormSubmission, but I didn't bother with PageRevision as I don't see why people would subclass that model (and we renamed it to Revision in 4.0 anyway).


Bump to .NET 6 and Rewrite VS Code

Rewrite VS Code to leverage the .NET CLI.
Create a VS2022 extension (WIP).
Fix #344
To build:
Get Recommended Node (I downloaded the left one currently 16 something).
Get .NET 6
Open a shell
Go into DevSkim-VSCode-PlugIn folder
Run npm run pack-ext
Open VS Code, Go to Extension Tab, Click the ... and choose "Install from VSIX." and select the vsix you built above.  This should also automatically install the .NET helper extension.

The code is now working (when the files get placed in the right location).
Remaining issue is getting the build to work properly.
Hoping to wrap this up by tomorrow.

Known issues:
The pattern for the fix is ignored and instead the match is replaced with the replacement text.  Instead it looks like the match from the finding should be checked against the pattern object in the fix and then anything that matches that pattern, inside the finding, is replaced.  Requires either adding a "calculate-fixed" to the dotnet CLI or reimplementing the pattern matching behavior in typescript.

@daalcant for signing this vsix should we sign the .NET dlls then embed them or just present the whole vsix to be signed?

The extension currently behaves differently in VS 2019 and 2022. Debugging the 2022 version is very slow, while the 2019 version is tolerable.
In this PR in both versions if you attempt to apply a fix the errors will be out of date with the current spans and it will throw an exception.

Reverted to a draft. Am going to take a different approach to create a single Language Server written in C# that leverages the DevSkim library and use that for both VS Code and VS 2022 and 2019.  Will be returning to work on this next week.

Reimplementing in a different branch.


doc: clarify that multi-meta variables can be named

Ah, I also included some local wording improvements I had done locally. I can split those in a separate commit if you prefer that.

Thank you very much for saving my poor English! This is a really nice mentioning!


Add Icon for Crafty Controller

What has been added

512x512 .png logo for Crafty Controller (crafty-controller.png)

Note

there were no .svg available

Their full logo has the the icon in it, I'll look into extracting it somewhere this week to create the an svg logo.
https://gitlab.com/crafty-controller/crafty-4/-/blob/de97cb799ef6496f63b0803a2101b91165946f26/app/frontend/static/assets/images/logo_long.svg

@Tinyblargon Please do! Thanks 🙂

@walkxcode currently waiting on this PR https://gitlab.com/crafty-controller/crafty-4/-/merge_requests/666

Merging this one: https://github.com/walkxcode/dashboard-icons/pull/534


refactor existing methods to use method_code_version and partial

Same as #455 but for all non-batch integration tasks.
Passed benchmark run at https://github.com/scottgigante-immunai/openproblems/runs/6993031187?check_suite_focus=true

@LuckyMD could you please review?

Sry, missed this in emails.

i see you're using partial also when only 1 function exists

Lol no that was a mistake. There was a second one that I forgot to use the partial decorator for. Thanks for the review!


When quicky changing directions on a 2 steppers setup sometimes one (or both) steppers can end reversed

Hi !
I'm trying to drive a two stepper setup based on a "noisy" input quickly changing from CW to CCW sometimes doing large movements, sometimes very short. The direction can be changed up to every 10ms. It could be considered to be close to a random noise.
Currently the settings are the following :
The platform is a good old arduino nano v3,
I tested both the official release available here as a zip :  https://www.ardu-badge.com/FastAccelStepper
And the current from repo.
I'm using arduino 1.8.19 if somehow that matters (the latest prior 2.X)
const int stepper1_pulsePin = 9; // Must be either 9 or 10
const int stepper1_directionPin = 3;
const int stepper1_enablePin = 2;
const int stepper1_reverseDirection = true;
const int stepper2_pulsePin = 10; // Must be either 9 or 10
const int stepper2_directionPin = 5;
const int stepper2_enablePin = 4;
const int stepper2_reverseDirection = false;
speedHz = 28000hz
acceleration = 30000;
I'm only using the moveTo command as the goal is to go as fast as possible to the target position, and if there not enough time simply give up and try to follow as best as possible the target position either in one direction or the other.
When the issue occurs, it ends to keep reversed  for a long time (even when switching directions again and again) and sometimes recover. I suspect it to recover when the movement finally settles enough to get a full stop.
I've tried to dissect the logic behind StepperISR, to hopefully give some insights,
Originally I thought about a race condition on the digitalwrite available in StepperISR between both steppers :

I tried to move the interrupt disabling way earlier (before evaluating if there must be a direction change), with no success.
I also tried to disable interrupts around the moveTo function to hopefully kill any race conditions between the moveTo changes and the stepper routines, with no success neither.

My eye got caught by the way the pin direction is transmitted to the interrupt : it's a toggle flag. So if somehow in such race conditions it gets toggled twice, or a toggle is missed, the actual direction pin state could (?) maybe get reversed for a long time and this miss survive many later toggles . I can't get my finger on which could get a missed toggle, but I somehow feel it's the cause.
For Science I also tried to always trigger a stop if the direction is to be changed, and wait for it to be stopped (!isRunning) to initiate the new movement with moveTo, but it ended having the same issue from time to time (which would ruin my theory about a full stop recovering the situation)
Maybe would you have some insights ? The library is super fast and convenient, but this really got me lost :D I guess this "almost random" direction changes is clearly not common, that would explain why an issue could be hidden.

Edit :
Just some extra infos which could matter :

The direction reverse can occur on one stepper, or both, number one or number two even if issue statistically seems to be more represented on #2 .
During the initialization I do an automatic position calibration, it never fails : but it's a move forward , stop, move backward, stop when a sensor is detected pattern. Not the same quick movements I have during the running conditions.

There may be a weak spot in the stepper ISR. Could you please check, if in your application, that code branch is executed ? For example, just set there a global variable to a specific value and monitor that variable. Idea is, if that new command contains a direction pin toggle, it may get lost.
For the stopped motor case: If the motor is stopped (!isRunning()), then the direction pin is set instead of using a toggle. So it should work as expected from a stopped motor. Just for the avr implementation, it could be that isRunning() returns false, but there still can happen another interrupt. That‘s the purpose of that branch to recover from this situation. I would have expected, that this specific case is handled well….but without test it is just an unproven hypothesis.
In addition, please try to set the direction change delay parameter to 1 in:
setDirectionPin(uint8_t dirPin, bool dirHighCountsUp = true,
                       uint16_t dir_change_delay_us = 0);

Then please check, if the behavior is gone.

Hi ! Thanks a lot ! I will check and report,
About the direction switch delay I did try it with various delays from 25 to 400us, it's a very interesting feature as it helps skipping lot of quick direction changes and makes it quieter in my purpose, but unfortunately it didn't helped.
In the meanwhile I also tried again this morning with slower accelerations, slower max speeds, I also tried a 400ms spacing between every updates.
I have indeed seen those two sepa

Thanks for the feedback. The issue is closed by you. Is this by accident or have you identified/solved the root cause/issue ?

Hi ! Sorry it was a bad manipulation!

With a 400ms delay, the issue has still occurred ?

Yes with the delay it was indeed still failing randomly. But at the end that will be a parameter I will use, due to the noisy nature of my application it's a good trade for reducing noise on direction changes, I need absolute positioning but not absolutely instant position :D
I will try to monitor the code branch you pointed this morning.
Another test I did last week after trying to understand better the library logic, was to avoid a single step change as I've seen that one step was a very specific case, so I Added a minimum value between two positions (I tried a minimum of 20step from memory) with no luck, but I guess that this code branch is about one step remaining, not overall one step move. But indeed just by reading it could be a good candidate for a direction change miss. I wish I could be of better help :D but I'm fighting to catch the exact events relations between the isr and the queue processing.
From my understanding moveto exclusively manipulates the queue end, and do not enqueue moves (so without queue overflow risks) . So I already excluded this possibility.
Overall I did lot of tests and combinations(always around the moveto command) speed, pauses, accelerations. I was hoping to come with a PR instead of a call for help :D
If I understand the potential breach you are pointing : if a direction change was due on this one step remaining branch, it would be missed, and if somehow the movement is started again at this exact time then it would keep it out of sync until a complete stop.
Since both motors are for now fed with the same instructions, I can see very visually when it occurs, and my conviction is that it's on small moves. And once a large move is triggered in the swapped direction it can get off from 2000 or 3000 steps.
I was using previously a very old version of your library, and I think it was already the case (probably less often as the whole code around was significantly slower). I've always put it on an overtorque issue.
Just for illustration instead of keeping the application mysterious (even if I tried to focus on the issue triggers and symptoms) , https://youtu.be/7ao_srZlhNc?si=hs74gvI-pad-QFn5
Overall it's a super simple serial to absolute position sketch
For all my current tests the motors are unloaded, but since I could see it very visually the direction swap, load for this case is not a factor
I will try to log it first and try to patch it if I can. Fingers crossed!

Great analysis and this looks promising. Unfortunately the test suite is very sensitive to code changes, which impacts the timing and as such throws a lot of false positives. So I need to check your patch on my local pc first and fix the false positives. I doubt, this can be done before the weekend.
Sorry for that.

Really no problems ;) Unfortunately I won't be available next week if you need some extra tests feedback. I will try to check as far as I can how well it performs now in real conditions ;) (minus this little doubt about one step being lost, no visual observation (on my hardware) can really guarantee it :D

Just a follow-up as promised :  after 4 days and lot of tests in real conditions. Not a single wrong direction issue anymore. I've not noticed any steps loss neither. I'm using the latest master version with the patch I submitted.
I can only say one thing : your library is amazing ;) absolute position, relative, dynamic acceleration and speed is nicely handled and butter smooth !
I've been using your library since 2 years and it have always beaten everything else I could test in terms of API and speed ;)

The new test for issue 250 is failing with the patch. So I have moved the patch one level up, but still no success. Need to continue to work on it.

Apparently, FastAccelStepper cannot cope well with interrupt blocks >20us at high speed. So the test failures on my side were not related to the direction pin changes.
Not sure, if this still works well on your hardware. As I expect no issues, I have made another formal release v0.30.12

Hi !
Thanks a lot for your efforts, I see indeed the patch was integrated as I submitted it. In my case I've seen no issues since, I could test it a full week, and everytime it felt to have kept perfectly the centered (which is the "idle" position when finished and is a good indicator of a drift).

Could you please test the latest master branch ? I have reworked the whole ISR to make it more robust against longer blocks of the interrupt. This allows to nearly eliminate the problematic code branch with your patch.
Robust means in this context: no steps lost, but a 4ms pause could occur between two steps.

For sure, I will be able to test it next week ;)

As promised, a feedback ;) I took the latest master version and let it run for 2 hours in my usage conditions. Everything was still aligned. So after two hours I can conclude with good confidence that there is no missed steps or directions issue. Thanks a lot !


Create action.yml

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Totals

Change from base Build<PHONE_NUMBER>3:
0.0%

Covered Lines:
0

Relevant Lines:
9

💛  - Coveralls


fix: change setConnectionOptions argument to partial

:tada: This PR is included in version 1.6.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


What about stop word removal

Thanks for useful efforts,
The original version and java implementation of Rouge have also an option for stop word removal, are you going to implement it too?

Hi (sorry, vacation delay),
Why not, it makes sense and It's super easy to do using nltk library (see example), we could add an option to do it.


Webpack 2 support

Does offline-plugin have webpack2 support?

Yes.

I mean, yes it's does, just use it with webpack 2. If you have any problems with it let me know, but here shouldn't be any.


feat(core): add an error event to monitor error from Algolia

Fix #1585
Adds an event that is emitted when an error is received in place of results.

We had one up until now, render which is used to give an information about the end of the rendering step. They are used in order to provide information that we can't provide using widgets.


Add metrics for all JAX-RS resource endpoints.

This exposes metrics to the internal metrics registry.

So I am planning to work on a decorator for that so I will close the pull request, otherwise I will lose track on all the pull requests that I have open.


Could you please provide the annoyation of Totaltext

I can not to  convert the  format of the Totaltext dataset

+1

+1


"Manage Custom Words" and "Widget and Property Default" menus not opening.

I remade a fresh portable comfyui install and still have this issue, tried in multiple browsers as well. The browser console log states that the autocompleter.js is not a function and that the server cannot be found.

Having the same problem on a fresh install of ComfyUI through SwarmUI

ComfyUI-Custom-Scripts\web\js\autocompleter.js
495行
								app.ui.settings.element.close();
改
								if (typeof app.ui.settings.element.close === "function") { 									app.ui.settings.element.close(); 								} else { 									app.ui.settings.element.style.display = "none"; 								}

ComfyUI-Custom-Scripts\web\js\autocompleter.js 495行 app.ui.settings.element.close(); 改 if (typeof app.ui.settings.element.close === "function") { app.ui.settings.element.close(); } else { app.ui.settings.element.style.display = "none"; }

@pythongosssss This seems to fix the issue. I needed to replace the same element.close function in widgetDefaults.js as well though to get the other menu working. Are there any other scripts that I should update the function in as well?

Can confirm! After making the same change in both autocompleter.js (ln 495) and widgetDefaults.js (ln 271) I am now able to load the Custom Autocomplete Words menu again.

Thanks, i've updated the broken bits now!


Add x-ms-request-id to perf telemetry logging

This PR:

Allows retrieval of x-ms-request-id (ESTS request ID) from server response headers to be added to AuthenticationResult as requestId
These request IDs are then added to existing performance telemetry in msal-browser

Codecov Report

Merging #5244 (fa3f0d8) into dev (1e544dc) will not change coverage.
The diff coverage is 92.85%.

Flag
Coverage Δ

*Carryforward flag

msal-angular
96.50% <ø> (ø)

msal-browser
86.94% <100.00%> (ø)

Carriedforward from 1e544dc

msal-common
85.47% <90.00%> (ø)

Carriedforward from 1e544dc

msal-core
82.84% <ø> (ø)

Carriedforward from 1e544dc

msal-node
83.09% <ø> (ø)

msal-node-extensions
76.03% <ø> (ø)

Carriedforward from 1e544dc

msal-react
94.50% <ø> (ø)

node-token-validation
88.88% <ø> (ø)

*This pull request uses carry forward flags. Click here to find out more.

Impacted Files
Coverage Δ

.../src/interaction_client/NativeInteractionClient.ts
72.94% <ø> (ø)

...owser/src/interaction_client/SilentIframeClient.ts
96.49% <ø> (ø)

...wser/src/interaction_client/SilentRefreshClient.ts
100.00% <ø> (ø)

...mmon/src/telemetry/performance/PerformanceEvent.ts
100.00% <ø> (ø)

lib/msal-common/src/response/ResponseHandler.ts
73.04% <50.00%> (ø)

lib/msal-browser/src/app/ClientApplication.ts
94.97% <100.00%> (ø)

...ib/msal-browser/src/app/PublicClientApplication.ts
100.00% <100.00%> (ø)

.../msal-common/src/client/AuthorizationCodeClient.ts
79.12% <100.00%> (ø)

lib/msal-common/src/client/RefreshTokenClient.ts
65.09% <100.00%> (ø)

lib/msal-common/src/utils/Constants.ts
100.00% <100.00%> (ø)

... and 9 more

Tests?

Tests?

Yes! Added.

Tests?

Yes! Added.

Can you also add an assertion to this test for requestId? https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/test/app/PublicClientApplication.spec.ts#L2633

Can you also add an assertion to this test for requestId? https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/test/app/PublicClientApplication.spec.ts#L2633

Done!


Saw a non-null label issue

Thank you for this excellent example. I am trying to  implement my model which is similar to this with the tensorflow 1.2. But there is something wrong:
InvalidArgumentError (see above for traceback): Saw a non-null label (index >= num_classes - 1) following a null label, batch: 0 num_classes: 218 labels: 58,191,215,196
[[Node: loss/CTCLoss = CTCLoss[ctc_merge_repeated=true, ignore_longer_outputs_than_inputs=false, preprocess_collapse_repeated=false, _device="/job:localhost/replica:0/task:0/cpu:0"](fc/transpose/_163, _arg_Placeholder_3_0_3, _arg_Placeholder_2_0_2, _arg_Placeholder_4_0_4)]]
[[Node: loss/CTCLoss/_165 = _Recvclient_terminated=false, recv_device="/job:localhost/replica:0/task:0/gpu:0", send_device="/job:localhost/replica:0/task:0/cpu:0", send_device_incarnation=1, tensor_name="edge_4527_loss/CTCLoss", tensor_type=DT_FLOAT, _device="/job:localhost/replica:0/task:0/gpu:0"]]
This is my code:
graph = tf.Graph()
with graph.as_default():
# feature inputs e.g. fbank, MFCC
# size : [batch_size, timesteps, feature_dim]
inputs = tf.placeholder(tf.float32, [None, None, FLAGS.n_mfcc])
    # use sparse_placeholder to generate a SparseTensor required by ctc_loss op
    targets = tf.sparse_placeholder(tf.int32, [None])
   .....
    # Time major
    logits = tf.transpose(logits, (1, 0, 2))
    tf.summary.histogram('fc', W)
    tf.summary.histogram('fc', b)

    with tf.name_scope('loss'):
        loss = tf.nn.ctc_loss(targets, logits, seq_len)

    with tf.name_scope('cost'):
        cost = tf.reduce_mean(loss)

....
for i, batch in
enumerate(datagen.iterate_train(FLAGS.batch_size, shuffle=shuffle,
sort_by_duration=sortagrad)):
train_inputs = batch['x']
train_targets = sparse_tuple_from(batch['y'])
train_seq_len = batch['label_lengths']
            feed = {inputs: train_inputs,
                    targets: train_targets,
                    seq_len: train_seq_len}
            batch_cost, _ = session.run([cost, optimizer], feed)
            train_cost += batch_cost*FLAGS.batch_size
            train_ler += session.run(ler, feed_dict=feed)*FLAGS.batch_size

The labels seems to be considered as one label together, how can I fix this issue?
Many thanks.

sorry, it is some foolish mistake. i will close the issue.


authentication in ssr (queryLoad)

How do i authenticate requests on the server side in sveltekit´s load function?
Using the setHeaders method overrides the global headers so parallel requests may be incorrectly authenticated.
// src/routes/__layout.svelte
export const load: Load = async ({ session, fetch }) => {

	kitQLClient.setHeaders(
		session.token ? { Authorization: `Bearer ${session.token}` : {}
	);

	await sleep(3000);

	console.log(kitQLClient.getHeaders());

	return {};
};

When two clients connect within 3 seconds and only one is logged in, the second requests authentication state is used for the first request aswell.

Thanks for pointing this out.
You would like to set headers per request? as extra settings?

I´m not sure whats the best idea, per request headers would solve the problem but then you have to add that bit of code in every load function. I usually provide a function via stuff and set the headers in the root layout.
// src/routes/__layout.svelte
export const load: Load = async ({ session, fetch }) => {
	return {
		stuff: {
			queryLoad: createKitQLQueryLoad({
				fetch,
				headers: {
					Authorization: `Bearer ${session.token}`
				}
			})
		}
	};
};

// src/routes/index.svelte
export const load: Load = async ({ stuff: { queryLoad }} ) => {
	await queryLoad(KQL_MyQuery);

	return {};
};

I don't really like to rely on stuff.
I thought that you wanted to have a different session.token depending on the query you are doing (KQL_MyQueryA or KQL_MyQueryB).
But if you have the same session.token, it should work already?
Maybe I don't get:

When two clients connect within 3 seconds and only one is logged in, the second requests authentication state is used for the first request aswell.

I guess that you added await sleep(3000); to emphasize the issue, right?

I dont like it neither, but it does the job in my case.
On the server side, kitQL creates a global Client Instance which is therefore used for every request. If i make changes to the headers to make authenticated request for a specific user, other users may be incorrectly authenticated as that user.
I´ve added the delay to simulate some requests that may take a while to complete.

Incoming first request
First request sets the clients headers
First request is fetching some data
Incoming second request
Second request sets the clients headers
-> at this point every new request is using the headers from the second request
First request is fetching some other data, but sends the headers from the second request

Hopefully this is easier to understand. Otherwise i can create a repro

Thx for your detailed comment.
I'll have a look at how to solve this in a nice way.

Hi - think I will love this fw - definitely an accelerator.
If I may, I am also quite confused as to how to enable access control. maybe a dedicated page in the document could help.
my 2c

@david-plugge Out of curiosity, can you share your implementation of the getSession hook? I assume you have that going so you can populate session info?

@nikfp i´m using supabase and get the user from a cookie, store that data in locals and polulate it to the session. Nothing special :)

Maybe this can help as well: https://github.com/jycouet/supabase-graphql-example/blob/main/examples/sveltekit

Thats definately a nice and clean setup.
But it doesnt cover authenticated request in load or am i missing something?
The authorization header is set in the root layout, but that code runs after every load function is called as far as i know.

The supabase team published auth-helpers for sveltekit
https://github.com/supabase-community/supabase-auth-helpers/blob/next/packages/sveltekit/README.md

Having exactly the same need here. Looking forward to a solution. KitQL is neat!

Maybe instead of importing kitQLClient as a singleton, changing it to a factory could work?

@ymc9 As of now, the way the KQLClient is initialized and then imported into the stores file, it will hard code the values provided into the client when the client is resolved in the stores file. A factory might not behave the way you are expecting, or at least might be a headache as some queries will resolve dependencies on Node and some on the browser. (I might test this though, I'm curious to see what happens)
HOWEVER, in digging through the source file for the KQLClient another time, it looks like there might be a another way. You gave me an idea on passing info through the request chain instead.
To start, we would extend the RequestParameters object type to accept a headers object.
export declare type RequestParameters<V> = {
  fetch?: typeof fetch;
  variables?: V;
  headers?: {[key: string]: string};
};

This type gets exported and picked up in the generated stores, so type safety would flow through as expected. Then each store query calls the request method of the KQLClient, so we just extend the input args with a headers type:
public async request<D, V>({
  skFetch,
  document,
  variables,
  operationName,
  operationType,
  browser,
  perRequestHeaders // note new input, should be optional
}): Promise<ResponseResult<D, V>> {

  // setup code before request

  try {

    // Build headers object to send with request
    // Per-Request headers will overwrite existing headers during merge
    const sendHeaders = perRequestHeaders ? {...this.headers, ...perRequestHeaders} : {...this.headers}

    const res = await fetchToUse(this.url, {
      method: 'POST',
      credentials: this.credentials,
      // use the built headers
      headers: { ...sendHeaders, 'Content-Type': this.headersContentType },
      body: JSON.stringify({
        query: print(document),
        variables
      })
    });

    // remainder of request logic

  } catch (errors) {
    dataToReturn.errors = [errors];
    return dataToReturn;
  }
}

This could satisfy the needs of the OP and still keep the default values set in the class creation for future use.
This would mean some tinkering with the way the stores are generated and with the KQLClient code, but it appears that it would work. Before I do anything like a PR though I'd like to hear from @jycouet as he might have already solved this, so my idea might be moot.

Thx a lot for all your comments.
Nice to see people involved 👍
I would suggest to not start a PR about this right now as a lot of things

Sorry, I leave it open for now to keep track of it 😁
(working from my phone right now)

Is it related to this?
https://github.com/HoudiniGraphql/houdini/pull/291

Yes @orefalo 👍
Add we have to explain a bit the work flow we have in mind 😉

Bien!
Now I connect the dots.
I was researching another good lib for svelte+gql and found houdini. Was surprise to see a pull req with your name on it.
Looking forward to it.
Sincerely,

I'm excited to see how this plays out. I was about to start working on a testing workflow for KitQL and try to get the loading states integrated with Storybook as mocks, but now that I know things are changing for the better I'll hold off. Looks like the Houdini PR has almost 100 commits since last Friday between just 2 authors, you fols have been busy!

It took time, but it finally happened 🥳
Check out the Announcement here

Basically, you can do what you want, before and after the fetch (server-side or client-side)
Here is an example 👇
import type { RequestHandlerArgs } from '$houdini';
import { HoudiniClient } from '$houdini';
import { stry } from '@kitql/helper';

// For Query & Mutation
async function fetchQuery({
  fetch,
  text = '',
  variables = {},
  session,
  metadata
}: RequestHandlerArgs) {
  // Prepare the request
  const url = import.meta.env.VITE_GRAPHQL_ENDPOINT || 'http://localhost:4000/graphql';

  // regular fetch (Server & Client)
  const result = await fetch(url, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${session?.token}` // session usage example
    },
    body: JSON.stringify({
      query: text,
      variables
    })
  });

  // return the result as a JSON object to Houdini
  const json = await result.json();

  // metadata usage example
  if (metadata?.logResult === true) {
    console.info(stry(json, 0));
  }

  return json;
}

// Export the Houdini client
export const houdiniClient = new HoudiniClient(fetchQuery);

Enjoy 🎉


Feature: Clickable map

May be cool to make the map clickable
On click: it open the map with all the names

Can you elaborate? @Mylloon

It's a neat, over complicated and yeah not all that useful idea.
It may also contain location and useful links.
Personally I have no interest in implementing this feature, I will accept PRs tho!
I will close this issue for now.


🐛 Bug Report: Unable to read URL

📜 Description
When trying to register existing API
👍 Expected behavior
Register the API
👎 Actual Behavior with Screenshots
Error

👟 Reproduction steps
API -> Register Existing API -> Enter valid github URL - > click Analyze
📃 Provide the context for the Bug.
Trying to test locally, followed the documentation to set up github integration
🖥 Your Environment
Development
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

Does the URL you're using match the example to the right under "Link to an existing entity file"? It's looking quite short

Closing the issue, its due to a configuration issue. thanks.

Hey @VJ1243 , can you update how you resolved this error? Thanks.


Add weather filter option to the menu

Let the user choose kind of weather.
by default all options should be checked.
See the Mockup below for more details.

@omerxx
@LironRS

As for #330, the filter lists should be expandable

Done in #412