Add top-level client constructor

Since gorackhd is vendoring go-swagger (which pulls in go-openapi),
conflicts arise if gorackhd clients are forced to import go-openapi as
well. Fix that by creating a top-level constructure, which will
automatically use the vendored versions of the go-openapi library.

@kacole2 this is my solution to avoiding the conflicting imports that arise since this library is vendoring other libraries.  If you're okay with it, I'll need to do the same for gorackhd-redfish.

receiving this error during make:
2016/04/25 16:15:36 rendered operation group client template: workflow.WorkflowClient
2016/04/25 16:15:37 rendered client facade template: client.MonorailClient
go install -v $(/Users/kcoleman/go/bin/glide nv)
gorackhd.go:11:2: cannot find package "github.com/go-openapi/runtime/client" in any of:
	/Users/kcoleman/go/src/github.com/emccode/gorackhd/vendor/github.com/go-openapi/runtime/client (vendor tree)
	/usr/local/Cellar/go/1.6.1/libexec/src/github.com/go-openapi/runtime/client (from $GOROOT)
	/Users/kcoleman/go/src/github.com/go-openapi/runtime/client (from $GOPATH)
gorackhd.go:12:2: cannot find package "github.com/go-openapi/strfmt" in any of:
	/Users/kcoleman/go/src/github.com/emccode/gorackhd/vendor/github.com/go-openapi/strfmt (vendor tree)
	/usr/local/Cellar/go/1.6.1/libexec/src/github.com/go-openapi/strfmt (from $GOROOT)
	/Users/kcoleman/go/src/github.com/go-openapi/strfmt (from $GOPATH)
make: *** [install] Error 1

Well that's weird.  I've done it a bunch of times and it works fine on my end -- just tried again with a make clean && make and all good.
What's really strange is that the package it says it can't find is then listed twice in the output, i.e. it should find it just fine at /Users/kcoleman/go/src/github.com/emccode/gorackhd/vendor/github.com/go-openapi/strfmt (vendor tree).
We are both using Go 1.6.1 too...
It also passed the CI build.  https://travis-ci.org/emccode/gorackhd/builds/125121652#L526

@kacole2 can we revisit this?  I just tried in a brand new Go environment, and still was successful.  Here is what I did:
$ cd /tmp
$ mkdir test
$ cd test
$ export GOPATH=`pwd`
$ go get github.com/emccode/gorackhd
$ cd src/github.com/emccode/gorackhd/
$ git checkout origin/constructor
$ make

still getting errors on my end. I will investigate it further.
First error:
# github.com/emccode/gorackhd
./gorackhd.go:16: cannot use "github.com/emccode/gorackhd/vendor/github.com/go-openapi/runtime/client".New(host, basePath, schemes) (type *"github.com/emccode/gorackhd/vendor/github.com/go-openapi/runtime/client".Runtime) as type "github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger/client".Transport in argument to "github.com/emccode/gorackhd/client".New:
	*"github.com/emccode/gorackhd/vendor/github.com/go-openapi/runtime/client".Runtime does not implement "github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger/client".Transport (wrong type for Submit method)
		have Submit(*runtime.ClientOperation) (interface {}, error)
		want Submit(*"github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger/client".Operation) (interface {}, error)
./gorackhd.go:16: cannot use "github.com/emccode/gorackhd/vendor/github.com/go-openapi/strfmt".Default (type "github.com/emccode/gorackhd/vendor/github.com/go-openapi/strfmt".Registry) as type "github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger/strfmt".Registry in argument to "github.com/emccode/gorackhd/client".New:
	"github.com/emccode/gorackhd/vendor/github.com/go-openapi/strfmt".Registry does not implement "github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger/strfmt".Registry (wrong type for Add method)
		have Add(string, "github.com/emccode/gorackhd/vendor/github.com/go-openapi/strfmt".Format, "github.com/emccode/gorackhd/vendor/github.com/go-openapi/strfmt".Validator) bool
		want Add(string, "github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger/strfmt".Format, "github.com/emccode/gorackhd/vendor/github.com/go-swagger/go-swagger/strfmt".Validator) bool
make: *** [install] Error 2

then i did rm -rf $GOPATH/src/github.com/go-swagger
Here's the 2nd error i'm getting:
2016/05/10 16:19:34 rendered client responses template: workflow.PutWorkflowsTasksResponses
2016/05/10 16:19:34 rendered operation group client template: workflow.WorkflowClient
2016/05/10 16:19:34 rendered client facade template: client.MonorailClient
go install -v $(/Users/kcoleman/go/bin/glide nv)
models/catalog.go:9:2: cannot find package "github.com/go-openapi/errors" in any of:
	/Users/kcoleman/go/src/github.com/emccode/gorackhd/vendor/github.com/go-openapi/errors (vendor tree)
	/usr/local/Cellar/go/1.6.1/libexec/src/github.com/go-openapi/errors (from $GOROOT)
	/Users/kcoleman/go/src/github.com/go-openapi/errors (from $GOPATH)
client/catalog/catalog_client.go:7:2: cannot find package "github.com/go-openapi/runtime" in any of:
	/Users/kcoleman/go/src/github.com/emccode/gorackhd/vendor/github.com/go-openapi/runtime (vendor tree)
	/usr/local/Cellar/go/1.6.1/libexec/src/github.com/go-openapi/runtime (from $GOROOT)
	/Users/kcoleman/go/src/github.com/go-openapi/runtime (from $GOPATH)
client/monorail_client.go:8:2: cannot find package "github.com/go-openapi/runtime/client" in any of:
	/Users/kcoleman/go/src/github.com/emccode/gorackhd/vendor/github.com/go-openapi/runtime/client (vendor tree)
	/usr/local/Cellar/go/1.6.1/libexec/src/github.com/go-openapi/runtime/client (from $GOROOT)
	/Users/kcoleman/go/src/github.com/go-openapi/runtime/client (from $GOPATH)
models/catalog.go:7:2: cannot find package "github.com/go-openapi/strfmt" in any of:
	/Users/kcoleman/go/src/github.com/emccode/gorackhd/vendor/github.com/go-openapi/strfmt (vendor tree)
	/usr/local/Cellar/go/1.6.1/libexec/src/github.com/go-openapi/strfmt (from $GOROOT)
	/Users/kcoleman/go/src/github.com/go-openapi/strfmt (from $GOPATH)
models/catalog.go:10:2: cannot find package "github.com/go-openapi/validate" in any of:
	/Users/kcoleman/go/src/github.com/emccode/gorackhd/vendor/github.com/go-openapi/validate (vendor tree)
	/usr/local/Cellar/go/1.6.1/libexec/src/github.com/go-openapi/validate (from $GOROOT)
	/Users/kcoleman/go/src/github.com/go-openapi/validate (from $GOPATH)
make: *** [install] Error 1

after doing
$ go get github.com/go-openapi/errors
$ go get github.com/go-openapi/runtime
$ go get github.com/go-openapi/strfmt
$ go get github.com/go-openapi/validate

It worked. Perhaps we should add those as dependencies in the main go file?

Hmm, maybe.
It still really bothers me that it works on my end and on Travis-CI.
The only other thing I could think of would be a difference in behavior for Glide, and that maybe we were using different versions.  But looking at the Makefile, it always does a go get -u on Glide, so it should always be running the latest.
$ glide -v
glide version 0.11.0-dev

The 1st error you ran into is actually what I see when using gorackhd. If you have any of the libraries that gorackhd vendors also downloaded into the non-vendored $GOPATH/src, then you end up with these conflicts. It's definitely a problem.
The point of the constructor here was to be able to create the client through gorackhd directly, and thus not have to copy/duplicate the dependencies in any code that is using gorackhd.

Make sure you are using packages from the $GOPATH/src!  Vendoring does not work properly if you aren't using Go's best practices for writing code.

@clintonskitson just gave me some tips on how I might be able to fix all this (and negate the need for this PR, I would think) by configuring glide.yaml in my project in a better way. I am not currently forcing it to have a single vendor dir -- right now I would end up with gorackhd/vendor and a separate rackhdcli/vendor, and I can/should squash those together.  Will report back!

@codenrhoden The gorackhd project should have checked in code that includes the generated code from swagger at a point in time. It should not include the vendor directory. Your repo should hold the only vendor directory that is generated by glide doing a recursive lookup.

@clintonskitson The gorackhd project does not currently check in any of the generated code. You are required to generated it. When you look at the repo, there is no vendor directory, but one will always be created when you run make.
@kacole2 are you opposed to having the generated client code checked in?

The generated code should definitely be checked in! Otherwise tools that want to use it have to deal with more complication than necessary.

@clintonskitson @kacole2 Opened #12 to add generated code from the current swagger spec.

@codenrhoden @clintonskitson it was per @akutz that generated code was not checked in. That's why generated folders are part of .gitignore. I have no qualms about having code checked in.

@kacole2 good to know. Okay, well I'd like to figure out how to move forward. Let's see if @akutz wants to chime in. I just want to come to a resolution on this, as everything I'm doing downstream of gorackhd changes based on how this part is structured.

do we still need to merge this? or have we found another way?

I think we have found another way. :) If I'm wrong, I'll re-open.


Flow Always Gets Created in 'Default Solution'

Is it possible to indicate a solution other than 'Default Solution' when creating a flow via the Power Management API's?  Or is it possible to update an existing flow to 'move' it to another solution?  I've tried using the 'solutionid' parameter to do both, but neither worked.

Hi @TracyGH . I'm not sure. Unfortunately, this isn't the best place for questions like this. This is where you can submit issues related to documentation. The best place for you to submit a question like this is on the Power Automate community forums: https://powerusers.microsoft.com/t5/Microsoft-Power-Automate/ct-p/MPACommunity. I hope this helps!

Hi @Dean-Haas,
Thank you for the prompt response.  I'm familiar with that community, but I don't think that's the appropriate place for this question either.  Those are typically 'power users' who ask questions pertaining to the Power Platform tool set (Power Automate, Power Apps Studio, etc.).  I'm asking a question about the Power Management APIs themselves, which is a different technology than the tools.
This piece of documentation is showing an example pertaining to my question.  In the past, I've seen users post technical questions regarding specific examples associated with the documentation it was in.  I can point out several examples.
I guess I will post something in StackOverflow, because I'm not really sure where else this belongs...?


