API for core data /event/device/{deviceId}/{limit}: does not work with deviceId but deviceName

I've found another documentation issue with the core-data.raml: It reads /event/device/{deviceId}/{limit}:  but actually should be /event/device/{deviceName}/{limit}:  as it works ONLY with deviceName and NOT with deviceID.
As mentioned to @jpwhitemn in rocket chat: https://chat.edgexfoundry.org/channel/general?msg=QP33tpNs5YCqkA5xh

The API and documentation are correct.  The API allows for the device name or the device id to be used to get the data for the Event collection - whichever is used by the device service to report the event/reading.  In other words, one or the other can be used, but not both.  In the case of the virtual device service, it reports its reading via the device name.  Therefore the event/readings are available via core data by the event name.  Since Core Data does not have information about both the name and id, it uses what is provided in the event/reading to filter the data.  A future version of the service may want to implement a query first to Metadata on the id or name provided through the request and determine which to use to query the database.


Place of communication

I remember there were GitHub discussions before, but now there is no place for communication. I want to know more about rivet and provide some contributions, but there is no communication channel

reopened: https://github.com/rivet-lang/rivet/discussions

reopened: https://github.com/rivet-lang/rivet/discussions

fantastic


3D Touch / Force Touch to directly connect to servers

mashREPL can be already called directly from Home Screen. It would be neat if same would be possible with other items such as ssh connections…

Good idea 👍
Yes I can implement an option inside each connection as "Quick connect" in order to add items to Home Screen Quick Actions.
I'm planning this issue.

This is off-topic but how do I support using TestFlight? Purchases are disabled there…

@akuropka You could :

