SSL certificate not presented for 2nd transactions.

We have a system where our load balancer user client cert CN and to double-check if the cert is correct. When we are sending requests from Spring cloud gateway CN is resolved in the first transaction but 2nd transaction onwards Client cert is not presented to the server as httpClient creates a connection pool.
Tried to disable HTTpclient pool using
httpclient:
        pool:
          type: DISABLED
          max-connections: 5
          acquire-timeout: 5
          max-idle-time: 10
          max-life-time: 0

But no luck, 2nd transaction onward certs are not being presented to the Server. Seems like HttpClient used is stateful and not stateless.

I'm having a bit of trouble following. Where is the certificate validation happening? I don't understand the issue of statefulness of HttpClient with regards to certificates.

Spring gateway is communicating with SSL enabled server and certificate validation happens there. Every time HTTP requests to SSL enabled server it's resolving the CN information based on the client certs. This is working fine with Apache HTTP calls, but the same is not working in the spring cloud gateway. Also in spring cloud gateway, 1st transaction works fine and CN information is resolved correctly, whereas 2nd transaction CN information is not being resolved.

what's the difference between 1st transaction and 2nd transaction, do you mean http request? Have you installed the certificates in the jvm or configured HttpClient to know about them?

There is no difference between these HTTP requests. Hitting the same API back to back.  Configuring with HTTPClient SSL properties. Below is my sample SSL properties
 httpclient:
        ssl:
          key-store: client-key-store
          key-store-password: *******
          trustedX509Certificates:
             - client-truststore.pem
          handshake-timeout: 500
          close-notify-flush-timeout: 3
          close-notify-read-timeout-millis: 0

Can you provide you full configuration rather than snippets here or there? You've also not said what version you are using.

Sorry, using
<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.7.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
<properties>
        <java.version>1.8</java.version>
        <spring-cloud.version>Hoxton.SR4</spring-cloud.version>
    </properties>

HttpClient configuration :
spring:
  cloud:
    gateway:
      metrics:
        enabled: true
      httpclient:
        pool:
          type: DISABLED
          max-connections: 5
          acquire-timeout: 5
          max-idle-time: 10
          max-life-time: 0
        ssl:
          key-store: client-key-store
          key-store-password: *******
          trustedX509Certificates:
             - client-truststore.pem
          handshake-timeout: 500
          close-notify-flush-timeout: 3
          close-notify-read-timeout-millis: 0

My Routing config :
@Configuration
@Slf4j
public class GatewayConfig {