Unordered Indexed Load

The brief discussion of memory ordering this morning leads me to think that we need indexed loads that are unordered just like we have indexed stores that are unordered.  It doesn't matter for a single hart, but memory ordering means it matters for multiple harts.  Otherwise, unless the memory being accessed is private to a single hart, the indexed loads can't be done out of order.

I think unordered indexed/strided loads are a good way to relax memory consistency model further for high performance implementations.
@daniellustig

Depending upon the application of the RVWMO model, whether elements n
and n+1 are considered independent when they have no syntactic data,
address or control dependency between them, from the perspective of
other harts, the loads can be reordered and hence, can be reordered
explicitly in the executing hart as long as the locally perceived
program order (defined by the syntactic dependencies) is maintained.
I have been trying to get a worthwhile first thoughts on this to
present. Also, considering the possibility of further relaxing the model
for vector to vector operations from syntactic to allow certain classes
of "dynamic actual" control and data( and possibly address) dependencies.
I believe it will be better to constrain initial implementations, extend
the memory model for RVVWMO and only if later needed, claw it back and
introduce explicit relaxation.
This allows for relaxing the actual implementations and meeting in the
middle with a solid physical implementation and an implementable,
efficient, effective and verifiable memory model.
On 2020-06-26 1:40 p.m., billhuffman wrote:

The brief discussion of memory ordering this morning leads me to think
that we need indexed loads that are unordered just like we have
indexed stores that are unordered. It doesn't matter for a single
hart, but memory ordering means it matters for multiple harts.
Otherwise, unless the memory being accessed is private to a single
hart, the indexed loads can't be done out of order.

On 2020-06-30 11:51 a.m., Alex Solomatnikov wrote:

I think unordered indexed/strided loads are a good way to relax memory
consistency model further for high performance implementations.

It seems like the rule that vector memory ordering is the same as a scalar loop would be, plus Rule #2 in the memory ordering section (Coherence for Read-Read pairs) requires indexed loads to order accesses to the same address in element order.

On 2020-07-09 7:50 p.m., billhuffman wrote:

It seems like the rule that vector memory ordering is the same as a
scalar loop would be, plus Rule #2
https://github.com/riscv/riscv-v-spec/issues/2 in the memory
ordering section (Coherence for Read-Read pairs) requires indexed
loads to order accesses to the same address in element order.

That would be
• Overlapping-Address Orderings:

b is a store, and a and b access overlapping memory addresses
2. a and b are loads, x is a byte read by both a and b, there is no
store to x between a*
and b in program order, and a and b return values for x written by
different memory
*operations

So, yes if the addresses overlap. But no if they do not.
In  that  the usual case involves only the index values that are
multiples of the eew,
a) the addresses will not overlap and we can read them in ascending
order (or any other that is performant),
or b) those that are the same we can read immediately after one another
(which in effect means in either order as an additional  physical read
will not occur in the tRVWMO domain of "regular main memory".
For indexes that are not multiples of eew the fall back to in order will
not be wrong, but even there some of the reads can likely be optimized
that don't overlap.
Depending upon how concurrence is defined in vector ops (what it really
means to loop over the elements in order), they may be further
relaxation of "global memory order".
Note as an equivalence, effectively vector operations (and load in
particular) are unrolled scalar loops with a massive number of available
registers.
(in general less constrained than renamed scalar registers in a
massively ooo implementation).
What especially complicates load and concurrence is restart and the
definition of vrestart as a transparent index for resumption (vs an
opaque parameterized directive to resume).

You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-v-spec/issues/501#issuecomment-656405001,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAWIKPYR56BDK736566ODTR2ZJUHANCNFSM4OJQ7QTQ.

Since the index vector contains byte offsets, any sort of overlap is possible.  I expect the most common overlap will be identical loads.  It is those identical loads or other overlaps that I think are the whole subject of discussion.

On 2020-07-09 9:59 p.m., billhuffman wrote:

Since the index vector contains byte offsets, any sort of overlap is
possible. I expect the most common overlap will be identical loads. It
is those identical loads or other overlaps that I think are the whole
subject of discussion.

Agreed it is possible.
It can be avoided by scaling index offset by EEW.
Perhaps this should be seriously considered as it also
 helps avoid misaligned addresses and
 helps avoid the shift of the index by log2(EEW) which I have
frequently seen in code.
Programmers most conveniently work with indexes to elements rather than
offsets in memory. .
Strided loads can be easily checked to see that abs(rs2) >= EEW before
optimizing.
However, even for indexed a check that log2(EEW) low order bits are
clear in each index element may not be overly onerous for an instruction
that, when optimized for the typical case, can provide substantial
performance benefit.
A pessimistic implementation that processes from 0 to vl can still
optimize by passes through that load from present cache entries, locally
assessing address overlap.
In other words, the benefits from and mechanisms used to out-of-order
process loads can be seen and applied by RVVWMO ordering VLXEI and not
require VLUXEI.
Further, what does unordered loads really mean from a concurrency
management stance?
 What guarantees does it still give, or actually relax/remove/ignor?
In the most extreme case it could mean that reads are allowed from
before or after a full fence.
Is that what is envisioned? Is that what could be implemented under the
current loose definition?
Will we have to provide new fence formulations to provide a
vector to scalar to vector  fence?
Will it be so heavy handed that the unordered loads will be effectively
unusable?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-v-spec/issues/501#issuecomment-656438224,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAWIKKMKIINTSEQN4HLHQTR2ZYWZANCNFSM4OJQ7QTQ.

We should not change the definition of the instructions to scale by EEW,
because one use case is for the index vector to be a vector of pointers,
with a scalar base address of x0 (or a small offset).
On Thu, Jul 9, 2020 at 9:35 PM David-Horner<EMAIL_ADDRESS>wrote:

On 2020-07-09 9:59 p.m., billhuffman wrote:

Since the index vector contains byte offsets, any sort of overlap is
possible. I expect the most common overlap will be identical loads. It
is those identical loads or other overlaps that I think are the whole
subject of discussion.

Agreed it is possible.
It can be avoided by scaling index offset by EEW.
Perhaps this should be seriously considered as it also
helps avoid misaligned addresses and
helps avoid the shift of the index by log2(EEW) which I have
frequently seen in code.
Programmers most conveniently work with indexes to elements rather than
offsets in memory. .
Strided loads can be easily checked to see that abs(rs2) >= EEW before
optimizing.
However, even for indexed a check that log2(EEW) low order bits are
clear in each index element may not be overly onerous for an instruction
that, when optimized for the typical case, can provide substantial
performance benefit.
A pessimistic implementation that processes from 0 to vl can still
optimize by passes through that load from present cache entries, locally
assessing address overlap.
In other words, the benefits from and mechanisms used to out-of-order
process loads can be seen and applied by RVVWMO ordering VLXEI and not
require VLUXEI.
Further, what does unordered loads really mean from a concurrency
management stance?
What guarantees does it still give, or actually relax/remove/ignor?
In the most extreme case it could mean that reads are allowed from
before or after a full fence.
Is that what is envisioned? Is that what could be implemented under the
current loose definition?
Will we have to provide new fence formulations to provide a
vector to scalar to vector  fence?
Will it be so heavy handed that the unordered loads will be effectively
unusable?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-v-spec/issues/501#issuecomment-656438224,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AFAWIKKMKIINTSEQN4HLHQTR2ZYWZANCNFSM4OJQ7QTQ
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-v-spec/issues/501#issuecomment-656477152,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH3XQXG6GKHESRI45NMAXTR22LBZANCNFSM4OJQ7QTQ
.

I agree with Andrew indexes need to be bytes.  And it would not solve the problem if they were scaled.  Overlap would still be there as identical indexes.  And if hardware finds identical indexes (or different but overlapping) in order for indexed loads, it might as well do so for indexed stores, which are less common in my experience.
This issue is considering whether the unordered concept to indexed stores.  There is another about unordered and exceptions and a third about yet looser ordering for indexed loads and stores.

On 2020-07-10 3:19 a.m., billhuffman wrote:

I agree with Andrew indexes need to be bytes.

I agree with Andrew that pointer based indexes are an important use case
and thus not to be eliminated.
The question I intended to pose is whether VLXEI is the correct
vehicle for that.
If indexes should rather be array indexes rather than memory offsets for
this instruction (and related store) and a different formulation
specifically deal with XLEN pointer addressing.

And it would not solve the problem if they were scaled. Overlap would
still be there as identical indexes.

Identical indexes is not a problem in the RVWMO model. There is no
intervening write from another hart to the identical index loads as they
are allowed to occur concurrently in RVWMO absent data, address and
control dependencies. Control and address dependencies can be and in
most cases need to be resolved before loads can occur. There are no data
dependencies per se as the operation is a load.

And if hardware finds identical indexes (or different but overlapping)
in order for indexed loads,

I don't follow the connection to stores

it might as well do so for indexed stores,

I have an issue open about clarifying index store behaviour and
explicitly naming the ordered store as Ordered.

which are less common in my experience.

This issue is considering whether the unordered concept to indexed
stores.

As we have discovered, the unordered load and  RVWMO are intimately
linked. A request for an Unordered load variant has to consider the two
issues you mention.

There is another about unordered and exceptions and a third about yet
looser ordering for indexed loads and stores.

What is the issue number for "unordered and exceptions" ?
The issue #504 raises the "yet looser ordering for indexed loads and
stores", now hopefully github linked to this issue.
#504 appears to suggest the heavy weight fence to allow weaker than
RVWMO memory access explicitly for indexed load/stores.
I agree that we should express RVV concurrency in a relaxed manner to
allow for a RVV specific RVVWMO definition that allows for the
parallelism requested there.
However, even within the current RVWMO model and a process model that
stipulates "as if processed consecutively from 0 to vl" there is
sufficient latitude to provide significant parallelism and respect the
currently provided fencing instructions.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-v-spec/issues/501#issuecomment-656525630,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAWIKLL4V6XQ47TOZLUH53R226HVANCNFSM4OJQ7QTQ.

I believe that identical indexes has exactly the same memory ordering issue that overlapping but not identical has.  A store to that location is very unlikely, but the fact that it can occur requires implementation constraints on how the overlapping or identical accesses happen.
Unordered and exceptions is issue #502.  Sorry I didn't include the issue numbers.

I'm not fully up to date with the status of the vector spec, so please forgive me if I'm missing any context, but since @solomatnikov cc'ed me in I'll add my two cents (for #501 #502 #504):
I think the natural thing to do from the memory model POV would be to stick with what the vector spec draft already suggests, or to mimic what the RVWMO spec says for misaligned loads or stores being decomposed into multiple memory operations, e.g.:
"A vector load or store instruction is decomposed into a set of component memory operations.  These memory operations are ordered normally with respect to the memory operations generated by preceding and subsequent instructions in program order.  Unless the instruction is indexed-unordered, the program order on those memory operations also respects element order.  For indexed-unordered instructions, the memory operations are not ordered with respect to each other in program order.  The memory operations then follow the standard RVWMO rules."
If that's acceptable from an implementation perspective, then that small snippet should fully cover the memory model implications.  However, if you want to relax vector-to-scalar ordering like #504 proposes, for example, then you'll need to build a lot more new memory model machinery.
Allowing repeated writes as proposed in #502 seems like a bad idea to me from a theory perspective.

"A vector load or store instruction is decomposed into a set of component memory operations.

If that's acceptable from an implementation perspective,

What RVWMO does not state is the order in which the components are to be process.
The implication is that the order is indeterminate and any physical order is allowed.

Some RVV instructions require elements to be processed in order from 0 (or vstart if not zero) to vl (vector length).

Indeed, for instruction restart, vstart is explicitly premised on this assumption.

3 .b) Notably, POR synchronous traps definition anticipates element set processing that is not strictly processed from 0 to vl.
I hope to, instead of the "exception definition" of synchronous used  RVV, expand the concurrency process model which naturally allows the current trap allowance as synchronous with respect to it. I have proposed that this extend process model "fuses" consecutive RVV instructions further relaxing visible process architectural state. #364

As with RVWMO's extensive analysis of RVI instruction dependencies, RVV instructions will also need to be profiled to ensure correct data, address and control dependencies are observed. Changes to vmul and vsew rearrange register dependencies. The related case of mixed width, narrowing and widening operations, introduce further complications to this mapping. Fortunately we have abandoned visible SLEN affects with an in-register matching in-memory approach, so things are much better than they would have been.

4.b) Most RVV instructions operate on elements in vertical sets (where their "indexes" and widths are equal.).
This is a substantial change from RVWMO in which all registers are considered collectively for their dependency impacts.
Instead, RVV can consider that not only memory operations that do not overlap, but also , elements sets that do not overlap can generate dependency rules that even though syntactically defined allow greater relaxation than expressed in RVWMO.

