device compliance question for partially implemented standard extensions

If a designer implements a device which supports

Machine Privilege
RISCV32 I
RISCV32 M (Multiply instructions, but no Divide)

Is the device compliant RV32I ?
Is the device compliant RV32IM ?
thanks
Simon Davidmann, Imperas

I think the litmus test is, does the corresponding compliance suite run? A
device that cannot execute the DIV instruction cannot claim to implement
the M extension, but implementing only a subset of the M extension is a
perfectly valid thing to do, and doesn’t break RV32I compliance.
On Wed, Jul 17, 2019 at 7:44 AM Simon Davidmann<EMAIL_ADDRESS>wrote:

If a designer implements a device which supports

Machine Privilege
RISCV32 I
RISCV32 M (Multiply instructions, but no Divide)

Is the device compliant RV32I ?
Is the device compliant RV32IM ?
thanks
Simon Davidmann, Imperas
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAH3XQUOZT5EYGRV333FC3DP74V6PA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G7YKHKQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH3XQW4OK6XEWIAWKOMXATP74V6PANCNFSM4IERF6UQ
.

What if divides get invisible traps and are emulated by the EE?  Does the compliance suite test the EE or the underlying hardware?

@aswaterman
what if the MUL opcode is re-used as a custom op by device? Would you still consider it to be RISC-V compliant? If not then you need tests to verify that the absence of a standard extension undergoes a trap, in which case implementing a subset of M would deem non-compliance.

Emulation via invisible traps is intended to be a valid approach—though if
the execution environment is bare-metal M-mode, can a trap to M-mode
possibly be invisible?
On Wed, Jul 17, 2019 at 10:44 AM Paul Donahue<EMAIL_ADDRESS>wrote:

What if divides get invisible traps and are emulated by the EE? Does the
compliance suite test the EE or the underlying hardware?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAH3XQTGH5V57ATFSX2FWQ3P75LAFA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2F5JKY#issuecomment-512480427,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH3XQXHJG74IBZQ2WHJ7ULP75LAFANCNFSM4IERF6UQ
.

If the MUL opcode doesn’t do what the spec says the MUL opcode does, then
it’s obviously noncompliant with the M extension, but it could still be
compliant with RV32I.
On Wed, Jul 17, 2019 at 10:49 AM Neel Gala<EMAIL_ADDRESS>wrote:

@aswaterman https://github.com/aswaterman
what if the MUL opcode is re-used as a custom op by device? Would you
still consider it to be RISC-V compliant? If not then you need tests to
verify that the absence of a standard extension undergoes a trap, in which
case implementing a subset of M would deem non-compliance.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAH3XQUOEBJYGRPNG6OQFZ3P75LTHA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2GAIHI#issuecomment-512492573,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH3XQXZ364U4UNJRR3JGFLP75LTHANCNFSM4IERF6UQ
.

Emulation via invisible traps is intended to be a valid approach—though if
the execution environment is bare-metal M-mode, can a trap to M-mode
possibly be invisible?

How about an implementation with two modes, one unprivileged and one non-standard privileged which emulates divides that are invisibly trapped from the unprivileged mode?  There can obviously be no standard compliance tests for the non-standard privileged architecture but there must be a way to test compliance of the standard-compliant unprivileged mode.
Is this true: The compliance suite must declare an implementation that invisibly traps and emulates divides as compliant.  The compliance suite tests the EE, not the hardware.

I agree with that sentiment, Paul, but I don't actually know what the
current compliance suite does.
On Wed, Jul 17, 2019 at 11:05 AM Paul Donahue<EMAIL_ADDRESS>wrote:

Emulation via invisible traps is intended to be a valid approach—though if
the execution environment is bare-metal M-mode, can a trap to M-mode
possibly be invisible?
How about an implementation with two modes, one unprivileged and one
non-standard privileged which emulates divides that are invisibly trapped
from the unprivileged mode? There can obviously be no standard compliance
tests for the non-standard privileged architecture but there must be a way
to test compliance of the standard-compliant unprivileged mode.
Is this true: The compliance suite must declare an implementation that
invisibly traps and emulates divides as compliant. The compliance suite
tests the EE, not the hardware.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAH3XQUGKPOM4JF3HVZO2HDP75NOVA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2GDNFQ#issuecomment-512505494,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH3XQTXAVIJFT7HKVVIVQ3P75NOVANCNFSM4IERF6UQ
.

I don't think the compliance suite will declare an emulation of an instruction op as compliant to that op.
Please see here for more info .

Is this true: The compliance suite must declare an implementation that invisibly traps and emulates divides as compliant. The compliance suite tests the EE, not the hardware.

I went through the current definitions of standard, reserved, custom, non-standard, and non-conforming extensions. I believe then the compliance suite should only check for standard-extension compatibility and shouldn't worry about the existence/absence of the remaining. Would you agree?
So a device with standard RV32I and non-conforming RV32M extensions can still be called a valid RISC-V device supporting RV32I.
Thanks :)

If the MUL opcode doesn’t do what the spec says the MUL opcode does, then it’s obviously noncompliant with the M extension, but it could still be compliant with RV32I.

Absolutely: it would be conforming to RV32i - but not to necessarily to a platform that requires RV32IM (i.e. that programs that use MUL and DIV ops work correctly) So this comes down to whether compliance should test compliance to a spec, or to a platform. If the implementation either traps correctly MUL/DIV (illegal op) or executes MUL/DIV correctly - its compliant to that platform.
The real issue is that we don't necessarily have infrastructure to test partial implementations. That would require changes to the reference model to specify to it which ops are implemented in HW (and/or which give illegal op traps), and associated changes/additions to the test suite and framework. (adding illegal opcode traps)

I can't find anything about the following in the spec document, but I remember conversations at a RISC-V workshop where it was discussed to use the Y-prefix for when a core supports individual instructions from extensions. E.g. RV32I_Ymul_Ymulh_Ymulhsu_Ymulhu. @aswaterman Is this still (was it ever) the plan?

I forgot where we came down on that.  @kasanovic?

I would like to ask a more fundamental question which is the following:
I am aware of an implementation which has "re-purposed" an instruction decode in the standard extension space, let us say for purpose of this example, it is the MUL operation
if a device is tested to be compliant to RV32I but contains (hidden) decodes matching some instructions from another standard extension eg RV32IM(MUL), then is it truly RV32I ?
Does the inclusion of a set, explicitly define the exclusion (complement) of all others ?
in which case, is RV32(extensions) defined as:
a) contains RV32(extensions) instructions, and no other instructions, or
b) contains RV32(extensions) instructions.
If the definition is (a) then (for example) portable code could be written using MUL/DIV instructions to execute on either a device reported as I or IM, by including a trap handler to impement MUl/DIV using I only instructions
on I the MUL/DIV will trap and emulate
on IM the MUL/DIV will execute in hardware
if the definition is (b) then the code can never be portable as the incorrect (and non-declared) implementation of the MUL operation, will cause a functional difference, and so the execution results cannot be deterministic
I apologize in advance if this question seems irrelevent, but it is important in terms of compliance testing to define whether compliance testing should detemine whether a devide provides a

definitive set of capabilities for a given device, or
a potentially incomplete subset of observed capabilities

I started replying without re-reading the specs, then re-read Section 1.3, which was useful.
The base ISA explicitly defines as "non-conforming" a non-standard extension that uses standard or reserved encodings.  It seems clear enough that implementing a subset of a standard extension is a non-standard extension (though that might be specified explicitly), and by definition non-conforming because it uses standard encodings.  Is that a correct interpretation?
If a "conforming implementation" is defined as an implementation without any non-conforming extensions.  Then, if a standard extension is not present on a conforming implementation, attempting to execute any of that extension's standard encodings must not result in anything that might be interpreted as a custom extension, including NOP or custom traps.  Although nowhere made explicit, it seems the only valid behavior provided for in the privileged spec is the illegal instruction trap.  Anything else might be taken as a non-conforming extension.  Again, is this a correct interpretation?
The first part means RV32I + multiply is non-conforming.
If it implements MISA (non-zero), MISA.X must be set, as the multiply alone is a non-standard extension.  If MISA.X is writable, the obvious interpretation is that clearing it disables all non-standard extensions including the multiply; and in that case, RV32IM can always be emulated even if the hardware multiply isn't implemented correctly.
(Is this a correct interpretation?)
So although notionally RV32I says nothing about instructions outside those it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be written as zero, it seems the compliance testsuite can indeed verify that all standard and reserved encodings outside those configured take an illegal instruction trap.
(One more time -- Is this a correct interpretation?  :)
Might it be useful to additionally define some terms to help classify conformance.

"Conditional conformance" -- Non-conformant implementations that can be made conformant by clearing MISA.X.  These and fully conformant implementations can emulate any standard extensions.

"Partial conformance" -- Non-conformant extensions that correctly implement a subset of a standard extension, and trap on the rest, allowing the full standard extension to be emulated.  This is independent from conditional conformance.

It seems reasonably straightforward for a compliance test suite to test full and conditional conformance.  Partial conformance is easy enough to test for standard extensions that don't add state (A, B, M, etc) by including full emulation routines which presumably already exist somewhere -- whatever the implementation doesn't cover gets emulated.  Standard extensions that add state (F, D, H, etc) are not so easily amenable to standard testing, because emulation varies according to what states hardware implements.  For example, an implementation that provides partial F support and emulates the rest likely needs to provide FCSR, and use that rather than an emulated copy to emulate the rest.

That's a really good analysis.
I think that if the reference model and framework can be augmented to
fully label what is implemented in  "HW", and what is not, then partial
conformance can be checked as well. I doh't think partial-F is really very
different than partial-M (e.g Mul without Div). It does require that FCSR
be correctly implemented for the ops that are supported (and FS in
MCSR.both of which follows from the fact that those ops are supported and
those are basically extra result bits)) , but shouldn't be any more than
that.
Am I missing something?
On Thu, Jul 18, 2019 at 9:52 AM Marc Gauthier<EMAIL_ADDRESS>wrote:

I started replying without re-reading the specs, then re-read Section 1.3,
which was useful.
The base ISA explicitly defines as "non-conforming" a non-standard
extension that uses standard or reserved encodings. It seems clear enough
that implementing a subset of a standard extension is a non-standard
extension (though that might be specified explicitly), and by definition
non-conforming because it uses standard encodings. Is that a correct
interpretation?
If a "conforming implementation" is defined as an implementation without
any non-conforming extensions. Then, if a standard extension is not present
on a conforming implementation, attempting to execute any of that
extension's standard encodings must not result in anything that might be
interpreted as a custom extension, including NOP or custom traps. Although
nowhere made explicit, it seems the only valid behavior provided for in the
privileged spec is the illegal instruction trap. Anything else might be
taken as a non-conforming extension. Again, is this a correct
interpretation?
The first part means RV32I + multiply is non-conforming.
If it implements MISA (non-zero), MISA.X must be set, as the multiply
alone is a non-standard extension. If MISA.X is writable, the obvious
interpretation is that clearing it disables all non-standard extensions
including the multiply; and in that case, RV32IM can always be emulated
even if the hardware multiply isn't implemented correctly.
(Is this a correct interpretation?)
So although notionally RV32I says nothing about instructions outside those
it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be
written as zero, it seems the compliance testsuite can indeed verify that
all standard and reserved encodings outside those configured take an
illegal instruction trap.
(One more time -- Is this a correct interpretation? :)
Might it be useful to additionally define some terms to help classify
conformance.

"Conditional conformance" -- Non-conformant implementations that can
be made conformant by clearing MISA.X. These and fully conformant
implementations can emulate any standard extensions.
"Partial conformance" -- Non-conformant extensions that correctly
implement a subset of a standard extension, and trap on the rest, allowing
the full standard extension to be emulated. This is independent from
conditional conformance.
It seems reasonably straightforward for a compliance test suite to test
full and conditional conformance. Partial conformance is easy enough to
test for standard extensions that don't add state (A, B, M, etc) by
including full emulation routines which presumably already exist somewhere
-- whatever the implementation doesn't cover gets emulated. Standard
extensions that add state (F, D, H, etc) are not so easily amenable to
standard testing, because emulation varies according to what states
hardware implements. For example, an implementation that provides partial F
support and emulates the rest likely needs to provide FCSR, and use that
rather than an emulated copy to emulate the rest.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AHPXVJVKNG3TIOYS6PRCJETQACNVTA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JDP5I#issuecomment-512899061,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHPXVJV5YFMZ3CVDAV4BBADQACNVTANCNFSM4IERF6UQ
.

On Thu, Jul 18, 2019 at 9:52 AM Marc Gauthier<EMAIL_ADDRESS>wrote:

I started replying without re-reading the specs, then re-read Section 1.3,
which was useful.

I agree.
The base ISA explicitly defines as "non-conforming" a non-standard

extension that uses standard or reserved encodings. It seems clear enough
that implementing a subset of a standard extension is a non-standard
extension (though that might be specified explicitly), and by definition
non-conforming because it uses standard encodings. Is that a correct
interpretation?

Sounds good to me.
I'm concerned with the declaration in 1.3 that "custom extensions are not
non-conforming" because:

custom extensions are not defined
if it means "non-standard extensions" then this statement is clearly not
true because it depends on which encodings each extension uses.

If a "conforming implementation" is defined as an implementation without

any non-conforming extensions.

It doesn't say that anywhere but it sounds reasonable.  Then let's also
assume that the compliance suite should be checking for whether the test
target is a conforming implementation and it should fail if not.
Then, if a standard extension is not present on a conforming

implementation, attempting to execute any of that extension's standard
encodings must not result in anything that might be interpreted as a custom
extension, including NOP or custom traps. Although nowhere made explicit,
it seems the only valid behavior provided for in the privileged spec is the
illegal instruction trap. Anything else might be taken as a non-conforming
extension. Again, is this a correct interpretation?

Can you point me to somewhere that says that reserved and/or custom
encodings that are unimplemented are required to trap (or to exhibit any
particular behavior at all)?  I see lots of specific examples of required
illegal instruction traps when accessing certain CSRs and whatnot but not
the blanket statement I've seen in other architectures.  I think that there
is no such requirement, though I'd like to be proven wrong since it would
simplify things.
This message from Krste specifically says that if Zifencei isn't
implemented then FENCE.I doesn't have to trap (though traps are "highly
recommended"):
https://lists.riscv.org/g/tech-privileged/message/6
(Also relevant to this conversation, it says that the compliance suite
shouldn't test for FENCE.I if Zifencei isn't implemented.)
The first part means RV32I + multiply is non-conforming.

If it implements MISA (non-zero), MISA.X must be set, as the multiply
alone is a non-standard extension. If MISA.X is writable, the obvious
interpretation is that clearing it disables all non-standard extensions
including the multiply; and in that case, RV32IM can always be emulated
even if the hardware multiply isn't implemented correctly.
(Is this a correct interpretation?)

I can agree with that, though the two "if" statements substantially reduce
the impact of this observation.

So although notionally RV32I says nothing about instructions outside those
it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be
written as zero, it seems the compliance testsuite can indeed verify that
all standard and reserved encodings outside those configured take an
illegal instruction trap.
(One more time -- Is this a correct interpretation? :)

Only if unimplemented encodings are required to take an illegal instruction
trap.

Might it be useful to additionally define some terms to help classify
conformance.

"Conditional conformance" -- Non-conformant implementations that can
be made conformant by clearing MISA.X. These and fully conformant
implementations can emulate any standard extensions.
"Partial conformance" -- Non-conformant extensions that correctly
implement a subset of a standard extension, and trap on the rest, allowing
the full standard extension to be emulated. This is independent from
conditional conformance.
It seems reasonably straightforward for a compliance test suite to test
full and conditional conformance. Partial conformance is easy enough to
test for standard extensions that don't add state (A, B, M, etc) by
including full emulation routines which presumably already exist somewhere
-- whatever the implementation doesn't cover gets emulated. Standard
extensions that add state (F, D, H, etc) are not so easily amenable to
standard testing, because emulation varies according to what states
hardware implements. For example, an implementation that provides partial F
support and emulates the rest likely needs to provide FCSR, and use that
rather than an emulated copy to emulate the rest.

Those terms can be defined but I'm not sure they can be tested without a
trap requirement.  This lack of a trap requirement really complicates a lot
of things for a test suite that has to run on any legal implementation.
Thanks,
-Paul

Partial F is perhaps likely to always implement all of FCSR, making it easy
enough to provide a version of FP emulation that assumes a hardware FCSR.
Maybe a better example is the hypervisor (H) extension.  It adds lots of
state,
lots of bitfields across a large number of CSRs.  The possible combinations
of implementing only a portion of the H extension are immense, and many
may affect what emulation must do.  Not so easy to test in a standard way.
-M
Allen Baum wrote on 2019-07-18 17:34:

That's a really good analysis.
I think that if the reference model and framework can be augmented to
fully label what is implemented in "HW", and what is not, then partial
conformance can be checked as well. I doh't think partial-F is really very
different than partial-M (e.g Mul without Div). It does require that FCSR
be correctly implemented for the ops that are supported (and FS in
MCSR.both of which follows from the fact that those ops are supported and
those are basically extra result bits)) , but shouldn't be any more than
that.
Am I missing something?
On Thu, Jul 18, 2019 at 9:52 AM Marc Gauthier<EMAIL_ADDRESS>wrote:

I started replying without re-reading the specs, then re-read
Section 1.3,
which was useful.
The base ISA explicitly defines as "non-conforming" a non-standard
extension that uses standard or reserved encodings. It seems clear
enough
that implementing a subset of a standard extension is a non-standard
extension (though that might be specified explicitly), and by definition
non-conforming because it uses standard encodings. Is that a correct
interpretation?
If a "conforming implementation" is defined as an implementation without
any non-conforming extensions. Then, if a standard extension is not
present
on a conforming implementation, attempting to execute any of that
extension's standard encodings must not result in anything that might be
interpreted as a custom extension, including NOP or custom traps.
Although
nowhere made explicit, it seems the only valid behavior provided for
in the
privileged spec is the illegal instruction trap. Anything else might be
taken as a non-conforming extension. Again, is this a correct
interpretation?
The first part means RV32I + multiply is non-conforming.
If it implements MISA (non-zero), MISA.X must be set, as the multiply
alone is a non-standard extension. If MISA.X is writable, the obvious
interpretation is that clearing it disables all non-standard extensions
including the multiply; and in that case, RV32IM can always be emulated
even if the hardware multiply isn't implemented correctly.
(Is this a correct interpretation?)
So although notionally RV32I says nothing about instructions outside
those
it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be
written as zero, it seems the compliance testsuite can indeed verify
that
all standard and reserved encodings outside those configured take an
illegal instruction trap.
(One more time -- Is this a correct interpretation? :)
Might it be useful to additionally define some terms to help classify
conformance.

"Conditional conformance" -- Non-conformant implementations that can
be made conformant by clearing MISA.X. These and fully conformant
implementations can emulate any standard extensions.
"Partial conformance" -- Non-conformant extensions that correctly
implement a subset of a standard extension, and trap on the rest,
allowing
the full standard extension to be emulated. This is independent from
conditional conformance.
It seems reasonably straightforward for a compliance test suite to test
full and conditional conformance. Partial conformance is easy enough to
test for standard extensions that don't add state (A, B, M, etc) by
including full emulation routines which presumably already exist
somewhere
-- whatever the implementation doesn't cover gets emulated. Standard
extensions that add state (F, D, H, etc) are not so easily amenable to
standard testing, because emulation varies according to what states
hardware implements. For example, an implementation that provides
partial F
support and emulates the rest likely needs to provide FCSR, and use that
rather than an emulated copy to emulate the rest.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub

https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AHPXVJVKNG3TIOYS6PRCJETQACNVTA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JDP5I#issuecomment-512899061,

or mute the thread