Re-install the App Store release (you won't loose any data)
Make the purchase
Re-install the TestFlight release (you won't loose any data)

Then you will be able to use your purchase inside the TestFlight release.

You can purchase it when :

You add more than one connection (a popup ask you to purchase)
You go to WebSSH Settings (top left gear icon) and choose "In-App Purchases"

If none of these options work then you already have the "PRO" purchase.
Does it help you?

Sadly, both don’t work and I’m pretty sure I did not purchase anything yet since the app did not work for me due to the problem with Duo 2FA.
I‘m open to any other option…

Strange 🧐
I will call it a "bug" so 😅
Your feedbacks and issues will reward me more than you think 🙏

Hello @akuropka 👋
I'm closing this issue because I've published 25.8 : https://github.com/isontheline/pro.webssh.net/issues/1082
Available on TestFlight :
https://testflight.apple.com/join/QSrBK59z

Hi @isontheline, thank you very much. 👋


Add DAWON battery gas valve

Add fingerprint of device following standard ZigBee valve protocol.
DAWON DNS Gas Valve

manufacturer
DAWON_DNS

model
SG-V100-ZB

powerSource
battery

https://pmshop.co.kr/product/iot-스마트-가스락-가스차단기/122/

Hi @junmo-kim
Is this PR for the WWST certification?

No this is only PR for replace internal DTH to Edge Driver device I have.
I have no representation of Dawon.
If this kind of PR is inappropriate, please close.
Sorry for disturbing.
2023년 3월 2일 (목) 오후 12:43, Kwang-Hui @.***>님이 작성:

Hi @junmo-kim https://github.com/junmo-kim
Is this PR for the WWST certification?
—
Reply to this email directly, view it on GitHub
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/pull/526#issuecomment-1451252550,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMK3WGDFR2J5R7YPTJL22DW2AJNLANCNFSM6AAAAAAUOALGGQ
.
You are receiving this because you were mentioned.Message ID:
@.***
com>


Split React rendering of KPIs to each individual box.

Splitting the rendering of the #kpi to each individual kpi-${type} seems to remove the wobble and flicker.

👍


Most *W instructions don't have sufficient justification

One of the frequently asked questions listed in the document is:

Do we really need all the *W opcodes for 32 bit ops on RV64?

In my opinion, the only *W instructions in the B extension that might have significant value are the rotate instructions, RORW, ROLW, RORIW, and maybe PACKW.  To help decide, the document proposes running "proper experiments with compilers that support those instructions".  That would be ideal of course, but I'm skeptical the community will wait on the B extension long enough for that to happen.  (Plus it's not exactly easy to set up unbiased experiments for these kinds of specialized features.)
In the meantime, I'd like to point out that most of the proposed *W instructions can be substituted by a sequence of only 2 or 3 other instructions.  The following are believed to be equivalent sequences (not always unique):
CLZW rd,rs
SLOI rd,rs,32
CLZ rd,rd

CTZW rd,rs
LI temp,-1
PACK rd,temp,rs
CTZ rd,rd

PCNTW rd,rs
PACK rd,zero,rs
PCNT rd,rd

SLOIW rd,rs1,i
SLOI rd,rs1,i
SEXT.W rd,rd

SLOW rd,rs1,rs2
ANDI temp,rs2,31
SLO rd,rs1,temp
SEXT.W rd,rd

SROIW rd,rs1,i
If i > 0:
SLLI rd,rs1,32
SROI rd,rd,(i+32)

If i = 0:
SEXT.W rd.rs1

SROW rd,rs1,rs2
NOT temp,rs1
SRLW rd,temp,rs2
NOT rd,rd

GREVIW rd,rs1,i
GREVI rd,rs1,i
SEXT.W rd,rd

GREVW rd,rs1,rs2
ANDI temp,rs2,31
GREV rd,rs1,temp
SEXT.W rd,rd

SHFLIW rd,rs1,i
SHFLI rd,rs1,i
SEXT.W rd,rd

SHFLW rd,rs1,rs2
ANDI temp,rs2,15
SHFL rd,rs1,temp
SEXT.W rd,rd

UNSHFLIW rd,rs1,i
UNSHFLI rd,rs1,i
SEXT.W rd,rd

UNSHFLW rd,rs1,rs2
ANDI temp,rs2,15
UNSHFL rd,rs1,temp
SEXT.W rd,rd

BEXTW rd,rs1,rs2
If rs2 is a known constant, rs2[63:32] = 0, and at least one bit in rs2[31:0] is a zero (very likely):
BEXT rd,rs1,rs2

If rs2 is a known constant, rs2[63:32] != 0 (unlikely), and at least one bit in rs2[31:0] is a zero:
PACK temp,zero,rs2
BEXT rd,rs1,temp

If rs2 is a known constant and rs2[31:0] = 0xFFFFFFFF (unlikely):
SEXT.W rd,rs1

If rs2 is not a known constant:
PACK temp,zero,rs2
BEXT rd,rs1,temp
SEXT.W rd,rd

BDEPW rd,rs1,rs2
If rs2 is a known constant and rs2[63:31] = 0:
BDEP rd,rs1,rs2

Else:
BDEP rd,rs1,rs2
SEXT.W rd,rd

CLMULW rd,rs1,rs2
CLMUL rd,rs1,rs2
SEXT.W rd,rd

FSLW rd,rs1,rs2,rs3
PACK rd,rs3,rs1
FSL rd,rd,rs2,rd
SEXT.W rd,rd

FSRW rd,rs1,rs2,rs3
PACK rd,rs1,rs3
FSR rd,rd,rs2,rd
SEXT.W rd,rd

Note that a final SEXT.W rd,rd can be eliminated if the rd result is known to be used only in subsequent 32-bit operations (such as SW or other *W instructions).  Other optimizing tweaks are also possible, depending on the circumstance.
Unless the proposed *W instructions can be shown to be much more prevelant than I expect, the combination of rare utility plus relatively easy synthesis from other instructions argues strongly for dropping them.
The document also says:

But they add very little complexity to the core. So the only question is if it is worth the encoding space.

While "very little complexity" may be true, I disagree that it should be dismissed and only encoding space considered.  "Very little complexity" certainly lowers the threshold of utility an instruction must demonstrate to be acceptable, but it doesn't make the instruction free to add.  There are many other possible instructions of very little complexity that we so far choose to exclude, and these *W instructions perhaps should be among them.
For instance, there's a whole category of instructions that would have more impact but aren't currently included, and that is the unsigned equivalents of the existing RV64I *W instructions:  ADDWU, SUBWU, SLLWU, etc.  These would be just like the existing *W instructions but instead zeroing the upper 32 bits, as appropriate for an unsigned int or uint32_t result type rather than int or int32_t.  We hardly need to run any experiments to know that such *WU instructions would be used far more frequently than the *W instructions proposed for the B extension.

Hi John.

To help decide, the document proposes running "proper experiments with compilers that support those instructions". That would be ideal of course, but I'm skeptical the community will wait on the B extension long enough for that to happen.

The community will need to wait for this anyway because this determines other decisions about what to include in the B extension as well.
On the contrary, to rush out a final B-extension spec before we even have compiler support and evaluation results would be very reckless.

In the meantime, I'd like to point out that most of the proposed *W instructions can be substituted by a sequence of only 2 or 3 other instructions.

This is the case for most *W instructions and is completely missing the point of *W instructions.
If you have 32-bit code it would be completely unacceptable if it would run 2-3x faster on RV32 than on RV64. The *W instructions must be seen as a whole under this objective, not as individual instructions.
Another aspects of *W is that multi-cycle operations could be faster if the core already knows its only a 32-bit operation. Examples would be MULW, BEXTW, BDEPW.
In many of the cases you have listed, the extra effort in the instruction decoder to blacklist those *W instructions in the instruction decoder would be larger than the extra effort to implement the *W instructions.
For example, the ALU hardware cost for having FSLW/FSRW when you already have FSL/FSR/ROLW/RORW is one extra ANDNOT gate. https://github.com/riscv/riscv-bitmanip/blob/master/verilog/shifter64.v#L51 Obviously the decoder cost for blacklisting it would be larger.
Finally, the *W instructions can also be used to reduce power by clock-gating half of the data path. This would even work with non-W instructions as long as they have the invariant that 32-bit sign-extended inputs will produce 32-bit sign-extended outputs. For this, one would simply tag all 32-bit sign-extended values in the register file. But that requires that all instructions that do not have this invariant have a *W variant. That was the main criteria used to determine which instructions should have a *W variant. The only exception to that rule is that there is no CLMULHW, like there's also no MULHW.

While "very little complexity" may be true, I disagree that it should be dismissed and only encoding space considered. "Very little complexity" certainly lowers the threshold of utility an instruction must demonstrate to be acceptable, but it doesn't make the instruction free to add.

As I have said, in many of the cases you have mentioned it would even require more hardware to blacklist those instructions.
I mean look at your own code:

ANDI temp,rs2,15
SHFL rd,rs1,temp
SEXT.W rd,rd

The overhead for SHFL/SHFLW is ONE SINGLE EXTRA GATE!  The only thing required is masking the upper bit of the argument. (Sign-extending the result of *W operations can be done based on the major opcode alone. No per-instruction overhead here.)
Clearly the extra effort to blacklist this instruction in the decoder would be larger than one single extra gate!
And for SHFLIW:
SHFLI rd,rs1,i
SEXT.W rd,rd
That's just free. It costs you nothing. If you have any *W operations then you already have the MUXes for the sign-extend, driven by the major opcode. All that blacklisting SHFLIW would do is driving up the cost and complexity of the instruction decoder.

Unless the proposed *W instructions can be shown to be much more prevelant than I expect, the combination of rare utility plus relatively easy synthesis from other instructions argues strongly for dropping them.

A few paragraphs above you dismissed the idea of such an evaluation because as you said "I'm skeptical the community will wait on the B extension long enough for that to happen".
We need to implement those things in hardware and compilers and then measure. This is the current roadmap. You can't say both, that those instructions must prove themselves in such an evaluation, and that we don't have time to conduct that evaluation.

While "very little complexity" may be true, I disagree that it should be dismissed and only encoding space considered.

Yet you are arguing against collecting more data and for dropping them now based on your suspicions on how commonly they are used and what the hardware cost of those instructions would be? That's not a very convincing argument.

For instance, there's a whole category of instructions that would have more impact but aren't currently included, and that is the unsigned equivalents of the existing RV64I *W instructions: ADDWU, SUBWU, SLLWU, etc.

Now you are just silly. You are proposing to spend TWO MAJOR OPCODES on nothing else than unsigned versions of the *W instructions? You realize that this would be 66% of the remaining reserved major opcodes, yes?

If you have 32-bit code it would be completely unacceptable if it would run 2-3x faster on RV32 than on RV64.

I'm not certain what you mean by "32-bit code" here.  RV32 code won't run directly on an RV64 machine.  You may be imagining code that uses 32-bit integer types and 32-bit "intrinsics", such as __builtin_shfl, as opposed to the 64-bit "long" version, presumably __builtin_shfll.  The glitch in that argument is that 32-bit unsigned int can be as likely to appear as int, and then the *W instructions aren't the right ones, because they sign-extend instead of zero-extend.  So you end up with extra instructions to account for the difference, and the 32-bit code again runs slower---in the worst case, maybe 2x slower---on RV64 than on RV32, even though we called that "completely unacceptable".
Ideally, 64-bit machines would be running code written for them, as that may even double the performance for some of these bit-manipulation applications.  I'm personally more interested in that case than the question of how fast 32-bit code runs on RV64.

In many of the cases you have listed, the extra effort in the instruction decoder to blacklist those *W instructions in the instruction decoder would be larger than the extra effort to implement the *W instructions.

That's not as definite as you make it sound.  It depends on the implementation.

(Sign-extending the result of *W operations can be done based on the major opcode alone. No per-instruction overhead here.)

Only when the implementations of the B instructions in question share part of their pipeline path with other *W instructions.  You may be assuming that would always be true, but it isn't necessarily.

And for SHFLIW:
SHFLI rd,rs1,i
SEXT.W rd,rd
That's just free. It costs you nothing. If you have any *W operations then you already have the MUXes for the sign-extend, driven by the major opcode.

Again, you're assuming that the implementations of those different instructions converge in the pipeline.  For many implementations, that will happen naturally, but it isn't necessarily true.

A few paragraphs above you dismissed the idea of such an evaluation because as you said "I'm skeptical the community will wait on the B extension long enough for that to happen".
We need to implement those things in hardware and compilers and then measure. This is the current roadmap. You can't say both, that those instructions must prove themselves in such an evaluation, and that we don't have time to conduct that evaluation.

Please correct me if I'm wrong, but I can't see how compiling generic, standard C code is going to produce many of these bit-manipulation instructions automatically, where the compiler matches source code patterns to produce BEXT, SHFL, etc.  Instead, it seems to me, the sort of source code that will use these instructions will depend heavily on intrinsics, like __builtin_clz, __builtin_popcount, and, presumably, __builtin_bext, etc.  In that environment, where the intrinsics and the machine instructions are more-or-less one-to-one, the usage numbers you get will be strongly biased by the source code examples you choose.
If you want to "prove" that BEXT is the most important instruction, just make sure all your code examples use __builtin_bext frequently.  You can then measure the frequency of use, and pretend it's all very scientific, but those numbers will be highly tainted by the original selection of the input samples.
What I meant was, I expect that figuring out some way to perform a set of reasonably unbiased experiments would take several years, if it's even possible at all, and, no, I don't think the community really wants to wait that long.  If you have some better way to gather data than what I described, I'd be happy to hear of it.

For instance, there's a whole category of instructions that would have more impact but aren't currently included, and that is the unsigned equivalents of the existing RV64I *W instructions: ADDWU, SUBWU, SLLWU, etc.

Now you are just silly. You are proposing to spend TWO MAJOR OPCODES on nothing else than unsigned versions of the *W instructions? You realize that this would be 66% of the remaining reserved major opcodes, yes?

First off, I was only pointing out that they would be more useful, and more often used, than the *W instructions you feel are so necessary.
Secondly, you are incorrect.  There is existing room in the OP-IMM-32 and OP-32 groups for encoding such *WU instructions, if a decision were made to adopt them.  No additional major opcodes need to be allocated.
I'm willing to accept pushback and engage in debate on these matters, but I was disappointed that you closed this issue so swiftly, before anyone else might comment.  I think it would be better, after providing your reasons for rejecting, if you left issues open for a little longer, so others might see and have an opportunity to correct anything that might need correcting.

I'm not certain what you mean by "32-bit code" here.

For example code using uint32_t. That's literally the whole motivation for having the *W instructions. So I would have assumed it is clear from the context.
And I feel like you simply disagree with the general RISC-V design decision to have *W instructions in the first place, but the B extension is hardly the right place to "fix" this decision.

The glitch in that argument is that 32-bit unsigned int can be as likely to appear as int, and then the *W instructions aren't the right ones, because they sign-extend instead of zero-extend. So you end up with extra instructions to account for the difference, and the 32-bit code again runs slower---in the worst case, maybe 2x slower---on RV64 than on RV32, even though we called that "completely unacceptable".

That's just plain wrong.
The idea behind *W instructions is simply that they operate on the lower 32 bits. It makes sense to have a consistent scheme for how to fill the upper bits, but it doesn't matter much what this scheme is exactly, if that scheme is sign-extend or zero-extend.
In fact, the code most benefiting from *W is code using uint32_t, not code using int32_t, because in C a signed int overflow is undefined but an unsigned overflow is defined. So you can just use 64-bit ops on an int32_t but for uint32_t you need *W instructions.

That's not as definite as you make it sound. It depends on the implementation.

Well, yes, but if you follow this argument all the way to the end you'd have to conclude we can't know anything and therefore can't make an informed decision either way. But that doesn't sound very productive.
So why not instead make some sane assumptions and look at the obvious ways of implementing this across a range of differently sized cores. Or implement it and measure. We are going to do the latter one and afaict what I said is broadly true for the former one.

Please correct me if I'm wrong, but I can't see how compiling generic, standard C code is going to produce many of these bit-manipulation instructions automatically

That depends on the instruction. Rotate shifts for example are something I'd absolutely expect a C compiler to infer. Same with SLO/SRO. Funnel shifts as well.
I don't expect a C compiler to compile generic code into GREV/SHFL/UNSFL but there are code patterns that match well to instruction sequences utilizing GREVI/SHFLI/UNSHFLI, especially BSWAP (GREVI -8) and BREV (GREV -1). Most compiler can already generate code using BSWAP.
There are things that could theoretically map well to certain sequences using BEXT/BDEP but most compiler's don't use them yet. But Intel and AMD only added their BEXT/BDEP equivalent a few years ago, so just give compilers a little more time to catch up.

Again, you're assuming that the implementations of those different instructions converge in the pipeline. For many implementations, that will happen naturally, but it isn't necessarily true.

But it makes sense to optimize for the case we are expecting, not for the case we are not expecting.
If removing functionality makes the implementations we expect more complex, I don't see how it makes sense to remove that functionality. Especially if it's only a few extra gates for the implementations we don't expect.

Instead, it seems to me, the sort of source code that will use these instructions will depend heavily on intrinsics, like __builtin_clz, __builtin_popcount

Note that __builtin_clz and __builtin_popcount both operate on 32-bit integers when using the RV64 calling convention. So they map directly to CLZW, PCNTW.
You'd have to use __builtin_clzl and __builtin_popcountl for the 64-bit version.
So all the existing code using __builtin_clz and __builtin_popcount will be sped up by the existence of CLZW and PCNTW.

and, presumably, __builtin_bext, etc.

Currently GCC has intrinsics __builtin_ia32_pext_si, __builtin_ia32_pext_di, __builtin_ia32_pdep_si, and __builtin_ia32_pdep_di. <x86intrin.h> provides wrappers _pext_u32, _pext_u64, _pdep_u32, and _pdep_u64.
Yes, I think it would sense to introduce architecture-independent intrinsics for these operations. I would assume this will happen when RISC-V also has instructions with this semantic.

If you want to "prove" that BEXT is the most important instruction, just make sure all your code examples use __builtin_bext frequently. You can then measure the frequency of use, and pretend it's all very scientific, but those numbers will be highly tainted by the original selection of the input samples.

Obviously we wouldn't measure the frequency of use as even a high frequency of use wouldn't tell us if the instruction is any good.
The relevant metrics are runtime speedup and code size reduction. Even if you hand-optimize an example to use something like BEXT/BDEP. If that leads to runtime speedup and/or code size reduction then this demonstrates the usefulness of the instruction in this context.
As with any microbenchmark this leaves the question open how relevant the example is for a larger code base. That's why we also need to do things like measure CRC/CLMUL instructions "in vivo" for stuff like the decompression and CRC checking code used in the Linux kernel startup.

First off, I was only pointing out that they would be more useful, and more often used, than the *W instructions you feel are so necessary.

I think you still haven't understood what the *W instructions are actually for.
They are for operating on the lower 32-bit of your 64-bit values. How you pad the results to 64-bit is not relevant for the intended use case.
Regarding the "the *W instructions you feel are so necessary" bit: I think you should take this discussion to Andrew. It looks like you simply have a fundamental issue with the existence of *W instructions in RV64. And that has nothing to do with the B extension.

Secondly, you are incorrect. There is existing room in the OP-IMM-32 and OP-32 groups for encoding such *WU instructions, if a decision were made to adopt them. No additional major opcodes need to be allocated.

The whole idea of the OP-IMM-32 and OP-32 major opcodes is that they are mirror images of OP-IMM and OP to simplify instruction decoders.
So the only space "left" in OP-IMM-32 and OP-32 are opcodes that correspond to OP-IMM/OP instructions that do not have a *W variant. And that's not a lot of free space.
But again. This is a conversation you should be having with Andrew. and it doesn't seem to have anything to do with the B extension. You seem seem to not like having *W instructions, and/or prefer *WU instructions. There is nothing the B extension could do about that.

I'm willing to accept pushback and engage in debate on these matters, but I was disappointed that you closed this issue so swiftly, before anyone else might comment.

I did re-open the issue.

I agree with @cliffordwolf. If you use an LP64 model then you need to make sure all the code out there that uses int or unsigned int runs well on a 64 bit CPU.
As pointed out, functions such as __builtin_popcount() take unsigned int, not unsigned long int.
If you provide *W operations you have to decide what to do with the upper bits. You can leave then alone (x86), zero extend them (Aarch64), or sign extend them (RISC-V). If you leave them alone then casting a 32 bit value to a 64 bit value requires a sext or zext every time. If you sign extend them then only unsigned values require a zext, signed ones are already correct. If you zero extend them then only signed values require a sext, unsigned ones are already correct. It's hard to say which is better. Most normal application code uses signed more than unsigned, favouring sign extension, and this also means you don't need special 32 bit compare (or compare and branch) instructions as the 64 bit instructions produce the correct result for both signed and unsigned 32 bit values.
It's a bit unfortunate that Aarch64 and RISC-V picked opposite answers. If they weren't being designed effectively at the same time (Aarch64 was designed first, but in secret, and announced after RISC-V) that might not have happened. It's not terribly important except in micro-benchmarks, where it's pretty much luck of the draw (or design) which one is favoured.
It's also a bit unfortunate that in the base instruction set RISC-V needs two instructions to zero-extend. These are an obvious choice for a macro-op fusion pair, and also the proposed PACK instruction can be used as a zero-extend.
Needing an extra instruction when unsigned is cast to unsigned long is unfortunate. Needing one or two extra instructions any time anything at all is done with 32 bit variables is, yes, unacceptable.

The decision should be framed by the criteria mentioned in section 1.1 of the Bitmanip draft.
Architecture consistency: Not having *W would be inconsistent with the architecture.  As far as I can tell, every instruction in the base architecture has a W equivalent (either as a new W instruction or, assuming all other *W instructions sign-extend the result, using an existing instruction).
Threshold metric: It depends on the exact threshold but at least some of the B extension's proposed W instructions don't meet the heuristic threshold.  But many W instructions in the base architecture also don't meet this metric (or the architecture's "small base integer ISA" goal).  Most of them can use the 64-bit instruction and then SEXT.W.  The decision was made that having the *W instructions across the board (architectural consistency) is more important than having fewer instructions.
Data-driven value: The FAQ says that *W will be taken out if there is no data.  The data-driven value criterion suggests that they shouldn't be added until there is data.  Or maybe the data-driven value criterion only applies to having the basic instruction plus the W variant, not each independently.  If that's the case then each instruction has already met the data-driven value test.
Hardware simplicity: It seems relatively simple either way.  Requiring an extra gate to remove *W doesn't seem that important but requiring several extra gates on some implementation that has a whole separate datapath (which itself adds far more gates) also doesn't seem that important.
Compiler support: This would seem to be either neutral or favor having *W.
For consistency, I think that it makes sense to keep the *W instructions regardless of whether there's data that they each individually have merit.  (Unless, of course, any of them is equivalent to a single other instruction.  That's why there's already no andcw or minw.)