Whereas the syntactic dependency tracing was sufficient for RVI, I believe RVV could benefit from "actual" execution dependency results. e.g. interaction of operation under mask with operation under complementary mask.

I believe each of these is distinct. e.g. vstart need not be premised on process order from 0 to vl.
These are the components that I believe need to be addressed in a RVVWMO "extension" to RVWMO., issues that are unique or at least dominant in RVV.
However, it is only item 5 that I believe may need extensive new mechanisms in place to fully support, whereas, a subset (e.g. the example I mentioned) may be easily accommodated. In other words , incremental application may be possible.
The rest are, to my way of thinking, refinements of existing infrastructure. Leveraging RVWMO model, with judiciously defined process constraints, rather than adopting a radically different RVVWMO approach, is my goal.

From what I can see, I agree with @daniellustig that the natural thing to do is to stick with the ordering already described.  I believe that all stride-1 and stride-N vector loads and stores actually have no RVWMO ordering requirements among the various elements themselves.  Indexed loads and stores, however, can have identical/overlapping accesses. Therefore, RVWMO rule #1 will apply to vector indexed stores and rule #2 will apply to vector indexed loads.  I believe that the remaining RVWMO rules do not apply to indexed loads and stores either.
We saw very early that vector indexed stores had an issue even for a single hart that meant having an unordered version was valuable.  At the single hart level, unordered indexed loads provide no value.  But when we consider memory ordering, I think we find that unordered versions have just as much value for vector indexed loads as they do for stores.  Thus issue #501.
As for @daniellustig's comment on #502, allowing repeated writes looks pretty ugly to me as well.  But the alternative seems to me to require translation and protection checks to occur in order for vector indexed loads and stores.  Probably further discussion should be under that issue.
The reason for issue #504 is, again, the difficulty of peering ahead for vector indexed operations.  Requiring other operations to be ordered with them is very restrictive and essentially forbids overlap with succeeding vector or scalar memory operations.  If there's not a standard way of allowing unordered indexed loads and stores to be out of order wrt succeeding instructions, there will certainly be a non-standard one.  Again, further discussion probably should be under that issue.

https://github.com/riscv/riscv-v-spec/issues/501#issuecomment-656438224

A store to that location is very unlikely, but the fact that it can occur

I was not sufficiently specific on what environment I considered for my assertion that identical memory overlap means the reads need not be ordered.
RVWMO nicely sidesteps the hardware issue by stipulating order by memory events; even when the memory model is intended to address the “standard” memory hierarchy and specifically allows features of this model (notably a write buffer) it still obscures the hardware nature of “regular main memory operations” on which it depends and to which it explicitly states is limited.
I was assuming a power of 2 cache line greater than or equal to the element size, cache coherent, non-distributed, single-copy atomic physical memory.
This specification  , with a write buffer, is the current “standard” memory configuration.
I did a little cheat because RVWMO does not guarantee atomicity to unaligned elements and expresses uncertainty about mixed width simultaneous operations (specifically with writes).
It is the fringe cases of elements spanning cache lines that are problematic, but even then the problem for read is one of cache thrashing while attempting to acquire the lock on all required adjacent pages.
So, the requirement that “log2(EEW) low order bits are clear” provides a sufficient condition (although not a necessary one) to allow reordering of all such reads.
Although it is instructive to consider the overlapping cases, it is sufficient to apply RVWMO rules to  non-overlapping loads to demonstrate no intervening write can occur with this physical configuration.
First consider a set of element loads with only one non-overlapping memory reference each,
RVWMO allows these reads to be in any global memory order, and as there is no dependence (address, data or control) between load elements in a single RVV load instruction the local hart physical read order (for “main memory” without I/O related cache rules, e.g. serializing byte order on half/word/double address ports) is allowed to vary from the “as if processed from 0 to v” rule.
Consider then adding into a RVV load an additional element read from one of the previous locations. (judicious masking of a RVV load can create the first state and unmasking one of the duplicates create this extant case).
As before, all the “independent memory reads, including the first of the duplicate reads can be reorganized so that the duplicate read is at the end of that set and thus the new duplicate read will immediately follow. As the cache system will have  a read lock on the cache line, and now that two consecutive read to the same location would otherwise be presented to the cache subsystem, there need be no intervening write to the memory location as a single read from cache can suffice for both load requests.
QED?
As the non-overlapping load is a very common use case, I don’t see a need for an unordered load variant.
(I will describe what I consider necessary criteria for  non-overlap and the difficulty of overlapping memory reads later and perhaps elsewhere, not wanting to hijack this thread).

@David-Horner: I think you're suggesting a fully associative cache that holds all values read by an indexed load but not yet fully in order.
I think it probably solves the memory ordering issue within the instruction but requires a lot of gates that are fundamentally unnecessary as the order of those loads will "never" really matter.  I expect actual high-performance implementations simply to violate the spec instead.  For the same reasons we have an unordered indexed store, it would be valuable to have an unordered indexed load with looser rules.
If we don't have an unordered indexed load, we are saying that memory ordering is a second class requirement - that we're willing to add an instruction for the final value issue (in indexed store) but not for memory ordering (in indexed load).
The fully associative cache also doesn't solve the additional difficulties discussed in Issue #504.  I expect implementations there simply to violate the spec.
These expected violations of the spec may be done under a mode bit.  But it would be far better to have ordered and unordered versions with loose enough order requirements on the unordered to work for high-performance implementations.

No. I'm not suggesting a fully associative cache, nor one that holds all required values for the load.
The cache configuration I specified is sufficient and n-way associative is acceptable.
For the aligned non-overlapping of my "cheat", the cache does not have to simultaneously accommodate all element memory locations, indeed only one cache line of the memory working set needs to be resident at a time.
Although I did not present a justification for this, for the not aligned but none overlapping duplicates allowed case, only the two adjacent cache lines of a split element need to be simultaneously present in the cache.
Nor am I suggesting in this thread that we relax the "process from 0 to vl" requirement. (I make that suggestion elsewhere.)
Rather I am saying:
Even when the processing is from 0 to vl, the RVWMO memory model allows the resultant values read to be different than what may appear as the global memory order as seen by other harts.
As a result, in practice an implementation can, for non-overlapping accesses with duplicates avoid a second read for the duplicates and allow the cache subsystem to provide "stale" data.
Multiple concurrent requests can be submitted to the cache subsystem.
However, ordering the index values to provide ordered addresses ( thus allowing a simple cache system to optimize multiple requests to a given cache latch), essentially out of 0 to vl order is perfectly legal and not a relaxation of the 0 to vl processing order per se.

I don't understand how one cache line is sufficient.  Suppose an implementation accesses 128 elements in any order before going on to further elements.  Suppose that the last one looked at is element 7.  The other 127 elements are different from each other but element 7 happens to match one of the later elements.  There are 120 later elements that it could match.  Element 7 could match any one of them, and whichever one it matches, I need to have kept that value so that element 7 does not get a newer value than an identical, higher numbered element.  It also seems to mean 128^2/2 comparitors to find matching elements.  And that's before accounting for overlapping elements, which would need to be detected as well, even if they were handled by starting over in order.

On 2020-07-15 4:01 p.m., billhuffman wrote:

I don't understand how one cache line is sufficient.

to be resident at a time....

Suppose an implementation accesses 128 elements in any order before
going on to further elements.
Suppose that the last one looked at is element 7.