https://github.com/notifications/unsubscribe-auth/AHPXVJV5YFMZ3CVDAV4BBADQACNVTANCNFSM4IERF6UQ

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAQHPIIOLD3GBMSSCHRD3NTQADOVDA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2J3MHY#issuecomment-512996895,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQHPIOBEHAYJPD5O22NZ3LQADOVDANCNFSM4IERF6UQ.

FWIW, when I wrote emulation libraries for the F/D extensions, I found it straightforward to provide two variants: one assuming none of the architectural state (no f-registers and no fcsr), and one assuming all of the architectural state, loads, stores, and moves to/from x-registers, but none of the other instructions.  I don't think the design points in the middle (fcsr without f-regs, or f-regs without fcsr) make too much sense.

Paul Donahue wrote on 2019-07-18 20:17:

On Thu, Jul 18, 2019 at 9:52 AM Marc Gauthier<EMAIL_ADDRESS>wrote:

I started replying without re-reading the specs, then re-read
Section 1.3,
which was useful.

I agree.
The base ISA explicitly defines as "non-conforming" a non-standard

extension that uses standard or reserved encodings. It seems clear
enough
that implementing a subset of a standard extension is a non-standard
extension (though that might be specified explicitly), and by definition
non-conforming because it uses standard encodings. Is that a correct
interpretation?

Sounds good to me.
I'm concerned with the declaration in 1.3 that "custom extensions are not
non-conforming" because:

custom extensions are not defined

Right, Section 1.3 does seem like the right place to explicitly define
"custom extensions".  It takes careful reading to figure out that a
"custom extension" is one that only uses "custom" opcodes.  I've created
a pull request, #413.

if it means "non-standard extensions" then this statement is
clearly not
true because it depends on which encodings each extension uses.

No, that's different.

If a "conforming implementation" is defined as an implementation without
any non-conforming extensions.

It doesn't say that anywhere but it sounds reasonable. Then let's also
assume that the compliance suite should be checking for whether the test
target is a conforming implementation and it should fail if not.

Conforming is not the same as compliant.  The testsuite tests compliance.
It can test conformance if an implementation claims to be conformant.
An implementation can be compliant and non-conformant.

Then, if a standard extension is not present on a conforming
implementation, attempting to execute any of that extension's standard
encodings must not result in anything that might be interpreted as a
custom
extension, including NOP or custom traps. Although nowhere made
explicit,
it seems the only valid behavior provided for in the privileged spec
is the
illegal instruction trap. Anything else might be taken as a
non-conforming
extension. Again, is this a correct interpretation?

Can you point me to somewhere that says that reserved and/or custom
encodings that are unimplemented are required to trap (or to exhibit any
particular behavior at all)?

No, nothing explicit.  My interpretation is that anything other than an
illegal
instruction trap can be considered a non-conforming extension.
In other words, an implementation doesn't have to trap.  But if it wants to
claim that it is free of any non-conforming extension, then by the above
reasoning it must trap.  Which (if correct) highlights the value of claiming
no non-conformance (or simply, "conformance", to avoid double negatives).

I see lots of specific examples of required
illegal instruction traps when accessing certain CSRs and whatnot but not
the blanket statement I've seen in other architectures. I think that there
is no such requirement, though I'd like to be proven wrong since it would
simplify things.
This message from Krste specifically says that if Zifencei isn't
implemented then FENCE.I doesn't have to trap (though traps are "highly
recommended"):
https://lists.riscv.org/g/tech-privileged/message/6
(Also relevant to this conversation, it says that the compliance suite
shouldn't test for FENCE.I if Zifencei isn't implemented.)

Right.  "Conformance" (absence of non-conforming extensions)
is not a requirement for compliance.
(Maybe there's a better term.  "Conformance" and "compliance"
are very similar.)

The first part means RV32I + multiply is non-conforming.

If it implements MISA (non-zero), MISA.X must be set, as the multiply
alone is a non-standard extension. If MISA.X is writable, the obvious
interpretation is that clearing it disables all non-standard extensions
including the multiply; and in that case, RV32IM can always be emulated
even if the hardware multiply isn't implemented correctly.
(Is this a correct interpretation?)

I can agree with that, though the two "if" statements substantially reduce
the impact of this observation.

So although notionally RV32I says nothing about instructions outside
those
it defines (the (b) answer), if MISA is non-zero and MISA.X is or can be
written as zero, it seems the compliance testsuite can indeed verify
that
all standard and reserved encodings outside those configured take an
illegal instruction trap.
(One more time -- Is this a correct interpretation? :)

Only if unimplemented encodings are required to take an illegal
instruction
trap.

If there are no non-conformant extensions, it seems traps must be taken.
If MISA.X is implemented and cleared, any non-standard extensions, which
includes both custom and non-conformant extensions, must be turned off.
So effectively, there should be no active non-conformant extensions, and
again it seems traps must be taken.
-M

Might it be useful to additionally define some terms to help classify
conformance.

"Conditional conformance" -- Non-conformant implementations that can
be made conformant by clearing MISA.X. These and fully conformant
implementations can emulate any standard extensions.
"Partial conformance" -- Non-conformant extensions that correctly
implement a subset of a standard extension, and trap on the rest,
allowing
the full standard extension to be emulated. This is independent from
conditional conformance.
It seems reasonably straightforward for a compliance test suite to test
full and conditional conformance. Partial conformance is easy enough to
test for standard extensions that don't add state (A, B, M, etc) by
including full emulation routines which presumably already exist
somewhere
-- whatever the implementation doesn't cover gets emulated. Standard
extensions that add state (F, D, H, etc) are not so easily amenable to
standard testing, because emulation varies according to what states
hardware implements. For example, an implementation that provides
partial F
support and emulates the rest likely needs to provide FCSR, and use that
rather than an emulated copy to emulate the rest.

Those terms can be defined but I'm not sure they can be tested without a
trap requirement. This lack of a trap requirement really complicates a lot
of things for a test suite that has to run on any legal implementation.
Thanks,
-Paul

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AAQHPIJFFOILSM2MNLNDLODQAEBZLA5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2KGG6I#issuecomment-513041273,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQHPII3DAJA2MSAEICZS4TQAEBZLANCNFSM4IERF6UQ.

On Fri, Jul 19, 2019 at 4:57 PM Marc Gauthier<EMAIL_ADDRESS>wrote:
Paul Donahue wrote on 2019-07-18 20:17:
Section 1.3 does seem like the right place to explicitly define "custom extensions".  It takes careful reading to figure out that a "custom extension" is one that only uses "custom" opcodes.  I've created a pull request, #413.

I saw that.  Thanks.

Conforming is not the same as compliant.  The testsuite tests compliance.
It can test conformance if an implementation claims to be conformant.
An implementation can be compliant and non-conformant.

OK.  Such similar terms can be confusing but I understand and agree.

Then, if a standard extension is not present on a conforming
implementation, attempting to execute any of that extension's standard
encodings must not result in anything that might be interpreted as a custom
extension, including NOP or custom traps.

I see what you're saying.  That's an interesting idea but I don't think it's the intent of the architecture.  We're both trying to interpret something that's not explicitly stated, though.
Can @aswaterman weigh in?
Let's say I have the simplest RV32I implementation with no other extensions of any kind.  An implementation with such a configuration cannot possibly trap.  At least it cannot meaningfully trap since without the standard privileged architecture (or some other extension) there is no trap information (cause/epc/etc.) and without Zicsr (or a non-standard CSR extension) there would be no way for the handler to see those CSRs anyway.
Does such an implementation as above implement a non-conforming extension because FP instructions (and many others) are NOPs rather than trapping?  To take it a bit further, what if the decoder doesn't look at certain bits that are don't-care for decoding the minimal RV32I subset and consequently FP instructions are decoded as arbitrary integer instructions?

It's totally reasonable for certain platform specifications to illegalize non-conforming extensions--i.e., to mandate that a standard encoding must either trap or perform the standard-specified action.  However, the ISA spec itself does not appear to take a position on the compliance of non-conforming extensions.
I would describe reinterpreting an FP opcode as a NOP, or as some arbitrary integer instruction, as a non-conforming ISA extension, which happens to be non-compliant with respect to the F extension.  Such an implementation might be compliant with respect to the RV32I base ISA, but might not be compliant to some platform specifications that require the F extension either be implemented or to faithfully trap.
There's lots of options here (too many), and as usual I'm going to punt to the need for platform specifications to constrain the set of valid implementations and behaviors.

This is a very long thread that isn't really an ISA spec issue - so I suggest conversation move to compliance group.
To help understand the philosophy though, one important RISC-V goal is to maximize reuse of the specifications.  This is why an implementation that uses a MUL opcode to do a DIVIDE operation can still be compliant with the RV32I ISA.  This implementation can reuse all the software tools and libraries that only rely on RV32I.  It is clearly not compliant with RV32IM ISA.
A software ecosystem (e.g., DebianLinux, AmazonFreeRTOS, etc,) can specify that their platform compliance forbids non-conforming implementations by requiring every opcode is either standard or takes an illegal instruction trap.   While this would seem like a generally "good idea" to enable forward compatibility, this is only a virtue in environments where emulating newly defined instructions on old hardware is both practical and desirable.  I believe that this kind of forward compatibility is only useful for a tiny fraction of systems shipped in practice (e.g., Unix servers and workstations), so mandating it for all systems unnecessarily limits use of RISC-V infrastructure in other areas.
The downside to the forward-compatibility mandate is that applications that are content with the existing RISC-V infrastructure won't be allow to  reuse that infrastructure while adding non-conforming instructions to customize for some task.   e.g. embedded systems customized for the task at hand.
pA separate goal is supporting compliance