"Data-driven value: The FAQ says that *W will be taken out if there is no data. The data-driven value criterion suggests that they shouldn't be added until there is data."
If you don't include something in the set of what you'll gather data on, then you'll never have the data to decide whether it should be in the set of things in the eventual standard extension.
I agree that *W versions don't have to justify themselves. We do, as a matter of consistency, have *W instructions. The 32 bit and 64 bit version should be evaluated together.

I'd like to thank everyone who has commented.
I wrote:

The glitch in that argument is that 32-bit unsigned int can be as likely to appear as int, and then the *W instructions aren't the right ones, because they sign-extend instead of zero-extend. So you end up with extra instructions to account for the difference, and the 32-bit code again runs slower---in the worst case, maybe 2x slower---on RV64 than on RV32, even though we called that "completely unacceptable".

Someone has since pointed me to a comment in the ISA specification's chapter for base RV64I:

The compiler and calling convention maintain an invariant that all 32-bit values are held in a sign-extended format in 64-bit registers.  Even 32-bit unsigned integers extend bit 31 into bits 63 through 32.

I saw this many months ago and since forgot about it, since I've been working directly with RV32 most of the time.  Based on past experience, I automatically expected that signed 32-bit values needed to be sign-extended to 64 bits and unsigned 32-bit values zero-extended to 64 bits, so that the 64-bit values in the registers would match the intended 32-bit values.  Under that mistaken assumption, the *W instructions wouldn't do the right thing for unsigned int and uint32_t.  Since the unsigned types could reasonably be expected to predominate over signed int and int32_t for the data that B instructions operate on, I couldn't see a good justification for providing hardware specially for the sign-extension case only.
Now that I've been corrected, it's easier for me to accept the *W versions of the B instructions.  You're right that I'm not entirely comfortable with the convention of sign-extending unsigned values, but I understand that the choice is set in stone now, so we have to work with it.  Sorry that I missed this earlier.
Clifford Wolf wrote:

I think you still haven't understood what the *W instructions are actually for.
They are for operating on the lower 32-bit of your 64-bit values. How you pad the results to 64-bit is not relevant for the intended use case.

While that's an extremely important use case, it's not the only one.  It is common for ordinary 64-bit code to have a mix of 64-bit and 32-bit types, such as long and int, with 32-bit int values commonly participating in 64-bit long or pointer computations.  In such cases, it very much matters how the upper 32 bits get filled, whether with zeros or an extension of the sign.  RISC-V's choice of sign-extension for *W was made deliberately to give preferential support for signed integers, so it's not quite right to say  the choice was arbitrary.
The part I was missing yesterday was the ABI rules that require sign extension of unsigned 32-bit values.  That convention is bad if you want  to use those values in 64-bit arithmetic, but it's good for standardizing on the existing *W instructions.

So the only space "left" in OP-IMM-32 and OP-32 are opcodes that correspond to OP-IMM/OP instructions that do not have a *W variant. And that's not a lot of free space.

You might want to check again.  Excluding SLT, SLTU, XOR, OR, and AND leaves more than half the space open.

I did re-open the issue.

And I appreciate it.

You might want to check again. Excluding SLT, SLTU, XOR, OR, and AND leaves more than half the space open.

That may help in OP-IMM-32 that's already very full and where is not a lot of space for new instructions in OP-IMM.
But, and maybe I misunderstood what you were proposing, there is no guarantee that in the future less than half of the OP instructions will have a *W variant. In fact, look at the M extension for example. It has 8 OP instructions and 5 OP-32 instructions. If you wanted to add *WU instructions for M you would need to use one of the "holes" the base ISA leaves. So if you want to add a *WU instruction for every *W instruction it doesn't matter what percentage of the base ISA instructions leave "holes" in OP-32. The only thing that matters what percentage of all OP instructions, including future ones, will have *W variants.
So what I'm saying is, maybe there's enough concrete free space for *WU instructions in OP-IMM-32 and OP-32 for *WU variants of base ISA instructions. But there surely isn't enough systematic space to add *WU variants of all OP instructions.
Also, as I'v said before, adding *WU instructions in the holes in OP-32 would make a huge mess in any instruction decoder.

So what I'm saying is, maybe there's enough concrete free space for *WU instructions in OP-IMM-32 and OP-32 for *WU variants of base ISA instructions. But there surely isn't enough systematic space to add *WU variants of all OP instructions.

I agree it would be terrible to do such a thing ad hoc, instruction by instruction.  If the Foundation chooses to, one option is to adopt a system like the following that I believe is compatible with all current standard instructions:
instruction bits
25 14 13  6:2

 -  -  0  00100   group A, imm     (ADDI, SLLI, SRLI, ...)
 -  -  1  00100   group B, imm     (SLTI, SLTIU, ORI, ANDI)

 -  -  0  00110   group A, imm, W  (ADDIW, SLLIW, SRLIW, ...)
 -  -  1  00110   group A, imm, WU (ADDIWU, SLLIWU, SRLIWU, ...)

 0  -  0  01100   group A, rs2     (ADD, SLL, SRL, ...)
 0  -  1  01100   group B, rs2     (SLT, SLTU, OR, AND, ...)
 1  0  0  01100   group C, rs2     (MUL, MULH, ...)
 1  0  1  01100   group D, rs2     (MULHSU, MULHU, ...)
 1  1  -  01100   group E, rs2     (DIV, DIVU, ...)

 0  -  0  01110   group A, rs2, W  (ADDW, SLLW, SRLW, ...)
 0  -  1  01110   group A, rs2, WU (ADDWU, SLLWU, SRLWU, ...)
 1  0  0  01110   group C, rs2, W  (MULW, ...)
 1  0  1  01110   group C, rs2, WU (MULWU, ...)
 1  1  -  01110   group E, rs2, W  (DIVW, DIVUW, ...)

The group labels A through E are simply my invention.  As you can see, instructions in groups A and C have encoding space for 32-bit versions, both for sign extension (W) and zero extension (WU).  Instructions in groups B and D have no 32-bit versions, and those in group E can have W versions but not WU versions.  It's not perfect, but any system must navigate around the existing instructions.
To be clear, there would be no change to the existing RV64I base.  Any added *WU instructions would be part of an extension.
Andrew has told me he wants to keep open the option for *WU instructions for now, which implies to me we should devise a system to reserve the encoding space now, even if the idea eventually gets dropped.  I haven't run this particular system by him yet, but I intend to do so soon.
Naturally, we would want any system that's adopted to be fully compatible with the B extension, by tweaking either or both as necessary.  I'll be looking into this question soon.  And now you or anyone else can do so too, if you're so inclined.
But this is getting off-topic for this GitHub issue, so we should move the discussion elsewhere if you'd like to continue.