    @Bean
    public RouteLocator myRoutes(RouteLocatorBuilder builder) {
            return builder.routes()
                    .route(p -> p
                            .path("/r/test/**")
                            .uri(""http://myurl.com"")
                    .route(p -> p
                            .path("/t/test123/getTestMapping")
                            .uri(""http://myurl.com"")
                    )
                    .route(p -> p
                            .path("/**")
                            .uri("http://myurl.com")
                    .build();
    }
}

Can you turn on wiretap to see if the client is sending the cert spring.cloud.gateway.httpclient.wiretap=true?

yes, 1st transaction gives something like this, but 2nd one onwards don't have handshake logs.
DEBUG [reactor-http-epoll-3] io.netty.util.internal.logging.AbstractInternalLogger: [id: 0x5ecc8e90] REGISTERED
DEBUG [reactor-http-epoll-3] io.netty.util.internal.logging.AbstractInternalLogger: [id: 0x5ecc8e90] CONNECT:myurl.com/<IP_ADDRESS>:443:443
DEBUG [reactor-http-epoll-3] reactor.util.Loggers$Slf4JLogger: [id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443:443] Connected new channel
DEBUG [reactor-http-epoll-3] io.netty.util.internal.logging.AbstractInternalLogger: [id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443:443] ACTIVE
DEBUG [reactor-http-epoll-3] io.netty.util.internal.logging.AbstractInternalLogger: [id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443:443] READ COMPLETE
DEBUG [reactor-http-epoll-3] io.netty.util.internal.logging.AbstractInternalLogger: [id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443:443] READ COMPLETE
DEBUG [reactor-http-epoll-3] io.netty.util.internal.logging.AbstractInternalLogger: [id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443:443] READ COMPLETE
DEBUG [reactor-http-epoll-3] io.netty.handler.ssl.SslHandler: [id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443:443] HANDSHAKEN: protocol:TLSv1.2 cipher suite:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
DEBUG [reactor-http-epoll-3] io.netty.util.internal.logging.AbstractInternalLogger: [id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443:443] USER_EVENT: SslHandshakeCompletionEvent(SUCCESS)
DEBUG [reactor-http-epoll-3] reactor.util.Loggers$Slf4JLogger: [id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443] onStateChange([connected], SimpleConnection{channel=[id: 0x5ecc8e90, L:/<IP_ADDRESS>:5215 - R:myurl.com/<IP_ADDRESS>:443:]})

Didn't see anything in the logs for certs,  added logging level
logging:
  level:
    root: debug
    org.springframework.cloud.gateway: TRACE
    reactor.ipc.netty: TRACE
    reactor.netty: DEBUG
    reactor.netty.tcp.TcpClient: DEBUG

Anything else I am missing?
Appreciate your help and time.

Yes, certificate is being sent. Think something wrong at our end.
Appreciate your time and help. Thank you


Add a generic Atomic type

Relevant issues: #1125 rust-lang/rust#24564
Relevant discussion in internals
Rendered

Dup of https://github.com/rust-lang/rfcs/pull/1477

It's not exactly a duplicate. The proposed approach is completely different. #1477 only talks about changing unstable intrinsics while this RFC proposes adding a new stable atomic API.

Right, that's true. It might be worth mentioning #1477?
Nonetheless, I :+1: this, since this will make everything much easier.

For people coming from C++ (which is Rust's target audience), there needs to be an equivalent of std::atomic. So I welcome this RFC.

Thanks for the RFC @Amanieu! I've also wanted this from time to time, although there's a number of questions I've had that I unfortunately haven't been able to answer in the past. I'm curious as to your thoughts on:

What does the compiler do on Atomic::<[u8; 4096]>::load()? This can either happen directly or through a very long chain of monomorphizations, and this RFC means that we'll be introducing a vector for monomorphization-related errors. I could, for example, expose an abstraction where just by linking a crate and instantiating some types I get a super obscure error. We've done our best in the compiler to avoid this so far.

I'm not certain that all platforms even support atomic operations with the size different than the pointer size. For example I wouldn't be confident in saying that all platforms support byte-level atomics (they might though!). This RFC indicates that we will guarantee this operation up to the pointer size, but do you know if this applies to all possible architectures we could port to?

From an API perspective, the differences in API surface area means that this won't be a very usable type if you only take Atomic<T>. If any consumer is taking Atomic<isize> then it seems not that different from taking AtomicIsize? Along these lines, I found it tough to motivate to myself having a generic type. You mention that this RFC is motivated by double-word-size atomics as well as known-32-bit ones, but is there a benefit to a <T> vs AtomicT? (note that not being generic would solve the first question I had).

Currently the standard library is principled in the sense of all exported types are those supported on all platforms. We have a system for platform-specific types (the std::os::* modules), but we don't currently have a system for architecture specific modules. I think that we'd want to try to avoid using platform-specific types without any sort of opt-in (like importing a std::os module). This would help audit a code base for what's using platform-specific operations. It sounds like, though, some of these types (or at least some monomorphizations) would be platform-specific, which may be unfortunate.

Curious to hear what you think about these!

I feel like the bitwise comparison is more significant than what's written here (which is differing struct padding). In particular, Rust generally avoids thinking about object identity, instead focusing on actual values/semantic comparison. Thus, compare_exchange doing a bitwise/identity comparison could lead to surprising results since the API isn't matching broader Rust expectations. For example, the compare_exchange in following example may fail:
let atomic = Atomic::new(&1);
let old = &1;
assert!(atomic.load() == old); // passes
atomic.compare_exchange(old, &2); // fails

(The orderings don't matter, and this may not compile as written due to lifetimes, and optimisations may use the same pointer for the two &1s, but one can easily come up with a small perturbation of that core example that will demonstrate the problem in practice. I'm using that simple form to focus on the underlying problem.)
I idly wonder if it might be better to have T in Atomic<T> (or maybe just a bound on T for the compare_exchanges) bounded by an additional trait representing that bitwise comparisons are OK, which would cover all the existing atomic types, and more, but not types like references. This trait would basically refine PartialEq or Eq, like Copy refines Clone, and we could have struct BitwiseCmp<T>(T); to force bitwise comparisons. The trait bound means the above example won't compile directly. If one definitely wants that behaviour, one uses the BitwiseCmp struct hence being explicit that something unusual might be happening:
let atomic = Atomic::new(BitwiseCmp(&1));
let old = BitwiseCmp(&1);
atomic.compare_exchange(old, BitwiseCmp(&2));

I'm on the fence about this:

on one hand, we haven't necessarily had the best experience with fancier stuff like this (e.g. Eq refining PartialEq can be confusing for newcomers, and many people aren't big fans of the recover-safety stuff); but
on the other, the more specialised nature of this situation likely means use of a wrapper like BitwiseCmp is reasonable rare, because one is either using types which naturally do bitwise comparisons (integers, raw pointers) or is using a special type(s) (like crossbeam's Shared) for which one can easily implement the trait.

Also, some thoughts I had while writing this:

mismatching comparisons behaviours could lead to unsafety, i.e. one sees the compare_exchange succeed, and uses that to assume some property of a value (i.e. it's equal to something else) that is then used in unsafe code. However, this seems like it would generally occur in a positive sense (i.e. relying on equality, not inequality), and the reasoning works fine in these cases if bitwise equality implies semantic equality.
bitwise equality doesn't imply semantic equality in all cases, both in theory (one can implement PartialEq in anyway, including rand()) and in practice (float NaNs with identical bit patterns don't compare equal). This means that a condition like if atomic.compare_exchange(old, new) == old could possibly never succeed if old somehow gets set to NaN (note that this can't/shouldn't be optimised down to use the direct success/fail indicators the instructions have, like the zero flag on x86, because that would change behaviour). However, I imagine using atomic floating point values is rare, getting a NaN atomic float is rarer, and, in terms of the worst consequences, relying on a float value for unsafe seems like it would be rather unusual.

(These are both addressed by having a bound more specific than Copy.)

Lastly, diving into pedant-land, some types have undefined values (bit patterns that should never occur, or are only valid sometimes) such as references and enums. These types need to be careful that it is only possible to read values that have been written to them, and certain uses of Relaxed memory orders don't prohibit out-of-thin-air reads that return a "random" value e.g. 1, 2 (this second one implies that C++ is outlawing OoTA reads, but I'm lead to believethat the approach for doing this without inhibiting optimisations makes the standard incoherent/inconsistent). However, this doesn't occur in practice, and so can probably be ignored.

I'm not certain that all platforms even support atomic operations with the size different than the pointer size. For example I wouldn't be confident in saying that all platforms support byte-level atomics (they might though!). This RFC indicates that we will guarantee this operation up to the pointer size, but do you know if this applies to all possible architectures we could port to?

Do we need to guarantee that Atomic<u8> is literally operating on bytes? I.e. can we pad it out to Atomic<usize>? I suppose this may make an operation like atomic.fetch_add(1) more complicated/expensive to handle the overflow case, and may be a foot-gun in that *const u8 can literally not be converted to a *const Atomic<u8> in place (although this seems like a bad idea anyway).

From an API perspective, the differences in API surface area means that this won't be a very usable type if you only take Atomic. If any consumer is taking Atomic then it seems not that different from taking AtomicIsize? Along these lines, I found it tough to motivate to myself having a generic type. You mention that this RFC is motivated by double-word-size atomics as well as known-32-bit ones, but is there a benefit to a  vs AtomicT? (note that not being generic would solve the first question I had).

One might want to be working with some "random" type, e.g. a state-machine enum, or a wrapper for type safety. For instance, crossbeam's internal Atomic is a wrapper around AtomicPtrs, but all the raw pointers it stores are really Shareds, and hence being able to store a Atomic<Shared<...>> instead would reduce the amount of "unnecessary" unsafe that's just doing conversions between Shared-stored-as-raw-pointers and Shared itself.

Platform support for non-pointer-sized atomics isn't an issue. The only number that matters is the largest size that a platform can perform a compare_exchange on. All smaller operations can be emulated using that. For example a byte atomic can be emulated by using a compare_exchange loop that only modifies a single byte of the value. This is actually how LLVM implements byte-level atomics on MIPS, which only supports word-sized atomics native. Note that the out-of-bounds read is fine here because atomics are aligned and will never cross a page boundary. Therefore it is perfectly safe to have sizeof(Atomic<u8>) == 1 on MIPS.

Regarding monomorphization: the specific constraint that we are looking for is sizeof(T) <= target_max_atomic_size. I don't think there is any good way of integrating this with the traits system. Consider struct S<T>(T, T): how can you describe whether S<T> can fit inside an atomic? Unfortunately I don't know of any good solution for this. We could go with the C++ approach of automatically falling back to a lock-based implementation of atomics, which is implemented in compiler-rt, however we then need to add an API to determine whether a certain atomic type is 'lock-free'. This property is important for dealing with interrupts or signal handlers where the use of locks can result in a deadlock. Also note that the compiler-rt implementation will not work in an embedded/kernel environment.

I disagree that Atomic<T> isn't a very usable type. The load, store, swap and compare_exchange methods are available for all atomic types. All of the extra methods on the specialized bool and integer atomic types are available for convenience and/or performance. Any atomic operation can be emulated using a compare_exchange loop. The specialized implementations of Atomic<T> for bool and integer types mirror the implementation of std::atomic<T> in C++, which has specializations for those types.

I don't think bitwise comparisons are a big issue as long as we make this clear in the documentation. compare_exchange in C++ is defined as performing a comparison in terms of memcmp, even if T has an overloaded comparison operator. However I propose that we offer slightly stronger guarantees than C++ regarding padding bytes. This is because Rust has an implementation-defined struct layout, which means we could in theory be inserting padding behind the user's back, which would break comparisons.

Another note regarding the monomorphization and bitwise comparison issues: keep in mind that atomic types are generally used as a low-level implementation detail, which means that T will usually be defined within the same module, and almost certainly from the same crate. Creating an Atomic<T> with a T that comes from outside the crate will be an extremely rare occurence.

Hmm actually it seems that we can't always guarantee that values up to the pointer size are guaranteed to be atomic. This is only an issue for platforms that don't support atomic operations natively, such as ARMv5.
On ARMv5, AtomicUsize::fetch_add is compiled to a call to __atomic_fetch_add_4, which is implemented in compiler-rt using spinlocks. This may violate the guarantees we have for AtomicUsize.
But my point here is, what should we do about architectures like ARMv5 that don't support native atomic operations at all? Should we disallow atomics entirely? Should we silently fall back to lock-based implementations?

Expanding a little on @Amanieu's notes about locks above:
In considering this, it's probably important to understand how C++ handles a similar question in it's std::atomic<T>.
C++ considers atomic and lockfree 2 separate questions: all T can be used in std::atomic<T>, but not all std::atomic<T> are lockfree. One can determine if a given T will be lockfree in an std::atomic by asking std::atomic_is_lock_free.
This separation is done to allow users to write code that uses std::atomic without needing customization on a per-platform basis (platform customization is handled in libstdc++ rather than user code). Essentially, it allows taking advantage of platform features where available, but avoids needing to specialize code on a per platform basis (an admirable goal).
For a generic atomic to make sense in rust (much like in C++), we need it to work for all types. Platform based restrictions here would greatly hamper usability of the standard library.
It might be useful to have lockfree-only variants for use in problematic areas as noted by @Amanieu above (interrupt handlers, signal handlers) but I'm not sure rust is very well specified in those areas to begin with. To take the case of signal handlers, POSIX has a different (and incredibly more restrictive) set of rules there than it does for separate threads. At some point we'll need to handle them, but right now we lack any rules about them (AFAIKT), so I don't think it would be a good idea to allow them to restrict Atomic<T>.

@Amanieu
Ah sorry for being a little slow to respond, but thanks for the responses! I hadn't actually considered implementing Atomic<u8> in terms of word-sized reads/writes before, but that does seem to be a reasonable implementation to me. To me at least it seems like quite an important semantic of the implementation, however, so could you add that to the RFC?
I would personally not want the standard library to back atomics with mutexes, it's too sweet of a name to silently switch to something so heavyweight behind the scenes (easy to forget). I also agree that threading this through the trait system is probably not possible, but it's also a serious drawback in my mind in the sense that I would personally consider it a non-starter.
I guess it's true, yeah, though that compare_exchange plus some trait bounds on T could indeed be useful in terms of implementing a general algorithm. Seems good to me!

@alexcrichton I've added a note about this to the RFC. Note that this emulation is done transparently by LLVM, so there is nothing we need to do on the Rust side to support it.

I would personally not want the standard library to back atomics with mutexes, it's too sweet of a name to silently switch to something so heavyweight behind the scenes (easy to forget). I also agree that threading this through the trait system is probably not possible, but it's also a serious drawback in my mind in the sense that I would personally consider it a non-starter.

I only see two approaches for supporting generic atomic types:

Fail at monomorphization time for over-sized types, since the size constraint can't be represented using the trait system. Users will need to use #[cfg] to determine if the appropriate atomic type is supported.
Automatically fall back to a mutex-based implementation for over-sized types. Note that even in this situation we can still guarantee sizeof(Atomic<T>) == sizeof(T) by having the mutex in an external array (which is what compiler-rt currently does).

Other approaches (in this thread) only support implementing atomic operations for specific types, such as i32/i64/i128. This still doesn't solve the problem of some types only being available on certain architectures (or even different versions of the same architecture).

I would personally not want the standard library to back atomics with mutexes, it's too sweet of a name to silently switch to something so heavyweight behind the scenes (easy to forget).

I can't agree with this. "Atomic" has a semantic meaning that doesn't mean "native CPU instructions for atomic operations." Those just happen to be used if available.
There's also a solid argument to be made that if C++'s std::atomic falls back to mutexes, that behavior is likely to be good enough for Rust too.

[...] it's too sweet of a name to silently switch to something so heavyweight behind the scenes (easy to forget).

@alexcrichton Wouldn't LockFree be an even sweeter name for lock-free data types? For just two characters more you get disambiguation and unblock yet other sweetness. :honey_pot: :cake: :lollipop:
Really, though, I think the semantics for the identifiers (A|a)tomic have already been determined by the present zeitgeist in the vein of C++. Rust may not be C++, but here it's borrowing an identifier already in vogue.

too sweet of a name

Atomic describes how accesses behave, but not how they are implemented. It is the intersection between Mutex and LockFree, specialized based on the type requested and the system on which it is running.
I think it would be more of a waste to make it equivalent to LockFree when it could be so much more.

The JVM atomic types (AtomicBoolean, AtomicInteger etc.) also fall back to locking on some platforms:

The specifications of these methods enable implementations to employ efficient machine-level atomic instructions that are available on contemporary processors. However on some platforms, support may entail some form of internal locking. Thus the methods are not strictly guaranteed to be non-blocking

There's quite a bit of precedent behind making "atomic" mean "lock-free if possible, but falls back to locks if needed."

I'm personally very weirded out if we ever pull in a huge amount of support for compiler-rt. That's a dependency pulled into all rust projects in existence so we need to control it and understand it as much as possible. I would very much prefer to write any support we need in Rust itself so we understand the pain we're going through to do that. To me having an array of global locks is distasteful enough that we shouldn't export it as a cross-platform interface in the standard library, for example.
It's basically just my own personal opinion that atomics should map to instructions, not mutexes. I haven't done much with atomics in C++, but I would personally avoid them in situations where they fell back to mutexes.
To me at least it seems like a cross-platform Atomic<T> story is bleak enough that we may not want to pursue it at this time. We may want to start thinking harder about how to have architecture specific types which would allow us to add a suite of types like this.

I'm personally very weirded out if we ever pull in a huge amount of support for compiler-rt. That's a dependency pulled into all rust projects in existence so we need to control it and understand it as much as possible.

Fair point, but using compiler-rt is entirely orthogonal to the question "should Rust have an Atomic<T> type that falls back to a mutex on some platforms."
Like you, I too would prefer a Rust solution.

It's basically just my own personal opinion that atomics should map to instructions, not mutexes. I haven't done much with atomics in C++, but I would personally avoid them in situations where they fell back to mutexes.

That seems like a fine personal/per-project decision, but not a great "global" one. Lots of people want a type that means "atomic access that's as fast as possible, but always correct" which is what std::atomic and the Java atomics provide.
It makes complete sense that some projects want something else, which would be direct use of a LockFree<T> type that never falls back to a mutex but isn't available everywhere (and which would limit the portability of their code, but that's their choice).

To me at least it seems like a cross-platform Atomic story is bleak enough that we may not want to pursue it at this time.

This runs counter to the conclusions of the C++ standards committee and the engineers who work on the JVM. There is a direct need for a type like this (as evidenced by C++, Java and this RFC), and Rust should have it. There's a stark difference between "I don't need this" and "nobody should ever need this."
Like I mentioned above, having an Atomic<T> type that behaves the same way similar constructs work in Java & C++ does not preclude having a LockFree<T> type as well.

The global mutex thing feels very strongly like something that should live in a library to me.  In fact, I think it could be done in regular Rust code today.  Each atomic method would at "runtime" switch on the return value of size_of, transmute to the appropriate pointer type, and do the atomic operation on that; LLVM would remove the unnecessary branches.  For unsupported types, you'd fall back to mutexes.  (You’d have to bake in assumptions about what sizes of integer can be subject to atomic operations, but there are many ways Rust could convey that static information to code in the future.)
The case this approach falls down in is if you don't want the global mutexes and thus want an unsupported size to produce some sort of error at trans time.  I guess you could hack it with asm!...

I feel like having Mutex as fallback introduces a hidden cost. It takes away the very purpose of atomic values.

It takes away the very purpose of atomic values.

I strongly object. While every "atomic" operation that falls back to the mutex now involves multiple hardware operations, it's still very definitely atomic in the sense of the word as intermediate states are not observable from safe rust. Similarly, you could argue that x86's atomic instructions aren't really atomic because they may cause bus locking.
The alternative of erroring out may look like a speedbump against accidental mutexes, but I'd argue that this works poorly in practice: Nowadays, with x86 everywhere, Rust projects are rarely going to be developed on multiple platforms, so many developers probably wouldn't hit the error that their code is incompatible with e.g. ARM. This introduces a huge portability hazard: You'd be unable to use crates unless the author specifically thought of your architecture (or you're lucky, of course). It essentially blows up the ecosystem into many tiny fragments. Falling back to a mutex here makes things slower, but it works. A potential performance footgun is an easy sacrifice to make when it allows us to maintain something as big as cross-platform compatibility - especially as I'd expect atomic variables to mostly be used by experienced programmers anyways who understand the pitfalls.
Now when a crate's developer does care about platforms where the fallback would occur, they can just branch on Atomic<Foo>::is_hardware_accelerated() (or whatever) to do something faster instead and LLVM would optimize the other path away. Now that I think of it, the proposed cfg conditionals are probably better as they allow customized data structures as well - although a classic if-else like here always feels a little awkward to me with cfg (because you're forced to repeat the condition).
tl;dr Mutex fallback is unfortunate but I consider it unavoidable.

Is there any reason we couldn't put the Mutex inside the Atomic in the cases where the mutex fallback is required, instead of the global mutex array thing? That seems like the normal and obvious thing to do. I assume there must be some reason why the existing approaches had to go with the less-obvious solution instead but I'm not aware of what it is.

The downside of including a Mutex inside the atomic is that you won't be able to transmute &Atomic<T> to &T, which might be necessary for passing it to the futex system call for example.

@Valloric

There is a direct need for a type like this (as evidenced by C++, Java and this RFC), and Rust should have it. There's a stark difference between "I don't need this" and "nobody should ever need this."

Ah sorry I think I'm not communicating my preference here clearly. The precedence of other languages doesn't mean much to me in terms of what the API of the standard library should look like, but rather what it should have. I agree that concrete types like AtomicU{8,16,32,64} seem quite useful but to me they belong in an architecture specific module rather than std::sync::atomic.
I'm all for providing primitives, but having a heavyweight runtime implementation with global mutexes or out of bounds reads to me sounds like a library implementation detail, not something exported as an atomic primitive (as those implementations indeed aren't primitive).

