Does Interrupt Level Affect WFI?

I assume from the sense of when WFI falls through in the privilege spec, that under CLIC, it falls through even when its priority is below the interrupt level in intstatus as that seems to be a global interrupt "enable" of sorts.  It would be good to have a sentence saying that for CLIC - if it's true.

Needs more clarification please?

In general, WFI can be a NOP so implementation does not have to hold WFI If interrupt is below threshold.

Consensus was that the implementation did not have to exit WFI if threshold was above pending interrupt's level.  This is consistent with threshold  on PLIC, which filters interrupt before being received at processors.

I am also interested to know what precisely causes a WFI wakeup event. This should be stated explicitly.

I think this is pretty clear in the priv spec already: any interrupt that's unmasked (regardless of current global mask) is guaranteed to wake up the hart, and implementations are additionally free to wake up for any other reason.

I think I still need to thrash out the details a bit here...
The CLIC has a potentially large number of inputs, each with its own enable and pending field. For these, it selects the highest priority pending-and-enabled interrupt and presents it to the core. The presentation of any interrupt in this manner is therefore a WFI wakeup event. Is that right?
I am still trying to understand what exactly pending-and-enabled means in this context (see issue #52). Originally I thought that it must be the interrupt-specific enable bit and the mstatus.xie bit, but I think now that this cannot be right, because the WFI wakeup event must occur even when mstatus.xie is 0. However, if the presented interrupt is not affected by mstatus.xie, it seems that under certain circumstances interrupts may be blocked from the core when they should not be. For example, suppose the the CLIC and core are configured in this way:

Interrupt A is M-mode, pending and enabled in the CLIC;
Interrupt B is S-mode, pending and enabled in the CLIC;
mstatus.mie=0
mstatus.sie=1

My questions are:

Does the above setting cause a WFI wakeup event?
Is the pending-and-enabled S-mode interrupt taken, or is it blocked by the mstatus.mie-disabled M-mode interrupt? In other words, do the mstatus.xie bits affect the presented interrupt, or not?

Thanks.

I think I still need to thrash out the details a bit here...
The CLIC has a potentially large number of inputs, each with its own enable and pending field. For these, it selects the highest priority pending-and-enabled interrupt and presents it to the core. The presentation of any interrupt in this manner is therefore a WFI wakeup event. Is that right?
I am still trying to understand what exactly pending-and-enabled means in this context (see issue #52). Originally I thought that it must be the interrupt-specific enable bit and the mstatus.xie bit, but I think now that this cannot be right, because the WFI wakeup event must occur even when mstatus.xie is 0. However, if the presented interrupt is not affected by mstatus.xie, it seems that under certain circumstances interrupts may be blocked from the core when they should not be. For example, suppose the the CLIC and core are configured in this way:

Interrupt A is M-mode, pending and enabled in the CLIC;
Interrupt B is S-mode, pending and enabled in the CLIC;
mstatus.mie=0
mstatus.sie=1

My questions are:

Does the above setting cause a WFI wakeup event?
Is the pending-and-enabled S-mode interrupt taken, or is it blocked by the mstatus.mie-disabled M-mode interrupt? In other words, do the mstatus.xie bits affect the presented interrupt, or not?

AFAICS, this paragraph in the priv spec answers both questions: https://github.com/riscv/riscv-isa-manual/blob/baea02550976abe89db299bfff01e9ef82b269a3/src/machine.tex#L2466

Thanks.

I agree this clarifies WFI (not affected by mstatus.xie) - but what about the interrupt presented by the CLIC? Is this the M-mode interrupt or the S-mode one?

Once the wakeup has occurred, the taking of the interrupt (or not) is the same as any other situation.  In the case you outline, it depends on the current privilege mode.  If the current privilege is M-mode, no interrupt is taken.  If S-mode or lower, interrupt B is taken.
  Bill

On 4/15/20 2:56 AM, JamesKenneyImperas wrote:
EXTERNAL MAIL
I agree this clarifies WFI (not affected by mstatus.xie) - but what about the interrupt presented by the CLIC? Is this the M-mode interrupt or the S-mode one?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/riscv/riscv-fast-interrupt/issues/31*issuecomment-613941324__;Iw!!EHscmS1ygiU1lA!V10gzMvtQ1Tn7pmYFTMPTiOJa0D0CIZW61zyF15f1xVXAFKQ7IxG5DSjGRkVN5E$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AKXXKKDL5ZHYQK7WBBSJSJDRMWADHANCNFSM4G2FHBUQ__;!!EHscmS1ygiU1lA!V10gzMvtQ1Tn7pmYFTMPTiOJa0D0CIZW61zyF15f1xVXAFKQ7IxG5DSj0O_jPgg$.

I spoke too quickly.  It's interrupt A (not B) that's taken at S-mode or lower privilege.
 Bill

On 4/15/20 8:25 AM, Bill Huffman wrote:
Once the wakeup has occurred, the taking of the interrupt (or not) is the same as any other situation.  In the case you outline, it depends on the current privilege mode.  If the current privilege is M-mode, no interrupt is taken.  If S-mode or lower, interrupt B is taken.
  Bill

On 4/15/20 2:56 AM, JamesKenneyImperas wrote:
EXTERNAL MAIL
I agree this clarifies WFI (not affected by mstatus.xie) - but what about the interrupt presented by the CLIC? Is this the M-mode interrupt or the S-mode one?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/riscv/riscv-fast-interrupt/issues/31*issuecomment-613941324__;Iw!!EHscmS1ygiU1lA!V10gzMvtQ1Tn7pmYFTMPTiOJa0D0CIZW61zyF15f1xVXAFKQ7IxG5DSjGRkVN5E$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AKXXKKDL5ZHYQK7WBBSJSJDRMWADHANCNFSM4G2FHBUQ__;!!EHscmS1ygiU1lA!V10gzMvtQ1Tn7pmYFTMPTiOJa0D0CIZW61zyF15f1xVXAFKQ7IxG5DSj0O_jPgg$.

Just to be absolutely precise here (he says, flogging the dead horse) you are saying that the single interrupt presented to the core by the CLIC is the highest-priority one that is enabled by both the interrupt-specific clicintie register and the appropriate mstatus.xie bit, but wakeup from WFI is gated only by the interrupt-specific clicintie register but not the mstatus.xie bit. Is that right?

My understanding is that the wakeup and the taking of the interrupt are entirely separate.  The taking of an interrupt after waking from a WFI is exactly like the taking of an interrupt at any other time.  So the only subject of discussion about WFI is the wakeup.
First, it should be stated that WFI is never forbidden to wake.  On any given cycle it is allowed to wake.  The issues are when it must wake and when it is most efficient for it not to wake.  For most issues, the current privileged spec is quite clear.  It says:   "The WFI instruction can also be executed when interrupts are disabled. The operation of WFI must be unaffected by the global interrupt bits in mstatus (MIE and SIE) and the delegation register mideleg (i.e., the hart must resume if a locally enabled interrupt becomes pending, even if it has been delegated to a less-privileged mode), but should honor the individual interrupt enables (e.g, MTIE) (i.e., implementations should avoid resuming the hart if the interrupt is pending but not individually enabled). WFI is also required to resume execution for locally enabled interrupts pending at any privilege level, regardless of the global interrupt enable at each privilege level."
So the relationship of waking to privilege, global interrupt enables, and local interrupt enables is clear.  Note that even if an interrupt is for a privilege lower than the current privilege, wakeup must occur.
What I haven't seen stated clearly in the CLIC spec is whether an interrupt which is masked by the current interrupt level (xintstatus) or by the interrupt threshold register (xintthresh) must wake from WFI.   I assume from the fact that an interrupt for a lower privilege must wake that an interrupt masked by xintstatus or xintthresh must wake.  It's hard to imagine an interrupt causing wakeup for a lower privilege but not for the same privilege but lower priority.  But I believe the CLIC spec should say explicitly.

Should be defined when WFI is allowed to stay asleep.

The global interrupt enables in xstatus.xie determine whether a pending-and-enabled interrupt causes a trap (jump to trap handler).  Any pending-and-enabled interrupt must cause WFI to be exited (whether or not  xstatus.xie is set).
Individual interrupt has to be enabled by individual enable bits to be taken. If pending interrupt is in higher-privilege mode, then higher-privileged xie bit is ignored (always enabled).  WFI does not have to retire for an otherwise enabled and pending interrupt for current privilege mode with interrupt level below the CLIC threshold for the current privilege mode.  For interrupts pending-and-enabled for a  higher privilege than current mode, the higher-privilege's CLIC threshold is ignored and treated as if set to lowest value for purpose of determining whether to take the interrupt, i.e., trap will be taken into higher-privilege mode, even if higher-privilege global interrupt enable is 0.
If global interrupt bit for current privilege in mstatus is only thing preventing trap from being taken, then WFI must wake up.
Threshold only applies to current privilege mode.
Define pending-and-globally-enabled.

I'd like to avoid repeating most of the interrupt enable definition here.
Can we say something like:  The WFI wake logic watches interrupts as if the current privilege's interrupt enable in mstatus were set, regardless of its actual current value.  If, under that condition, no interrupt would be taken, WFI is permitted to remain asleep.  If WFI wakes but no interrupt actually takes a trap, execution continues normally with the next instruction.

How about this wording?  It also tries to avoid repeating the interrupt enable def.  I tried to copy wording style from the privilege spec:
In CLIC, similar to original mode, WFI is unaffected by the global interrupt bits in mstatus but should honor clicintie, xintstatus, xintthresh, i.e., events that would have caused an interrupt to be taken but are not due to the global interrupt bit settings in mstatus are required to cause WFI to resume execution.

I agree it avoids repeating the definition.  It misses addressing interrupts that are to be taken, I think.
In CLIC, similar to original mode, WFI is unaffected by the global interrupt bits in mstatus but should honor clicintie, xintstatus, xintthresh, i.e., events that should cause an interrupt to be taken as well as those that would have caused an interrupt to be taken but do not due to the global interrupt bit settings in mstatus are required to cause WFI to resume execution.
OR
In CLIC, similar to original mode, WFI is unaffected by the global interrupt bits in mstatus but should honor clicintie, xintstatus, xintthresh, i.e., WFI may remain sleeping only when no interrupts are pending that would be taken if the current privilege's mstatus enable were set.

Hi Kevin, shouldn't this wording
"WFI will wake up only if an interrupt"
be
"WFI will wake up if an interrupt"  because a WFI can be a NOP and not actually sleep, right?   We just specify when it must wake up, but it can wake up earlier if it wants.

Kevin and Dan,
I agree that we only specify when a WFI must wake up.  It can wake up any time it wants to in addition.  So, it sounds like Dan’s proposed wording should be better.
  Bill

From: dansmathers<EMAIL_ADDRESS>Sent: Thursday, January 7, 2021 3:53 PM
To: riscv/riscv-fast-interrupt<EMAIL_ADDRESS>Cc: Bill Huffman<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [riscv/riscv-fast-interrupt] Does Interrupt Level Affect WFI? (#31)
EXTERNAL MAIL
Hi Kevin, shouldn't this wording
"WFI will wake up only if an interrupt"
be
"WFI will wake up if an interrupt" because a WFI can be a NOP and not actually sleep, right? We just specify when it must wake up, but it can wake up earlier if it wants.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/riscv/riscv-fast-interrupt/issues/31*issuecomment-756457099__;Iw!!EHscmS1ygiU1lA!Xi72U3BiZckzFTLDQr-OCWRsbfMCAzmUj83NeFszroewx1sjghrYJgGlnNtrMK0$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AKXXKKEQOYWJLI2DBJHLELDSYZCNLANCNFSM4G2FHBUQ__;!!EHscmS1ygiU1lA!Xi72U3BiZckzFTLDQr-OCWRsbfMCAzmUj83NeFszroewx1sjghrYJgGlxM9fGmc$.

Kevin and Dan,
I agree that we only specify when a WFI must wake up.  It can wake up any time it wants to in addition.  So, it sounds like Dan’s proposed wording should be better.
  Bill

From: dansmathers<EMAIL_ADDRESS>Sent: Thursday, January 7, 2021 3:53 PM
To: riscv/riscv-fast-interrupt<EMAIL_ADDRESS>Cc: Bill Huffman<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [riscv/riscv-fast-interrupt] Does Interrupt Level Affect WFI? (#31)
EXTERNAL MAIL
Hi Kevin, shouldn't this wording
"WFI will wake up only if an interrupt"
be
"WFI will wake up if an interrupt" because a WFI can be a NOP and not actually sleep, right? We just specify when it must wake up, but it can wake up earlier if it wants.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/riscv/riscv-fast-interrupt/issues/31*issuecomment-756457099__;Iw!!EHscmS1ygiU1lA!Xi72U3BiZckzFTLDQr-OCWRsbfMCAzmUj83NeFszroewx1sjghrYJgGlnNtrMK0$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AKXXKKEQOYWJLI2DBJHLELDSYZCNLANCNFSM4G2FHBUQ__;!!EHscmS1ygiU1lA!Xi72U3BiZckzFTLDQr-OCWRsbfMCAzmUj83NeFszroewx1sjghrYJgGlxM9fGmc$.

Thank you for your valuable suggestion and I have modified the spec accordingly with the following checkin:
c521e6f71d1f37b10dba30b06a54a63ddc28c549

Thank you for your valuable suggestion and I have modified the spec accordingly with the following checkin:
c521e6f71d1f37b10dba30b06a54a63ddc28c549

While updating the spec, I noticed the following problems:
In spec we described: In CLIC, similar to original mode, Wait for Interrupt instruction (WFI) is unaffected by the global interrupt-enable bits in mstatus.xie but should honor clicintie[i] and xintthresh. Also, the threshold is valid only for the current privilege mode (while ignored for other privilege
modes).
However, this definition creates counter-intuitive cases. For example:

When WFI occurs in M-mode, a pending M-mode interrupt level = 3, mintthresh = 4, WFI won’t wake up (because it is masked by m-mode threshold)

However,

When WFI occurs in M-mode, if there is a U-mode interrupt with similar level = 3, and uintthresh = 4, WFI will wake up in this case (because threshold is only valid for the current privilege mode (M-mode) and ignored for U-mode interrupts)

This seems really strange because a lower privilege interrupt can wake WFI but a current higher privilege mode interrupt cannot.
Another question is: if level == threshold, should WFI wake up? In normal usage, we only care about preemption and preemption will not occur in this "equal" case. However, it is not clear whether we should wake up WFI in this "equal" case...

While updating the spec, I noticed the following problems:
In spec we described: In CLIC, similar to original mode, Wait for Interrupt instruction (WFI) is unaffected by the global interrupt-enable bits in mstatus.xie but should honor clicintie[i] and xintthresh. Also, the threshold is valid only for the current privilege mode (while ignored for other privilege
modes).
However, this definition creates counter-intuitive cases. For example:

When WFI occurs in M-mode, a pending M-mode interrupt level = 3, mintthresh = 4, WFI won’t wake up (because it is masked by m-mode threshold)

However,

When WFI occurs in M-mode, if there is a U-mode interrupt with similar level = 3, and uintthresh = 4, WFI will wake up in this case (because threshold is only valid for the current privilege mode (M-mode) and ignored for U-mode interrupts)

This seems really strange because a lower privilege interrupt can wake WFI but a current higher privilege mode interrupt cannot.
Another question is: if level == threshold, should WFI wake up? In normal usage, we only care about preemption and preemption will not occur in this "equal" case. However, it is not clear whether we should wake up WFI in this "equal" case...

I think if WFI occurs in M-mode that U-mode (or S-mode) interrupts are not required to cause a wake-up.  My understanding is that interrupts which would have been taken if the appropriate global enable were set (and we weren't in the WFI state) must cause a wake-up.  The computation for required wake-up, then, is the same one as for taking an interrupt except for the global enable and the WFI state.  So interrupts at lower privilege are never required to cause a wake-up.  Interrupts at a higher privilege are required to cause a wake-up without reference to any threshold.  That's the sense in which the threshold is only valid in the current privilege mode - just as it is when taking an interrupt outside of WFI.
The math comparing the pending interrupt level to the threshold should also be the same as for taking an interrupt.  So wake-up is not required to occur in the "equal" case.  (Of course, wake-up is allowed to occur at any time without a reason.)

I think if WFI occurs in M-mode that U-mode (or S-mode) interrupts are not required to cause a wake-up.  My understanding is that interrupts which would have been taken if the appropriate global enable were set (and we weren't in the WFI state) must cause a wake-up.  The computation for required wake-up, then, is the same one as for taking an interrupt except for the global enable and the WFI state.  So interrupts at lower privilege are never required to cause a wake-up.  Interrupts at a higher privilege are required to cause a wake-up without reference to any threshold.  That's the sense in which the threshold is only valid in the current privilege mode - just as it is when taking an interrupt outside of WFI.
The math comparing the pending interrupt level to the threshold should also be the same as for taking an interrupt.  So wake-up is not required to occur in the "equal" case.  (Of course, wake-up is allowed to occur at any time without a reason.)

In the discussion of our Task Group meeting on 20210119, Krste thought this counter-intuitive behavior was not a bug and hence acceptable. So we would not change the definition but only explain in the spec that sometimes lower privilege-mode interrupt can wake up WFI but a higher-privilege mode interrupts cannot.
Regarding whether WFI should wake up when level == threshold, we concluded that we would define it in a way such that hardware cost is minimized. Therefore, we would re-use the existing circuit for normal usage, which is detecting preemption when level > threshold. Similarly, we would change the definition to allow WFI wake up when an interrupt level > threshold (but not for == case).
Lastly, we would also make a note in the spec to remind users that WFI should not be placed inside an ISR.

Personally, to avoid creating counter-intuitive cases, I agree with Bill that "interrupts at lower privilege are never required to cause a wake-up."  Maybe we can re-discuss this issue again in details in the coming group meeting (since did not have much time in previous discussion).
I simply recorded the minutes from 20210119 but it is by no means final yet.

Discussion in TG meeting was to consider dropping all thresholds from consideration for determining "locally enabled".  This provides a more consistent view of WFI wakeup, but does remove ability to use threshold to remove events from set that will wake up WFI.
Separately, another extension could be to add some way to filter lower privilege (and possibly same privilege, below-threshold interrupts) from causing WFIs (this would be advisory as WFI can always wake at any point in time).
Proposal, is uie=0, don't wake WFI on user interrupts?  Change from priv spec for CLINT.
If all lower-privilege xie=0, then can use threshold value for current privilege mode to filter wakeup events?

To avoid redefining the behavior of xie, here is an easy and perhaps more elegant proposal:

If thereshold is set to "-1" (minus one, which is a meaningless/illegal value), then all thresholds are ignored. [For first usage mode]

Otherwise, if threshold has a meaningful/legal value (0-255), then this threshold is used to mask interrupts in current privilege mode (the ones below or equal to threshold) and all lower privilege modes.  [For second usage mode]

Also, this proposal has quite low cost because we only need to add one sign bit to the threshold field to recognize minus value.

Hi Kevin,
I think I understand that you’re differentiating between two modes:

If the current privilege’s threshold is -1, then WFI must wake up if any interrupt whose individual enable is set occurs at any privilege.
If the current privilege’s threshold is 0-255, then WFI must wake up if any interrupt occurs at a higher privilege or at the current privilege and above the threshold.  Interrupts at lower privilege or at the current privilege and at or below threshold are permitted to be ignored.

The xie bits never matter to when wake up is required.  If threshold is set to -1, that is equivalent to 0 for purposes of whether an interrupt is taken.
Is that right?   What about xintstatus?
  Bill

From: Kevin-Andes<EMAIL_ADDRESS>Sent: Thursday, February 4, 2021 11:48 AM
To: riscv/riscv-fast-interrupt<EMAIL_ADDRESS>Cc: Bill Huffman<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [riscv/riscv-fast-interrupt] Does Interrupt Level Affect WFI? (#31)
EXTERNAL MAIL
To avoid redefining the behavior of xie, here is an easy and perhaps more elegant proposal:

If thereshold is set to "-1" (minus one, which is a meaningless/illegal value), then all thresholds are ignored. [For first usage mode]
Otherwise, if threshold has a meaningful/legal value (0-255), then this threshold is used to mask interrupts in current privilege mode (the ones below or equal to threshold) and all lower privilege modes. [For second usage mode]

Also, this proposal has quite low cost because we only need to add one sign bit to the threshold field to recognize minus value.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/riscv/riscv-fast-interrupt/issues/31*issuecomment-773561414__;Iw!!EHscmS1ygiU1lA!VoCPJ3q_HcuPFCouxB1jTdIBSdWquu2AD3d4uyqX4r8hmWYRDjl6vZPm6N2zkQs$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AKXXKKENASW46ROTWMTJBWTS5L2XXANCNFSM4G2FHBUQ__;!!EHscmS1ygiU1lA!VoCPJ3q_HcuPFCouxB1jTdIBSdWquu2AD3d4uyqX4r8hmWYRDjl6vZPmHFaxWns$.

Hi Bill,
Yes, that is exactly what I meant. Thank you for clarifying and summarizing my proposal further.
My intention is to support the 2 modes we discussed (i.e., no filtering and filtering with threshold) while avoid redefining xie to maintain backward-compatibility.  This can be achieved by simply adding one sign bit to the threshold.
Also, there should be no change in the behavior of xinstatus. It should behave just like normal. Do you notice any problem with xinstatus?
Thanks.
Regards,
Kevin

The question about xintstatus was whether it affects whether a WFI wakes up.  I think the answer is "no."  But I think we should state that.

In the TG discussion on 2021/02/16, Krste clarified that, if a higher privilege interrupt occurs, it will not resume WFI but start servicing this new high privilege interrupt instead.

Also, in the TG discussion on 2021/02/16, Bill Huffman had a nice proposal: use “0” for threshold to replace “-1” if we want the “no filtering mode,” which allows any interrupts to wake up WFI. This is cheaper (no cost at all) and also very intuitive since this usage is in agreement with the original definition.

To clarify a bit, I believe using “0” would have exactly the obvious/expected behavior for the current privilege and higher privileges.  The difference if we do this would be that, when the threshold is set to “0”, WFI would be required to fall through on lower privileged interrupts as well.  When threshold is greater than zero, WFI would not be required to fall through on lower privileged interrupts (or on same privilege interrupts at or below the threshold).
The description is in terms of “would be required to fall through” (or not) because falling through is always allowed for any reason.  We’re only spec’ing when it’s required to fall through.
This keeps the interrupt selection as expected, but requires a small change in what actions are taken after the highest priority interrupt is selected.  It does mean that there’s no way to fall through on all current privilege interrupts but no lower privilege interrupts.
  Bill

From: Kevin-Andes<EMAIL_ADDRESS>Sent: Thursday, February 25, 2021 12:11 PM
To: riscv/riscv-fast-interrupt<EMAIL_ADDRESS>Cc: Bill Huffman<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [riscv/riscv-fast-interrupt] Does Interrupt Level Affect WFI? (#31)
EXTERNAL MAIL
Also, in the TG discussion on 2021/02/16, Bill Huffman had a nice proposal: use “0” for threshold to replace “-1” if we want the “no filtering mode,” which allows any interrupts to wake up WFI. This is cheaper (no cost at all) and also very intuitive since this usage is in agreement with the original definition.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/riscv/riscv-fast-interrupt/issues/31*issuecomment-786169338__;Iw!!EHscmS1ygiU1lA!VCaFrJ-UtGutlRNCFl1ZscZG-SppJgrC3yWYGhQIwRmhO6OcfYOg4y51gg7WK6o$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AKXXKKEOBC676AD3TC5BNZTTA2VEDANCNFSM4G2FHBUQ__;!!EHscmS1ygiU1lA!VCaFrJ-UtGutlRNCFl1ZscZG-SppJgrC3yWYGhQIwRmhO6OcfYOg4y51OpO1jNg$.

Thank you for the detailed clarification. Indeed, using “0” does create a difference that WFI would be required to fall through on lower privileged interrupts (while the normal usage of qualifying preemption would not). Also, you are right that “there’s no way to fall through on all current privilege interrupts but no lower privilege interrupts” because the definition for “0” changes subtly now.
In order to keep it simple/backward-compatible and avoid potential confusion, it is probably better to keep the definition of “0” to be the same. To this end, adding a sign bit may be desirable and justified as we are not changing existing definition or behavior.
By the way, the advantage of using a sign bit (i.e., negative threshold) is that it is somewhat easier to remember and program compared to an alternative of creating a separate mode bit elsewhere.

This appears to be a more general issue than only for the CLIC.  Other interrupt controllers, including the original CLINT scheme, might want to have a way to change WFI behavior to ignore all lower-privilege interrupts when executed in a higher-privilege mode.  For example, we could add another mode bit in a status CSR to modify WFI behavior in this way for all local interrupt controllers.
If we address this in the CLIC spec, we might find that later we'll have to define the interaction of the CLIC setting with the other more-universal setting.  Suggest we raise this as a privilege group issue, and possibly worth fast tracking. OTOH this might be difficult to get agreement across the different local interrupt controller designs (CLINT, CLIC, AIA).
The WFI-mode bit when clear would preserve existing behavior.
The WFI-mode bit when set could have the form of 1) always ignore lower-mode interrupts, or 2) respect xie bits of lower-mode interrupts, so higher-mode can modify yie bits of modes y<x to get desired behavior.
Action is to raise this issue on priv committee.

I had a discussion with Andrew and we came up with what we believe is a clean solution, which is to add a new WFMI instruction ("wait for mode's interrupts").  This instruction only has to wakeup for pending-and-enabled interrupts in the current mode, and is not required to wakeup for lower modes (pending-enabled higher-mode interrupts will just interrupt as usual).  Making a new instruction avoids having to deal with state (which could be separate bits for each privileged mode)  and we don't believe there is an important use case that wants to modulate the behavior of fixed binary code with WFI by changing a state setting.
The encoding is same as WFI except with bit 28 clear.  This also provides a true user-mode WFMI, whereas existing WFI is encoded as a supervisor mode instruction, with exception to allow use at user-mode.  The encoding also means a simple legal implementation can simply merge WFI/WMFI in hardware treating bit 28 as don't care (though losing benefit of selective wakeup).
@aswaterman Andrew will be bringing up privileged list for discussion as a general, hopefully fast-track, extension.

Yeah, it will be a little while, but I'll get it out there.

I think this allows a choice.  An implementation can do one of two things:

Treat both instructions the same way.  Always wakeup on all interrupts of the current mode and on interrupts of all lower modes.
Keep micro-state for which instruction was executed.  Do the same as above for WFI.  Wakeup only on above threshold current mode interrupts for WFMI.

Higher mode interrupts are always taken.

Agreed.
On Fri, Mar 5, 2021 at 10:14 AM billhuffman<EMAIL_ADDRESS>wrote:

I think this allows a choice. An implementation can do one of two things:

Treat both instructions the same way. Always wakeup on all
interrupts of the current mode and on interrupts of all lower modes.

Keep micro-state for which instruction was executed. Do the same as
above for WFI. Wakeup only on above threshold current mode interrupts for
WFMI.

Higher mode interrupts are always taken.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-fast-interrupt/issues/31#issuecomment-791593377,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH3XQSVSO7BQN6R6U4IJ23TCENPJANCNFSM4G2FHBUQ
.

can issue #31 and #120 be closed with pull #144?


abort() in vsnprintf with MIMALLOC_VERBOSE=1, threads, and setlocale (Windows)

On Windows, If MIMALLOC_VERBOSE=1 environment variable is set, and a thread is created after setlocale(), then thread initialization code crashes with stacktrace  below. Apparently, it seems that ucrtbase.dll is expecting/missing some thread-local locale-related variable, when its vsnprintf() is called. Also, debug CRT does not abort,  only optimized version does.
I can reproduce with the below code, compiled RelWithDebInfo or Release (or MinSizeRel), with mimalloc malloc override is used.
#include <windows.h>
#include <stdio.h>
#include <process.h>
#include <locale.h>

unsigned int __stdcall thread_func(void*)
{
	printf("In second thread...\n");
	return 0;
}

int main()
{
	HANDLE hThread;
	unsigned int threadID;

	setlocale(LC_ALL, "en_US.UTF8");
	hThread = (HANDLE)_beginthreadex(NULL, 0, &thread_func, NULL, 0, &threadID);
	WaitForSingleObject(hThread, INFINITE);
	CloseHandle(hThread);
}

Stacktrace:

1      ucrtbase.dll!abort
2      ucrtbase.dll!__crt_cached_ptd_host::update_locale_slow
3      ucrtbase.dll!__crt_stdio_output::output_processor<char,__crt_stdio_output::string_output_adapter,__crt_stdio_output::standard_base<char,__crt_stdio_output::string_output_adapter>>::process
4      ucrtbase.dll!common_vsprintf<__crt_stdio_output::standard_base,char>
5      ucrtbase.dll!__stdio_common_vsprintf
6      [Inline Frame] mimalloc.dll!vsnprintf
7      mimalloc.dll!mi_vfprintf
8      mimalloc.dll!_mi_verbose_message
9      mimalloc.dll!mi_reserve_os_memory_ex
10     mimalloc.dll!mi_arena_reserve
11     mimalloc.dll!_mi_arena_alloc_aligned
12     mimalloc.dll!mi_segment_os_alloc
13     mimalloc.dll!mi_segment_alloc
14     mimalloc.dll!mi_segment_reclaim_or_alloc
15     mimalloc.dll!mi_segments_page_alloc
16     mimalloc.dll!_mi_segment_page_alloc
17     mimalloc.dll!mi_page_fresh_alloc
18     mimalloc.dll!mi_page_queue_find_free_ex
19     [Inline Frame] mimalloc.dll!mi_find_free_page
20     mimalloc.dll!mi_find_page
21     mimalloc.dll!_mi_malloc_generic
22     mimalloc.dll!mi_heap_calloc
23     ucrtbase.dll!DllMainDispatch
24     ntdll.dll!LdrpCallInitRoutine
25     ntdll.dll!LdrpInitializeThread
26     ntdll.dll!_LdrpInitialize
27     ntdll.dll!LdrpInitializeInternal
28     ntdll.dll!LdrInitializeThunk
Looking at the stacktrace,  it seems that ucrtbase.dll's function __stdio_common_vsprintf is called inside ucrtbase.dll's DllMain function ucrtbase.dll!DllMainDispatch(). Not sure how safe that is. Perhaps it tries to use thread local storage which is not initialized yet. An alternative could be a self-written locale-unaware minimal version of vsnprintf, or using _vsnprintf exported function by ntdll.dll.
mimalloc_bug.zip

This issue seems will be fixed in the next release: #740

You can check the dev branch, there has the commits for this issue, but not merge to master yet.


be opinionated about dot chaining indentation

and perhaps ?: indentation.
currently, this is accepted by standard(1):
export function opinions () {
  return rad()
.x
        ? 3
  : 1
}

which
really this came up because i wasn't sure whether to:
// a: keep level
if (cat) {
 woggle()
 .wiggle(w => {
   return w.x ? w.y : w.z
 })
}

or:
// b: indent
if (cat) {
 woggle()
   .wiggle(w => {
     return w.x ? w.y : w.z
   })
}

and depending on the particulars of what i'm writing one seems better than the other, but that has left me with some inconsistency in the codebase.
a has the upside of the closing braces ending up at the same indentation as the original target of the operation
b has the upside of sometimes feeling right
i'm sure i can learn to live with either should this project suggest one

also in favour of a:
if you later decide to add a newline before a dot, you don't have to change indentation of its innards.
as in:
expect(a).toEqual({
  type: 'tears',
  number: 99
})

becomes:
expect(a)
.toEqual({
  type: 'tears',
  number: 99
})

rather than
expect(a)
  .toEqual({
    type: 'tears',
    number: 99
  })

use prettier, period. :D

i mean, fine, but

The whole point of standard is to save you time by avoiding bikeshedding about code style.

this is now some code style that i am bikeshedding about.
there are plenty of formatting rules in standard. including that the dot should be on the same line as the property.
as well as comma-dangle, block-spacing, comma-style, func-call-spacing, key-spacing and so very on.
i mean, you know this, there's no need for me to repeat them here.
semi-spacing, padded-blocks, space-in-parens
there are projects on which i can't use prettier but i would still not like to think about these things
space-unary-ops,  spaced-comment(!!!!), template-curly-spacing
i'll see what i can do about getting the tech lead to allow me to set up prettier, but the last time i reformatted the entire project he took it thick.
semi
(i understand you said "not always true", and i understand your suggestion is probably quite a good one, but it doesn't help me much right now)

Member expressions indentation is a dupe of https://github.com/standard/standard/issues/628 and both generally covered by https://github.com/standard/standard/issues/735. Suggest closing.

thanks, tim


feat: add channel version to core app callbacks

Description

closes: #195

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against the correct branch (see CONTRIBUTING.md).
[ ] Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/).
[ ] Added relevant godoc comments.
[ ] Provide a conventional commit message to follow the repository standards.
[ ] Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
[ ] Re-reviewed Files changed in the GitHub PR explorer.
[ ] Review SonarCloud Report in the comment section below once CI passes.

Can we also remove or deprecate GetAppVersion now that we've made this change?

No, the version still needs to be unwrapped for others uses (async packets or migrations). The port router refactor will address this interface though

I've added app version callbacks, let me know if how I did it is reasonable or if it should be done differently @colin-axner


Fix streams creation for roles with existing payments, fix editing payments

Closes #2261
Closes #2274
Note - edit/delete is not as much working. I'll be working on that in the next PR. With that I'll also implement more thoughtful mapping

I don't really understand these changes? @mudrila

Merging this early to keep things moving


Implementation Examples

It would be nice to have some examples of how to implement this router with popular libraries. For example, I'm currently trying to use it with React but not sure how to mount components based on baobab-router state changes...

baobab-router binds the url changes to a baobab tree. This means that if the url changes, so does the baobab tree and, the other way around, if the baobab tree catch relevant changes, it will update the url.
So there are really no differences between using the boabab cursors/data and use them inside a React component and what baobab-router proposes.
Example
var tree = new Baobab({
  view: 'home'
});

var router = new BaobabRouter(tree, [
  {
    route: '/home',
    defaultRoute: true,
    state: {
      view: 'home'
    }
  },
  {
    route: '/settings',
    state: {
      view: 'settings'
    }
  }
]);

var Navigation = React.createClass({
  cursor: ['view'],
  render: function() {
    var currentView = this.cursor.get();

    return (

Home

Settings

    );
  }
});

We will produce better examples in the future with @jacomyal when we can find some time.

As a side note: I tried to use both react-router and baobab once and found that this can work but only if you application's state does not need to know anything about the url (sometimes, it is impossible but in a lot of case, considering the router and the state tree as two different stores can make sense).
This library was therefore created by @jacomyal for cases when your application's state effectively relies on the current url fragments.

The README now provides two different examples. Though, these examples just show the interactions between the URL and the state, and do not go as far as showing some views examples.


⚠ Processors has degraded performance

In 4015ea0, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 38 ms

Resolved: Processors performance has improved in a3c8d23.


Implement Danger

Dear @dkhamsing, our CI God,
Do you think it would be cool to add Danger to AwesomeiOS?
If so, can you do it? I don't wanna mess up with the bots you're already running

Haha
We can try it, if anything the current setup can be lauded or turned off
What rules do you want to enforce?

Oops fixed a typo

ENSURE THERE IS A SUMMARY FOR A PR
fail "Please provide a summary in the Pull Request description" if github.pr_body.length < 5
WARN WHEN THERE ARE MERGE COMMITS IN THE DIFF
if commits.any? { |c| c.message =~ /^Merge branch 'master'/ }
warn 'Please rebase to get rid of the merge commits in this PR'
end
ONLY ONE LIB PER PR (I created 😉 )
fail "Please only add one library per PR" if git.lines_of_code > 1
What do you think? 🤔


Remove the repeated time you from the old-PR reminder message

Remember each time you time you ...

:+1:

:ship:


Support minimum/maximum size constraint on hashtable validation type

Just as the array property validation type allows one to constraint on the minimum and maximum length of array values (via the minimumLength and maximumLength constraints), allow one to specify the minimum and maximum number of elements that can be stored in a value that is declared with the hashtable validation type.
For example (not to be considered final):
propertyValidators: {
  accounts: {
    type: 'hashtable',
    required: true,
    minimumSize: 1,
    maximumSize: 2
  }
}

Resolved by https://github.com/Kashoo/synctos/pull/82.


Remote device Upload/Download rates are switched or misleading

I've got only two connected devices, and both show ~1MiB/s upload rate, and both ~20kbps download.
Makes no sense to me - one device is actually downloading at ~1MiB/s.

Is this in the main syncthing UI? If so, that's a syncthing issue.
On 10 July 2017 23:00:43 BST, cloo<EMAIL_ADDRESS>wrote:

I've got only two connected devices, and both show ~1MiB/s upload rate,
and both ~20kbps download.
Makes no sense to me - one device is actually downloading at ~1MiB/s.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/canton7/SyncTrayzor/issues/383

Yes, that is main UI.

Post on the syncthing forum, then. SyncTrayzor just shows that UI, I didn't design it.
On 10 July 2017 23:27:40 BST, cloo<EMAIL_ADDRESS>wrote:

Yes, that is main UI.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/canton7/SyncTrayzor/issues/383#issuecomment-314267912


Removed external/example-test

Removed example-test from external directory as it's no longer needed.
Issue #3181
Documentation in progress.

@jnjerin could you remove the change for thorntail-mp-tck in this PR? thorntail-mp-tck change is merged via https://github.com/adoptium/aqa-tests/pull/3195


[DRAFT] use integer ( maybe autoincrement on SQL) ids instead of UUID

this is not a "ready to merge" PR.
I took at look at #320 and it is not adequate to properly support integer IDs
This PR is the entire kitchen sink we need to be able to properly support integer IDs in both graphql and jsonapi.
I need some guidance on how best can this be integrated ? (using a possible resourceConfig.generatedId option)

Now that we've merged #320, and as explained there the spec requires the id to be a string, do we still need this PR @championswimmer, or can we close it?


Integrate with Spotlight Search

See this post: https://agostini.tech/2019/04/22/using-nsuseractivity-for-spotlight-search/

That is very cool. Let’s do it.


button text and russian

I fixed the problem with the button text and added the russian translations.
@Tarrke @hoylemd @gsuberland please take a look :)

@Tarrke @hoylemd I'm merging this to fix the issues people have with the current version. I would still like to hear your feedback though :)

Sorry for last week, I wasn't there to read mails :).

Sorry for last week, I wasn't there to read mails :).

No worries. I'm the one who usually needs months to respond.. I won't complain about a week :D


ARKit image detection & Vertical Plane Detection

Image detection
Usage:
<ARKit
  detectionImages={[{ resourceGroupName: 'DetectionImages' }]}
  onAnchorDetected={onAnchorUpdated}
  onAnchorUpdated={onAnchorUpdated}
  onAnchorRemoved={onAnchorRemoved}
/>

detectionImages is an array of objects. Currently only images from assets are possible, but in future, we also want to enable images from filesystem, remote, etc.
to add an image to detect to xcode, see https://developer.apple.com/documentation/arkit/arreferenceimage?language=objc
see also https://developer.apple.com/documentation/arkit/recognizing_images_in_an_ar_experience?language=objc for best practises
onAnchorDetected, onAnchorUpdated and onAnchorRemoved is the more generic version of onPlaneDetected, etc. onAnchorDetected will notfiy about every anchor (plane and image currently).
these callbacks passes an object with the same properties as in the onPlane-callbacks (position, positionAbsolute, eulerAngles, id)
the object has a new type-property that specifies the type of the anchor (currently plane and image)
depending on the type, there are additional properties on the anchor
If you specify the onPlane-versions, onAnchor won't notify about planes atm. but i will review this decision. I am unsure whether we should have a onXXXAnchor... for every anchor type or just one generic onAnchor-callback for every anchor type (i favour the later).
onPlaneUpdate has been renamed to onPlaneUpdated (more consistent)

Vertical plane detection
Usage:
<ARKit
  planeDetection={ARKit.ARPlaneDetection.HorizontalVertical}
/>

Will notify about vertical planes as well in onPlaneDetected. You can distinguish with planeAnchor.alignment === ARKit.ARPlaneAnchorAlignment.Vertical

I'm on "react-native-arkit": "0.9.0-beta.3".
Have a fresh create-react-native install, followed the steps for manual install. and trying to get a basic asset showing on the screen
and I'm getting undefined is not an object (evaluating 'ARKitManager.ARPlaneDetection')

@elderbas it's ARKit.ARPlaneDetection. ARKitManager is used internally. Was this mentioned somewhere in the readme? maybe i did a mistake

This is the only mention of ARKit.ARPlaneDetection in the docs

Also, FYI, if I don't put a value for planeDetection prop, to let it go to default, I still get the same error.

@elderbas I fixed the typo in the example in the Readme.
I also tried to not give a value for planeDetection and it worked. I am not sure what went wrong, can you try to reproduce it and file an issue?

@macrozone Any update when you would be able to use images from an external resource like a s3 bucket?


es6 support

How can I use the below code (template strings) with jslint?
`${apiHost}/users/${user.id}/cart`

Keep on getting errors

Right now, I don't think you can do that without some manual tweaking.
SublimeLinter-jslint uses node-jslint to do the actual linting. node-jslint still uses the old jslint version by default, which doesn't support es6/es2015 syntax. node-jslint does provide command line options to use the new jslint which does support es6/es2015 syntax. However, the new version also uses 0-based line number indexing which will make Sublime Text show the error indicators on wrong lines (see issue #5).
You could try to manually tweak your linter installation (see issue #5 for details) or wait for the default behavior of node-jslint to change (the change has been announced and should be coming in node-jslint v1.0.0.

node-jslint now supports a new option which can be used to enable es6/es2015 syntax support without breaking the error highlighting inside Sublime Text. See issue #5 for the solution.


3.10.0 Thrown grenades do not explode

All entire grenades are not working properly. After throwing grenade model being alive for detonator delay time, after that it disappears instead of explosion. That happens with all kind of grenades. Also it doesn't matter by who it was threw out.

Originally written by eye-d

You will need to attach the logs that were required in the new issue template:
Server: (found in /user/logs/server-yyyy-mm-dd-xx.log)
BepinEx: (found in /BepinEx/LogOutput.log)
Client: (found in /Logs/log_<date>_<version>/<date>_<version> traces.log)

Originally written by DrakiaXYZ

I can confirm grenades do not explode.
Smoke grenades work as expected.

Originally written by chomp

This appears to be a PvE  bug: https://www.reddit.com/r/EscapefromTarkov/comments/1e5flvl/bug_grenades_not_working/

Originally written by chomp

Edit: Was a patch causing the issue should be resolved now

Originally written by Kaeno

fixed, closing

Originally written by CWX


feat: folder support in local media library (WIP!!!)

This PR adds basic support for browsing subfolders in media library.

ToDo:

[ ] folder creation dialog

@KaneFreeman If you think the changes I made are enough, the only thing remaining is creating folders. Would be great if you could help me to create a popup/dialog to ask for the slug of the new folder.
When trying to do it myself and replicating the way the confirm dialog works, my custom browser event didn't get registered for some reason, so the dialog didn't open.

@KaneFreeman If you think the changes I made are enough, the only thing remaining is creating folders. Would be great if you could help me to create a popup/dialog to ask for the slug of the new folder. When trying to do it myself and replicating the way the confirm dialog works, my custom browser event didn't get registered for some reason, so the dialog didn't open.

Yeah we can land this PR then address that. The confirmation dialog is a bad example as it is designed to be used inline (like in an if statement, awaiting the response) which is not what we want to do here. We can instead do a much more normal callback approach, where we simply render the dialog directly in the media library, tell it to open when you click the create folder button, then listen for an event from it that would create the actual folder.


diagonal() has incorrect default

Thanks for all the hard work on this.
In v0.102.8 CPU there is a minor bug:
Tensor.diagonal() has its final argument (dim2) set to 0, whilst documentation states this should be 1.
      //   dim2:
      //     Second dimension with respect to which to take diagonal. Default: 1.
      //

This causes an exception if calling diagonal without stating all arguments explicitly.
      public Tensor diagonal(long offset = 0L, long dim1 = 0L, long dim2 = 0L)

should be
...
      public Tensor diagonal(long offset = 0L, long dim1 = 0L, long dim2 = 1L)

Thanks

Thank you! A fix has been made in the PR #1401.


First version of REST calls for NSC plugin

This PR contains the following:

Rest Framework Infrastructure.
REST Implementation for NetworkElementEntity.
REST implementation for InspectionPortEntity.
REST implementation for InspectionHookEntity.

@sudhirappaji I have not looked at this PR yet but I believe you are currently working on https://github.com/opensecuritycontroller/security-mgr-sample-plugin/pull/33 and therefore not blocked on this one but please let me know otherwise.

@emanoelxavier , I have just released the security-mgr-sample-plugin for review for device updates and will continue to work on testing this changes on deployed OSC. so not blocked for time being and I assume that this nsc will not be part of this release?

@sudhirappaji I havent fully finished the review yet but I added a few comments. Thx.

@arvindn05  @emanoelxavier , I have addressed all of the review remarks.

@arvindn05, @emanoelxavier - Addressed the review comments, please check. I will meanwhile update the branch with the master as part of next iteration.

@arvindn05 , I have made the changes as requested, please review.

@arvindn05 , Please review and I have incorporated as per your suggestion. I have removed the test cases added by Praveen, as I see test structure has changed during the merge.
@pravinrajr9 , please add the test case as per the new structure as part of this PR.

@arvindn05 , I have added the tests needed, please review.

please address minor comments. @larkinscarvalho please review the unit tests.

@larkinscarvalho , please review and once you approve I will merge these changes.

@larkinscarvalho , I am go ahead and merging this... and if you have further remarks, will resolve this as a separate PR.


Moving formatting service to common layer

### Summary of the changes
Moving RazorFormattingService to common layer. It's immediately needed for OnAutoInsert support, but will eventually be needed by the formatting endpoints themselves.
Fixes:
Part of https://github.com/dotnet/razor/issues/9519

Switching back to draft while I investigate test failures


Module not found: Can't resolve 'primereact/schedule'

after I do npm start I get

<EMAIL_ADDRESS>watch-css C:\git\primereact-sigma
npm run build-css && node-sass-chokidar src/layout/ -o src/layout/ --watch --recursive | node-sass-chokidar public/assets/layout/ -o public/assets/layout/ --watch --recursive

Failed to compile.
./src/components/DataDemo.js
Module not found: Can't resolve 'primereact/schedule'

attached package.json
{   "name": "sigma-react",   "version": "2.0.0-beta.2-SNAPSHOT",   "homepage": "/sigma-react",   "private": false,   "repository": {     "type": "git",     "url": "https://github.com/primefaces/sigma.git"   },   "license": "MIT",   "dependencies": {     "axios": "^0.18.0",     "babel-polyfill": "^6.26.0",     "chart.js": "^2.4.0",     "classnames": "^2.2.5",     "fullcalendar": "4.0.0-alpha",     "moment": "^2.17.1",     "primereact": "2.0.1",     "primeflex": "1.0.0-rc.1",     "primeicons": "1.0.0",     "quill": "^1.3.1",     "react": "^16.2.0",     "react-dom": "^16.2.0",     "react-transition-group": "^2.2.1",     "react-router-dom": "^4.2.2",     "node-sass-chokidar": "^1.3.0",     "npm-run-all": "^4.1.3"   },   "devDependencies": {     "react-scripts": "2.1.1"   },   "scripts": {     "build-css": "node-sass-chokidar src/layout/ -o src/layout/ | node-sass-chokidar public/assets/layout/ -o public/assets/layout/",     "watch-css": "npm run build-css && node-sass-chokidar src/layout/ -o src/layout/ --watch --recursive | node-sass-chokidar public/assets/layout/ -o public/assets/layout/ --watch --recursive",     "start-js": "react-scripts start",     "start": "npm-run-all -p watch-css start-js",     "build-js": "react-scripts build",     "build": "npm-run-all build-css build-js",     "test": "react-scripts test --env=jsdom",     "eject": "react-scripts eject"   },   "browserslist": [     ">0.2%",     "not dead",     "not ie <= 11",     "not op_mini all"   ] }

Primereact 2 got rid of schedule in favour of fullcalendar. But the sigma theme was last updated in September 25th, and is still not updated to use the new calendar instead of former schedule. That’s why you got the error.
I don’t know who’s responsible for this repo, but they don’t seem to be very reactive to maintain the theme up to date. I suppose we’ll have to propose a PR ourselves or something.
Me? As a workaround, I temporarily commented out all usage of Schedule at the moment since I don’t use it right now

Thanks, I got it working by renaming primereact/schedule with primereact/fullcalendar.

@grounzero @AlainD- this issue has been resolved, verify and close

I checked, and it's solved since Sigma React 3.0.0

@grounzero @cagataycivici this issue resolve, close it


update parameter order

update parameter order to keep same with others like IotDpsResource_CreateOrUpdate

@JeffreyRichter @mikekistler  Could you help take a look at the breaking change, I think the original definition is incorrect.

Qiaoqiao,
The order of parameters is not significant at the REST API level, so the original definition is not incorrect.
But generated SDKs may have methods that use the parameter ordering from the REST API, so changing the ordering could be breaking for SDKs and the users of SDKs.
So while the parameter ordering may be inconsistent, changing it now has the potential for more harm than good.
Mike
From: Qiaoqiao Zhang @.>
Date: Tuesday, June 6, 2023 at 1:26 AM
To: Azure/azure-rest-api-specs @.>
Cc: Mike Kistler @.>, Mention @.>
Subject: Re: [Azure/azure-rest-api-specs] update parameter order (PR #24312)
@JeffreyRichterhttps://github.com/JeffreyRichter @mikekistlerhttps://github.com/mikekistler Could you help take a look at the breaking change, I think the original definition is incorrect.
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-rest-api-specs/pull/24312#issuecomment-1577989000, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUNNB376QF4T6RZZ35DKRLDXJ3ESVANCNFSM6AAAAAAY35FQRI.
You are receiving this because you were mentioned.Message ID: @.***>

@mikekistler Thanks Mike for providing the context, I think we will close this PR and try to fix it in the generator side.  Thanks you.


Minor bug fixes

Plumb the service-ip-range properly
Make sure long names don't prevent the provisioning of the load balancer

@wellsie - Minor fixes here


New Feature: Focus Mode

Description
This introduces a new feature: Focus Mode. Focus Mode adds a toggle button on List Page, Create & Edit Page to hide/show other components on screen and just to focus on Table or Form component. You can customize whether you want to show it on List Page, Create Page and Edit Page (by default it will show on all three pages when enabled).
To enable it, in PanelProvider add ->focusMode():
public function panel(Panel $panel): Panel
    {
        return $panel
            ->default()
            ->id('admin')
            // .... other configurations
            ->focusMode();
    }

To disable it on List Page:
           ->focusMode(showOnListPage: false)

To disable it on Create Page:
           ->focusMode(showOnCreatePage: false)

To disable it on Edit Page:
           ->focusMode(showOnEditPage: false)

Visual changes
Before (List Page):

After (List Page):
Focus Mode Off

Focus Mode On

Before (Edit / Create Page):

After (Edit / Create Page):
Focus Mode Off

Focus Mode On

Screen Recording:
https://github.com/user-attachments/assets/93e8d741-7fb9-469b-b281-ac643dbeb341
Functional changes

[✓] Code style has been fixed by running the composer cs command.
[✓ ] Changes have been tested to not break existing functionality.
[ ] Documentation is up-to-date.

Documentation will be updated once this pull request is approved.

Thank you for contributing, @EzyHow!
While I do understand the use case of this feature, I think it's too opinionated to have in Filament core.
Since it's rather easy to add the same functionality using a plugin, I'm going to close this PR.
Feel free to let us know if you have any questions :)

Thank you for contributing, @EzyHow! While I do understand the use case of this feature, I think it's too opinionated to have in Filament core. Since it's rather easy to add the same functionality using a plugin, I'm going to close this PR.
Feel free to let us know if you have any questions :)

Basic idea behind this was to easily handle tables with large number of columns. If you think, it is too opinionated to have it in Filament core, I happily accept your decision and will create a plugin for it.

If it's just for tables, you may also set the max width of the page and make the sidebar collapsible.


[WIP] Bagger in production environment

What is this PR trying to achieve?
The METS bagger running on AWS and listening for jobs
https://github.com/wellcometrust/platform/issues/2635
Who is this change for?
Platform team, for anyone to be able to run sets of METS through the archive bagging service for testing

@tomcrane can we get this mergeable and add anything else in a different PR?

It should be mergeable now, still need at address @mklander's concern above, will look at that with @fractos


When creating line diffs do not split within an html entity

Fix #13342
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

Codecov Report

Merging #13357 into master will decrease coverage by 0.00%.
The diff coverage is 19.14%.

@@            Coverage Diff             @@
##           master   #13357      +/-   ##
==========================================
- Coverage   42.09%   42.09%   -0.01%
==========================================
  Files         689      689
  Lines       75856    75903      +47
==========================================
+ Hits        31935    31950      +15
- Misses      38687    38717      +30
- Partials     5234     5236       +2

Impacted Files
Coverage Δ

services/gitdiff/gitdiff.go
63.27% <19.14%> (-4.13%)
:arrow_down:

modules/util/timer.go
42.85% <0.00%> (-42.86%)
:arrow_down:

modules/charset/charset.go
68.53% <0.00%> (-4.50%)
:arrow_down:

modules/queue/workerpool.go
58.77% <0.00%> (-1.23%)
:arrow_down:

services/pull/pull.go
40.78% <0.00%> (-0.50%)
:arrow_down:

models/gpg_key.go
53.90% <0.00%> (+0.57%)
:arrow_up:

routers/repo/view.go
38.11% <0.00%> (+0.64%)
:arrow_up:

services/pull/patch.go
55.68% <0.00%> (+1.70%)
:arrow_up:

models/unit.go
49.31% <0.00%> (+2.73%)
:arrow_up:

services/pull/check.go
51.82% <0.00%> (+2.91%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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

I've uploaded a simple test for this

🚀


Native file dialog API?

Mostly a question, not a request.
There is often a very handy thing plugins want but it is hard and painful to implement right - native file dialogs.
Although LV2 has ways to specify a file, it involves tying it to an lv2 patch parameter.
It also only works to open files, not save them.
So I am wondering about your thoughts on such an API.
Telling people to go use the regular tiny libs for such things (like osdialog or tinyfiledialogs) is IMO a bad idea, as they are awful for plugins:

can block the main event loop
fork/exec strategy on linux, which does not always work
also on linux, requires gtk/kde extra tools (which can also change over time)

I think such a thing should exist, but is way out of scope for Pugl.  If the current ones aren't good they should be fixed or replaced.
Such a library could perhaps go in lv2kit, but certainly not in Pugl itself.
Personally I like the host-mediated way anyway.  Plugins should not be saving arbitrary files.


Migrate tests from ScalaTest to Munit: DecoderSuite

Add duplicated traits for LargeNumberDecoderTests, temporary
while we migrate the rest of existing tests until a next PR.

Looks good to me, thanks.


TypeError: Cannot read property 'stat' of undefined (examples/canvas)

Describe the Bug
examples/canvas doesn't work: when I open http://localhost:8080/, it begans loading forever.
Steps to Reproduce
git clone https://github.com/rustwasm/wasm-bindgen.git
cd examples/canvas
npm install

// A big tree of dependencies...

npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture<EMAIL_ADDRESS>npm WARN optional Skipping failed optional dependency /watchpack-chokidar2/chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture<EMAIL_ADDRESS>npm WARN optional Skipping failed optional dependency /webpack-dev-server/chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture<EMAIL_ADDRESS>npm WARN canvas No repository field.
npm WARN canvas No license field.

npm run serve
> @ serve /home/hirrolot/Desktop/wasm-bindgen/examples/canvas
> webpack-dev-server

🧐  Checking for wasm-pack...

✅  wasm-pack is installed.

ℹ  Compiling your crate in development mode...

✖ ｢wdm｣: TypeError: Cannot read property 'stat' of undefined
    at WasmPackPlugin._compile (/home/hirrolot/Desktop/wasm-bindgen/examples/canvas/node_modules/@wasm-tool/wasm-pack-plugin/plugin.js:120:24)
    at _checkWasmPack.then (/home/hirrolot/Desktop/wasm-bindgen/examples/canvas/node_modules/@wasm-tool/wasm-pack-plugin/plugin.js:66:23)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
    at Function.Module.runMain (module.js:695:11)
    at startup (bootstrap_node.js:188:16)
    at bootstrap_node.js:609:3
ℹ ｢wds｣: Project is running at http://localhost:8080/
ℹ ｢wds｣: webpack output is served from /
ℹ ｢wds｣: Content not from webpack is served from /home/hirrolot/Desktop/wasm-bindgen/examples/canvas
ℹ ｢wdm｣: wait until bundle finished: /
^C

Expected Behavior
https://rustwasm.github.io/wasm-bindgen/exbuild/canvas/

This looks like it's a bug in webpack or the WasmPackPlugin, not in this crate. If this shows up in this crate itself, though, please let me know!

Is this not relevant when the above-mentioned bug means that the listed example in this repo won't work?

If this isn't working for you it's likely due to https://github.com/rustwasm/wasm-bindgen/issues/1227 where to guarantee examples run they need to be copied out first.

Copying out the example doesn't work for me :/


Feature Request: Disable escaping HTML in toPrettyJSON (add toPrettyRawJson?)

Currently using toJSON functions in the Helm templates escapes HTML:
      {{- with .Values.store.limits }}
      store_limits: {{ toPrettyJson . | indent 6 }}
      {{- end }}

  limits:
    channels:
      foo.>:

Results in:
      store_limits:       {
        "channels": {
          "bar.\u003e": null
        }
      }

I'd say that since this function is used outside of the content of generating HTML, maybe escaping HTML should be disabled?
Output of helm version:
helm version
version.BuildInfo{Version:"v3.3.2", GitCommit:"e5077257b6ca106d1f65652b4ca994736d221ab1", GitTreeState:"dirty", GoVersion:"go1.15.2"}

Output of kubectl version:
kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T21:51:21Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.15", GitCommit:"2a313bf59aa0e1c98bbee2aea6ae727d3f6da6fd", GitTreeState:"clean", BuildDate:"2020-09-03T05:20:07Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):  AKS

@wallyqs Thanks for raising the issue. For clarification, are you saying the toPrettyJSON function is removing HTML escape characters?

The HTML escaping is a product of the default setting for the Go JSON encoder.
If you want to avoid it you can use toRawJson instead. That explicitly disables HTML escaping.

I know that it is due to Go JSON encoder defaults ;) toRawJson is not pretty though so would become a long string
store_limits:       {"channels":{"bar.>":null}}

instead of
      store_limits:       {
        "channels": {
          "bar.>": null
        }
      }

I think helm would likely never be used to output HTML so ok to disable as with toRawJSON? Or maybe have toPrettyRawJson?

Are there concerns of breaking backwards compatibility if we were to change the default JSON encoder settings? In other words, are there charts out there using toPrettyJson or toJson expecting this behaviour?
If we were to output raw strings, what would be the use of toJson vs toRawJson?

I'd say that there are actually a lot of charts using it out there unintentionally outputting JSON with escaped html (which is a very common format for automated still readable configuration), since it is a time saver over having to implement the complete schema: https://github.com/search?l=YAML&q=toPrettyJson&type=Code

@bacongobbler changing the default encoder would break backwards compat. This is part of sprig and it won't make that backwards breaking change. This is why toRawJson was introduced in the first place.

That's fair, sounds like toPrettyRawJson would fit better

Closing since stale, thanks!

Closing since stale, thanks!

If you run across this, here is a hacky equivalent of toPrettyRawJson I think:
{{- .Values.configmap.data | toPrettyJson | replace "\\u0026" "&" | replace "\\u003c" "<" | replace "\\u003e" ">" | nindent 4 }}


chore: exercise in nix overlays

This is mostly a (learning) experiment about how to use overlays and scoped package substitutions. Actually it is not that complicated :-)
Here I customise the logs package globally to not use js_of_ocaml.
But still I think that this can go in, so that we have a "tutorial" for future modifications.

Just doing some repo cleanup for better focussing on active work:
Closing PR as it seems inactive for a longer time. Please re-open if it is still relevant and after it has been updated with latest master changes.


Add include= kwarg to BigCommerceCheckoutsAPI

From the BigCommerce API docs:

include in query - string

cart.line_items.physical_items.options - physical options
cart.line_items.digital_items.options - digital options
consignments.available_shipping_options - shipping options
promotions.banners - promotion options

Rather than try to add a kwarg for each of these, instead we just have a single kwarg called include. You can pass it a list/tuple/etc. of strings, and it will join them and set them as the include query param. We now support this everywhere BigCommerce does in the checkout API.
# before
add_consignment(checkout_id, include_available_shipping_options=True)

# after
add_consignment(checkout_id, include=['consignments.available_shipping_options'])

include_available_shipping_options still works on the functions that previously supported it for backwards compatibility.

Honestly could add an @includable which adds the include arg and passes it into kwargs but idc


[ai-text-analytics] Changes for service GA, SDK preview.5

This PR contains all of the changes needed for preview.5 of Text Analytics, including migration to the GA endpoint.
There are a handful of changes here, all are in the changelog file.
Major changes to the API include:

Addition of warnings as a document response property
Renaming all instances of Collection to Array to indicate that they are true JS Arrays (CC @bterlson )
Removing grapheme-based properties (except in document statistics, where it has been renamed back to characterCount)

LGTM.
Could you also add the changes to the changelog?

/azp run js - textanalytics

/azp run js - textanalytics - tests

/azp run js - textanalytics - tests

/azp run js - textanalytics - tests

/azp run js - textanalytics - tests

/azp run js - textanalytics - tests


Any additional steps in case ADFS goes down?

I have PHS enabled on my federated domain. During a test, if ADFS goes down, authentication simply times out because ADFS is unreachable. Does AAD automatically detect that ADFS is down to then switch to authentication using PHS? If not, how can I (either manually or programmatically) switch authentication temporarily to use PHS as backup?

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

ID: 2ea0a363-ec5e-9efe-9b79-47aa3e6ba081
Version Independent ID: 29f1829b-6c53-7636-37a5-351a28a5b98b
Content: Tutorial:  Setting up PHS as backup for AD FS in Azure AD Connect
Content Source: articles/active-directory/hybrid/tutorial-phs-backup.md
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

@cap273 Thanks for your feedback! We will investigate and update as appropriate.

@cap273 I do not think fallback is automatic and you have to perform manual steps once adfs fails.  Please refer to blog for the details.

@cap273 We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


has-tip and mobile devices

I wonder if anybody else has come across this and (more usefully) found a solution?
When the has-tip class is applied to a link element, the code grabs any click action on mobile devices and displays the tooltip. Which is of course the normally desired action. But the problem I've found is that by grabbing the click it makes the link un-clickable, which is not desirable.
The only solution I've found so far is not to use has-tip on link elements, which may well be the only possible solution.
This behaviour may differ on some systems, I've been able to observe it on Opera Mobile and MicroB on my Nokia N900 and also on the Android browser running in the desktop emulator.
If there isn't a way round this it might be worth flagging up so other developers can avoid getting caught out.

Great point. What if, on mobile, the tooltip inherits the link and allows for custom link text via a data attribute?
My destination

For now, you can just set it up like this:
My destination

    My destination?

I think I understand what you mean about inheriting the link. Click to get the tooltip then click the tooltip to activate the link?
I can see that would work in principle, but I'm not convinced the annoyance to visitors of having to click twice to take the link would be worth what benefit the tooltip would bring in most cases.
I think for me at least, the way to go would be to adapt your hide-on-phones/show-on-phones suggestion so there's a tooltip on desktops but not on phones. So thanks for the idea.


[question] unsupervised classification

Is it possible with pysal, given a raster data with multi bands?

While we do have a Fisher-Jenks and friends set of functions for vector map classification, we don't really have tools to handle input-output of large raster data. I think your best bet is probably using something like Rasterio for IO and then passing the array of values to your favorite classification function, either our FJ classifier or something more like scikit-learn.


Linux .so file is executable

E.g. pdo_sqlsrv.so has 0755 perms.
Please consider setting 0644.
Thank you.

@szepeviktor are you downloading the released binaries or building the driver from source?

I was building it.
BTW I have Windows-feeling when downloading linux software in a ZIP.
--
+36204242498
Ezen a készüléken sok az elütés.
Elnézést!
On September 20, 2016 7:08:07 PM CEST, Hadis Fard<EMAIL_ADDRESS>wrote:

@szepeviktor are you downloading the released
binaries
or building the driver from source?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/Microsoft/msphpsql/issues/148#issuecomment-248366451

@szepeviktor we will ship the packages via tar.gz in the next release.

I failed to implement it.
Results
There is an m4 macro: PHP_SET_LIBTOOL_VARIABLE()
libtool has a config variable install_override_mode which could be set to 0644

I've found out that the linker produces the .so file with permissions 0755, fixed, not variable.
make "INSTALL=$(pwd)/build/shtool install -c --mode=0644" install instead of make install will do the job.
It is not nice.

One more thing the PHP_SUBST(varname) macro does:

Adds variable with it's value into Makefile, e.g.:
CC = gcc

Maybe I don't get the syntax right. This is foreign territory for me.
INSTALL='$(top_srcdir)/build/shtool install -c --mode=0644'
PHP_SUBST(INSTALL)

@szepeviktor in the Makefile the mode is set to 644,  INSTALL = $(top_srcdir)/build/shtool install -c INSTALL_DATA = $(INSTALL) -m 644. The permissions also depends on the permission of the user type (root and local user) and the ownership of the directories, also you can change the permission using chmod as well.


It navigates to an incorrect page after clicking 'here' on 'Release Note -> Windows ARM64 Preview' part

Storage Explorer Version: 1.34.0-dev (98)
Build Number: 20240507.1
Branch: rel/1.34.0
Platform/OS: Windows 10/Linux Ubuntu 22.04/MacOS Sonoma 14.4.1(Apple M1 Pro)
Architecture: x64/x64/arm64
How Found: From running test cases
Regression From: Not a regression
Steps to Reproduce

Open 'Release Notes' -> Go to 'Windows ARM64 Preview' part.
Click the hyperlink 'here'.
Check whether navigates to the correct page.

Expected Experience
Navigate to the correct page.
Actual Experience
Navigate to below page.

This link will not be setup to work properly until right as we are releasing.

I've pre set the fwd link to go to https://github.com/microsoft/AzureStorageExplorer/releases/download/v1.34.0/StorageExplorer-windows-arm64.exe. It 404's right now, but will later not. Closing this.


Hide direct api usage of polkadot/js

We should not use direct call from polkadot/js to avoid coupling

[x] This issue tries to do that for native token balance fetching

This issue refactors balance fetching logic, this will affect

[ ] Showing balance of all types of tokens
[ ] Showing free balance in transaction screens

Version test: http://<IP_ADDRESS>:8900/s/isMFWnAZ2iYQpqZ
Validation passed.

Showing balance of all types of tokens on all accounts
Showing balance of all types of tokens on single account
Showing balance of all types of tokens upon switching/deleting/adding account
Showing free balance in transaction screens


Cannot access to the account in any way

I lost the access to the main account on Nuget
I no longer have access to the email address associated with the account they used to publish the packages.
The domain has expired.
Please, can you help me to recover it?
Thank you.

@matteomigliore , please send us an e-mail to 'support at nuget.org' with details about the name of your account and we will help you recover it!

@skofman1 yes, you are tight, but No one has answered for 10 days!

@matteomigliore , I see that we responded to your e-mail on Jan 28th. Please check your inbox for e-mails from admin at nuget.org.

Hi Svetlana,
I cannot access to the emails linked to the domani because has not been
renewed.
Is there another way to solve?
Thank you.
Matteo Migliore
CEO - LEGALDESK
Cellulare 327 311 37 91
Il ven 5 feb 2021, 19:37 Svetlana Kofman<EMAIL_ADDRESS>ha
scritto:

@matteomigliore https://github.com/matteomigliore , I see that we
responded to your e-mail on Jan 28th. Please check your inbox for e-mails
from admin at nuget.org.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/NuGetGallery/issues/8408#issuecomment-774214142,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADJWTUZSAYCRJBMO4VCXSTS5Q3GLANCNFSM4W7KR6QA
.

@matteomigliore We have started the process to hand the account over to you.
If we have not received a reply from the email on the account in a few more days, we will help fix the email address on the account.
Sorry that this has taken so long.
We appreciate your patience.

Hi @ryuyu, it's been 5 days, do I have any hope of recovering my account? In total I have been waiting for 20 days.
Thank you.

@matteomigliore We are now ready to help you claim the account.
However, we have received no reply on any of the mails we have sent to you.
Could you send an email to<EMAIL_ADDRESS>from the email that you would like to claim the account to?
Please include my name in either the subject or the body of the mail.
We will need this to continue to process.
Thanks again for bearing with us while we work through this.

Hi @ryuyu ok, I send you the email. Thank you.

@matteomigliore I have update the account to the email address you provided.
You should be able to use the Reset Password procedure (https://docs.microsoft.com/en-us/nuget/nuget-org/nuget-org-faq#how-to-recover-nugetorg-password-login) to complete the reclaim of the account.
Please let me know if you continue to have difficulty.
Thanks for the your patience!

Hi, I don't see the packages from none of my accounts.
Thank you.

Thank you guys.
Now all is fixed. Good job.


Uncaught TypeError: validateEventDispatches is not a function

[Enter steps to reproduce below:]

Open up Atom Beta on OSX ( 1.8.0-beta1 )
watch app keep prompting about type error

Atom Version: 1.8.0-beta1
System: Mac OS X 10.11.4
Thrown From: go-debug package, v0.1.12
Stack Trace
Uncaught TypeError: validateEventDispatches is not a function
At /Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/EventPluginUtils.js:99

TypeError: validateEventDispatches is not a function
    at Object.executeDispatchesInOrder (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/EventPluginUtils.js:99:5)
    at executeDispatchesAndRelease (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/EventPluginHub.js:42:22)
    at executeDispatchesAndReleaseTopLevel (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/EventPluginHub.js:53:10)
    at Array.forEach (native)
    at forEachAccumulated (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/forEachAccumulated.js:24:9)
    at Object.EventPluginHub.processEventQueue (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/EventPluginHub.js:215:7)
    at runEventQueueInBatch (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/ReactEventEmitterMixin.js:18:18)
    at Object.ReactEventEmitterMixin.handleTopLevel [as _handleTopLevel] (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/ReactEventEmitterMixin.js:29:5)
    at handleTopLevelImpl (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/ReactEventListener.js:73:24)
    at ReactDefaultBatchingStrategyTransaction.Mixin.perform (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/Transaction.js:136:20)
    at Object.ReactDefaultBatchingStrategy.batchedUpdates (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/ReactDefaultBatchingStrategy.js:63:19)
    at Object.batchedUpdates (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/ReactUpdates.js:97:20)
    at ReactEventListener.dispatchEvent (/Users/jdyer/.atom/packages/go-debug/node_modules/react-for-atom/node_modules/react/lib/ReactEventListener.js:150:20)

Commands
     -2:22.1.0 settings-view:check-for-package-updates (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)
     -1:55.1.0 core:close (div.panels-item)
  2x -1:46.6.0 find-and-replace:select-next (atom-text-editor.editor.is-focused)
     -1:45 editor:duplicate-lines (atom-text-editor.editor.is-focused)
  2x -1:44 editor:delete-to-end-of-subword (atom-text-editor.editor.is-focused)
     -1:39.4.0 editor:duplicate-lines (atom-text-editor.editor.is-focused)
     -1:16.9.0 settings-view:open (atom-text-editor.editor.is-focused)
     -1:11.2.0 core:select-all (atom-text-editor.editor.mini.is-focused)
     -0:47.8.0 go-debug:stop (atom-text-editor.editor.is-focused)
     -0:04.8.0 go-debug:toggle-panel (atom-text-editor.editor.is-focused)

Config
{
  "core": {}
}

Installed Packages
# User
atom-prism, v0.1.2
autocomplete-go, v1.1.0
builder-go, v1.0.0
dockerletion, v0.2.0
environment, v1.2.0
go-config, v1.1.4
go-debug, v0.1.12
go-get, v1.0.3
go-plus, v4.1.0
gofmt, v1.1.6
gometalinter-linter, v1.1.0
gorename, v1.0.2
language-docker, v1.1.6
linter, v1.11.4
linter-docker, v0.1.2
linter-golinter, v1.2.0
navigator-godef, v1.0.3
pretty-json, v1.2.0
tester-go, v1.0.4

# Dev
No dev packages

seems to be the same problem as in https://github.com/facebook/nuclide/issues/463 ...
unfortunately no solution yet ...

react-for-atom v15.0.2-1 fixed https://github.com/facebook/nuclide/issues/463. Try updating this package to v15.0.2-1 and see if this problem persists.

seems to be fixed with the new react version! (a4e227bc692114afec8a1881f99535f3c541e94e)


Implement an MVP of the OTP ets interface

There are cases where AtomVM could benefit from ets tables.
This task would involve implementing a “minimal viable product” for ets in AtomVM.  In essence, the minimal implementation should support the ets (unordered) set type, with operations for insertion, lookup, and deletion.  Support for sharing tables across processes with support for read-concurrency is desirable, but not strictly needed for the MVP.
Implemented functions of ets (with caveats)would include (but may not necessarily be limited to) the following:

ets:new/2 with support for the set type, key_pos, named_table, private, public, and protected access, and read_concrrency (opportunistic)
ets:member/2
ets:insert/2 and ets:insert_new/2
ets:lookup/2 and ets:lookup_element/3
ets:delete/2 and ets:delete_all_objects/1
ets:tab_to_list/1
ets:whereis/1

The implementation should be done as a Bif (I think) and should preserve the same behavior as OTP — specifically, terms that are stored in ets tables should be copied from the process heap into implementation-defined storage (e.g., a heap fragment, or even a (compressed?) encoded term.

I'm unable to get gleam/mist running due to a dependency on ets:lookup_element/3 .
Does anyone intend to push the rest of this work forward?
I fully understand the unfortunate circumstances around it being partially completed, so forgive me for asking.
I'm trying to understand if I need to start learning C to help do so.


Add a simple demo app to core demos that we can use to test IE

Summary

What is the change?

Add a simple demo app to the core demos that we can use to test the web components in IE.
The app can be empty. We can add what we want to it locally for testing.
We should be able to launch it for local IE testing from terminal.
The app doesn't have to be on a framework. This is left to the implementer's discretion.

Why should it go in Clarity?

Storybook is a pita to run locally in IE.

Does this change impact existing behaviors? If so how?

Nope.

Given that our IE11 testing matrix for Core ends with version 4. Is this still a priority?

@coryrylan

No longer needed.


Refactor of files structure in components directories

Refactor of files structure in components directories to improve developer experience.
New structure pattern:
src/
└── components/
    └── Button/
        ├── Button.helpers.ts
        ├── Button.types.ts
        ├── Button.tsx
        └── index.ts
    └── Tile/
        ├── Tile.types.ts
        ├── Tile.tsx
        ├── TileCover.tsx
        └── index.ts

Additional file with types *.types.ts should be added if  lines amount  is larger than 40.
*.helpers.ts should contains utility tools dedicate for component.

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


L8 catalog use Extent schema not envelope

Fix #190
Signed-off-by: Jason T. Brown<EMAIL_ADDRESS>

travis build fails because of python 2 but setup has requirement for python 3

Mergin'


Add Chef Compliance support to the Reckoner

Other than my nit re: license.count, the :shipit: would like to see this :ship:'d

:shipit: squirrel restates his desire for this to be :ship:'d based on recent changes.


Follow and consider if mega-linter could be a working/safe alternative to super-linter

https://nvuillam.github.io/mega-linter/
https://nvuillam.github.io/mega-linter/#mega-linter-vs-super-linter

Mega-Linter can automatically apply fixes performed by linters, and push them to the same branch, or create a Pull Request that you can validate
This is pretty handy, especially for linter errors related to formatting (in that case, you don’t have any manual update to perform)

I'm here to help if you have any question :)


dsmr 4.2 datagram every 10 seconds from p1

The issue is that the EVSE also has a 10 second delay to require new API data for L1/L2/L3.
What happens is that the charging stops and starts randomly because of missing API information.
I would like to extend the delay in EVSE to 12 seconds before charging stops when no API data is received. This provides enough margin for the p1 data to be processed.

I will contact the energy provider to see if I can upgrade my meter to dsmr v5.

Alternatively you could install one of the supported modbus-kWh meter in your panel. You wouldnt need the Sensorbox in that case.

I suppose the timeout could be a bit longer than 10 seconds. Most main breakers have C-characteristics and will only trip after being overloaded for minutes at a time. I figured this out while charging in Normal mode by accident and all breakers surviving, even while loading it with 32A for minutes at a time.  I guess making it configurable is even better.
Then again, if you set it through API you could also easily have your automation software send a new value more frequently, even if it's the older value. Just make sure it will stop sending values if there obviously is a communication problem between the P1 meter and your automation software.

I currently only send mainmeter values through the api when I actually receive data from p1 signal. I could store the last value and send data more frequently but I think this is bad practice, when p1 meter stops working but I keep sending the data because it is stored there can be unwanted situation. Now when p1 stops I also stop sending and the smartevse will error out correctly. I have been running with a timeout of 12 seconds, it does work. But I have contacted my energy company and they will exchange my meter for a dsmr v5 meter. They say it will take a few months due to shortages.


feat(#161): Replace Old Constructor Invocations

Replace old constructors invokations with new one.
Closes: #161.

History:

feat(#161): ugly implementation of instruction replacement for constructors
feat(#161): try to compare XML nodes correctly
feat(#161): build correct XML nodes for instructions
feat(#161): compare instructions opcodes
feat(#161): precise XML node comparision
feat(#161): print information about inserted instructions into methods
feat(#161): Make XmlMethod stateful
feat(#161): update XML after inlining constructors
feat(#161): fix setInstructions method
feat(#161): correct replacement algorithm
feat(#161): replace INVOKESPECIAL for constructors
feat(#161): prepare unit test for XmlInstruction comparision
feat(#161): fix XmlInstruction comparision
feat(#161): Finish with correct integration test
feat(#161): fix all qulice suggestions
feat(#161): add more puzzles

PR-Codex overview
This PR focuses on improving the XML representation in the XmlClass, XmlMethod, and XmlInstruction classes.
Detailed summary

Added a node() method in XmlClass and XmlMethod to expose the internal XML node.
Added a setInstructions() method in XmlMethod to update the method instructions.
Added equals(), hashCode(), and toString() methods in XmlInstruction.
Refactored the nodesAreEqual() method in XmlInstruction for better readability.

The following files were skipped due to too many changes: src/main/java/org/eolang/jeo/improvement/ImprovementDistilledObjects.java

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor merge

@rultor merge

@volodya-lombrozo Done! FYI, the full log is here (took me 3min)


type attribute doesn't work with custom exceptions

I have a Swagger annotated class:
import { ApiProperty } from '@nestjs/swagger';

export class BaseExceptionTemplate {
  @ApiProperty({required: true,type: Number})
  statusCode: number;

  @ApiProperty({required: false, type: Number})
  clientCode: string;

  @ApiProperty({required: true, type: String})
  message: string;

  @ApiProperty({required: false, type: [String]})
  errors: string[];

  @ApiProperty({required: false,type: String})
  path: string;

  @ApiProperty({required: false,type: String,})
  timestamp: string;
}

My controller method is the following:
  @Post('/register')
  @ApiOperation({ summary: 'Registra um novo usuário' })
  @ApiResponse({
    status: 201,
    description:
      'Usuário registrado com sucesso. Um e-mail com instruções será enviado para o endereço cadastrado.',
  })
  @ApiException(() => ClienteNaoEncontradoException, {type: () => BaseExceptionTemplate})
  @ApiException(() => ClienteJaCadastradoException, {type: () => BaseExceptionTemplate})
  @ApiException(() => LigacaoNaoEncontradaException, {type: () => BaseExceptionTemplate})
  @ApiException(() => EmailJaCadastradoException, {type: () => BaseExceptionTemplate})
  @ApiException(() => ValidationFailedException, {type: () => BaseExceptionTemplate})
  register(@Body() registerDto: RegisterDto) {
    throw new NotImplementedException('Not yet implemented!');
  }

The final Swagger example contains only this:
{
  "statusCode": 409,
  "message": "E-mail já cadastrado",
  "error": "E-mail já cadastrado"
}

Shouldn't it resemble the annotated class?

Hi @lzkill, thank you for reporting the issue.
The type is indeed missing in the Swagger example value. We'll take a look at this issue soon :)
I have a question regarding the usage of type here: Do you want to override the whole template with BaseExceptionTemplate which will be shown in Swagger UI or just the message property?
In the current implementation of the decorator, the type is attached to the message property:

The example value then contains the statusCode twice. Is this intended by you? :)

Hi @jsproede. How are you? Yes, I was trying to override the whole template. This would be a clean way to define the structure to show on the GUI. What are you thoughts on this?

@lzkill You're right. We'll take a look at this, because currently the type is attached to message it would be a breaking change if we'd release a new version which uses the type as main example/schema value :)

I think this would be awesome! That definitely fills the gap with the whole @ApiException thing.

Hi @lzkill. The issue with missing example response values specified with type property has been fixed and will be available in the next version :) I've moved the usage of Swagger annotated classes together with the template property into a new issue.


Fix test name typos

Terrible typo on my part.
:eyes: @sgnr @davidcornu

Shame on us reviewers for not having caught that :shipit:

Fix the new typo that replaced the old typo :trollface: and :shipit:


pyo3-build-config: Build "abi3" extensions without an interpreter

Ignore the build host Python interpreter configuration when
compiling portable "abi3" extension modules.
Such extensions should not depend on a concrete Python version
or build configuration by design.
Maturin already does this when building "abi3" extension wheels
by defining PYO3_NO_PYTHON=1 for Cargo when an abi3-py3*
feature is detected.
Closes #2292

The only concern is cases like cryptography, where I think they build using abi3-py36 yet also need to query the interpreter to get SSL information etc. - see https://github.com/pyca/cryptography/pull/6695#discussion_r767289574 and #2092

The only concern is cases like cryptography, where I think they build using abi3-py36 yet also need to query the interpreter to get SSL information etc. - see pyca/cryptography#6695 (comment) and #2092

Oh, I can now see how this will break things like https://github.com/aganders3/hello-pyo3-build-config/blob/main/build.rs when an abi3-py3* feature is enabled.
I'll try a different approach then: making PyO3 not fail the build when the default Python interpreter is not found or too old or otherwise unusable, but the extension module can still be built without it. It will at least prevent unnecessary build failures like this: https://github.com/PyO3/maturin/pull/875#issuecomment-1090045846.