of the initial 128.

The other 127 elements are different from each other but element 7
happens to match one of the later elements.

(OK. only one duplicate in the first 128)

There are 120 later elements that it could match. Element 7 could
match any one of them, and whichever one it matches, I need to have
kept that value so that element 7 does not get a newer value than an
identical, higher numbered element.

That is not a requirement. RVWMO allows the simplification of providing
the later element load request to be filled by the previous load, but it
does not require the two values to be the same. Some may want the RVV
model to ensure matching values for matching addresses, but as currently
formulated we do not guarantee that outcome.
For example a load of stride zero to a strongly ordered non-idempotent
I/O location (potentially with other read side-effects) may be required
to return differing values each read and must also be read the vl times.
Back to the "main memory" case.
As RVV allows load and store operations to be interrupted and restarted
there can be no reasonable expectation of matching values for matching
addresses. (consider that a task context switch has occurred).
Performance aside, I hope it is clear that a single resident cache line
is sufficient for the non-overlap duplicate case..
So, to be clear, that "consistency" is not what I am advocating.
Rather that we execute the RVV load as (if) a set of vl scalar loads
presented to the ooo superscalar's instruction decoder in 0 to vl order
and apply the RVWO rules.
The overhead in RVV for non-overlapping memory locations is much less
than it would require for this hypothetical superscalar ooo and still
provide comparable performance (with a comparable cache subsystem) if
the hart were to first check in-cache lines and order its requests.

It also seems to mean 128^2/2 comparitors to find matching elements.
And that's before accounting for overlapping elements, which would
need to be detected as well, even if they were handled by starting
over in order.

Agreed, overlapping elements are more challenging. I'm working on that.
Given that the typical use case will be no or identical overlap, there
is a clear win for RVV loads with RVWMO.
Even with some non-identical overlap we could see substantial benefits
to accommodate subsets of those cases as well.
Even the pathological case has no need for comparitors; in order
processing suffices.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-v-spec/issues/501#issuecomment-658978588,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAWIKNXYHMBHAT7C7SUFG3R3YDLHANCNFSM4OJQ7QTQ.

I wasn't asking for the same values.  That was just to keep from doing the accesses in the wrong order and getting a newer value in the smaller index access and an older value in the larger index access.
I don't seem to understand what you're suggesting at all.  Could you explain what happens when there's a low index that matches a high index but they get accessed in the reverse order?  And the hardware doesn't know what will match until late in the game?

I wasn't asking for the same values. That was just to keep from doing the accesses in the wrong order and getting a newer value in the smaller index access and an older value in the larger index access.
I don't seem to understand what you're suggesting at all.

Could you explain what happens when there's a low index that matches a high index but they get accessed in the reverse order?

Certainly.
I will assume aligned and same size access to simplify the narrative.
Up to now I have described what RVWMO allows and therefore what legal relaxations are possible.
This question moves to the realm of what happens when an implementation potentially violates RVWMO rules by a certain behaviour.
As a result, "what happens" needs further explanation than either
1) a simplistic detailing of the behaviour of differing cache subsystems or

2) a reduction to a statement of correctness.

What happens is dependent upon details not present in the question.
Especially important is the reason for the reads being accessed in the reverse order.
A) If the cache subsystem consolidates concurrent identical reads, then the right thing happens even if the subsystem does its reads in reverse order. Both (all) elements can be updated with the identical results provided by the cache.
Note: the read scheduling process can instead consolidate pending identical address reads thus avoiding unnecessary cache read requests and the complication of reverse order reads.
B) If the cache subsystem does not consolidate concurrent identical read requests and does not maintain order of read requests, the result allocation process is allowed to pick one of the results and allocate that value to all outstanding elements with the same memory address (even if those requests have not yet been handed to the cache subsystem).
The result allocation process may mark all such allocations as complete to avoid any further request to the cache subsystem and further work if and when any outstanding cache read requests are signaled.
Alternatively, it may mark none of the elements complete, but apply the same process of updating all the "outstanding" processed elements with the most recent value and only when that set of read requests in complete mark the set complete.
However, knowing that the subsystem does not consolidate and does not maintain order it may be preferred that the scheduler do the consolidation. There are many approaches that can be used, but a reasonable strategy is to augment the bookkeeping of the first read request to the address to add to the list the current request.
C) if the cache subsystem does not consolidate concurrent identical read requests but does maintain order of at least identical address read requests, the reverse order only occurs because the scheduler made an out of order request. This can be handled as in B) above. Hopefully there is a good design reason to shift the onus to after the cache subsystem response.
However, this does violate the premise I established that RVWMO provides meaningful relaxation even in the presence of 0 to vl processing order.
The significant idea here is that the RVWMO model gives considerable latitude to implementer because
within an RVV load there is

not explicit memory synchronization ( rules 4 through 8),
no syntactic dependencies ( 9 through 11) and
no pipeline dependencies (12 and 13).
Overlapping address orderings 1 and 3 do not apply, and
as all elements are of the same size, if all reads are memory size-aligned, non-overlapping or identical addresses, then all identical reads can be consecutive without an intervening write eliminating rule # 2.
(see previous comment for demonstration by induction)

As a result an unordered read is unnecessary in the common bolded above use case,
and in many other cases as well.
(e.g. unaligned depending upon how such unaligned memory fields are allowed to be decomposed and/or whether there is cache-line crossing).
It is worth noting that the results that can occur may be unexpected .
On completion of the RVV load the values in elements 0 through vl of vd can have any values consistent with the global memory order within a window.
That window is bounded by the Program Order Rules which as we see can provide an extremely large range. The opportunity for "unexpected" results is large, but worse, because the reads are stipulated to occur in 0 to vl there is an expectation that "strict" memory ordering is enforced. What RVWMO may actually allow is not anticipated, may be thought to be superseded by process order, or is completely absent in consideration.
The values could  be in reverse chronological order, or in reverse dependency order as seen by the other hart(s) doing the writes.
There is currently no provision to provide fences between successive reads.
So, even though order 0 through vl may be stipulated the returned values in many use cases are not at all dependent upon that order and, in fact, the stipulation creates an unnecessarily complex and potentially misleading conceptual process model.

And the hardware doesn't know what will match until late in the game?

There are many approaches that are consistent with out of order read processing and identical address consolidation that do not need to know what will match until the element is reached. More aggressive ooo may read further ahead, but even simple opportunistic approaches will benefit from judiciously identifying non-overlapping address scenarios, identifying duplicates and consolidating as they arise.

Resolved in https://github.com/riscv/riscv-v-spec/commit/511d0b84a3848de437fd01990d078feaa2871b11


win10 no export file Excel

win10 didn't make export file Excel. I can Just click the button. no result

The problem that cannot be reproduced, I wonder if it is related to the system language.

is there any way to fix or workaround this issue ? when I click Export Files - Export to Excel nothing happens
in other your tool Genshin Wish Export this feature works as expected

is there any way to fix or workaround this issue ? when I click Export Files - Export to Excel nothing happens in other your tool Genshin Wish Export this feature works as expected

I'm not sure what caused the problem. Please package the userData folder under the tool folder and send it to my email address<EMAIL_ADDRESS>


Fix the the request logging boolean toggle

Since we have cut the 0.17, we can go for the proper toggle setup:

if request logging is on — template must be present and the logging will be on
if the request of logging is off — template can be present, but will not affect whether the request logs will be collected

Really
Fixes https://github.com/knative/serving/issues/8644
/assign @yanweiguo @julz

/retest

(ノಠ益ಠ)ノ彡┻━┻
Unrelated
/retest

/retest


stream_builder.h asserts in open

aaudio/utils/stream_builder.h assert(false) in the open() method seems harsh for something that can easily fail.
If the caller requests EXCLUSIVE mode then on some platforms it will succeed and on some platforms it will crash. Better to return nullptr and check in caller.

This class has been removed


Api Key is no longer required

Api key should be marked as optional, as it is no longer required by the api provider.
https://github.com/AndreVarandas/dart-fortnite-api-wrapper/blob/7e36f07070c1ec397a54ee701dc21e21fc209766/lib/api/fortnite_client.dart#L27

Wont do


If a spinner hasn't been constructed when the spin call is made then set...

... the startActive flag so that spinner will start as soon as constructed.

Hi @awk ,
Thanks for your contribution :+1: .
We've decided to refactor the whole code base because of the many requests of webpack and amd compatibility issues, and we're using already webpack in master branch (+TypeScript).
Can you please fix this first and explain how this code is helping?

Closing for deprecated pull-requests


fix(client): raw payload in MW and PCE

closes https://github.com/prisma/prisma/issues/18092

Should we also add a test for middleware?

Ideally yes, but I think that we'd also need to test all other methods and also test middlewares on mongo. I trust this is a good proxy for now. But we should test middlewares thoroughly for each provider, I think there's quite a gap there atm. I created a ticket for this.

Added a missing case for middlewares.


Can't see room name on phone

What screen size is your phone because it seems to be working just fine for me.

What screen size is your phone because it seems to be working just fine for me.

this was an actual issue, it has been fixed now


[Gardening] Clearing the code in core a little bit.

I had some time to finally do some cleaning in the core code. It's not anything big, just moving things around etc. List of changes:

[x] Moved Task to its own file (it was in TargetType and I always had trouble finding where is this one hell of a struct)
[x] Removed multipartQueryComponents - it's not used now after the improvement of Task
[x] Moved Multipart's append methods to extension of RequestMultipartFormData instead of being part of MoyaProvider
[x] Sorted files in the project while I was at it 😄

Codecov Report

Merging #1254 into 9.0.0-dev will increase coverage by 1.4%.
The diff coverage is 0%.

@@             Coverage Diff             @@
##           9.0.0-dev   #1254     +/-   ##
===========================================
+ Coverage      81.59%     83%   +1.4%
===========================================
  Files             24      24
  Lines            766     753     -13
===========================================
  Hits             625     625
+ Misses           141     128     -13

Impacted Files
Coverage Δ

Sources/Moya/TargetType.swift
100% <ø> (ø)
:arrow_up:

Sources/Moya/MultipartFormData.swift
25% <0%> (-75%)
:arrow_down:

Sources/Moya/MoyaProvider+Internal.swift
81.67% <0%> (+10.44%)
:arrow_up:

Continue to review full report at Codecov.

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


Enigma Support

a tracking issue for enigma support someday

Someone suggested to use recaf instead, which is an interesting proposal.

Enigma should be ready to go with df14dd7.


Stand up instance of vanilla KeyCloak for testing

To move fast on experiments with KeyCloak and at the same time ease demoing and jointly testing solutions, we decided to set up a shared dev deployment of KeyCloak somewhere that we can use as testing platform for different use cases / requirements. This would ensure that we are able to look at the same thing while evaluating (vs everyone running local KeyCloak).
Version
It is not clear yet whether there are any restrictions on the version of KeyCloak to use

https://github.com/NASA-IMPACT/veda-auth-central/issues/121

For now, we decided on using the latest stable release, at the time of writing 26.0.1.
Acceptance criteria

[x] We bootstrap a deployment and shares the IaC somewhere accessible to the team
[ ] We present the solution to the rest of the auth team

https://github.com/NASA-IMPACT/veda-keycloak


Add Windows ARM64 CI support

/claim #430
/closes #430
description
Add support for Windows ARM64 CI in release-app.yml, has been tested in Travis CI and Windows Surface.
related issue: #430
Reopened due to repository creation

@louis030195 Also, GitHub Actions offers larger runners with Windows ARM64 native support (https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners)
You might be interested, since cross compilation tends to be slower.

@Neptune650 just created this one, let me know if you can use it or anything i need to do, also if you have any idea of how much it will cost (so unclear their billing)

@Neptune650 just fyi
i see some v8 code stuff, i actually removed deno lib dependency, the only dependency is deno CLI now (which facing some issue to release on windows actually) but it should be easier to implement windows arm now
sorry for the changes, can you update this PR? seems like the official deno build does not offer windows arm though https://docs.deno.com/runtime/getting_started/installation/
maybe through cargo install?
cargo install deno --locked
giving you part of the bounty for the effort for now, can you try to install deno cli in windows arm in the pre_build.js? (this file is kinda dirty but do its job)
/tip $80 @Neptune650

@Neptune650 just fyi
i see some v8 code stuff, i actually removed deno lib dependency, the only dependency is deno CLI now (which facing some issue to release on windows actually) but it should be easier to implement windows arm now
sorry for the changes, can you update this PR? seems like the official deno build does not offer windows arm though https://docs.deno.com/runtime/getting_started/installation/
maybe through cargo install?
cargo install deno --locked
giving you part of the bounty for the effort for now, can you try to install deno cli in windows arm in the pre_build.js? (this file is kinda dirty but do its job)
/tip $80 @Neptune650

Thanks for the tip, but I'm not sure what happens because I haven't received it... no idea why.
I'll see how we can build Deno for Windows ARM64

@Neptune650 will fix algora
i am stuck atm in installing deno cli in windows, trying to fix now

@Neptune650 will fix algora
i am stuck atm in installing deno cli in windows, trying to fix now

Alright, do tell me if you need assistance regarding fixing the Deno CLI

@louis030195 Hello, I'd like to point out two things, first is that since GitHub Runners don't have GPUs by default, the Rust CI takes a lot of time, this leads to it being cancelled, there are three possible solutions:

Use GPU larger runners, I can set up these for you if needed with Actions: https://github.blog/changelog/2024-07-08-github-actions-gpu-hosted-runners-are-now-generally-available/
Use larger runners with more time available to run.
Remove these tests altogether.

Thoughts?

@Neptune650 just created this one, let me know if you can use it or anything i need to do, also if you have any idea of how much it will cost (so unclear their billing)

And regarding this, the pricing for the configuration you picked will be $0.08 per minute ran.

@louis030195 Also I'm not quite sure yet how I could get access to these runners to start testing the Actions under Windows ARM directly, any suggestion?

@louis030195 Also I'm not quite sure yet how I could get access to these runners to start testing the Actions under Windows ARM directly, any suggestion?

not sure what i need to do to let you access the runners
i'd prefer do whatever to use bigger runner, if we can reduce build time also it will be extremely valuable

@louis030195 Also I'm not quite sure yet how I could get access to these runners to start testing the Actions under Windows ARM directly, any suggestion?

not sure what i need to do to let you access the runners
i'd prefer do whatever to use bigger runner, if we can reduce build time also it will be extremely valuable

I think the only way is giving access to the organization but I don't think that's very convenient, perhaps accepting my Actions changes each time? Not sure.

there is a chance that we switch to bun instead of deno in the upcoming week(s) to run pipes since deno in the end provides little upsides and too many downsides (does not support well nextjs, not even easy to write Rust extensions)
likely if going to bun we'll write Rust webassembly extensions for screenpipe-js SDK or another hack
bun does not seem to support windows ARM well too https://github.com/oven-sh/bun/issues/9824

there is a chance that we switch to bun instead of deno in the upcoming week(s) to run pipes since deno in the end provides little upsides and too many downsides (does not support well nextjs, not even easy to write Rust extensions)
likely if going to bun we'll write Rust webassembly extensions for screenpipe-js SDK or another hack
bun does not seem to support windows ARM well too oven-sh/bun#9824

@louis030195 From what I read, even when building from source, it doesn't seem like Bun supports Windows ARM64 natively, so what should be done? This is a pretty big blocker.

@Neptune650 let's pause this issue for now, unless more people ask for windows ARM

@Neptune650 let's pause this issue for now, unless more people ask for windows ARM

@louis030195 That's okay with me

@Neptune650 let's pause this issue for now, unless more people ask for windows ARM

I'm interested in support for Windows on ARM, willing to test

one way to do this is to disable the "pipe store" feature when it's ARM windows (which is the one that uses bun which seems hard to compile for windows arm)

one way to do this is to disable the "pipe store" feature when it's ARM windows (which is the one that uses bun which seems hard to compile for windows arm)

@louis030195 Well another issue is ONNX, which is only supported in ARM windows if using CPU - which is extremely slow.

one way to do this is to disable the "pipe store" feature when it's ARM windows (which is the one that uses bun which seems hard to compile for windows arm)

@louis030195 Well another issue is ONNX, which is only supported in ARM windows if using CPU - which is extremely slow.

i think most people have no GPU anyway and it seem to work fine still


expose isPackageInstalled

This way consumers of this package can also check if a package is installed, which will make this package even more useful.

hello @smokokoi,
thanks for contributing
which issue is this PR related to?

@jgcmarins hey there!  there's no issue that the PR fixes. It's more like a feature. Instead of asking people to use another package to check if a native app is installed, it can be done via this package, as this functionality is already implemented.
For example, if I want to share on Instagram and the app is not installed, then I'd like to show an alert with option going to Google Play and download it.

For example, if I want to share on Instagram and the app is not installed, then I'd like to show an alert with option going to Google Play and download it.

Great!
It would be nice to also support iOS.
Another cool improvement is to add those informations on README

You're right. I'll add it. I made sure to include a very easy to understand code in the example.
I didn't add iOS because RN native also supports it with Linking.canOpenURL

I didn't add iOS because RN native also supports it with Linking.canOpenURL

Great!
Also another good information to add to README

@jgcmarins - I updated the readme. Please accept the PR.

cheers :)

sure, I will do it as soon as possible
for now, could you use master branch?

I can't use the master. I'll wait for whenever you release it.

I perfectly understand.
This is such a best practices.
You can do like that:
"react-native-share": "git+https://github.com/react-native-community/react-native-share.git#03183deb41617a4d145b42bffbea4ca39df0a165"

03183deb41617a4d145b42bffbea4ca39df0a165 is the merge commit, pointing right to your improvements

@mikehardy + @jgcmarins  - cheers for the advice and I'd totally do it if I were working on my own project. There are other considerations, so I'll just wait for the build. Thank you!


Which version of open3d should I use?

As I tried, version <= 0.3.0 cannot work properly on Python 3.7 which is mentioned in your README, while version >= 0.5.0 doesn't have "open3d.geometry.TriangleMesh.create_from_point_cloud_poisson", I wonder if I should use an old version and build from source code?

Finally I use:

Finally solved, I’m using:

Hi, we use 0.9.0 version and you can try pip install open3d==0.9.0.

Finally solved, I’m using:
Anaconda
Python 3.8
open3d 0.11.0


Cookie manager per user vs global

The default example uses: https://docs.streamlit.io/library/api-reference/performance/st.cache_resource
Which states: "Cached objects are shared across all users, sessions, and reruns."
cookie_manager has a variable called cookies, which will becase global and will be sahred accross users, right?
If that's the case on the server side we have a mix of some random combination of cookies, which overwrite each other.
That means if one has more than 1 user on the streamlit page cookie manager is not usable.
I've started to dig deep because this is exactly what we are experiencing, we overwrite each others session_ids.
Could you please confirm or deny this hypothesis?

Honestly, I think that's a typo in the example code. If you change that decorator to @st.cache_data I think you're good to go.
Thanks for raising that issue, it's useful for others.

thanks for the reply @ZupoLlask, well, as far as I understand cache_data is still global, although on that page streamlit does not state it explicitly it only says https://docs.streamlit.io/library/api-reference/performance/st.cache_data
"Each caller of the cached function gets its own copy of the cached data."
So eg.: if you do this:
@st.cache_data(experimental_allow_widgets=True)
def get_time():
   return time.time()

and open the page in 2 browsers you'll see the same result.
one solution could be to not use caching at all, but I'm unsure what the implications of that are.

Hi there!
Since my reply, I continued to investigate the gripes behind the problems with my use case and my understanding evolved a bit.
Streamlit has a difficult execution model, specially if your use case require statefulness across browser sessions (more than a single st.session_state per user, if you want to make it persistent to page reloads) and it gets even harder if you want to make it work with simultaneous unique users (each with potentially multiple browser sessions).
Eventually, yesterday I've been able to make the all thing work reliably with the additional complexity of having integrated Google Oauth2 authentication.
However, in the end, I felt a bit insecure because everything seems too convoluted (to get some common end result working, at least when you use any other framework but Streamlit) and for that reason I'm taking some time to get my head wrapped around all the concepts and misconcepts.
As I need some time for this, I'll get back to you as soon as I'm ready to share more solid conclusions.