@main--

It essentially blows up the ecosystem into many tiny fragments

To me this is true, but no more so than the Unix/Windows support in the standard library. We do a "best effort" to provide cross platform APIs, but whenever you need something specific we provide the ability, it just needs to be forcibly opted into.
For example maybe these types are only available in std::arch::x86 or std::arch::x86_64. A library could then provide atomics which fall back to mutexes (with all the crazy logic for doing the right thing on each architecture), but in my opinion the standard library shouldn't be doing it right now.

global mutexes or out of bounds reads to me sounds like a library implementation detail

That is a library impl detail. The a user of Atomic wants atomic operations as fast as the platform can provide them. Sometimes mutexs (or some other lock-like item) will be the fastest way.

I'm all for providing primitives, but [...]

I think the problem is thinking about this as a guaranteed primitive. It isn't (or at least, shouldn't need to be). It is a generic mechanism that may take advantage of those primitives in a convenient and portable way.

A library could then provide atomics which fall back to mutexes

Potentially, though this is made less-good by the lack of the type system knowing the size of a type (and probably forces a switch for supported sizes).
And we could say "should be in a library" about nearly everything in rust. I'd expect that std should at least attempt to provide a platform abstraction (it does for Mutex and friends, after all). What makes Atomic<T> not appropriate where Mutex<T> is?

I agree strongly with @alexcrichton here - a heavyweight fallback seems distinctly unrusty to me. It masks the performance implications of atomic operations, doesn't map clearly to a system primitive, and is likely to have odd differences in behavior.
I also feel very nervous about adding the possibility for a compile failure at monomorphization time! Checked generics (generics that are checked at the definition site not the usage site, like C++ templates) are one of rust's best features in my opinion. Violating this property is a very slippery slope to go down, and we've resisted adding other more useful features, like type-level numbers (which would allow implementing this whole scheme outside of std), without a solution to this problem.
I also agree with @alexcrichton that we should just provide zero-cost architecture specific atomics in architecture specific modules and allow library authors to play with heavyweight fallbacks.

@alexcrichton so I take it you would prefer something similar to this:
#[cfg(target_has_atomic = "8")]
struct AtomicI8 {}
#[cfg(target_has_atomic = "8")]
struct AtomicU8 {}
#[cfg(target_has_atomic = "16")]
struct AtomicI16 {}
#[cfg(target_has_atomic = "16")]
struct AtomicU16 {}
#[cfg(target_has_atomic = "32")]
struct AtomicI32 {}
#[cfg(target_has_atomic = "32")]
struct AtomicU32 {}
#[cfg(target_has_atomic = "64")]
struct AtomicI64 {}
#[cfg(target_has_atomic = "64")]
struct AtomicU64 {}
#[cfg(target_has_atomic = "128")]
struct AtomicI128 {}
#[cfg(target_has_atomic = "128")]
struct AtomicU128 {}

Note that the existing atomic types are already dependent on the target architecture supporting atomic operations. It just so happens that all currently supported targets (tier 1, 2 and 3) all support atomic operations natively.

@reem

which is extremely unexpected behavior for an atomic primitive.

Yes, this is why LockFree was brought up way back in the comment thread. To have proper support for signal handlers, we'd want something restricted to LockFree operations. That doesn't mean we can't also have a completely generic Atomic. (an alternate here is something akin to Sync, but it isn't clear to me that we can provide a useful Sync-like rule for the compiler to apply).

availability of this type with similar semantics in other languages is not a convincing argument on its own

Which is why there have been other arguments. On the other side of this, we should be careful not to ignore why other languages chose to do things in some manner. We've got a lot of resources we can take advantage of by looking at other language designs.

@alexcrichton Note that my worries are specifically about a generic atomic type. With the approach you have in mind where concrete types are available under architecture-specific modules, I do agree that the issue is much less severe as programmers would then explicitly opt in to cross-platform incompatibility.

@jmesmon

And we could say "should be in a library" about nearly everything in rust.

Certainly! Here we're talking about the standard library, however, rather than just any old library. The standard library, in my opinion, is where you go for types that have clear and concise implementations and semantics. For example a Mutex<T> has an obvious implementation, and it's quite clear what the semantics are going to be.
An Atomic<T> backed by a mutex has very different semantics than if it's an atomic operation in terms of instructions. Signal handlers are a good example here, you could imagine others (like concerns with green threading perhaps) where a mutex is unfortunately inappropriate.
I certainly agree that there are many users who "just want the fastest thing" or "just want an AtomicU64", but this is what I think crates.io is for. The library would probably have something about locks in the name and be super clearly documented as having fallback implementations on various architectures.

@Amanieu

so I take it you would prefer something similar to this:

Along those lines, yeah! I'd specifically be thinking of having architecture-specific modules (similar to std::os::{macos, linux, windows, ...} to have all the concrete types:
std::arch::x86::{AtomicU8, ..., AtomicU32};
std::arch::x86_64::{AtomicU8, ..., AtomicU64};
std::arch::arm::{AtomicU32};

And we may be able to extend that to so we have a std::os::unix-like module which encompasses a bunch of platforms:
std::arch::pointer_width_32::AtomicU32;
std::arch::pointer_width_64::AtomicU64;

Note that the existing atomic types are already dependent on the target architecture supporting atomic operations. It just so happens that all currently supported targets (tier 1, 2 and 3) all support atomic operations natively.

This is certainly quite interesting to me! This is part of where I feel like our story on other architectures is a little lacking. I feel like we don't have a great idea what's going on here. Do you have some specifics we could dig into though? On one hand the ship has sailed here (the Atomic{U,I}size types are stable), but it's important to keep in mind!
Some questions I might have are:

What platforms do we support that don't have atomic operations at all? Is it just ARMv5?
Do platforms we support not have atomic pointer-sized operations?
What platforms fall back to compiler-rt for support of atomic operations?