I agree that there is merit in systematically adding *WU versions of R-type instructions that have *W versions. If you do it at all then it should be for BOTH the base instruction set and for any new *W instructions in the BitManip extension.
This is easily affordable in terms of opcode space by, as has been pointed out, using something in the hi bits of the instruction, keeping the identical opcode and func3 to the *W version. It's also very cheap to implement.
Probably the only OP-IMM-32 instruction that can be justified is ADDIWU. That does need a new opcode.
This can't be retrofitted to the base instruction set. It needs to be in an extension. There is a real and multiplying cost to every extra extension.
I know Clifford has said this doesn't fit into the BitManip extension. However, since we'd like to have some *WU instructions in the BitManip extension then we should at minimum make sure that the encoding scheme used is compatible with another extension adding *WU versions of the base instruction set *W instructions.
However I think adding *WU to base ISA *W instructions would not be a ridiculous thing to do in the BitManip extension. It could save proliferation of extensions, it's very low cost (and high benefit), it could potentially encourage people to implement the BitManip extension who might not otherwise do so [1]. If evidence was gathered showing it to be useful (pretty trivial -- it would eliminate virtually every "LSL n;LSR n" sequence in RISC-V code) then I think Andrew could be persuaded to put it in B.
[1] it could also be separately available in another extension for people who really really don't want to implement shuffles etc -- multiple extensions are allowed to implement the same instruction.

Interestingly, in a message to me yesterday where we talked about possible *WU instructions, Andrew literally wrote:

I’m not opposed to putting them in B.

To be sure, that expresses ambivalence more than advocacy.  But as far as "could be persuaded" goes, I believe yes.

This is easily affordable in terms of opcode space by, as has been pointed out, using something in the hi bits of the instruction

So that would set 50% of the OP major opcode aside for stuff that has no *W equivalent?
Also, in case there will be more ternary instructions in the future: I don't see that scheme working for ternary instructions, where there is only encoding space for two ternary instructions per minor opcode.

Probably the only OP-IMM-32 instruction that can be justified is ADDIWU

One would also want an SLTIWU instruction, as this is not equivalent to SLTI.
The shifts don't need that much encoding space.
So, if for example inst[31] is used to indicate *WU instructions in OP-32 and OP-IMM-32 (shifts only) then the only things required additionally would be

Two major opcodes in OP-IMM-32 for ADDIWU and SLTIWU
Ternaries would need special handling.

For B we could put FSLWU/FSRWU in the places for the non-existing CMIXW/CMUXW instructions. I would not know where to put FSLIWU/FSRIWU.

I know Clifford has said this doesn't fit into the BitManip extension.

I can be persuaded. :) Especially when Andrew says he is not against it. I would have expected more pushback for something that uses this much encoding space.
So if enough people in the group want this then I'd be happy to write it up. Sounds like the kind of thing that should be easy enough to evaluate.
I personally am a bit concerned about the encoding space that this would require (half of OP-32 + two minor ops in OP-IMM-32, plus effectively 50% of OP). And it would always just replace two instructions: a *W instruction followed by a PACK to zero-out the upper half. Considering that this is only useful when converting from 32-bit values to 64-bit values, I'm not sure how many instructions it would safe in real-world code. (I think code size is the more interesting metric here then performance considering that a high-performance processor could easily merge *W+PACK.)
For comparison: A load-immediate instruction that can load a 17-bit signed immediate would only require a single minor opcode and would replace a 48-bit sequence with a 32-bit sequence. Tbh I would not be surprised if such an instruction would reduce the code size more than adding *WU instructions, at a fraction of the encoding space cost. (But I'm just speculating here of course.)

I wrote:

I would not know where to put FSLIWU/FSRIWU.

Actually, since there would only be FSRIWU it would fit nicely where the non-existing FSLIW instruction would go.
I wrote:

Ternaries would need special handling.
For B we could put FSLWU/FSRWU in the places for the non-existing CMIXW/CMUXW instructions.

Similarly, half of the OP ternary encodings, i.e. half of the opcodes, could be reserved for ternary OPs that don't need *W/*WU variants, so that we could systematically use those encodings in OP-32 for *WU.
Bruce wrote:

Probably the only OP-IMM-32 instruction that can be justified is ADDIWU

What I really like about ADDIWU is that it would enable a two-instruction (64-bit) sequence for loading an unsigned 32-bit immediate into a 64-bit register. Right now this needs three instructions.

I wrote:

So that would set 50% of the OP major opcode aside for stuff that has no *W equivalent?

I haven't seen the P extension proposal yet but I'd assume they would want a lot of encoding space, and would not need *W variants of their instructions. So that would be one example of something that could go in that space (presumably with lots of space to spare, half a major opcode is huge).

Moved *WU discussion to #14. Closing here.


routing has already provided a reference line but the planning module still failed to extract segments from routing

System information

OS Platform and Distribution Linux Ubuntu 18.04:
Apollo installed from source:
Apollo version 6.0:

Steps to reproduce the issue:

I'm connecting the apollo with LGSVL 20.06. I can see through dreamview that routing has already provided a reference line but the planning module still failed to extract segments from routing. However, this framework runs smoothly one day before. Is there anything unstable in apollo 6.0 that could raise such error?

Thanks in advance.
Supporting materials (screenshots, command lines, code/script snippets):
below are parts of the nohup.output
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.841025 36746 pnc_map.cc:421] [map]Failed to update vehicle state in pnc_map.
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.841032 36746 reference_line_provider.cc:538] [planning]Failed to extract segments from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.841039 36746 reference_line_provider.cc:580] [planning]Failed to create reference line from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.841058 36746 reference_line_provider.cc:203] [planning]Fail to get reference line
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.907341 36754 pnc_map.cc:175] [map]Cannot find waypoint: id = lane_13  s = 47.5889
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.907416 36754 pnc_map.cc:421] [map]Failed to update vehicle state in pnc_map.
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.907428 36754 reference_line_provider.cc:538] [planning]Failed to extract segments from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.907444 36754 reference_line_provider.cc:580] [planning]Failed to create reference line from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:16.907467 36754 reference_line_provider.cc:203] [planning]Fail to get reference line
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.123008 36744 pnc_map.cc:175] [map]Cannot find waypoint: id = lane_13  s = 47.5889
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.123064 36744 pnc_map.cc:421] [map]Failed to update vehicle state in pnc_map.
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.123073 36744 reference_line_provider.cc:538] [planning]Failed to extract segments from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.123082 36744 reference_line_provider.cc:580] [planning]Failed to create reference line from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.123102 36744 reference_line_provider.cc:203] [planning]Fail to get reference line
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.326292 36747 pnc_map.cc:175] [map]Cannot find waypoint: id = lane_13  s = 47.5889
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.326331 36747 pnc_map.cc:421] [map]Failed to update vehicle state in pnc_map.
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.326340 36747 reference_line_provider.cc:538] [planning]Failed to extract segments from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.326350 36747 reference_line_provider.cc:580] [planning]Failed to create reference line from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.326367 36747 reference_line_provider.cc:203] [planning]Fail to get reference line
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.841080 36745 pnc_map.cc:175] [map]Cannot find waypoint: id = lane_13  s = 47.5889
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.841140 36745 pnc_map.cc:421] [map]Failed to update vehicle state in pnc_map.
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.841156 36745 reference_line_provider.cc:538] [planning]Failed to extract segments from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.841167 36745 reference_line_provider.cc:580] [planning]Failed to create reference line from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.841189 36745 reference_line_provider.cc:203] [planning]Fail to get reference line
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.907457 36750 pnc_map.cc:175] [map]Cannot find waypoint: id = lane_13  s = 47.5889
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.907518 36750 pnc_map.cc:421] [map]Failed to update vehicle state in pnc_map.
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.907527 36750 reference_line_provider.cc:538] [planning]Failed to extract segments from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.907537 36750 reference_line_provider.cc:580] [planning]Failed to create reference line from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:17.907557 36750 reference_line_provider.cc:203] [planning]Fail to get reference line
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:18.123378 36744 pnc_map.cc:175] [map]Cannot find waypoint: id = lane_13  s = 47.5889
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:18.123428 36744 pnc_map.cc:421] [map]Failed to update vehicle state in pnc_map.
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:18.123438 36744 reference_line_provider.cc:538] [planning]Failed to extract segments from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:18.123447 36744 reference_line_provider.cc:580] [planning]Failed to create reference line from routing
[/apollo/bazel-bin/modules/dreamview/dreamview --flagfile=/apollo/modules/common/data/global_flagfile.txt]  E0113 14:37:18.123466 36744 reference_line_provider.cc:203] [planning]Fail to get reference line

Please check whether the planning module starts normally.

Is the map used driveable?

I use the latest version of lgsvl and apollo6.0 several days ago，only a few maps were found to have elegant positioning.

Thanks a lot for the info!!! It's quite useful to me.
I have one more question. I tried to generate some collision scenarios for apollo. But even if I keep all the settings the same, apollo will not always collide with the NPC every time I ran it. Why is apollo simulator not stable? Is there any way to improve it?
Thanks in advance and looking forward to your reply!

Hello @styj5 ,
There may be some bugs with the sensor data in the simulation. TBH Lgsvl and Apollo can only do some basic tests.
Here is a bad news: https://www.svlsimulator.com/news/2022-01-20-svl-simulator-sunset/

Hello @LordonCN ,
thanks for the timely reply :smiley:
But in my case, apollo has perfect perception ability - i.e. directly feed it with the ground truth information. In my opinion, the bugs of sensor data shouldn't be a problem. What do you think?
And also thank you so much for forwarding me this news, it's really sad. :sob: Maybe I need to search for another simulation framework later.
Have a nice day! :sunny:

@styj5 did you find a solution to the problem? I am seeing a similar issue with the planner module failing.

@AkshayDesaiSDCE If you mean failed to generate reference line, you can turn to https://github.com/ApolloAuto/apollo/issues/12604; for reproduction the cases, my answer is no :(

This issue is closed since the problem is solved.


Fix logger crash on 404

Pull Request Test Coverage Report for Build 275

4 of 6 (66.67%) changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.2%) to 90.009%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

server/logging/setup.py
3
5
60.0%

Totals

Change from base Build 258:
-1.2%

Covered Lines:
1928

Relevant Lines:
2142

💛  - Coveralls


randomized_quicksort added

Why did you submit the .py code in CPP directory? And please add the entire question on top as a comment. Check the other codes in the repository for reference.


Lacking geocodes for many incidents

As I mentioned in #3 , there are many data points without census geocodes (1474/2804).
Potential fixes:

use zip code packages such as rusps as mentioned in this post
use ggmap:: via google API
use the Python package, uszipcode

I chose ggmap for now


Limit ReDOS by checking the length before running the regexp.

Go doesn't support look-ahead assertions so I did this out of the regexp.

This attempts to address CVE-2023-46402 and #24

LGTM

