runtime: updates needed when goroutines switch threads on ppc64

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version devel +adb1e67 Tue Aug 30 08:08:37 2016 +0000 linux/ppc64le
What operating system and processor architecture are you using (go env)?
Ubuntu 16.04
We haven't hit a specific problem in this area yet, but there are concerns that some additional instructions should be included in the runtime.gosave routine when a goroutines's information is saved before it is swapped off a thread.  We should be doing a sync and an instruction to clear any lwarx reservation that might be pending.

How could there be an lwarx reservation pending?  Goroutines aren't preempted arbitrarily.  They are requested to stop and they stop only at agreed transition points.

I think the situation of concern was if a goroutine called C code that was preempted.
If that is not a situation we need to be concerned about then I can just add the sync because I was told it should be there.

C code (or Go code) may be preempted by the kernel, but it won't be preempted by the goroutine scheduler.  That is, there is no scenario in which preempting C code will lead to a call to runtime.gosave.
I'm fine with adding a sync instruction to runtime.gosave if we can see some path that requires it.  But I don't want to add it just because there might conceivably be a problem.  Right now I don't see how there could possibly be a problem.

Back to the pending reservation question -- couldn't someone write some functions in asm code where one function did a lwarx and another did a stwcx, and those asm functions were both called from within a goroutine in such as way so that preempting would be possible between the two?  Bad programming style but is it illegal in Go?

I would say that doing a lwarx in one function and stwcx in another is
illegal in Go assembly.  When writing assembly, there be dragons, and this
is (another) one.
On Wed, Aug 31, 2016 at 8:06 AM, Lynn Boger<EMAIL_ADDRESS>wrote:

Back to the pending reservation question -- couldn't someone write some
functions in asm code where one function did a lwarx and another did a
stwcx, and those asm functions were both called from within a goroutine in
such as way so that preempting would be possible between the two? Bad
programming style but is it illegal in Go?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16928#issuecomment-243794293, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGkgIB9jLDEm2QBPeVS2lalcwxdusl5eks5qlZiAgaJpZM4Jw0w5
.

It certainly seems like a bad thing to write code with lwarx and stcwx that way.  Are you saying not to worry about that case and if someone reported it they would be told it's illegal?  I don't think it would have to be Go asm, I think someone could write a
Let me back up to what prompted this issue to begin with.  We are looking at ways to improve some of the atomic loads and stores on ppc64le so they don't have to do as many syncs -- maybe remove some or replace with lwsync in some cases.  Changing some of those would depend on having a sync in gosave when a goroutine is swapped off a thread.  So my thought was to put the change into gosave first separately and then follow with the other changes to some of the atomics.  If it's preferred that all changes related to syncs and lwsyncs are done in one change we can do that instead.

On Wed, Aug 31, 2016 at 11:25 AM, Lynn Boger<EMAIL_ADDRESS>wrote:

It certainly seems like a bad thing to write code with lwarx and stcwx
that way. Are you saying not to worry about that case and if someone
reported it they would be told it's illegal? I don't think it would have to
be Go asm, I think someone could write a

Yes, we can say "don't do that".  lwarx and stcwx don't pair across a
preemption point.  Same as depending on register state to be preserved
across a preemption point - it may work in the common case, but not if a
preemption occurs.

Let me back up to what prompted this issue to begin with. We are looking
at ways to improve some of the atomic loads and stores on ppc64le so they
don't have to do as many syncs -- maybe remove some or replace with lwsync
in some cases. Changing some of those would depend on having a sync in
gosave when a goroutine is swapped off a thread. So my thought was to put
the change into gosave first separately and then follow with the other
changes to some of the atomics. If it's preferred that all changes related
to syncs and lwsyncs are done in one change we can do that instead.

Your plan sounds fine.  All changes don't have to be in one CL.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16928#issuecomment-243855260, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGkgIBFzfKN53W4iyzd_t6HVDWZ49VjRks5qlcb_gaJpZM4Jw0w5
.

I would have said that adding a STCX. seemed a small price to pay to make the goroutine switch bulletproof, but I understand @randall77 comment, it's your ABI and runtime so you can make the rules.
Regarding the need for the SYNC, we got the explanation from one of our cache architects (Derek Williams), which I will paraphrase here:
It is possible for a store done by a goroutine to linger indefinitely in the L2 store queue. If this goroutine is preempted and then immediately restarted on another processor, then without a guarantee of an intervening SYNC it could possibly enter a state where it would not be able to see it's most recent stores, because they would not have been committed to the coherence order yet. His final words were "There's no room to debate this one".

I believe there is room for debate once you understand that goroutines are not preempted at arbitrary points, but only at well understood and agreed upon points.

I was also asked about the case where Go calls C and C starts a transaction.  Is there any way the transaction could be left in an unfinished state and then the goroutine is preempted by the Go scheduler.

The Go scheduler will never preempt a goroutine that is running C code.
In the sense that we are discussing here, the Go scheduler never preempts anything at all.  It just, essentially, sets a flag on the goroutine saying "please stop."  The goroutine checks that flag from time to time (currently, at each call to a function written in Go or written with the Go assembler, if that function is not marked nosplit).

In addition to what Ian said, the Go scheduler uses synchronization
operations to move a Goroutine from one P (one OS thread) to another.  So
the Go scheduler guarantees that after a goroutine stops, it will make sure
all of its state gets to the new processor before the goroutine is started
again.
On Wed, Aug 31, 2016 at 1:42 PM, Ian Lance Taylor<EMAIL_ADDRESS>wrote:

The Go scheduler will never preempt a goroutine that is running C code.
In the sense that we are discussing here, the Go scheduler never preempts
anything at all. It just, essentially, sets a flag on the goroutine saying
"please stop." The goroutine checks that flag from time to time (currently,
at each call to a function written in Go or written with the Go assembler,
if that function is not marked nosplit).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16928#issuecomment-243894335, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGkgIOa4PxAE_4X2loUmmHddJ_2kebMRks5qlecegaJpZM4Jw0w5
.

Hello, I'm the Derek Williams Bishop referred to. I'm a hardware guy and I know how to spell Go, but that's most of what I know about Go.  But I am the Power ISA memory model expert, so what I say here and in other emails will be slanted towards how the hardware works at the machine instruction level.  There's doubtless some translation to be had from that world-view into Go.
Above, ianlancetaylor says:
I believe there is room for debate once you understand that goroutines are not preempted at arbitrary points, but only at well understood and agreed upon points.
Possibly yes. Can you give me some idea what these agreed upon and well understood points guarantee? Some of the usual hygiene that has to happen at context switches might be avoidable based on these conditions, but before I can have an opinion I need to know what guarantees those points give you.
And randall77 says:
In addition to what Ian said, the Go scheduler uses synchronization
operations to move a Goroutine from one P (one OS thread) to another.  So
the Go scheduler guarantees that after a goroutine stops, it will make sure
all of its state gets to the new processor before the goroutine is started
again.
Interesting. can you explain what synchronization operations those are?
They might fix things, but I can't tell because I have no idea what they are.
I apologize for my ignorance here. Once I have some idea what these things are and if they fix this, I'll be in a better position to comment.
Thanks,
Derek

On Wed, Aug 31, 2016 at 5:28 PM, strikerdw<EMAIL_ADDRESS>wrote:

Hello, I'm the Derek Williams Bishop referred to. I'm a hardware guy and I
know how to spell Go, but that's most of what I know about Go. But I am the
Power ISA memory model expert, so what I say here and in other emails will
be slanted towards how the hardware works at the machine instruction level.
There's doubtless some translation to be had from that world-view into Go.
Above, ianlancetaylor says:
I believe there is room for debate once you understand that goroutines
are not preempted at arbitrary points, but only at well understood and
agreed upon points.
Possibly yes. Can you give me some idea what these agreed upon and well
understood points guarantee? Some of the usual hygiene that has to happen
at context switches might be avoidable based on these conditions, but
before I can have an opinion I need to know what guarantees those points
give you.

Those points are at most function call prologues (a few specially chosen
runtime functions opt out of allowing preemption).
In Go, all registers are callee-save so no registers are live at these
points, except the stack pointer and any arch-specific things like thread
pointer and zero register.

And randall77 says:
In addition to what Ian said, the Go scheduler uses synchronization
operations to move a Goroutine from one P (one OS thread) to another. So
the Go scheduler guarantees that after a goroutine stops, it will make sure
all of its state gets to the new processor before the goroutine is started
again.
Interesting. can you explain what synchronization operations those are?
They might fix things, but I can't tell because I have no idea what they
are.
I apologize for my ignorance here. Once I have some idea what these things
are and if they fix this, I'll be in a better position to comment.

There's a lock around the global run queue (src/runtime/lock_futex.go).
Processors also put and take work from per-P queues using atomic load +
compare and swap (src/runtime/proc.go:runqget, for example).

Thanks,
Derek
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16928#issuecomment-243942064, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGkgIHBW0FNcXaQ2ogewa06qCCd5fboVks5qlhw3gaJpZM4Jw0w5
.

@strikerdw Hi, thanks for the comments.  I alluded to the cases earlier.  The goroutine scheduler works by, essentially, setting a flag asking a goroutine to stop.  The goroutine checks the flag periodically, and, if it is set, stops, and enters the scheduler.  A goroutine also enters the scheduler whenever it blocks on some operation, like a channel operation.  Goroutines are never preempted.
The periodic flag checks currently occur at function entry for ordinary functions.  Those are the only moments when a goroutine enters the scheduler because of a preemption request.  All that needs to be saved at such a point--all that is saved when a thread switches from one goroutine to another--is the PC, the stack pointer, and, on some architectures, the link register.  Everything else is in memory somewhere.