I'm getting more and more uncomfortable about what operations are silently translated to calls into compiler-rt. We basically have no idea when that library is used or what we need from it. Not to mention it's a huge PITA to build almost everywhere...

Alternately, I don't see why it couldn't be implemented through the trait system:
Have magic traits trait Sizeof<const size: usize> and ditto Alignof.  This could either be automatically implemented for all types (ala auto traits) or, preferably to me, require some explicit attribute to enable.  Either way, for generic types it wouldn't require explicitly writing out under which conditions you have which size, since that's platform dependent and hard to write precisely; the compiler would just implement the traits based on the real calculated size.  In other words, you're basically making the exact contents of the type a potentially breaking API detail, modulo small changes that will never change the machine layout, like changing one pointer type to another.  This is okay, at least with an explicit attribute, because most of the small types you'd expect atomics to work on are never going to change layout, e.g. all smart pointers are always going to be pointer-sized.  You'd have to be careful with the extent to which Option layout optimizations and such are stabilized, though.  (That said, atomics are not the only use case for explicit sizing - with specialization it may occasionally be beneficial to have optimized container layouts for specific sizes of inner type, but that too would usually be relevant for types at most, say, twice pointer sized.)
Implementation-wise, this would require doing type memory layout much earlier than it's currently done, which probably makes it difficult, but I think that should be done anyway, for the sake of const fn and such.

@comex

It does, for some definition of "declaration time".  The Atomic<T> type would have a bound on Sizeof*, so specifying an inappropriate type would be an error in the trait system; but since size calculation, which is now part of monomorphization, would have to be done earlier, you could say it's just moving the problem.  However, it's distinct in two ways:

Since Sizeof would be a trait bound, you would have to explicitly specify it in generics structs/enums containing the Atomic.  You couldn't just have an opaque library type Foo<T> with no bounds which will sneakily fail to compile if T is too big, as with monomorphization-time checks today.

In the version I preferred where Sizeof is only derived for types opting in via attribute, library authors can be confident that changing the layout of an exported type won't break clients trying to use atomics on it, because it won't be allowed unless they added the attribute.

*actually, it might have to be something like SizeAtMost.  I was thinking of being able to write, in some future Rust with generic integers, something like where T: Sizeof<size>, size <= 8.  But I guess being able to put expressions in bounds like that is iffy, and even if you could, without Haskell-style existentially qualified types, you'd have to make size an inferred generic parameter on Atomic, which is ugly...   Anyway, those are details.

@alexcrichton

This is certainly quite interesting to me! This is part of where I feel like our story on other architectures is a little lacking. I feel like we don't have a great idea what's going on here. Do you have some specifics we could dig into though?

Here is a quick survey of atomic support for all existing Clang/LLVM targets:
Key: 0 = doesn't support any atomics, X = supports all atomic operations with <= X bits

x86: i386(0), i486(32), i586+(64)
x86_64: 128 if cmpxchg16b is supported, 64 otherwise
ARM: ARMv5 & older(0), ARMv6(32, ARM mode only), ARMv6K(64, ARM mode only), ARMv6T2 (64, ARM & Thumb modes)
ARM-M (microcontroller profile, Thumb only): ARMv6-M(0), ARMv7-M(32)
AArch64: 128
SPARC: SPARCv8(0), SPARCv9(64)
PowerPC: PPC32(32), PPC64(64)
SystemZ: 64
MIPS: MIPS32(32), MIPS64(64)
LE64: 64
WebAssembly: 32-bit(32), 64-bit(64)
NVPTX, AMDGPU, Hexagon, MSP430, TCE, PNaCl, SPIR, XCore, AVR: no atomic support

I'd specifically be thinking of having architecture-specific modules (similar to std::os::{macos, linux, windows, ...} to have all the concrete types:

Note from the list above that there is quite a bit of variation even within a single architecture, so it doesn't really make sense to have a separate set of atomic operations per architecture.

On one hand the ship has sailed here (the Atomic{U,I}size types are stable), but it's important to keep in mind!

Not necessarily. We could argue that Atomic{U,I}size are stable for all currently supported architectures (which all support atomics), but these types may not be available for other (mostly embedded) architectures. We can state that these architectures are only usable with libcore and that libstd requires support for pointer-sized atomic operations.
This is similar to the proposal for float-free libcore which involves removing f32 and f64 from libcore, and only supporting such a configuration with no_std.

I'm all for providing primitives, but having a heavyweight runtime implementation with global mutexes or out of bounds reads to me sounds like a library implementation detail, not something exported as an atomic primitive (as those implementations indeed aren't primitive).

While I agree that a mutex-based implementation may be an issue, the code to use out-of-bounds reads to simulate smaller atomic sizes that natively support is implemented directly in LLVM backends. LLVM will generate the necessary masking and compare-exchange loop inline, without the need to call into compiler-rt.

Do platforms we support not have atomic pointer-sized operations?

All of the platforms we support have pointer-sized atomic operations. The oldest ARM platform that is supported is arm-unknown-linux-gnueabi, which uses ARMv6 (in ARM mode) and thus supports pointer-sized atomic operations. The lack of atomics is only an issue if a custom target spec is used, which is not an "officially" supported target.

What platforms fall back to compiler-rt for support of atomic operations?

The decision to fall back to compiler-rt is done in the LLVM backend based on whether the target architecture has native support for atomics of the required size. If a native operation is not available then it will automatically fall back to a call to compiler-rt.

@Amanieu thanks for the impressive investigation! I think your conclusion about avoiding architecture-specific modules is correct, it seems like that wouldn't benefit much here as there's lots of variance withing the architecture itself.
I wonder, however, if we could possibly use the same principle still, though? Perhaps:
std::sync::atomic::{AtomicUsize, AtomicIsize};
std::sync::atomic::b8::AtomicU8;
std::sync::atomic::b16::AtomicU16;
std::sync::atomic::b32::AtomicU32;
std::sync::atomic::b64::AtomicU64;
std::sync::atomic::b128::AtomicU128;

These modules could all be conditionally defined based on the target_has_atomic #[cfg] proposed in this RFC, and they could correctly take into account various architecture differences like ARMv5 and 128 bit atomics on x86_64.
At that point it boils down to when we define target_has_atomic, and I'd personally be comfortable defining it for any operation that doesn't link to compiler-rt (inline compare-exchange loops seem fine to me).
We in theory may not support platforms that don't have any atomics at all quite that well, but it's sorta the same story for floats? Both the core/std variants are stable, so we unfortunately can't move either easily :(

Actually I would prefer if we also gated the Atomic{I,U}size and AtomicPtr types behind #[cfg(target_has_atomic = "ptr")]. This would not be a breaking change since all currently supported platforms would still have these types available. This would only affect custom targets, which currently fail to link due to missing compiler-rt symbols anyways.
To keep things consistent the new AtomicU* types should also be placed directly in std::sync::atomic, but the type themselves would be gated using #[cfg]. There isn't much point in using a module containing a single type when we can just gate the type itself.
I'll write up a new RFC for this soon.

@alexcrichton  I've created a new RFC: #1543

Thanks @Amanieu! I'll continue discussion of this proposal over there.

What's wrong with
unsafe trait HardwareSupportedAtomic {}

#[cfg(target_has_atomic = "8")]
unsafe impl HardwareSupportedAtomic for u8 {}
#[cfg(target_has_atomic = "8")]
unsafe impl HardwareSupportedAtomic for i8 {}

struct Atomic<T: HardwareSupportedAtomic>;

:bell: This RFC is now entering its week-long final comment period :bell:

My own personal opinion is that I'd rather take the strategy proposed in https://github.com/rust-lang/rfcs/pull/1543 over this one, but the atomic-rs library seems quite promising to fill this gap in the meantime!

Yep, without the type system growing an understanding of the size of a type, I'm not sure we can do better than what atomic-rs provides now. Should probably just keep in mind that this is a use case where a const size_of and type-level integers would be useful.

