Data races: there is wrong memory order in refcount.h

here should be release instead of relaxed:
https://github.com/openssl/openssl/blob/6afaa3f41f5b65432b6700064b077032b9e0c625/include/internal/refcount.h#L51

Example of issue: https://github.com/ClickHouse/openssl/commit/10e427ee32cf74bc2d1e4945c57e3d518c737e12
But tsan doesn't work with such fences, so for tsan (or always, there is almost no difference in asm) needed acq_rel and fence no needed

here should be acquire because openssl using it to compare res with zero:
https://github.com/openssl/openssl/blob/6afaa3f41f5b65432b6700064b077032b9e0c625/include/internal/refcount.h#L59

Some explanation:

Trivial: If someone using acquire they also should write release somewhere
Examples: boost::smart_ptr and llvm libc++
More formal

here should be release instead of relaxed:
https://github.com/openssl/openssl/blob/6afaa3f41f5b65432b6700064b077032b9e0c625/include/internal/refcount.h#L51

Example of issue: ClickHouse@10e427e
But tsan doesn't work with such fences, so for tsan (or always, there is almost no difference in asm) needed acq_rel and fence no needed
2. here should be `acquire` because openssl using it to compare `res` with zero:
   https://github.com/openssl/openssl/blob/6afaa3f41f5b65432b6700064b077032b9e0c625/include/internal/refcount.h#L59

Some explanation:
1. Trivial: If someone using `acquire` they also should write `release` somewhere