Tagging previous commiter for attention. @whilp @alokmenghrajani @isaaguilar
Would it be possible to merge the PR and create a new release tag.

I implemented something similar (see https://github.com/whilp/git-urls/pull/27) except I made my max len 8000, and it is still very performant.


feat: adds node cl v6 examples

Adds the Node v6 CL updated examples.
Various corrections were made to previous Node snippets such as update a webhook which never even called the update function.
Adds missing type param to create report examples in other langs

Drafting till we release v6 shortly


Add character: 4 to font: boomer

Character : 4
Font : boomer

I want to write code for 4.

4 has already been added under #106. Try for something else.


Add full code snippet functionality to MDX component

Add full code component functionality to match Gatsby theme

[ ] Path / src links
[ ] Prism syntax highlighting

Not high priority because the as-is code block works, it just doesn't have feature parity with Carbon Gatsby theme.

Hey team! Please add your planning poker estimate with ZenHub @alisonjoseph @andreancardona @francinelucca


Add support for UpdateClient to hyperspace relayer abstraction

Summary / Feature Request
Add support for ibc client updates using the hyperspace relayer implementation.
Essentially, implement this:
https://github.com/strangelove-ventures/interchaintest/blob/main/relayer/hyperspace/hyperspace_commander.go#L224-L226

I assume the hyperspace relayer must have client update functionality built in somehow as there is already successful happy path transfer tests using cosmos chains <-> polkadot. I'm guessing that it is just not directly exposed via a CLI?

Doesn't look like there's an update client command exposed in the CLI. When that's added upstream, we'll revisit.
In the meantime, here's what's exposed: https://github.com/ComposableFi/composable-ibc/blob/master/hyperspace/README.md#running-hyperspace---cli-interface

Thanks, I'll open an issue upstream as well 👍

Once upstream adds it we are happy to add it in. Closing since it is out of our control for the time being.


[SWARM-584] Upgrade to wildfly-camel-4.2.0

Can one of the admins verify this patch?

ok to test

ok to test


Set swagger parameter defaults when generating partial controllers

We have just started using NSwag to generate ASP.NET Core controllers (we like schema-first). As part of that work i found that defaults in the swagger schema on parameters are not applied automatically by the controllers.
Consider this example Swagger snippet:
paths:
  /lookup:
    post:
      parameters:
      - name: "index"
        in: "query"
        required: false
        default: 42
        type: "integer"

When i use the partial controller style, there actually an excellent opportunity to set the default before calling on to the underlying implementation. In addition, the IXYZController interface method does not need to accept an int? since a default will always be set.
Why is this a good thing? Because it ensures that the backend developer uses the defaults that are expected by the caller.
Why only partial controllers? Initially i just wanted to inject the value directly in the method signature, but then i remembered that not all defaults can be set in like that (int can, but decimal or guid cannot for example). It could be done in the base controller class by introducing a level of indirection, but that is a bit more complicated to implemented and i am lazy :)
Any caveats? A few, in particular the DefaultToString method that is responsible for rendering the default value in such a way that i can be embedded into the generated code, currently only deals with decimal, double, boolean and string explicitly and not all formats of those. For example datetime and guid format should probably be supported as well. I am happy to add that, but i just want to check that the PR is relevant first. UPDATE: Reading through some of the other PR's i noticed this, which i guess should be used instead?
https://github.com/RSuter/NJsonSchema/blob/master/src/NJsonSchema.CodeGeneration.CSharp/CSharpValueGenerator.cs
Below i have included the output from the unit test i added, showing the behavior as it looks after the changes in this PR:
    [System.CodeDom.Compiler.GeneratedCode("NSwag", "<IP_ADDRESS> (NJsonSchema v<IP_ADDRESS> (Newtonsoft.Json v<IP_ADDRESS>))")]
    public interface IController
    {
        System.Threading.Tasks.Task BarAsync(int abc, bool booldef, int intdef, double doubledef, decimal decdef, string strdef, int? bar = null);

    }

    [System.CodeDom.Compiler.GeneratedCode("NSwag", "<IP_ADDRESS> (NJsonSchema v<IP_ADDRESS> (Newtonsoft.Json v<IP_ADDRESS>))")]
    public partial class Controller : System.Web.Http.ApiController
    {
        private IController _implementation;

        public Controller(IController implementation)
        {
            _implementation = implementation;
        }

        [System.Web.Http.HttpGet, System.Web.Http.Route("foo/bar")]
        public System.Threading.Tasks.Task Bar(int abc, bool? booldef = null, int? intdef = null, double? doubledef = null, decimal? decdef = null, string strdef = null, int? bar = null)
        {
            return _implementation.BarAsync(abc, booldef ?? true, intdef ?? 42, doubledef ?? 0.6822871999174D, decdef ??<PHONE_NUMBER>4264337593543950335M, strdef ?? @"default""string""", bar);
        }
    }

Here abc is required, and bar is not required, but has no default, the rest have various defaults.
Note that the IController interface is always called with the default values, and that the only parameter in the underlying implementation using an explicit nullable type is bar.

Thanks for the PR. Can't we use the DefaultValueGenerators instead of duplicating this logic?
https://github.com/RSuter/NJsonSchema/blob/master/src/NJsonSchema.CodeGeneration.Tests/DefaultValueGeneratorTests.cs

@RSuter Indeed we can ( replacing DefaultToString i would hope ) i think i also mentioned it in the wall-of-text describing the PR. I only found about about it after making the PR, and wanted to verify that the PR was relevant before making more changes.
Sounds like it is relevant, so i will find some time to use the default value generator instead.

Yes, using the default value generator would be great...

Just returned from 3 weeks of vacation, just wanted to say that i still intend to make the changes discussed above.

@RSuter i started using value generator instead, and have rebased against master.

Sorry, had no time to check this.. But in general it looks good... hope to merge this in the next days

Hey @petertiedemann, thanks for the PR. You can test/use it in the latest release.


How to train this model with tensorflow?

We provide this repository where you can see a definition of the model architecture + an implementation in both PyTorch and partially working implementation in Keras.
We do not provide a pure TensorFlow implementation, the Keras one is the closest, but feel free to make a PR with your implementation based on our architecture if you're feeling bold.


made it run with python3 interpreter

Python3 Version
I made it run with python3.
Changes
Changes in kappa.py
In doing so, I converted the ratings matrix (ndarray) to an integer type. Its values are used as indices in various places in kappa.py. I found it easer to change it directly in read_ratings() than to use int() at every usage if ratings[k, 0] . That, however, changed the exception:
Changes in test_kappa.py
Now, for the test with invalid_data.txt the exception changed: SystemExit --> IndexError, since the invalid string in the file is forcedly converted into an int.
Test Plan

[ ] Check, if the tests run
[ ] Look at the changes (functionality still maintained?, conventions, format?)
[ ] Consider creating a new branch as the base for this PR (do you want to keep the python 2 version?)

Remark on "python 3.x" in the Readme: I am using Python 3.7.4. I have not checked, if it runs with 3.x :sweat_smile:
@jorgearanda : you can either keep it as a separate branch or merge to master. :)

@jorgearanda

Hey @mueller-fr ! This looks awesome, thank you so much. I'll give it a more thorough pass by tomorrow and merge it in.
Apologies it took this long for me to get to it: I only just got the github notification about your PR today! 😅

Thanks again, @mueller-fr ! Awesome PR 🏅


Disable hands when using controlls

This got fixed in https://github.com/Nitwel/Immersive-Home/commit/933210bbc9e3314d5e9a6713d0dcca1a3ebd6811


Stripe CLI apps upload failed

Describe the bug
The stripe apps upload CLI command ends with the following error:
marco@marco-ubuntu:~/modulo/progetti/stripe/test$ stripe apps upload --log-level debug
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG config.Config.InitConfig: Using profiles file path=/home/marco/.config/stripe/config.toml
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG cmd.pluginCmd.runPluginCmd: Running plugin...
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG plugins.plugin.Run: negotiated gRPC with plugin process
2024-02-14T11:08:18.127+0100 [ERROR] plugin.child.apps: plugin process exited: path=/home/marco/.config/stripe/plugins/apps/1.5.14/stripe-cli-apps pid=9520 error="exit status 2"
[Wed, 14 Feb 2024 11:08:18 CET] DEBUG Tearing down plugin before exit
[Wed, 14 Feb 2024 11:08:18 CET] DEBUG pluginTemplateCmd.runPluginCmd: Plugin command 'apps' exited with error: rpc error: code = Unavailable desc = error reading from server: EOF

To Reproduce
Steps to reproduce the behavior:

Enable the CLI following this guide: https://stripe.com/docs/stripe-apps/create-app (I use apt)
stripe login
stripe apps create test --log-level debug (test app based on "hello-world" template will be created)
stripe apps upload --log-level debug
The command fails

Expected behavior
The app will be uploaded into Stripe.
Screenshots
-Not applicable-
Desktop (please complete the following information):

OS: Ubuntu linux 22.04.3 LTS
Browser: Google Chrome
Version 121.0.6167.184 (Official Build) (64-bit)

Desktop 2 (please complete the following information):

OS: macOS Ventura 13.6.4
Browser: Google Chrome
Version 121.0.6167.184 (Official Build) (64-bit)

Desktop 3 (please complete the following information):

OS: arch
Browser: Google Chrome
Version 121.0.6167.139 (Official Build) (64-bit)

Same behavior on all desktops. On macOS and arch brew/pacman, node.js, stripe cli were installed from scratch.
Additional context
I have read the other issues that concern app uploading, but none have solved this problem.
I currently need to create an app without UI, which is used only to allow the user to authenticate the OAuth 2.0 flow to integrate our PigrecoOS platform with Stripe, mainly to manage products payment/checkout, as already done for Paypal. I reverted to this "hello world" to verify that the problem was not due to changes I had made.
I have successfully implemented and executed the API requests using the private key in test mode using the PHP SDK. But given this notice, an application is still required to prevent our customers from having to enter their private keys into the backend of our platform.
Commands executed successfully:

stripe login

marco@marco-ubuntu:~/modulo/progetti/stripe$ stripe login
Your pairing code is: ****-****-****-****
This pairing code verifies your authentication with Stripe.
Press Enter to open the browser or visit https://dashboard.stripe.com/stripecli/confirm_auth?t=******* (^C to quit)
> Done! The Stripe CLI is configured for modulo.srl with account id acct_***********

Please note: this key will expire after 90 days, at which point you'll need to re-authenticate.

stripe apps start the app preview displays correctly

