text:
Is a hart a hardware thread?

My colleagues and I are struggling to precisely define "hart" and are concerned the spec is misleading.
Section 1.1 paragraph 2 states "A RISC-V compatible core might support multiple RISC-V-compatible hardware threads, or harts, through multithreading."
This language suggests that a hart is a hardware thread.
Section 1.2 states "From the perspective of software running in a given execution environment, a hart is a resource that autonomously fetches and executes RISC-V instructions within that execution environment. In this respect, a hart behaves like a hardware thread resource even if time-multiplexed onto real hardware by the execution environment."
This language suggests that a hart is not a "hardware thread resource" but behaves like one.
Later in Section 1.2 states "The important distinction between a hardware thread (hart)... harts operate like hardware threads."  Part of this paragraph equates harts to hardware threads, and part indicates that they are different but similar ("like").
It would be helpful to define precisely what a hardware thread is, and whether a hart is actually a hardware thread, or if it is an abstraction of a hardware thread.
To the best of my understanding, a hart is not precisely a hardware thread. I would suggest the following changes to Section 1.

1.1 or 1.2 Precisely define hardware thread, and explain how a hart is similar to but not exact the same as a hardware thread.
1.1 "might support multiple RISC-V-compatible hardware threads, or harts, through multithreading" -> "might support multiple RISC-V-compatible harts through multithreading"
1.2 "distinction between a hardware thread (hart) and a software thread context" -> "distinction between a hart and a software thread context"

On Tue, Mar 12, 2024 at 8:28 AM David Harris @.***>
wrote:

Section 1.1 paragraph 2 states "A RISC-V compatible core might support
multiple RISC-V-compatible hardware threads, or harts, through
multithreading."
This language suggests that a hart is a hardware thread.

Yes, this strongly "suggests" that  "hart" = "hardware thread".

Section 1.2 states "From the perspective of software running in a given
execution environment, a hart is a resource that autonomously fetches and
executes RISC-V instructions within that execution environment. In this
respect, a hart behaves like a hardware thread resource even if
time-multiplexed onto real hardware by the execution environment."
This language suggests that a hart is not a "hardware thread resource" but
behaves like one.
Later in Section 1.2 states "The important distinction between a hardware
thread (hart)... harts operate like hardware threads." Part of this
paragraph equates harts to hardware threads, and part indicates that they
are different but similar ("like").

This text and the surrounding paragraph is trying to say that the
environment’s harts operate like hardware threads - versus like software
threads - from the perspective of the software inside
the execution environment.  In other words the key point being made isn't
about hart versus hardware thread, but about software thread versus
hardware thread.

It would be helpful to define precisely what a hardware thread is, and
whether a hart is actually a hardware thread, or if it is an abstraction of
a hardware thread.
To the best of my understanding, a hart is not precisely a hardware
thread. I would suggest the following changes to Section 1.

1.1 or 1.2 Precisely define hardware thread, and explain how a hart
is similar to but not exact the same as a hardware thread.

1.1 (as excerpted above) clearly defines "hart" = "hardware thread".

1.1 "might support multiple RISC-V-compatible hardware threads, or
harts, through multithreading" -> "might support multiple RISC-V-compatible
harts through multithreading"

This seems fine (and it reinforces explicitly that "hardware thread" =
"hart").

1.2 "distinction between a hardware thread (hart) and a software
thread context" -> "distinction between a hart and a software thread
context"

The former seems fine and better in that it makes clear that  "hardware
thread" = "hart".

Message ID: @.***>

My understanding is that a "hart" is a fundamental notion in this abstract computation model, and the authors are mentioning hardware threads only by analogy, to illustrate how this abstract notion may be implemented in real hardware. Please correct me if this understanding is wrong.

I would say that the spec repeatedly and directly affirms that "hart" = "hardware thread", i.e. that doesn't seem to be a thing that is ambiguously suggested once in the spec and never mentioned or stated again.
Having said that, some would view "hardware thread" as an abstraction.  (While others would view that as a physical reality and "software thread" is an abstraction, but then again to software people that is their reality.)
In short, the spec says that "hart" = "hardware thread" and reaffirms that a few times.  From some perspectives that may be an abstraction (e.g. from a multi-threaded CPU perspective), and other perspectives that is a concrete physical idea.  Neither is wrong.  But from the ISA specs' perspective, yes, "hart" is a form of abstraction - that is grounded as a hardware level thread of execution and not as a software thread (as OS people would think in terms of).

Yes, a "hart" is an abstraction of a hardware thread.  So there are many possible concrete implementations of a hart, include a real hardware thread, a QEMU emulation of a hardware thread, etc.

@pdonahue-ventana A hart is a thing that independently runs forward, continually executing instructions inside some execution environment.  The text you quoted from spec is saying that while each user-level execution environment sees one or more harts running code at user-level, in reality under the hood, the operating system is sharing physical processor cores among the user-level execution environments.  The physical cores only advance the state of each user-level execution context when a core is running a hart from that context.  The hart abstraction is needed so we don't have to discuss physical cores when they're running a different context, while also preserving the concept of something inside each context that has register state and that advances independently, executing instructions from the current context.

Thank you.  This is helpful to define a hart as "an abstraction of a hardware thread."
If I understand this correctly, a this abstraction means that hart could be a physical hardware thread, which I believe comprises its own architectural state (PC, registers, and CSRs), and the ability to fetch and execute instructions. It could also be a QEMU emulation of a hardware thread.  It could also be a guest hart, which is time-multiplexed onto a a host hart. Examples of guest harts are user-level harts managed by host hart(s) running a supervisor-mode operating system, and guest OS harts managed by host hart(s) running a hypervisor.
Page 4 uses the terms "guest hart" and "host hart".  These terms don't appear elsewhere.  Are they the preferred language for referring to time-multiplexing harts?  The term "virtual hart" comes to me for harts time-multiplexed onto other harts, by analogy to virtual memory and virtual machines, but it isn't in the spec.
On page 4, should I read "The distinction between a hardware thread (hart) and a software thread context" as ["hardware thread context" vs. "software thread context"] or ["hardware thread" vs. "software thread context"]?  The language is ambiguous.  The term "context" here is also undefined.  Does it mean the values of the architectural state (PC and registers, as in a context switch, as used in Privileged Spec 3.1.6.6), or does it relate to the execution environment (the context in which the thread is running, as seems to be used in Pan's thesis "Cooperative Hierarchical Resource Management for Efficient Composition of Parallel Software" at page 32), or something else?
Just beyond in page 4, I see that a hart differs from a software thread (or software thread context) in that software running inside the execution environment is not responsible for causing progress of each of its harts.  I get that - I used to program MacOS in the 1980s when it was cooperative multitasking, and a process that failed to yield would tie up the whole machine.  However, a modern preemptive multitasking operating system doesn't have that problem.  In preemptive multitasking, does every Pthread run on one user-level hart, which might be a guest hart time-multiplexed onto a physical hart?  Thus, is there a one-to-one correspondence between software threads and user harts in a preemptive multitasking system?
@kasanovic you use the term "Execution Context" (EC) in your reply above, which is not in the spec except one mention in 3.6 "PMAs do not vary by execution context".  What is your definition of EC? Should this term be defined in the spec before being used in 3.6, and used elsewhere if it is helpful to explain harts?
Sorry for so many questions - I want to be sure I'm using the terms precisely because they are not standardized across the literature.

I use execution context in the industry-standard way to refer to the state of a computation (as used in the phrase "context switching").  An execution environment enables the state of an execution context to advance (so a simple hardware microcontroller provides a low-level M-mode execution environment which advances the state of the single M-mode execution context by executing instructions and taking interrupts in hardware, while a hypervisor provides multiple supervisor-level execution environments which each can advance the state of a guest-OS execution context).  The interface between an execution context and an execution environment is the "execution environment interface (EEI)", which is an abstract interface that defines the available memory spaces, the instructions supported, behavior of requested traps, and any other per EEI behavior.  The Linux ABI provides an EEI for user processes, and includes things like how the execution context is initialized, what instructions can be executed, what memory can be touched, what syscalls are supported and their effect on the execution context (including syscalls that add harts to the context) and how to interact with the outside world, etc.  An abstract EEI can have many different concrete execution environment implementations (e.g., an actual Linux  kernel running on hardware or a QEMU user-mode emulation can both provide a user-level EE obeying the Linux ABI which can advance the state of a user-level execution context). Note that it is possible to migrate an execution context from one concrete execution environment to another, as is done when migrating VMs around a datacenter or when snapshotting simulations to move between functional-only and cycle-accurate simulations.

I think of context switching as saving and restoring the PC, registers, and CSRs.  That's a lighter weight operation than migrating VMs around a data center. Does "execution context" refer to {PC, registers, CSRs} or does it also include the memory used by a hart (and perhaps state of certain I/O devices), that would be necessary to migrate the hart around a data center?
Returning to the previous question, is there a one-to-one correspondence between software threads and user harts in a preemptive multitasking system?

"context" is a generic term.  When a unix-style OS switches a physical core from one user process to another, the VM page table pointer is switched to present a completely different view of user memory. The only actual physical data movement is swapping the registers in this case, but conceptually the physical core moved into an entirely different memory context.  Migrating a VM around a data center involves more physical copying of data, but is the same concept (moving a context on/off different physical resources).
A user hart is an abstraction of a processor running instruction in that user context.  The problem with equating this to a preemptive software thread is that software threads have their own specifications as to operations they perform and how they synchronize depending on the threading model.  If we take the most primitive common software thread, a pthread, then that can be implemented by a hart, but pthreads provide far more sophisticated synchronization operations that rely on the execution environment interface.  I don't believe you can implement all pthread operations using only harts with no support from the execution environment.  A hart is just something that fetches and executes instructions within an execution context.

Just to pile on, this is the definition of Hart that is in the glossary that I'm resurrecting.
HART
Hardware Thread. At machine-mode level, each hart is a real hardware thread, either one hart per core without hardware multithreading, or multiple harts per core with hardware multithreading, and 'hart' represents the hardware resource. It is possible to emulate harts in software; for example, privileged execution environments can multiplex lesser-privileged harts onto physical hardware using timer interrupts. Note that co-operative multithreading within the same privilege level is not a compliant implementation, however. Across all implementation choices, the concept of a hart is defined as a resource abstraction representing an independently advancing RISC-V execution context within a RISC-V execution environment.
Is this an acceptable definition? My hope is that some day we can just link to the glossary for definitions, making them all single source.
Glossary - https://github.com/riscv/riscv-glossary

@kersten1 A hart is an abstraction of a hardware thread, meaning that it captures the important aspects of a real hardware thread for the purposes of defining the RISC-V specifications.  So we should not equate hart with a "real hardware thread" - a hart is anything that has the appearance of executing instructions within an execution context.  All harts are considered equal from the perspective of the specifications, whether real or emulated.

Hart
An abstraction of a hardware thread that has the appearance of running instructions within an execution context. A hart captures the important aspects of a real hardware thread that are used to define the RISC-V specifications.  All harts are considered equal from the perspective of the specifications, whether real or emulated.
@kasanovic Sorry to keep poking on this but I feel that this is an important concept to get right.... :)