@ZupoLlask could elaborate with a little more specifics please? Looks valuable to me.
As of caching - my understanding was:

st.cache_data - single user session, basically same as session_state
st.cache_resource - app-wide singletons

And as streamlit doesn't really know what user is (no auth) - it has no mechanics related to that. Normally I'd stick to Redis or something like that for user-specific caching (different tabs, browsers), or maybe a st.cache_resource with one of arguments being unique user id.
How far is that from your testing results? I'm build a quite large multi-user app and those questions are quite important to me, though I had no time to test properly yet.

Hi, so yeah most of us come to this extention exactly for user management.
Both of this cannot be true:
"single user session" vs "And as streamlit doesn't really know what user is"
cache_data still stores the information globally, see my previous example: https://github.com/Mohamed-512/Extra-Streamlit-Components/issues/54#issuecomment-1763480097
"Normally I'd stick to Redis or something like that for user-specific caching (different tabs, browsers), or maybe a st.cache_resource with one of arguments being unique user id."
Yes of course, but that's not the question, question is setting and storing the user_id or better session_id in a cookie.
I've ended up using streamlit-cookies-manager, please note: https://github.com/ktosiek/streamlit-cookies-manager/issues/5
Problem with that is that it's not maintained, but it works (after the patch), this cookie manager does not work as per documentation. It might work if you do not add any caching at all.
However since I've now a working solution, I was not interested to fully test that approach :)

Regarding @tonkolviktor code snippet, please check the toy example I created to illustrate the "correct" usefulness of st.cache_data and st.cache_resource:
import streamlit as st
from datetime import datetime

@st.cache_data
def get_now(i):
   return datetime.now()

@st.cache_resource
def server_cache():
    obj = {}
    return obj

cache_keys = ["st_runs", "count", "uid"]
cache = server_cache()

if not cache:
    for key in cache_keys:
        cache[key] = cache.get(key, 0)

def main():
    cache["st_runs"] += 1
    print("st_runs", cache["st_runs"])

    if "uid" not in st.session_state:
        cache["uid"] += 1
        st.session_state["uid"] = cache["uid"]

    st.write(f"uid {st.session_state['uid']}")

    st.button("rerun (no-op)")
    if st.button("increment (count)"):
        cache["count"] += 1
    if st.button("decrement (count)"):
        cache["count"] -= 1

    st.write(f"count {cache['count']} @ datetime {get_now(cache['count'])}")

    if cache.get("count") == 0:
        print("count", cache.get("count"))

if __name__ == "__main__":
    main()

A few notes on this toy code:

don't worry about racing conditions when assigning new values to some dict key (including increment and decrement operators) because with recent Python versions those operations are atomic;
that uid is a very simple prototype on how to track different Streamlit sessions (which means a clean/empty st.session_state) server-side using st.cache_resource, as st.cache_data is not useful for this;
the usefulness of st.cache_data can be demonstrated for tracking the datetime a new count number was used for the first time;
I'm tracking the number of Streamlit (re)runs because that's the key for most issues when we try to build apps (at least) a bit more complex than the average app, specially when you have several Streamlit widgets being used at the same time or depending on each other (with some depending on an immediate rerun to behave properly while the other nearby depending on a not immediate rerun later in time to also behave properly).

Regarding the specific issue with your snippet, or why my example works and yours don't:

st.cache_data depends on the concept or cache HIT or cache MISS;
the difference of HIT vs MISS is directly related with the arguments you are passing when you run your function;
in my get_now function that's precisely the reason why I'm considering the i argument that I never use... for anything else but to trigger a new function call (cache MISS) instead of getting the cached st.cache_data output from a previous function call (cache HIT).

As it's stated in the Streamlit docs, we must be very careful with st.cache_data and st.cache_resource as both are indeed shared globally, but both are useful for different things like making our apps persistent to browser reloads (which trigger a new Streamlit session) if we pair them with a UUID (only known by our app) store in a cookie and some OAuth2 authentication service (don't store anything from OAuth2 response in a cookie).
On my tests (using CookieManager from Extra-Streamlit-Components package), most of my issues were related with racing conditions of some widgets depending on a rerun now while the the others requiring a rerun later (not now).
Although @Mohamed-512 did a wonderful service developing this kind of early feature more than 2 years ago, CookieManager may work for you depending on your code and on other widgets being used code, or if you understand how to get around all those issues and rerun racing conditions.
Although my example is now working reliably using streamlit-auth and extra_streamlit_components, I feel that both packages logic is too fragile and troublesome for my use case and I'm going to replace CookieManager dependency with https://github.com/blipk/StreamlitExtras/tree/main/streamlitextras/cookiemanager as this one's logic some far more robust. Probably I'll try to extend its Authenticator class to directly use GoogleOAuth2 without depending on Firebase... But I'm not sure I'll want to do that at this stage.
Some of the issues we stumbled upon can be worked around by using Redis or some database, as stated by @CHerSun.
In my case, I insisted in trying not to use that kind of resource for learning purposes as I started to fear that Streamlit gripes could probably be worse than I anticipated and wanted to dig dipper to find out if I could get it and live with them.

thanks for the details answer @ZupoLlask

Regarding the specific issue with your snippet, or why my example works and yours don't:

I did not really understand what do you mean by "works". The only thing I wanted to show is what you stated as well: "st.cache_data and st.cache_resource as both are indeed shared globally"
My intention was not to create a user specific cache_data, specially not without a cookie which is the key to all this.
Thanks for streamlitextras (I was for a while really confused because it's so similar to Extra-Streamlit-Components) I agree with you I think that's the way forward regarding the cookie manager. It's a really nice catch, since nowhere in the examples the cookiemanager is explicitly mentioned. Thanks!!!
(For auth which is not really the scope of this ticket :) but since we all came here because we want to do auth, let me quickly share this repo: https://github.com/sfc-gh-bhess/st_oauth which in itself was not really useful, but it shows how an oauth flow could work. TODOs to make it work :)

The session_state must be replaced with cookie with session_id and a server side storage of your choice.
I've replaced the vanilla rest+jwt calls with https://pypi.org/project/python-keycloak/
refresh token logic must be implemented
now I have a pretty nice and stable authentication.)

With all that being said it would be probably nice if the cookie manager of this repo would be fixed as well.

i

tested this. Ouch. Thank you for clarifying this.

Hi all, I also ended up here to create some sort of light "user" functionality to my app.
My current situation is:

if I use the cached version, all the users (once deployed) share the same cookies - this in my case is not acceptable
if I use cookie_manager = stx.CookieManager() with no cache, the app performs an additional rerun that slows down the loads but, at least, keeps the cookies differentiated among users (or browser) and everything works as expected.

I mentioned this issue about the additional rerun into the #58


Fixed #23.

So I've submitted this PR to the issue #23 . Changed the line about AMD module define and add the module name (isMobile)  like this:
//AMD
define('isMobile', [], global.isMobile = instantiate());

Nice! Also add yourself to contributors file and I'll merge it. :smiley:   Or I can add you myself if you don't want to.

Yes I've done. @kaimallea . Thanks! And I am honored.

:+1: Awesome, thank you for contributing!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Dependencies for issues