I was afraid of that. I follow much of that, but not all of it.
So let me just try to explain from a machine code level what can happen. We'll have to map this up to the Go reality later.
Suppose I have this machine code:
st r1, X                    // r1=1
...context switch....  // took a context switch here (in your world that's some function call that allows it)
ld r2, X                   // read X back.
In Power, the st r1, X doesn't propagate to memory immediately (and in fact propagates to other processors and memory at varying points in time). So, memory write for the st r1, X can hang out in a queue on the processor you started executing on and not be visible to anyone else for a very long time unless a barrier pushes it around.  If the  bit doesn't have a barrier (an HWSYNC in this case) in the path, when the S/W thread here wakes up on the other processor, that other processor may not have yet seen the st r1, X and could easily see a stale cached version of X. So the ld r2, X can see "0" (assume inital before write of X is 0).
That's bad. Coherence (or uniprocessor data dependencies -- depending on who you're talking to) just went out the window. Don't cross the streams kinda bad......
The way we cope with this in POWER is for context switches to have an HWSYNC. That also doesn't technically push the store out by itself (I'm fibbing a bit here, but it's close enough for this discussion), but what it does do is order the st X,1 ahead of the stores to whatever job queue control data structure that the H/W thread we're destined for will read in order to realize it can dispatch the S/W thread. So by the time the S/W thread dispatches on the new H/W thread,  the HWSYNC has ensured that the ST X,1 is visible to the new H/W thread.
Normal programmers never see this. It just happens in the OS and no one is the wiser. Once you start taking on thread migration at a user level, however, you start feeling and having to manage these effects.
So when Ian said earlier something to the effect that "everything else is in memory somewhere", it's probably a bit more accurate to say that everything is at least on its way to memory and will get there eventually or when a barrier pushes it through.
It's really hard for me to imagine how you avoid this. Sadly it'll take me a long time to learn enough Go to read your scheduler code and look at the barriers in that and determine if that synchronization will fix this (unless there's an obvious HWSYNC that's executed on the departing thread :-)).
As an aside, I don't work for ARM, and I don't play an ARM engineer on television, but their memory model has a great many technical similarities to ours. As a matter of architecture, I would expect them to have similar issues. As a matter of most of the current implementations I've aware of, they may get away with skipping the barrier..... for now. You should check with them at some point.
Let's agree about SYNC before we start into STCX/reservations. The case there is open for more debate.
Derek

I think you're overthinking this.  Almost any parallel computation does:
thread 1:
*x = 5
unlock y
thread 2:
lock y
... = *x
Any implementation has to implement lock and unlock so the read in thread 2
is guaranteed to see 5.
That's all we need for the Go scheduler to work properly.  The unlock
y/lock y pair are inside the scheduler (what gets called when a Goroutine
takes an "interrupt" and is descheduled, then rescheduled).  There's
nothing special about goroutine state - it is just data guarded by locks.
There's a few optimizations in the scheduler where we don't actually do a
lock/unlock but a cheaper compare-and-swap or other atomic operation.
You're also going to have to implement those atomic ops so that their
memory semantics are correct.  The implementations are in
runtime/sync/atomic.
On Wed, Aug 31, 2016 at 7:14 PM, strikerdw<EMAIL_ADDRESS>wrote:

I was afraid of that. I follow much of that, but not all of it.
So let me just try to explain from a machine code level what can happen.
We'll have to map this up to the Go reality later.
Suppose I have this machine code:
st r1, X // r1=1
...context switch.... // took a context switch here (in your world that's
some function call that allows it)
ld r2, X // read X back.
In Power, the st r1, X doesn't propagate to memory immediately (and in
fact propagates to other processors and memory at varying points in time).
So, memory write for the st r1, X can hang out in a queue on the processor
you started executing on and not be visible to anyone else for a very long
time unless a barrier pushes it around. If the bit doesn't have a barrier
(an HWSYNC in this case) in the path, when the S/W thread here wakes up on
the other processor, that other processor may not have yet seen the st r1,
X and could easily see a stale cached version of X. So the ld r2, X can see
"0" (assume inital before write of X is 0).
That's bad. Coherence (or uniprocessor data dependencies -- depending on
who you're talking to) just went out the window. Don't cross the streams
kinda bad......
The way we cope with this in POWER is for context switches to have an
HWSYNC. That also doesn't technically push the store out by itself (I'm
fibbing a bit here, but it's close enough for this discussion), but what it
does do is order the st X,1 ahead of the stores to whatever job queue
control data structure that the H/W thread we're destined for will read in
order to realize it can dispatch the S/W thread. So by the time the S/W
thread dispatches on the new H/W thread, the HWSYNC has ensured that the ST
X,1 is visible to the new H/W thread.
Normal programmers never see this. It just happens in the OS and no one is
the wiser. Once you start taking on thread migration at a user level,
however, you start feeling and having to manage these effects.
So when Ian said earlier something to the effect that "everything else is
in memory somewhere", it's probably a bit more accurate to say that
everything is at least on its way to memory and will get there eventually
or when a barrier pushes it through.
It's really hard for me to imagine how you avoid this. Sadly it'll take me
a long time to learn enough Go to read your scheduler code and look at the
barriers in that and determine if that synchronization will fix this
(unless there's an obvious HWSYNC that's executed on the departing thread
:-)).
As an aside, I don't work for ARM, and I don't play an ARM engineer on
television, but their memory model has a great many technical similarities
to ours. As a matter of architecture, I would expect them to have similar
issues. As a matter of most of the current implementations I've aware of,
they may get away with skipping the barrier..... for now. You should check
with them at some point.
Let's agree about SYNC before we start into STCX/reservations. The case
there is open for more debate.
Derek
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16928#issuecomment-243956966, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGkgIEedZlkRkrD2SwVR4SQsAqqZgqznks5qljUYgaJpZM4Jw0w5
.

For the record, the SYNC instructions required by what Keith is talking about are in https://golang.org/src/runtime/internal/atomic/asm_ppc64x.s and https://golang.org/src/runtime/internal/atomic/atomic_ppc64x.s .
On the one hand, we could certainly be doing something wrong, and it would be great if you could analyze our code and verify that it works.  On the other hand, we aren't new at this stuff; we do pretty much know what we're doing.

@strikerdw I agree now that the current implementation is OK for normal cacheable memory. Locking the scheduler lock to insert the preempted goroutine into the global queue guarantees that any HW thread that is able to see and pick up the goroutine from the global queue will necessarily be able to see all stores made by the goroutine before it was placed in the queue.
So I think the question now has to do with I/O and non-cacheable memory. As @laboger mentioned above we want to replace almost all HWSYNC instructions in our atomics with LWSYNC to improve performance. The only remaining HWSYNC would be in the seldom-used atomic.Store() routines. LWSYNC does not order I/O or noncacheable memory, and presumably C-language routines called from Go could be using these types of memory.

I guess the concern is that C code might use I/O instructions and non-cacheable memory but fail to call HWSYNC?  I have no idea how much of a problem that would be.  We could add HWSYNC instructions to the code that moves between C and Go easily enough.  Calling from Go to C will go through the function asmcgocall in runtime/asm_ppc64x.s.  Calling from C to Go will go through the function crosscall2 in runtime/cgo/asm_ppc64x.s (note that those are two files with the same name in two different directories).