n the unpriv-isa-asciidoc_20240411, page 554 or page 563 defines R-type and I-type formats, which differ only in that instr[31:20] = {funct7, rs2} for R-type and imm12 for I-type.
Some instructions such as fsqrt, fcvt, cpop, and zip use a single register, and contain constants in the instr[24:20] that serve as an extended function code rather than an immediate.  It appears that the unprivileged spec is silent about their type. Is there a collective understanding of type for these instructions?
Is it best to classify these instructions as I-type even though the immediate is not used as a source operand?  Or better to call them R-type with rs2 hardwired to a funct5 value?
Sorry this question is pendantic, but I’m a pedant.
Thank you,
David

The question is totally off-topic given the thread is about the definition of hart. But I’ll briefly comment that I-type would also have been a poor classification because there’s no immediate operand. We use instruction types as classification tools, not as strictures. We’d have hundreds of distinct types if we used that tool with precision—-and at that point, it wouldn’t be doing anyone any service.

My error replying to an old post.  I'll start a new issue.

@kersten1  How about:
Hart: An abstraction of a hardware thread that captures the important aspects of a real hardware thread for the purposes of defining the RISC-V specifications.  In particular, a hart is the agent that executes instruction within an execution context.

"instruction" -> "instructions".
And maybe "RISC-V ISA specifications".
On Tue, Jun 18, 2024, 3:30 PM Krste Asanovic @.***>
wrote:

@kersten1 https://github.com/kersten1 How about:
Hart: An abstraction of a hardware thread that captures the important
aspects of a real hardware thread for the purposes of defining the RISC-V
specifications. In particular, a hart is the agent that executes
instruction within an execution context.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/1257#issuecomment-2177195205,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALLX6GSDD22XPP6YR2GVV6TZICYG5AVCNFSM6AAAAABESO6YXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZXGE4TKMRQGU
.
You are receiving this because you commented.Message ID:
@.***>

@gfavor The term hart is used in non-ISA specifications, but yes, should have plural instructions:
Hart: An abstraction of a hardware thread that captures the important aspects of a real hardware thread for the purposes of defining the RISC-V specifications. In particular, a hart is the agent that executes instructions within an execution context.

authors: aswaterman davidharrishmc gfavor kasanovic kersten1 nick-knight

repo: riscv/riscv-isa-manual


text:
Bitmanip clash with R-type fmt & clash(?) with OP128 (page 42 of ISA manual)

Q1: Should two source reg + 1 dest reg (R-type like) operations go into OP or OP-IM?
Below is the v0.90 BitManip proposed encoding of FSRI:
rs2 | 1 | imm6 | rs1 | func3 | rd | OP-IM
where func3 = 0b101, OP-IM  = 0b0010011
Note:
(1) FSRI is effectively an "R-type" instruction (two source regs, one dest reg) but uses it's own format which is different to the standard R-type instruction format
(2) FSRI is the only instruction to use this format, so this new format is a "one off" for a single instruction
(3) FSRI is placed into the OP-IM major opcode, which to date only contains I-type (single source reg) instruction formats (again, another "one-off")
(4) OP-IM is very constrained in terms of unused opcode space, as non-shift instructions already fully use all the 12 immediate bits, and the RV64 shift instructions leave only 6 bits for a func6 opcode (vs 7 bits in func7 of the OP major opcode).
Q2: Should the possibility of binary compatibility between RV128 and RV64 be preserved by all standard extensions?
Page 42 of the latest draft of RISC V ISA manual hints binary compatibility may be a future goal:
To improve compatibility with RV64, in a reverse of how RV32 to RV64 was handled, we might change the decoding around to rename RV64I ADD as a 64-bit ADDD, and add a 128-bit ADDQ in what was previously the OP-64 major opcode (now renamed the OP-128 major opcode).
I note the use of past tense above ("now renamed the OP-128 major opcode")...
Does this mean the choice of OP-128 (over OP-64) is now highly likely?  (I am in favour if so).
Even if it is premature to make a decision (given RV128 might be some time away), should we be making active decisions now (eg. BitManip) to define instructions (eg. FSRI) that are excluded from RV128 (which the current 0.90 spec states as a policy)?  This would mean RV128 can't have binary compatibility with RV64 (as it won't be a superset of RV64).
[Or if FSRI is then retrofitted into a future RV128 to be binary compatible with RV64, then it would come at considerable cost to OP-IM encoding space, ie: using up 5 of the available 6 func bits in the shift-like I-type OP-IM instructions].
I have already raised the above two issues with BitManip's editor but he has decided it was a broader RISC V opcode question that was outside scope of BitManip.
==> This seems fair enough, I am in favour of having FSRI in BitManip, I just think it should be encoded differently
ie: in OP rather than OP-IM, given that it's essentially a 2 source register R-type instruction and should therefore use the standard R-type format and not create a new single instruction format on it's own.  This will allow it to be available in both RV64 and RV128 whilst only using 6 out of the 10 bits (ie: 64/1024 = 6%) of opcode space in OP's func7+func3 - see (https://github.com/riscv/riscv-bitmanip/issues/42) for how this encoding could work.

I think @cliffordwolf will have to help with this discussion.  I don't understand why rs2 isn't in the usual place, so it's hard to comment on the rest of question 1.
I had imagined RV128 machines would run RV64 code with a mode switch (UXL/SXL/MXL), so it is possible there will be instructions that are legal in RV64 mode but illegal in RV128 mode.  In my mind, the main reason for the change of encoding for ADDD in RV128 is to make supporting both modes cheaper; the goal wasn't to run RV64 code in RV128 mode.  Would you agree, @kasanovic?

I think @cliffordwolf will have to help with this discussion. I don't understand why rs2 isn't in the usual place, so it's hard to comment on the rest of question 1.

I hope @cliffordwolf doesn't mind me quoting his previous reply when I asked him about rs2 being moved (note there is a "cosmetic" renaming of rs2 into rs3 in his terminology):

No, the format doesn't move rs2 to another position. Like with all immediate instructions, rs2 is replaced by the immediate. The new field is rs3 and it is in the usual rs3 position.

My translation/interpretation (apologies in advance if it is not a correct interpretation) is he wants to use a R4-like instruction format for FSRI because he also happens to use the R4 instruction format for FSR and FSL.  However, FSR and FSL are true R4 instructions as they have three input registers - this is not the case for FSRI, which has two register inputs and an immediate 6 bit shift amount.  So he made (IMHO an arbitrary & wrong) choice to modify R4 by dropping rs2 and putting in an immediate field in it's place.  (My opinion is that the good old R-type format is best for FSRI, no need to invent a new immediate version of R4).

In my mind, the main reason for the change of encoding for ADDD in RV128 is to make supporting both modes cheaper; the goal wasn't to run RV64 code in RV128 mode. Would you agree, @kasanovic?

Can I clarify if the RV shift & multiply will also follow encoding of ADDD/ADDQ?  (ie: double word operations in OP and quad word operations in OP-128)
To "sell" the idea of keeping all double word operations in OP, some possible benefits are:
(1) Potential of binary compatibility between RV64 and RV128, but also
(2) Only need to reserve 6 bits for shift fields in OP-IM, and avoid the "wastage" of bits like what occurred when 5 bit shift fields (RV32) went up to 6 bit (RV64)... ie: retains use of all 6 func code bits in OP-IM shift instructions for encoding instructions, even in RV128.
(3) Potentially less operating system mode switching overhead in mixed 64/128 operation?  (64 bit code can simply call 128 bit code using a direct jump, no need to go into a syscall to change mode bits)
(4) Less pipeline complexity?, ie: don't need to handle flushing of invalid RV128 (but valid RV64) instructions from pipelines upon mode switch.  (Presumably RV32 would be more or less deprecated from systems capable of RV128 by such a future point in time).

@xphung wrote:

Below is the v0.90 BitManip proposed encoding of FSRI:
rs2 | 1 | imm6 | rs1 | func3 | rd | OP-IM

@aswaterman wrote:

I think @cliffordwolf will have to help with this discussion. I don't understand why rs2 isn't in the usual place, so it's hard to comment on the rest of question 1.

OP also opened this issue in the riscv-bitmanip repository.
What they write about the rs2 position is a lie. I've clarified that before in the other issue but they still make this false claim. I have no idea what motivates them to make this stuff up. Here is a literal screenshot of the bitmanip spec document showing that the field on the left is rs3:

@xphung wrote:

note there is a "cosmetic" renaming of rs2 into rs3 in his terminology

There is no "cosmetic renaming" going on here, whatever that's supposed to mean. The second operand of a funnel shift (rs2/imm) is the shift amount. It's in its usual place. The 1st and 3rd operand are the data bits. They come from rs1 and rs3, both in their usual places.
I'm happy to discuss any actual design decisions in the bitmanip spec. But OPs interpretation is a strawman.

What they write about the rs2 position is a lie. I've clarified that before in the other issue but they still make this false claim. I have no idea what motivates them to make this stuff up. Here is a literal screenshot of the bitmanip spec document showing that the field on the left is rs3:

The last line matches what I put at the start of this issue submission (aside from immaterial renaming of rs3 vs rs2), so I don't see how it's a "lie":
rs2 | 1 | imm6 | rs1 | func3 | rd | OP-IM
I highlight this issue because:
(1) @cliffordwolf directed me as follows "I'd direct you to the RV128 task group for that" when I raised the issue on GitHub's BitManip source page
(2) Creating a new R-type 2 source register + one destination register format is a major change for RISC V, and hard to justify for a single instruction (when the standard R-type format will do just fine).  It is very important for superscalar decoders to have register fields always in the same position within the instruction, and putting the second source register in a new position complicates instruction decode (just renaming it as rs3 instead of rs2 doesn't fix this)... this is very a basic RISC V principle, so I'm not really suggesting anything radical.

so I don't see how it's a "lie"

It's a falsehood because you claim its rs2 in an unusual location, when in fact it's rs3 in the usual location. And it's a lie because I've told you now a couple of times that this is incorrect, so you know by now. And knowingly telling a falsehood, that's lying.

I highlight this issue because:
(1) @cliffordwolf directed me as follows "I'd direct you to the RV128 task group for that" when I raised the issue on GitHub's BitManip source page

Which you are now framing it as if the word "that" in my comment would have referred to the rs2/rs3 thing, which of course it didn't.

Whether the register field is called rs2 or rs3, it doesn't change the fact that FSRI only has two register fields - it's immaterial what name the second register is given.
The existence of an immediate field as the 3rd input also doesn't really change much the decoding of the two source register fields.  (As an example, SD/SW/SH/SB instructions similarly have an immediate field as a 3rd input, but still keep the two source register operands in the "normal" positions).
The important thing is that superscalar instruction decoders (when decoding the two source register fields) can find the two source register fields in their expected location within the instruction word, so they can check for register out-of-order read/write conflicts as early as possible in the processing pipeline.  (This is very basic RISC microarchitecture knowledge, it's not anything I'm inventing myself - but it should have been a starting point principle when creating the BitManip instruction encoding - obviously it wasn't!  There are likewise other issues with the BitManip encodings, which I'll hold off bringing up for now, as it's important to settle this matter first).

P.S. Please don't "shoot the messenger" (me) on me pointing out where I think designs can be improved.  I'm not trying to be unnecessarily difficult nor do I do this with any personal animosity, I just want to ensure RISC V's ISA design is the best possible.
I'd love to be more collaborative, but this got shut off early as a "time waster", without enough weight given to understanding the basic microarchitecture design issues, and I was redirected elsewhere, so that's what I did.

I don't even know where to start. A pipeline will have existing logic for MUX'ing the imm field into the data path for rs2. rs3 is always in the same position. There is really no problem here. You are for some reason renaming rs3 into rs2 so that you can create the illusion of a problem. In fact, the encodings you proposed in the other issue would create the need for all kinds of additional MUXes. I have no idea why you feel the need to waste everyones time like this. I'm now going to unsubscribe from this issue.

Decoding a 6 bit immediate (even if in new position & needing MUX) is not the time critical path.
The time critical path is more likely to be decoding & scoreboarding/renaming the registers, so optimal positioning of register fields is more important than the immediate fields

In fact, the encodings you proposed in the other issue would create the need for all kinds of additional MUXes.

The existing R4-type FMADD is instructive.
To avoid MUX'ing, a similar argument could have been made that the FMUL instruction should not have used the R-type instruction format - and instead use a format similar to your proposed FSRI (ie: not use an rs2 register placement, but instead place it's second source register in the rs3 position).
But RISC V designers never made that decision for FMUL, and potentially (depending upon exact implementation) instead went for a MUX up to 128 bits (for Quad FP).
For FSLI, the case to avoid MUX'ing is even weaker as we are talking about MUX'ing a maximum of 6 bits (for the shift amount) - a tiny fraction of what RISC V does for FMUL.
So bottom line is your excessive MUX argument was already rejected by the FMAD/FMUL precedent, and I don't see any reason to create a new precedent for FSRI.

source: gharchive/issue

authors: aswaterman cliffordwolf xphung

license_type: permissive

license_source: github-api


text:
Allow to only receive resampling indices (make hierarch agnostic to specific statistical tests).

I am currently working with data from the Human Connectome Project. The dataset contains a lot of siblings, sometimes even dizygotic or even monozygotic twins. Basically for all my statistical tests, I would have to consider this nested structure when computing p-values (which I would like to derive from permutation test) or confidence intervals (which I would like to obtain from bootstrapping tests). This is how the demographic data would look like:

The problem is, that I would like to conduct multivariate tests (i.e. CCA to be more specific). Which means that besides from the demographic information that could be used to conduct a hierarchical resampling procedure, I also have matrices  X  and y that contain the "actual data" and that I would use to perform my statistical test. When looking at the Hypothesis Testing section, I can see that hierarch currently seems to be restricted to simple univariate tests like t-tests and ANOVA? Do you think it would be feasible to allow users to only obtain resampled indices so they could apply their own tests?
This is my current approach which is quite tedious:
1.) Use FSL-Palm to derive exchangability blocks using the hcp2blocks.m function
2.) Use a python implementation of FSL-Palm's quicker function (skpalm.permutations.quickperms) to derive a matrix of reampled indices.

Many thanks for your note @JohannesWiesner!
You raise an interesting and quite useful question, which would ideally be very straightforward to implement - I could expose the helper function the hypothesis_test function uses to generate resampled datasets. I assume with that, you should be able to perform your desired analysis, right?

Yup, that should do the trick! :)

I'll take a crack at this over the next few weekends - hopefully it is going to be as simple as I hope.

Any update on this? Still could use the bootstrapping implementation from hierarch :) AFAIK FSL Palm does not offer drawing with replacement.

@rishi-kulkarni thought I'd just comment to say I work on similar problems to @JohannesWiesner and agree there would be a lot of value to exposing the function to generate the indices to the extent it adds helpful motivation :)
Nice work on this package!

Hi @JohannesWiesner @jameschapman19
This took a little more thinking than I expected, as we want to handle situations where there are different number of observations per treatment group (as is common with biological datasets).
All that said, I ended up deciding to create a generator that yields resampled datasets rather than the resampled indexes, to provide full transparency into which obs are associated with which resampled treatment group. Please open another issue if you notice any bugs with this function!

repo: rishi-kulkarni/hierarch

license: MIT


text:
when and how 'rewriting_compile' function is called?

i read "rewriter.py"  source code, "builtins.compile" confused me
@functools.wraps(original_compile)
    def rewriting_compile(*args, **kwargs):
        ...
builtins.compile = rewriting_compile

what i understand at first is "compile function has been hooked, when run 'python xxxx.py' and compile the code, builtins.compile will be called first, so rewriting_compile function will be called".
but after i run test code as below, i am confused.
import dis
import functools
import random
import os
import _frozen_importlib_external
import builtins
from sys import version_info
from ast import PyCF_ONLY_AST

original_compile = builtins.compile

@functools.wraps(original_compile)
def rewriting_compile(*args, **kwargs):
    flags = (len(args) >= 4 and args[3]) or kwargs.get("flags") or 0
    print("rewriting_compile")
    return False

builtins.compile = rewriting_compile

print("end")

"rewriting_compile" will not be printed.
so my question is  " when and how 'rewriting_compile' function is called".

I'm not sure why it would be in your case - in python, the compilation step is generally only done when you import a new module (or e.g. use eval to run an arbitrary statement). This is why I mention that install_rewriter() needs to be called very early on in the python process, preferably before any interesting modules are imported.

import functools
import builtins

original_compile = builtins.compile

@functools.wraps(original_compile)
def rewriting_compile(*args, **kwargs):
    flags = (len(args) >= 4 and args[3]) or kwargs.get("flags") or 0
    print("rewriting_compile")
    return False

builtins.compile = rewriting_compile
compile = rewriting_compile

import hashlib

eval("1==1")

# code = compile("", "name", "exec")

if "eval" or "import a new module" will call compile function，why above code does not print "rewriting_compile"?

I'm not sure about the eval case (I've never really dug into the inner workings of eval) but for the import hashlib, this is a case that won't call builtins.compile because the bytecode for that will have already been compiled & written to a .pyc file - instead it will call _frozen_importlib_external._compile_bytecode when it tries to load that off disk. That's why I have to hook both of them.

authors: leveryd risicle

repo: risicle/cpytraceafl


text:
Panicked when handling the request: column pruning fails to generate equivalent plan.