^Cmarco@marco-ubuntu:~/modulo/progetti/stripe/test$ stripe apps start --log-level debug
[Wed, 14 Feb 2024 11:36:41 CET] DEBUG config.Config.InitConfig: Using profiles file path=/home/marco/.config/stripe/config.toml
[Wed, 14 Feb 2024 11:36:41 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:36:41 CET] DEBUG cmd.pluginCmd.runPluginCmd: Running plugin...
[Wed, 14 Feb 2024 11:36:41 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:36:41 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:36:41 CET] DEBUG plugins.plugin.Run: negotiated gRPC with plugin process
[11:36:42] compiled successfully
💻 Running development server on http://localhost:4242 (^C to quit)
✨ You can now preview Test in your Stripe account.

🌐 Press Enter to open the Stripe dashboard

^C[Wed, 14 Feb 2024 11:39:26 CET] DEBUG cmd.pluginCmd.runPluginCmd: Ctrl+C received, cleaning up...
[Wed, 14 Feb 2024 11:39:26 CET] DEBUG Tearing down plugin before exit

stripe plugin upgrade apps (I already have the 1.5.14 version)

marco@marco-ubuntu:~/modulo/progetti/stripe/PigrecoOS$ stripe plugin upgrade apps
✔ upgrade to v1.5.14 complete.

Terminal output:
marco@marco-ubuntu:~/modulo/progetti/stripe$ stripe apps create test --log-level debug
[Wed, 14 Feb 2024 10:54:17 CET] DEBUG config.Config.InitConfig: Using profiles file path=/home/marco/.config/stripe/config.toml
[Wed, 14 Feb 2024 10:54:17 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 10:54:17 CET] DEBUG cmd.pluginCmd.runPluginCmd: Running plugin...
[Wed, 14 Feb 2024 10:54:17 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 10:54:17 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 10:54:18 CET] DEBUG plugins.plugin.Run: negotiated gRPC with plugin process

🖊  Enter details of your new Stripe app (these can be changed later)
App ID: com.example.test
Display name: Test
✔ Created skeleton files based on "hello-world" template
installing dev dependencies... @stripe/ui-extension-tools
npm WARN deprecated<EMAIL_ADDRESS>Use your platform's native atob() and btoa() methods instead
npm WARN deprecated<EMAIL_ADDRESS>Use your platform's native DOMException instead
npm WARN deprecated<EMAIL_ADDRESS>Use your platform's native performance.now() and performance.timeOrigin.

added 592 packages, and audited 593 packages in 32s

124 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
installing dependencies... stripe @stripe/ui-extension-sdk

up to date, audited 593 packages in 1s

124 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
✔ Installed dependencies
✔ Created Test at /home/marco/modulo/progetti/stripe
Inside that directory, you can run several commands:

$ stripe apps start
Start a development server locally for viewing your app in the Stripe dashboard

$ stripe apps add view
Add a new view to your app

$ stripe apps upload
Upload your app to be submitted for review

To get started, try starting the development server from the app directory:

$ cd test
$ stripe apps start
[Wed, 14 Feb 2024 10:54:56 CET] DEBUG Tearing down plugin before exit
marco@marco-ubuntu:~/modulo/progetti/stripe$ cd test
marco@marco-ubuntu:~/modulo/progetti/stripe/test$ stripe apps upload --log-level debug
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG config.Config.InitConfig: Using profiles file path=/home/marco/.config/stripe/config.toml
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG cmd.pluginCmd.runPluginCmd: Running plugin...
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG config.Config.GetProfilesFolder: Using profiles file path=/home/marco/.config/stripe
[Wed, 14 Feb 2024 11:08:16 CET] DEBUG plugins.plugin.Run: negotiated gRPC with plugin process
2024-02-14T11:08:18.127+0100 [ERROR] plugin.child.apps: plugin process exited: path=/home/marco/.config/stripe/plugins/apps/1.5.14/stripe-cli-apps pid=9520 error="exit status 2"
[Wed, 14 Feb 2024 11:08:18 CET] DEBUG Tearing down plugin before exit
[Wed, 14 Feb 2024 11:08:18 CET] DEBUG pluginTemplateCmd.runPluginCmd: Plugin command 'apps' exited with error: rpc error: code = Unavailable desc = error reading from server: EOF

The stripe-app.json manifest has not been modified in any way and contains:
{
    "id": "com.example.test",
    "version": "0.0.1",
    "name": "Test",
    "icon": "",
    "permissions": [],
    "ui_extension": {
        "views": [
            {
                "viewport": "stripe.dashboard.customer.detail",
                "component": "App"
            }
        ],
        "content_security_policy": {
            "connect-src": null,
            "image-src": null,
            "purpose": ""
        }
    }
}

One thing that stood out to me in your manifest was the name of your id. When you upload, you'll need to change the id of com.example.test in your stripe-app.json to something unique as it's likely that id has already been uploaded by another developer.  Apps running locally don't have that requirement.

One thing that stood out to me in your manifest was the name of your id. When you upload, you'll need to change the id of com.example.test in your stripe-app.json to something unique as it's likely that id has already been uploaded by another developer. Apps running locally don't have that requirement.

The app I had written previously had the id srl.modulo.stripe and now I set this "hello world" to srl.modulo.test-pigrceoos without the result changing.
If you look more carefully at the logs you will see these lines:
2024-02-14T19:19:32.003+0100 [ERROR] plugin.child.apps: plugin process exited:
path=/home/marco/.config/stripe/plugins/apps/1.5.14/stripe-cli-apps pid=14631 error="exit status 2"

which in my opinion indicate a problem in the apps plugin.
Note that I don't get any specific output from that plugin, like in the examples I saw in the documentation, where manifest validation is logged for example.
I saw from the help of the stripe plugin install command that it is possible to indicate a specific version via the [name]@[version] syntax, but I couldn't find any information in your documentation or here on github about what the older versions are, otherwise I would have attempted to install an older version of the plugin.

I'm able to use stripe apps upload fine.  Perhaps there's another version problem?  Here's my configuration:
node -v
v20.11.0

stripe -v
stripe version 1.14.7

stripe apps -v
apps version 1.5.14

I'm able to use stripe apps upload fine. Perhaps there's another version problem? Here's my configuration:
node -v
v20.11.0

stripe -v
stripe version 1.14.7

stripe apps -v
apps version 1.5.14

I should note that I'm not a Stripe employee, just a developer who has a interest in the success of Stripe Apps as a platform.

marco@marco-ubuntu:~/modulo/progetti/stripe/test$ node -v
v21.6.2
marco@marco-ubuntu:~/modulo/progetti/stripe/test$ stripe -v
stripe version 1.19.2
marco@marco-ubuntu:~/modulo/progetti/stripe/test$ stripe apps -v
apps version 1.5.14

This means it is not the apps plugin. I will try to downgrade stripe cli.

You should also be aware that when running stripe apps upload there are more strict checks in place to ensure your code runs correctly and there are no typescript or in some cases, eslint errors.  Not all the examples are feature complete, for example, you will need to run npm i before uploading an app. Running stripe apps start is more forgiving as it's intended to be a developer localhost environment.

You should also be aware that when running stripe apps upload there are more strict checks in place to ensure your code runs correctly and there are no typescript or in some cases, eslint errors. Not all the examples are feature complete, for example, you will need to run npm i before uploading an app. Running stripe apps start is more forgiving as it's intended to be a developer localhost environment.
Check your code by verifying stripe apps start creates an error-free app in your Stripe dashboard.

Thanks for the support.
marco@marco-ubuntu:~/modulo/progetti/stripe/test$ npm run lint

><EMAIL_ADDRESS>lint
> eslint --ext ts,tsx src

/home/marco/modulo/progetti/stripe/test/src/views/App.tsx
  11:16  warning  'userContext' is defined but never used  @typescript-eslint/no-unused-vars
  11:29  warning  'environment' is defined but never used  @typescript-eslint/no-unused-vars

✖ 2 problems (0 errors, 2 warnings)

marco@marco-ubuntu:~/modulo/progetti/stripe/test$ npm run test