I'll echo what Krste said. (I confess I've probably been using the word
"conforming" incorrectly...)
The goal of compliance is to test whether an implementations assertions
about what it supports is (non-proper) superset of a platform's
requirements.
This gets a bit tricky if an implementation implements only MUL, but not
DIV.
It will be compliant to RV32i, but not to RV32im, as Krste said.
Nothing more needs to be said if the platform is RV32i, or RV32im, but
those are likely toy platforms that are classroom projects only.
From the perspective of a platform that requires both MUL and DIV to be
implemented, however, it will be compliant IFF DIV traps properly - because
it can then be emulated.
Compliance will not test that the emulation of DIV is correct, however -
just that it is possible to be implemented via the correct trapping
behavior.
We do need the infrastructure to ensure that the reference model will
faithfully trap on DIV but not MUL in this case (or any other op that is
required by not implemented by HW)
On Sat, Jul 20, 2019 at 11:41 AM Krste Asanovic<EMAIL_ADDRESS>wrote:

This is a very long thread that isn't really an ISA spec issue - so I
suggest conversation move to compliance group.
To help understand the philosophy though, one important RISC-V goal is to
maximize reuse of the specifications. This is why an implementation that
uses a MUL opcode to do a DIVIDE operation can still be compliant with the
RV32I ISA. This implementation can reuse all the software tools and
libraries that only rely on RV32I. It is clearly not compliant with RV32IM
ISA.
A software ecosystem (e.g., DebianLinux, AmazonFreeRTOS, etc,) can specify
that their platform compliance forbids non-conforming implementations by
requiring every opcode is either standard or takes an illegal instruction
trap. While this would seem like a generally "good idea" to enable forward
compatibility, this is only a virtue in environments where emulating newly
defined instructions on old hardware is both practical and desirable. I
believe that this kind of forward compatibility is only useful for a tiny
fraction of systems shipped in practice (e.g., Unix servers and
workstations), so mandating it for all systems unnecessarily limits use of
RISC-V infrastructure in other areas.
The downside to the forward-compatibility mandate is that applications
that are content with the existing RISC-V infrastructure won't be allow to
reuse that infrastructure while adding non-conforming instructions to
customize for some task. e.g. embedded systems customized for the task at
hand.
pA separate goal is supporting compliance
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/409?email_source=notifications&email_token=AHPXVJVWDATAKWOPWAUKOI3QANL35A5CNFSM4IERF6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NTZQA#issuecomment-513490112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHPXVJVDLEFCJ7VONJDMQE3QANL35ANCNFSM4IERF6UQ
.


Remove link in MD that doesn't render in html

Description
Removing link added in markdown as it doesn't render correctly on the docs site.
Test Plan
How did you test the new or updated feature?

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.
Type of Change (Check all that apply)

[ ] user-visible impact
[ ] breaking change for a client SDKs
[ ] breaking change for FNs (FN binary must upgrade)
[ ] breaking change for validators or node operators (must upgrade binaries)
[ ] breaking change for on-chain data layout
[ ] necessitate either a data wipe or data migration

Release notes

interim fix while we resolve the underlying issue

fixes https://github.com/MystenLabs/sui/issues/8752


Respect Astropy IERS URL configuration

FWIW, I'm using this patch in my fork because I don't have any other work around for our live telescopes. It's working great. Would be nice to get it merged. @bmorris3 maybe you can kick off the tests again?

@bmorris3 @lpsinger anything I can do to help get some movement on this? I have to do a lot of manual restarting of our CI tests just because the IERS download has failed and this will help fix that. Thanks!

@bmorris3 also, see comment in https://github.com/astropy/astropy/issues/8981#issuecomment-544735592.
The default IERS servers are going down in two days and will be down for 6 months.

@wtgee Sorry for the delay. These are scary times indeed! Tests restarted, will merge pending tests pass.

This build is failing with the following peculiar error:
sh: 0: Can't open /etc/init.d/xvfb

I'm going to see if I can find the source...

This build is failing with the following peculiar error:
sh: 0: Can't open /etc/init.d/xvfb

I'm going to see if I can find the source...

Not sure why it's giving an error with these changes, but it's part of the matplotlib testing:
https://github.com/astropy/astroplan/blob/4693ed89fc52237e261a0ece194ee32940c3c380/.travis.yml#L91-L96

Yes, that whole section is very obsolete and can be removed.
However it doesn't seem to be true that you don't do mpl tests, there is at least one in test_sky.py, even though it may be a dummy one.
Anyway, the current way to set this up is to use set SETUP_XVFB=True in the global variable part of the travis config.


Create Story Project

https://github.com/chingu-voyage3/grad.then/issues/27#issuecomment-351352376

In this section do we need to give use cases for the app? :)

#130 is directly related to the Story Project.
However, I'd like to give it a different meaning. There are 2 ideas we can implement.