Apologies for the delay. My day job required my attention today....
OK, first off, I'm going to set Bishop's answer to the side and talk about this from a different point of view.. His answer is technically correct in so far as it goes, but that answer obscures the issues here more than it helps understanding.
Also, to be clear, I don’t intend to imply for a moment that you folks don’t know what you’re doing. I’m quite sure you do. However, the specific mechanics and hardware needs Power has on software for thread migration is not a subject we document as well as we should, so it’s difficult for anyone, no matter how skilled, to find.
What Randal says above about unlock-ing and lock-ing and threads and reading/writing variables is all true, but I don't think that example captures all the subtlety going on in process migration.
So, again consider this program (note it's single threaded):
ST X,1
some_go_function_call_so_we_can_context_switch()
LD X
I believe we all agree the LD X better get 1 (assuming that the function call didn't manipulate X). If we don't agree, please say so now. So, the critical issue here is what magic happens in the thread migration code.
Now if the thread migration code, in the process of locking the job list, putting the S/W thread info on the job list, and unlocking the job list winds up incidentally doing an HWSYNC on the physical hardware thread we are departing, this issue will work out (killing the reservation is a separate issue).
I suspect that’s what’s happening now. I looked at your assembler code and it’s got “SYNC” all over the place in it (which I assume means what I call an HWSYNC in our standard mnemonics).  So it’s hard for me to imagine you don’t have an HWSYNC in there somewhere though I haven’t confirmed this.
So it may be working, but I don't think the intent was to use an HWSYNC in this path because it would indirectly manage the hardware thread migration issues. I think your intent in that locking/barrier work was mainly to manage getting the S/W thread onto the job list safely.
If what you were out to do is just the job list manipulation, a better implementation in Power would use LWSYNC and possibly ISYNC instead of any HWSYNCs here. And modifying these primitives on Power to not use so much HWSYNC is something we’re looking at because there’s a chance they’re currently over-burdened with synchronization (this a different and deep subject and it depends on what the Go language's memory model semantics are).
So if we get to a point where the primitives are a bit more efficient, HWSYNC might not “just happen” in the path. You'd still need at least an LWSYNC, but those don't interact with cache-inhibited ops. So with only LWSYNC left the job list manipulation would work but programs with I/O over the migration would fail. Consider this program:
store to I/O data register
go_function_call_so_we_can_context_switch()
store to control register telling adapter to read data registers
The LWSYNC in the thread migration code wouldn’t push the store to the I/O data register out on the old hardware thread and the store to the control register could happen from the migrated to H/W thread first.  The device would read a corrupted data register value.
Having HWSYNC in many or most the atomic primitives instead of LWSYNC might fix this thread migration issue and not require the one HWSYNC explicitly in the path, but you're paying HWSYNC penalties for every other use of the primitive instead of LWSYNC penalties.
I think the bottom line is this: on a thread migration if you place one explicit HWSYNC in the path, it just works. Period. No having to think, no debates, no long github posts. No complex sets of rules. Done.  And it might wind up being faster than having the HWSYNCs in most/all of the primitives.
If you don’t have that explicit HWSYNC, one has to really scrub the thread migration code path to be sure it either 1) implicitly winds up doing an HWSYNC for some reason (and it prossibly didn’t need to do an HWSYNC there instead of an LWSYNC) or 2) figure out whatever barriers you do have in the migration path and then what subtle things (like I/O) you have to tell the programmer that can’t span over the function call that might context switch.
The second option can be really complex to figure out and leaves the programmers with a complex set of rules. If I understood correctly, one of the guiding principles of Go is to keep user programmers from having to think about this stuff?
So I can’t say there is no other way to achieve the thread migration than by an explicit HWSYNC in the path, but I think the other options over penalize the barriers in the primitives or require a complex set of “can’t do’s” for the programmer and can be hard to figure out.
Derek

Go provides no way to write to an I/O register except by executing assembly code.  I'm perfectly willing to say that any assembly code that writes to an I/O register is responsible for executing HWSYNC instructions as needed.  I appreciate your concerns as to documenting what a programmer can assume about a context switch, but since approximately zero Go programmers will try to manipulate I/O registers it doesn't seem like a major concern.  Go isn't really that kind of language.  I think it's vastly more likely that anybody who wants to do that will call into a C library, so I can see a good argument for calling HWSYNC on the Go <-> C call paths.
The SYNC instruction that appears in Go assembly code does appear to assemble to an HWSYNC instruction (0x7c0004ac).  If we can replace this with a more efficient instruction, that would be great.
We do currently use LWSYNC in one case: to ensure that the garbage collector metadata for a new object is visible to the concurrent garbage collector before the object is actually used in any way.  See publicationBarrier in runtime/malloc.go.

Ok. That is a legitimate choice.
To not be remiss then, I should point out that unless there's an incidental HWSYNC (say in the to or from C paths), the programmer putting in HWSYNCs may not be enough:
ST to data register
go_function_call_so_can_preempt()
HWSYNC
ST to ctrl register
will also fail. The HWSYNC the programmer inserted executes on the thread we migrated to and that does not push out the CI store on the thread we migrated from.  In the absence of proper run-time support the programmer inserting even correct barriers may not be enough.
So, at this point I'll assume the issues around barriers in the thread migration path are either avoided or handled by whatever barriers are there or in the C path. There are a few other hygiene clean up things that are generally necessary when migrating threads in Power. I will list them below and leave it to you folks to decide if they matter in the context of Go's thread scheduler.  All of these operations are executed on the thread being departed. (I think this list is complete).

Doing a stcx to a scratch location to clear the reservation for larx/stcx instructions. This prevents a STCX on the thread being dispatched on the H/W thread errantly succeeding based on the prior S/W threads larx.

Doing a tabort instruction (P8 and later). This resets the transactional tracking mechansim and prevents a thread being dispatched from errantly committing a partial transaction.

Doing a cp_abort instruction (P9 and later). This resets the copy-paste instruction machinery so that an interrupted copy-paste pair doesn't errantly execute on the new thread.

If there are any questions, I'm happy to answer, but otherwise I'll consider this subject closed.
If programmers do manage to do things that cause issues with the context switching, those bugs are extremely difficult to isolate and debug. They'll happen quite randomly and usually only in cases of heavy load (yes I've had the misfortune of doing this).
This is probably not the entirely correct place to ask, but who (if anyone) is responsible for deciding what the Go programming language memory model is? Are there any written documents? Like the C++ or C or (shudder) Java memory models? To figure out if the atomic routines in Go can use more efficient Power barriers, I need to better understand what the language's memory model requirements are. Any help is appreciated.
Thanks ,
Derek

The Go memory model is at https://golang.org/ref/mem .  You will likely find it unsatisfactory.  See also #5045, #7948, and #9442.
In any case, the Go memory model is for user code.  It does not describe the requirements on the Go runtime itself.  That is, the Go memory model describes the sync/atomic package, or, more precisely, it should describe that package but doesn't.  The Go memory model does not describe the runtime/internal/atomic package, which is what the runtime uses.

I was out a few days last week and Bishop is now out through the end of next week.  Lots of good discussion here to help understand the situation.  Here is my suggestion on how to proceed.
Bishop has proposed changes to some of the atomic functions to use LWSYNC instead of HWSYNC to improve performance.  Most of these are in the runtime/internal atomics.  Once he gets back he can submit his change.  Bishop has studied the Go scheduler more than I but I see Keith's point about the runqput functions doing locks when swapping goroutines and how that should meet the requirement of doing a sync and clearing the reservation.

As far as goroutine switching is concerned, the key point is what Keith said: the Go runtime really looks like any other multithreaded user program that Linux might run. The only way a goroutine stops execution on one thread and starts anew on another is when the goroutine itself is handed off to the other thread using either a locked data structure (the global run queue) or an atomic compare and swap. Assuming those lower level things are implemented correctly, there's nothing extra needed to make sure the memory is carried along.
It is also important that goroutines are cheap: goroutine switches happen at very high frequencies. It's important not to weigh them down to the level of thread context switches. I'm unconcerned about assembly authors leaving the processor in an unfortunate state (stcx, tabort, cp_abort, etc). That's their problem, as discussed above.
I know that Derek, Bishop, and Lynn are working on sanity checking the actual atomics, and I spoke to them about that earlier this week and expect to continue to do so. Assuming those are OK and stay OK, goroutines should come along for the ride.
Since Derek wrote:

If there are any questions, I'm happy to answer, but otherwise I'll consider this subject closed.

I will close this.


Bump pyweatherflowudp to 1.1.1

Resolves issue #109

I will merge this, and build new containers.

I need to add one more thing to this before you build

Ok, no worries. You merge again when you are ready to go. I will then build tonight or tomorrow morning,

It'll be up in just a few seconds


Fix duplicate 'cflags_cc' entry

My previous PR worked fine on my system but was apparently buggy because of a dual cflags_cc property that I failed to identify; this PR should fix this (and a trailing comma).

This PR triggers other errors. I'll experiment a bit more.

@jjrv Is this <@_cflags> value actually required ?

Turns out it wasn't in cflags_cc becausecflags get included there automatically. ldflags still needs it.
Does the develop branch work for you now? It does pass all tests, including compiling asm.js on OS X.

Thanks! I don't have this error myself, but I've asked those affected to check (https://github.com/facebook/yoga/pull/304).

@jjrv Our issue was apparently with our bindings.gyp, nbind was fine :v:


chore: bdd-nh-1587715793 to 0.0.1

chore: Promote bdd-nh-1587715793 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Build Python wheels on Windows

Tested here: https://github.com/kuzudb/kuzu/actions/runs/5126793944/jobs/9221725746 (I overrode the workflow settings to have it run on that branch, which, along with faking the version, is the differences from this PR).
cibuildwheel is run manually because the quoted arguments passed to it in the windows/powershell version of the cibuildwheel action don't work properly for options which are left empty (on kuzu's windows runner at least).
TODO: double-check that the wheels work. Done. All the wheels contain the extension and I installed and tested the python3.11 wheel.
I rewrote the package_tar.sh in python so that it would run more easily on Windows.
It was also necessary to fix make clean on windows, as it is called in setup.py and would return an error if the directories to clean don't exist.
And while I'm fairly sure that ARCHIVE_OUTPUT_DIRECTORY worked to control the output directory of the python extension when I was just testing building the extension before, the extension wasn't being stored in the correct directory again, which setting RUNTIME_OUTPUT_DIRECTORY fixed (setting all three should be exhaustive).

Could you please trigger Build-Linux-Wheels and Build-Mac-Wheels on CI to make sure it does not break any existing workflow? As long as it still works for both Mac and Linux we can merge it.

It seems this breaks both Mac and Linux wheel build:  https://github.com/kuzudb/kuzu/actions/runs/5150769886 and https://github.com/kuzudb/kuzu/actions/runs/5150768166. Could you please look into it?


Generate the RSA auth keys

Hi guys, I've been trying to figure out how to generate the ADB keys within this python module, so we can run a 100% Python implementation of ADB, without ever requiring to run the server to first generate the keys. There is an ongoing discussion here regarding this issue.
So I wrote a simple code with the supported RSA librairies:
from adb.usb_exceptions import DeviceAuthError
from adb import adb_commands
from adb.sign_pythonrsa import PythonRSASigner
from adb.adb_protocol import InvalidChecksumError
import os.path as op
from Crypto.PublicKey import RSA
from adb import sign_pycryptodome

Signer = PythonRSASigner.FromRSAKeyPath

uri='<IP_ADDRESS>:5555'
byte_uri = str.encode(uri)
adbkey=op.expanduser('~/.android/adbkey')

if op.isfile(adbkey):
    print('Key found, trying with auth')
    signer = Signer(adbkey)
    adb = adb_commands.AdbCommands().ConnectDevice(serial=byte_uri, rsa_keys=[signer])
else:
    print('Adbkey {} not  found, trying without auth'.format(adbkey))
    key = RSA.generate(2048)
    private_key = key.export_key(pkcs=8)
    public_key = key.publickey().export_key(format='DER')
    with open(adbkey, 'wb') as priv:
      priv.write(private_key)
    with open(adbkey+'.pub', 'wb') as pub:
      pub.write(public_key)
    try:
        adb = adb_commands.AdbCommands().ConnectDevice(serial=byte_uri)
    except DeviceAuthError:
        print('Auth key required for device {}'.format(uri))