I'm very late to this party, but I want to first of all thank @Amanieu for the excellent work on this RFC as well as the alternative.
This RFC helped me better understand the motivation behind Atomic<T> -- I always thought it strange to want to write generic code over the T, but that's actually not the main point. The motivation more seems to be that you can use your own distinct types that may happen to be e.g. word or double-word sized. In other words, you are working with a single concrete type, like Atomic<MyType>, where perhaps MyType is a newtyped usize that rules out certain values, or whatever.
(Of course, Atomic<usize> is also more elegant than AtomicUsize, but that's a secondary concern at best.)
That said, due to the various questions about how to handle fallback (or whether to generate errors at trans time), amongst other things, I feel like it's best to provide this kind of support outside of std for the time being, and focus instead on bolstering the basic integer atomics we provide for now. We can always add Atomic<T> later, and no matter when we add it, deprecations would likely be involved.

cc @rust-lang/lang

The libs team discussed this RFC during triage yesterday and the decision was to close this in favor of merging https://github.com/rust-lang/rfcs/pull/1543 instead, thanks regardless for the RFC @Amanieu!


serde_yaml 0.9

serde_yaml 0.9.x now generates documents that are inconsistent with what kubectl (and the rest of the K8s ecosystem) expects (as well as the schemas generated by schemars), see https://github.com/stackabletech/operator-rs/pull/450, https://github.com/dtolnay/serde-yaml/issues/298.
We probably need to figure out a decent strategy for handling this on our end, and discourage use of 0.9 until we have a proper answer.

Looking at the issues for this and seeing how both stackable and the example controllers have upgraded to serde_yaml 0.9 I don't think there's a particular need for us to hold back here anymore.
Our usage of serde_yaml is generally only for tests (it's a dev dep in kube-core + kube-derive) with only one legit use case (config loading) from kube-client.


Allow using uuid_*() functions as defaults in PostgreSQL

Through the use of the uuid-ossp module PostgreSQL allows the using various functions within queries, which includes database column defintions' default values.
This PR adds an exception to getDefaultValueDefinition on PostgresAdapter which will allow using these functions by directly passing them as a string, e.g.:
$this->table('mytable')
	->addColumn('token', 'uuid', ['default' => 'uuid_generate_v4()'])
	->save();

This would fail in the current version with the message
[PDOException]
SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input syntax for type uuid: "uuid_generate_v4()"

If you think there's a different way to do this that could work better then let me know, this was just the first solution that came to my mind.

Codecov Report

Merging #1230 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #1230   +/-   ##
=======================================
  Coverage   72.19%   72.19%
=======================================
  Files          35       35
  Lines        5549     5549
=======================================
  Hits         4006     4006
  Misses       1543     1543

Impacted Files
Coverage Δ

src/Phinx/Db/Adapter/PostgresAdapter.php
92.67% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Seems duplicated to #1065.


fix: Auto update apk branch on each travis build

Fixes #94

Copy correct apk to build environment and upload

@niranjan94 Fixed

Travis build failed due to guava modified header, closing and reopening PR to trigger another build

@niranjan94 Travis is saying that git authentication failed. Can you please take a look?

@iamareebjamal will check that

@iamareebjamal token updated. Works now.


Overhaul the DNS01 solver

Is your feature request related to a problem? Please describe.
cert-manager's DNS-01 challenge support is quite poor. We only support 8 DNS providers and the currently accepted way to add external providers is to create a webhook, which is confusing and difficult for people who aren't able to quickly write and deploy new Go software.
We also don't like maintaining the existing providers as they are hard to test.
We should support lots of DNS providers and offer a fallback that anyone can use without having to fork our webhook-example.
Describe the solution you'd like
I propose to add a DNS01 challenge solver that uses go-acme/lego, and deprecate all existing providers.
This offers over 70 commonly-used DNS providers, and has two fallback options; HTTP request and external program.
A downside is that it appears to be configured explicitly using environment variables, wit no easy option to inject config. This would limit you to one lego issuer.
Describe alternatives you've considered
Implement a go-acme/lego webhook solver and ship it with cert-manager. This may be a better solution, but maybe it would be nicer to have it in-tree?
Explore libdns, which has a better abstraction but supports fewer providers.
Implement a generic webhook solver that uses lexicon or similar and ship it with cert-manager.
Additional context
Inspired by this thread on slack.
Environment details (remove if not applicable):

Kubernetes version: any
Cloud-provider/provisioner: any one of the unsupported DNS providers

/kind feature

This would be amazing; I have some projects which are load balanced between multiple kubernetes clusters for failover reasons and so HTTP-driven verifications don't work. There is a dearth of good DNS01 webhook solvers -- lots of those projects out there, but many of them have various issues. I recently had to update one in order to support a newer version of kubernetes and cert-manager.
Given that there is already what seems to be a well supported acme library in go it seems like a no-brainer to add support for that so that you can handle a large number of different DNS providers; cert-manager is such a fantastic tool for managing letsencrypt (or other ACME) certificates so the lack of DNS01 solvers is a major issue for anyone who has need of that functionality. A lot of time has been spent on various webhooks, but then those webhooks need to be updated and maintained as things in cert-manager change.
If you leave webhook support there to handle anything custom then that allows the community to still expand that but you can handle most DNS providers "out of the box".

This is a great idea! Saw this after commenting on an older issue:
https://github.com/cert-manager/cert-manager/issues/2140#issuecomment-1079417732

/remove-lifecycle stale

/remove-lifecycle stale

/remove-lifecycle stale

Unfortunately this issue has been closed. I too think this would be awesome.
Are there any updates on this? I have found https://github.com/cert-manager/cert-manager/issues/3421#issuecomment-719450646, where this is mentioned. @meyskens


Request/Feature idea: AFSK messenger with DTMF activation to receive

It would be nice to have text messages on radio without activating manually the AFSK receive function. My idea is to have a specific dtmf sequence sent from the TX radio that would be decoded on RX side. If that specific code is received the RX would switch to AFSK receive and would display the message and switch back to FM.
Also this way you could send a message to a specific radio based on ANI ID or to a group.
Thanks.

I'm sure someone will create a fork to do that for you, just not me.


Patch to honour reminders

Could you please apply the patch below?  It means when you run
gcalcli --use_reminders remind ...
you will not get reminded for events with reminders if you they haven't occurred yet.  Eg suppose you have an event in an hour with a popup reminder of 30mins and you run
gcalcli --use_reminders remind 60
you won't get reminded (which is what I would expect)
Cheers
--- /usr/local/bin/gcalcli 2015-02-24 09:14:39.159179052 +1300
+++ gcalcli 2015-02-24 09:12:16.399317717 +1300
@@ -1745,7 +1745,10 @@
         self._IterateEvents(self.now, eventList,
                             yearDate=True, work=self._EditEvent)

-    def Remind(self, minutes=10, command=None):
+    def Remind(self, minutes=10, command=None, use_reminders=False):
+        """Check for events between now and now+minutes.
+           If use_reminders then only remind if now >= event['start'] - reminder
+    """

         if command is None:
             command = self.command
@@ -1765,6 +1768,11 @@
             if event['s'] < self.now:
                 continue

+            # not sure if 'reminders' always in event
+            if use_reminders and 'reminders' in event and 'overrides' in event['reminders']:
+                if all(event['s'] - timedelta(minutes=r['minutes']) > self.now for r in event['reminders']['overrides']):
+                   continue   # don't remind if all reminders haven't arrived yet
+
             if self.military:
                 tmpTimeStr = event['s'].strftime('%H:%M')
             else:
@@ -2115,6 +2123,8 @@
 gflags.DEFINE_bool("dump", False, "Print events and don't import",
                    short_name="d")

+gflags.DEFINE_bool("use_reminders", False, "Honour the remind time when running remind command")
+
 gflags.RegisterValidator("details",
                          lambda value: all(x in ["all", "calendar",
                                                  "location", "length",
@@ -2428,11 +2438,11 @@

     elif args[0] == 'remind':
         if len(args) == 3:  # minutes and command
-            gcal.Remind(int(args[1]), args[2])
+            gcal.Remind(int(args[1]), args[2], use_reminders = FLAGS.use_reminders)
         elif len(args) == 2:  # minutes
-            gcal.Remind(int(args[1]))
+            gcal.Remind(int(args[1]), use_reminders = FLAGS.use_reminders)
         elif len(args) == 1:  # defaults
-            gcal.Remind()
+            gcal.Remind(use_reminders = FLAGS.use_reminders)
         else:
             PrintErrMsg('Error: invalid remind arguments\n')
             sys.exit(1)

Gee sorry about the formatting!  Doesn't look like I could copy and paste the patch in.  I can email it to you if you want, or maybe I'll figure out how to attach files.

I added code fences around your diff to include it.  A pull request would be great, otherwise I'll see about getting this integrated.

I really like this change. Please create a pull request so we can easily merge it in. :-)

git apply works wonders :)
My only note after reviewing this is that it uses FLAGS within the gcalcli class.  Need to clean that up so it's passed to gcalcli like everything else and referenced as a class variable.  (Consistency more than anything.  FLAGS.allday does this as well.. le sigh)


I think we lost column position/rank

Terms in Chris Mungall's  mixs_source repo had Position comments. I think that reflected the ordering in the MIxS 6 Google Sheet. I might have eliminated that in my transition from comments to annotations. Should we add it back in?
See https://cmungall.github.io/mixs-source/size_frac/

Would probably be best to use the new rank alot.

We have a new rank slot. It may need work, but we don't need to worry about losing the information from the google sheet.


Failing to recommend right class

The extension is really missing the point, please find the screenshot, it is failing to make right recommendation over intellisense. Am I missing something here? Would be great if it is fixed. Thanks.

..and it worked fine after installing the HTML CSS support plugin, is this a prerequisite?

Woah, that's really weird, that's one example of usage I always attempt to do by myself when using Bootstrap for example and it always work. I wonder if it could be conflicting extensions.


To remove duplicates and keep order

bearophile_hugs reported this on 2013-05-21T16:59:50Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=10131
CC List

greensunny12
razvan.nitu1305

Description
I suggest to add to Phobos a function with semantics similar to this one, that sometimes I find useful:

T[] noDupes(T)(in T[] s) {
    import std.algorithm: canFind;
    T[] result;
    foreach (T c; s)
        if (!result.canFind(c))
            result ~= c;
    return result;
}

void main() {
    import std.string: squeeze;
    assert("AAAA".noDupes == "A");
    assert("AAAA".squeeze == "A");
    assert("ABAC".noDupes == "ABC");
    assert("ABAC".squeeze == "ABAC");
}

Notes:
- It's related to std.string.squeeze and std.algorithm.uniq, but they need the items to be sorted to remove all the duplicates, while the function discussed here doesn't change the order of the items.
- The implementation shown here is slow, O(n^2), because it's meant to just show the semantics clearly. If the items are hashable it's possible to create a O(n) implementation, storing the items in a hash. If the items are comparable it's possible to write a O(n ln n) version that creates an array of sorted pointers and then performs binary searches on it. The O(n^2) version is a fallback if the items are not hashable nor comparable. The three versions are meant to be three parts of the same general function.

greensunny12 commented on 2017-10-10T13:15:12Z
PR https://github.com/dlang/phobos/pull/5774


Document how to use an "early access preview" version of new Keptn's Bridge

Document how to get the early access preview version of Keptn's Bridge in https://keptn.sh/docs/0.6.0/reference/keptnsbridge/

https://keptn.sh/docs/0.6.0/reference/keptnsbridge/#early-access-version-of-keptn-s-bridge
done


fix(actions): enable push for automatic release

Before submitting a pull request, please read
https://github.com/bancolombia/scaffold-clean-architecture/wiki/Contributing
Description
Enable automatic release
Category

[ ] Feature
[ ] Fix

Checklist

[ ] The pull request is complete according to the guide of contributing
[ ] Automated tests are written
[ ] The documentation is up-to-date
[ ] The pull request has a descriptive title that describes what has changed, and provides enough context for the changelog
[ ] If the pull request has changed structural files, you have implemented an UpgradeAction according to the guide
[ ] If the pull request has a new Gradle Task, you should add Analytics according to the guide

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


feat: move from BigNumber to BigInt

This PR:

Adds a new package called @fuel-ts/math which has some utilities for working with bigints. This is a copy from Ethers v6 and we can move to their package when that's out of beta.
Removes any dependency to @ethersproject/bignumber and uses native bigints instead.
Fixes the test for UtxoIdCoder, which was a copy of WitnessCoder that tested Witness :D
Upgrades to Jest 28. (27 had issues with bigints) #267

Notes:

In the transactions package, instead of changing all BigNumbers to BigInts, I changed the ones lte u32 to just number. They are mostly lengths and indexes and those are natively represtented as numbers and not bigints in JS so this makes our APIs more convenient.

Should we add this to the typedoc list?

@AlicanC Should we add this to the typedoc list?

Yeah, nice catch.


Update munit to 1.0.0

About this PR
📦 Updates org.scalameta:munit from 0.7.29 to 1.0.0 ⚠
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "munit" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scalameta", artifactId = "munit" }
}]

labels: library-update, early-semver-major, semver-spec-major, commit-count:1

Superseded by #35.

Superseded by #44.


[Docker] Config.isDocker is not right in some Docker version / Linux distribution

Updated by @zixia
There's so many difference between Docker container and the Linux distribution.
It seems that we have to list all the docker /proc/self/cgroup files by ourselves...

[x] Ubuntu 16.04
1:name=systemd:/init.scope

[x] Docker version 1.9.1-circleci-cp-workaround, build 517b158(LXC Container in CircleCI)
2:cpuset:/user/1001.user/13034.session/lxc/box2176/lxc/5cd9c2d7f4a7be56db6b79afdf65376bc882c0fa98dd187cda3bf61082041c09

[x] Debian 8@VPS of Google Cloud:
1:name=systemd:/system.slice/ssh.service

[x] Docker version 1.12.1, build 23cf638
1:name=systemd:/docker/3dcbb75a8e932d16a2443afadbe6f02ff242d2665cc43e3f2c7926ae8fdd0633

See Also:

http://tuhrig.de/how-to-know-you-are-inside-a-docker-container/

THE FOLLOWING IS THE ORIGNAL ISSUE POST

Run npm run doctor or wechaty run doctor(for docker user), paste output here
one ubuntu 16.04 (not a docker):
><EMAIL_ADDRESS>doctor /home/user1/apps/wechaty
> ts-node bin/doctor

#### Wechaty Doctor

1. Wechaty version: #git[4c5f713 fix & enhance docker entrypoint help & command parse, with unit tests]
2. Linux x64 version 4.4.0-45-generic memory 378/3919 MB
3. Docker: true
4. Node version: v7.0.0

Expected behavior
3. Docker: true

this expected to be false
Actual behavior
function isWechatyDocker() {
  /**
   * Continuous Integration System
   */
  const isCi = require('is-ci')
  if (isCi) {
    return false
  }

  /**
   * Cloud9 IDE
   */
  const c9 = Object.keys(process.env)
                  .filter(k => /^C9_/.test(k))
                  .length
  if (c9 > 7 && process.env['C9_PORT']) {
    return false
  }

  const cgroup = '/proc/1/cgroup'
  try       { fs.statSync(cgroup).isFile() }
  catch (e) { return false }

  // http://stackoverflow.com/a/20624315/1123955
  const line = execSync(`sort -n ${cgroup} 2>/dev/null | head -1`)
                .toString()
                .replace(/\n$/, '')

  // instead of `/`, docker will end with a container id
  if (/\/$/.test(line)) {
    return false
  }

  return true
}

but on ubuntu 16.04 ,wen run cat /proc/1/cgroup, it's returns  not the same as  the others version linux.
~$ cat /proc/1/cgroup
11:cpuset:/
10:perf_event:/
9:memory:/init.scope
8:pids:/init.scope
7:hugetlb:/
6:cpu,cpuacct:/init.scope
5:net_cls,net_prio:/
4:blkio:/init.scope
3:devices:/init.scope
2:freezer:/
1:name=systemd:/init.scope

~$ sort -n /proc/1/cgroup 2>/dev/null | head -1
1:name=systemd:/init.scope

it's no end with '/' , and method return true finnally
Steps to reproduce the behavior (and fixes, if any)
Paste the full output logs here with WECHATY_LOG=silly set

Hmm... the isDocker() is a dirty & quick function...
We need to rewrite it. Do you have any good idea?

:( i have no idea about this, i googling it, docker upgrade day by day, i  seems there is no regular way help to do this.
i had checking cat /proc/1/cgroup in ubuntu 14.04, and 14.06, it has has difference string pattern.
but in docker ,i seems cat /proc/1/group  always contain keyword 'docker' ?

http://tuhrig.de/how-to-know-you-are-inside-a-docker-container/

@JasLin could you please confirm that the latest version on master resolve this issue? thanks

@zixia the issue has gone.
run  npm run doctor  with the latest code on ubuntu 16.04 and 14.04, it got the right result .

great.
Could you help to paste the output of following two commands under ubuntu 16 for me? Because I need them to be set as test fixture:

cat /proc/self/cgroup
cat /proc/1/cgroup

appreciated.

it's pretty!
had tested this new patch ,it works as well

ok, then this issue closed


Resources with datasets that are closed (updated as needed) not showing correctly in scraper call

Resources that were of datasets that are updated as needed and not on regular intervals were showing with improperly in the scraper call and need to show with the * for end date.
For instance:
    "daterange_for_data": "[2017-09-06T00:00:00 TO *]"

Production updated with the potential remedy. In UAT

The ongoing/closed dataset update option on the COD form is now enforced and persisted in the edit. Closing.


Firefox doesn't build (store corruption?)

Issue description
Fails with chmod permission error on any build.
https://pastebin.com/qAz7yyP6
Derivation contains:
https://pastebin.com/5yyi37qQ
As noted by chat members, my derivation' hash differs from their, and however builds on their systems, but not mine. If you want try building it: http://ge.tt/6zzdEdp2
The question is: how can we note that the system is corrupted and how we can repair it?
Steps to reproduce

I don't know. That's something about cosmic radiation.

Technical details

system: "x86_64-linux"
host os: Linux 4.9.83, NixOS, 17.09.3047.8bce347f02f (Hummingbird)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 1.11.16
channels(root): "nixos-17.09.3243.bca2ee28db4"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

BTW, I have to resolve this problem by reinstallation.

Did you try checking the store for corruption? nix verify --all --no-trust

@lheckemann Yes, I've checked that. No errors.
The issue is resolved by full reinstallation and getting rid of brtfs subvolumes for /var, /tmp, /home, which could trigger abnormal behavior.


Add formatting options

It would be nice to have some kind of option to decide the formatting of the numbers, i.e. 40.5W vs -40.5 vs -40°30'

you can pass functions for formatting in the options: latFormatTickLabel and lngFormatTickLabel.

Especially in higher zoom levels it would be great to have the labels showing deg min format.


Metal: Wrap MTLComputePipelineState

Description
Wraps MTLComputePipelineState. Depends on #3223.

To keep things simple - it is best to have one PR in flight and open a dependent PR after its parent PR(s) have landed.
Closing this PR now - please re-open when it is ready to land and not be in a draft state and its dependencies have all landed


fix: upgrade to winit v0.30

Objective

Upgrade winit to v0.30
Fixes https://github.com/bevyengine/bevy/issues/13331

Solution
This is a rewrite/adaptation of the new trait system described and implemented in winit v0.30.
Migration Guide
The custom UserEvent is now renamed as WakeUp, used to wake up the loop if anything happens outside the app (a new custom_user_event shows this behavior.
The internal UpdateState has been removed and replaced internally by the AppLifecycle. When changed, the AppLifecycle is sent as an event.
The UpdateMode now accepts only two values: Continuous and Reactive, but the latter exposes 3 new properties to enable reactive to device, user or window events. The previous UpdateMode::Reactive is now equivalent to UpdateMode::reactive(), while UpdateMode::ReactiveLowPower to UpdateMode::reactive_low_power().
The ApplicationLifecycle has been renamed as AppLifecycle, and now contains the possible values of the application state inside the event loop:

Idle: the loop has not started yet
Running (previously called Started): the loop is running
WillSuspend: the loop is going to be suspended
Suspended: the loop is suspended
WillResume: the loop is going to be resumed

Note: the Resumed state has been removed since the resumed app is just running.
Finally, now that winit enables this, it extends the WinitPlugin to support custom events.
Test platforms

[x] Windows
[x] MacOs
[x] Linux (x11)
[x] Linux (Wayland)
[x] Android
[x] iOS
[x] WASM/WebGPU
[x] WASM/WebGL2

Does anyone have opinions on squeezing this into 0.14 vs merging it at the start of 0.15? On the one hand fixes are great, on the other hand these upgrade PRs are consistently incredibly painful to review and introduce a large number of new bugs that must be manually tested.

IMHO, this could be finished and merged as part of 0.14: I only moved code from free variables and functions inside the WinitAppRunnerState, not really changing any logic.
Also, apart from testing it, the number of missing/required changes is not high: I just need to understand better the AccessKit part, restore the exit flags (that aren't currently working) and compile/test the various platforms.
The low_power example (and I believe others too) in MacOS works already.

I think android support is broken without the update. See this message from Francois https://github.com/bevyengine/bevy/pull/13254#issuecomment-2097010522

Windowing functionality is working for me on Windows now.
Clear color is broken, but that appears to be #13378.

Clippy failures appear to be real / introduced in this PR. Should be an easy fix, but like always let us know if you'd like a hand with anything.

Done now!

it crashes on iOS
f12304112535b479837f44271dc6a165f0001f5d-crash_reports.zip
Device logs.txt

Crash fixed on iOS: it was trying to access the AudioSync as a single() component before initializing it.

I'm attempting another run on iOS courtesy of Francois's fancy example runner tool. We'll let you know how that goes!

Examples appear to be working correctly on iOS now! We should manually verify that I suspect, but that's very good news.

There is one pending failure on testing macos on CI, that depends on winit, but I don't know how to solve this: I tried clearing up WinitWindows (that should contain all the references) but that's not enough. Ideas?

Solved, and I think it's reasonable too.

WebGL2 doesn't work:
[Error] panicked at crates/bevy_render/src/renderer/mod.rs:185:10:
Unable to find a GPU! Make sure you have installed required drivers!

Stack:

@http://localhost:1236/target/wasm_example.js:1821:30
load_gltf-5001a1b02be6d88f.wasm.wasm-function[console_error_panic_hook::hook::h7a76884a2553e4eb]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::ops::function::Fn::call::h8cfe78e1e00bc822]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::panicking::rust_panic_with_hook::h32c80a64fe4de396]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::panicking::begin_panic_handler::{{closure}}::hd496964d114e98b9]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::sys_common::backtrace::__rust_end_short_backtrace::h0d4686a7fe3981a4]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[rust_begin_unwind]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::panicking::panic_fmt::hc7427f902a13f1a9]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::panicking::panic_display::h57441543e669293c]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::option::expect_failed::h44ad93b37e925be9]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[bevy_tasks::single_threaded_task_pool::TaskPool::spawn::{{closure}}::h98b19299c4328dd5]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[wasm_bindgen_futures::queue::Queue::new::{{closure}}::h065fa42fda1152c3]@[wasm code]
load_gltf-5001a1b02be6d88f.wasm.wasm-function[<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h277b19d767b55f34]@[wasm code]
__wbg_adapter_60@http://localhost:1236/target/wasm_example.js:241:134
real@http://localhost:1236/target/wasm_example.js:210:21

	(anonymous function) (wasm_example.js:1837)
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[console_error_panic_hook::hook::h7a76884a2553e4eb]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::ops::function::Fn::call::h8cfe78e1e00bc822]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::panicking::rust_panic_with_hook::h32c80a64fe4de396]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::panicking::begin_panic_handler::{{closure}}::hd496964d114e98b9]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[std::sys_common::backtrace::__rust_end_short_backtrace::h0d4686a7fe3981a4]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[rust_begin_unwind]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::panicking::panic_fmt::hc7427f902a13f1a9]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::panicking::panic_display::h57441543e669293c]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[core::option::expect_failed::h44ad93b37e925be9]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[bevy_tasks::single_threaded_task_pool::TaskPool::spawn::{{closure}}::h98b19299c4328dd5]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[wasm_bindgen_futures::queue::Queue::new::{{closure}}::h065fa42fda1152c3]
	load_gltf-5001a1b02be6d88f.wasm.wasm-function[<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h277b19d767b55f34]
	__wbg_adapter_60 (wasm_example.js:241:135)
	real (wasm_example.js:210)