gather positive and negative experience about "how people get the developer's job" (A StoryCard can have 2 different colours of the background).
It's optional, but you might find it fun. Could everyone in our team share his/her own story? If you haven't got the dev job still (like me :upside_down_face: ), you can write an imaginary story (how you'd like it to be). It's very optional and I do not insist. :smiley:

I have a few stories from interviews...
I have 10+ years experience as a developer but for VBA, SQL and the like, since I have started applying for junior dev roles there are some odd situations I have come across

That's great!
I will be happy to read your stories @spences10 :book: :smile:


Fix for the template map concurrency issue

Another update, to address the concurrency issue with the template map. Changed the templatemap to an atomic value that is only read from. New items are added to a copy of the template map after locking using a sync.Mutex lock . Then the template map is replaced / updated. As recommended by @runner-mei here #1188

Closing in favor of #1225


Improve blaze-client connection pool

The current Blaze connection pool is lacking in several ways compared to other clients:

Max connections is more of a max idle connections.  In practice, many more concurrent connections can be opened.
Can't restrict connections by host.
No monitoring.

commons-pool2 provides roughly what we need, but is not quite right:

New dependency.
Connection creation is synchronous.
Connection borrowing during wait is synchronous.

Closed in favor of #497.


CWI scripts - Analysis of the residuals

= Description =

Integrate the analysis of the residuals as a !BioPreDyn method.

= Context =

Analyzing the residuals provides information about the quality of a parameter estimation operation.

= Success criteria =

Residuals of a parameter estimation can be analyzed using the !BioPreDyn API.

= Expected issues =

None.

Imported from trac issue 49.  Created by bmoreau on 2014-08-28T13:58:37, last modified: 2014-09-04T17:34:53


Any support for masked language modeling?

I see that there's support for causal language modeling, and that models trained with MLM objectives are supported for sequence and token classification tasks, but could I ask if there's anything I missed/any hacky way to get PEFT to work for masked language modeling?

Hello, you could make the current examples to work for MLM pre-training by just converting the model to the PEFT model. Please try it out and let us know if you face any issues.

Thanks! Will do

@ryan-caesar-ramos Did it worked for you?

Hello @bkopin-quinten I can't remember why but I did not push through with trying this. Sorry!

@pacman100 Which PEFT type and task would you use for masked language modeling?


Sov 1010 zero collateral ratio healthbar component

https://sovryn.atlassian.net/browse/SOV-1010

@Rickk137 could you pls add some test cases?


Upgrade react-select to 2.0

~Still needs a look at the multi-select from Lou.~
When the next version of react-select comes out, it'll support themes, which will allow us to simplify the style overrides a lot.

@zarsky-broad can you provide any information about how you recommend testing this? I don't know what to look for.

@katevoss Every instance of react-select, that is, every dropdown in the application, should work as expected after this upgrade. Take a look a the places that are changed in code to find them.

@MattPutnam We can potentially fix those things in a follow-on. For now I'm going ahead with this.


play file .raw

Hi all
When I downloaded data in "https://people.xiph.org/~jm/demo/rnnoise/rnnoise_contributions.tar.gz" link , Can I play them as music (.mp3 file ) ?
If it can , Could you help me to show proper command or software ?
Very thank you

No, All are raw file present there you have to convert the raw file into other format. You can use this link https://github.com/smallmuou/wavutils  to get a tool to convert. This one is orking fine for me.

You can use Audacity to listen these files. Use File -> import -> raw audio. Set sample rate to 48000 and sample size to signed 16bit pcm.

I use sox:
play --type raw --rate 8k --bits 16 --channels 1 --encoding signed in.wav
And you can use sox for convertion, just change play to sox like:
sox --type raw --rate 8k --bits 16 --channels 1 --encoding signed in.wav out.mp3


fix memory corruption in gluoncv ssd training

Description
Fix #13710
In bipartite match, the temporary workspace size is miscalculated and not enough to hold the index tensor.
Since it is related to sizeof(DType) and sizeof(int32_t), the bug is only triggered on some platforms.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

Is it better to create two workspaces for DType and int32_t respectively?

workspace allocation is limited to one time only, so total space has to be calculated aforehead

@zhreshold Thanks!


Fix x86 Conv tuning tutorial

@kevinthesun Could you verify?

There is a known issue of measurement on c5.9xlarge. As @kevinthesun and I discussed in #1585 .
At that time I provided a hack to fix it. But this is not upstreamed.
I also found this issue on arm cpu.
Here I provide another easier hack to fix this. It works for arm cpu.  @kevinthesun Can you verify it on c5.9xlarge instance ?
diff --git a/python/tvm/autotvm/measure/measure_methods.py b/python/tvm/autotvm/measure/measure_methods.py
index ec3eb7e..60b463c 100644
--- a/python/tvm/autotvm/measure/measure_methods.py
+++ b/python/tvm/autotvm/measure/measure_methods.py
@@ -214,6 +214,7 @@ class RPCRunner(Runner):
         kwargs = {}
         if 'cuda' in self.task.target.keys or 'opencl' in self.task.target.keys:
             remote = request_remote(self.key, self.host, self.port)
+
             ctx = remote.context(str(self.task.target), 0)
             max_dims = ctx.max_thread_dimensions
             kwargs['check_gpu'] = {
@@ -460,7 +461,10 @@ def run_through_rpc(measure_input, build_result,
         if ref_input:
             args = [nd.array(x, ctx=ctx) for x in ref_input]
         else:
+            # create empty arrays on the remote device and copy them once.
+            # This can avoid some memory issues that make the measurment unreliable
             args = [nd.empty(x[0], dtype=x[1], ctx=ctx) for x in build_result.arg_info]
+            args = [nd.array(x, ctx=ctx) for x in args]

         costs = time_f(*args).results
         if len(costs) > 2:  # remove largest and smallest value to reduce variance

@merrymercy oh I was intended to say, what passes to topi_x86_conv2d_NCHWc should be output channel, while I also made a mistake - it should be kernel[1][0]

This PR lgtm.

I mean if you run this tutorial without some fix to measurement, probably you will get wrong results.

@merrymercy I'll verify your methods on c5.

@merrymercy Got it. Let's merge this and make another PR for the measurement fix.

@kevinthesun Got chance to verify?

@merrymercy I just verified your method and it works for c5 instance.


Add HeyTaco to Slack Community Guidelines

Add how Techqueria uses HeyTaco to give kudos to https://techqueria.org/slack

The HeyTaco! bot sparks conversations and builds stronger relationships with its fun and unique kindness currency... tacos! :taco:
Their model fits perfectly with Techqueria's brand so we were so glad when the founders decided to offer us a community discount, making it completely free for all 3000+ of our Slack members when it usually costs $2 bucks per person per month. :shocked facewith explodinghead:
You can learn more about HeyTaco! at  https://www.heytaco.chat

How @heytaco works :pushpin:

You can use @heytaco to give someone a :taco: when you'd like to show praise, appreciation, or to add a little happiness to their day. :hey-taco:

1. Every person in our Slack Workspace has 5 tacos to give out per day
:taco: x :five:
2. To give someone a taco, add a taco emoji after their username
Like this: @username your positive attitude was a real help today! :taco:
3. You can give tacos to anyone on your team as long as the bot has invited to the channel
You can invite the bot to channels using /invite @heytaco
4. There is a leaderboard to see who is getting the most tacos
Anyone in our Slack Workspace can sign in and see the leaderboard using https://www.heytaco.chat/leaderboard
5. Need help?
If you need help, you can just DM @heytaco the word help and it will assist you (edited)

Hi @fvcproductions, I'd like to work on this issue as well. 🤓
Q: Is it okay to add the HeyTaco! how-to instructions under Best Practices in the Slack Guidelines?

@enriquenov Actually let's put this under "Customization" and make it the first item. 👍
I would also include a screenshot of how HeyTaco works from the HeyTaco website for better clarity!

@fvcproductions sounds good, I'm on it!


How should I use scrapy-playwright without downloading images?

Hi,
Could anyone help me to use scrapy-playwright without downloading images?
Thanks for your support,

This seems like a duplicate of #26, please reopen with more info if you don't agree.

This seems like a duplicate of #26, please reopen with more info if you don't agree.

I have a question on this.
I have followed the example you provided in the answer to that thread, and from my initial thought I imagined no images would be downloaded, i.e.  I would not get any response/requests sent to .jpeg attachements.
Here's the output I get:
 'playwright/context_count': 1,
 'playwright/page_count': 1,
 'playwright/page_count/closed': 1,
 'playwright/request_count': 30,
 'playwright/request_count/method/GET': 30,
 'playwright/request_count/navigation': 1,
 'playwright/request_count/resource_type/document': 1,
 'playwright/request_count/resource_type/font': 1,
 'playwright/request_count/resource_type/image': 20, #<- why are requests sent to images?
 'playwright/request_count/resource_type/script': 5,
 'playwright/request_count/resource_type/stylesheet': 3,

Perhaps I have misunderstood what context actually do - If I wanted no requests/responses sent/received from images how would I accomplish this or is this the same as saying 'without downloading images'.

Only #63 should be considered "in progress". That said, it's probably going to keep showing requests like that in the stats, because it relies on aborting requests caught by the Page.route method, while these stats are incremented via the request event. The playwright/request_count/blocked stat and lack of playwright/request_count/resource_type/image should be indicatives that it's working.

Only #63 should be considered "in progress". That said, it's probably going to keep showing requests like that in the stats, because it relies on aborting requests caught by the Page.route method, while these stats are incremented via the request event. The playwright/request_count/blocked stat and lack of playwright/request_count/resource_type/image should be indicatives that it's working.

playwright/request_count/blocked is this a new feature? I cannot seem to get this output. If I understand the increment correctly, the resource_types should only increment those requests with a response 200? Therefore, the images have received a response - wouldn't it save resources to prevent these responses altogether?

I have checked the update you have made, and thank you for taking the time to make these amendments. I have updated my handler.py with the latest to include the changes and ran the script above. I still do not get any request_count/blocked with the approach above, here's the output console:
{'downloader/request_bytes': 222,
 'downloader/request_count': 1,
 'downloader/request_method_count/GET': 1,
 'downloader/response_bytes': 51182,
 'downloader/response_count': 1,
 'downloader/response_status_count/200': 1,
 'elapsed_time_seconds': 6.398593,
 'finish_reason': 'finished',
 'finish_time': datetime.datetime(2022, 3, 1, 11, 49, 40, 883833),
 'item_scraped_count': 1,
 'log_count/DEBUG': 64,
 'log_count/INFO': 44,
 'memusage/max': 119721984,
 'memusage/startup': 119721984,
 'playwright/context_count': 1,
 'playwright/page_count': 1,
 'playwright/page_count/closed': 1,
 'playwright/page_count/max_concurrent': 1,
 'playwright/request_count': 30,
 'playwright/request_count/method/GET': 30,
 'playwright/request_count/navigation': 1,
 'playwright/request_count/resource_type/document': 1,
 'playwright/request_count/resource_type/font': 1,
 'playwright/request_count/resource_type/image': 20,
 'playwright/request_count/resource_type/script': 5,
 'playwright/request_count/resource_type/stylesheet': 3,
 'playwright/response_count': 30,
 'playwright/response_count/method/GET': 30,
 'playwright/response_count/resource_type/document': 1,
 'playwright/response_count/resource_type/font': 1,
 'playwright/response_count/resource_type/image': 20,
 'playwright/response_count/resource_type/script': 5,
 'playwright/response_count/resource_type/stylesheet': 3,
 'response_received_count': 1,
 'scheduler/dequeued': 1,
 'scheduler/dequeued/memory': 1,
 'scheduler/enqueued': 1,
 'scheduler/enqueued/memory': 1,
 'start_time': datetime.datetime(2022, 3, 1, 11, 49, 34, 485240)}

That's correct, the configure_context approach was very much experimental (there wasn't even a PR). There are still some details to think about with the new approach as well, but the following should be enough for now to block requests based on resource type
PLAYWRIGHT_ACCEPT_REQUEST_PREDICATE = lambda req: req.resource_type not in ("image", "script")

Thank you for the implementation - I agree, there's still more creative ideas for it's implementation. An additional one may be the following:

To substantiate in the meta arguments, or handlers when to activate the settings argument for PLAYWRIGHT_ACCEPT_REQUEST_PREDICATE.

For the following reason:
If I am using PageCoroutine to log into a website I cannot remove some resource types as otherwise I won't have access to the login. After accessing the site, I may be making further requests to another domain belonging to the site. It may be useful to access the  PLAYWRIGHT_ACCEPT_REQUEST_PREDICATE here. Although, making this multifunctional, for example -
meta = {
    'playwright_accept_request_predicate': {
        'activate':True,
        'position': 1
            }
}

activate would describe whether to activate the settings for PLAYWRIGHT_ACCEPT_REQUEST_PREDICATE for the requests in that method. Whereas, position would denote the following:
PLAYWRIGHT_ACCEPT_REQUEST_PREDICATE = lambda req: req.resource_type not in ("image", "script")

The position of the resource_type. However, there may be a few technical issues with this. Alternatively, we could include:
meta = {
    'playwright_accept_request_predicate': {
        'activate':True,
        'group': 'resource_type'
        'position': 1
            }
}

This makes things slightly more complex - however, what this would represent is the following:
The position argument is already pre-determined by the position of resource_types in the source code. For example, if resource types take the following list sequence: request.resource_type  = ['xhr', 'JS' ...] then we pick on this position.
Then the following will denote:
meta = {
    'playwright_accept_request_predicate': {
        'activate':True,
        'group': 'resource_type'
        'position': False
            }
}

All the resource types are included.

On addition to the above; there's also a need to include the route handle, as such:
meta = {
    'playwright_accept_request_predicate': {
        'activate':True,
        'handle': 'fulfill'
        'group': 'resource_type'
        'position': False
            }
}

Where, the handle determines how to handle the route. Furthermore, I have noticed that route.request provides the request to be aborted.
Alternatively, I was thinking how functional would route.request be in the given case; The idea I had was that we can abort all request urls when their response is not <200>. Not sure how much of an impact this has on the scrapy context and the side-effects of running this, however it may prevent issues like time-outs.
@elacuesta  your thoughts?

I'm sorry, that sounds overcomplicated. My aim is to keep things as simple as possible, I don't want to build a whole new API.
Moreover, things like the position argument are not generalizable because the predicate to abort requests is arbitrary, not just based on the resource type.

abort all request urls when their response is not <200>

The idea is to abort requests before they're sent, if they already have responses it's just not possible to abort them anymore.
However, passing the Route object instead of just the Request sounds interesting, to allow the usage of Request.fulfill. I'm not sure though, perhaps that could be a separate hook to keep this one simply returning a boolean.


Reduce flake8 max-line-length to 147

Description
Reduce flake8 max-line to 147
Changed Behaviour
No change
Fixes
Fixes # (#3105)
Type of change

Code maintenance/cleanup

Hi @benclifford could you please review  the changes I've made? I'll appreciate your feedback and thoughts on them.

@yadudoc,  I have fixed the conflicts. Thank you for the notes

@Liz-Adhiambo Please note that the line limit is at 147 now.

@yadudoc I have reduced the max-line length to 146 now . I did experience sort of a blocker when I tried working on line 496 in the monitoring.py file, breaking the line always gave me a statement is unreachable error so I opted to shorten the word "message" to "msg". Are there any other solutions I could have tried? What do you think?

Changing the word "message" to "msg" seems like the wrong way to fix a "statement is unreachable" error - changing just a word shouldn't change whether a statement is reachable or not!
Have a closer read of the code, and of the error messages you got from mypy, and see if you can understand what was happening before and after your change.

@benclifford Okay  let me try that again

I tried a different approach, introducing a variable name for the error message. What do you think?


Initial work

All the tests done so far are meant to support the blog post for next week.
TODO:

[ ] Figure out why the binary load is so slow
[ ] Profile Python time vs Postgres time
[ ] Test pandas to binary copy
[ ] Finalize the public API of loaders
[ ] Create a post-testsuite report containing all load times and a diff of the Postgres conf
[ ] Do it all on hard mode by using models with foreign keys

Longest I've ever had a PR open.


Do not normalize vertical spaces unless they are between items

With this PR, we no longer normalize the number of vertical lines unless those are in between items.
Since this PR changes the default formatting style, I would like to include this PR to the 2.0 release.
Close #2954.

I'm running the latest nightly rust and formatting files using cargo +nightly fmt and I still experience this bug that was merged 2 years ago. What am I doing wrong?

@dcow You're not doing anything wrong. This PR was merged into the rustfmt-2.0.0-rc.2 branch (I ran git branch -a --contains=7159095  to verify that).
 Some are simple cherry-picks, but others are more involved due to the two branches diverging. Others are complicated by the fact that they were introduced at a time where a major version of rustfmt was in the works (now on pause) so they could more liberally introduce breaking changes for the new release, which we need to be mindful of when trying to backport them into 1.x branch.
That being said, if you're still having issues I'd suggest opening up a new issue with a short code snippet that we can use to reproduce your issue, and one that we can test against 1.x and the rustfmt-2.0.0-rc.2 branch


Testcontainers for Java: Add showcase examples for different scenarios

About
Foundation for a potential tutorial about how to use Testcontainers for Java with CrateDB, and for re-using blueprints at, for example, https://github.com/crate/crate-jdbc/issues/377.
=> README -- direct view
References

https://github.com/testcontainers/testcontainers-java/pull/6790
https://www.testcontainers.org/modules/databases/cratedb/

Details
The patch exercises different features of Testcontainers for Java with a basic query SELECT * FROM sys.summits LIMIT 3;.

TestClassScope: Class-scoped testcontainer instance with JUnit 4 @Rule/@ClassRule integration.
TestFunctionScope: Function-scoped testcontainer instance with JUnit 4 @Rule/@ClassRule integration.
TestJdbcUrlScheme: Database containers launched via Testcontainers "TC" JDBC URL scheme.
TestManual: Function-scoped testcontainer instance with manual setup/teardown.
TestSharedSingleton: Testcontainer instance shared across multiple test classes [^shared], implemented using the Singleton pattern.
TestSharedSingletonEnvironmentVersion: Testcontainer instance honoring the CRATEDB_VERSION environment variable, suitable for running a test matrix on different versions of CrateDB, shared across multiple test classes.

[^shared]: Sometimes it might be useful to define a container that is only started once for several test classes. There is no special support for this use case provided by the Testcontainers extension. Instead, this can be implemented using the Singleton pattern. See also Manual container lifecycle control » Singleton containers.
Backlog
Startup

Propagating command-line options to CrateDB

Database provisioning

Using a classpath init script
Using an init script from a file
Using an init function

Other test frameworks
Testcontainers for Java also provides integrations for other test frameworks. Currently, all test cases are based on JUnit 4.

JUnit 4
Jupiter / JUnit 5
Spock

@amotl I've pushed several changes/improvements, please take a look. (apologies, but It was easier than providing comments).
I've also added TestManualWithLegacyCrateJdbcDriver which shows how to use the legacy crate jdbc driver with testcontainers.

Hi. I've just added a final commit per 32fb51680ea4, effectively carrying over the summary from the pull request description into the "What's inside" section of the README. Can you have another look at this? Thanks already!

Merged. Thanks!


STOR-1168 OCPBUGS-12614: Bump common libraries

Bump github.com/openshift/api@master github.com/openshift/build-machinery-go@master github.com/openshift/client-go@master github.com/openshift/library-go@master <EMAIL_ADDRESS>cc @openshift/storage

/label px-approved
/label docs-approved

/lgtm

/label qe-approved
discusses with QE, CI is enough.

/jira refresh


Form button not updating sprig request.

Question
I am having a little trouble getting a form with date field to work. It does not seem to update the request. The #board section refreshes but the dates do not update so it is always the same entries. It seems that I don't know how to get the form values pushed to sprig.
original dates
{% set startDate = now|date_modify('first day of this month')|date('Y-m-d') %}
{% set endDate = startDate|date_modify('last day of this month')|date('Y-m-d') %}

resets for new dates
{% set newStart = '' %}
{% set newEnd = '' %}

original querry with some items omitted for clarity
{% set entryQuery =
   craft.entries({
      section: ['xxxxxxxxx'],
      serviceDate: ['and', '>= ' ~ startDate, '< ' ~ endDate],
   })
%}

updated sprig query ( I am only including the start date here for clarity
{% if newStart %}
  {% set startDate = newStart|date('Y-m-d') %}
  {% do entryQuery.serviceDate(
      ['and', '>= ' ~ startDate, '< ' ~ endDate]
   ) %}
{% endif %}

This is where it is not working. "newStart" and "newEnd" don't seem to be pushed to the updated query. It's probably a silly omission on my part.
<form sprig s-replace="#board" s-indicator=".spinner">

          Start Date
          <input type="date" class="form-control" name="newStart" id="newStart" autocomplete="off" value="{{ startDate }}"/>

          End Date
          <input type="date" class="form-control" name="newEnd" id="newEnd" autocomplete="off" value="{{ endDate }}"/>

          <button type="submit" class="btn btn-success">Update</button>

    </form>

Additional context
Add any other context or screenshots about the support request here.

Instead of resetting the values, give them defaults.
{% set newStart = newStart ?? '' %}
{% set newEnd = newEnd ?? '' %}

I knew it was something ridiculously silly that I have spent all day looking at. ugh. Of course, it works now.


[5.3] Update Validator.php

This change is used when you need that validation stop after the rule of an attribute fails. It's similar to what the ' Bail ' do, but we stopped validation instead of validating the next attribute.
The use is best accomplished when an attribute use another attribute in your rule.
To use this, only use "stop" in attribute rule.

What is the use case for this?

@themsaid ok :)

Going to hold off on this because I don't see this as being a common use case.


Make it obvious when event has precise start location and when it doesn't

Ideally we want all events to have a google map link that points to exact location, but sometimes events can be created without this "luxury" for various reasons. We should at least make it obvious when location can be trusted and when it cannot be and when flyer must be opened.
One of the options is to show a label "precice start address" and when address is approximate show a circle like this one: https://developers.google.com/maps/documentation/javascript/examples/circle-simple

I think we need 3 labels:

Race Location (as we have now) - it should be the registration place
Precise race location (as you said)
Start Location (with start sign like this http://screencast.com/t/xNjmYpzH, if we don't have a registration place from flier, but could find the start place)

@Me4ta I think as far as racer concerned we need just one – registration location (where should I drive 5am in the morning), but also we need to reinforce if that location is "precise" meaning just copy-paste or open in Google Maps or NO.
Start Location is not important at all, since they will figure it out at the race most likely.


License

Can you add a license? Preferably MIT?

Just marking my second here.  It'd be nice to use this with some projects.


Need Vibration support for PineTime DevKit0 in dts

I don't see any vibration support in the PineTime DevKit
boards/arm/pinetime_devkit0/pinetime_devkit0.dts
Describe why you are asking for this support?
I don't really know how to add it. My understanding of the devicetree is limited.
Additional context
I have seen other projects with an overlay to support it:
https://github.com/ck-telecom/pinetime/blob/develop/app/boards/pinetime_devkit0.overlay
We know what the pins are from here, can we add them all into the board:
https://github.com/joaquimorg/MY-Time/blob/master/src/pinetime_board.h
This is a zephyr example with the vibration:
https://github.com/ck-telecom/pinetime/blob/develop/app/src/service/vibrator.c

This would need a driver, not a very complex driver but probably one that turns a GPIO on and off, or just to work similarly to https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/basic/custom_dts_binding. The one linked in your post is an abuse of the GPIO key driver, it is not a button and should not pretend to be one.

I'm no expert on any of this. Does that mean something should be added to the pinetime_devkit0 dts file? Can somebody add it?

Having me add it might be a little dangerous. I would be glad to do it, but think I need to figure out what I need to add. You've given me some good direction. I think I need to sort through it.

Trying is a great way to learn, people will review it and leave comments if they think things can be improved


License clarification

Hi, does license "BSD" mean the BSD-3-clause (https://opensource.org/licenses/BSD-3-Clause), or one of the other BSD licenses?  Thanks!

Good point. We're currently building an app and are working on proper attribution. So far, the only (indirect) dependency that we have that doesn't have an SPDX-compatible license id is readline. It would really help if your package were using one of the identifiers from the SPDX licenses list.

I second that.
We have automatic validations to ensure that all of our project dependencies have a license that matches one of those allowed by our legal department. Unfortunately, "BSD" is considered too vague to be added to that list, which means that unless it is clarified, we'll have to either switch to another similar library that has a clear license, or implement the features we need on our own.
Would it be possible to use one of the SPDX identifiers instead?
https://spdx.org/licenses/
Thanks!

Same for us. We're totally willing to live with not having a valid SPDX identifier, but knowing what BSD flavor this package is meant to be published as would be great.


ic_launcher.png duplication

The lib is carrying with a ic_launcher.png file making gradle.build to fail when android:icon is set to ic_launcher.png (default config).
This is the error:

/home/fernandoperez/Desktop/SomeFolder/grade-manager/app/build/intermediates/res/merged/debug/drawable-hdpi/ic_launcher.png: error: Duplicate file.
/home/fernandoperez/Desktop/SomeFolder/grade-manager/app/build/intermediates/res/merged/debug/drawable-hdpi-v4/ic_launcher.png: Original is here. The version qualifier may be implied.
Error:Execution failed for task ':app:processDebugResources'.
com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/home/fernandoperez/Android/Sdk/build-tools/23.0.2/aapt'' finished with non-zero exit value 1

Making a rename of ic_launcher.png, Android Studio throws the following warning:
The resource @drawable/ic_launcher is defined outside of the project (in one of the libraries) and cannot be updated. This can change the behavior of the application.  Are you sure you want to do this?  Unhandled references: materiallist\1.2.0\res\drawable-hdpi-v4\ic_launcher.png materiallist\1.2.0\res\drawable-mdpi-v4\ic_launcher.png materiallist\1.2.0\res\drawable-xhdpi-v4\ic_launcher.png materiallist\1.2.0\res\drawable-xxhdpi-v4\ic_launcher.png

Hmm, odd. Thousands of apps use this library and I've never received this error before.
I don't think it's directly related to this library.

Is there any chance you are using this: https://github.com/dexafree/MaterialList
But the old version. It clearly turns out that your problem caused by materiallist\1.2.0\res\drawable-xhdpi-v4\ic_launcher.png and so on. Try to fix it.


hook only specific apps

Hello,
First of all, let me thank you for such a great program and a life saver.
I have a business app at work that steals focus all the time, and it's simply awful, it is interfering with my workflow and is infuriating to the point where all I want to do is smash the computer and go yell at the devs.
With that said, I find that hooking all user apps is kinda slow and unnecessary, as only a limited amount of apps exhibit poor behavior when it comes to stealing focus.
It would be great if hooking only specific apps could be implemented.
Personally, I don't need any fancy user interface settings for that, if it could be implemented via a config file, it would be really awesome.
For example, it could be a setting like this:
hookonly=myimagename.exe
hookonly=othermisbehaving.exe

or, if xml is preferred,
<hookonly>
<imagename>myimagename.exe</imagename>
<imagename>othermisbehaving.exe</imagename>
</hookonly>

Thank you.

I completely agree with you about needlessly hooking everything. I wanted to build a proper UI, but never got around to it. This sounds much more doable. I'll keep your suggestion in mind when I get some free time.

I came here to suggest this. A UI would be nice, but even some configuration file would be sufficient.
In our case ("us" being the entire "Pitfall: The Lost Expedition" speedrunning community), have a game from the Windows 95 - XP days that have an extremely aggressive focus stealing. We can't do anything outside the game. To a point where if the game softlocks, we have to reboot our computer!
A previous workaround was to use DxWnd, but then the game crashes whenever we use our keyboard to do anything else.
"Stay Focused" finally allows us to play while multitasking (ex: streaming, chatting, modding) and without any risk for crashes :D

Done: https://github.com/bladeSk/StayFocused/releases/tag/Beta3

I don't get it.
I've created a file named StayFocused.ini next to StayFocused.exe in the StayFocusedBeta3 folder, and I added the program I want (PDR.exe, which is Cyberlink Powerdirector). I restarted the app. The output windows is still listing:
Config loaded • mode = whitelist • whitelisted exes:
photoshop.exe
---

There is a StayFocused.exe.config which is gibberish to me.
I don't know what to do 🤷🏻♂

The config is always read from %APPDATA%\StayFocused.ini, the "Open Config" button opens that location. StayFocused.exe.config contains C# metadata and its name is a technical requirement/limitation of C#, although I agree it's confusing in this context


Migrate circleci to version 2.0

Will make it possible to parallelize some stuff later on
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

Ok, let's do that after the move…


Moving the container to F37 or at least F36?

SSIA

I thought I could test a pre-release Python 3.12 there, but that's not yet possible.  So no use-case => no problem => closing.  Sorry for the rush.
Seems like you are moving to Fedora N+1 when N goes EOL?  If so, just a small suggestion: it deserves a note in the README file that this is the policy.  Then nobody will be "shocked" the container is too old. :)

I thought I could test a pre-release Python 3.12 there, but that's not yet possible.

See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2137912 and https://src.fedoraproject.org/rpms/python3.11/pull-request/89
We plan to add it to Fedora 35 as well.

Seems like you are moving to Fedora N+1 when N goes EOL? If so, just a small suggestion: it deserves a note in the README file that this is the policy. Then nobody will be "shocked" the container is too old. :)

https://github.com/fedora-python/fedora-python-tox/issues/61

Thank you @hroncok !


Update metal-rs dependency to fix leaks

There's a leak in published metal-rs 0.15.0, patching against master branch fixes those.
Related: https://github.com/gfx-rs/metal-rs/issues/95
Shouldn't have any issues working against master branch with regards to API breakages.

Most importantly, hal-0.3 branch of gfx-backend-metal needs to be updated

Fixed in https://github.com/gfx-rs/gfx/pull/2972

Sorry, only fixed in the backend, not the main crate. My bad.
PR https://github.com/gfx-rs/gfx/pull/2973


[Discussion] Train new model

How to train a new model with an entire new database of stems? They need to be four or i just need two ( vocals and instrumentals)?

Please check the train section of the wiki https://github.com/deezer/spleeter/wiki/2.-Getting-started#train-model

How to train a new model with source code ,not command ?  @Faylixe


More problems with let

let console.log.lol = 0 in console.log 5  # prints "undefined" instead of "5"

let console.log.lol = 0 in console.log.lol  # runtime error

The second one happens because there's a marshal round-trip for the log function and "expandos" don't get marshalled towards the native side. That is, when the expanded log closure is marshalled to a native function, the native function doesn't have the extra "lol" property.

As of 6b61305dd7c812b83f0c56be355c0676d85e6a02, the second one is gone and the problem with the first one is that after the expansion console.log's character becomes undefined.


Add Turbine client endpoint

Implemented Turbine related test cases and classes. Also made updates to embankments to include the LocationIdentifier and updated cwms-radar-model yaml.

Based on PR: https://github.com/USACE/cwms-data-api/pull/717


How to exclude a path?

I need to exclude a full folder from the reordering. Ideally it would be possible to configure this in the pyproject.toml file in a tool section.

there's no need for every tool to implement this poorly when exclude works
also lol pyproject.toml, surely you jest

Sorry, didn't know that pre-commit exclude works for this. Didn't see this in this README.

yeah there's no need to duplicate the documentation for every option from pre-commit everywhere poorly


ibus-engines.m17n: 1.4.5 -> 1.4.6

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/ibus-m17n/versions.
meta.description for ibus-engines.m17n is: "m17n engine for ibus"
meta.homepage for ibus-engines.m17n is: "https://github.com/ibus/ibus-m17n"
meta.changelog for ibus-engines.m17n is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.4.6 with grep in /nix/store/7wl744n44h9qbhv7080snfzwy9kc24b8-ibus-m17n-1.4.6

found 1.4.6 in filename of file in /nix/store/7wl744n44h9qbhv7080snfzwy9kc24b8-ibus-m17n-1.4.6

directory tree listing: https://gist.github.com/d0043af779d074f16ee8e61a4b2b69e3

du listing: https://gist.github.com/586f2936c6f3a2004603af641f9f2e1c

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
ibus-engines.m17n

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/7wl744n44h9qbhv7080snfzwy9kc24b8-ibus-m17n-1.4.6 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ibus-engines.m17n https://github.com/r-ryantm/nixpkgs/archive/c5ee83899d44ef99a7f7fbc901b3ab38c6c66b3b.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/7wl744n44h9qbhv7080snfzwy9kc24b8-ibus-m17n-1.4.6
ls -la /nix/store/7wl744n44h9qbhv7080snfzwy9kc24b8-ibus-m17n-1.4.6/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ibus-engines.m17n

Maintainer pings
cc @ericsagnes for testing.

@ofborg eval


Importing doesn't work, also can't add any services

Bug description:
Trying to import my franz account gives me this error:
Could not login into Franz with your supplied credentials. Please check and try again.
I double checked the credentials and they work fine for franz.
Trying to create a new account does log me in, but I still can't add any services (described below).
Steps to reproduce:

Go to 'Add new services'
Click on ''All Services"
Click on "(e.g) Airtable"
Loading symbol briefly appears, then throws me into 'Most popular' with "Sorry, but no service matched your search terms."

This happens with any service I try to add, this also happens when 'not using an account'
Expected behavior
Add the service
Environment:

Operating System: Manjaro Linux
Ferdi Version:
Name            : ferdi
Version         : 5.5.0-10
according to pacman -Q --info ferdi

The visibility issue was fixed in #1398. Do you have other remaining problems?

The same is happening for me. Started to happen today after updating my services. https://github.com/getferdi/ferdi/issues/1390
I cannot use or add any service. =/

Same here on linux mint on latest beta. It seems that I can only add telegram, whatsapp an hangouts.
Will try stable...

I have the same issue.  All of my services were gone from Ferdi, and I can no longer add services. Big Sur 10.5.
Nothing in App Support folder was readonly. saw this in another thread
It goes away after a reinstall, but it certainly doesn't instill confidence :(

Which version of Ferdi are you using @ajboni @edtbl76 @leoheck ? Please specify that information before we can try to debug the issue.

I’m using 5.6.0.
(The main download). Reinstalling seems to have fixed the issue. (I had to wipe all of the app data and start from scratch). I was using it w/o a login. I’m hoping that using it w/ a login helps fix the experience. (I notice that you retain my services/workspaces in my account metadata).
Ed Mangini
@.***
On August 12, 2021 at 12:43:41 PM, Leandro Heck @.***) wrote:
Hi @vraravam , this was 3 month ago. I don't have this issue anymore. I saw this after replacing all the recipes - I believe.
I think I have fixed it by completely removing Ferdi and its config files and starting all over again. I am not sure it its version.
This is the version I am currently using.
I can't copy and paste info from this screen (this is so bad, why disable the cursor there?)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

@leoheck - please update to at least the latest public (non-beta version) - 5.6.0
Thanks for responding on the version.
On the topic of the about dialog - that is unfortunately the native dialog that electron delegates to and we can't do anything about it - other than revamp that code to use the equivalent one from the electron-utils package. #1420 is the one where we are tracking that work.

Closing the issue with the latest fix that I just committed. Unable to reproduce the original comment since that is logged against v5.5 which we no longer support.


Add Weather Phone IVR in Node.js

@niravcodes the guide on README has some broken links, can you double-check?


[BUG] There are no troubleshooting tools available to investigate JWT issues

Add more troubleshooting information to middleware to describe why a jwt is unauthorized


fix: match date -I error messages with GNU date

Fixes #4494

panic isn't the right approach to manage a user facing error.
With your change:
$ ./target/debug/coreutils date -I@
thread 'main' panicked at 'date:` invalid argument `@` for '--iso-8601'', src/uu/date/src/date.rs:118:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

it should be like GNU:
date: invalid argument '@' for '--iso-8601'
Valid arguments are:
  - 'hours'
  - 'minutes'
  - 'date'
  - 'seconds'
  - 'ns'
Try 'date --help' for more information.

See https://github.com/uutils/coreutils/blob/main/src/uu/date/src/date.rs#L249-L253 as example
Also, it will need a test to make sure we don't regress

@shanmukhateja are you still working on it ? :)