But the problem is that the original code generates a custom public key, which is "naked" as in no formating is present and there is also the user and hostname of the device.
The code generating the keys is here, although I'm not familiar enough with C to understand and port the function.
To me it seems to be as simple as porting this function, any thoughts ? Could somebody do it ?
Thanks! 🙂

I tried previously and ran out of time trying to figure out how to get the key in that format, sorry! Anybody else want to try?

I tried previously and ran out of time trying to figure out how to get the key in that format, sorry! Anybody else want to try?

I'm not alone who run out of time on ADB stuff


[TRANSFORM] Fix virtual device annotation issue with BYOC subgraphs

Heterogeneous module partitioned by BYOC has functions nodes without any VirtualDevice definition (having FullyUnconstrained device). Ignoring the device here causes expr_virtual_devices_ being empty when PopVirtualDevice is called assuming above PushVirtualDevice is succeeded. PushVirtualDevice and PopVirtualDevice occurs as pairs across function body, hence it's better to insert the The Virtual Device for Uncontrained and Pop it subsequently.

Hi @srkreddy1238, I didn't quite understand the conclusion you make,

PushVirtualDevice and PopVirtualDevice occurs as pairs across function body, hence it's better to insert the The Virtual Device for Uncontrained and Pop it subsequently

Naively I can understand why we skip pushing an unconstrained virtual device: If something is fully unconstrained then it's virtual device shouldn't influence the function body visitation. What issue is this causing in BYOC?
Is there a unit test you can consider contributing that can help illustrate the issue?

PushVirtualDevice and PopVirtualDevice maintains the current VirtualDevice information on stack expr_virtual_devices_ . These calls are invoked across a block parsing (FunctionNodes, CallNode ..etc). The stack (expr_virtual_devices_) grows as we nest into the functions.
def @tvmgen_default_clml_main_17(%clml_17_i0: Tensor[(1, 2048), float32] /* ty=Tensor[(1, 2048), float32] */, Inline=1, Compiler="clml", global_symbol="tvmgen_default_clml_main_17", Primitive=1) -> Tensor[(1, 1000), float32] {
  %245 = fn (%FunctionVar_0_01: Tensor[(1, 2048), float32] /* ty=Tensor[(1, 2048), float32] */, PartitionedFromPattern="nn.dense_nn.bias_add_", Composite="clml.dense") -> Tensor[(1, 1000), float32] {
    %244 = nn.dense(%FunctionVar_0_01, meta[relay.Constant][257] /* ty=Tensor[(1000, 2048), float32] */, units=1000) /* ty=Tensor[(1, 1000), float32] */;
    add(%244, meta[relay.Constant][258] /* ty=Tensor[(1, 1000), float32] */) /* ty=Tensor[(1, 1000), float32] */
  } /* ty=fn (Tensor[(1, 2048), float32]) -> Tensor[(1, 1000), float32] */;
  %245(%clml_17_i0) /* ty=Tensor[(1, 1000), float32] */
}

In the above IR the composite function %245 = fn (%FunctionVar_0_01 will not have a VirtualDevice definition ( VirtualDevice(?)) and the PushVirtualDevice fails. Whereas at end of this function parsing the PopVirtualDevice removes the VirtualDevice corresponding to the our scope function. From here all annotations fail due to empty stack.
I figured it out as part of large network. I am working on to facilitate a test case for the same.

@mbs-octoml

@junrushao can you take a look on this ?

cc @echuraev @elvin-n does this change look good to you and pass internal texture tests?

cc @echuraev @elvin-n does this change look good to you and pass internal texture

Our tests runs in CI and if we see green CI it means this change does not affect them and whole flow. I cannot answer if this change affects origin Mark's idea and if it does not brake anything in other places. Again, assuming that we have many tests for VirtualDevices and they passed, this change should be safe.

@junrushao can you conclude this PR ?  There are some follow up on this.

Sure! It’s been approved for a while already. Not sure why it’s not merged yet


fix: Allow proto-loader configuration with sensible default that incl…

…udes keepCase to keep the proto casing.

:tada: This PR is included in version 1.0.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add 'scope' parameter/ARM property

need to add the missing 'scope' parameter/ARM property and allow for value to be null if or use the TF 'resourceGroupName' value if scope is not specified

@jesseloudon I have implemented the built-in Azure policy called "Audit delegation of scopes to a managing tenant" (category is LightHouse). It is possible that multiple LightHouse registrationAssignment's can be created in more than one subscription within an Azure tenant.
I believe in order to create more than one exemption for these multiple LightHouse configurations within a tenant, I would need to use this scope parameter with a for_each in front of it to create these multiple exemptions. It says here that the value of scope is a string (not a list of strings).
Would you agree that I'm approaching this in the correct way and I would need to make use of this scope parameter?

hey @mlcooper - great Q
I do think multiple exemption resources are the way to go in your particular use case w/ either a count or for_each on this exemption module. I have a count example here if that helps! https://github.com/globalbao/terraform-azurerm-policy-exemptions/tree/main/examples/count
Regarding usage of the scope parameter:

this is designed for setting the scope of the exemption resource to be different to the ARM template's deployment scope - important to know this in the context of using this exemption module which creates the deployment to a specific resource group scope
yes looks like scope is a string so only 1 value can be passed in
I need to add/test the scope parameter usage in this module per this open issue 😄

@jesseloudon do you know what the value of the scope parameter would be if I wanted to create an exemption for a Resource Group that has ID /subscriptions/1111111-2222-3333-4444-555555555555/resourceGroups/rg-resources-policy-dev?
I'm asking because I have not been able to find any examples of what the value for the scope parameter would be, either in Azure's documentation or in someone's public code on github.

hi @mlcooper
I'm thinking that the RG ID or resource ID you pass into the Scope parameter would need to be in the same subscription context as the Terraform deployment for the policy exemption.
Additionally, if you need to target multiple subscriptions for policy exemptions from your calling/parent Terraform module you can use provider aliases as per this example: https://github.com/globalbao/terraform-azurerm-policy-exemptions#create-2-policy-exemptions-targeting-rgs-in-two-different-subscriptions


Boruvka's algorithm for minimum spanning tree

💥 Proposal
Like Prim’s and Kruskal’s, Boruvka’s algorithm is also a Greedy algorithm for finding the minimum spanning tree.
Have you read the Contributing Guidelines on Pull Requests?
(Write your answer here.)
Yes

/assign


fix: Make the logic around last_count working

Did 2 changes here:
First is the important one where I removed && [[ $last_count -ge 0 ]] as that was blocking changing last_count, because it was initialized to -1. Now it should work as expected.
Second I made sure warning is printed if we fail to obtain current count value.

/test mvp

/test mvp

/test mvp


Trying to change status bar color on IOS (android working)

Steps to Reproduce

Check out the latest counter example
Change status bar color via setSystemUiOverlayStyle to white with black text
Run app in IOS Simulator

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

void main() {
  runApp(const MyApp());

  SystemChrome.setSystemUIOverlayStyle(const SystemUiOverlayStyle(
      statusBarColor: Colors.white, // Color for Android
      statusBarBrightness:
          Brightness.dark // Dark == white status bar -- for IOS.
      ));
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headline4,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ),
    );
  }
}

Expected results:
A white status bar color with black icon and text
Actual results:
Status bar color stays at the color of the appbar

Logs

$ flutter analyze
Analyzing flutter_app...
No issues found! (ran in 1.7s)

$ flutter doctor -v
[✓] Flutter (Channel stable, 2.5.1, on macOS 11.5.2 20G95 darwin-x64, locale
    de-DE)
    • Flutter version 2.5.1 at /Users/alexander.gutheil/Development/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision ffb2ecea52 (11 days ago), 2021-09-17 15:26:33 -0400
    • Engine revision b3af521a05
    • Dart version 2.14.2

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/alexander.gutheil/Library/Android/sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 13.0, Build version 13A233
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.60.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.26.0

[✓] Connected device (4 available)
    • Redmi 4X (mobile)           • 80aed727d740                             •
      android-arm64  • Android 7.1.2 (API 25)
    • Alexander’s iPhone (mobile) • 8fc6289ff444127cb93d7d2685f0251f231ddaf6 •
      ios            • iOS 14.6 18F72
    • iPhone 13 (mobile)          • EA016BFC-2290-41AF-9BBD-AAD1DDB6E76B     •
      ios            • com.apple.CoreSimulator.SimRuntime.iOS-15-0 (simulator)
    • Chrome (web)                • chrome                                   •
      web-javascript • Google Chrome 94.0.4606.61

• No issues found!

Hi @gutisalex
statusBarColor only suppose to work on Android devices. See https://github.com/flutter/flutter/issues/77904#issuecomment-803055437
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you


[Bug]: useForwardProps throws warning due to passing Component in as

          @zernonia, we would need, I think, also to omit the `as` attribute and pass it manually otherwise, we get this warning

[Vue warn]: Vue received a Component that was made a reactive object. This can lead to unnecessary performance overhead and should be avoided by marking the component with markRaw or using shallowRef instead of ref.

<script>
// ...
const pickedProps = reactiveOmit(props, 'as', 'autoFocus')
// ...
</script>

<template>
// ...
<Primitive
  v-bind="pickedProps"
  :as="props.as"
  // ...
</template>

Originally posted by @iamandrewluca in https://github.com/radix-vue/radix-vue/pull/649#discussion_r1479576691

@iamandrewluca can you share what version of Vue you are using? I tested on latest shadcn-vue repo (Vue 3.4.15) and it seems good tho. Not seeing the warning.

v3.4.15

v3.4.15
https://github.com/radix-vue/radix-vue/assets/1881266/8eb3bf8a-55c1-4164-8c51-ba22eddec24c