It would be nice if you could define dependencies for issues.
This would mean you define that this issue (#1) depends on this other (#2), so you can't close the first one (#1) unless the other one (#2) is closed.

A good idea.

As long as it only checks one jump. e.g. #1 => #2 => #3. #1 only checks #2 and #2 only checks #3.
Otherwise the lookup-time would be painful...

And what about autoclose with commit? Should than pre-receive hook fail?

@bkcsoft So that one issue only dependent only 1 issue?
@lafriks autoclose with commit will then check the dependecies

@lunny but autoclose commit would then need to also close the other issue. To not make it too complicated, i would propose to not close the issue if it has another one depending on it.
So, if i committed something to #1 to autoclose #1, but #1 depends on #2 and #2 is still open, it would simply not close #1. Maybe a logmessage to the issue why it couldn't be closed.
Sent from my Oneplus A0001 using FastHub

@lunny @kolaente There are two options either as @kolaente described not to close issue even if in commit with fixed #1 message or not allow pushing commits for issues that can not be closed yet

@bkcsoft So that one issue only dependent only 1 issue?

@lunny So that one issue only depends on the closest issues

@bkcsoft I mean one issue maybe dependent two or three issues?

@lunny @bkcsoft I'd say one issue should be able to have more than one dependent issue. (And all dependents must be closed)
Example:
#1 depends on #2, #3 and #4, so #2, #3 and #4 must be closed before #1 can be closed.

@kolaente not only issues, but also pull requests.

@lunny @kolaente Never said anything about multiple dependencies, only that an issue should only be linked to it's closest related dependency.

I'll start working on this (But bare with me, my go skills are not the best :grin: )

Closing as PR has been merged.


Fix infinite loop

Popper.js' componentDidUpdate fails the props change test, which calls updatePopperInstance, which eventually causes componentDidUpdate to get called again. By using a deepEquals comparison on props.modifiers we correctly determine that the props did not update, and break the loop.
I don't have a nice simple repro for this issue, but it seems to only trigger in a complicated app on Chrome (at least 70.x->78.x) on Windows when the page's zoom level is less than 100%.

I have this happening in our app and for us it only happens at precisely 75% zoom in chrome. We are using a blueprint datepicker but I can't repro on their test page.

@FezVrasta any chance you could look at this PR?

This patch resolves reproducible browser freeze (CPU in busy loop) in our app which uses Blueprint. My reproducible test case involves running Chrome on Windows at 75% zoom (as mentioned by @DanHarman above).
I will note that we are also getting reports of similar issues at 100% zoom. I'm hopeful this fix will help there as well, but I haven't been able to reliably reproduce that issue yet.

Any chance we can get a patch release with this fix? We'd love to update to fix the freeze issues we've been seeing in our apps!

1.3.7, there you go.
Thanks again for the help everybody!

@FezVrasta thank you!


How is {log, logit, bilog} determined in bayesmark/sklearn_func.py?

Thanks for a great project. I'm using the benchmarking function in bayesmark/sklearn_func.py. This file defines several benchmark functions using sklearn. A "space" is defined for each function's hyperparameters. How is this "space" determined?
# RF
rf_cfg = {
    "max_depth": {"type": "int", "space": "linear", "range": (1, 15)},
    "max_features": {"type": "real", "space": "logit", "range": (0.01, 0.99)},
    "min_samples_split": {"type": "real", "space": "logit", "range": (0.01, 0.99)},
    "min_samples_leaf": {"type": "real", "space": "logit", "range": (0.01, 0.49)},
    "min_weight_fraction_leaf": {"type": "real", "space": "logit", "range": (0.01, 0.49)},
    "min_impurity_decrease": {"type": "real", "space": "linear", "range": (0.0, 0.5)},
}

In particular, I'd like to know how {log, logit, bilog} is determined here. Is there anything that would help me?

The user determines the space based on where they want more "search resolution". For instance, logit space will make algorithms more inclined to search near 0 and 1.


Backport time related fixes from ROS1: PR #79 #105 #106 and #154

The master branch (ROS1) contains several enhancements related to GPS time parsing that could be also useful in the ROS2 version. This PR brings those changes in the ros2 branch.

I did a quick initial review, and this looks good to me. As soon as I have a chance, I'll test it out and if it works as expected, I'll merge it. Thanks for your contribution!

Looks good to me:

The Jpr and Rpr CI failures are unrelated.
Tested with a BU-353S4 GPS device

Thanks for this contribution!


Added ssl option when instantiating StrictRedis

This is a simple change that allows defender to connect to a secure ElastiCache redis instance (aka rediss://)
Future work could include allowing proxy connections using certificates to traditional Redis instances.

Coverage decreased (-0.2%) to 91.484% when pulling f0087db63c8983be109d122102bb74dd019b28c7 on Telmediq:development into 250c4d53880d5309d2bd6f0376c1e22b4a1ddb68 on kencochrane:master.


Knex with official oracledb driver

Hi, Seems the official oracledb driver support was there in knex from version 0.11.8 https://github.com/tgriesser/knex/pull/990. I was able to connect to Oracle 12 by installing oracledb nodejs driver in my AdonisJS project using the following configuration:
oracle: {
    client: 'oracledb',
    connection: {
      timeout: 10,
      host: 'localhost:1521',
      //port:'1521',                **//Declaring port here does not work**
      user: 'username',
      password: 'password',
      database: 'mydb'
    },
    debug: true
  }

But even after the connection got through, any queries made to OracleDB through the AdonisJS model resulted in an error. I am using a pre-defined table called 'USERS' (notice uppercase) with associated Model called Users. When the query is made to OracleDB it goes like this:
Error: select * from "users" - ORA-00942: table or view does not exist
Seems passing table names in quotes does not work with Oracle.. Is it possible to fix this issue from lucid so that we can add node/oracledb driver support to AdonisJS?

Is this the oracle db support issue? Or the table name needs to be fixed?

Table name passes inside double quotes to the DB like this: select * from "users"
Instead, it should pass like this : **select * from users**

Does it work fine with knex?

Just tested with latest Knex v0.12.6, and the issue exists in Knex library. Meanwhile knex.raw("select * from USER");  works fine with NodeJS/OracleDB driver. Meanwhile stong-oracle does not work at all.

@tejzpr Seems to be an issue with knex. Would you mind reporting this issue with them?

Done! :)

@tejzpr Does it only happens when table name case is mis-matched or everytime?

This issue occurs only if table name or field name case mismatch occurs. If table name & field name is of the same case in DB and Model then everything works fine. Verified this by overriding table name in model by using the following code.
static get table () {     return 'USER'   }

Another issue I just found is that Omitting Fields From JSON Output by using
static get visible () {
   return ['title', 'body']
 }

does not work with Oracle Database.

A possible solution to this issue could be that any Table name or Field name generated for Oracle data source be converted to uppercase before passing on to Knex query builder since Oracle internally saves table names & field names in upper case. i.e. even if a table is created in lower case like user_list in oracle it can still be accessed by running select * from USER_LIST;. But if a table is created in upper case like "USER_LIST" it cannot be accessed by passing select * from user_list;

Nope the end user should be responsible for setting up right database table name, instead of framework deciding it

Since it's not an issue with lucid, neither with knex, closing the issue

Hi according to comment from the knex issue that I raised some days back, the case sensitivity to Oracle table names should be handled while creating queries. Since AdonisJs had generators for creating models, shouldn't query compatibility be handled during that time?

Since Adonis does not know whether the table name is lowercase or uppercase it seems to be hard to transform names on the fly. The best way is to define the tablename on the model.


Kargo bid adapter

Thanks for improving the documentation 😃
Please give a short description and check the matching checkboxes to help us review this as quick as possible.
🏷 Type of documentation

[X] new bid adapter
[ ] update bid adapter
[ ] new feature
[ ] text edit only (wording, typos)
[ ] bugfix (code examples)
[ ] new examples

📋 Checklist

[X] Related pull requests in prebid.js or server are linked
[X] For new adapters check submitting your adapter docs

Mentioned in User Documentation https://docs.prebid.org/prebid-server/developers/add-new-bidder-go.html

Sorry - @SSuranie just pointed out that bid adapter doc .md files need to go in /dev-docs/bidders, not /dev-docs/modules. It's not consistent with where the BidAdapters go in Prebid.js.

Hey @bretg, I have added the readme to the bidders directory

The server-side adapter was merged last month. Merging docs.


i3: config.modes.resize: add Return to defaults

Rebased into master: https://github.com/rycee/home-manager/commit/3c875267afdac6348e5e7177df10364db8bb5edd. Thanks for the contribution!


Improve evaluation

How to evaluate GAPs?
How to deal with substitution? May need to implement own Levenshtein algorithm
Tokenisation (only discrepancy is merging?)

Character offsets from original untokenized string to bypass tokenization differences! (Some of the CGEL trees have entire words that were accidentally omitted. Assuming the annotator has inserted no more than one word at any given point in the text, it could have a character span like 13,13. Should we actually score whether the word string matches given that edits to the word-string are possible e.g. misspellings, normalizing capitalization?)

One nice thing about the character-level eval is that we can also double check the same underlying sentence is being parsed. Here's the performance of the UD->CGEL convertor on EWT and Twitter respectively:
{'raw_dist': 5.92, 'normalised_dist': 0.06299538767574435, 'precision': 0.1690013046614213, 'recall': 0.1861626346918553, 'valid': 24, 'count': 100}
{'raw_dist': 4.984615384615385, 'normalised_dist': 0.09388778321396395, 'precision': 0.35429347629281677, 'recall': 0.3832528038475125, 'valid': 30, 'count': 65}

Was going to bring up 3 more special cases in our meeting this week...until I realized we won't be meeting this week. :)

Inserted words: Our .cgel format allows for the annotator to specify that some words were missing from the original string due to a typo. I think such nodes can be assigned offsets in the same way as gaps (e.g., _14 for an inserted word whose right sibling starts with original string character 14).
Gap coindexations: While the actual variables don't have to match, we want to make sure the coindexation is correct. Because every gap must have exactly one antecedent, an easy solution is to change its category to incorporate the offset of the antecedent (e.g. GAP becomes GAP_10,13). Then the labeled evaluation requires the antecedent to be in the correct position, and the unlabeled evaluation ignores it. (This does not check the category of the antecedent when scoring the gap, but of course the antecedent constituent is scored separately.)
Lexical strings: The tree can contain spelling corrections. Moreover, if two annotators insert a word in the same position, the word itself may or may not match (suppose a copula is missing and one annotator guesses "is" and the other "was"). Should the lexical strings be scored independently of their category (POS) and function?

For the labeled score, I think counting a substitution as equal to an insertion plus a deletion is too harsh. Consider a gold Comp:PP constituent that is incorrectly predicted to have label Mod:PP. We're saying that error is twice as bad as if the constituent wasn't predicted at all! For computing precision and recall, counting it as .5 of an insertion and .5 of a deletion would make more sense I think.
This is a typical case BTW: when a constituent's span is correct, the function is usually more difficult to decide than the category.

Yeah...what about .25 insertion & deletion costs if category XOR function is wrong, .5 if they're both wrong?

Now implemented in edit_distance(): with strict=False, partial credit for aligned nodes:

Nonterminals: 0.25 penalty for wrong function, 0.25 for wrong category (leave 0.5 credit for span)
Lexical terminals: 0.25 penalty for wrong function, 0.25 for wrong category, 0.25 for wrong normalized string (leave 0.25 credit for token span)
Gap terminals: 0.25 penalty for wrong function, 0.25 for wrong antecedent span (leave 0.5 credit for gap)

Thus, for every aligned node, 0 ≤ cost < 1. (This cost is divided equally between precision-error and recall-error.) As before, inserted/deleted nodes have a cost of 1.
Assignment of relative offsets to gaps and other inserted nodes still TBD.

eval.py is now fully based on Tree Edit Distance, as documented in our LAW 2023 paper.


[ENHANCEMENT] Add an explanation for solution of powerset

Description

Seeing that the code is so concise, I feel that it would be helpful to provide a little bit of description to the solution as readers may be unsure on how and why the solution works.
PR Type

[x] Snippets, Tests & Tags (new snippets, updated snippets, re-tagging of snippets, added/updated tests)
[ ] Tools, Scripts & Automation (anything related to files in the scripts folder, Gatsby, website, Travis CI or Netlify)
[ ] General, Typos, Misc. & Meta (everything related to content, typos, general stuff and meta files in the repository - e.g. the issue template)
[ ] Other (please specifiy in the description above)

Guidelines

[x] I have read the guidelines in the CONTRIBUTING document.

I am LOST! No clue nor understand much of any of this so really dont know how u have to read a mile long to what yall seem to think as simply short...???


Usage in other LSP clients?

Is it possible to use or modify this server in other LSP clients? For example in vim-lsp?

The server directory contains the core of the Language Server. You might need to make a few changes, but I think it can be used with other text editor clients as well.

Unfortunately, I know nothing about javascript.
How is your server started? Is there an executable? Like for example, for c++, the server executable is clangd.

This project uses npm, and you can compile it with npm run compile
The compiled JavaScript files are output to server/out/.
The client app then runs server/out/server.js  (you can see this in the following file: https://github.com/sashi0034/angel-lsp/blob/43a7cdb94d179ff0e7bbdb0d5f9aee2a7218f34a/client/src/extension.ts#L21).
By the way, I’m also interested in making it work with other client apps. I'm currently busy, I plan to work on this in the near future.


File inclusion checks get confused when only character case is different

When the case has changed between the original project and the included files, the converter gets confused as it is presumably doing a case sensitive check. Not sure how my projects ended up with different cases but they did.
Here's a simple sample I created and the messages generated
DemoApp.zip
File found which was not included, consider removing ####\DemoApp\program.cs.

File was included but is not on disk: ####\DemoApp\Program.cs.

Great repro inside the zip file, made verification of the fix super easy, thanks!


Minor changes sessions-code-interpreter.md

Updated the command from az containerapps to az containerapp

@anthonychu
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Clean up test output

Do the replication tests print anything now on success? I'm not sure how robust the orchestration is to exit codes. Can we distinguish all passed from none ran? Other than this, lgtm.

Yes, there's still output on success -- it's just more nicely formatted/aligned and easier to read now :)


[request] Provide builds for x86dbg plugin

The x64 counterpart is there, I believe the code can be almost entirely copied over verbatim, if not verbatim 100%.
Beats using TitanHide GUI manually :-)