@sylvestre Yes I plan on working on it except I'm not sure how to implement SimpleError struct inside FromStr which returns Self.
In the case of panic, it halts the execution but now when I try using the struct, it complaints of trying to return Result.
Thoughts?

You should try a bit more :)
and look how it is done elsewere

Have you seen my comment in the issue? You probably don't need to change this function, just make sure that clap gives an error before we even get here.

look great :)
just a missing test

@sylvestre unit tests added.

please add the tests here:
https://github.com/uutils/coreutils/blob/main/tests/by-util/test_date.rs
and following their behavior :)

@sylvestre ..third time's the charm?

thanks :)

Thank you for being patient. @sylvestre

oh, don't mention it :)


Merge 'release/1.1.0' into 'master'

This just merges the release/1.1.0 branch into master so that master is pointing to the latest release.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 3 committers have signed the CLA.:white_check_mark: wmcginty:x: Tyler Milner:x: tylermilnerTyler Milner seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


HTTP3 Support

When could we expect http3 support on okhttp. Its almost a month http3 introduced.

No current plans. It’s significant work. It’s possible to wrap cronet behind an interceptor but the integration has noticeably different behaviour.

Tracking here: https://github.com/square/okhttp/issues/907


graph: Fix an error in KillState::new

On Mac OSX, Instant::now() is the time since the last boot, which might
have been less than a day ago, in which case KillState::new would panic. We
now use 'now - 60s' as a time in the past for initialization, and if that
fails, we'll use just 'now'. There's not much danger in using 'now', it
might just lead to spurious logging and a too-soon update of the kill_rate
if the node becomes immediately overloaded after starting.
Thanks to kevholder for root-causing the issue and demonstrating a fix.
Fixes https://github.com/graphprotocol/graph-node/issues/1805