Ahh! It's actually because of reactiveOmit https://github.com/radix-vue/radix-vue/blob/main/packages/radix-vue/src/Combobox/ComboboxInput.vue#L68 and not useForwardProps

@zernonia, Thanks a lot!


xiaomi hyperOS can't install onnx models

deviceName:  Redmi k50
osVersion: <IP_ADDRESS>

Hi, I have already answered here for this problem.

TKS I'm using a proxy.


Improve README

This PR tries to partially address some of the concerns raised in issue #26 to improve the README.md file.

@falquaddoomi, thank you so much! And please feel free to review whatever PR is ready. It doesn't matter if you are not a reviewer (it should be the same for everyone). I was just trying not to bother many of you with this.


CI Improvements

chore: use single .node-version ref
fix(ci): add missing permissions for release

Thank you!


Opening http://localhost:6789/ automatically

Is your feature request related to a problem? Please describe.
It is a little annoying when starting up a new project, http://localhost:6789/pipelines does not automatically open in a browser tab.
Describe the solution you'd like
Let console open http://localhost:6789/pipelines automatically.
Describe alternatives you've considered
Only one solution to this??
Additional context
N/A

I can take this 🙋🏼♂

Wow, you’re the best @bruno-uy!!! <3

If you're using pip or conda to run mage it's pretty straightforward. It gets tricky inside a docker container (recommended usage) because it needs to interact with the host's default browser. I'm trying different options without luck. I'll keep you updated.

I'm thinking about using the standard webbrowser Python library to open the app URL after the server is up (right before this print), but as I mention the webbrowser library cannot access the default browser because docker runs in isolation from the host machine.
If you want to access the host file system, you need to mount a volume, expose those folders, and have control of the window system to open the browser (as far as I understood reading some docs).
TL;DR: opening the host browser from the docker container is not the best practice, but we can include that when using pip or conda.
@Ayumi08 @tommydangerous let me know if I'm missing something and what do you think about my proposal.

I think that's totally acceptable solution. Thank you so much!!!

Hi @Ayumi08 , this feature is available in version 0.8.29. Let us know whether it works for you.

🙌🙌🙌


In NiceCXNetwork remove get_edge_attribute_objects() since it always raises Warning (which is incorrect behavior anyways)

In NiceCXNetwork remove get_edge_attribute_objects() since it always raises Warning (which is incorrect behavior anyways)

Fixed with commit in chrisdev


Consider using cbindgen for C and C++ bindings.

The current C bindings are pretty lacking and are made unusable due to the fact that you need to parse JSON to get stuff like layout data. While looking for potential solutions, I came across cbindgen which seems to be able to generate quite usable bindings that even include struct and enum definitions considerably reducing the amount of boilerplate code one needs to write. This will require some changes to the main source code so we are going to need to experiment with this.

I'm fairly certain that won't work for our use case as it can't handle wasm, C#, Java, Swift, Python, Ruby and all the other bindings we generate. cbindgen isn't even useful for this though as we do pretty much everything cbindgen does already anyway (+ all this other stuff). What is missing here are all the functions for querying the information out of the layout states, which basically are just missing because no one needed them yet. But they are super easy to write.
What could be interesting though is a proc macro based binding generator or whatever that lets us annotate our methods and then auto generate the C API for them. That's definitely worth exploring.

I'm fairly certain that won't work for our use case as it can't handle wasm, C#, Java, Swift, Python, Ruby and all the other bindings we generate. cbindgen isn't even useful for this though as we do pretty much everything cbindgen does already anyway (+ all this other stuff). What is missing here are all the functions for querying the information out of the layout states, which basically are just missing because no one needed them yet. But they are super easy to write.

I did some work with in the past few hours it and it seems to be missing support for some very important things so its already out of the question.

What could be interesting though is a proc macro based binding generator or whatever that lets us annotate our methods and then auto generate the C API for them. That's definitely worth exploring.

This seems even better than just using cbindgen. We can also annotate structs with #[repr(C)] to allow them to be directly exposed to C code provided we create a struct definition in the header file. cbindgen does something similar to allow structs themselves to be exposed.

Going to close this for now


Second Screen Clock

Any idea how to do this with the second screen clock now that they added it as well?

Thank you, works great on primary.  We were looking for something like this for days. I was using ElevenClock and then setting the clock color font to the same color as the task bar.  Super hacky.  Yours is much better!

Hi @flynnsbit
I've added support for secondary screens in the new version 1.3.0 😉
Just use the --secondary switch (or -s, /s) and if will find and hide/show those clocks too.
I'm planning to add a version of the tool with an UI, so that people not used to work with the console can use it easily.
Hope this helps and thanks for the suggestion!

Thank you!!


get_words function is not defined

get_words function is not defined

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

ID: ff1757f1-3eb4-923b-7904-1c6369e7ba0b
Version Independent ID: d0f9e299-8553-30b5-1bf0-8f454925584e
Content: Quickstart: Document Intelligence (formerly Form Recognizer) SDKs - Azure AI services
Content Source: articles/ai-services/document-intelligence/quickstarts/get-started-sdks-rest-api.md
Service: azure-ai-document-intelligence
GitHub Login: @laujan
Microsoft Alias: lajanuar

@james-mwakichako
Thanks for your feedback! We will investigate and update as appropriate.

@james-mwakichako
I've delegated this to @laujan, a content author, to review and share their valuable insights.

Hi @james-mwakichako, Thank you for your feedback. What programming language and model are you using? Thanks again!
cc: @RamanathanChinnappan-MSFT

@laujan I am using Python

Hi @james-mwakichako, Thank you for your feedback. get_words is a helper function defined as follows:
def get_words(page, line):     result = []     for word in page.words:         if _in_span(word, line.spans):             result.append(word)     return result
It is defined within this code sample: Quickstart: Document Intelligence (formerly Form Recognizer) SDKs - Azure AI services | Microsoft Learn
Thanks again!

#please-close


New API for Creating New Port Types

The current system uses multiple inheritance making the code very hard
to follow and reason about:

too much magic and too much you need to keep in your head

attributes like self.name and self.closed appear in your
name space and you have to dig around in the base classes to see
where they come from

there is a self._parser in every port even if you don't need it

self._parser is not thread safe

BaseInput.receive() needs to account for all the numerous
current and historical behaviors of self._receive().

blocking and nonblocking receive can not be protected by the same
lock (since a call to receive() would then block a call to
poll()), which means ports that due true blocking need to do
their own locking.

if you want to do our own locking you need to remember to set
_locking=False. This will replace the lock with a dummy lock,
which while doing nothing still adds a bit of overhead.

A good principle is for any part of the code to know as little as
possible about the rest of the code. For example a backend port should
only need to worry about:

opening and closing the device

reading and writing data (blocking and nonblocking)

It should not have to worry about things like autoreset,
closed=True/False and iteration. Also, as long as its send()
and receive()/poll() methods are thread safe the rest of the API
will be as well.
Some alternatives to subclassing:

embedding: write a basic port and wrap it in a FancyPort which
provides the rest of the API

mixins: write a basic port and use mixins (PortMethods,
InputMethods, OutputMethods) to import the rest of the API.

Looks related to #494 to me.


Plugin: Images - maxWidth not being respected in largest() function

I have the following widths configured:
widths: [1800, 1200, 900, 600, 350]

On an image with original width 1500 and using the following code for src: helpers.images.largest('/images/photo-2.jpg',{maxWidth:400}).relative
Expected:
return value of photo-2-ejs-350.jpg
Actual:
return value of photo-2-ejs-1200.jpg
I have deleted my manifest and regenerated to no avail.

TY this is great. I'll test this out and if a PR doesn't already exist, can create one.

This will be picked up on the typescript branch release. I'm trying to release beta 1.8.0-beta.3 for Elder.js and betas for all of the plugins tonight.
We've got ElderGuide.com migrated over, we'll get FindEnergy.com and the others moved then release 1.8.0 and a migration guide.
Included here: https://github.com/Elderjs/plugins/commit/52354e21194cb5e8595714c355f49f0054699687


Add PDF file support as option for documents parameter

Describe the improvement
Add support for PDF files in the documents parameter, allowing users to provide PDFs directly.
Code snippet of expected outcome
import cohere

co = cohere.ClientV2("<<apiKey>>")

response = co.chat(
    model="command-r-plus",
    documents=[{'id': '1', 'data': {'path': '/path/to/document.pdf'}}],
    messages=[
        {
            "role": "user",
            "content": "What is this document about?"
        }
    ]
)

print(response)

Here is how much code I currently have to write to get the above going:
chat_with_pdf.zip

Hey @ai-yann thanks for suggestion, we won't be implementing this right now because PDF would introduce a lot of complexity with parsing etc. we would currently expect the client to manage this complexity.


build faild

Hi  Alex，
when i run make to build the project,there is a problem which shows no rule ro run make target 'fpga.bit'.Please tell me how to solve it.Thanks a lot!

@LXinQ this repo is just a fork of Alex's Forencich verilog-pcie repository.
Please open an issue there if it is still failing with the latest master.


semicolon treated as an expression

; returns undefined (as there is no value), but is usable in expressions such as let x = (;); or while (;) {}

Relevant code:
https://github.com/y21/dash/blob/605db2eb69e335c78a98e9607a14e5aee6b62360/crates/dash_parser/src/expr.rs#L368-L369


Crash when baking reflection probes with IPL_BAKEDDATAVARIATION_REVERB