you can build for WebGL2 with cargo run -p build-wasm-example -- --api webgl2 load_gltf, then  serve the folder examples/wasm with your preferred tool

Argh, this is kinda blocker for me: in the previous version, a window was created before the loop was started, so that the RenderPlugin was able to build the renderer with an existing PrimaryWindow/RawHandleWrapper. Now this is not easily allowed in winit .30, since create_windows is deprecated for the not-running EventLoop, but more than that it doesn't expose the primary_monitor() and available_monitors() methods that are used to build the WindowAttributes.
I tried different solutions:

waiting for the PrimaryWindow/RawHandleWrapper inside the RenderPlugin (but it stucks forever)
creating the renderer within a system (even extracting the renderer resources to the RenderApp), but many other plugins require the renderer to be built during the plugin creation phase
tried to build the window without the primary_monitor and available_monitors (but they are required to setup full screen or a window in a multi-monitor setup)

I don't really know how to progress here: the ideal solution IMO would be one of these 2:

build the plugins inside the loop
create the renderer in a system

but neither is straightforward.

could you also update the patches in this folder: https://github.com/bevyengine/bevy/tree/main/tools/example-showcase?
The should be applied correctly when you run git apply --ignore-whitespace the-file.patch

https://github.com/Sophya/bevy/pull/5 fixes WebGL2