2. Examples: [boost::smart_ptr](https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp#L43) and [llvm libc++](https://github.com/llvm/llvm-project/blob/main/libcxx/include/__memory/shared_ptr.h#L111)

3. [More formal](https://www.boost.org/doc/libs/1_86_0/libs/atomic/doc/html/atomic/usage_examples.html#boost_atomic.usage_examples.example_reference_counters)

Have you read the comment above the CRYPTO_DOWN_REF() function and the reasoning in https://github.com/openssl/openssl/pull/6900 ?

If they are observing TSAN errors with the current code it might mean they are not using the refcounted objects correctly. I.e., once you start using an object across multiple threads, it MUST never reach 0 concurrently. What would be the semantics otherwise? Once it reaches 0, the object is released -> the other concurrent threads will encounter UAF at that point if they use the object.

here should be release instead of relaxed:
https://github.com/openssl/openssl/blob/6afaa3f41f5b65432b6700064b077032b9e0c625/include/internal/refcount.h#L51

Example of issue: ClickHouse@10e427e
But tsan doesn't work with such fences, so for tsan (or always, there is almost no difference in asm) needed acq_rel and fence no needed
2. here should be `acquire` because openssl using it to compare `res` with zero:
   https://github.com/openssl/openssl/blob/6afaa3f41f5b65432b6700064b077032b9e0c625/include/internal/refcount.h#L59

Some explanation:
1. Trivial: If someone using `acquire` they also should write `release` somewhere

2. Examples: [boost::smart_ptr](https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp#L43) and [llvm libc++](https://github.com/llvm/llvm-project/blob/main/libcxx/include/__memory/shared_ptr.h#L111)

3. [More formal](https://www.boost.org/doc/libs/1_86_0/libs/atomic/doc/html/atomic/usage_examples.html#boost_atomic.usage_examples.example_reference_counters)

Have you read the comment above the CRYPTO_DOWN_REF() function and the reasoning in #6900 ?

ofc, it's wrong unfortunately :(

In any case, I don't want to convince anyone that I'm right.
Personally, I use the patch for these lines because it fixes tsan's errors.
I just thought it was a random bug, so I decided to report it.
If it was done intentionally, I don't have desire to convince anyone that it's wrong.

The problem is these tsan errors might indicate a bug in how Poco uses OpenSSL.

What would be the semantics otherwise?

one thread:
create object -- rc1
copy object -- rc2
start other thread
move copy of object to other thread
main thread and other thread destroy their copies of object at the same time.

So it's concurrently reaches zero.
The semantics same as std::shared_ptr (strong reference) or any other reference counters

The problem is these tsan errors might indicate a bug in how Poco uses OpenSSL.

Ok whatever.
Let's believe that everyone (rust std lib, boost, llvm libc++, etc) wrong and only openssl devs right and understand memory model

@MBkkt Thanks for pointing this out.

What I think he's saying is that for the acquire to work when reaching 0, there must be a release in another thread, otherwise it's not actually doing anything. I think we ran into this same issue before with the lru code.

@MBkkt  I think there is a fundamental misunderstanding of the semantics of CRYPTO_UP_REF/CRYPTO_DOWN_REF here.
I had a hard time understanding this as well when I first looks at this issue.  The fundamental issue is, when can there be a parallel increment and decrement when a refcount on an object is at 1.  The answer is that it can't, by virtue of usage requirements.
If you have two threads, A and B, sharing an object Z which has a refcount of 1, then it is in fact entirely possible for A to do a decrement of the refcount on Z, while B does an increment of the refcount of Z, the result of which may well be that A will free the object while B thinks it has a reference to it, leading to an invalid memory deference later in the code path of B.  No amount of memory ordering will correct this, because this is a misuse of the api, because, by definition this scenario means that B was referencing object Z without first holding a reference count to it.
The semantics of the reference count api mandate that prior to any sharing between threads, a reference count must be held by both threads to prevent exactly the above scenario.  That is to say, prior to A sharing object Z with B, A must increment the refcount on B's behalf (so that at the time sharing begins, the reference count of Z is at least 2).  This prevents parallel increments and decrements between threads when the refcount is at 1.
This same requirement holds in the boost library that you referenced above.  From the discussion section here:
https://www.boost.org/doc/libs/1_86_0/libs/atomic/doc/html/atomic/usage_examples.html#boost_atomic.usage_examples.example_reference_counters
Increasing the reference counter can always be done with memory_order_relaxed: New references to an object can only be formed from an existing reference, and passing an existing reference from one thread to another must already provide any required synchronization.

Quoting your example above:

one thread:
create object -- rc1
copy object -- rc2
start other thread
move copy of object to other thread
main thread and other thread destroy their copies of object at the same time.
So it's concurrently reaches zero.
The semantics same as std::shared_ptr (strong reference) or any other reference counters

Assuming that one thread (lets call it A) creates rc1, and then copies the object to rc2
If we assume that rc2 points to rc1 with an increased ref count (i.e. a minimum of 2 now), then, when rc2 is given to another thread (call it B), both threads can independently decrement the refcount, but the return value should be unique to each, i.e. the first thread will decrement to 1, while the second thread will decrement to zero, and everything is ok.
Whats more likely to happen here (on weak memory ordered systems, like arm), is that the decrement from the first thread may not be "seen" by the second thread in time, and both will decrement from 2 -> 1, leading to leaked memory, as neither thread will free the object.
But thats not whats happening in the error you posted here.  You're getting a very clear crash on a NULL pointer deference, which suggests one thread is decrementing to 0 while the other thread is still using the object.  This suggests that in the copy object operation to rc2 above, that the reference count isn't being incremented at all, as per the previously stated required semantics.
I'll be the first to admit, that the C++ code in Clickhouse is pretty dense, and I find it hard to follow, but looking at the EVPPKey implementation in that code, I don't see any reference to EVP_PKEY_up_ref.  This suggests that any sharing of EVP_PKEY objects between Clickhouse classes is being handled by some other method external to the openssl library.  Can you elaborate on how Clickhouse, when sharing EVP_PKEY objects between threads, handles reference counting?

@nhorman
About memory_orders:

The fundamental issue is, when can there be a parallel increment and decrement when a refcount on an object is at 1. The answer is that it can't, by virtue of usage requirements.

Ofc it can't, you're completely right about this.
And it's the same as for other reference counters that I mentioned, it's common, nothing unique and special.
But imagine you have two threads both owning their own reference of resource.
So the reference counter is 2.
In such a case imagine both of them destroying objects in the "same" time.
So we need some "hb" for decrements(!), but not for increments (that is why increment relaxed is enough!).
For tsan such code is needed: fetch_sub(1, acq_rel), because tsan doesn't work for fence(acquire) or fence(release).
In general, in terms of real instructions, enough is if (fetch_sub(1, release) - 1 == 0) { fence(acquire).
In terms of memory order we want to hb between the last decrement and every decrement before it.
In terms of compiler and processor we don't want some load/store from free call will be executed before last decrement (that's why acquire needed), and we don't want someload/store will be executed after non-last decrement (that's why release needed).
Well simplified it's same as trivial spinlock
lock (acquire)
// instructions here cannot be executed early
...
// instructions here cannot be executed later
unlock(release)

same for counter https://godbolt.org/z/Tbxj1cP85
About clichouse tsan stacktrace
So for clickhouse if you will look in their stacktrace you will see tsan report datarace between:

access to the object in decrement before last decrement

#0 CRYPTO_DOWN_REF build_docker/./contrib/openssl/include/internal/refcount.h:51:12
#1 EVP_PKEY_free build_docker/./contrib/openssl/crypto/evp/p_lib.c:1795:5

access to the object in free after last decrement

#1 CRYPTO_free build_docker/./contrib/openssl/crypto/mem.c:282:5
#2 EVP_PKEY_free build_docker/./contrib/openssl/crypto/evp/p_lib.c:1809:5

It's because there is no "hb" relation between this events
Another bug that I noticed :(
It's probably debug only (I don't think this printf really used in production).
In this line, object accessed in C code after decrement!
https://github.com/openssl/openssl/blob/b2474b287fbc7a24f0aa15e6808c6e3ef8287f23/crypto/evp/p_lib.c#L1795
So what can happen (in serialized view on parallel execution):

thread_1: decrement counter: 2 => 1
thread_2: decrement counter: 1 => 0
thread_2: destroy object
thread_1: executes this line REF_PRINT_COUNT("EVP_PKEY", x);
so data race between 3 and 4 even if we will write seq_cst everywhere

So my understanding of what tsan reports is:
T1: decrement counter atomic
T2: decrement counter atomic
T2: call free, writing to the location of the counter, non-atomic, and 8 bytes instead of 4.
It seems to me that the T2 decrement happens before the other write that free does, writes to the same location in the same thread can not change order. So I currently don't see an issue, there is a happens before relation.

@kroeckx

T1: decrement counter atomic

this should happens before this

T2: call free, writing to the location of the counter, non-atomic, and 8 bytes instead of 4.

Otherwise will be data race, that tsan reports.
Important here that happening before doesn't Imply happens-before (https://preshing.com/20130702/the-happens-before-relation)
So one way to achieve this happens-before it's make release for all decrements, and acquire for last read before destroy.
This is exactly examples and references that I provided.

(1) happened before (2)
(2) Happens before (3)
You're right that there is no happens before between (1) and either (2) or (3). So there is a theoretic problem. But as far as I know, for there to be a practical one, some other write/read needs to be there that can be reordered.
In theory, T1 could have modified the struct, and then have done a release before the decrement. But T2 should not read that.

To clarify, for the other elements we have a release+acquire. The other writes need to have an happens before the free call.

To summarize, I think there are 2 cases:

Only the refcounter is changed:
a. T1: decrease the refounter
b. T2: decrease the refcounter (happened after a)
c. T2: acquire fence (doesn't do anything useful)
d: T2: free (happens after b and c)
Other members of the struct are also changed
a. T1: acquire a lock
b. T1: do read and/or writes
c. T1: release the lock
d. T1: decrease the refcounter (happens after c)
e: T2: decrease the refcounter (happened after d)
f: T2: acquire fence (happens after c and e)
g: T2: call free (happens after f)

Case 1 has a theoretic problem and is reported by TSAN, but I see no actual problem. If there are actual other writes that could be reordered, it would be in case 2, step b, and the proper acquire/release constraints are there.

@kroeckx
First of all, even if it's theoretic only issue, I think it should be fixed if it doesn't affect perf (it doesn't).
Secondly, how you can guarantee that all use cases fallen in 2-case? I tried fast grep and found a lof of different (in quick look) usecases.
Also I don't think you're analysis correct in terms of memory model.
I understand what did you mean: b -- release, f -- acquire, everyone happy.
But it's not clear how "release the lock" itself and its interaction with "acquire fence" is specified.
And the last I don't think it's worth relying on "release lock" will compile on non-x86 to something like
// ... some asm
// release barrier

@kroeckx I think the order of operations in the bug @MBkkt described here is like this in the problematic case:
Reference pseudo code from EVP_PKEY_free:
result = CRYPTO_down_ref(count);
PRINT_REF_COUNT(count);
if (result  > 0)
   return;
REF_ASSERT_ISNT(i < 0);
evp_pkey_free_it(obj_with_zero_count);
CRYPTO_free_ref(count);

CPU 0
CPU1

CRYPTO_down_ref [returns 1]
CRYPTO_down_ref [returns 0]

(gets pre-empted by irq)
PRINT_REF_COUNT (dereferences count)

--
if (result > 0) [ false]

--
REF_ASSERT_ISNT

--
evp_pkey_free_it

--
CRYPTO_free_ref(count)

(returns to cpu)
--

PRINT_REF_COUNT(count)
--

In the above situation (completely independently of any fencing/memory ordering issues), we have a situation in this specific piece of code, in which a thread drops its ref count, and then assumes it still has access to the memory pointed to by the refcounted object, which is invalid.
Its not something we're likely to hit, as the scheduler timing has to be just right, but it is a bug, in that the only time a holder of the refcount may continue to dereference  a refcounted object after dropping its own count, is if its the thread which did the last decrement to zero.  In that case that thread is guaranteed to be the only remaining owner of that object.  Any other thread that decrements to a non-zero value may not make any further references to the counted object, or it risks a use after free scenario.
searching for usages of REF_PRINT_COUNT, its a recurring pattern in which we decrement and then print the count, which is wrong.  On increments its ok, because the calling thread must own a count on the object, but on decrement the print must either be done before the decrement.

@nhorman It's true, but as I wrote it's different bug.
This issue about memory order, not about incorrect usage ref print count

Another bug that I noticed :(

right, I get that, was just trying to draw a distinction between the two.
As for the initial problem you reported
In looking at your description:
But imagine you have two threads both owning their own reference of resource.
So the reference counter is 2.
In such a case imagine both of them destroying objects in the "same" time.
So we need some "hb" for decrements(!), but not for increments (that is why increment relaxed is enough!).

In that scenario I imagine a few possible outcomes:

Thread a decrements to 1, then thread b decrements to 0, thread b frees the object
This is the good/expected scenario

Thread a and b decrement at the same time running on an strongly memory ordered system (ie intel), someone wins, one thread gets a return value of 1 the other 0, everything works ok.

Thread a and b decrement at the same time running on a weakly memory ordered system (ie arm), both atomic operation read the value 2 from the shared memory location, decrement to one, no one frees the memory and we get a leak

What I don't think can happen is a double free scenario.  As in the event that either thread saw the publication of the other threads decrement, we fall into scenario (1).
Unless theres something I missed, the only concerning scenario here is scenario (3), in which on a weakly memory ordered system any given cpu might atomically update a variable, but won't write that back to the shared location until some arbitrary time later, for which you do need synchronization.  Which...yeah, as I write this, does seem to be a bug
From cppreference
Atomic-fence synchronization
An atomic release operation X in thread A synchronizes-with an acquire fence F in thread B, if

* there exists an atomic read Y (with any memory order),
* Y reads the value written by X (or by the release sequence headed by X),
* Y is sequenced-before F in thread B.
* In this case, all non-atomic and relaxed atomic stores that are sequenced-before X in thread A will happen-before all non-atomic and relaxed atomic loads from the same locations made in thread B after F.

For the above description, we have an acquire fence, which would synchronize and subsequent reads of the refcount, but only actually does any synchronization if the the executing thread gets a 0 counter return value, which by definition means no other thread should ever be reading this value.
This begs the question though: Why aren't we seeing a problem here?  Setting aside the tsan error for the moment (as described above, tsan doesn't understand fencing), I would expect that on weakly memory ordered systems, we would see lots of scenario (3) above, in which multiple threads decrement in close time proximity, we should see missed decrements, and leaked memory, but we don't.
I did some investigation of something similar for our rcu assign/deref code here, and the patch fixed the problem (in that case for mac M1 cpus).  I wonder if the construction of the atomic operations for the refcount properly resolves to the ldapr instruction on arm systems, ensuring intel-like strict memory ordering, avoiding the issue

The debug print off the reference count is clearly wrong.

So I was re-reading the part about fencing, and synchronize-with earlier today. And things aren't really clear to me yet.
I read that you can replace a write-release with atomic relaxed write+release fence, and read-acquire with acquire fence+atomic relaxed read.
The synchronize-with would be about an atomic (guard) variable that you write in 1 thread, read in the other, and where you just release+acquire in some way around that variable.
Then I also find text saying that a fence is more strict than write-release and read-acquire, but can't actually find such text in the standard, but also didn't have time to properly look.
We don't seem to have anything that actually matches what the standard says, as far as I can see. But implementations probably do what we want them to do, and actually stop the reorder.

So after re-reading things, a "synchronizes with" is all about 1 thread writes it, the other reads it. After the acquire fence we don't read anything anymore, so at least for the C standard there is no "synchronizes with". It does not say anything about reordering, that's an implementation detail for the C standard. But I can't see a way that the acquire fence doesn't do what we want it to do.

@kroeckx in regards to your comment above, I'm not sure its actually a re-ordering issue at all.  To reference the CRYPTO_DOWN_REF code:
static __inline__ int CRYPTO_DOWN_REF(CRYPTO_REF_COUNT *refcnt, int *ret)
{
    *ret = __atomic_fetch_sub(&refcnt->val, 1, __ATOMIC_RELAXED) - 1;
    if (*ret == 0)
        __atomic_thread_fence(__ATOMIC_ACQUIRE);
    return 1;
}

In the scenario in which two threads A and B are both executing this code at or near the same point in time, with a reference count of 2, one of two things will happen:

The __atomic_fetch_sub operation will be strongly ordered, one operation will happen definitively before the other, and the one that happens second sees the result of the first leading to an ordered decrement to zero.

The __atomic_fetch_sub operation will be weakly ordered, both operations may actually occur in parallel without seeing the result of each other, and we wind up with 2 independent decrements from 2 to 1

In case 1, everything works as you might expect.  This is the case on intel platforms which enforce ordering across cpus.  In this case the __atomic_fetch_sub in one thread sees the result of the __atomic_fetch_sub in the other thread (regardless of the order chosen), and one of the threads decrements to zero, and frees the object.  Thats what we expect.
In case 2, we have a (potential) problem.  On weakly ordered systems like arm the following might happen:

The atomic operations are still atomic with respect to each individual cpu, but because the memory writes are weakly ordered, its entirely possible for two threads running on two cpus to read the same value from main memory, resulting in two decrements from 2->1 rather than one from 2->1 and another from 1->0.
The __atomic_thread_fence operation is a no-op  on intel systems, because the hardware enforces atomic updates between cpus, but on weakly ordered system, the fence is supposed to enforce that through a software instruction, but its irrelevant because neither thread ever sees a zero value (they both compute a decrement from 2->1), so no fencing happens, i.e. the sub/fetch operation has already read from main memory and computed an incorrect result in one of the two threads.
Whats ostensibly needed here is for the fence to occur as part of the __atomic_sub_fetch (i.e. the relaxed memory ordering should actually be a release, or perhaps even an aquire/release, since __atomic_fetch_sub is a read/modify/write operation), to ensure that any one thread always sees the result of another threads actions.  This is the happens before constraint I think @MBkkt is referring to.
There is, I think perhaps a saving grace though (maybe).  If arm systems translate atomic read/modify_write operations into the "right" set of assembly instruction (which enforce strongly ordered semantics) then the fence becomes irrelevant, much like it does on intel platforms.
So the question in my mind is, does this happen on arm?  I'm building openssl for an arm system now to check.  If it does, then it seems to be a non-issue.  If it doesn't, then we probably need to update __ATOMIC_RELAXED to __ATOMIC_RELEASE or __ATOMIC_ACQ_REL to be correct.

https://stackoverflow.com/questions/52336790/is-a-relaxed-atomic-counter-safe

I see what that is saying, but I can't seem to reconcile it with what the compiler produces.  on aarch64, CRYPTO_UP_REF emits this:
static inline int CRYPTO_DOWN_REF(CRYPTO_REF_COUNT *refcnt, int *ret)
{
   fe608:       a9be7bfd        stp     x29, x30, [sp, #-32]!
   fe60c:       910003fd        mov     x29, sp
   fe610:       f9000fe0        str     x0, [sp, #24]
   fe614:       f9000be1        str     x1, [sp, #16]
    *ret = atomic_fetch_sub_explicit(&refcnt->val, 1, memory_order_relaxed) - 1;
   fe618:       f9400fe1        ldr     x1, [sp, #24]
   fe61c:       52800020        mov     w0, #0x1                        // #1
   fe620:       4b0003e0        neg     w0, w0
   fe624:       940c04df        bl      3ff9a0 <__aarch64_ldadd4_relax>
   fe628:       51000401        sub     w1, w0, #0x1
   fe62c:       f9400be0        ldr     x0, [sp, #16]
   fe630:       b9000001        str     w1, [x0]
    if (*ret == 0)
   fe634:       f9400be0        ldr     x0, [sp, #16]
   fe638:       b9400000        ldr     w0, [x0]
   fe63c:       7100001f        cmp     w0, #0x0
   fe640:       54000041        b.ne    fe648 <CRYPTO_DOWN_REF+0x40>  // b.any
        atomic_thread_fence(memory_order_acquire);
   fe644:       d50339bf        dmb     ishld
    return 1;
   fe648:       52800020        mov     w0, #0x1                        // #1
}

Which uses the builtin __aarch64_ldadd4_relax to do the read/modify/write.  That assembly looks like this:
<PHONE_NUMBER>3ff9a0 <__aarch64_ldadd4_relax>:
  3ff9a0:       d503245f        bti     c
  3ff9a4:       f0000fb0        adrp    x16, 5f6000 <exported_ciphers+0x2f0>
  3ff9a8:       397ab210        ldrb    w16, [x16, #3756]
  3ff9ac:       34000070        cbz     w16, 3ff9b8 <__aarch64_ldadd4_relax+0x18>
  3ff9b0:       b8200020        ldadd   w0, w0, [x1]
  3ff9b4:       d65f03c0        ret
  3ff9b8:       2a0003f0        mov     w16, w0
  3ff9bc:       885f7c20        ldxr    w0, [x1]
  3ff9c0:       0b100011        add     w17, w0, w16
  3ff9c4:       880f7c31        stxr    w15, w17, [x1]
  3ff9c8:       35ffffaf        cbnz    w15, 3ff9bc <__aarch64_ldadd4_relax+0x1c>
  3ff9cc:       d65f03c0        ret

The concern here is the use of the ldxr and stxr instructions, which according to this:
https://developer.arm.com/documentation/ddi0602/2024-09/Base-Instructions/LDXR--Load-exclusive-register-?lang=en
Produces sequentially consistent reads and writes, which is good, but says nothing about the ordering with other cpus
changing the memory order to __ATOMIC_ACQ_REL and rebuilding produces this:
static inline int CRYPTO_DOWN_REF(CRYPTO_REF_COUNT *refcnt, int *ret)
{
   fe608:       a9be7bfd        stp     x29, x30, [sp, #-32]!
   fe60c:       910003fd        mov     x29, sp
   fe610:       f9000fe0        str     x0, [sp, #24]
   fe614:       f9000be1        str     x1, [sp, #16]
    *ret = atomic_fetch_sub_explicit(&refcnt->val, 1, __ATOMIC_ACQ_REL) - 1;
   fe618:       f9400fe1        ldr     x1, [sp, #24]
   fe61c:       52800020        mov     w0, #0x1                        // #1
   fe620:       4b0003e0        neg     w0, w0
   fe624:       940c050f        bl      3ffa60 <__aarch64_ldadd4_acq_rel>
   fe628:       51000401        sub     w1, w0, #0x1
   fe62c:       f9400be0        ldr     x0, [sp, #16]
   fe630:       b9000001        str     w1, [x0]
    if (*ret == 0)
   fe634:       f9400be0        ldr     x0, [sp, #16]
   fe638:       b9400000        ldr     w0, [x0]
   fe63c:       7100001f        cmp     w0, #0x0
   fe640:       54000041        b.ne    fe648 <CRYPTO_DOWN_REF+0x40>  // b.any
        atomic_thread_fence(memory_order_acquire);
   fe644:       d50339bf        dmb     ishld
    return 1;
   fe648:       52800020        mov     w0, #0x1                        // #1
}

with the only difference being the use of __aarch64_ldadd4_acq_rel:
00000000003ffa60 <__aarch64_ldadd4_acq_rel>:
  3ffa60:       d503245f        bti     c
  3ffa64:       f0000fb0        adrp    x16, 5f6000 <exported_ciphers+0x2f0>
  3ffa68:       397ab210        ldrb    w16, [x16, #3756]
  3ffa6c:       34000070        cbz     w16, 3ffa78 <__aarch64_ldadd4_acq_rel+0x18>
  3ffa70:       b8e00020        ldaddal w0, w0, [x1]
  3ffa74:       d65f03c0        ret
  3ffa78:       2a0003f0        mov     w16, w0
  3ffa7c:       885ffc20        ldaxr   w0, [x1]
  3ffa80:       0b100011        add     w17, w0, w16
  3ffa84:       880ffc31        stlxr   w15, w17, [x1]
  3ffa88:       35ffffaf        cbnz    w15, 3ffa7c <__aarch64_ldadd4_acq_rel+0x1c>
  3ffa8c:       d65f03c0        ret

here the ldaxr and stlxr are used which according to:
https://developer.arm.com/documentation/ddi0602/2024-03/Base-Instructions/LDAXR--Load-Acquire-Exclusive-Register-?lang=en
Are identical to ldxr and stxr, but with the added benefit of load-acquire and store-release semantics, which from here:
https://developer.arm.com/documentation/102336/0100/Load-Acquire-and-Store-Release-instructions
Adds the guarantee that ordering is preserved accross cpus.
In building the test code from the stackoverflow question you pointed to, I get this:
void ThreadProc(atomic<int>& counter)
{
  400c44:       a9bc7bfd        stp     x29, x30, [sp, #-64]!
  400c48:       910003fd        mov     x29, sp
  400c4c:       f9000fe0        str     x0, [sp, #24]
    for (int i = 0; i < 10000000; i++)
  400c50:       b9003fff        str     wzr, [sp, #60]
  400c54:       1400000d        b       400c88 <ThreadProc(std::atomic<int>&)+0x44>
        counter.fetch_add(1, memory_order_relaxed);
  400c58:       f9400fe0        ldr     x0, [sp, #24]
  400c5c:       f9001be0        str     x0, [sp, #48]
  400c60:       52800020        mov     w0, #0x1                        // #1
  400c64:       b9002fe0        str     w0, [sp, #44]
  400c68:       b9002bff        str     wzr, [sp, #40]
#endif // __cpp_lib_atomic_wait

      _GLIBCXX_ALWAYS_INLINE __int_type
      fetch_add(__int_type __i,
                memory_order __m = memory_order_seq_cst) noexcept
      { return __atomic_fetch_add(&_M_i, __i, int(__m)); }
  400c6c:       f9401be1        ldr     x1, [sp, #48]
  400c70:       b9402fe0        ldr     w0, [sp, #44]
  400c74:       9400035b        bl      4019e0 <__aarch64_ldadd4_acq_rel>
  400c78:       d503201f        nop
    for (int i = 0; i < 10000000; i++)
...

The notable thing here being that, for whatever reason the c++ code translates a fetch_add in the atomic library to a call to __aarch64_ldadd4_acq_rel, rather than __aarch64_ldadd4_relaxed (despite the memory order being specified as relaxed).
From the above, I have to come to the conclusion that our reference counting code on weakly memory ordered systems isn't correct there.  We should be using __ATOMIC_ACQ_REL for the ref count to ensure that values from the atomic operation get published correctly for other cpus to see.
The only things I can't reconcile is why we don't see leaks on arm based on this.
This also leaves the issue of the tsan error, which I think, on any system but ARM is actually a false positive (brought on by the fact that tsan doesn't understand fences.
I would suggest that we make the memory order conditional on the arch, specifying ACQ_REL for weakly ordered systems, and introducing some tsan annotations for intel (as it does hardware ordering enforcement) (i.e. __tsan_acquire and __tsan_release)

I'm not sure I follow you there @kroeckx , its the only call in that function to the atomic fetch_add routine there, so I'm not sure how it could be wrong.

yeah, thats the issue, heres the full output:
void ThreadProc(atomic<int>& counter)
{
  400c44:       a9bc7bfd        stp     x29, x30, [sp, #-64]!
  400c48:       910003fd        mov     x29, sp
  400c4c:       f9000fe0        str     x0, [sp, #24]
    for (int i = 0; i < 10000000; i++)
  400c50:       b9003fff        str     wzr, [sp, #60]
  400c54:       1400000d        b       400c88 <ThreadProc(std::atomic<int>&)+0x44>   <= Jump to 400c88
        counter.fetch_add(1, memory_order_relaxed);
  400c58:       f9400fe0        ldr     x0, [sp, #24]
  400c5c:       f9001be0        str     x0, [sp, #48]
  400c60:       52800020        mov     w0, #0x1                        // #1
  400c64:       b9002fe0        str     w0, [sp, #44]
  400c68:       b9002bff        str     wzr, [sp, #40]
#endif // __cpp_lib_atomic_wait

      _GLIBCXX_ALWAYS_INLINE __int_type
      fetch_add(__int_type __i,
                memory_order __m = memory_order_seq_cst) noexcept
      { return __atomic_fetch_add(&_M_i, __i, int(__m)); }
  400c6c:       f9401be1        ldr     x1, [sp, #48]
  400c70:       b9402fe0        ldr     w0, [sp, #44]
  400c74:       9400035b        bl      4019e0 <__aarch64_ldadd4_acq_rel>
  400c78:       d503201f        nop
    for (int i = 0; i < 10000000; i++)
  400c7c:       b9403fe0        ldr     w0, [sp, #60]
  400c80:       11000400        add     w0, w0, #0x1
  400c84:       b9003fe0        str     w0, [sp, #60]
  400c88:       b9403fe1        ldr     w1, [sp, #60]
  400c8c:       5292cfe0        mov     w0, #0x967f                     // #38527
  400c90:       72a01300        movk    w0, #0x98, lsl #16
  400c94:       6b00003f        cmp     w1, w0
  400c98:       54fffe0d        b.le    400c58 <ThreadProc(std::atomic<int>&)+0x14> <=== Conditional jump back to 400c58
}
  400c9c:       d503201f        nop
  400ca0:       d503201f        nop
  400ca4:       a8c47bfd        ldp     x29, x30, [sp], #64
  400ca8:       d65f03c0        ret

So the branch instruction takes us down to 088, which then conditionally jumps back to c58 which does the fetch_add.  Its just some weird compiler re-arranging.

@MBkkt can you test with the associated PR please, and confirm that it fixes the issues you've encountered?

I would suggest that we make the memory order conditional on the arch, specifying ACQ_REL for weakly ordered systems, and introducing some tsan annotations for intel (as it does hardware ordering enforcement) (i.e. __tsan_acquire and __tsan_release)

We should choose the correct semantics for the operation being performed regardless of the architecture.  Anything less is just plain wrong.  I.e. ACQ_REL is the way to go here.  This stuff is really difficult to get correct and we should not try to be clever.

The atomic operations are still atomic with respect to each individual cpu, but because the memory writes are weakly ordered, its entirely possible for two threads running on two cpus to read the same value from main memory, resulting in two decrements from 2->1 rather than one from 2->1 and another from 1->0.

But that is the basic function contract if a relaxed atomic operation.
So if something like that can happen with your CPU then it is simply broken.
There must be a way for one CPU to LOCK the memory bus, and flush the data cache of other CPU cores,
then read the value, do the modify, and then write it back.
This involves of course a hardware protocol to communicate with the memory system, and lock it for
a short duration.

I have to agree with @bernd-edlinger, the C standard says how relaxed atomics should work. If that doesn't work as expected, this is a compiler bug.
My understanding of the weak ordering of ARM (since v7?) is that it should just work as expected, it can just reorder read and writes while something like x86 is more restrictive in the reordering it does.

It is really not about the inconsistency of the refcount itself. It is about potential inconsistency of data written to the object by one thread when it is freed by another thread.
I do not think we currently have any such situation where this could realistically happen, however after reading https://davekilian.com/acquire-release.html I have to agree that at least in the theoretic sense our current use of relaxed in down ref is wrong.

The current implementation does only work under the assumption that there are no writes
to the object, except for the refcount itself.
The original report was about EVP_PKEY objects, shared between two threads.
For correct operation the EVP_PKEY objects must be fully constructed before
they are shared between multiple threads, otherwise race conditions are unavoidable.
So if one thread calls any of the EVP_PKEY_set functions, it will result in disaster,
also a release fence will not fix this.

Yes, exactly, that's why I say it is not a real issue with our current code, just a theoretical one if we in future add refcounted data structures that allow for lockless writes.

In order to better understand what's going on here I've created a test program.
refcnt.tgz
the program mimics behaviour outlined here:

main thread initializes array of CRYPTO_REF_COUNT counters. it sets them to 2
then program spawns two threads each thread CRYPTO_DOWN_REF on each counter in array
once both threads are done main program checks if all counters are zero

there are two variants of thread functions:

dropper() which uses CRYPTO_DOWN_REF
naive_dropper() which just uses ref_counters[i].val--; to drop reference

no matter what I've tried I could not obtain a report from thread sanitizer. I was using gcc on arm as well as intel, debian bookworm. This is the command line to build the code: gcc -g -O0 -pthread -fsanitize=thread  -I/home/sashan/work.openssl/openssl.binaries/openssl-3.3/include -I/home/sashan/work.openssl/openssl.review/include/   refcnt.c -o refcnt -L /home/sashan/work.openssl/openssl.review/libcrypto.a
my questions:
- do functions (naive_dropper() and dropper()) demonstrate a data race we talk about here? if not how I should change them?
- am I using sanitizer right? or is there some additional step required?
thanks. I'm adding source code for dropper() and naive_dropper() for easier reference.
 13 static void *
 14 dropper(void *unused)
 15 {
 16         int     i;
 17         int     val;
 18
 19         pthread_barrier_wait(&barrier);
 20
 21         for (i = 0; i < COUNTERS; i++)
 22                 CRYPTO_DOWN_REF(&ref_counters[i], &val);
 23
 24         pthread_exit(NULL);
 25
 26         return (NULL);
 27 }
 28
 29 static void *
 30 naive_dropper(void *unused)
 31 {
 32         int     i;
 33         int     val;
 34
 35         pthread_barrier_wait(&barrier);
 36
 37         for (i = 0; i < COUNTERS; i++)
 38                 ref_counters[i].val--;
 39
 40         pthread_exit(NULL);
 41
 42         return (NULL);
 43 }

@Sashan It looks like it would be a valid write-after-write error to me, and so should trigger tsan.  Unfortunately, I can't seem to get it to trigger either, and I'm not at all sure why

@bernd-edlinger @kroeckx I'm not sure I follow your reasoning, to quote from the above comment:

But this clearly violates the basic function contract if a relaxed atomic operation.
So if something like that can happen with your CPU then it is simply broken.
What "this" are you referring to?  The only mention that I can find for atomic ordering requriements in C11 comes from section 7.17.3:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

 For memory_order_relaxed, no operation orders memory.

Thats it.  An atomic relaxed operation can complete operations in any order.   Now, perhaps theres a bug in the implementation of a relaxed read/modify/write on arm (see the ldadd4_relaxed implementation above).  But it certainly seems to me from the implementation that a relaxed fetch_sub can initiate two reads before the modify/write completes on either

There must be a way for one CPU to LOCK the memory bus, and flush the data cache of other CPU cores,
then read the value, do the modify, and then write it back, and unlock the data bus again.

Sure there is. On arm, its the use of the ldaxr and stlxr instructions which enforce load/acquire and store/release semantics.  Those are the instructions that get emitted when you specify an acquire/release order in your atomic operation.

This involves of course a hardware protocol to communicate with the memory system, and lock it for
a short duration.
yup, those instructions drive that protocol.

@nhorman please note the memory_order_relaxed for the atomic operation means that instructions before and after the atomic operation can be scheduled before or after the atomic operation regardless of where they were placed before.
However that DOES NOT mean that the atomic operation itself will work on inconsistent data. I.e. there cannot be any leaks due to two threads concurrently decrementing the refcount from 2 to 1. Otherwise this would NOT be an atomic operation at all.
The acquire or release memory order is best explained here https://davekilian.com/acquire-release.html


Set correct CORS header in API endpoint.

The correct header string is 'Access-Control-Allow-Origin'.
See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Whoops, thanks!


Add more pre-commit linting

The pre-commit linting related commits by @pradyunsg from https://github.com/pydata/pydata-sphinx-theme/pull/514, so those can already be merged separately

@choldgraf I am personally fine with those, you're OK with merging? (as long as pre-commit runs them, I don't care too much which exact linting rules we use :))

+1 from me, any objection to using pre-commit.ci ?

Thanks @pradyunsg !
(enabled "rebase and merge" for a moment, to preserve Pradyun's commits)

any objection to using pre-commit.ci ?

I have no experience with it. What does it exactly provide over the current pre-commit running in github actions? Automatic fixing?
(I am not sure if I am in favor of by default running this automatically, IMO it can also give annoying conflicts if commits were added remotely that you don't have locally, and fixing that up is not necessarily a newbie git workflow. I would personally prefer an "on demand" automatic fix)

yeah - the main benefit I've found is when people make edits to things directly from the GitHub UI, or where they make edits before remembering to install pre-commit locally. In those cases, if you forgot to do something that pre-commit would have fixed, it is automatically applied to the PR. So most useful for first time contributors or drive-by contributors. Not a huge deal either way but maybe something we can consider if we run into this issue relatively often

FWIW, you can't use pre-commit.ci unless you drop the "local" step that builds things using the yarn-installed environment. :)


how can I import core-js automatically?

var result = categories.find(ct => ct.id() === categoryId);

when I run jest, I got a error what - TypeError: Object # has no method 'find'
I know that I should import core-js to solve that error but he fact that I should import core-js every time using jest bothers me a lot.
What I want is to load core-js automatically when I run jest.
Is loading core-js automatically implemented already? or should I fork it and pull request.
Please let me know :)

You can load polyfills into the environment by using config.setupEnvScriptFile and then require.requireActual (I think to make sure it's not mocked) from there.
See what we do in jstransform: https://github.com/facebook/jstransform/blob/master/package.json#L42 & https://github.com/facebook/jstransform/blob/master/jestEnvironment.js

@zpao thank you a lot

For anyone that lands on this these days, the modern day fix is have a setupFiles setting in your package.json:
    "setupFiles": [
      "<rootDir>/internal/tests/browserMocks.js"
    ],

In the browserMocks.js file include this require statement at the top:
require('core-js');

For anyone who's too lazy to create a browserMocks.js file, you can set core-js directly in your package.json:
    "setupFiles": [
      "<rootDir>/node_modules/core-js"
    ]

If you'd like to be even lazier you can use the name only, too:
"setupFiles": ["core-js"]


Js fix headers

Adding April back in, and moved index.css into folder to see if that makes a difference when rendering


Support for Anthropic Prompt Caching

Description
Would be great if support for Anthropic's new prompt caching beta could be implemented:
https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
Thanks!

I definitely want to add support for this and will be looking into it.
I've added this to our v1.1 milestone!

Great, thanks! Any rough idea of when 1.1 will be out? @willbakst

Not certain yet (maybe a week or two?)
In the meantime, here is an example of using custom messages and headers to access the feature in v1:
from mirascope.core import anthropic
import requests

@anthropic.call(
    "claude-3-5-sonnet-20240620",
    call_params={
        "max_tokens": 1024,
        "extra_headers": {"anthropic-beta": "prompt-caching-2024-07-31"},
    },
)
def analyze_book(book: str) -> anthropic.AnthropicDynamicConfig:
    return {
        "messages": [
            {
                "role": "system",
                "content": [
                    {
                        "type": "text",
                        "text": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.\n",
                    },
                    {
                        "type": "text",
                        "text": f"{book}",
                        "cache_control": {"type": "ephemeral"},
                    },
                ],
            },
            {
                "role": "user",
                "content": "Analyze the major themes in Pride and Prejudice.",
            },
        ]
    }

response = requests.get("https://www.gutenberg.org/files/1342/1342-0.txt")
pride_and_prejudice = response.text

analysis = analyze_book(pride_and_prejudice)
print(analysis.content)

Before working on an implementation, I'm trying to think through the design here. What do we think about using tags similar to :image for cached data? For example, maybe something like this?
from mirascope.core import anthropic, prompt_template

@anthropi.call("claude-3-5-sonnet-20240620")
@prompt_template(
    """
    SYSTEM:
    You are an AI assistant tasked with analyzing literary works.
    Your goal is to provide insightful commentary on themes, characters, and writing style.

    {book:cache(type=ephemeral)}

    USER: Analyze the major themes in {title}
    """
)
def analyze_book(book: str, title: str): ...

book = requests.get("https://www.gutenberg.org/files/1342/1342-0.txt").text
analysis = analyze_book(book, "Pride and Prejudice")
print(analysis.content)

Yeah that's the most natural way to express cache breakpoints.
One thing I wanted to mention is that I think it's also important to expose some of Anthropic's caching details. For example, breakpoints only work if the number of tokens preceding them exceeds some number (1024 in Sonnet 3.5's case), and you can only set a max of 4 breakpoints. It would be nice to raise a warning or something if the breakpoints did not hit. Or perhaps, could there be like an 'automatic' mode that sets the breakpoints for me, say after every 1024 tokens?

Oh interesting, after some more digging I'm realizing we also need to consider how to cache tools.
I'm thinking something like this might be the best thing:
from mirascope.core import BaseTool, ConfigDict, anthropic, prompt_template

class FormatAnalysis(BaseTool):
    analysis: str
    key_points: list[str]

    model_config = ConfigDict(cache_control={"type": "ephemeral"})

    def call(self) -> str:
        return f"Key Points:\n{self.key_points}\nFull Analysis:\n{self.analysis}"

@anthropic.call("claude-3-5-sonnet-20240620", tools=[FormatAnalysis])
@prompt_template(
    """
    SYSTEM:
    You are an AI assistant tasked with analyzing literary works.
    Your goal is to provide insightful commentary on themes, characters, and writing style.

    Here is the literary work, {title}: {book:cache_control(type=ephemeral)}

    USER: Analyze the major themes in {title}
    """
)
def analyze_book(book: str, title: str): ...

book = requests.get("https://www.gutenberg.org/files/1342/1342-0.txt").text
analysis = analyze_book(book, "Pride and Prejudice")
print(analysis.content)

The tools would then cache up to the breakpoint of the tool with the cache (like they have in their examples). This would also then enable caching to work for things like response_model.
For the breakpoint maximum, that's easily included (we just see how many breakpoints are included and raise a warning or error if it's more than the limit).
For the token limit stuff, I'm not sure if including a tokenizer and checking that is worthwhile compared to using their existing response booleans for whether or not a cache was created (i.e. there's no real difference in my book between counting and warning up-front vs. finding out after making the call that you were already prepared to make anyway). We can always show a warning based on this response boolean.
I will work to implement this soon hopefully, just need to finalize the design and implementation details :)

This is released in v1.1!
docs: https://mirascope.io/docs/latest/learn/provider_specific_features/#prompt-caching


not able to run kubectl logs / kubectl exec

when I run kubectl logs / kubectl exec, I encounter no route to host error to connect to api server, as shown below, I already run
ufw allow in on cbr0 && sudo ufw allow out on cbr0
ufw default allow routed
iptables -P FORWARD ACCEPT

but it doesnot help
root@host:~# kubectl exec busybox cat /etc/resolv.conf
Error from server: error dialing backend: dial tcp <IP_ADDRESS>:10250: connect: no route to host

root@host:~# kubectl logs --previous  busybox -n default
Error from server: Get https://host:10250/containerLogs/default/busybox/busybox?previous=true: dial tcp <IP_ADDRESS>:10250: connect: no route to host

root@host:~# microk8s.status
microk8s is running
addons:
cilium: disabled
dashboard: enabled
dns: enabled
fluentd: disabled
gpu: disabled
helm: disabled
ingress: disabled
istio: disabled
jaeger: disabled
juju: disabled
knative: disabled
kubeflow: disabled
linkerd: disabled
metallb: disabled
metrics-server: disabled
prometheus: disabled
rbac: disabled
registry: enabled
storage: enabled
root@host:~# microk8s.inspect
{
Inspecting services
  Service snap.microk8s.daemon-cluster-agent is running
  Service snap.microk8s.daemon-flanneld is running
  Service snap.microk8s.daemon-containerd is running
  Service snap.microk8s.daemon-apiserver is running
  Service snap.microk8s.daemon-apiserver-kicker is running
  Service snap.microk8s.daemon-proxy is running
  Service snap.microk8s.daemon-kubelet is running
  Service snap.microk8s.daemon-scheduler is running
  Service snap.microk8s.daemon-controller-manager is running
  Service snap.microk8s.daemon-etcd is running
  Copy service arguments to the final report tarball
Inspecting AppArmor configuration
Gathering system information
  Copy processes list to the final report tarball
  Copy snap list to the final report tarball
  Copy VM name (or none) to the final report tarball
  Copy disk usage information to the final report tarball
  Copy memory usage information to the final report tarball
  Copy server uptime to the final report tarball
  Copy current linux distribution to the final report tarball
  Copy openSSL information to the final report tarball
  Copy network configuration to the final report tarball
Inspecting kubernetes cluster
  Inspect kubernetes cluster

WARNING:  Docker is installed.
Add the following lines to /etc/docker/daemon.json:
{
    "insecure-registries" : ["localhost:32000"]
}
and then restart docker with: sudo systemctl restart docker
Building the report tarball
  Report tarball is at /var/snap/microk8s/1079/inspection-report-20191128_024023.tar.gz

inspection-report-20191128_024023.tar.gz
@ktsakalozos  Appreciate your help.

The IP <IP_ADDRESS> does not seem to be the IP of your machine, at least not anymore. The connection to the kubelet on that IP is not present anymore. Perhaps this deployment is on a laptop? What can you tell me about the setup you have? Is there something special about it? When IP changes are detected the apiserver-kicker [1] restarts a few of services. It is worth trying a microk8s.stop; microk8s.start;. Also just to check with you, the kubectl you are doing is an alias to microk8s.kubectl, right?

Hi @ktsakalozos thanks for the advice, I am running microk8s in a Ubuntu VM, the IPs are listed below, everything else seems to work well other than this network issue, I tried microk8s.stop then microk8s.start but the issue is still there, could you please advise how microk8s assign the IP and how to re-configure it? yes, kubectl is the alias to microk8s.kubectl
IP address for ens3:    <IP_ADDRESS>
IP address for cni0:    <IP_ADDRESS>
IP address for docker0: <IP_ADDRESS>

How does your /etc/hosts look like? What is/was on <IP_ADDRESS>? Here is how we setup kubelet https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/wrappers/run-with-config-args#L22 We do not do anything special. Kubelet should start on the default interface and you should be able to get the pod logs from the 10250 port (if I understand this correctly). How does this <IP_ADDRESS> came to be? How does the output of ip route look like?

Hi @ktsakalozos pls find the config below
~$ cat /etc/hosts
<IP_ADDRESS>	localhost.localdomain	localhost
::1		localhost6.localdomain6	localhost6

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

~$ ip route
default via <IP_ADDRESS> dev ens3 proto dhcp src <IP_ADDRESS> metric 100
<IP_ADDRESS>/12 dev ens3 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS> dev ens3 proto dhcp scope link src <IP_ADDRESS> metric 100
<IP_ADDRESS>/24 dev cni0 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/16 dev docker0 proto kernel scope link src <IP_ADDRESS> linkdown

~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
From <IP_ADDRESS> icmp_seq=1 Destination Host Unreachable

~$ cat /var/snap/microk8s/current/args/kubelet
--kubeconfig=${SNAP_DATA}/credentials/kubelet.config
--cert-dir=${SNAP_DATA}/certs
--client-ca-file=${SNAP_DATA}/certs/ca.crt
--anonymous-auth=false
--network-plugin=cni
--root-dir=${SNAP_COMMON}/var/lib/kubelet
--fail-swap-on=false
--cni-conf-dir=${SNAP_DATA}/args/cni-network/
--cni-bin-dir=${SNAP}/opt/cni/bin/
--feature-gates=DevicePlugins=true
--eviction-hard="memory.available<100Mi,nodefs.available<1Gi,imagefs.available<1Gi"
--container-runtime=remote
--container-runtime-endpoint=${SNAP_COMMON}/run/containerd.sock
--node-labels="microk8s.io/cluster=true"
--cluster-domain=cluster.local
--cluster-dns=<IP_ADDRESS>

Hi @ktsakalozos I believe I found the root cause
the VM ip is ephemeral, the original ip is <IP_ADDRESS> and after upgrading it changed to <IP_ADDRESS>,
is there any way to configure/update the ip in microk8s accordingly? and what config files need to be updated? I tried microk8s.stop then microk8s.start, but it does not work


[Story] Review and document OC Roadmap for 2023 Q3-Q4

What projects is this story for?
No response
As a user, I want
As the Product Owner, I want stakeholders and developers to have a clear vision of where OpenChallenges will be heading during the second half of the year.
Description
Due date: July 5 (D&T Ops meeting)
Acceptance criteria

Presented the updated Roadmap to @chepyle and the D&T Ops team

Tasks
No response
Anything else?
No response
Have you linked this story to a GitHub Project?

[X] I have linked this story to a GitHub Project and set its metadata.

The Roadmap has been shared with the team and positive feedback has been received.


R file icon for file explorer

I use R lang on a daily basis. I want to have an icon for the R file type (.r) visible in the file explorer.

Please check the below file: 👇
fix.zip

Thanks for the suggestion but we're currently not adding any new system file icons, please see https://github.com/microsoft/vscode/issues/60699#issuecomment-429208011.


The lesson allows you to continue without placing the buttons side by side

Challenge http://www.freecodecamp.com/challenges/waypoint-use-the-bootstrap-grid-to-put-elements-side-by-side has an issue. Please describe how to reproduce it, and include links to screen shots if possible.

While using the  the lesson is marked as complete without closing the div  which results in stacked buttons rather than a row of buttons

Hey @maper81,
A fix has been completed and should be up soon. Thanks!
Good Luck with the rest of the challenges!


L2 head move

Skipped tests which require prover to be run, and other failing, e.g. related to reorg.


hack: add check_error_case.sh and test_lib.sh

This adds a new bash test script in hack that checks the case of the first character of error messages to make sure they are not uppercase.
Resolves #380.

lgtm

LGTM


Add support for RFC 3537

Add module and test for RFC 3537

Codecov Report

Merging #115 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #115      +/-   ##
=========================================
+ Coverage    99.4%   99.4%   +<.01%
=========================================
  Files         105     106       +1
  Lines        6433    6440       +7
=========================================
+ Hits         6395    6402       +7
  Misses         38      38

Impacted Files
Coverage Δ

pyasn1_modules/rfc3537.py
100% <100%> (ø)

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 d8d2525...fb33c1f. Read the comment docs.

Thank you!


Fixes, alerts, more user management

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


Add default calcification rates to labels

I'll be starting work on functionality to compute calcification-rate metrics for CoralNet datasets. These metrics will be computed based on two things: the annotations present in the image/source of interest, and calcification rates defined for each label.
I'll make another issue dealing with user-defined calcification rates, and other issue(s) for the actual export of the metrics. This issue will deal with baking default calcification rates into CoralNet. Travis Courtney will be providing these default rates using data from ReefBudget.
This example table shows what is involved in specifying calcification rates:

Label
Region
Mean rate
Lower bound
Upper bound

Acropora
Atlantic
19.21
14.34
24.31

Acropora cervicornis
Atlantic
31.73
25.39
40.76

Acropora palmata
Atlantic
9.82
7.29
12.38

Agaricia
Atlantic
6.87
6.14
7.85

Dipsastraea
Atlantic
8.76
8.65
8.89

Dipsastraea
Indo-Pacific
0.98
0.81
1.21

Cliona
Atlantic
-5.17
-7.3
-3.04

CCA (crustose coralline algae)
Atlantic
0.36
0.3
0.43

ReefBudget currently distinguishes between two separate regions for purposes of tracking calcification rates. We're calling them Atlantic and Indo-Pacific. A label could have different rates specified between the two regions, or it could only have a rate specified for one of the regions (coral species generally only occur in one region or the other).

Both lower bound and upper bound must be specified since they are not symmetric about the mean.

Some non-coral labels will have rates defined to account for negative carbonate production terms. Not all labels will have rates defined though, and in the case of a missing rate, the label can be taken to have a rate of 0 for computation purposes.

Tasks:

[ ] Write a Django management command to import default calcification rates from a CSV file (formatted similarly to the above table) into the database.

Each rate table would have a name. The exact info encoded in the table name can be left to Travis, but presumably it would indicate when the info was last updated, and the region the rates are for.

There are a couple of options for database storage details.

Add per-label fields for default calcification rates. This does not readily make it possible to do ops such as sorting labels by calcification rate, unless separate DB entries are made for mean/lower/upper in each of the 2 regions (i.e. 6 entries). However, I can't think of a situation where we'd need to do that anyway, so it may suffice to have a single JSON entry in the DB per label, containing mean/lower/upper for all regions. One problem though, the name of the rate table doesn't get stored this way, so that has to be a separate field which is not associated with any label in particular. That single field would probably go in its own table, awkwardly enough, since shoehorning the field in an unrelated table probably wouldn't be the best idea.

Looking ahead, we may want to implement storage of source-specific rate tables (#377). This means we would define a database model where one database row represents one rate table. The CoralNet default tables can be stored using this database model, with the source relationship-field left blank. I would probably favor this implementation, it seems like it would be cleaner (though I could be wrong).

We should anticipate doing the import several times near the beginning as we're still figuring out the whole process. In the long term, though, the main factors determining update frequency would be:

Significant usage of newly added labels in CoralNet

Significant reorganizing of labels, perhaps arising from new features such as multiple labels per point (issue #160)

Updated methodologies for measuring calcification rates, although Travis says this is expected to be stable for at least a few years

Overall, I say we handle updates via a management command (requiring web server access) for the time being. So for example, Travis sends me a CSV file, then I log onto the web server, upload the CSV to the server, and run the management command to put it into CoralNet. If that ends up being cumbersome given the frequency of updates, then we can consider implementing a more convenient update method.

[ ] Show default calcification rates on label-detail pages.

Rates are in units of kg CaCO_3 m^-2 yr^-1.

Show mean, lower confidence bound, and upper confidence bound.

Again, labels may have no rates, rates for only one region, or rates for both regions. The display should accommodate all cases.

Indicate the last update date / table name of the default rates. Perhaps this could be mentioned in the label detail page's help dialog.

[ ] Label list: indicate availability of default calcification rates for each label.

The idea here is that the presence/absence of calcification rates could be a factor for people who are picking labels for their source. At first I wasn't sure about this, but considering that CoralNet's label pool is very hard to keep organized, sometimes the label choices do have to be dictated by technical realities like this.

The Status column has some unused space, so a calcification icon could be included in that column (present if rates are available, absent if not). Alternatively, the icon could be in its own column which can be toggled as shown/hidden using a checkbox, although I currently think using the Status column would be the smartest use of space.

For the label list, it may be too complex to indicate which regions' rates are available for each label. Perhaps just show the icon if at least one region is available.

Stephen, You mentioned in an earlier email that you would get together with
Travis while working on some other tasks.
Did that you guys meet and converge on scope and details?
David
On Thu, Mar 18, 2021 at 6:00 PM StephenChan @.***>
wrote:

I'll be starting work on functionality to compute calcification-rate
metrics for CoralNet datasets. These metrics will be computed based on two
things: the annotations present in the image/source of interest, and
calcification rates defined for each label.
I'll make another issue dealing with user-defined calcification rates, and
other issue(s) for the actual export of the metrics. This issue will deal
with baking default calcification rates into CoralNet. Travis Courtney will
be providing these default rates using data from ReefBudget
https://urldefense.com/v3/__http://geography.exeter.ac.uk/reefbudget/__;!!Mih3wA!WiOje2iyfnE2Wnb2ZK6iFqwWZaHwTgSxjIvgaQBpF3P_BtoZNGUUhOXt5ZTwLOju$
.
This example table shows what is involved in specifying calcification
rates:
Label Region Mean rate Lower bound Upper bound
Acropora Atlantic 19.21 14.34 24.31
Acropora cervicornis Atlantic 31.73 25.39 40.76
Acropora palmata Atlantic 9.82 7.29 12.38
Agaricia Atlantic 6.87 6.14 7.85
Dipsastraea Atlantic 8.76 8.65 8.89
Dipsastraea Indo-Pacific 0.98 0.81 1.21
Cliona Atlantic -5.17 -7.3 -3.04
CCA (crustose coralline algae) Atlantic 0.36 0.3 0.43

ReefBudget currently distinguishes between two separate regions for
purposes of tracking calcification rates. We're calling them Atlantic and
Indo-Pacific. A label could have different rates specified between the two
regions, or it could only have a rate specified for one of the regions
(coral species generally only occur in one region or the other).
Both lower bound and upper bound must be specified since they are not
symmetric about the mean.
Some non-coral labels will have rates defined to account for negative
carbonate production terms. Not all labels will have rates defined though,
and in the case of a missing rate, the label can be taken to have a rate of
0 for computation purposes.
Tasks:

Add database field(s) for default calcification rates for each label.

Certain operations, such as sorting labels by calcification rate,
may warrant separate DB entries for mean/lower/upper in each region.
However, I can't think of a situation where we'd need to do something like
that. So it may suffice to have a single JSON DB entry per label,
containing mean/lower/upper for all regions.

Write a Django management command to import default calcification
rates from a CSV file (formatted similarly to the above table) into the
database.
  We should save the date that the default rates were last updated.
  (Specifically, the date the rates were last updated by ReefBudget, not the
  date they were actually uploaded to CoralNet.) I think it can be a single
  date in the database rather than one date per label, although
  implementation-wise either way would be OK.
  -

  We should anticipate doing the import several times near the
  beginning as we're still figuring out the whole process. In the long term,
  though, the main factors determining update frequency would be:
  1.

     Significant usage of newly added labels in CoralNet
     2.

     Significant reorganizing of labels, perhaps arising from new
     features such as multiple labels per point (issue #160
     <https://urldefense.com/v3/__https://github.com/beijbom/coralnet/issues/160__;!!Mih3wA!WiOje2iyfnE2Wnb2ZK6iFqwWZaHwTgSxjIvgaQBpF3P_BtoZNGUUhOXt5YaldZv_$>
     )
     3.

     Updated methodologies for measuring calcification rates,
     although Travis says this is expected to be stable for at least a few years

Overall, I say we handle updates via a management command (requiring
web server access) for the time being, and if that ends up being cumbersome
given the frequency of updates, then we can consider implementing a more
convenient update method.
Show default calcification rates on label-detail pages.
  Rates are in units of kg CaCO_3 m^-2 yr^-1.
  -

  Show mean, lower confidence bound, and upper confidence bound.
  -

  Again, labels may have no rates, rates for only one region, or
  rates for both regions. The display should accommodate all cases.
  -

  There should be some indication of when the default rates were last
  updated (again, on ReefBudget's end). On the label detail page, perhaps
  this could be mentioned in the page's help dialog.
  -

Label list: indicate availability of default calcification rates for
each label.
  The idea here is that the presence/absence of calcification rates
  could be a factor for people who are picking labels for their source. At
  first I wasn't sure about this, but considering that CoralNet's label pool
  is very hard to keep organized, sometimes the label choices do have to be
  dictated by technical realities like this.
  -

  The Status column has some unused space, so a calcification icon
  could be included in that column (present if rates are available, absent if
  not). Alternatively, the icon could be in its own column which can be
  toggled as shown/hidden using a checkbox, although I currently think using
  the Status column would be the smartest use of space.
  -

  For the label list, it may be too complex to indicate which
  regions' rates are available for each label. Perhaps just show the icon if
  at least one region is available.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/beijbom/coralnet/issues/368__;!!Mih3wA!WiOje2iyfnE2Wnb2ZK6iFqwWZaHwTgSxjIvgaQBpF3P_BtoZNGUUhOXt5alRjRKc$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABKA5APW3FTMWJ5CPK2GBW3TEKO23ANCNFSM4ZNZPT2A__;!!Mih3wA!WiOje2iyfnE2Wnb2ZK6iFqwWZaHwTgSxjIvgaQBpF3P_BtoZNGUUhOXt5ZBjMUk5$
.

@kriegman I'm discussing with Travis, yes - he sent me a preliminary CSV of calcification rates which could be used as the import format into CoralNet's DB. The "example table" is based on that CSV, and we've been discussing a few details about that. Most of the other details here Travis seemed to be fine with before, but I will certainly double check.

Great. Sounds like it’s right on track.
David
On Fri, Mar 19, 2021 at 12:33 AM StephenChan @.***>
wrote:

@kriegman
https://urldefense.com/v3/__https://github.com/kriegman__;!!Mih3wA!RNHqhLro44kyPGC2Wko5wJVpL0Vsw4FSXzrixBLjKYXQWF7iCj8s1KP1BBkenpPX$
I'm discussing with Travis, yes - he sent me a preliminary CSV of
calcification rates which could be used as the import format into
CoralNet's DB. The "example table" is based on that CSV, and we've been
discussing a few details about that. Most of the other details here Travis
seemed to be fine with before, but I will certainly double check.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/beijbom/coralnet/issues/368*issuecomment-802618817__;Iw!!Mih3wA!RNHqhLro44kyPGC2Wko5wJVpL0Vsw4FSXzrixBLjKYXQWF7iCj8s1KP1BLWHTLov$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABKA5ANOSKK7UXKYKLHXNJ3TEL445ANCNFSM4ZNZPT2A__;!!Mih3wA!RNHqhLro44kyPGC2Wko5wJVpL0Vsw4FSXzrixBLjKYXQWF7iCj8s1KP1BB-fmRr1$
.

--
Sent from Gmail Mobile

I think it's important to have version ID labels for the calcification rate tables and perhaps have the legacy tables available in some location. Perhaps it would make sense for me to upload these rate tables to a citable, stable Zenodo repo so that there's tracked version history for the primary calcification rate table releases and any subsequent calcification rate table updates? For example, the user may want to re-run previously annotated images with the updated calcification rate table and/or use an older calcification rate table for future images to maintain consistency in any time series analyses.
I like the idea of having a simple calcification rate check box for the the Status Column so that the users can see which labels have calcification rate data available. I don't think we need to specify on that page whether the rate is Indo-Pacific vs Atlantic-- just that there is calcification rate data available for the respective label.

I think it's important to have version ID labels for the calcification rate tables and perhaps have the legacy tables available in some location. Perhaps it would make sense for me to upload these rate tables to a citable, stable Zenodo repo so that there's tracked version history for the primary calcification rate table releases and any subsequent calcification rate table updates? For example, the user may want to re-run previously annotated images with the updated calcification rate table and/or use an older calcification rate table for future images to maintain consistency in any time series analyses.

That sounds like it would work. If you set up a Zenodo repo, then once I implement #369, I can add a link to that repo next to the download links for the current default rate tables.

I like the idea of having a simple calcification rate check box for the the Status Column so that the users can see which labels have calcification rate data available. I don't think we need to specify on that page whether the rate is Indo-Pacific vs Atlantic-- just that there is calcification rate data available for the respective label.

OK, good to confirm this.

Sounds great! I'll put together the Zenodo repo with the calcification rate tables and the R code to construct those tables from the raw data sources so that everything is traceable leading into the incorporation of calcification rates into CoralNet.

Marking this as done with PR #403 - just need to remember to add the link to the versioning repo (Zotero or whichever it may be) when it's available.


Release/close of Receiver

What is the procedure of closing/releasing receivers?
I have tested with the NDI Signal generator, and when switching between receiving sources, the number of connections grows - the receivers are not released.
How to reproduce:
Create new receiver to Receive Source 1. (Signal generator)
Create new receiver to Receive Source 2. (Other source)
Create new receiver to Receive Source 1. (Signal generator)
The number of connections on the Signal generator now says 2, and will grow to 3 if I switch to another source and back to the signal generator.
I use the same variable to hold the reference to the receiver, and it is being overwritten each time the receiver is created successfully.
I see there is a finalizeReceive method in grandiose_receive.cc, but I does not see when it is used...
Best regards

Nevermind!
I just read the sentence in the readme:
"The receiver instance will disconnect on the next garbage collection, so make sure that you don't hold onto a reference."
I used Electron, and I did not were aware that you could manually trigger garbage collection.
https://stackoverflow.com/questions/51372010/enabling-manual-garbage-collection-in-electron-app


[bugfix]: filter out __ngcc_entry_points__.json file

This PR fixes a bug where depngn was tripping over the __ngcc_entry_points__.json file, which is automatically added to node_modules in Angular apps when building. Not sure why this ends up being a part of the output of npm ls (I don't think it gets added to package.json or package-lock.json), but ¯\_(ツ)_/¯.
Resolves #33.
Changes

added an AUTO_EXCLUDE array (only has the one entry right now, but I assume other libraries/packages do hacky things to node_modules as well, so we can add more stuff there in the future as it comes up)
filters out auto excluded entries from the initial npm ls output
uses reduce to build the new object because we're fancy 💅🏻 (i actually think a for loop would be faster here, but this isn't currently the bottleneck of the app -- that's the npm view part)

Future features
This also sort of lays the ground work to give the user the ability to filter out some things, so that's neat! All we'd have to do is add a flag to the CLI args, pass that to the root depngn function, and then check the values inside the filter in getDependencies.

looks good, thank you, @kindoflew!


Issue Title: Implement Rate Limiting Middleware

Issue Description: Currently, the FastAPI Rocket Boilerplate lacks rate limiting middleware, which is essential for controlling the number of requests a client can make to the API within a specific time frame. This issue aims to implement rate limiting middleware, allowing developers to configure and enforce rate limits on API endpoints.
Proposed Solution: Implement a rate limiting middleware that:
Supports rate limits based on IP address or user tokens.
Allows developers to configure rate limits for specific routes or groups of routes.
Provides clear documentation on how to configure and use rate limiting in the boilerplate.
Expected Impact: The addition of rate limiting middleware would enhance the security and reliability of the API by preventing abuse and ensuring fair usage of resources

Hello Adesoji,
The nocache middleware is a middleware oriented to avoid the cache in the swagger documentation (a common situation working with Fastapi).
Therefore, the enhancement of this issue is not needed now.
Thanks so much for your time and effort on this, please keep using the project and supporting like this!


Add resilience to kubectl logs -f on test pod

We fairly consistently see a situation where a kubectl logs -f [deis-tests] --namespace=deis exits (like it got a connection reset or got an EOF) on ci e2e runs. This makes the test logic think that the tests are done running and therefore kick off the "wait for pod exit code" rigamarole. We should figure out a way to ensure that tests have either finished successfully, still are running, or have errored by adding in a check for pod status (other than container exit code) which can then rekick off a tailing of the test logs.

With #120 I increased the timeout for the logic to wait for the container's exit code. We'll see if that helps at all.

Closing this as we aren't seeing this issue anymore


[release-1.19] Remove conditional cleanup from traffic test

This is an automated cherry-pick of #46801

Wait until 1.19.1


refactor: Move view visibility trigger into AndroidUtils

Add AndroidUtils class for common view related tasks
Add tests for AndroidUtils

@niranjan94 Please merge


Bring the "PCs Only" optin back

Hi there, this is a great module.
There was an option in earlier versions for 0.7.x to show the estimate only to the players on hover.
In the latest version for 0.8.x that option is gone. Please bring it back, it is maximally anoying to see the text estimate and the healthbar as a GM.

Never mind, the option changed to a dropdown menu.


final "ticket.confirmed" webhook no longer being sent for paid orders, "order.processing" sent first instead

Describe the bug
Since about January 20, we have not been receiving the "ticket.confirmed" type webhook for paid ticket orders. We do seem to still receive it for a $0 test ticket.
The last paid one where we received a "ticket.confirmed" was:
{"createdAt":"2023-01-19T22:31:24.507Z","id":4899873,"type":"ticket.confirmed","CollectiveId":574860,"data":{"recipient":{"name":"Guest"},"tier":{"id":48608,"name":"General Admission (Early)","amount":3500,"currency":"USD","description":null,"maxQuantity":null,"formattedAmount":"$35.00","formattedAmountWithInterval":"$35.00"},"order":{"id":615291,"totalAmount":3500,"currency":"USD","description":"Registration to DrupalCamp NJ 2023 (General Admission (Early))","interval":null,"createdAt":"2023-01-19T22:31:18.151Z","quantity":1,"formattedAmount":"$35.00","formattedAmountWithInterval":"$35.00"}}}

For that ticket we received 3 webhooks:
"id":4899871,"type":"collective.transaction.created"
"id":4899872,"type":"collective.member.created"
"id":4899873,"type":"ticket.confirmed"

For a more recent ticket we get 3 webhooks payloads but 1 of the 3 are of a different type, and none include the tags from the order:
"id":4939380,"type":"order.processing"
"id":4939384,"type":"collective.transaction.created"
"id":4939385,"type":"collective.member.created"

Expected behavior
When a ticket purchase goes through we expect to receive a "ticket.confirmed" webhook.  This type is still in the drop-down selector for webhooks e.g. on our event settings at: https://opencollective.com/drupalnj/events/drupalcamp-nj-2023-3943c0c2/admin/webhooks
In these recent PRs, the ticket.confirmed webhook type was enhanced to include tags:
https://github.com/opencollective/opencollective-api/pull/8450
https://github.com/opencollective/opencollective-api/pull/8457
Additional context
Looking at the commit log, there don't seem to be many related changes in that time frame. A couple possible suspects are:
commit f724b4caec8ebab01026f5f171a8a56a9e3222b9
Author: Henrique<EMAIL_ADDRESS>Date:   Mon Jan 23 15:04:11 2023 -0300

    Handle payment method before creating transactions (#8449)

and
commit cb0af05e83cff42066096f1ed9efe6a43d5517e4
Author: Henrique<EMAIL_ADDRESS>Date:   Mon Jan 23 08:35:18 2023 -0300

    Match or create payment method on payment intent success (#8429)

Those changes affected Stripe payments webhook, and I think most or all of our paid tickets are coming as credit cards via Stripe.

Triage Template (core team only)
This template is for members of the team to triage for prioritisation. For more guidance see https://www.loom.com/share/369ab467fbc64dec848085d38ff57ca0:
P1 high frequency, high impact
P2 low frequency, high impact
P3 high frequency, low impact
P4 low frequency, low impact
Examples of high impact - a problem affects users during an essential process (expenses and payments > onboarding and registration > contributing) with no workaround.
High frequency - >10% of users affected (measured as a proportion of total potential users for this case).

cc @hdiniz, could any of these changes have impacted the type of webhook events we generate?

Thanks for the bug report @pwolanin! I believe this could be related with the the recent stripe payment element integration which modified the credit card flow, I will check.

Thanks @hdiniz !


Fix Sybase stored proc text order

When retrieving the source for a Sybase stored procedure that has multiple rows in the syscomments table the order can come back incorrectly and hence what is displayed is incorrect.
The change simply adds an order by to the SQL used to fetch the comment text.

Thank for the fix!


Fix TravisCI Build Failures

I'm opening this PR in an attempt to correct the build failures on TravisCI.  Sorry for the PR and notifications, but I do not want to setup Travis on my own Github organization just for this one repository.
The build's tests are passing, but the script script/integration.sh is not working properly.
Travis ends with The command "script/integration.sh" exited with 1.
EDIT: Its related to sqlite3 releasing version 1.4 recently.  Despite not specifying a version for sqlite3 anywhere (in the gemspec and in the dummy app's Gemfile), Travis and also my local Ubuntu environment is looking for sqlite3 1.3.6 still.  Investigating....
The sqlite3 v1.3.6 dependency is built into ActiveRecord's SQLite3 adapter.  See https://github.com/rails/rails/blob/5-2-stable/activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb#L12

@mikz - the build is working again.  This was a bit difficult to sort out between SQLite3 and Bundler major version releases but I got it.

@mikz - Can this get merged?  The build is passing again.

@danielricecodes thank you for the PR 👍 . I'll merge it first and then try to simplify it later.


Promise.defer no more

closes https://github.com/TypeStrong/atom-typescript/issues/890

PS: the test infrastructure needs work. Its broken at the moment as I get a ton of duplicate ident errors locally npm run build but the build server says "all good" :rose:

Marking this as a minor as its a significant change ... but should work just fine :rose:


python3Packages.aioguardian: init at 1.0.4

Motivation for this change
aioguardian is a Python3, asyncio-focused library for interacting with the Guardian line of water valves and sensors from Elexa.
https://github.com/bachya/aioguardian
This is a Home Assistant dependency.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108673 run on x86_64-linux 1

2 packages built:

python37Packages.aioguardian
python38Packages.aioguardian

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108673 run on x86_64-linux 1

2 packages built:

python37Packages.aioguardian
python38Packages.aioguardian

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108673 run on x86_64-darwin 1

2 packages failed to build and are new build failures:

python37Packages.aioguardian: log was empty
python38Packages.aioguardian: log was empty

I am going to put this in a collected PR.
diff --git a/pkgs/development/python-modules/asyncio-dgram/default.nix b/pkgs/development/python-modules/asyncio-dgram/default.nix
index 9edc215abcf..fab037d0b39 100644
--- a/pkgs/development/python-modules/asyncio-dgram/default.nix
+++ b/pkgs/development/python-modules/asyncio-dgram/default.nix
@@ -1,4 +1,5 @@
-{ lib
+{ stdenv
+, lib
 , buildPythonPackage
 , fetchFromGitHub
 , pytestCheckHook
@@ -16,6 +17,9 @@ buildPythonPackage rec {
     sha256 = "1zkmjvq47zw2fsbnzhr5mh9rsazx0z1f8m528ash25jrxsza5crm";
   };

+  # OSError: AF_UNIX path too long
+  doCheck = !stdenv.isDarwin;
+
   checkInputs = [
     pytestCheckHook
     pytest-asyncio

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108673 run on x86_64-darwin 1

2 packages failed to build and are new build failures:

python37Packages.aioguardian: log was empty
python38Packages.aioguardian: log was empty

I am going to put this in a collected PR.
diff --git a/pkgs/development/python-modules/asyncio-dgram/default.nix b/pkgs/development/python-modules/asyncio-dgram/default.nix
index 9edc215abcf..fab037d0b39 100644
--- a/pkgs/development/python-modules/asyncio-dgram/default.nix
+++ b/pkgs/development/python-modules/asyncio-dgram/default.nix
@@ -1,4 +1,5 @@
-{ lib
+{ stdenv
+, lib
 , buildPythonPackage
 , fetchFromGitHub
 , pytestCheckHook
@@ -16,6 +17,9 @@ buildPythonPackage rec {
     sha256 = "1zkmjvq47zw2fsbnzhr5mh9rsazx0z1f8m528ash25jrxsza5crm";
   };

+  # OSError: AF_UNIX path too long
+  doCheck = !stdenv.isDarwin;
+
   checkInputs = [
     pytestCheckHook
     pytest-asyncio

Looks like that the asyncio-dgram build issue will be addressed with #108799.

Looks like that the asyncio-dgram build issue will be addressed with #108799.

Looks like that the asyncio-dgram build issue will be addressed with #108799.

I just merged this.

Looks like that the asyncio-dgram build issue will be addressed with #108799.

I just merged this.

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108673 run on x86_64-darwin 1

2 packages built:

python37Packages.aioguardian
python38Packages.aioguardian

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108673 run on x86_64-darwin 1

2 packages built:

python37Packages.aioguardian
python38Packages.aioguardian

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108673 run on x86_64-linux 1

2 packages built:

python37Packages.aioguardian
python38Packages.aioguardian

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108673 run on x86_64-linux 1

2 packages built:

python37Packages.aioguardian
python38Packages.aioguardian


Debug Test For Go Not Working

Describe the bug
Using Kickstart with a couple of additional plugins unrelated to debugging. I am able to start debugging Go projects using the Debug , Debug (Arguments), Debug test (go.mod). However, when I try to use the Debug test option I get an error that states Error on launch: Failed to launch. I have set my cursor inside a test function and also tried putting it on the test function signature, but that did not change the results.
To Reproduce

Open Go project in neovim at the root of the project
Open a test file (*_test.go naming pattern)
Navigate to a test
Invoke the DAP continue function( By default this is F5)
Select the Debug test option

Desktop

OS:  MacOS Sonoma 14.4.1
Terminal: Kitty

Neovim Version
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1713773202

Note
I am still rather new to NeoVim and might be doing something silly and apologize in advance if this is a me problem.

@AnthonyMBonafide maybe check out this vid if it provides any help:
https://www.youtube.com/watch?v=lyNfnI-B640
simple neovim debugging setup (in 10 minutes)

@AnthonyMBonafide maybe check out this vid if it provides any help: https://www.youtube.com/watch?v=lyNfnI-B640 simple neovim debugging setup (in 10 minutes)

Thank you. I saw this earlier and am still a little lost. Is there some more information on how to get the Debug test configuration working. He said in the video he wasn't going to go into setting up for that in particular :( . Can you point to some other resource that might help with setting up DAP in more depth?

@AnthonyMBonafide sorry, I don't know. Maybe try asking here:
https://github.com/leoluz/nvim-dap-go

Hey did you install delve? and can you run dlv in terminal. If so then you need to specify some values like port and path in the config and you should be good to go.

@dam9000, I see it listed in the README on how to run them. Could you point me in the right direction of how you would suggest to add this as a key map for Go projects? My thinking at this point is to have a keymap to basically execute :lua require('dap-go').debug_test(). Maybe slightly better would be to have the Debug test option execute that command. Not really sure. Any suggestions?

So you want to translate this vimscript to lua:
nmap <silent> <leader>td :lua require('dap-go').debug_test()<CR>

lua:
vim.keymap.set('n', '<leader>td', function()
  require('dap-go').debug_test()
end, { silent = true, desc = 'Debug Test' })

@dam9000 , yes thank you. Also, how to I configure this just for Go as other languages cannot leverage that? Should I set up that mapping on attach for dap-go ? IDK if that even makes sense or how to do that correctly. I'll look into the docs and if I figure it out I will create a PR.

You can extract nvim-dap-go out of the dependency list of nvim-dap and set nvim-dap-go to load only on ft = 'go'. Then you can set your keymaps in the config function of nvim-dap-go, which will bind the keymap only on plugin load (when you open a file whose filetype is go).

if I figure it out I will create a PR.

I think that nvim-dap-go exists here only to be as an example of how to add language specific debuggers, so providing all of the keybindings may not be a goal

Please seek further assistance at the specific dap adapter's repository.


BIDMach FileSource Adding A Line of 0 Between Data

I piped 2 FMat file (each contains a 1000001*7 matrix) into FileSource and set batchSize = 10000 and dorows = true. But in the output batches, FileSource added a row of 0 between the end of 1st file and the start of 2nd file.
I think the bug might be because that the number of rows in each file is not a multiple of batchSize, but I'm not sure why FileSource would add a line of 0 there. Could anyone take a look to see if there is any subtle bugs, or if this is a intended behavior?
Thanks,
Jack

I'm assuming your file size was 7*1000001. Please try to use file sizes which are multiples of the minibatch size.


Condition failed (debug) in ACesiumCreditSystem::removeCreditsFromViewports

In Visual Studio, build a debug version of the Unreal sample (and plugin)
Press F5 to run
In Unreal, open 04_MAIN_CesiumSublevels in cesium-unreal-samples.
Start Play-in-Editor mode.
Press 4 to fly to Paris.
Once you land, press 1 to go back to Denver

Almost right away, you'll see an exception thrown in Visual Studio...
(you can continue past it though)
Ensure condition failed: !IsGarbageCollecting() [File:D:\build\++UE5\Sync\Engine\Source\Runtime\UMG\Private\Slate\SObjectWidget.cpp] [Line: 43]
SObjectWidget for 'ScreenCredits_C /Engine/Transient.UnrealEdEngine_0:GameInstance_0.ScreenCredits_C_2' destroyed while collecting garbage.  This can lead to multiple GCs being required to cleanup the object.  Possible causes might be,
1) ReleaseSlateResources not being implemented for the owner of this pointer.
2) You may just be holding onto some slate pointers on an actor that don't get reset until the actor is Garbage Collected.  You should avoid doing this, and instead reset those references when the actor is Destroyed.
[2023.06.08-17.03.54:392][209]LogOutputDevice: Error: Ensure condition failed: !IsGarbageCollecting() [File:D:\build\++UE5\Sync\Engine\Source\Runtime\UMG\Private\Slate\SObjectWidget.cpp] [Line: 43]
SObjectWidget for 'ScreenCredits_C /Engine/Transient.UnrealEdEngine_0:GameInstance_0.ScreenCredits_C_2' destroyed while collecting garbage.  This can lead to multiple GCs being required to cleanup the object.  Possible causes might be,
1) ReleaseSlateResources not being implemented for the owner of this pointer.
2) You may just be holding onto some slate pointers on an actor that don't get reset until the actor is Garbage Collected.  You should avoid doing this, and instead reset those references when the actor is Destroyed.

[2023.06.08-17.03.54:392][209]LogStats:             FDebug::EnsureFailed -  0.000 s
UnrealEditor-Win64-DebugGame.exe has triggered a breakpoint.

Thanks @csciguy8. The good (but not great) news here is this isn't an exception but an assertion, and it's essentially asserting to avoid a (basically irrelevant in this case) performance problem. So it won't show up in release builds, and it's only embrassing rather than actually harmful. We should see if there's an easy fix, but there may not be.

Looked for an easy fix, and haven't found one yet. It's a bit of guess and check, trying different changes with ACesiumCreditSystem.
Here's what I've found:

Seems to be specific with destination 4 (Paris) in 04_MAIN_CesiumSublevels
This destination is the only one that calls ACesiumCreditSystem::BeginDestroy when you fly away from it
Commenting out AddToViewport and RemoveViewport in ACesiumCreditSystem makes the assertion go away, hinting it's related to these two calls
Moving the call this->removeCreditsFromViewports() from ::BeginDestroy to ::FinishDestroy didn't fix it


Display the quota description instead of repeating the number

Added some code to check if description is present and then display it instead of repeating the order number.

Good job @amonaco :beer:


Info of the code

Is it possible to get a description of the code architecture?
Where are the results output?
How can the results be consulted what format do they have?

Once I run the test how can I view the results what are the references?

Hi @FrancescoArcuri13 . This is a research project, and it’s not under active development. You will need to read the code to figure out the answers to these questions.
If you would like to submit a PR with documentation, we would be happy to include it.


Who can explain me define $MODEL_NAME_CAMEL$ in php file stub

help I need something like that in :
\vendor\infyomlabs\laravel-generator\templates\scaffold\controller\controller.stub
     $theme = $this->gettheme();
     $name_set_magic$ = ucfirst($MODEL_NAME_CAMEL$);
    Theme::set$name_set_magic$($$MODEL_NAME_CAMEL$);

PHP function names are case insensetive so you can just put:
Theme::set$MODEL_NAME_CAMEL$($$MODEL_NAME_CAMEL$);
Otherwise, Theme::set$MODEL_NAME$($$MODEL_NAME_CAMEL$); if your model names are TitleCased.
Or Theme::set$MODEL_NAME_HUMAN$ if they don't contain underscores.

Good.  Thank Your comment
😊


Help understanding traffic flow

Traffic flow is described as:

But the rendered templates suggest, that a "plain old" ClusterIP k8s service is used to route traffic into the data-plane (traefik daemonset). Doesn't that imply, that we absolutely can NOT guarantee, that traffic gets sent to the traefik-pod on the same node? A service will route the traffic to SOME traefik-pod on SOME node, right?
Edit: typo and replaced wrong flow image

Hello @erdii,
you are correct. Services exposed via ClusterIP will be assigned traffic by kube-proxy based on the round robin algorithm.
This image has been created in order to make the traffic flow better visible und understandable, even tough it might not be 100% accurate. However, it helps in showing the concept behind it :)
As we want maesh to be non-invasive, we're not aware of a solution to make that flow 100% guaranteed. One possible option would be to set the kube-proxy into VPS mode, however, we wont take that cluster-wide actions.

Hey @SantoDE! Thank you for your answer.
I really like the idea of a non-invasive service-mesh that only deploys one agent per node, but the ClusterIP load-balancing basically circumvents the whole idea behind a service-mesh.
Say: I want to secure my "in-cluster" pod-to-pod communication with tls and decide to offload tls handling to maesh. Now I have a false sense of security, because I think, that "inter-node" pod-communication is TLS secured, but there can happen one "cleartext" hop to another node.
Maybe you could expose the local node ip to a mesh-consumer via fieldRef to "status.hostIP" and expose maesh via host-network? This, too is a hack but it would ensure that "inter-node" mesh traffik passes through the local traefik instance.
status.hostIP example: https://stackoverflow.com/a/57325211

Thanks for your feedback and suggestions @erdii.
I'll have a look and take it into account. Thanks a lot!