I'm encountering a segfault when trying to bake reflection probes with IPL_BAKEDDATAVARIATION_REVERB.  The bake begins and runs for a second or two, spewing this warning constantly: Warning: Simulating reflections for 1 sources, which is more than the max (0). Some sources will be ignored., before eventually crashing without finishing.
This is what my bake parameters look like:
IPLBakedDataIdentifier identifier{};
identifier.type = IPL_BAKEDDATATYPE_REFLECTIONS;
identifier.variation = IPL_BAKEDDATAVARIATION_REVERB;
IPLReflectionsBakeParams bake_params{};
bake_params.scene = scene;
bake_params.sceneType = IPL_SCENETYPE_DEFAULT;
bake_params.identifier = identifier;
bake_params.bakeFlags = IPL_REFLECTIONSBAKEFLAGS_BAKEPARAMETRIC;
bake_params.probeBatch = batch;
bake_params.numRays = 32768;
bake_params.numDiffuseSamples = 1024;
bake_params.numBounces = 64;
bake_params.simulatedDuration = 2.0f;
bake_params.savedDuration = 2.0f;
bake_params.order = 2;
bake_params.numThreads = 4;
bake_params.irradianceMinDistance = 1.0f;
iplReflectionsBakerBake(context, &bake_params, nullptr, nullptr);

Using IPL_BAKEDDATAVARIATION_STATICSOURCE/LISTENER with the rest of the parameters unchanged bakes fine and doesn't crash or spew any warnings.
Is the warning itself related to something I'm doing incorrectly or a parameter I'm not specifying? I don't see anything special in the documentation for the reverb variation vs static source/listener.
Thanks

For the record, this is on v4.0.3 of the C API, and since phonon.dll doesn't have debug symbols, I can't provide a meaningful stack trace.