Describe the bug
Trying out the new generate_series with now() supported, but:
dev=> create materialized view time_mv as
dev-> select Extract('year' FROM Date t::date) as year, Extract('month' FROM Date t::date) as month, 1::int as constant
dev-> from
dev-> generate_series(
dev(>     '2024-01-01 00:00:00+00'::timestamptz,
dev(>     now(),
dev(>     interval '1 month'
dev(> ) as s(t);

ERROR:  Panicked when handling the request: column pruning fails to generate equivalent plan.
Input schema: Schema { fields: [] }
Input plan:
LogicalProject { exprs: [] }
└─LogicalNow
Output schema: Schema { fields: [ts:Timestamptz] }
Output plan:
LogicalNow

SQL: CREATE MATERIALIZED VIEW time_mv AS SELECT EXTRACT(YEAR FROM CAST(DATE 't' AS DATE)) AS year, EXTRACT(MONTH FROM CAST(DATE 't' AS DATE)) AS month, CAST(1 AS INT) AS constant FROM generate_series(CAST('2024-01-01 00:00:00+00' AS timestamptz), now(), INTERVAL '1 month') AS s (t)
This is a bug. We would appreciate a bug report at:
  https://github.com/risingwavelabs/risingwave/issues/new?labels=type%2Fbug&template=bug_report.yml

But if:
dev=> create materialized view time_mv as
dev-> select t, 1::int as constant
dev-> from
dev-> generate_series(
dev(>     '2024-01-01 00:00:00+00'::timestamptz,
dev(>     now(),
dev(>     interval '1 month'
dev(> ) as s(t);
CREATE_MATERIALIZED_VIEW

Error message/log
No response
To Reproduce
No response
Expected behavior
No response
How did you deploy RisingWave?
No response
The version of RisingWave
latest main branch
dev=> select version();
                       version
------------------------------------------------------
 PostgreSQL 13.14.0-RisingWave-1.11.0-alpha (unknown)
(1 row)

Additional context
No response

The panic is the surface problem. The deep problem is that Date t::date will try to parse t as date type, so that the final schema is actually completely not related to LogicalNow.
Should use extract('year' from t) or extract('year' from t::date) instead.
I'm fixing the column pruning bug.

Besides the fix for:

column pruning panic
sqlparser misinterpretation

I also realized another issue in the example above:
from
generate_series(
     '2024-01-01 00:00:00+00'::timestamptz,
     now(),
     interval '1 month'
) as s(t);

Here the interval '1 month' is actually of variable length (28 to 31 days). @stdrc Could you confirm if such "bad" interval values would be problematic in the intended use case? FYI the following "worse" interval value can cause an infinite loop in PostgreSQL batch query:
select generate_series('2024-01-31T00:00:00Z'::timestamptz, now(), interval '1 month -29 days');

Here the interval '1 month' is actually of variable length (28 to 31 days). @stdrc Could you confirm if such "bad" interval values would be problematic in the intended use case?

The timestamp calculation is based on session timezone, so it should behave as expected.

FYI the following "worse" interval value can cause an infinite loop in PostgreSQL batch query:
select generate_series('2024-01-31T00:00:00Z'::timestamptz, now(), interval '1 month -29 days');

I just raised another issue #17786 to track this bug, cuz this seems not quite related to the bug described in this issue. Now we can close this issue.

authors: lmatz stdrc xiangjinwu

repo: risingwavelabs/risingwave


text:
refactor(over window): add some short-circuit logic in find_affected_ranges and some other refactoring

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Introduce a new type RowsFrameBounds to represent ROWS frame bounds;
Add short circuit logic in find_affected_ranges to avoid wasted computation.

This is a preliminary work for RANGE frame support.
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[x] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

I'm doing a big refactoring for find_affected_ranges, let's merge this PR first cuz my refactor branch is based on this.

source: gharchive/pull-request


text:
ci: add a github action to ensure no package version regression

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
close #17250

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.


text:
refactor(type): introduce Timestampz type

Signed-off-by: Runji Wang wangrunji0408@163.com
I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
This PR introduces Timestampz type as a wrapper over the original i64, as well as the corresponding TimestampzArray and TimestampzArrayBuilder. It makes a 1-1 mapping between SQL data types and Rust types, removes the ambiguity of i64 value -> int64 or timestampz. Thus ToText and ToBinary can be called without specifying the data type.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Refer to a related PR or issue link (optional)

Thus ToText and ToBinary can be called without specifying the data type.

This may not be the right direction to go, although a 1-1 mapping does feel cleaner at first glance.
There are basically 2 different designs:

Scalar/Datum contains enough sql-typing information, and can derive its corresponding DataType.
Scalar/Datum only contains arbitrary binary data, whose proper interpretation depends on its accompanying DataType.

In our current implementation, ScalarImpl is not [u8] but an enum. So it does feel closer to the former design than the latter. However, this may just be a side effect of rust tagged union (aka enum):

Matching against enum is easier to use than reinterpreting [u8].
The extra tagging bits inside enum ScalarImpl happen to contain enough information as enum DataType.

My concern is, as our DataType becomes complex later, the tagging bits inside ScalarImpl won't be enough, and we still need to take the latter design that passes ScalarImpl and DataType together.

Do beware of: https://github.com/risingwavelabs/risingwave/pull/7067 added to merge train.

@xiangjinwu Thanks for the explanation! I'll revert this part.

Closed as it will encourage ignoring data types that leads to misinterpretation. Will reopen it when we find a proper solution.

authors: jon-chuang wangrunji0408 xiangjinwu


text:
Add FlashTorch and Lucent under Visualization

Thanks for the compilation of PyTorch resources! I've added two more visualization libraries FlashTorch and Lucent (disclaimer I am the owner of Lucent)

Thanks! Merged.

authors: greentfrapp ritchieng

repo: ritchieng/the-incredible-pytorch

license: mit

license_source: bigquery


text:
Add Out Txt file for --playlist option

What is the purpose of your issue?

[ ] Bug
[X] Feature Request
[ ] Question
[ ] Other

Description

Add Option for saving --playlist to specific file, not just the playlist_name.txt
Log

Duplicate of #423.

authors: filipppp ritiek

repo: ritiek/spotify-downloader


text:
extension:createFile failed in code v1.35

The extension stopped working - tried to reinstall it but still getting the error

Did anyone ever figure this out?

repo: ritwickdey/vscode-create-file-folder


text:
provide consensus function to read transaction using its long ID

It is already possible to fetch/read a transaction using its shortID (see: https://godoc.org/github.com/rivine/rivine/modules/consensus#ConsensusSet.TransactionAtShortID). Using the shortID is the most efficient, however when creating a transaction using SendCoins (also used to register Data), we only know the long ID (TransactionID). Therefore it should be possible to get a transaction of any user just using that ID.
The shortID should be returned as part of the returned transaction (should a transaction of the long ID (== transactionID) be found). This way next time the user can use the ShortID which is more efficient.

Right now transaction ID's are not indexed in the consensus set. As such we'd need to loop over every block to see if txn matches the ID, and if the ID is not present we'll need to check the entire chain, which might take a long time depending on the size of the chain. So its best tto create a new bucket which maps long ID's to short ID's, as that should not take up a lot of space. Using this approach will make the long ID equally efficient to the short ID as well.

authors: GlenDC LeeSmet

repo: rivine/rivine


text:
Need help on setup

I'm installing on my macOs Serria 10.12.4. I'm using python 3.6.
Pip version : pip 9.0.1 from /usr/local/lib/python3.6/site-packages (python 3.6)
When I run pip3 install -e .
But it show me this error. Anyone know how to fix this?
Build using cmake ...
Scanning dependencies of target dlib
[  0%] Building CXX object dlib_build/CMakeFiles/dlib.dir/base64/base64_kernel_1.cpp.o
[  1%] Building CXX object dlib_build/CMakeFiles/dlib.dir/bigint/bigint_kernel_1.cpp.o
[  2%] Building CXX object dlib_build/CMakeFiles/dlib.dir/bigint/bigint_kernel_2.cpp.o
.....
[ 91%] Building CXX object CMakeFiles/dlib_.dir/src/other.cpp.o
/private/var/folders/c6/vl7hxs354zjfz4qdgmn258900000gn/T/pip-build-ja5_ssrg/dlib/tools/python/src/other.cpp:56:1: error: reference to 'list' is ambiguous
list _max_cost_assignment (
^
 /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/list:777:29: note: candidate found by name lookup is 'std::__1::list'
class _LIBCPP_TYPE_VIS_ONLY list
^
/usr/local/include/boost/python/list.hpp:57:7: note: candidate found by name lookup is 'boost::python::list'
class list : public detail::list_base
^
/private/var/folders/c6/vl7hxs354zjfz4qdgmn258900000gn/T/pip-build-ja5_ssrg/dlib/tools/python/src/other.cpp:72:11: error: reference to 'list' is ambiguous
const list& assignment
^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/list:777:29: note: candidate found by name lookup is 'std::__1::list'
class _LIBCPP_TYPE_VIS_ONLY list
^
/usr/local/include/boost/python/list.hpp:57:7: note: candidate found by name lookup is 'boost::python::list'
class list : public detail::list_base
^
2 errors generated.
make[2]: *** [CMakeFiles/dlib_.dir/src/other.cpp.o] Error 1
make[1]: *** [CMakeFiles/dlib_.dir/all] Error 2
make: *** [all] Error 2
 error: cmake build failed!

same problem. need help please..

I'm having exactly the same problem!

I remove all the version of setup.py
	install_requires=[
  'Keras',
 'editdistance',
'h5py',
'matplotlib',
'numpy',
'python-dateutil',
'scipy',
'Pillow',
'tensorflow',
'Theano',
'nltk',
 'sk-video',
 'dlib'
  ])
This seems work for me.

authors: arnoldtkl optimisth sf308

repo: rizkiarm/LipNet


text:
Transformação VDEFMIN_UHE_PAT para VDEFMIN_UHE_EST

arquivo VDEFMIN_UHE_EST, conversão de VDEFMIN_UHE_PAT para VDEFMIN_UHE_EST parece não estar batendo. Excel da extrema esquerda mostra o valor do VDEF_UHE_EST para o estágio 10 cenário 10 e o VDEF_UHE_PAT (excel da direita) apresenta valores para patamares do VDEF_UHE_PAT em m3/s. A conta mostra que ao multiplicar-los por 2.63, transformando para hm3 encontram-se os valores:
0, 1360.7 e 2902.01, que somados (pois são hm3, pode somar), resulta em 4262.71, que transformado para m3/s vira 1620.802, não batendo com o valore dado no VDEFMIN_UHE_EST no excel da esquerda.

A partir do commit 1a7e376e70081a4fda402d2b9b0105e02c3e81e3 os valores de violações estão válidos. Porém, esta e outras violações de variáveis a nível de UHEs passaram a ser disponibilizadas em hm3 ao invés de m3/s.
A partir da release v2.0.0 esta informação poderá ser extraída em ambas as unidades, nos novos formatos das sínteses.

repo: rjmalves/sintetizador-newave


text:
Compilation failed in require at ...

Following the README I cloned repository, ran init.sh which executed successfully, I am able to get project info, bug details and I can checkout specific version.
The issue is when I try to execute compilation of that version it fails.
defects4j checkout -p Lang -v 1b -w /tmp/test-folder
defects4j compile

OS: Mac OS X (Catalina)
Java: 13.0.2(+8).
Is there a way I can use this project?

It seems you're using an unsupported Java version. As described in here, the latest version of D4J requires Java 8.

@KovacicB just to follow-up on the Java-8 requirement. You can install a Java-8 JDK using homebrew or download it from the Oracle website.
Hope this helps.

Yes, Java 8 solved the issues. Thank you for quick responses!

authors: KovacicB jose rjust


text:
SharedConfigLoadError

Dear Ryan,
Thank you for this plugin. This is amazing to use!
I just had a strange error. One thing i did was saving the config file. Even though that the config file is in the correct format (because from the CLI I can still run commands) I get the below error. Do you know how to resolve this?

[16:45:47.033] Logging Started...
[16:45:50.673] AWS Console Services[Script Filter] Queuing argument ''
[16:45:50.763] AWS Console Services[Script Filter] Script with argv '(null)' finished
[16:45:50.765] ERROR: AWS Console Services[Script Filter] Code 1: 🍺
16:45:50 workflow.go:327: ---- AWS Console Services/3.6.0 (AwGo/0.20.2) ----
16:45:50 main.go:31: running workflow with query: ``
16:45:50 workflow.go:342: ------------------ FATAL ERROR -------------------
16:45:50 workflow.go:343: SharedConfigLoadError: failed to load config file, /Users/daanhage/.aws/credentials
caused by: INIParseError: invalid state with ASTKind { {4 NONE 0 [61]} true [{expr {1 STRING 0 [99 108 105 95 112 97 103 101 114]} true []}]} and TokenType none : goroutine 1 [running]:
runtime/debug.Stack(0xc0001c7c28, 0x1, 0x1)
	/usr/local/Cellar/go/1.14.5/libexec/src/runtime/debug/stack.go:24 +0x9d
github.com/deanishe/awgo.(*Workflow).Run.func2(0xc0000cf0e0)
	/Users/ryankoval/go/pkg/mod/github.com/deanishe/awgo@v0.25.0/workflow.go:343 +0xe7
panic(0x152d6e0, 0xc0000a9c60)
	/usr/local/Cellar/go/1.14.5/libexec/src/runtime/panic.go:969 +0x166
github.com/aws/aws-sdk-go/aws/session.Must(...)
	/Users/ryankoval/go/pkg/mod/github.com/aws/aws-sdk-go@v1.34.10/aws/session/session.go:326
github.com/rkoval/alfred-aws-console-services-workflow/awsworkflow.NewWorkflowSession(0x0, 0x0, 0xc0001c7e98)
	/Users/ryankoval/go/src/github.com/rkoval/alfred-aws-console-services-workflow/awsworkflow/aws.go:11 +0xef
main.main.func1()
	/Users/ryankoval/go/src/github.com/rkoval/alfred-aws-console-services-workflow/main.go:32 +0x9c
github.com/deanishe/awgo.(*Workflow).Run(0xc0000cf0e0, 0x15961e0)
	/Users/ryankoval/go/pkg/mod/github.com/deanishe/awgo@v0.25.0/workflow.go:357 +0x28f
main.main()
	/Users/ryankoval/go/src/github.com/rkoval/alfred-aws-console-services-workflow/main.go:30 +0x39
16:45:50 workflow.go:344: ---------------- END STACK TRACE -----------------
16:45:50 feedback.go:468: Sent 1 result(s) to Alfred
16:45:50 workflow.go:375: [ERROR] SharedConfigLoadError: failed to load config file, /Users/daanhage/.aws/credentials
caused by: INIParseError: invalid state with ASTKind { {4 NONE 0 [61]} true [{expr {1 STRING 0 [99 108 105 95 112 97 103 101 114]} true []}]} and TokenType none
16:45:50 workflow.go:401: ------------------- 5.139765ms -------------------
[16:45:50.793] AWS Console Services[Script Filter] {
  "variables": {
    "AW_SESSION_ID": "L0IRDFFUKBAXMVQ07S4J48ON"
  },
  "items": [
    {
      "title": "SharedConfigLoadError: failed to load config file, /Users/daanhage/.aws/credentials\ncaused by: INIParseError: invalid state with ASTKind { {4 NONE 0 [61]} true [{expr {1 STRING 0 [99 108 105 95 112 97 103 101 114]} true []}]} and TokenType none",
      "valid": false,
      "icon": {
        "path": "/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertStopIcon.icns"
      }
    }
  ]
}
[16:47:38.261] AWS Console Services[Script Filter] Queuing argument ''
[16:47:38.346] AWS Console Services[Script Filter] Script with argv '(null)' finished

Dear Ryan (and other who might face this issue). Very strange.... but this syntax broke. However not always:
[default]
aws_access_key_id = xxxxx
aws_secret_access_key = xxxx
cli_pager= # this cli_pager param...however now I cannot reproduce anymore as well. Quite strange...

The solution:

I backuped the credentials & config file.
Reran aws configure
Verified that alfred aws workflow worked again
Added back parts of my original file 1 bit at a time

Hope this helps others a little.


text:
Support more than 256 variants for archived enums

I'm using rkyv in an RPC system where I have a Procedure enum that's basically:
#[repr(u16)]
enum Procedure {
    DoThingA(Box<ThingAData>) = 100,
    DoThingB(Box<ThingBData>) = 200,
    // many more...
}

where commands are grouped together and have custom discriminant values. My idea was to have the discriminants be constant, but allow room in between for more to be added in a way that is meaningful to humans. By keeping them constant in such a simple structure, it would be easy for CheckBytes to validate it even if more are added in the future, helping with stability when I update distributed systems gradually in a production environment.
Unfortunately, unless I'm missing something, rkyv currently generates new linear u8 discriminants for the Tag and Archived values/discriminants, due to its own compatibility concerns regarding Endianness and alignment.
To solve the Endian issue, I came up with the idea to double the width of my discriminants and mirror their bytes so the value is the same between Big/Little endian, and thereby making the Tag/Archived enum #[repr(u32)] (and maybe #[repr(u32, align(4))]), and immune to that cross-platform difference.
I implemented this manually Here, but would like a way to enable copying the raw multibyte discriminants into the Tag/Archived enum from the derive macros, as that would make my own code much more maintainable.
I could turn the enum in that referenced code into something that only generates:
#[repr(u32, align(4))]
#[derive(rkyv::Archive, rkyv::Serialize, rkyv::Deserialize)]
enum Procedure {
    DoThingA(Box<ThingAData>) = mirror_tag(100),
    DoThingB(Box<ThingBData>) = mirror_tag(200),
    // many more...
}

and rkyv could copy that repr information and custom discriminant expressions onto the Tag/Archived enum.
This could either be done via an attribute such as #[unsafe_archive_repr(u32, align(4))] (as suggested in Discord), or a variation of that which will assert at compile time if the discriminants are cross-Endian-safe, likely via checking of the Tag variants are mirrored.
So in essence, I'd like for rkyv to provide a way to specify the repr of the resulting Archived enum/tags, and copy the expressions that generate the discriminant values from the originating struct, such that I can create RPC enums that can maintain backwards compatibility in an elegant way.

Unfortunately, I have to take this out of the 0.8 milestone since there's just not enough time to get this done. I'm going to change the wording of this issue slightly to address supporting more than 256 variants for enums.
In the meantime, you may be able to get away with a "manual enum" by wrapping an ArchivedU16 and holding a union of your fields.

@djkoloski

In the meantime, you may be able to get away with a "manual enum" by wrapping an ArchivedU16 and holding a union of your fields.

Could you please elaborate ? What would it look like ?
I need a simple enum with more than 256 variants
Thanks

Here's a quick example of a hand-rolled simple enum with no data-carrying variants:
use rkyv::{
    bytecheck::{CheckBytes, InvalidEnumDiscriminantError, Verify},
    primitive::ArchivedU16,
    rancor::{fail, Fallible, Source},
    traits::NoUndef,
    Archive, Deserialize, Place, Portable, Serialize,
};

// Original enum
#[derive(Clone, Copy)]
enum MyEnum {
    A = 0,
    B = 1,
    // ...
    Z = 1000,
}

// Hand-written archived enum
#[derive(CheckBytes, Portable)]
#[bytecheck(crate = rkyv::bytecheck, verify)]
#[repr(C)]
struct ArchivedMyEnum(ArchivedU16);

// Implementation detail: `ArchivedMyEnum` has no undef bytes
unsafe impl NoUndef for ArchivedMyEnum {}

impl ArchivedMyEnum {
    // Internal fallible conversion back to the original enum
    fn try_to_native(&self) -> Option<MyEnum> {
        Some(match self.0.to_native() {
            0 => MyEnum::A,
            1 => MyEnum::B,
            // ...
            1000 => MyEnum::Z,
            _ => return None,
        })
    }

    // Public infallible conversion back to the original enum
    pub fn to_native(&self) -> MyEnum {
        unsafe { self.try_to_native().unwrap_unchecked() }
    }
}

unsafe impl<C: Fallible + ?Sized> Verify<C> for ArchivedMyEnum
where
    C::Error: Source,
{
    // verify runs after all of the fields have been checked
    fn verify(&self, _: &mut C) -> Result<(), C::Error> {
        // Use the internal conversion to try to convert back
        if self.try_to_native().is_none() {
            // Return an error if it fails (i.e. the discriminant did not match
            // any valid discriminants)
            fail!(InvalidEnumDiscriminantError {
                enum_name: "ArchivedMyEnum",
                invalid_discriminant: self.0.to_native(),
            })
        }
        Ok(())
    }
}

impl Archive for MyEnum {
    type Archived = ArchivedMyEnum;
    type Resolver = ();

    fn resolve(&self, _: Self::Resolver, out: Place<Self::Archived>) {
        // Convert MyEnum -> u16 -> ArchivedU16 and write to `out`
        out.write(ArchivedMyEnum((*self as u16).into()));
    }
}

// Serialization is a no-op because there's no out-of-line data
impl<S: Fallible + ?Sized> Serialize<S> for MyEnum {
    fn serialize(&self, _: &mut S) -> Result<Self::Resolver, <S as Fallible>::Error> {
        Ok(())
    }
}

// Deserialization just calls the public conversion and returns the result
impl<D: Fallible + ?Sized> Deserialize<MyEnum, D> for ArchivedMyEnum {
    fn deserialize(&self, _: &mut D) -> Result<MyEnum, <D as Fallible>::Error> {
        Ok(self.to_native())
    }
}

To add support for data, this would have to be expanded further to build a fully destructured enum using a union of variant structs.
I think the only real blocker to supporting enums with more than 256 variants is that the discriminants for the generated archived enum would have to be different on little-endian and big-endian machines. @novacrazy had the idea of mirroring the discriminant to work around that, which would also work at the cost of bloating the tag size a bit.

Thanks a lot, I would not have found it by myself honestly.

To clarify, the blockers for enums with multibyte discriminants are:

Endianness: The generated enums would have different discriminants assigned to variants. This could lead to subtle bugs for users.
Alignment: We can increase the alignment of the generated enum to get a portable representation. However, we can't decrease the alignment, so this would not work with the unaligned feature.

I keep forgetting some of these problems.

authors: ThomasCartier djkoloski novacrazy

repo: rkyv/rkyv


text:
Update macro docs

Updated some docs for the Archive, Serialize, and Deserialize derive macros.

https://github.com/rkyv/rkyv/blob/9d1b30f31580ca07d5df0c43892e89b079ac8e7d/rkyv_derive/src/lib.rs#L64
Maybe this should now read "enable safe accessing"?

https://github.com/rkyv/rkyv/blob/9d1b30f31580ca07d5df0c43892e89b079ac8e7d/rkyv_derive/src/lib.rs#L64
Maybe this should now read "enable safe accessing"?

Both would probably be the most explicit: "enable safe accessing and deserialization".

authors: MaxOhn djkoloski


text:
ReflectionType is not namespaced

ReflectionType is not properly namespaced causing an error at runtime.

@rlerdorf how are you able to run this without correcting this error. i am very curious now, do you use some special PHP version?

repo: rlerdorf/phan


text:
[Core] Improve define-by-run state management.

In PyTorch, we currently manage state for get/set weights via a wrapper object called PyTorchVariable which accesses layer weights.
However, in define by run backends we also may want to use lists and numpy arrays to manage state and set/get it through the executor interface, e.g. in buffers. Performing space inference is difficult on raw lists so we could consider wrapping the 'list' variables with an object storing the desired spaces.

Management of these is now unified, e.g. in buffers all variables are created via get_variables.

repo: rlgraph/rlgraph


text:
Don't link to diasp.eu node for the diaspora* project

diaspora* is a decentralized network. Currently, the page links to diasp.eu which is one of the hundreds installations of diaspora*. I guess the site should link to the official website of diaspora* instead, explaining how to delete an account. Do you want me to open a PR?

I've updated the name instead (to show its actually for diasp.eu).
Thanks :+1:

Well the process and even the end of the url (/user/edit#close_account_pane) is true for every diaspora* nodes (and diasp.eu is only one of them). I think it will be nice to keep the name "diaspora*".

authors: Flaburgan rmlewisuk


text:
Latest release not marked as latest release

In https://github.com/rmrevin/yii2-fontawesome/releases the latest release is marked as 2.15.0 but there are several newer releases since then. In composer if you require something like ~2.9 it gets 2.15 instead of 2.17.1. Why is 2.15.0 marked as the latest release instead of 2.17.1?

Hello. Added release 2.16 and 2.17. Thanks for issue.

authors: derekisbusy rmrevin


text:
Sensible default for outputPublicPath

I am not at all a webpack expert, so this change may not be appropriate. However when writing my own config, I did not need a public path, default being '/'.
So I think we should rely on this default when computing the component path (but once again I am not a webpack expert).

Was this change created to fix a bug of some sort or improve the library, or is this just a "i think it should be this way" type of change?

Hi,
It is more a small improvement. Sometime you don't set the publicPath in your output config, because Webpack provide its own default value (/). So I had to seek for this value and to set it manually in order to use your loader. It is not a bug per se but one should not need to change the output config in order to set a loader.
But I can't guarantee that there is no regression whatsoever, take it as a proposal.

authors: eric-burel rnicholus

repo: rnicholus/web-components-loader


text:
Median value

Hi, I am having issue with cheapest blocks. Sometimes it misses the night. I need to run battery recharge each night + each day (when there is not enough sun). My guess it would be median. And if value is under median, the sensor would go on signaling enable charging (to get over top prices) . Could that be managed or added to sensor set? The idea is to be able to utilize both graph lows, not only the main cheapest block. thanks

Median can be achieved by using Current Spot Electricity Hour Order. When it's value is <= 12 it's below the median, otherwise it's above it.
Or maybe I just don't understand the question :)

thanks, I have had issues with working with the hour order, i cannot correctly formulate the automation rules, because the values are in the attributes and i seem not to understand how to create a condition
condition:

condition: state
entity_id: sensor.current_spot_electricity_hour_order
attribute:  bellow 12 ?   // values like: "2023-11-02T12:00:00+01:00"
state: ""
Can you please give an example, how to create one? something like when current spot price is bellow <12 . Sorry to bother you.

Sorry for late answer, I missed the notification for this comment.
Try something like this:
description: ""
mode: single
trigger:
  - platform: numeric_state
    entity_id:
      - sensor.current_spot_electricity_hour_order
    below: 12
condition: []
action: []

sensor.current_spot_electricity_hour_order is order of current hour when you sort all hours in a day by the price. So when value of this sensor is below 12, it means the price is below median.


text:
Refactor Proposal

I am thinking to refactor this library so to include below things

Update cropper.js version
use Typescript
Convert to a functional component
add unit tests
update documentation
Provide Hooks for easy usage

Things would be more or less in the above order and therefore I would like to ask the people using it if this is something they would like to have.

Actually really pumped to see this, do you think 'develop' is far enough along that I could start using it without regretting it?

If you want you can try using the branch now.
I am occupied a lot these days. If I find I'll make a preview/beta release so we can properly test it.
I'll also need to find some time to add unit tests

@hisnameisjimmy if you can try out this and provide some feedback then I would be really thankful
https://www.npmjs.com/package/react-cropper/v/2.0.0-0

Closing this for now. Will try to make a proper 2.0.0 release soon.

authors: hisnameisjimmy shekhar-shubhendu

repo: roadmanfong/react-cropper


text:
Improve adb -s completion to show helpful info

Currently it shows for example the following
DEVICE_ID  -- transport_id:2
Which doesn't really ease device selection, I've adapted the awk script to print device name with it's model name, see the example below
DEVICE_ID  -- Pixel_3(blueline)

Good job! :+1:

Thanks

repo: robbyrussell/oh-my-zsh


text:
add readme for the rust plugin

I added a readme for the rust plugin, hope it helps!

Thanks!

authors: jotaro-sama mcornella


text:
WIP: Add list songs functionality

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

TODO: Create test cases to cover new code.

Is this PR ready for review?

Not quite, it's failing the build, and there's still some test cases to write.

Since this is failing the build and hasn't seen update for over a month - I'm going to close this.
If you decide to come back to this, feel free to open another PR

authors: robertmain tyzoid

repo: robertmain/jukebox


text:
AFHTTPSessionOperation not run on background

Thanks for your library.
I used AFHTTPSessionOperation and add it to NSOperationQueue but it always run on main thread. I want that task will be processed on background thread. Please give me some advice for this.
This is my code:
   // create opertation
    NSOperation *operation = [AFHTTPSessionOperation operationWithManager:_sessionManager HTTPMethod:@"POST" URLString:apiURL parameters:params uploadProgress: nil downloadProgress: nil
    success:^(NSURLSessionDataTask * _Nonnull task, id  _Nonnull responseObject) {
        @autoreleasepool{
            if(responseObject) {
                completion(responseObject,nil);
            }
        }
    } failure:^(NSURLSessionDataTask * _Nonnull task, NSError * _Nonnull error) {
        @autoreleasepool{
            NSLog(@"Error: %@", error);
            completion(nil,error);
        }
    }];
    [_opertationQueue addOperation:operation];

Thanks for you help.

This is not a AFHTTPSessionOperation issue, but rather central behavior of AFNetworking in general. In short, completion handlers are run on the session manager's completionQueue, and if that's nil, they run on the main queue. You can change this behavior by specifying the GCD queue you want the completion handlers run upon:
AFHTTPSessionManager *sessionManager = [AFHTTPSessionManager manager];
sessionManager.completionQueue = dispatch_queue_create("com.domain.app.networkcompletionqueue", DISPATCH_QUEUE_SERIAL);

authors: HTKT robertmryan

repo: robertmryan/AFHTTPSessionOperation


text:
exec from the TUI breaks when multiple wanders exist in $PATH and doesn't pass env vars

Describe the bug
The spawned wander here points to a different binary than the one that started the current process and potentially does not read the original process's env vars or config params.
To reproduce
Steps to reproduce the behavior:

install wander<0.14.0 somewhere default, say where homebrew finds it
install wander@0.14.0 somewhere not in your $PATH
run wander and try to exec into an alloc, you should see it try to spawn the binary from 1 above

Expected behavior

exec  may make use of the path returned by os.Executable instead of the string "wander" as well as adding existing env vars to the spawned process and a reference to the config file param to ensure the spawned process uses the same settings as the original running process.

Screenshots
If applicable, add screenshots to help explain your problem.
Please complete the following information:

OS: Darwin,Linux
Terminal: all
Version: 0.14.0
Configuration options used: env vars and .wander.yaml

Hi @coderigo , thanks for trying out v0.14 and opening this issue! What I'm getting here is that there are really 3 bugs at play:

the wander executable run by the exec action should be the same as the running wander executable (right now it resolves to whichever wander executable is in your $PATH)
the cli options passed to the exec action should be the same as those passed to the running wander executable (right now they aren't)
the env vars accessible to the exec action should be the same as those passed to the running wander executable (right now they aren't)

Does that sound right?

first of all - thanks for a great tool 💪
You've got it bang on. I didn't know if you wanted to treat them as one bug or three separate ones since it all seems to happen in those few lines of code, but yes, exactly what you describe is the issue.

first of all - thanks for a great tool 💪
You've got it bang on. I didn't know if you wanted to treat them as one bug or three separate ones since it all seems to happen in those few lines of code, but yes, exactly what you describe is the issue.

Thanks! :) Sounds good, I'm happy to keep this as one bug issue. Should be fixed shortly!

Legend

@coderigo , mind trying out the fix and letting me know how it looks when you get the chance?
go install github.com/robinovitch61/wander@4172951d37d915e7f02b2660980130992f168e8e

(latest commit on next branch)

glorious. does what it says on the can 👍 thanks!


text:
Unable to run

Hi,
I am using Python 3 in conda with the spyder and created a new env for ENVbrainDecode.
I am trying to run examples/bcic_iv_2a.py and getting this error
( **File "/Users/sagihaider/anaconda/envs/ENVbrainDecode/lib/python3.6/site-packages/torch/cuda/__init__.py", line 51, in _check_driver
    raise AssertionError("Torch not compiled with CUDA enabled")
AssertionError: Torch not compiled with CUDA enabled**)

Can you please look into this.
Tha following packages are available in the ENVbrainDecode:
(ENVbrainDecode) Haiders-MacBook-Pro:~ sagihaider$ conda list
# packages in environment at /Users/sagihaider/anaconda/envs/ENVbrainDecode:
#
_license                  1.1                      py36_1
alabaster                 0.7.10                   py36_0
anaconda                  4.4.0               np112py36_0
anaconda-client           1.6.3                    py36_0
anaconda-navigator        1.6.2                    py36_0
anaconda-project          0.6.0                    py36_0
appnope                   0.1.0                    py36_0
appscript                 1.0.1                    py36_0
asn1crypto                0.22.0                   py36_0
astroid                   1.4.9                    py36_0
astropy                   1.3.2               np112py36_0
babel                     2.4.0                    py36_0
backports                 1.0                      py36_0
beautifulsoup4            4.6.0                    py36_0
bitarray                  0.8.1                    py36_0
blaze                     0.10.1                   py36_0
bleach                    1.5.0                    py36_0
bokeh                     0.12.5                   py36_1
boto                      2.46.1                   py36_0
bottleneck                1.2.1               np112py36_0
Braindecode               0.1.6.3                   <pip>
cffi                      1.10.0                   py36_0
chardet                   3.0.3                    py36_0
click                     6.7                      py36_0
cloudpickle               0.2.2                    py36_0
clyent                    1.2.2                    py36_0
colorama                  0.3.9                    py36_0
contextlib2               0.5.5                    py36_0
cryptography              1.8.1                    py36_0
curl                      7.52.1                        0
cycler                    0.10.0                   py36_0
cython                    0.25.2                   py36_0
cytoolz                   0.8.2                    py36_0
dask                      0.14.3                   py36_1
datashape                 0.5.4                    py36_0
decorator                 4.0.11                   py36_0
distributed               1.16.3                   py36_0
docutils                  0.13.1                   py36_0
entrypoints               0.2.2                    py36_1
et_xmlfile                1.0.1                    py36_0
fastcache                 1.0.2                    py36_1
flask                     0.12.2                   py36_0
flask-cors                3.0.2                    py36_0
freetype                  2.5.5                         2
get_terminal_size         1.0.0                    py36_0
gevent                    1.2.1                    py36_0
greenlet                  0.4.12                   py36_0
h5py                      2.7.0               np112py36_0
hdf5                      1.8.17                        1
heapdict                  1.0.0                    py36_1
html5lib                  0.999                    py36_0
icu                       54.1                          0
idna                      2.5                      py36_0
imagesize                 0.7.1                    py36_0
ipykernel                 4.6.1                    py36_0
ipython                   5.3.0                    py36_0
ipython_genutils          0.2.0                    py36_0
ipywidgets                6.0.0                    py36_0
isort                     4.2.5                    py36_0
itsdangerous              0.24                     py36_0
jbig                      2.1                           0
jdcal                     1.3                      py36_0
jedi                      0.10.2                   py36_2
jinja2                    2.9.6                    py36_0
jpeg                      9b                            0
jsonschema                2.6.0                    py36_0
jupyter                   1.0.0                    py36_3
jupyter_client            5.0.1                    py36_0
jupyter_console           5.1.0                    py36_0
jupyter_core              4.3.0                    py36_0
lazy-object-proxy         1.2.2                    py36_0
libiconv                  1.14                          0
libpng                    1.6.27                        0
libtiff                   4.0.6                         3
libxml2                   2.9.4                         0
libxslt                   1.1.29                        0
llvmlite                  0.18.0                   py36_0
locket                    0.2.0                    py36_1
lxml                      3.7.3                    py36_0
markupsafe                0.23                     py36_2
matplotlib                2.0.2               np112py36_0
mistune                   0.7.4                    py36_0
mkl                       2017.0.1                      0
mkl-service               1.1.2                    py36_3
mne                       0.15.dev0                 <pip>
mpmath                    0.19                     py36_1
msgpack-python            0.4.8                    py36_0
multipledispatch          0.4.9                    py36_0
navigator-updater         0.1.0                    py36_0
nbconvert                 5.1.1                    py36_0
nbformat                  4.3.0                    py36_0
networkx                  1.11                     py36_0
nltk                      3.2.3                    py36_0
nose                      1.3.7                    py36_1
notebook                  5.0.0                    py36_0
numba                     0.33.0              np112py36_0
numexpr                   2.6.2               np112py36_0
numpy                     1.12.1                   py36_0
numpydoc                  0.6.0                    py36_0
odo                       0.5.0                    py36_1
olefile                   0.44                     py36_0
openpyxl                  2.4.7                    py36_0
openssl                   1.0.2l                        0
packaging                 16.8                     py36_0
pandas                    0.20.1              np112py36_0
pandocfilters             1.4.1                    py36_0
partd                     0.3.8                    py36_0
path.py                   10.3.1                   py36_0
pathlib2                  2.2.1                    py36_0
patsy                     0.4.1                    py36_0
pep8                      1.7.0                    py36_0
pexpect                   4.2.1                    py36_0
pickleshare               0.7.4                    py36_0
pillow                    4.1.1                    py36_0
pip                       9.0.1                    py36_1
ply                       3.10                     py36_0
prompt_toolkit            1.0.14                   py36_0
psutil                    5.2.2                    py36_0
ptyprocess                0.5.1                    py36_0
py                        1.4.33                   py36_0
pycosat                   0.6.2                    py36_0
pycparser                 2.17                     py36_0
pycrypto                  2.6.1                    py36_6
pycurl                    7.43.0                   py36_2
pyflakes                  1.5.0                    py36_0
pygments                  2.2.0                    py36_0
pylint                    1.6.4                    py36_1
pyodbc                    4.0.16                   py36_0
pyopenssl                 17.0.0                   py36_0
pyparsing                 2.1.4                    py36_0
pyqt                      5.6.0                    py36_1
pytables                  3.3.0               np112py36_0
pytest                    3.0.7                    py36_0
python                    3.6.1                         2
python-dateutil           2.6.0                    py36_0
python.app                1.2                      py36_4
pytorch                   0.1.12              py361_2cu75    soumith
pytz                      2017.2                   py36_0
pywavelets                0.5.2               np112py36_0
pyyaml                    3.12                     py36_0
pyzmq                     16.0.2                   py36_0
qt                        5.6.2                         2
qtawesome                 0.4.4                    py36_0
qtconsole                 4.3.0                    py36_0
qtpy                      1.2.1                    py36_0
readline                  6.2                           2
requests                  2.14.2                   py36_0
resampy                   0.1.5                     <pip>
rope                      0.9.4                    py36_1
ruamel_yaml               0.11.14                  py36_1
scikit-image              0.13.0              np112py36_0
scikit-learn              0.18.1              np112py36_1
scipy                     0.19.0              np112py36_0
seaborn                   0.7.1                    py36_0
setuptools                27.2.0                   py36_0
simplegeneric             0.8.1                    py36_1
singledispatch            3.4.0.3                  py36_0
sip                       4.18                     py36_0
six                       1.10.0                   py36_0
snowballstemmer           1.2.1                    py36_0
sortedcollections         0.5.3                    py36_0
sortedcontainers          1.5.7                    py36_0
sphinx                    1.5.6                    py36_0
spyder                    3.1.4                    py36_0
sqlalchemy                1.1.9                    py36_0
sqlite                    3.13.0                        0
statsmodels               0.8.0               np112py36_0
sympy                     1.0                      py36_0
tblib                     1.3.2                    py36_0
terminado                 0.6                      py36_0
testpath                  0.3                      py36_0
tk                        8.5.18                        0
toolz                     0.8.2                    py36_0
torchvision               0.1.8                    py36_2    soumith
tornado                   4.5.1                    py36_0
traitlets                 4.3.2                    py36_0
unicodecsv                0.14.1                   py36_0
unixodbc                  2.3.4                         0
wcwidth                   0.1.7                    py36_0
werkzeug                  0.12.2                   py36_0
wheel                     0.29.0                   py36_0
widgetsnbextension        2.0.0                    py36_0
wrapt                     1.10.10                  py36_0
xlrd                      1.0.0                    py36_0
xlsxwriter                0.9.6                    py36_0
xlwings                   0.10.4                   py36_0
xlwt                      1.2.0                    py36_0
xz                        5.2.2                         1
yaml                      0.1.6                         0
zict                      0.1.2                    py36_0
zlib                      1.2.8                         3
(ENVbrainDecode) Haiders-MacBook-Pro:~ sagihaider$

Hi,
from the error message it seems that torch is not installed with CUDA. Do you have a CUDA-capable GPU/graphics card and CUDA(+cudnn?) installed? In this case, you should reinstall pytorch from http://pytorch.org/ for your CUDA version.
Otherwise, you should set
cuda = False

in this line:
https://github.com/robintibor/braindecode/blob/6feb797cce101a3ab17c8a2ea77869f6e2fddb88/examples/bcic_iv_2a.py#L130
However, it will likely be very slow then on CPU.

Please reopen if there is still problems, otherwise I hope the problem is solved.

authors: robintibor sagihaider

repo: robintibor/braindecode


text:
[Feature request] Allow updating speak config dynamically

Scenario
My application gets user config on load to get user's default locale and supported locales. I have a default speakConfig like below
{
     defaultLocale: { lang: 'en-US' },
    supportedLocales: [{ lang: 'en-US' }],
    assets: ['common'],
}

I tried 2 attempts:

Creating a wrapper component around QwikSpeakProvider and pass a reactive store data into my wrapper component.  The reactive store data is set based on API response. However, this way doesn't work.
Manually set value via useSpeakContext. For example speakContext.config.supportedLocales = [{ lang: 'en-US' }, { lang: 'nl-NL' }]. This way doesn't work either

Request
A new feature to allow config to be dynamic configured or if new feature is not possible, maybe some documentation updates?

Hi @ahnpnl,
I blocked with Object.freeze(config) editing speck config dynamically for two reasons:

making it reactive and updatable consumes unnecessary resources, because Qwik creates and serializes subscriptions
in my opinion a configuration must be available before the app is rendered and shouldn't be changed at runtime (also for security reasons... even if it's just a translation library, ok!)

So about you first attempt: if you create a component to update a state in the parent component, then Qwik (yet for the moment) doesn't make the state immediately available, but only within the child components (note the usage of the Speak component in this library).
I think you should use useTask$ with isServer (ex useServerMount$), i.e.:
root.tsx
export default component$(() => {
  const urlEnv = useServerData<string>('url');
  const origin = isServer && urlEnv ? (new URL(urlEnv)).origin : '';

  let config: SpeakConfig = {
    defaultLocale: { lang: '' },
    supportedLocales: [],
    assets: []
  };

  useTask$(async () => {
    if (isServer) {
      const response = await fetch(`${origin}/config.json`);  // just an example
      const result: SpeakConfig = await response.json();
      config.defaultLocale = result.defaultLocale;
      config.supportedLocales = result.supportedLocales;
      config.assets = result.assets
    }
  });

  return (
    /**
     * Init Qwik Speak (only available in child components)
     */
    <QwikSpeakProvider config={config} translationFn={translationFn}>
      ...
    </QwikSpeakProvider>
  );
});

Another way could be to get the config server side (adapter), for example in node, and pass it as an option to the root component (at least in production) and use a local config in dev mode.
However, all this reasoning, I don't think it has to do with the library, but with how Qwik works. I don't think they should be in the doc, also because Qwik is constantly changing on these things and they would never be updated...

Thanks, I think using useTask$ with isServer would work since it will block rendering until the async api call is resolved. My 1st attempt actually tried to optimize by not blocking rendering but do streaming.
Thank you for your response, I think I would have to take the downside about blocking rendering.

I tried to allow config dynamically configurable, just remove this line: https://github.com/robisim74/qwik-speak/blob/434c2ebf9e49751edf8bdb58199518780a9928bb/src/library/qwik-speak-component.tsx#L80,  but I get this error from Qwik:
Error: State mutation inside render function. Move mutation to useWatch(), useBrowserVisibleTask() or useServerMount()
The message is not updated (useWatch() + useServerMount() = useTask$), but in the end Qwik doesn't seem to allow the change once the context is initialized during rendering.
If you have any idea, we could work on it.


text:
Updated Generated Files

@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

Updated Generated Files
@robmoffat

repo: robmoffat/landscape-scanning


text:
readfile is not identing every line

When using  a values list item, readFile + indent is only indenting the first line.
Steps  to Reproduce

helmfile --debug template

repositories:
  - name: linkerd
    url: https://helm.linkerd.io/stable

releases:
  - name: linkerd
    namespace: linkerd
    chart: linkerd/linkerd2
    version: 2.10.2
    values:
      - identityTrustAnchorsPEM: |
        {{ readFile "certs/ca.crt" | indent 2 }}

Actual Results
 9:     values:
10:       - identityTrustAnchorsPEM: |
11:           -----BEGIN CERTIFICATE-----
12:   MIIBxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxJTEj
13:   MCEGxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxjEy
14:   MDUyxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2x1
15:   c3RxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxUEE
16:   jsUxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3cA
17:   Ve3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxB0G
18:   A1UxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxiB8
19:   qPcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxdOv
20:   SECxxxxxxoxxxxxxxxxmufs=
21:   -----END CERTIFICATE-----

Expected  Results
 9:     values:
10:       - identityTrustAnchorsPEM: |
11:           -----BEGIN CERTIFICATE-----
12:           MIIBxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxJTEj
13:           MCEGxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxjEy
14:           MDUyxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2x1
15:           c3RxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxUEE
16:           jsUxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3cA
17:           Ve3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxB0G
18:           A1UxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxiB8
19:           qPcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxdOv
20:           SECxxxxxxoxxxxxxxxxmufs=
21:           -----END CERTIFICATE-----

Workaround
repositories:
  - name: linkerd
    url: https://helm.linkerd.io/stable

releases:
  - name: linkerd
    namespace: linkerd
    chart: linkerd/linkerd2
    version: 2.10.2
    values:
      - identityTrustAnchorsPEM: |
{{ readFile "certs/ca.crt" | indent 10 }}

Hi @darkn3rd ,
Issue #1579 (I use it also) is a conunter-example for request.
Regards

@AssafKatz3 Thanks for your help!
This looks like a go template usage issue, and not a helmfile specific issue. Closing.

repo: roboll/helmfile


text:
Clean up internal code

I want to change some things, but I'm not sure whether it is a good idea, so I want to ask first.
Since (Ios)BuildSettings classes are just wrappers for task results that can now be called inside launchTask method directly, do we still need them? They are hidden from api, so they just add some layer of complexity, which I am not sure is needed.

Can this be closed now that your changes have been merged?

Yeah, this issue is now outdated.

authors: Darkyenus ajhager

repo: roboscala/sbt-robovm


text:
Lower-level keyword name conflicts

Hello,
I have used Robot Framework to create over 30 resource files, each of which has its own lower-lever resource file linked to it.
I needed to use keywords from the higher-level resource files in one bundle, so I created a wrapper resource file (importing the 30 higher level resource files into it). I then created a test suite and imported this one resource into it.
My goal has been to use (in tests) the higher-level keywords only (lower-level just helped me on the implementation side). So, because lower-level keywords are being used by their immediate parent only, I did allow their names to be unique only within that resource file (i.e. in the whole bundle of 30 resource files + their children, the children keywords won't have unique names).
In my test cases: I am using unique paths for my higher level keywords. I am getting conflicts for the lower-level keywords. For example:

Multiple keywords with name 'keyword_name' found. Give the full name of the keyword you want to use:
low_level_resource_file1.keyword_name1
low_level_resource_file1.keyword_name1
low_level_resource_file2.keyword_name1

How can these conflicts be occurring? I am specifying a unique path for the higher-level keyword, from there the lower-level one should be unique.
I am also getting duplicates reported, although no duplicates exist.
How can I resolve this?

Should mention also the version is RIDE 1.5.2.1

First of all, sorry for ignoring this issue for so long. It was buried under a pile of other issues during summer time when I didn't have much time to follow this tracker.
The problem you have faced is very annoying and also known, see #1041. I hope we could fix it one way or other at some point, but cannot unfortunately give any promises when. I close this issue a duplicate of #1041.

This problem could also be resolved by keyword visibility modifiers proposed by #430. That would probably be a simpler than changing import logic as required by #1041 and wouldn't cause backwards compatibility problems either.

authors: KseniaStar pekkaklarck

repo: robotframework/robotframework


text:
About Robot Framework Security.

Hello. I'm a new one here.
I have a question about framework security. Can I allow test from specific IP to prevent test bot from other IP.
Best Regard.

No you cannot. Please send questions to robotframework-users mailing list in the future.

authors: Neroroms pekkaklarck


text:
(FLK-E302) Expected 2 blank lines

Description
Two blank lines are expected between functions and classes.
Occurrences
There are 34 occurrences of this issue in the repository.
See all occurrences on DeepSource → deepsource.io/gh/robotichead/NearBeach/issue/FLK-E302/occurrences/

Hey @robotichead, due to some other work I am not able to work on this issue. Can you reassign it to someone else?

@robotichead i'm willing to work on this.

My PR #329 fixes this issue.
@robotichead can you please merge the above mentioned PR?

repo: robotichead/NearBeach


text:
ergoCubSN001 - neck files updated

This PR updates XML files for the neck following tests on the setup
⚠ This mod applies only to the pitch and roll of the neck, other joints of the head have to be calibrated as soon as available
cc @pattacini @sgiraz

CI still fails:
WARNING] ServiceParser::convert(): P3P is not a legal string for eObrd_connector_t
[WARNING] ServiceParser::parse_port_conn(): CONN:P3P is not a legal string for a eObrd_connector_t
[WARNING] ServiceParser::parse_actuator_port(): CONN:P3P is not a legal string for a pwm connector port
[ERROR] ServiceParser::check_motion() PROPERTIES.JOINTMAPPING.actuator.port not valid for item 0
[ERROR] ServiceParser::parseService() gets same errors parsing SERVICE MC group
[ERROR] embObjMC  BOARD head-eb20-j0_1 (IP 10.0.1.20)  cannot parse service
[ERROR] BOARD head-eb20-j0_1 (IP 10.0.1.20)  Missing motion control parameters in config file
[ERROR] |yarp.dev.PolyDriver|head-eb20-j0_1-mc| Driver <embObjMotionControl> was found but could not open

This is due to the fact that we haven't integrated yet the new FW.
Thus, I'll keep this PR in draft and come back to it once the FW is updated.

Thus, I'll keep this PR in draft and come back to it once the FW/parser is updated.

Awaiting the following PR to be merged before putting this in ready for review:

https://github.com/robotology/icub-firmware-shared/pull/87

Required upstream PR merged ✅
I'm rebuilding the docker image used by the CI via https://github.com/robotology/robots-configuration/actions/runs/6198027673.
Once done, I'll put this PR in ready-for-review.

authors: davidetome pattacini

repo: robotology/robots-configuration


text:
Top level docs for Roc code structure

I have been reading various modules to learn how Roc works. I was wondering what the best way is to communicate this information for new people. I'm making an assumption that this hasn't already been discussed etc, but thought I would put an idea in for consideration.
I created a Workspace.md file in design, as a place to capture high level details. Intent is to capture the bulk of information in cargo doc comments as I go, however I felt that something that ties it together would be good. I'm guessing this content would eventually live on the website or mature into another form, but for now I thought this might help people navigate the internals easier.
Please let me know if this is useful and if I should continue? It is generating a lot more questions for me about how things work... but I guess putting something down would also answer the question for others. I was also thinking this could be a good place to link to the design discussions that already exist nested within the folders.
One concern I have is that if the design of Roc is still very much in flux, then something like this may just be too much to maintain.

This is a good initiative :)
I'm thinking of the often-given advice that documentation should be kept close to the code to prevent it from getting out of sync.
So in this PR I would recommend sticking to adding documentation to the top of lib.rs and bin.rs files in crates.
Next, to get this overview file we could perhaps extract those top doc comments from lib.rs and bin.rs files and combine them into a README.md to put in the crates folder?

Thank you Anton. I will work towards that. I guess what I was thinking here was also motivated by the interfaces and relationship between different crates. I was hoping to map that out a bit, so it is easier to digest and understand where functionality lives/should live etc.

repo: roc-lang/roc


text:
Update nfl constants.py

Fix the fumbles_recovered_for_touchdown stat.
Closes Issue #543

Closing as this is now resolved.

authors: mdekarske roclark

repo: roclark/sportsipy


text:
AHP dringend machen

Da sind alle notwendigen Infos. Bis 2.12.2018 wir sollen fertig sein.

erledigt

repo: rodchenk/foliage