and https://github.com/Sophya/bevy/pull/6 fixes the patches

@mockersf @alice-i-cecile I applied the patches and they work perfectly with WebGL2! Very good job! 💪

Ups, sorry, done now!
On Thu, May 23, 2024 at 1:20 PM François Mockers @.***>
wrote:

@.**** commented on this pull request.
In examples/window/custom_user_event.rs
https://github.com/bevyengine/bevy/pull/13366#discussion_r1611498283:

+fn send_event(

input: Res<ButtonInput>,
event_loop_proxy: NonSend<EventLoopProxy>,
+) {
if input.just_pressed(KeyCode::Space) {

   let _ = event_loop_proxy.send_event(CustomEvent::WakeUp);

}
if input.just_pressed(KeyCode::KeyE) {

   let _ = event_loop_proxy.send_event(CustomEvent::Key('e'));

}
+}

+fn handle_event(mut events: EventReader) {

for evt in events.read() {

   info!("Received event: {evt:?}");

}
+}

did you miss to push a commit? I don't see any changes
—
Reply to this email directly, view it on GitHub
https://github.com/bevyengine/bevy/pull/13366#discussion_r1611498283,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZKFRREU2TE3W7J3YWC3WC3ZDXGJHAVCNFSM6AAAAABHWOLJ6CVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDANZTGY3DANJSGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

On android, I'm able to make it crash sometimes after unsuspending.
05-24 01:46:00.782  8569  8637 I RustStdoutStderr: thread '<unnamed>' panicked at /home/eero/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ndk-context-0.1.1/src/lib
.rs:87:5:
05-24 01:46:00.782  8569  8637 I RustStdoutStderr: assertion failed: previous.is_none()
05-24 01:46:00.782  8569  8637 I RustStdoutStderr: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Also it's pretty easy to quickly open and close the app and then the music keeps playing when suspended.
It might have been possible before, but for some reason this PR is a lot slower for me to open compared to 0.13, so the window to make the bug happen is also larger.

xcodebuild: error: missing value for key 'id' of option 'Destination'

Merge failed due to an iOS failure.

the only change that could provoke that failure is the makefile change, and I don't see how that could happen

I've ran all the windowing examples for testing. (Linux, Xorg, KDE, NVIDIA)
Here are my observations:
scale_factor_override

When the window is maximised, changes in the scale factor don't apply, to make them apply one has to make the window smaller again. (Re-maximising keeps the updated scale factor)

window_settings

Theme changing doesn't work
Toggling window buttons doesn't work
NOT a regression, didn't work before either

multiple_windows

WARN bevy_winit::state: Skipped event Destroyed for unknown winit Window Id WindowId(182452226) upon closing the window, other than a warning it works just fine
NOT a regression, happened before too

screenshot

ERROR present_frames: wgpu_core::present: No work has been submitted for this frame before taking the first screenshot, but after pressing space

I have tested on webgl2, the application will hang when switched tabs.  Something like this  https://github.com/bevyengine/bevy/issues/13486

scale_factor_override
* When the window is maximised, changes in the scale factor don't apply, to make them apply one has to make the window smaller again. (Re-maximising keeps the updated scale factor)

Can reproduce on macOS:
Screenshots:

When full screen, text is wonky

Minimizing the window then fixes

I've asked for help with this PR over in the winit Matrix chat: https://matrix.to/#/!DGpLzJTRzBDTwZiogk:matrix.org/$jRbYEC1NZSMWItgF2w8S4HOVacyDyAI5avVWq1N6UDE?via=libera.chat&via=matrix.org&via=mozilla.org

On android, the app always crashes for me when resuming and starts from the beginning.

I did some more testing on Android and it seems that the crashing might be a MIUI quirk. After clearing other background apps, the crashing went away. Sorry for the noise.

Also it's pretty easy to quickly open and close the app and then the music keeps playing when suspended.

I also did some more investigation on this. It is still an issue. It seems that the suspended-function is just never called by winit if the app is closed early enough (at least on my device with Android 11). I don't know if we can do much about it. It is a regression, but maybe not worth blocking over imo.

I also tested with opt-level=3 and lto="thin", and there the time window for making the music bug happen is very very small. I couldn't make it happen in practice, maybe it would be easier on a less powerful device.

scale_factor_override
* When the window is maximised, changes in the scale factor don't apply, to make them apply one has to make the window smaller again. (Re-maximising keeps the updated scale factor)

Can reproduce on macOS:

I think this is related to 2 combined things happening:

the scale factor override is only a Bevy internal setup, and it's set in the WindowResolution property of the Bevy Window. There is no counterpart in winit. So the event loop doesn't really react to the change, and a custom event should be emitted instead. It can be handled in the bevy_winit::changed_windows system.
winit can send an event for a changed scale factor (easy to repro changing the browser zoom in a WASM app) and the relative event is handled. This is also a source of a bug related to this even in 0.13 (that's a winit one, but can be solved in Bevy too).

I can handle both in this PR or in a follow up one in the next couple days.

I fixed the scale factor override issue and solved this 🤞

Can confirm it works!

@mockersf is there an easy way to test the IOS build that's failing? it seems the only blocker to merge this PR now...

Could you give me more details on the iOS build failure? I don't see it in CI, I'll try to reproduce tomorrow
also, another patch update please: https://github.com/Sophya/bevy/pull/7

Could you give me more details on the iOS build failure? I don't see it in CI, I'll try to reproduce tomorrow

Seems like iOS is skipped? This happened last time it was added to the merge queue: https://github.com/bevyengine/bevy/actions/runs/9215755498/job/25354702941

FYI: this fixes an issue on main, where mouse inputs are only reported every other frame on MacOS.

FYI: this fixes an issue on main, where mouse inputs are only reported every other frame on MacOS.

Oh wow, just tested and this is extremely noticeable on one of my apps running in debug mode. I was wondering yesterday how it could possibly feel so sluggish. Huge fix!
I am seeing an issue however around startup where there is some rescaling visible.
https://github.com/bevyengine/bevy/assets/10366310/4b64b30a-5f92-4cd4-87a3-d42ce3c70882
In this video it's pretty instant but it's seemed to hang just a bit longer a few times.

@pietrosophya once you commit the changes suggested in https://github.com/bevyengine/bevy/pull/13366#discussion_r1623303666 to fix the iOS build I'll merge this in.

FYI: this fixes an issue on main, where mouse inputs are only reported every other frame on MacOS.

I think it has also been happening to me on Wayland. Oh wow.

@pietrosophya once you commit the changes suggested in https://github.com/bevyengine/bevy/pull/13366#discussion_r1623303666 to fix the iOS build I'll merge this in.

https://github.com/Sophya/bevy/pull/7 is also still waiting.

FYI: this fixes an issue on main, where mouse inputs are only reported every other frame on MacOS.

It appears the issue is not completely fixed, there are still frames where inputs are missing, but it is measureably improved.

Patch #7 applied, and also accepted/reverted the change for building iOS

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to https://github.com/bevyengine/bevy-website/issues/1328 if you'd like to help out.

I'm in the process of migrating my custom rendering backend to work with Bevy 0.14 and I'm running into trouble because the RawWindowHandleWrapperHolder contains a None value when initializing my rendering plugin. At what point can I rely on the value being set?


Pick off some easy coverage wins around raise statements

Related: #1214.

Codecov Report

Merging #1239 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #1239   +/-   ##
======================================
  Coverage     100%    100%
======================================
  Files          21      21
  Lines        1985    1985
======================================
  Hits         1985    1985

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 c28170e...aef4a8f. Read the comment docs.

Want to update this onto the new master?

Want to update this onto the new master?

Done.


Adding example code to docs

Seems like it should be possible for typedoc to do this automatically but doesn't seem to be a supported feature. I see there's also a command for including examples in JSDoc format but typedoc doesn't support it. Instead they suggest including as code snippets, which sounds like it would also work (https://github.com/TypeStrong/typedoc/issues/135).
Just think it would be nice for example on the tx page to see all of the types actually constructed together once as an example of the object. I find it a lot easier to confirm what you're doing is correct if you're able to just compare the results.

Might also make it easier to link main cosmos docs to sig docs in support of a better description of how transactions and messages are constructed (https://github.com/cosmos/cosmos-sdk/issues/4705)


Support Docker Desktop for building native executables with quarkus 3.6.0

Support Docker Desktop for building native executables with quarkus 3.6.0
The @Blocking annotations validation are new in Quarkus 3.6.0

@johnaohara Thanks

@shivam-sharma7 : we still need the @Blocking annotation, but it needs to be defined on the interface methods, instead of the concrete class: https://github.com/shivam-sharma7/Horreum/blob/quarkus/horreum-api/src/main/java/io/hyperfoil/tools/horreum/api/internal/services/UserService.java#L25

@shivam-sharma7 : we still need the @Blocking annotation, but it needs to be defined on the interface methods, instead of the concrete class: https://github.com/shivam-sharma7/Horreum/blob/quarkus/horreum-api/src/main/java/io/hyperfoil/tools/horreum/api/internal/services/UserService.java#L25

@johnaohara I'm thinking to do that in a seprate PR!

@johnaohara I'm thinking to do that in a seprate PR!

It needs to be in this PR, we can't intentionally break the threading model

rebased against the master

@jesperpedersen have a look

@johnaohara should I open PR against the 10.x for backport


Missing Behavior with Line Selection Shortcuts

Issue Type: Bug
Hello,
Previously on VScode and currently on other editors (GEdit, Safari, Firefox, TexPad, ...), I could select a whole line with Ctrl+Shift+Up/DownArrow or Option+Shift+Up/DownArrow.
You might say why would I need Ctrl/Option, the Shift+Up/DownArrow should work. However, they are not the same, when the line is wrapped. For the wrapped lines, Ctrl/Option should allow selecting the whole line. Without Ctrl/Option, I should select the wrapped line, part of the actual line.
This is probably the default behavior. Even available on the basic editor GEdit, or the GitHub's issue reporting textbox, but not possible anymore on VSCode. Surprisingly, it woks on the Issue Reporter window of VSCode, where I am writing this message right now.
Even though I removed the keybindings associated with Shift+Ctrl+Up/DownArrow, the line selection behaviour did not fall back to the defaults.
Can you please allow this basic line selection feature again. Or better might be that if there is no shortcut assigned to Ctrl/Option+Shift+Up/DownArrow, then the line selection behaviour goes back to defaults.
Kind Regards,
Furkan
VS Code version: Code 1.66.0 (e18005f0f1b33c29e81d732535d8c0e47cafb0b5, 2022-03-30T05:50:04.419Z)
OS version: Darwin x64 21.4.0
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz (4 x 2900)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
16.00GB (0.10GB free)

Process Argv
--crash-reporter-id 3468f190-00ec-451c-946c-13748b66e60c

Screen Reader
no

VM
0%

Extensions (10)

Extension
Author (truncated)
Version

Untabify
ili
0.0.2

remote-containers
ms-
0.231.4

remote-ssh
ms-
0.78.0

remote-ssh-edit
ms-
0.80.0

cpptools
ms-
1.9.7

hexeditor
ms-
1.9.5

veriloghdl
msh
1.5.3

tcl
ras
0.1.0

abc-music
sof
0.4.0

latex-support
tor
3.10.0

(1 theme extensions excluded)

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30443607
pythontb:30283811
pythonvspyt551:30345470
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
pythonvsnew555:30457759
vscscmwlcmt:30465135
cppdebug:30466689
pynewfile477:30463512

@furkanturan I don't remember implementing such a command in the editor and binding it to Ctrl+Shift+Up/DownArrow or Option+Shift+Up/DownArrow. I have checked with version 1.60 of VS Code back from August 2021 and neither  Ctrl+Shift+Up/DownArrow nor Option+Shift+Up/DownArrow have the effect you describe. In what VS Code version did this work for you?

@alexdima You are apparently correct. The oldest version I have now is 1.66. I just tested on it and saw that the line/paragraph selection with Ctrl+Shift+Up/DownArrow does not work on it too. Probably, I miss remember as it is a behavior that I use on many other editors. Apologies for opening this issue as a bug.
In fact, this has been quite surprising for me. The basic key combination that is available in most editors (that I tried) is not available on VS Code. Therefore, before closing this issue, I would like to kindly ask, if it can issue this as a feature request? The line selection feature to the users can assign the Ctrl+Shift+Up/DownArrow key combination.
Kind Regards,

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Tests as code

We want tests as code. There are too many URL bashers and load test tools using XML or YAML to write scripts. We want tests that are clean and execute a sequence of actions. Lua is making a comeback and there will be a Rust binding. There are also a number of dynamic languages that bind to Rust. TODO: Find the list link.

I pulled these two links from Reddit which are languages that bind to Rust:
https://github.com/rust-unofficial/awesome-rust#scripting
https://github.com/alilleybrinker/langs-in-rust#list-of-languages
We need an embedded language that is easy for developers and testers . Fighting with the borrow checker when writing load tests is a no go and I know you like your system languages, but others don't.

This looks like a widely used dynamic language that can be used in Rust. A mix between Rust and JavaScript. Actively used and maintained.
https://github.com/rhaiscript/rhai

If the aim is to meet people where they are, then the least common denominator is likely TypeScript / JavaScript. Seems like it would be doable with Deno<EMAIL_ADDRESS>

Have you used https://k6.io/? What are your thoughts?

I was involved in the early stages of k6. It is badly designed. IMHO JavaScript has hit saturation point. Elixir is beautiful and I'd be looking for something like that embedded in Rust.


New operators to do trending

A nice to have would be to have some operators to estimate a value based on previous ones by using different algorithms (Moving average, Weighted moving average, least-square or Moving median)
see https://en.wikipedia.org/wiki/Moving_average
see https://en.wikipedia.org/wiki/Linear_trend_estimation
Operators can be:
linear: trend(serie, nb points)
least square: lstrend(serie, nb points)

Moving median would be a nice one to have.  Presently, to apply a median filter requires that you downsample your data.


No contextualization

Can you provide more details, with a full list of commands and code selection

On the web page:

In vscode:


fix(font-family) Incorrect font-family used in demo components

Issue here.

Fonts are coming from:
Fonts are coming from:
body: Roboto, sans-serif
body: "Source Sans Pro", sans-serif
normalize.less:body: "Helvetica Neue", Helvetica, Arial, sans-serif
bootstrap.min.css:html: sans-serif


Create train.py

a demo about Kovasznay flow

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

LGTM


PDF/X standard for print

Our document should conform with PDF/X and this plugin should help:
https://ctan.org/pkg/pdfx?lang=en
Related Questions
https://tex.stackexchange.com/questions/576/how-to-generate-pdf-a-and-pdf-x
https://www.overleaf.com/latex/examples/creating-pdf-slash-a-and-pdf-slash-x-files/bbbycnbyqhnm
https://tex.stackexchange.com/questions/232757/pdfx-package-writes-into-pdf-file
https://tug.org/tug2015/preprints/moore-pdfx.pdf

@elbotho shall we set milestone to germanwide print?


PPAPI 2 NPAPI

Hi!
I was thinking about using the converter the other way around.
As you probably know Chrome is dropping NPAPI support and I could see that alot of companies would be interested in buying a service to automatically convert their npapi to ppapi.
What do you think?
Kind regards
Johan

What do I think about what particularly? Implementing such "converter"? I'm not interested in such converter myself, since I don't have a use case.

By the way, it would be comparable with Wine in terms of complexity.
Much easier to just convert sources of plugins to use PPAPI directly.

Hi!
I was thinking that you could sell it to alot of different players out there, cause their solutions don't work with Chrome any longer. It would be a hassle for them to rewrite it to PPAPI. I was thinking about providing a service that took their NPAPI app and made it work using PPAPI instead. Like a layer ontop of it to made it seem like a PPAPI.
The reason why I contacted you was that you had worked with both specifications.
I feel like this is an opportunity that soon will be closed and wanted to hear your insights into this.

If you like the idea, feel free to use it as you wish.
I personally don't think it's feasible. As said earlier, one need to intercept all native calls made by NPAPI plugin and wrap them into corresponding PPAPI calls. That's lot harder than to do opposite (which I'm doing in current project). Wine project does a similar translation. But it centers on providing implementation of only Windows calls. Converter you are going to build must handle all Windows, Mac OS X, and Linux.

By the way, I've got an implementation idea. So I'll describe it here, for anyone interested.
Chrome runs plugin host process in a sandbox, which effectively blocks NPAPI plugin operation. But network communication is still possible. Therefore, one could implement externally launched host process which loads NPAPI plugin and then listen for incoming commands. Another part will be custom PPAPI plugin, which will supply that host process with commands. One need to implement passing of keyboard and mouse events, and also graphics images.