There is no such thing as x86dbg.


Mitigate possible NSE exception in PrivateAccessValidator.java

Issue #, if available: n/a
Description of changes:
Within PrivateAccessValidator#getPrivateAccessValiationEvent, an unchecked call to Optional#get occurs. This might throw a NoSuchElementException if the optional is indeed empty.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks for the review, @mtdowling; I didn't mean for you to look at this over the weekend, apologies.
I haven't seen the error in-practice, but it was reported by a static analysis tool after I ran a compilation locally. I'm happy to help improve the codebase if this is something you would find useful. Are there any places in the code in particular that actually might be at risk of NoSuchElementException?

Thanks for updating. Generally any place that we use .get() right now is probably fine and rather than convert to returning optionals or additional conditionals, we could switch to using these kinds of expect* style methods when available or using something like orElseThrow.

Got it, thanks! I'll fix the checkstyle errors shortly.

Thanks!


The app is crashing if tracker URI contains Unicode symbols

encodeURIComponent causing an exception if the function argument contains Unicode symbols
URIError: URI malformed
at encodeURIComponent (native)
at /home/nodejsuser/offcloud/server/downloader/node_modules/parse-torrent/node_modules/magnet-uri/index.js:117:17
at Array.forEach (native)
at /home/nodejsuser/offcloud/server/downloader/node_modules/parse-torrent/node_modules/magnet-uri/index.js:112:14
at Array.forEach (native)
at Function.magnetURIEncode [as toMagnetURI] (/home/nodejsuser/offcloud/server/downloader/node_modules/parse-torrent/node_modules/magnet-uri/index.js:110:6)
I think it makes sense to filter/escape value before encodeURIComponent, or catch the exception

Unicode is handled correctly. This error is caused by an invalid Unicode sequence.
From MDN:

Note that an URIError will be thrown if one attempts to encode a surrogate which is not part of a high-low pair.


'node' is not recognized as an internal or external command, operable program or batch file.

version: 1.25
i was just trying to run a program and i got this error message
'node' is not recognized as an internal or external command,
operable program or batch file.
which is weird because the file 'node.dll' is present in the folder
help me pls

no it does not
On Mon, 23 Jul 2018 at 10:26, Andre Weinand<EMAIL_ADDRESS>wrote:

How does your debug configuration look like?
I you open VS Code's integrated terminal and run node there, does it work?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/54849#issuecomment-406979668,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AnnBAd_JJKvaPDccdYVYPz84eOdipCkjks5uJYiygaJpZM4VakIY
.

having "node.dll" in a folder does not sound like a correctly installed Node.js.
Please install node.js correctly and verify that you can run it from a command prompt or form VS Code's integrated terminal.


Startup Issue

Extension Name: search-rg
Extension Version: 1.0.0
OS Version: Windows_NT x64 6.1.7601
VSCode version: 1.28.0

We have written the needed data into your clipboard. Please paste:

Closing please see https://github.com/Microsoft/vscode/issues/60318


Languages of titles

To order the titles correctly, we need to ignore "the", but Cahiers titles are in multiple languages (mainly English, French and Italian).  So the il, i used as the definite article in Italian (for masculine singular and plural nouns starting with a consonant) are ambiguous: I vinti but I, Daniel Blake.  We can fix this by adding a language attribute to these ambiguous cases.

In progress in the title-languages branch.

done


blah i like to play on nintendo is now separated to two lines

blah i like to play on nintendo is now separated into two lines:
blah
I like to play on nintendo

I also fixed typos:


Added a fixtures that checks if tasks are still running in tests

Closes #519

With the additions in the above the modified test correcly failed with:
ERROR tests/core/test_status.py::test_async_status_exception_timeout - RuntimeError: Not all tasks [<Task cancelling name='Task-1481' coro=<sleep() running at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/tasks.py:639> wait_for=<Future cancelled> cb=[AsyncStatusBase._run_callbacks()]>] closed during test test_async_status_exception_timeout.

Now it's been changed. We still need to track down what's causing the Task destroyed but it is pending - I would assume we need to add the same check to the RunEngine cleanup.

With the changes to the RunEngine we get explicit errors in the tests creating tasks that aren't awaited/cancelled.
There seems to be some nasty behavior in tests when devices connected to outside the RunEngine loop are used within the RunEngine (I've already corrected some of these tests in the same commit). I did some experimenting to see if could creatively change the RunEngine's event loop to avoid this, but no joy... I'll adjust the rest and see if I can find a way to warn the user if they use devices connected in a different event loop within the RunEngine.
https://github.com/bluesky/ophyd-async/blob/24c7ccf04eaf28370e0b57ce877b2a493209bf17/tests/conftest.py#L98-L101
=============================================== short test summary info ===============================================
ERROR tests/epics/adsimdetector/test_sim.py::test_detector_with_unnamed_or_disconnected_config_sigs[-config signal must be named before it is passed to the detector] - RuntimeError: Not all tasks {<Task pending name='Task-8496' coro=<StandardDetector.unstage() running at /scratch/twj43146/Programming/ophyd-async/src/ophyd_async/core/_detector.py:227> wait_for=<Future pending cb=[Task.task_wakeup()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/base_events.py:427> cb=[AsyncStatusBase._run_callbacks()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/tasks.py:374>} closed during test test_detector_with_unnamed_or_disconnected_config_sigs[-config signal must be named before it is passed to the detector].
ERROR tests/epics/adsimdetector/test_sim.py::test_detector_with_unnamed_or_disconnected_config_sigs[some-name-config signal some-name-acquire_time must be connected before it is passed to the detector] - RuntimeError: Not all tasks {<Task pending name='Task-8596' coro=<StandardDetector.unstage() running at /scratch/twj43146/Programming/ophyd-async/src/ophyd_async/core/_detector.py:227> wait_for=<Future pending cb=[Task.task_wakeup()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/base_events.py:427> cb=[AsyncStatusBase._run_callbacks()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/tasks.py:374>} closed during test test_detector_with_unnamed_or_disconnected_config_sigs[some-name-config signal some-name-acquire_time must be connected before it is passed to the detector].
ERROR tests/sim/test_sim_detector.py::test_writes_pattern_to_file - RuntimeError: Not all tasks {<Task pending name='Task-17379' coro=<PatternDetectorController._coroutine_for_image_writing() running at /scratch/twj43146/Programming/ophyd-async/src/ophyd_async/sim/demo/_pattern_detector/_pattern_detector_controller.py:55> wait_for=<Future pending cb=[Task.task_wakeup()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/base_events.py:427> cb=[AsyncStatusBase._run_callbacks()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/tasks.py:374>} closed during test test_writes_pattern_to_file.
ERROR tests/sim/test_streaming_plan.py::test_streaming_plan - RuntimeError: Not all tasks {<Task pending name='Task-17410' coro=<PatternDetectorController._coroutine_for_image_writing() running at /scratch/twj43146/Programming/ophyd-async/src/ophyd_async/sim/demo/_pattern_detector/_pattern_detector_controller.py:55> wait_for=<Future pending cb=[Task.task_wakeup()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/base_events.py:427> cb=[AsyncStatusBase._run_callbacks()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/tasks.py:374>} closed during test test_streaming_plan.
ERROR tests/sim/test_streaming_plan.py::test_plan - RuntimeError: Not all tasks {<Task pending name='Task-17435' coro=<PatternDetectorController._coroutine_for_image_writing() running at /scratch/twj43146/Programming/ophyd-async/src/ophyd_async/sim/demo/_pattern_detector/_pattern_detector_controller.py:55> wait_for=<Future pending cb=[Task.task_wakeup()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/base_events.py:427> cb=[AsyncStatusBase._run_callbacks()] created at /dls_sw/apps/python/miniforge/4.10.0-0/envs/python3.11/lib/python3.11/asyncio/tasks.py:374>} closed during test test_plan.
====================================== 423 passed, 1 skipped, 5 errors in 26.88s ======================================

Currently, detector controller is only disarmed once:
https://github.com/bluesky/ophyd-async/blob/d7f07488fdfa976037791cbdfdb21e0f7c5f7430/src/ophyd_async/core/_detector.py#L202-L207
However it is armed in both trigger and prepare:
https://github.com/bluesky/ophyd-async/blob/d7f07488fdfa976037791cbdfdb21e0f7c5f7430/src/ophyd_async/core/_detector.py#L253-L257
https://github.com/bluesky/ophyd-async/blob/d7f07488fdfa976037791cbdfdb21e0f7c5f7430/src/ophyd_async/core/_detector.py#L299-L303
This is the cause of all the test failure's here.

Interestingly, the standard detector unstage error is only present if I set the debug mode to true in the RE event loop.