This seems worth a comment

True - I made the mistake of putting the comment into the commit message. Fixed now.

@lutter I think you forgot to push the change.

@lutter I think you forgot to push the change.

I did indeed; rebased to latest master and pushed for realz


[Bug]: aws_regions_by_service.json: FileNotFoundError[13]

Unable to run Prowler as of the most recent version in master branch on Mac OS Ventura as a fresh install. Getting the following error:
(local-path)/prowler/providers/aws/aws_regions_by_service.json: FileNotFoundError[13]
After looking at the true installed path for aws_regions_by_service.json, it appears to be missing an additional /prowler/ directory. Please confirm this issue.
True path as installed:
(local-path)/prowler/prowler/providers/aws/aws_regions_by_service.json
Is it by design that prowler should only be executed if your current directory is the prowler parent directory? Using relative paths worked in the past.
Possibly related to the following issue: https://github.com/prowler-cloud/prowler/issues/1669 as I have this issue once upgraded to prowler 3.0.2, specifically this change: https://github.com/prowler-cloud/prowler/blob/master/prowler/config/config.py#L65
Workaround:
Ensure you execute from the installed /prowler/directory.
Example works:
cd /prowler/ && python3.9 prowler.py aws -h
Example doesn't work:
cd /literally-anywhere-else/ && python3.9 /prowler/prowler.py aws -h