We have just released v4.3.0 (https://github.com/ValveSoftware/steam-audio/releases/tag/v4.3.0), which fixes this issue.


Inline Editing support

Dose django tinymce support inline editing? If not, I think this would be an amazing feature to add.

Sure did you try it already?
Apparently you just need to add the inline: true parameter. (according to the link you sent.)

Closing due to resolved issue.


Entity.getRiding bug

Entity.getRiding always return -1.Please fix it.

I'm sorry .getRiding is working,getRider is not working.


Feat: Adding Animation

Describe the feature
Your landing page already looks fantastic, but incorporating animations on the image used on the landing page could make it even more captivating. With my experience in this area, I'm eager to contribute to this enhancement.
If you could assign me this task under GSSOC24, I would be thrilled to work on it.
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@harshmishra19 assigned, send demo video while creating pr


AppData call takes longer than 5 seconds

RainLoop version, browser, OS:
1.16.0 / Chrome & Curl
Expected behavior and actual behavior:
/?/AppData call takes longer than 5 seconds both on my local installation, as well as in the rainloop-demo
Steps to reproduce the problem:
When loading Rainloop or when changing between multiple accounts request the mentioned call is processed and slows down the usage
Logs or screenshots:
time curl 'https://mail.rainloop.net/?/AppData@no-mobile-0/0/1311346818829715/'   -H 'Connection: keep-alive'   -H 'Pragma: no-cache'   -H 'Cache-Control: no-cache'   -H 'sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="97", "Chromium";v="97"'   -H 'sec-ch-ua-mobile: ?0'   -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36'   -H 'sec-ch-ua-platform: "Windows"'   -H 'Accept: */*'   -H 'Sec-Fetch-Site: same-origin'   -H 'Sec-Fetch-Mode: no-cors'   -H 'Sec-Fetch-Dest: script'   -H 'Referer: https://mail.rainloop.net/'   -H 'Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7'   -H 'Cookie: _ga=GA1.2.75753229.1643485940; _gid=GA1.2.1067139009.1643485940; rltoken=55280dad41c41b63e910ccafd677fbcc; _ga=GA1.3.75753229.1643485940; _gid=GA1.3.1067139009.1643485940; _gat=1'   --silent --output /dev/null

real    0m5.688s
user    0m0.109s
sys     0m0.030s

Yes I also observe this on both of my servers. Seems to even happen to official demo page.
Somehow I assume it could be related to Subscription server on their side. As if you go to Admin Panel -> Licensing

(Keep in mind that this is my wild guess)

it is possible it is actually the same as issue #2160 - on login page, for some reason, there is a curl to http://api.rainloop.net/status/FQDN
as api.rainloop.net seems dead, it incurs a timeout.
The question is why api.rainloop.net is even called at every login. I was not aware, when installing the server that it would make such call to a distant server.
I am not sure to understand clearly the potential privacy issues here.

As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.

it is possible it is actually the same as issue #2160 - on login page, for some reason, there is a curl to http://api.rainloop.net/status/FQDN
as api.rainloop.net seems dead, it incurs a timeout.
The question is why api.rainloop.net is even called at every login. I was not aware, when installing the server that it would make such call to a distant server. I am not sure to understand clearly the potential privacy issues here.

I can confirm it is the same issue.
These requests are related to subscription status verification:

http://api.rainloop.net/status/FQDN - checks the subscription status for FQDN. Expects one of the following responses:

NO - no subscription found
EXPIRED:timestamp - subscription found, valid until timestamp
EXPIRED:1898625600 or EXPIRED:1898625700 - a special case of the previous response, displayed as unlimited subscription

http://api.rainloop.net/activate/FQDN/key - attempts to activate a subscription for FQDN using key.

OK - assumed successful activation
TOO_MANY_CONNECTIONS - assumed failed activation due to rate limit
ERROR:string - assumed failed activation, the reason is specified in string

The first request is sent when accessing both user and admin interface in order to disable premium features when the subscription is expired or had never existed for the FQDN. The latter is sent when subscription key activation is attempted (after passing local checks).
The API is not used for anything else at the moment.

As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.

Or you can use #2148, as the legal status of this code is uncertain, both because of the presence of AGPLv3 LICENSE file in the root of this repository, and #450. Alternatively, switch to something which doesn't have uncertain support status for years.

A thing was missed, TOO_MANY_CONNECTIONS exists for the first request as well..

@yeupou I just realized I did not explain why it is the same issue as #2160, at all.
As you can see here, this function is in Prem provider, and it calls this->Type().
Type function calls $this->Parser($this->Fetcher(false, true)) and gets its result, as you can see here.
In the Fetcher function, you can see the request itself here.
Here you can see the line which defines APP_API_PATH.
So it takes some time until the request times out, and the execution proceeds.

As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.

How did you manage to do that ?
I do not have a license too but I have the timeout as well.

In my case, I decided it was easier to move to snappymail.
Plus, I did not like much finding by accident that servers where pinging a distant server while I never subscribed to anything like this and found nothing in this regards in config.

As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.

How did you manage to do that ? I do not have a license too but I have the timeout as well.

In my case:
-Download community edition from official site
-In previous instalation folder remove everything but the data folder (remember to keep backups of everything)
-Extract index.php and rainloop folder from the downloaded community zip

As a temporary fix I migrated over to community edition, it seems to work fine. As I did not have license im not sure if your branding carries over or not.

How did you manage to do that ? I do not have a license too but I have the timeout as well.

If you are lazy to apply entire #2148, open /rainloop/v/1.16.0/app/libraries/RainLoop/Providers/Prem.php, and replace this code with return 'EXPIRED:1898625600'; if you want to have access to premium feature, or with return 'NO'; if you don't want it.
If you insist on switching to Community edition regardless, you should actually care to search for word "community" in this repository (here), you will notice that the only differences are the absence of Prem.php and different JS files. So you just remove this file and replace the JS files with the ones in Community edition archive.

Missed a few files, here is an actual diff.

Does anyone know how to contact guy other than support@ email ? We paid license $300 less than 2 months ago and now we can't even know if developer is alive or not..

Does anyone know how to contact guy other than support@ email ? We paid license $300 less than 2 months ago and now we can't even know if developer is alive or not..

Treat it as wasted money and don't help copyright holders get more rich. Assuming they are even copyright holders (see issues mentioned earlier).
You should have taken a look at what you are paying for.
IMHO $300 is insane amount for just branding and simple updater, which can be done by another programmer for much cheaper.

( unfortunately snappymail that is a more-or-less rewrite of rainloop has the appdata-stuck problem as well - at least with 2 apaches in a row )


Add basic typings for supported class-level (static) Component properties

This PR addresses a few relatively minor obstacles to using Preact "out of the box" -- i.e., without having to create your own types to handle what are really ecosystem-standard properties -- in a TypeScript project. The obstacles are related to the absence of typings for static (class-level) Component variables, namely displayName and defaultProps.
Obstacle 1:
Suppose that you are writing a higher-order component (HOC) that wraps a Preact Component, and you want to create a reasonable displayName for the HOC on the basis of the wrapped component's displayName. Trying to read the displayName property of the Preact Component results in complaints from the TypeScript compiler that that property does not exist on the type. For example:
function getName(component: typeof preact.Component): string {
    return component.displayName || component.name || 'Component';
}

The compiler complains that displayName does not exist on the type.
Obstacle 2:
If you're writing an ordinary (not higher-order) Preact Component and you want type-checking for ecosystem-standard static properties (displayName and defaultProps), you won't have any. For example:
class SomeComponent extends Component<SomeProps, SomeState> {
    static displayName = { lol: 'wut' };
    // . . .
}

In that case, the compiler will not complain, which is sub-optimal. Likewise:
class SomeComponent extends Component<SomeProps, SomeState> {
    // . . .
}
SomeComponent.displayName = 'SomeComponent';
SomeComponent.defaultProps = { someProp: 'lol' };

Here, the compiler complains that the latter two properties do not exist on the type.
The PR fixes these issues. It validates displayName as a string, if present, and defaultProps as "any", if present (at the moment, anyway; I might prefer changing the type for defaultProps to "object", which is really what's desired, but I'm not sure whether this project wants its type definitions to be supported only by the latest version of TypeScript (2.2); if so, please let me know and I will update the PR!).

Coverage remained the same at 97.695% when pulling 3662d10a508e07cef772b34cd85dfb7260986deb on jmrog:typescript-defaultprops-displayname into 4a4dda91ec9acf7c6b0d8ed80c22b18e5d4d0529 on developit:master.

Thanks for such a detailed and well-explained overview of the change, really helps @jmrog 👍

Coverage remained the same at 97.695% when pulling 187a65cb8fe83ed2e7021a6e967e7f96780ca229 on jmrog:typescript-defaultprops-displayname into de70e6b219db5d97fc9bb82b2ef9250389062732 on developit:master.

LGTM. As an idle thought, I wonder whether it would be possible or make sense to derive Preact's typings from React's typings in future, as opposed to duplicating them - often with subtle differences.

@robertknight certainly seems nicer for maintenance. I wonder how different they are at this point?

IIRC, they are quite different. I had the same thought as @robertknight and did some (albeit brief/cursory) looking at React's typings before this PR (and the one in #576). Making Preact's typings similar to React's would require a decent amount of restructuring of the type declarations (again, IIRC; I haven't looked while writing this comment). It does seem like a sensible goal, though.


New changelog

New HTML5 & CSS3 based changelog. Thoughts?

Do those styles work with GitHub - readme?
or do we have to put the changes in 2 places ?

It's in pure HTML & CSS, unfortunately I don't know if it's compatible with the GitHub repo, since it doesn't render when clicked on. I'll be styling the table with CSS3 in due course, but I just wanted to make sure that the colours, design etc worked before making it more permanent.

Something I have found that might be useful for upgrade detection:
https://github.com/Smurf-IV/Elucidate/commits
and for new releases:
https://www.somsubhra.com/github-release-stats/?username=Smurf-IV&repository=Elucidate
or
https://githubstats0.firebaseapp.com/

What do you think of: https://wagnerp.github.io/Krypton-NET-5.470/?

Nice :-)

Is the need for the Updates directory removed, with the above Link ?
Also the Above link does not display the Icon:

It should be working off README.md. I don't know if the icon needs to be in the root, as at the moment, it's in the Assets\PNG\Square Design directory.

Yes, I don't know why this happens, as all relevant assets are in the root


[WSL 2] No network connectivity after upgrade to 18945

Your Windows build number:  10.0.18945.1001

What you're doing and what's happening:

After upgrading to 18945, I cannot connect to any network locations from inside WSL. While eth0 appears to get an IP address, it is not routable. For example, with this network configuration seen inside WSL:
avatar@athena:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 72:f4:f0:99:f5:ce brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b2:55:25:91:06:1f brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:97:65:1c brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe97:651c/64 scope link
       valid_lft forever preferred_lft forever
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit <IP_ADDRESS> brd <IP_ADDRESS>
avatar@athena:~$ ip r
default via <IP_ADDRESS> dev eth0
<IP_ADDRESS>/16 dev eth0 proto kernel scope link src <IP_ADDRESS>

the only address that can be pinged is the local interface, <IP_ADDRESS>. Pinging the default gateway (<IP_ADDRESS>), the Windows host (<IP_ADDRESS>), a local LAN address (<IP_ADDRESS>), or the Internet (<IP_ADDRESS>) all fail, thus:
avatar@athena:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
From <IP_ADDRESS> icmp_seq=1 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=2 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=3 Destination Host Unreachable
^C
--- <IP_ADDRESS> ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 166ms
pipe 4

What's wrong / what should be happening instead:

All of the above addresses should be reachable.

Further data:

The virtual network addresses for WSL are also unreachable from the Windows host; i.e., from a command prompt, it is impossible to ping either <IP_ADDRESS> or <IP_ADDRESS>.

The "vEthernet (WSL)" adapter on the Windows host seems to have gone missing; no such adapter is showing up in ipconfig.

PS:1899 {ATHENA:avatar} C:\Users\avatar.ARKANE-SYSTEMS#get-vmswitch WSL | fl *

DefaultQueueVmmqQueuePairs                       : 0
DefaultQueueVmmqQueuePairsRequested              : 16
Name                                             : WSL
Id                                               : 5497cb45-d77e-4001-a761-ae05b7dc802e
Notes                                            :
Extensions                                       : {Microsoft Windows Filtering Platform, Windows Defender Application
                                                   Guard Filter Driver, Microsoft Azure VFP Switch Extension,
                                                   Microsoft NDIS Capture}
BandwidthReservationMode                         : Absolute
PacketDirectEnabled                              : False
EmbeddedTeamingEnabled                           : False
IovEnabled                                       : False
SwitchType                                       : Private
AllowManagementOS                                : False
NetAdapterInterfaceDescription                   :
NetAdapterInterfaceDescriptions                  :
NetAdapterInterfaceGuid                          :
IovSupport                                       : False
IovSupportReasons                                :
AvailableIPSecSA                                 : 0
NumberIPSecSAAllocated                           : 0
AvailableVMQueues                                : 0
NumberVmqAllocated                               : 0
IovQueuePairCount                                : 0
IovQueuePairsInUse                               : 0
IovVirtualFunctionCount                          : 0
IovVirtualFunctionsInUse                         : 0
PacketDirectInUse                                : False
DefaultQueueVrssEnabledRequested                 : True
DefaultQueueVrssEnabled                          : False
DefaultQueueVmmqEnabledRequested                 : True
DefaultQueueVmmqEnabled                          : False
DefaultQueueVrssMaxQueuePairsRequested           : 16
DefaultQueueVrssMaxQueuePairs                    : 0
DefaultQueueVrssMinQueuePairsRequested           : 1
DefaultQueueVrssMinQueuePairs                    : 0
DefaultQueueVrssQueueSchedulingModeRequested     : StaticVrss
DefaultQueueVrssQueueSchedulingMode              : Dynamic
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor          : False
SoftwareRscEnabled                               : False
BandwidthPercentage                              : 0
DefaultFlowMinimumBandwidthAbsolute              : 0
DefaultFlowMinimumBandwidthWeight                : 0
CimSession                                       : CimSession: .
ComputerName                                     : ATHENA
IsDeleted                                        : False

Taken together, I think this indicates that something's gone adrift in the virtual switch configuration that WSL uses? Is there any way to recreate that?

(The new localhost feature works great, though!
...I feel this is somehow ironic.)

I just observed this and resolved it: I saw that linux eth0 interface was on <IP_ADDRESS> and wsl host interface was <IP_ADDRESS>.  By running
ifconfig eth0 <IP_ADDRESS> netmask <IP_ADDRESS>
route add default gw <IP_ADDRESS>

networking was restored to my WSL.

Must be a slightly different variation - I don't seem to have a wsl host interface any more. :(
Glad you got it working, though.

I could ping the default gateway, but not outside the host. I worked around it by just uninstalling the distros, then uninstalled the feature. The reinstalled after a reboot and reinstalled the distros. After reboot I got internet connectivity in the distros.

I resolved mine similarly, now, by uninstalling the virtual machine platform and WSL, rebooting, then reinstalling them. (I left the distro in place; it was still there after the reinstall of both of them.) That seemed to fix whatever was up with the config of the WSL virtual switch (it showed as internal again afterwards, and the interface was once again present), and restored networking.

I lose internet connectivity after doing some npm installs and running docker, can't get it to work again.

Looks like sometimes the WSL virtual interface is using a narrower network on the linux side so the default gateway ends up invalid (IINM windows allow a default gateway outside the main interface network but not linux):
$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::215:5dff:fe70:91d2  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:70:91:d2  txqueuelen 1000  (Ethernet)
        RX packets 1892  bytes 285656 (285.6 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 21  bytes 1586 (1.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

On the windows side, the WSL interface was:
PS C:\Users\paulos> ipconfig
...
Ethernet adapter vEthernet (WSL):

  Connection-specific DNS Suffix  .  :
...

I think the problem is that the default gateway on the linux side should be <IP_ADDRESS> but since it is outside the <IP_ADDRESS>/24 network the WSL instance ends up without a default gateway.
If I change the netmask to <IP_ADDRESS> and add the windows IP as default gateway on the linux side too, voila! problem fixed:
$ sudo ifconfig eth0 <IP_ADDRESS> netmask <IP_ADDRESS>
$ sudo route add default gw <IP_ADDRESS>

This is a dupe of https://github.com/Microsoft/WSL/issues/3438

I got internet working after setting gateway and subnetmask, randomly then it'd stop again..
After changing the /etc/resolv.conf from the previous nameserver to
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>

and doing:
netsh int ip reset all
netsh winhttp reset proxy
ipconfig /flushdns```

it worked again... very strange, got those commands from the feature @pauloscardine mentioned

Build 18970 has some fixes in this area, if you are continuing to see issues after this build please open a new issue.

it occured in 19008.1

LxssManager creates an inbound rule for DNS traffic for WSL2 VM. Check if the Windows Firewall has that rule.

I stopped my antivirus Fireball and Network started working

I just observed this and resolved it: I saw that linux eth0 interface was on <IP_ADDRESS> and wsl host interface was <IP_ADDRESS>. By running
ifconfig eth0 <IP_ADDRESS> netmask <IP_ADDRESS>
route add default gw <IP_ADDRESS>

networking was restored to my WSL.

i was able to fix the problem by changing the resolve.conf file and some netsh commands. But this seemed way better and more accurate (and it worked for me)

I also see this issue currently (happened after taking the most recent security update on Windows), and it's strange and unhelpful that this thread drifted immediately to restoring internet by referencing the vEthernet (WSL) adapter.
vEthernet (WSL) adapter is missing on the Windows side. There is nothing to reference and no amount of WSL routing will fix it.
This happened to me a few months ago also, and the only way I could get the vEthernet (WSL) adapter to reappear was uninstall, disable, restart, reinstall WSL as suggested in previous posts. Otherwise, there's nothing helpful in this thread and this is still an outstanding bug.
If you can see your vEthernet (WSL) adapter in windows' ipconfig, then here is your thread:
https://github.com/microsoft/WSL/issues/4275
(and please don't post here)

Another Windows Update, another missing vEthernet (WSL) Adapter..... six weeks later

I'm facing the same issue as @andymule at the moment. I'm on OS build 20211.1000, which is the latest one from the dev channel.

ipconfig lists the WSL adapter as disconnected

the control panel "Network Connections" doesn't list it at all

Hyper-V manager doesn't list any machine at all, and doesn't even have actions such as "new VM", which is really weird

(may be a duplicate of https://github.com/microsoft/WSL/issues/4810)

Same, no WSL adapter after an upgrade to 10.0.19041.450.
Two "Wireless LAN adapters" have appeared in the ipconfig output though, none is connected, but one has the same MAC as the physical WiFi iface.
    : No

Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  .   : No
   Autoconfiguration Enabled . . . .   : Enabled

Ethernet adapter external:

   Connection-specific DNS Suffix  .   : No
   Autoconfiguration Enabled . . . .   : Media disconnected
   Connection-specific DNS Suffix  .   : Yes
   Autoconfiguration Enabled . . . .  : Media disconnected
   Connection-specific DNS Suffix  .   : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter WiFi:

   Connection-specific DNS Suffix  .   : Yes
   Autoconfiguration Enabled . . . .  : Disabled

C:\>

Microsoft has an outstanding reputation of closing non-resolved issue.
Looks like the WSL distro IP address and netmask are hardcoded somewhere, and they won't change when you modify the settings in the Windows host adapter.
In adapter settings, enable DHCP:

Shutdown WSL and restart the vEthernet adapter from an elevated Powershell:
wsl --shutdown
Restart-NetAdapter "vEthernet (WSL)"

On the Windows host, my WSL adapter has been assigned this non-routable APIPA address that I cannot seem to change:
Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  .  :

Open WSL and run the following command:
ip addr show dev eth0

Here is my output:
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:8f:b3:c5 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/20 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe8f:b3c5/64 scope link
       valid_lft forever preferred_lft forever

For some reasons, the range <IP_ADDRESS>/20 is hardcoded somewhere and WSL randomly chooses an IP from that range at startup.
Also, no Internet access from/to your WSL distro, since the NAT adapter is actually built-in into the WSL vEthernet adapter and configuration is hidden.

Was running WSL1 with no issues. Updated to WSL 2 using set version command broke things... DNS was working with 1, broken with 2.  Suggestion to set a manual DNS rather than using the host worked.


Throw an error if using Relative across forks

Github's review model does not allow the base branch
to live in another fork, making it impossible to use
the relative review model. Disable it with a clear
warning.
Reviewers: greg-b, brian-k

#
head
base
diff
date
summary

0
6b9839f1
343d289d
diff
Sep 15 1:58 PM
2 files changed, 11 insertions(+)

Reviews in this chain:
└https://github.com/Skydio/revup/pull/43 Throw an error if using Relative across forks


use global var to prevent autotrack editor from loading more than once

this is usually a singleton instance but if a website uses a modular version of Mixpanel it doesn't have to be and the autotrack editor can get loaded twice. This PR uses window to ensure a singleton instance.

Noooooo! Global?


Add support non strict update and checks

Fixes #42

Codecov Report

Merging #43 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #43   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           10        10
  Lines          271       268    -3
=========================================
- Hits           271       268    -3

Impacted Files
Coverage Δ

cruft/_cli.py
100.00% <100.00%> (ø)

cruft/_commands/check.py
100.00% <100.00%> (ø)

cruft/_commands/update.py
100.00% <100.00%> (ø)

cruft/_commands/utils.py
100.00% <100.00%> (ø)

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 1b39244...d0d2cd0. Read the comment docs.

@timothycrosley can you also release this version once you merge this?

@timothycrosley can you also release 2.1 once you merge this?


docs: minor typos

What is it?

[ ] Feature / enhancement
[ ] Bug
[x] Docs / tests

Description
solves #3552
Use cases and why

One use case

Another use case

Checklist:

[ ] My code follows the developer guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] Added new tests to cover the fix / functionality

thank you very much!


move https://github.com/joyent/node-http-signature/blob/master/lib/util.js into it's own module?

Hi, would you consider moving ./lib/util.js into it's own module?
this is quite useful on it's own, independently of http-signature.
Moving it out will make more discoverable (more searches for convert SSH key to PEM will hit it) and modules that need that will be able to use that directly,
and won't have to review unrelated changes in http-signature.
If this was something else, i'd be inclined to refactor and republish this myself, but obviously the security of this particular module is much more important and It's not worth creating a fork just for the sake of a architectural style issue.

Just FYI, we went and made a version of this with a different API so that we could start getting rid of some copy-paste adaptations of this code which have made their way into other modules as well. The new version also supports ECDSA keys (though http-signature doesn't just yet), and a bunch of other useful features -- see https://github.com/arekinath/node-sshpk for more info about it if you're curious.
The functions in util.js have now been replaced with thin wrappers around this API, so I'm gonna mark this issue as closed. Thanks for your time looking at this!


[Feature] Be able to select option with Return key

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: https://github.com/reaviz/reaselct/issues/3
What is the new behavior?
Now user will be able to select option with return key
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information

released!

@faizanu94  I think this caused a regression with tagging.

@amcdnl yeah I just saw a fix you merged with createable flag used


RUSTC_WRAPPER is ignored for rustc -vV call

Problem
We are setting RUSTC_WRAPPER in order to intercept every invocation of rustc from cargo. However, it looks like cargo will call rustc -vV in any case, completely bypassing the RUSTC_WRAPPER env var. Only the RUSTC env var seems to be honored for the -vV call. This is causing us a bunch of pain right now since we need to figure out how to best intercept this -vV call.
The docs describe both RUSTC and RUSTC_WRAPPER in very similar terms, so I think this is clearly a bug -- both env vars should be effective for the same invocations.
We prefer to use RUSTC_WRAPPER over RUSTC because we need to intercept all things that cargo calls (including rustdoc, and running the actual binaries), and RUSTC_WRAPPER makes it easier to figure out what cargo called us for -- if we are invoked with the first argument being rustc, we know it was rustc that cargo wanted. (This is in the cargo-miri wrapper.)

The current behavior is annoying for both Miri and bootstrap, and probably other tools -- everyone has to overwrite both RUSTC_WRAPPER and RUSTC, which is quite surprising. At least in the case of Miri it is also fragile: what I'd like to do is set RUSTC to /cargo-miri-phase-rustc/if-you-see-this-some-build-script-forgot-to-apply-the-rustc-wrapper or something like that, so that when we get invoked as the wrapper we can easily tell that this is what happens. But of course that doesn't work because cargo then calls the non-existing wrapper. This means we have to use a less reliable technique to detect when we are the wrapper. It also means we can't outright error when something invokes RUSTC without the wrapper, even though that is almost always a bug -- it is absolutely crucial that the wrapper is applied so that it can adjust the command-line arguments accordingly.
@ehuss this was previously attempted in https://github.com/rust-lang/cargo/pull/10887, but unfortunately rejected because more testing was requested. So it seems like passing the cargo test suite is not sufficient. I have never used sccache, so I don't even know what "using sccache" looks like, let alone testing it sufficiently. Is there documentation of what you think should be done? Is it sufficient to pass rustc bootstrap, or does that not use sccache? sccache is mentioned in src/ci, for whatever that is worth.
It seems hard for me to imagine that a wrapper would work with $WRAPPER rustc --print sysroot (which is wrapped!) but not with $WRAPPER rustc -vV. So I don't quite understand why you think this is so risky.

To test with sccache, I would recommend going to https://github.com/mozilla/sccache and reading the instructions. You just need to install the sccache binary (cargo install sccache usually works), and that page also explains how to set RUSTC_WRAPPER to wherever you installed it. Then, just go try building a few projects with a cargo including the change from #10887 and make sure it still works, and the caching works.
rustc does not directly use sccache for building Rust code, it is only used for caching the llvm build. I think some people use it for local development, and I believe all you have to do is set RUSTC_WRAPPER.
The concern is that sccache parses the rustc command-line, and there have been several instances in the past where small changes of the options have broken sccache. It probably works, but it is worth checking.

FWIW bootstrap also has trouble with this.

Copying over from https://github.com/rust-lang/cargo/issues/14385#issuecomment-2297167054

As described here (but admittedly without going into much detail), the end users I am concerned about are rustc bootstrap and cargo-miri. They both set RUSTC_WRAPPER. rustc bootstrap uses the wrapper to decide which stage's compiler to invoke. Things would obviously go quite wrong if cargo got the wrong rustc version here. To achieve that, bootstrap currently sets both the RUSTC and RUSTC_WRAPPER env vars, but that then requires awkward hacks in the rustc binary that it uses for both of those env vars because the binary has to auto-detect whether it got invoked as $RUSTC or as $RUSTC_WRAPPER $RUSTC. That hack also got linked in the issue I referenced above. cargo-miri has similar hacks. (Sadly Miri will likely have to keep these hacks forever as there are too many build scripts out there that invoke rustc without accounting for the wrapper. But that is no excuse for cargo itself to do this incorrectly, and rustc bootstrap may get away with dropping the hack since it more tightly controls which crates it is run on.)


Display errors correctly on Unauthenticated-Status

These types of error shouldn't normally appear if the AuthProxy is configured correctly. However, if it happens this improves the error messaging when in an ErrorBoundary or CurrentUserProvider (which normally is the outermost component which calls the API).
Also throw the correct Exception in the CometGuard and append the underlying error message (though don't show it to the user as like mentioned before this normally should not happen).

@fraxachun please resolve conflicts, thanks!