><EMAIL_ADDRESS>test
> jest

 PASS  src/views/App.test.tsx
  App
    ✓ renders ContextView (10 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        3.189 s
Ran all test suites.

marco@marco-ubuntu:~/modulo/progetti/stripe/test$ npm i

up to date, audited 593 packages in 2s

124 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

As you can see there are no vulnerabilities or problems in the tests, but only two unused variables.
The stripe apps start command runs correctly and the app is correctly previewed in the dashboard.

Additional information for the stripe golang team.
Looking at the request logs for my CLI key in the Stripe dashboard, I was able to isolate one that is definitely related to the stripe apps upload command and which fails with code 404:

code
method
uri
timestamp

404 ERR
GET
/v1/tailor/app_by_public_id
13:59:05

200 OK
GET
/v1/tailor/terms_acceptance_by_account/acct_*************/valid
13:59:04

200 OK
GET
/v1/tailor/terms_acceptance_by_account/acct_*************/valid
13:57:41

GET /v1/tailor/app_by_public_id
Stato     404 ERR
ID        req_6h9FrrMuLnzsHF
Orario    15/02/24, 13:59:05
Indirizzo IP ***.***.***.***
Versione  API [2023-10-16](https://stripe.com/docs/upgrades#2023-10-16)
Origine   Stripe/v1 stripe-cli/master

Request query parameters:
{
  "public_id": "srl.modulo.test-pigrecoos"
}

Response body:
{
  "error": {
    "code": "resource_missing",
    "doc_url": "https://stripe.com/docs/error-codes/resource-missing",
    "message": "No such app: srl.modulo.test-pigrecoos",
    "request_log_url": "https://dashboard.stripe.com/test/logs/req_6h9FrrMuLnzsHF?t=1708005545",
    "type": "invalid_request_error"
  }
}

Maybe I'm doing something wrong, but I followed your documentation carefully.

Hi @marco-sacchi,
The team took a look at this and were having trouble reproducing the error. Do you mind including a video recording, so we can help troubleshoot further?

Hello @marco-sacchi,
We have identified the underlying problem and made a fix. Could you please update the apps plugin by running
❯ stripe plugin upgrade apps

and verify it is 1.5.15
❯ stripe apps version
stripe apps
 version: 1.5.15
 git-sha: ee99516
 build-time: 2024-02-15 19:48:43 +0000 UTC

Apologies for the inconvenience this bug has caused.

closing this bug for now. If you run into any issues please re-open or open a new one.


Add test for bug with None in dict

It seems that I have found a bug.
 As for me, it should be fixed.

Not sure. Following this logic "this could be fixed" for False and 0 and anything non-indexable.


investigate multi-node signing solution

The SDK function for addSignature doesn't work in a multi-node situation. But adding the same signature to each sub transaction (where a sub transaction is the same as the main transaction but has the node ID specified by the sdk) shouldn't work either as the node ID is part of the transaction that is signed.
Some more research needs to be done to properly handle the adding, and possible removing, of signatures from a transaction that has multiple nodes.

Fixed with #1023


fix sequence column is not proceeded correctly

Proposed changes
Issue Number: close #xxx
When checking the keys in PrimaryKeyIndex, seq_col_length is not set to correct value, then we got a NOT_FOUND result for an existing key.
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Feature/amortizer

Can you rebase this on top of master to make sure tests pass?

Says it's up-to-date.
Some my changes may have affected that failing test. I'll look into it.

LGTM :+1:

+r

The build is good and I'm seeing 1 +1s from the following folks:

tdfischer

As such, I'll attempt to merge and close this pull request.


Create Stored Procedure for retrieving the API un/key combo

#94 added support for API key auth. However to retrieve the key and username, each service would need to construct a custom query.
Instead of that, add a stored procedure where anyone who has db credentials can issue a call.
There is still somewhat of a barrier in that a user needs db credentials, but this lowers the bar until we have a shared settings
store over a key value structure.

@tanabarr It has to be run. Once a dependency is added that uses this stored procedure, we can add a smoke test around that service + authing against the API.


SK locales

Please add to bootstrap-datepicker.sk.js
clear: "Vymazať",
weekStart: 1,
format: "d.m.yyyy"
Thanks
Libor

feel free to make a PR for that :-)
On Sun, Aug 9, 2015 at 10:51 AM, liborp<EMAIL_ADDRESS>wrote:

Please add to bootstrap-datepicker.sk.js
clear: "Vymazať",
weekStart: 1,
format: "d.m.yyyy"
Thanks
Libor
—
Reply to this email directly or view it on GitHub
https://github.com/eternicode/bootstrap-datepicker/issues/1521.


Big refactor

Let's follow the progress here

[x] Close to graduation
[x] Language center
[x] Students
[x] Courses
[x] Open uni
[x] Study programmes
[x] Faculties
[x] Associations (used for determining all the different study programmes and study tracks)
[x] Class statistics / Custom populations / Study guidance groups / Course population

After everything else is done:

[x] Delete unused models and the related code from backend and updater

Done! Release 3.0.0


Migrate TFLite's stateful lowerings to MLProgram

We have stateful behavior supported via MLProgram. Migrating the TFLite
lowerings from directly lowering to IREE means we can better seperate
TFLite legalization from being IREE specific.

One potential issue is that this uses only direct loads/stores, so there could be issues with variable reads/writes nested in control flow operations. I checked into convert TensorFlow to the MLProgram dialect however without some form of memory handle we won't be able to fully convert the existing lowering.


Incorrect matches

https://github.com/zooniverse-ui/markdownz/blob/master/src/components/markdown.js#L44
https://github.com/zooniverse-ui/markdownz/blob/master/src/components/markdown.js#L46
Talk does not match subject mentions like this.  The syntax for matching a subject is ^S<id>, e.g. ^S123.
Likewise collection mentions are ^C<id>.
The best way to handle this in terms of front-end links would probably be to add a redirect route at /talk/subjects/:id that looks up the project slug and redirects to the project route.

Is this going to change anything that was using the old ^123 to match subject id 123?

The syntax in older versions of talk was just the zooniverse id (AGZ0000001).  New talk has never matched without the type prefix (otherwise you can't disambiguate the thing you're mentioning).

As far I know new Talk has always matched subjects without an S prefix. In project specific Talks it can match the subject without a qualified project.

Nope.  It's never even been used in new talk.

Here's the mentioning regex if you're curious too: https://github.com/zooniverse/Talk-Api/blob/master/app/models/concerns/comment/mentioning.rb#L5-L9

Yeah that's different than the help text on the Front-End, which is what I presume everyone has been using so far: https://github.com/zooniverse/Panoptes-Front-End/blob/master/app/talk/comment-help.cjsx#L11
In addition to being different than what the Front-End markdown parsers has been using, so if we change it, existing in markdown links to subjects will be broken.

I guess that help text has always been wrong then.  It doesn't look like anybody has mentioned a subject with either syntax at all.  If they had, I'd just migrate it.

Well then no big deal either way.


Interpret the result of multclass model

Hey,
I am training a multiclass modell.
When I evaluate this I am getting

Results
Box_preciscion
Box_recall
class_recall
i. label
ii recall
iii precision
iv size

So this is how expetcted. But how do I interpretate this?
I am following the way with a backbone model and then extend this.
In the original way the documentation says:
'box precision is the proportion of predicted boxes which overlap a ground truth box.'
'The recall is the proportion of ground truth which have a true positive match with a prediction...'
How is this in a multiclass model? Does those values have the same meaning?
And if yes, is the recall and precision than based on the predicted boxes or based on the original dataset
(I mean if the original dataset has 1000 boxes, but the backbone model predictes only 500 boxes-> is the recall and precision than based on those 1000 boxes or based on the 500 boxes?)
I hope you understand my point. Thanks in advance!

So I have just checked the code and I think there is a logical mistake.
So in the evaluate.evaluate function we calculate the box_precision and box_recall based on the IoU Threshold. The seems logical since we want to check if the BBoxes were correct.
Inside the evaluate.evaluate the class recall ist calculatetd. This is done by calling the compute_class_recall function with results as parameter. results is a DF that contains all predictions, true labels, and if there is a match. The match column is 1 when the IoU is over the IoU Threshold. So the results DF contains data, where the IoU is > and < than the threshold.
Based on this the class_recall is calculated For each group we caluclate this. For Example the Recall is calculated with the sum of where true_label == predicted label divided by the len of this group DF.
But I think there is the logical mistake. In the results DF are all predictions include. But this doesn't make sense. Since we say when the IoU is > IoU Threshold the box is predicted correct. So the precison and recall for a class should be based on this.
In my opinion we need in the compute_class_recall something like this:
for name, group in box_results.groupby("true_label"):
    correct_predicted_bboxes = group.loc[group['match']==1]
    class_recall_dict[name] = sum( correct_predicted_bboxes.true_label ==  correct_predicted_bboxes.predicted_label)/group.shape[0]
    number_of_predictions = box_results[box_results.predicted_label==name].shape[0]
    if number_of_predictions == 0:
        class_precision_dict[name] = 0
    else:
        class_precision_dict[name] = sum( correct_predicted_bboxes.true_label ==  correct_predicted_bboxes.predicted_label)/number_of_predictions
    class_size[name] = group.shape[0]

Hi @NickHarnau thanks for the thoughts. I've read this a few times and I confess I cannot understand what you are trying to explain. Let's worth through this more slowly. Can you show me an example with a evaluate score, and then the eval score you think is correct? There is too much here to try to unpack. One aspect that may help that I've gone back and forth on is whether the class recall should include boxes that were missed. So let's say you have 5 trees, with a true state of 2 maples and 3 oaks. The model predicts four trees, with 3 oaks and 1 maple. What is the correct 'class recall'. The code is currently structured to have a 4/5 box_recall and then 3/3 oaks and 1/1 maple. So the class recall is 100%. Its a very literal interpretation of recall. The model made 4 class predictions and all are accurate. This is the inherent challenge in multi-task models like retinanet. As long as you are consistent, i'm not sure either way is more correct.

Hi @bw4sz  thanks for your reply!
I am trying to explain it with an example :)
What do you mean by prediction in your answer? I would interprate this as TP boxes after the IoU threshold.
As far as I understand the Framwork, there are two kinds of predictions.

The prediciton of the model based on the score parameter (default = 0.1)
The TP predictions based on the IoU threshold (default = 0.4)

As far as I understood it:
we have 5 trees. 3 oaks and 2 maples. The model makes a preditcion with 8 trees - 4 oaks and 4 maples. After looking at the IoU threshold we get 4 tree predictions - 3 oaks and 1 maple.
So by looking at the code the box_recall is 4/5 and the box_precision is 4/8.
So you the calculating the class_recall based on the second predictions (after IoU threshold).
That makes totally sense for me, but that is not how it is implemented in the code I guess.
But let us look at my example with slightly different numbers and bit more complex:
So first some statements:
Recall = Correctly Identified Object (TP) / all truth Objects (TP+FN)
Precision = Correctly Identified Object (TP) / all predictions of class (TP+FP)
I am unsure about the code. I am especially looking at the evaluate.evaluate and evaluate.compute_class_recall function.
Let's start with the evaluate.evaluate function:
This function takes an argument the predictions and ground truth data. Lets say our ground truth data contains 10 trees - 5 maples and 5 oaks. The prediction dataframe contains 12 predictions (e.g. Score>0.1) with 8 maples and 4 oaks. From those two we are getting a result dataframe. This dataframe contains always as many rows as our ground truth dataframe. In this dataframe we have the IoU and the predicted and true label. From this result dataframe the Box_Precision and Box_Recall is calculated. For that we set an IoU Threshold. All Predictions over this Threshold (e.g.0.4)  are considered to be true positive . Let us say in our case this are the case for TP= 9 -> Prediction: 6 maples and 3 oaks, Truth: 5 maples and 4 oaks. FN=1, FP = 3
From that we get the Box_Precision of 9/12 and Box_Recall of 9/10.
So far so good!
So in the next step the compute_class_recall function is called for calculating the class_recall and class_precision. The compute_class_recall function takes the results dataframe as argument. Like mentioned, the results dataframe has the same length as the ground truth dataframe and is the base for calculating the TP.
So and at this point I am getting the confused.
In the code:
The compute_class_recall takes here the results dataframe as an argument. The results dataframe is at this point as long as our ground truth dataframe (leaving out that the predicted_label=na rows where dropped). This results dataframe is now the base for calculating the class precision and class recall. We are not first check our predictions for the TP. The IoU Threshold does not play a role for calculating the class_recall and class_precision. Neither does the predictions dataframe. So considering the code,
TP_M = 5 / FP_M = 1 /  FN_M = 0 /  TP_O = 3 /  FP_O = 0 / FN_O = 2
maple_recall =  1 / maple_precision = 5/6  / oaks_recall= 3/5 / oaks_precision=1
This is the how the code implementation is right now
logical
The two options from the beginning:
1.
The compute_class_recall takes here the results dataframe as an argument. The results dataframe is at this point as long as our ground truth dataframe. This results dataframe is now the base for calculating the class precision and class recall. In the result dataframe we take the IoU threshold to identify TP boxes. This is the base  calculating the class_recall and class_precision.
TP_M = 5 / FP_M = 1 /  FN_M = 0 /  TP_O = 3 /  FP_O = 0 / FN_O = 2
So maple_recall =  1 / maple_precision = 5/6  / oaks_recall= 3/4 / oaks_precision=1.
So the oaks_recall here is different, because we take the TP boxes as references (the true classes in contrast to the predicted classes of the TP boxes). The interpretation is like follow:
From the boxes correctly predicted by the model, 3/4 of all oaks are found.
---> This is what you claimed how the class_recall is calculated in your reply.
2
Modify the  compute_class_recall to take the results dataframe and the prediction dataframe as arguments. Those dataframes are now the base for calculating the class_recall and class_precision.  In the result dataframe we take the IoU threshold to identify TP boxes. But now the TP boxes are not our reference. The ground_truth dataframe is our reference.
TP_M = 5 / FP_M = 3 /  FN_M = 0 /  TP_O = 3 /  FP_O = 1 / FN_O = 2
So maple_recall =  1 / maple_precision = 5/8  / oaks_recall= 3/5 / oaks_precision=3/4.
So there are different values here is different, because we take the truth data and predictions as references (the true classes in contrast to the predicted classes of the ground truth dataframe ). The interpretation is like follow:
The model finds 3/5 of all oaks.
I mean let's step back -> how you claimed it depends on the intepretation and if it is consistent --> so wether using 1. or 2. does not matter. But what matters is that both approaches are not found in the code. The approach in the code does not take into account at all the IoU Threshold for calculating the class_recall and class_precision.
Maybe I have a mistake in my thinking or I am having an older Version of the code. (I used pip install, so I should have the latest version). Do I miss something?
I already did some modification in the code in the evaluate.evaluate and evaluate.compute_class_recall -> so if you are interested I can provide it or we can use it for further discussion :)
I am more than happy for your Feedback! I hope that my example makes sense :)