Thank you for letting us now @ah-jota ! We'll fix it shortly.


tooltip的文本内容和shadowStyle位置不一致

Version
4.9.0
Steps to reproduce
ShawdowStyle of mobile tooltip does not work,
The contents of the Tooltip are correct, but the shadows are in the wrong place
What is expected?
Tooltip's tooltip line can be slid as you move, and the content of the tooltip box matches where the line is located
What is actually happening?
At the mobile end with different resolutions, the position of the indicator line is on January 1st, but the content of the prompt box is to display the data on January 2nd, and the indicator line cannot slide continuously.

The text message of tooltip is the data shown on 2020-10-14, then the indicator shadow refers to 2020-10-19, and when 2020-10-19 slides to 2020-11-11, it can't slide continuously, only jump to 2020-11-11

The situation is in a special data combination will appear this kind of problem, and the same set of data on different mobile phones may have normal, some errors, And on the computer is no problem, so I guess the underlying adaptation problem.


Add passenger_set_header and passenger_env_var parameters for Passenger 5.0+

Passenger 5.0 deprecates passenger_set_cgi_param and replaced it with passenger_set_header and passenger_env_var. This allows you to specify those parameters.
https://blog.phusion.nl/2015/03/04/phusion-passenger-5-0-1-released/

Yeah, several existing parameters don't match the name of the nginx directives, but it's certainly something we'd like to avoid in future. Thanks for updating!


Fix current version breaking side menu (remove bootstrap, custom css, custom js, custom template)

This PR:

removes the old version (2019) of bootstrap
removes the custom css
removes the empty custom javascript file
removes the custom template (required to include the above removed items)
updates a few of the rendered docutils nodes to lists, headers, etc instead of plain text to allow the above changes to have a minimal impact on the rendered docs

The above changes are mostly motivated by an issue where the old version of bootstrap causes the side/navigation menu to refuse to scroll. Making the above changes fixes this issue.
One side-effect of the above changes is the loss of the details button which collapses and expands some portions of the schema description. This seems like a reasonable loss for the benefit of not having to maintain all of the above items (which are currently causing the above described issue).
As the CI here doesn't provide previews for rendered docs I opened a test PR with asdf-standard that uses the source branch for this PR:
https://github.com/asdf-format/asdf-standard/pull/418
the rendered docs for the test PR are here:
https://asdf-standard--418.org.readthedocs.build/en/418/
Here are a few useful comparisons:

core/asdf:

current: https://asdf-standard.readthedocs.io/en/latest/generated/stsci.edu/asdf/core/asdf-1.1.0.html
with this pr: https://asdf-standard--418.org.readthedocs.build/en/418/generated/stsci.edu/asdf/core/asdf-1.1.0.html

core/complex:

current: https://asdf-standard.readthedocs.io/en/latest/generated/stsci.edu/asdf/core/complex-1.0.0.html
with this pr: https://asdf-standard--418.org.readthedocs.build/en/418/generated/stsci.edu/asdf/core/complex-1.0.0.html

For core/asdf the current docs contain the following:

with details "expanded":

with this PR the docs contain:

Test PRs are also open for stdatamodels and rad:
https://github.com/spacetelescope/stdatamodels/pull/246
https://github.com/spacetelescope/rad/pull/354
The formatting for these is slightly different and are subject to the numerous bugs in the stsci sphinx theme.

Thanks for the review!


integrating with aws xray for tracing

Hi ,
I  am using  aws xray for tracing (https://github.com/aws/aws-xray-sdk-go)
I was able to integrate aws-x-ray with bun without any error  by doing this:
	connStr := config.GetConfig().ReadPostgresqlConnStr

	instrumentedDB, err := xray.SQLContext("pg", connStr)
	log.Println(err)

	readDBPool = bun.NewDB(instrumentedDB, pgdialect.New())
	readDBPool.AddQueryHook(bundebug.NewQueryHook())

It did not throw any error.
but when I  do this:
var result int
	rows, err := db.QueryContext(ctx, "SELECT 1+1")
	if err != nil {
		return false, errors.Wrap(err, errors.DBConnectionFailedException)
	}

	err = db.ScanRows(ctx, rows, &result)
	if err != nil {
		return false, errors.Wrap(err, errors.DBConnectionFailedException)
	}
	return true, nil

It gives me this error:
sql: expected 1 arguments, got 0
same if my psql select query returns 10 values then error says,
sql: expected 10 arguments, got 0
I could not solve this error.  Another way I can think of integrating aws xray using hooks. Though that will require more code changes so I prefer to integrate in a above mentioned method.
I created this issue first in aws xray repo but got no reponse there.
Though it was working fine when I did not integrated aws-xray
Note
and I am doing this in local so I have done this:
os.Setenv("AWS_XRAY_SDK_DISABLED", "TRUE")

Thanks for the report. Should be fixed in v0.3.1

@vmihailenco  , Now I am getting error unexpectedly .
For most of the time everything is running fine but when I hit an API multiple times consecutively. Only the first one gets succeeds , next one fails with error like this  *errors.errorString: pgdriver: query returned 19 columns, but dest has 10 items

Please try v0.3.2 :mushroom:


[HUDI-2921] - Docs organization for Flink quickstart

What is the purpose of the pull request
Flink quickstart was way too long and was a dump of all Flink docs.
Brief change log

I created a Flink Setup page and moved basic setup/config there
I moved other Flink content to the relevant sections in the docs (eg. compaction to compaction, metastore to metastore, etc)

Verify this pull request
docs change only
Committer checklist

[X] Has a corresponding JIRA in PR title & commit

[X] Commit message is descriptive of the change

[X] CI is green

[X] Necessary doc changes done or have another open PR

[X] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Thanks for the fix but can we fix the broken notes of the pages ?