It took me awhile to understand your example, but I do think you are correct. The crux is that the class recall was including all predictions, not just the matched ones. That was an error. Pull request is above and should be merged shortly.


Getting layout[i].x === NaN when onLayoutChange is called

Hi,
I copied your basic example, putting my own layout with draggable and resizable to true (super simple layout: 4x4 grid with width and height to 1). Everything render fine at the first run, but when I click on an item to drag it, onLayoutChange get called and the layout get mess up. I've noted that I receive NaN on the x value of the item I clicked on. If i ignore this, it will never happen again, but it's kind of glitchy.
Also, I never see the actual resize icon at the lower right corner, I'm I missing something in the CSS?, I've copied most of your example.
Thanks

@ThePainnn Did you resolve this? I'm seeing the same exact issue now.

Sorry no. I sto investigating this issue since I also had some serious performance issue when combining it with D3 charts content.
I've change my grid to gridstack.js (JQuery) which needed more work to make it work with React, but got great performance without

I found that this was due to not specifying the width, cols, and other properties (shown in the examples) properly. For those finding this in the future, compare your code against the examples and make sure you didn't leave any properties out.


Update Silverlight to 5.1.41212

Thank you for the contribution. It was merged directly as 6aa1c41fc0442e0594298bbe8f73b45eb448e6ca to keep commit history cleaner. Your contribution is still credited to you.


macOS brew installation issue

Following the README for installing on macOS, getting the following error:
==> Installing zf from natecraddock/taps
==> Installing dependencies for natecraddock/taps/zf: z3 and zig
==> Installing natecraddock/taps/zf dependency: z3
==> Pouring z3--4.11.2.arm64_ventura.bottle.2.tar.gz
🍺  /opt/homebrew/Cellar/z3/4.11.2: 142 files, 30.3MB
==> Installing natecraddock/taps/zf dependency: zig
==> Pouring zig--0.10.0.arm64_ventura.bottle.tar.gz
🍺  /opt/homebrew/Cellar/zig/0.10.0: 13,837 files, 362.1MB
==> Installing natecraddock/taps/zf
==> zig build -Drelease-fast=true
Last 15 lines from /Users/mxgrn/Library/Logs/Homebrew/zf/01.zig:
2022-12-03 07:39:57 +0000

zig
build
-Drelease-fast=true

/private/tmp/zf-20221203-28656-cl3y6q/zf-0.5/src/main.zig:238:45: error: invalid builtin function: '@minimum'
        var terminal = try ui.Terminal.init(@minimum(candidates.len, config.lines), no_color);
                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: zf...
error: The following command exited with error code 1:
/opt/homebrew/Cellar/zig/0.10.0/bin/zig build-exe /private/tmp/zf-20221203-28656-cl3y6q/zf-0.5/src/main.zig -OReleaseFast --cache-dir /private/tmp/zf-20221203-28656-cl3y6q/zf-0.5/zig-cache
 --global-cache-dir /private/tmp/zf-20221203-28656-cl3y6q/zf-0.5/.brew_home/.cache/zig --name zf --enable-cache
error: the following build command failed with exit code 1:
/private/tmp/zf-20221203-28656-cl3y6q/zf-0.5/zig-cache/o/e6c08c3c962bc14f424bc077b89fec37/build /opt/homebrew/Cellar/zig/0.10.0/bin/zig /private/tmp/zf-20221203-28656-cl3y6q/zf-0.5 /privat
e/tmp/zf-20221203-28656-cl3y6q/zf-0.5/zig-cache /private/tmp/zf-20221203-28656-cl3y6q/zf-0.5/.brew_home/.cache/zig -Drelease-fast=true

Thank you for the reminder. The most recent release of zf (0.5) requires Zig 0.9.0, while the latest version of zig is 0.10.0. I haven't yet made a release, but I have one coming soon! I had forgotten that there was a small code incompatibility between the Zig versions and I wasn't prioritizing the zf release. I will get it out soon!

I just released zf 0.6.0 and updated the brew package. Sorry for the wait! I'm closing this, but please let me know if it still doesn't work.

Also, zf was just upstreamed to homebrew core so you don't need my natecraddock/taps tap anymore!


comments not work in my repo

Describe the bug
context

my repo is dacao-reading-notes
Generated book address：dacao-reading-notes

I have set comments in my conf.py
extensions = [
    'recommonmark',
    'sphinx_markdown_tables',
    'sphinx_comments'
]

comments_config = {
    "hypothesis": True,
    "utterances": {
        "repo": "da1234cao/dacao-reading-notes",
    },
    # "dokieli": True
}

However, in online books, utterances is not work
Reproduce the bug
git clone git@github.com:da1234cao/dacao-reading-notes.git
sphinx-autobuild.exe .\source\ .\build\html\

List your environment
The following is the build process of readthedocs：https://readthedocs.org/projects/dacao-reading-notes/builds/21245507/

I know where I am going wrong.

I have to insert javascript code of utteranc after document.
At the same time, I should choose the extension of markdown as myst_parser.


Fix docker rate limit

This is not going to work because PRs cannot get access to the token for security reason. Closing.


added real time clock to the project

Description
I want to add a analog clock but when i added a analog clock it was looking odd then i switched to a digital clock.
I have integrated a digital clock.
kindly merge my PR  and label as hacktoberfest
If you want any change let me know
https://github.com/user-attachments/assets/8ef72f0e-864d-4f90-8a18-b07a00e574ba
Fixes #(issue number)
#140
Type of change
I have added a new feature which will enhance the overall user experience of the website.
Please delete options that are not relevant.

[ ] New feature (non-breaking change)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so that they can be reproduced.

[ ] Test B

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] Any dependent changes have been merged and published in downstream modules

There is minor conflict which can be resolved
Kindly merge my PR and label as hacktoberfest

@Anshgrover23 if any specific clock or any thing you want to implement let me know


Add pagination to the candidate API

Context
Adding pagination to the candidate API.
Changes proposed in this pull request
Using the pagy gem.
The API will now accept two optional parameters:
page: the page number of the results
per_page: the number of results to return per page
The headers will also include information on the page range available:
/candidate-api/candidates?updated_since=2021-09-12T14%3A54%3A24%2B01%3A00&page=1&per_page=20; rel="first"
/candidate-api/candidates?updated_since=2021-09-12T14%3A54%3A24%2B01%3A00&page=1&per_page=20; rel="prev",
/candidate-api/candidates?updated_since=2021-09-12T14%3A54%3A24%2B01%3A00&page=3&per_page=20; rel="next"
/candidate-api/candidates?updated_since=2021-09-12T14%3A54%3A24%2B01%3A00&page=8&per_page=20; rel="last"

Guidance to review
Example call:
localhost:3000/candidate-api/candidates?updated_since=2021-09-12T14%3A54%3A24%2B01%3A00&page=2&per_page=20
Link to Trello card
https://trello.com/c/rEyWGcRK/
Things to check

[ ] This code does not rely on migrations in the same Pull Request
[ ] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[ ] API release notes have been updated if necessary
[ ] Required environment variables have been updated added to the Azure KeyVault

lgtm. I'll let @duncanjbrown sign it off


feature: support redis lua for transaction storage & global lock

[x] I have registered the PR changes.

Ⅰ. Describe what this PR did
PR 4772
为seata lua增加全局锁和事务存储的lua实现。
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #5333 (c1c8d28) into 2.x (2302178) will decrease coverage by 0.19%.
The diff coverage is 30.16%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@             Coverage Diff              @@
##                2.x    #5333      +/-   ##
============================================
- Coverage     48.85%   48.66%   -0.19%
- Complexity     4218     4257      +39
============================================
  Files           764      769       +5
  Lines         26870    27183     +313
  Branches       3352     3379      +27
============================================
+ Hits          13127    13229     +102
- Misses        12362    12566     +204
- Partials       1381     1388       +7

Impacted Files
Coverage Δ

...c/main/java/io/seata/common/ConfigurationKeys.java
0.00% <ø> (ø)

...ommon/src/main/java/io/seata/common/Constants.java
100.00% <ø> (ø)

...va/io/seata/common/loader/ExtensionDefinition.java
38.70% <0.00%> (ø)

...ava/io/seata/common/util/LowerCaseLinkHashMap.java
0.00% <0.00%> (ø)

...c/main/java/io/seata/core/lock/AbstractLocker.java
0.00% <0.00%> (ø)

...sole/impl/redis/BranchSessionRedisServiceImpl.java
0.00% <0.00%> (ø)

...sole/impl/redis/GlobalSessionRedisServiceImpl.java
0.00% <0.00%> (ø)

...ta/server/storage/redis/lock/RedisLockManager.java
16.66% <0.00%> (ø)

.../server/storage/redis/lock/RedisLockerFactory.java
0.00% <0.00%> (ø)

...e/redis/store/RedisLuaTransactionStoreManager.java
9.09% <9.09%> (ø)

... and 11 more