Add a Publisher 0..1 specialization

add a marker interface
add 5th paragraph to the specification

The TCK additions, examples and other changes can be added as a follow up (@OlegDokuka have volunteered to work on them if needed) to keep this PR small and focused.

@viktorklang any chance to look at this PR?
Cheers,
Oleh

Yes, I’ve seen it :)
Still on the fence on its inclusion though, needs to be argued further IMO.
👍
Cheers,
√

Although I agree that other types (single, completable, maybe) are required to express different high level APIs as many different libraries (reactor, rxjava, servicetalk, etc) have demonstrated, I do not think that the proposed change here actually addresses those concerns.
Even if we provide a MonoPublisher it isn’t a fit for Single as Single guarantees exactly one item. The question then would be as to what makes at-most one semantics special as compared to exactly-one when we know both are required for high-level APIs.

@NiteshKant thanks for the feedback!

Even if we provide a MonoPublisher it isn’t a fit for Single as Single guarantees exactly one item

Since Single is "exactly one", it still fits to 0..1 and can/should implement MonoPublisher.

The question then would be as to what makes at-most one semantics special as compared to exactly-one when we know both are required for high-level APIs.

I see the point of "exactly one" and totally understand why some libraries have decided to have separate Single/Maybe types.
That said, I think Single is a separate concern, and here is why:
MonoPublisher defines a specialization/marker of Publisher. It only defines that the Publisher's upper bound of emitted items is limited to one (and request(1) guarantees that).
But at the same time Single defines a behaviour (that must also be enforced), because now we need to define that onComplete without onNext is an error (not the case for MonoPublisher). The consumers will be required to check this contract, the error state will need to be defined (when SinglePublisher emits zero elements), akin to non-positive request, etc etc
I am not saying that we should not have SinglePublisher at all, but I have a feeling that it is not as simple as MonoPublisher (which is a truly low hanging fruit here).

I agree with @bsideup. Single, Maybe, Completable are derivable types from MonoPublisher. The goal is to define a generic type representing 0..1 regardless on whether it is guaranteed 1| guaranteed 0 | or maybe 0..1 | (if we talk more on such, we can have Error, which guaranteed to return an error and never onComplete or onNext) But my belief is that it is implementation, which less compatible when there is no 0..1 abstraction. Thus having MonoPublisher is a big step to say - hey, here we have a subtype of Publisher which guarantees to send no more than a single element

@bsideup

thanks for the feedback!

❤ , thanks for starting this discussion!

Since Single is "exactly one", it still fits to 0..1 and can/should implement MonoPublisher.

Single defines a behaviour (that must also be enforced)

The value of introducing another type is that they can be used as arguments or return types to public APIs. In this context, the value of Single is that its API contract is strict => it can not terminate without a result. Extending MonPublisher does not provide the same guarantee, so extending MonoPublisher is no different than extending Publisher.

but I have a feeling that it is not as simple as MonoPublisher (which is a truly low hanging fruit here).

Agreed, defining a contract for Single (and friends) has a bigger surface area. My motivation here is to drive a change by value and not by the level of complexity of the change. In that spirit, MonoPublisher adds some value but does not cover all cases hence the question about return on investment.
@OlegDokuka

Single, Maybe, Completable are derivable types from MonoPublisher.

So is MonoPublisher which is derivable from Publisher. I don't see this as a convincing argument. If we do not provide a type which is decoupled from Publisher for these special cases, the value add is trivial.

@NiteshKant
I fully understand your point of trying to derive separate types, but consider the following.

The value of introducing another type is that they can be used as arguments or return types to public APIs.

Is it not that applicable to MonoPublisher even though it is a subclass of the Publisher?
It is MonoPublisher != Publisher along with it is  MonoPublisher  <| Publisher, which means when you have a Publisheryou can not pass it to the API whenMonoPublisher` is defined as an acceptable type.
It means that MonoPublisher requires a specific extension that produces at most 1 element.
The same applies to the return type. If an API method returns MonoPublisher it strongly guarantees at most one element and leaves space to receive or not value and receive onComplete or onError. (this may leave a question when it is useful since we may get onComplete which may be meaningless - but this discussion will be at the end).
Following the mentioned idea, having MonoPublisher as a start point you can develop Single | Maybe which is compatible with external libraries that expect MonoPublisher as an input.
Clearly, we loose the semantic of stronger behavior of Single, but we preserve the guarantee of the at most one element which is valuable in majority of cases.
Sidenote:  Completable is semantically redundant since Completable ~= MonoPublisher<Void> ~= Publisher and we all know that Void is nullable value so we can exclude it as a value of the onNext call, hence all possible states are onError or onComplete which is effectively the same as Completable (see https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/core/CompletableObserver.java).
So, we left with the main question - do we need SinglePublisher type?
This question is addressed to anyone who participates in this thread and the answer should be derived from the following:
***How frequently in the real world a user demands strong results vs weak results which may or may not return value? Is that demand semantic related or performance-related? What users do with CompletableFuture which has the same resulting semantic as MonoPublisher and if most of the users are satisfied with the CompletableFuture sematic are not them get the same from the MonoPublisher? (Assume Publisher is always exposing the broader surface since it has more undetermined state than MonoPublisher)
Cheers,
Oleh

@OlegDokuka
Rite .. all connect APIs, HTTP response APIs, etc need Single more than a Maybe (Mono).
For motivations for Completable, you may find this RxJava issue useful.
RSocket fireAndForget is accurately represented as a Completable BTW.
Drawing analogies for different types from the synchronous world, you have the following return type variants:

public Collection<T> getAllUsers() <- return type represented as a Publisher
public T getUser(String userId) <- return type represented as a Single
public void recordEventForUser(String userId, Event event) <- return type represented as a Completable.

How often do you see similar methods while designing an API? There aren't may ways to tell which is more important than other, all are important I would say.

Rite .. all connect APIs,

Agree.

HTTP response APIs

2xx is effective Maybe since there can be empty response so if one would need to respond with the empty result they would always have to invent Single<Result> with the Result subtype  ResultEmpty for such purposes.

RSocket fireAndForget is accurately represented as a Completable BTW.

In fact, we are good with Mono<Void> as I said generic allows expand the meaning of the result whilst Single<Void> is impossible.

For motivations for Completable, you may find this RxJava issue useful.

I see the problems...
In the reactor, we usually solve the mentioned as the following
connection.write(Observable.just("hello"))
          .cast(String.class)
          .concatWith(connection.getInput())

as
connection.write(Observable.just("hello"))
          .then(connection.getInput())

or
Flux<Object> merge = Flux.merge(empty(), generateRating());

The second is indeed a bit aglee and would require
Flux<String> merge = Flux.merge(((Mono<String>)((Mono)empty())), generateRating());

or
 Flux<String> merge = Flux.merge(empty().then(Mono.empty()), generateRating());

Agree, I can see how completable with generic can help...

I think the discussion got shifted in a wrong direction.
Do we (as a reactive community) need SinglePublisher, for even better type safety? Yes.
Does it mean that we don't need much simpler 0..1 specialization of Publisher called MonoPublisher or whatever? Of course not.
If we ever talk about adding SinglePublisher, I would fight to the end that it should extend MonoPublisher. Which means that MonoPublisher is the first step in all this discussion, and, unlike SinglePublisher, MonoPublisher is easy to add.
Plus, if somebody questions the value of MonoPublisher, I would like to point out that Project Reactor existed for many users, where you only get 0..n and 0..1 Publishers. That's the API's bare minimum needed to express most of the reactive apps, and it served very well for far.

Extending MonPublisher does not provide the same guarantee, so extending MonoPublisher is no different than extending Publisher.

I think "no different" is a stretch here. SinglePublisher should extend MonoPublisher, so that the consumer of it knows that it is finite, as opposed to an infinite Publisher of something that will never end and you can't do things like do X then Y.

The bottom line is that we should not open the can of worms. Let's focus on MonoPublisher (keeping in mind that both SinglePublisher and Completable are special cases (1..1 and 0..0) of MonoPublisher - this is important!) and the value it brings.
There were enough discussions and the last I remember is that more or less everyone agreed that we could use a type that helps describing "at most one" Publishers.
More (if needed and agreed) Publisher types can be added as a follow up (but MonoPublisher is basically a prerequisite for them)

Just to clarify.

I think the discussion got shifted in the wrong direction.

Apologies for those long-reading, but I guess I tried to get @NiteshKant point.
My general PoV has not changed, and pervious was more on understanding the general use-case.

the absence of general semantic for the monoid stream does not exist in the spec at all which is more harmful

As I stated, this is the main reason for this PR.

Do we (as a reactive community) need SinglePublisher, for even better type safety? Yes.
Does it mean that we don't need much simpler 0..1 specialization of Publisher called MonoPublisher or whatever? Of course not.

Agree with @bsideup and propose to raise the follow-up discussion on SinglePublisher demand once we are done with Monoid one.

@bsideup I believe any of the 1 or less items types should not extend Publisher at all as the demand is implicit with subscribe(). Both RxJava and ServiceTalk follow this model.

@NiteshKant I am afraid this will hurt the adoption.
Also, they remain valid Publishers, so why shouldn't they extend?
We're not changing the semantics, and the request(1) is still required before they start doing the work.

@NiteshKant what is your word on not extending Publisher? Were there any historical reasons to have it not a subtype?
I can see a performance reason, so having it as a separate type allows to get rid of redundant calls, but do you have anything in mind apart from performance optimizations?

I am not saying that this change is incorrect in terms of semantics but it isn't perfect from an API design point of view. The biggest disadvantage for me is that there is request-n semantics for at most one item. As shown by RxJava and ServiceTalk, interaction with such entities is easier without the request-n semantics, request-1 is implicit upon subscribe.

@NiteshKant

isn't perfect from an API design point of view
interaction with such entities is easier without the request-n semantics, request-1 is implicit upon subscribe.

As much as I would like to reduce the overhead and simplify subscribing on such specialized Publishers, I am afraid it has a much bigger scope than just adding a marker overhead and, given the inclusion of RS into JDK, may require double as much effort.
Before submitting the proposal we evaluated multiple options and then reduced it to the minimal change that has the best "change size vs impact" balance, while also keeping a room for improvements for later.
I will be first to support the next initiative to apply the optimizations (RS spec 1.1?), but I have a feeling that it will take much longer, while MonoPublisher can go into a patch release and already bring a lot of value to both library/framework developers (easier to express their APIs) and users (easier to understand the consumed APIs).
WDYT?

Here's a counter-proposal. Add method:
void Publisher.subscribe(Subscriber<? super T> subscriber,                                            long initialRequests, long maximumRequests);
Notes:

This is in the spirit of "0-RTT" improvements in network protocols  (QUIC, TLS1.3, etc); the same rationales hold of removing one or more request-response sequences.
As usual requests of Long.MAX_VALUE mean effectively unbounded.
The current one-arg version is equivalent to subscribe(s, 0, Long.MAX_VALUE).
It applies to the motivating use cases, and may also improve latency in other common use cases
It can be default-implemented without creating a subinterface.
No type-introspection is needed (instead track maxRequests)

Open issues:

Require (vs allow) auto-close when maxRequests hit?

Thanks for your proposal, Doug. I’d like to explore what is possible
without marker interfaces.

Here's a counter-proposal. Add method:
void Publisher.subscribe(Subscriber<? super T> subscriber, long
initialRequests, long maximumRequests);
I think the challenge would be that you’d have to know Subscriber
implementation details to figure out what to pass into subscribe(..), and
the Subscriber would no longer be in charge of its demand generation.

A counter-counter-proposal would be to add to Subscriber:
public long initialRequested() {
return 0;
}
Then all Publishers can query the Subscriber for initialRequested and start
onNext()-ing at-most that amount immediately after issuing onSubscribe.
It does require a bit of cleverness in the Subscription implementation, but
seems tractable.
Pairing initialRequested() with a method on Publisher:
public long maxElements() {
return -1;
}
a Processor could use both maxElements and initialRequested to optimize the
setup. (Negative is unknown, 0 is known-empty, Long.MAX_VALUE is unbounded).
Notes:

This is in the spirit of "0-RTT" improvements in network protocols
(QUIC, TLS1.3, etc); the same rationales hold of removing one or more
request-response sequences.
As usual requests of Long.MAX_VALUE mean effectively unbounded.
The current one-arg version is equivalent to subscribe(s, 0,
Long.MAX_VALUE).
It applies to the motivating use cases, and may also improve latency
in other common use cases
It can be default-implemented without creating a subinterface.
No type-introspection is needed (instead track maxRequests)

Open issues:

Require (vs allow) auto-close when maxRequests hit?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/reactive-streams/reactive-streams-jvm/pull/490#issuecomment-640076300,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAACU5YFK6FAPZWBJSXN5MDRVJMRDANCNFSM4NMDYXYQ
.

--
Cheers,
√

@DougLea are you suggesting that we add this method to MonoPublisher or Publisher?
@viktorklang

I’d like to explore what is possible without marker interfaces.

Although I like where the idea of adding initialRequested goes, I would like to remind that the optimizations wasn't the top reason to add MonoPublisher.
Currently, there is no way to express 0..1 result with RS types.
Yes, we can optimize the routine of subscribing on 0..1 Publishers. But there is still a big problem of not being able to express 0..1 result type in libraries' public APIs that do not want to depend on some RS implementation that most of the time come with Maybe/Mono/Uni/Whatever type.
So I am kindly asking to keep in mind this important UX (not performance!) issue.

@viktorklang I contemplated adding to subscription along these lines, but it seems better in all ways to overload a subscribe method: no RTTs if remote, and no thread-safety issues if local; plus simpler default implementability. Or maybe I'm missing something?

@viktorklang @DougLea the purpose of that PR is to add an interface that identifies a Publisher of a single type.
Optimizations that expose the subscriber demand in another way are out of spec and far more than Reactive-Streams Spec should define.

I like the initial and max requested/elements proposals as it has both positives, 0-RTT and the ability for subscriber to assume there can be only one (or less) items. It also has the advantage that we do not have to add new interfaces.
Perhaps maxExpected is more appropriate when coming from a Subscriber to express that a Subscriber only expects n items ever and if there are more it will be regarded as an error (mono/single case).

I would agree with @viktorklang that these values detached from a Subscriber implementation will be confusing if we assume that the entity calling subscribe() can be different than the one implementing a Subscriber which is common for intermediary layers (function composition cases).
I think having two additional methods on a Subscriber will be cleaner:

initialRequested()
maxExpected()

Additional constraints on the new methods would be that they will only be called before calling onSubscribe(); eliminating the potential sequencing ambiguity between request-n from Subscription and initialRequested().

@bsideup If Subscriber can signal to the Publisher that it only expects a single item ever then the different types for API clarity can continue to be handled by the libraries on top by adapting the Subscriber implementations. So I think this proposal achieves what you are looking for.

@NiteshKant

If Subscriber can signal to the Publisher that it only expects a single item ever then the different types for API clarity can continue to be handled by the libraries on top by adapting the Subscriber implementations. So I think this proposal achieves what you are looking for.

You're talking about the runtime. I am talking about the compile time / method signatures.
Can we please stop ignoring the important aspect of being able to determine the 0..1 nature by looking at method's return type?
Let's stop thinking about the optimizations for a second and think about the users who are struggling because they can't express / identify finite 0..1 methods just by using the RS.

Is there an overhead when you subscribe on 0..1 sources? Yes.
Are the end users (not RS frameworks devs) talking about it and asking to fix it ASAP? Not really.
Is there a strong demand from the end users to be able to express / identify 0..1 return type? Yes.

Totally with @bsideup on this one, the fact there is no type in RS that allows detection of a single causes no end of pain for library authors and users.
It causes problems in numerous areas such as runtime detection of the reactive type. In Micronaut for example we had to write a isSingle method that uses a horrible hack and forces us to dynamically depend on concrete implementations:

https://github.com/micronaut-projects/micronaut-core/blob/1.3.x/core/src/main/java/io/micronaut/core/async/publisher/Publishers.java#L308

In additional as @bsideup said there is no way to write an API that isn't bound to a particular reactive library that expresses that the API emits a single value. To workaround this limitation we had to introduce an annotation in Micronaut called @SingleResult:

https://github.com/micronaut-projects/micronaut-core/blob/1.3.x/core/src/main/java/io/micronaut/core/async/annotation/SingleResult.java

Which we are then forced to use to identify APIs that emit a single item. For example:
https://github.com/micronaut-projects/micronaut-core/blob/e9378a1adf1873bbb30889b74a5498c6cab89eca/runtime/src/main/java/io/micronaut/discovery/DiscoveryClient.java#L40
All of these items make it harder than it should be to allow interoperability between Reactive libraries which is the fundamental goal that this PR is trying to resolve and surely a fundamental goal of Reactive Streams.
I would absolutely love to see MonoPublisher (or whatever it is called), it would solve many, many problems for users and library authors.

One more comment, this PR is also non-breaking as it introduces a new interface that can be gradually adopted by libraries. The discussion has veered towards introducing a new method which IMO is much more invasive and a greater breaker change for people that have adopted Reactive Streams.

@bsideup and others: I'm addressing the protocol side of the lack of control for initially:n, max:m. Solving this makes it simpler to include corresponding specialized types if so desired; even ad-hoc non-standardized ones.
While I'm at it: There's a difference between cancelling a subscription versus versus hitting max request bound versus cancelling a CompletableFuture: In the first case, you will eventually stop getting them. In the second, you won't get them at all past bound, and in the third case, you may get them but they will throw exceptions upon use.  The second version probably most commonly applies but is not currently supported.
A further aside, there was a vocal contingent (including some RS contributors) opposing including cancel in CompletionStage interface. One argument is along the lines of above, but I should have realized with RS that  there should be some compensating RS features such as this.

Hey @DougLea.
Thank you for the clarification.

@bsideup and others: I'm addressing the protocol side of the lack of control for initially:n, max:m. Solving this makes it simpler to include corresponding specialized types if so desired; even ad-hoc non-standardized ones.

I belive such improvements are general enough and not fully related to this topic, thus I guess it is better to have a separate discussion for it.
WDYT?
Cheers,
Oleh

I've refrained as much as possible from commenting on the PR (and issue) so as not to pile up the discussion with Reactor's pov, but here are my most important thoughts on the points raised during these past few days:

the notion that imperative methods like T method() translate to a Single in the reactive world is overlooking how often T is nullable (eek! or an Optional, or a Null Object 😅)

Expressing the 0..1 semantic definitely looks like the low hanging fruit

the protocol change proposal is more intrusive, more involved in terms of adoption by RS libraries and doesn't solve the type/usefulness to APIs aspect, which is fundamentally what we're after

that said, I think @DougLea 's proposal opens up another very interesting discussion at the protocol level: the ability for a Subscriber to communicate the sum total of its demand in one call (or at least communicate to the Publisher that is won't need more than these last N elements). This amounts to an alternative to request+cancel that communicates that this is a "happy path". Think differentiating a cancellation originating from take vs from timeout. This is a more general and impacting change though, and should be probably discussed in another issue.

My reservation with the SinglePublisher proposal is that response bounds are not necessarily properties of a Publisher or a Subscriber, but instead parameters of a protocol (i.e., Subscription), that cannot currently be expressed. Adding SinglePublisher without fixing this invites further flailing.

From my POV, extending Publisher for 0..1 types isn’t the most appropriate design as request-n is implicit upon subscribe. However, if we do go that route, I agree with @DougLea that establishing response bounds should be the first step. All proposals here are opt-in so there is no backward incompatibility.

@simonbasle it looks like null == absence of an element is a common understanding in the reactor world. I am afraid it breaks down when you consider that null can be emitted by a Publisher; would that mean it does not count towards request-n?

@NiteshKant null is not a valid element in RS: https://github.com/reactive-streams/reactive-streams-jvm#2.13

@simonbasle it looks like null == absence of an element is a common understanding in the reactor world. I am afraid it breaks down when you consider that null can be emitted by a Publisher; would that mean it does not count towards request-n?

@NiteshKant
In reactor null is used for 2 cases - indicating an element when there is an ASYNC fusion mode, so this is a signal to drain the underlying queue, otherwise it is invalid
Sent with GitHawk

@NiteshKant

From my POV, extending Publisher for 0..1 types isn’t the most appropriate design as request-n is implicit upon subscribe

MonoPublisher does not change the spec. There is no implicit request-n.
Also, the primary goal of MonoPublisher is to be able to know that such Publisher producers at most one item (mostly for the end users that need to know it).
To optimize (with instanceof) or not is left to the frameworks and outside of the scope of this PR. It just a nice side effect of having this change - the runtime introspection of Future-like Publishers. That said, I'd be happy to see a follow up on this topic!

@viktorklang ahha ... thanks!
@simonbasle sorry about that point then 🙂
I guess nullable return types are a Maybe making the variant list:

public Collection<T> getAllUsers() <- return type represented as a Publisher
public T getUser(String userId) <- return type represented as a Single. Error if T is null
@Nullable public T getUserIfExists(String userId) <- return type represented as a Maybe/Mono
public void recordEventForUser(String userId, Event event) <- return type represented as a Completable.

How does this change relate to the stated goal of Reactive Streams (from the README):

It is the intention of this specification to allow the creation of many conforming implementations, which by virtue of abiding by the rules will be able to interoperate smoothly, preserving the aforementioned benefits and characteristics across the whole processing graph of a stream application.
It should be noted that the precise nature of stream manipulations (transformation, splitting, merging, etc.) is not covered by this specification. Reactive Streams are only concerned with mediating the stream of data between different API Components. In their development care has been taken to ensure that all basic ways of combining streams can be expressed.

Note that there is nothing in the stated goal about providing an end-developer facing API, in fact, the second paragraph explicitly excludes such high level API concerns from the specification, and states that the spec is only about low level mediation, ie, runtime concerns. The goal of increased type safety seems to be one that I believe is focused on end-developer experience, not low level mediation, and so this use case, I believe, is not applicable to Reactive Streams.
The JDK already has an asynchronous mono type - CompletionStage. Its semantics are well defined, it supports multiple implementations, it provides much stronger type safety from the point of view of enforcing that only a single element is emitted, and it's even suitable for use as an end developer type. If the goal is to deliver increased type safety across implementations, why not use that? This seems to be an attempt to compete with that.

@jroper

The JDK already has an asynchronous mono type - CompletionStage. Its semantics are well defined, it supports multiple implementations, it provides much stronger type safety from the point of view of enforcing that only a single element is emitted, and it's even suitable for use as an end developer type. If the goal is to deliver increased type safety across implementations, why not use that? This seems to be an attempt to compete with that.

CompletionStage does not represent lazy-evaluated type so I would never use this one in the reactive world. As it was discussed earlier, CompletionStage missing the fundamental capabilities like cancellation so this is another valuable NEVER USE IT.

The goal of increased type safety seems to be one that I believe is focused on end-developer experience, not low level mediation, and so this use case, I believe, is not applicable to Reactive Streams.

Indeed, this is higher level API, but the world needs it. it has shown the demand for many projects.
That said, if not reactive-streams would be a holder of such API, then other initiatives will be created instead to provide a common standard Reactive Type for a lazy, cancellable stream of a single or empty value.

@jroper thanks for joining the conversation!

The JDK already has an asynchronous mono type - CompletionStage
This seems to be an attempt to compete with that.

While CompletionStage is indeed a popular type used for representing the result of some asynchronous action, there are two things that make me still want to have MonoPublisher:

lack of cancellation. CompletionStage does not define anything for cancelling the operation, and IMO the strongly defined cancellation is one of the things that make Reactive Streams so nice. And even if toCompletableFuture() is used, due to CompletableFuture's implementation where cancel would just mark it as "ignore the result" and continue waiting for the result, there is a high chance that it will be ignored by the end user since he is not used to cancelling CompletableFutures.
weak protocol - although CompletionStage does not enforce the "hot" nature of it, the JDK uses it as a hot source. If one wants to have a lazy CompletionStage, they need to write quite some code (especially on Java 8), while RS' Publisher (and MonoPublisher, respectively) clearly defines the cold behaviour.

Note that there is nothing in the stated goal about providing an end-developer facing API, in fact, the second paragraph explicitly excludes such high level API concerns from the specification, and states that the spec is only about low level mediation, ie, runtime concerns. The goal of increased type safety seems to be one that I believe is focused on end-developer experience, not low level mediation, and so this use case, I believe, is not applicable to Reactive Streams.

Regarding this one: I would maybe agree if not the Processor type which is just a convenient helper interface that extends both Publisher and Subscriber. Also, I'd say I've seen waaay less usages of Processor in the wild compared to places where MonoPublisher could be used and helpful.

the spec is only about low level mediation, ie, runtime concerns
The goal of increased type safety seems to be one that I believe is focused on end-developer experience, not low level mediation, and so this use case, I believe, is not applicable to Reactive Streams.

the 0..1 specialization is a very important runtime concern that allows the implementations to differentiate potentially infinite Publisher from a singular result. Not only it allows to greatly optimize the operators (e.g. by avoiding a queue, or when it comes to network), but also helps communicating such Publishers between different frameworks (and most of the reactive frameworks have the 0..1 specialization that is not interchangeable at the moment and has to be treated as any other Publisher).

Agreed with @bsideup @OlegDokuka
Even if it is stated in the spec that MonoPublisher shouldn't be used a public contract and only at runtime (which is fine IMO), it is a critical missing piece. There are many cases where the runtime implementation can and should adapt based on whether the emitter is 0..1 or not and surely this is what RS is all about, making it easy for frameworks and tools to implement this kind of interop between reactive libraries, unless this spec is just lip service and in reality developers should just choose one (RxJava, Reactor, Akka etc. ) and stick with it and not expect to be able to interop correctly with other libraries.

@OlegDokuka

Indeed, this is a higher-level API, but the world needs it. It has shown the demand for many projects and all well know reactive libraries implemented such a type.

Even more so, what about map? map is probably the single most common API provided by reactive libraries and used by users, and the world needs it more than MonoPublisher, yet, it's not, and will never be part of Reactive Streams. I don't see how the needs for these types in user facing APIs relates to a need for these types in the Reactive Streams API. If I saw a codebase that was making liberal use of more than one Reactive Streams implementation, I would flag that as a problem. Reactive Streams is an integration API, it's for use at the edges, it allows multiple different technologies to implement the spec to make it trivial to integrate them with any other streaming library. As an end user, when you include a library that doesn't use the reactive streams implementation that you're using generally, then when you get a reactive streams type back from it, you immediately wrap it in your implementations types, and then use your implementations high level methods.
@graemerocher

unless this spec is just lip service and in reality developers should just choose one (RxJava, Reactor, Akka etc. ) and stick with it and not expect to be able to interop correctly with other libraries.

Are you saying that currently, RxJava, Reactor and Akka don't interop correctly between each other when using 0..1 elements? Because if that's the case, we need to put the brakes on right now and fix that, the APIs as they stand today are designed to be able to handle the 0..1 case, indeed there are TCK tests that ensure this.
@bsideup

Regarding this one: I would maybe agree if not the Processor type which is just a convenient helper interface that extends both Publisher and Subscriber. Also, I'd say I've seen waaay less usages of Processor in the wild compared to places where MonoPublisher could be used and helpful.

I agree that Processor is not very useful, but that's not a reason why MonoPublisher should be included, it's a reason why Processor should be removed.

the 0..1 specialization is a very important runtime concern that allows the implementations to differentiate potentially infinite Publisher from a singular result. Not only it allows to greatly optimize the operators (e.g. by avoiding a queue, or when it comes to network), but also helps communicating such Publishers between different frameworks (and most of the reactive frameworks have the 0..1 specialization that is not interchangeable at the moment and has to be treated as any other Publisher).

I agree that some optimisations can be done - though there are plenty of other optimisations too that could be done if we made even more richer types, for example, publishers that are backed by finite in memory collections have some pretty significant optimisations that can be made, failed publishers, subscribers that never back pressure, subscribers that just cancel, subscribers that only take a single element, etc. Where would we stop? And again this is where I come back to the purpose of reactive streams. The primary purpose is interop, performance is important but it is a secondary concern. Facilitating the primary purpose is ensuring that the API is as simple as possible. The fact that reactive streams is only 4 interfaces with 7 methods between them is key to achieving this goal (and as mentioned, one of these interfaces shouldn't even be there). Adding 20% more interfaces will complicate this, it will introduce more edge cases which need to be carefully discussed, and the semantics specified.
The 0..1 publisher optimisations can be implemented without MonoPublisher, simply by providing a helper method that wraps a Publisher in a given frameworks 0..1 publisher interface. Then, that framework can define its own semantics for what to do when the user erroneously passes a 0..n publisher to that method. And that's where I believe performance optimisations belong, it's up to each framework to decide what can be optimised and how it will be optimised. MonoPublisher starts pushing those performance concerns back into the Reactive Streams spec, which muddies the purpose of Reactive Streams.

Are you saying that currently, RxJava, Reactor and Akka don't interop correctly between each other when using 0..1 elements? Because if that's the case, we need to put the brakes on right now and fix that

Sorry, but I don't think we're going to have a healthy and productive discussion if we mock each other and distort words. That's clearly not what @graemerocher said in his comment, and I bet you know that.

The 0..1 publisher optimisations can be implemented without MonoPublisher, simply by providing a helper method that wraps a Publisher in a given frameworks 0..1 publisher interface

You can't do this optimization in RxJava without knowing about Reactor's type.

it's up to each framework to decide what can be optimised and how it will be optimised

Yes, but without a common type, there isn't anything that helps the frameworks to "decide what can be optimised and how it will be optimised"

I agree that some optimisations can be done - though there are plenty of other optimisations too that could be done if we made even more richer types, for example, publishers that are backed by finite in memory collections have some pretty significant optimisations that can be made, failed publishers, subscribers that never back pressure, subscribers that just cancel, subscribers that only take a single element, etc. Where would we stop

We stop at the very low hanging fruit, and it is the MonoPublisher interface. It costs nothing to add, does not change the semantics, but immediately unlocks quite a few possibilities.

Adding 20% more interfaces will complicate this, it will introduce more edge cases which need to be carefully discussed, and the semantics specified.

I would agree here if we change the semantics for 0..1 Publisher, but we don't. What edge cases are you talking about, do you have anything concrete in mind?
Note that we did not propose any new type that would reduce the overhead of subscribe/onSubscribe/request/onNext. Although it is a huge performance optimization, it will indeed require a lot of thinking, edge case hunting, etc etc.


Some heap snapshot related addons

This pull:

Polishes the snapshot routine.
Adds global.__requireOverride callback to allow snap-shotted modules to be loaded directly.
Exposes global.__nativeRequire to allow callback to C++ for non-snap-shotted modules.
Adds a configuration entry in the package.json for a custom snapshot script.

Ping @blagoev @slavchev @Plamen5kov

:+1:

run ci

run ci


Remote configuration for Call screen

Allow using remote UI configuration on the Call screen.
MOB-1570
Implemented:
RemoteConfiguration:
    - callScreen
        - background
        - bottomText
        - duration
        - operator
        - topText
        - buttonBar
            - chatButton, minimizeButton, muteButton, speakerButton, videoButton
                - inactive, active, selected
                    - background
                    - imageColor
                    - title

Nice screenshots!! 👍

Please try to divide it into smaller PRs next time.
But it is very great work. My praises @AndriiHorishniiMOC!

@AndriiHorishniiMOC You've really done a good deal of work. 👍


Remove [xaml] plaintext from WPF articles.

Some of the WPF articles have text [xaml] in them. I think it was there to mark a section as xaml code, but it's not needed. Find and remove these.

[ ] dotnet-desktop-guide\framework\wpf\graphics-multimedia\how-to-create-a-cubic-bezier-curve.md
[ ] dotnet-desktop-guide\framework\wpf\graphics-multimedia\how-to-create-a-linesegment-in-a-pathgeometry.md
[ ] dotnet-desktop-guide\framework\wpf\graphics-multimedia\how-to-create-an-elliptical-arc.md
[ ] dotnet-desktop-guide\framework\wpf\graphics-multimedia\how-to-create-a-quadratic-bezier-curve.md

Hi! I can take care of these.


ConnectivityResolver

ConnectivityResolver is a special customiser used by JcloudsLocation to determine the address and credentials with which a location should be contacted. By default it should behave as the previous logic in JcloudsLocation, but it exposes options to have Brooklyn prefer to contact VMs on private addresses and can be injected on a per-entity basis. For example:
services:
- type: server
  location: the-same-private-network-as-brooklyn
  brooklyn.initializers:
  - type: org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver
    brooklyn.config:
      mode: ONLY_PRIVATE
- type: server
  location: another-cloud
  # implicit use of the default network info customizer.

Would result in the first entity being managed on the instance's private address (and deployment failing if this was not possible) and the second being managed on its public address. Graceful fallback is possible by replacing ONLY_PRIVATE with PREFER_PRIVATE. There are PUBLIC variants of each of these.
These changes were prompted by a thread on the Brooklyn mailing list last December: http://markmail.org/thread/xpr6nsyimv7goewy. Some of the items discussed in that thread have been left for future work. It depends on PRs #497 and #524.
I'd like opinions on:

naming: "BasicLocationNetworkInfoCustomizer" is cumbersome.
whether the class should extend BasicJcloudsLocationCustomizer. I can see it being useful to anyone that wants to subclass BLNIC but at the moment it's totally unused.
whether we should include the publishNetworks option right now. It controls the publication of host.address.{public,private}.n sensors. The idea is good but the feature feels a bit half-baked right now.
whether ManagementAddressResolveOptions is the right way to convey information between the location and the customiser. Again, it's a bit ungainly.

Will have a look through this now, however, on the points for opinion above, my 2¢ worth is:

naming: "Customizer" isn't really needed (we don't insist on e.g. VanillaSoftwareProcessEntity), and this class isn't really "Basic" (which to me refers to the "default no-op" behaviour of BasicJcloudsLocationCustomizer). Also "Location" doesn't add much to the description, when you already have "Network".  The role of the class is about choosing which network you want, not really about "Info" as such so how about org.apache.brooklyn.location.jclouds.NetworkPreference.
what to extend: I suppose another way to look at it is, "if someone changes behaviour in BasicJcloudsLocationCustomizer is that something we would want this to inherit"?   No strong feeling but I tend to think that we would want that, so it should extend it.
publishNetworks - I'd say prefer leaving things as separate as possible, so would suggest leaving that to a separate PR.
resolve options - will have a look.

I tested this successfully:  put a brooklyn on ibm-bluebox-lon-pub, and used it to deploy the blueprint
location: ibm-bluebox-lon-pub
services:
- type: server
  name: custom
  brooklyn.initializers:
  - type: org.apache.brooklyn.location.jclouds.BasicLocationNetworkInfoCustomizer
    brooklyn.config:
      mode: ONLY_PRIVATE
- type: server
  name: default
  # implicit use of the default network info customizer.

i.e. both servers are deployed to the same location as brooklyn, which is configured to create a public address (jclouds.openstack-nova.auto-create-floating-ips: true).
The server 'custom' above was assigned a host address on the private network, while the 'default' one was assigned it on the public network:
$ for ename in custom default ; do printf "%s " ${ename} ;  br app app1 ent ${ename} sensor host.address ; done
custom <IP_ADDRESS>
default <IP_ADDRESS>

naming

I think a more appropriate name for the interface would be ConnectivityResolver and for the implementation DefaultConnectivityResolver (could even drop the location part).

whether the class should extend BasicJcloudsLocationCustomizer:

No

whether we should include the publishNetworks option right now:

it's a nice to have feature, though not sure the current format is optimal, see comments above. If in doubt could include it disabled by default.

whether ManagementAddressResolveOptions is the right way to convey information between the location and the customiser:

My first thought was that JcloudsLocation  + config should be enough, potentially including credentialsOverride. Why include both config and options if it can be reconstructed on the other side.  I favour minimal interfaces which don't duplicate data. But on the other hand I'm happy to leave as is, especially if the bean is reused at other places. Could clean it up in future.

@geomacy @neykov thanks for your thorough comments. Please see 728fb46 for changes addressing your suggestions and c9fcf15 for a simplification of ReachableSocketFinder.

looks good, will merge


One import is not changed, even though others are

Hi, we recently added this for snabbdom, but there seems to be a bug.
In all the files in the build folder the extension is properly added except for jsx.js, the top of the file looks like this:
import { vnode } from "./vnode.js";
import { h } from "./h";
export function Fragment(data, ...children) {

This means the file is getting processed, but for some reason the last import is not. All other files are fine.
I will work around this for now using search and replace.

hey @jvanbruegge, thank you for raising this issue to me, I just saw this in my email. I'll take a look and get back to you

@jvanbruegge the bug should be fixed now, would you like to give it a try before I publish it?

@jvanbruegge is everything working well on your side?

Yes, 1.6.1 is working as expected, all imports are changed


odo add binding - Bind as files UI update

Signed-off-by: Parthvi Vala<EMAIL_ADDRESS>
What type of PR is this:
/kind feature

What does this PR do / why we need it:
This PR adds a more understandable question when asking how to service should be bound to the component.
Which issue(s) this PR fixes:

Fixes #5770
PR acceptance criteria:

[x] Unit test

[x] Integration test

[x] Documentation (https://deploy-preview-5817--odo-docusaurus-preview.netlify.app/docs/3.0.0/command-reference/add-binding)

How to test changes / Special notes to the reviewer:

mkdir /tmp/101; cd /tmp/101
Setup a bindable operator and spawn a service. For example - https://operatorhub.io/operator/cloud-native-postgresql
odo init --name restapi --devfile go --starter go-starter
odo add binding

/retest-required

/approve

/override ci/prow/v4.10-integration-e2e

/lgtm

I feel that we should document the need to either have a running odo dev in a separate terminal, or execute odo dev after adding a binding if it's not running in a separate terminal.

I don't think that has to be the case. odo add binding does not require for the component to be pushed on the cluster, it simply adds data to the devfile, you can run odo dev later on to create it on the cluster. I think the suggestion you made in https://github.com/redhat-developer/odo/pull/5817#discussion_r896426197 should suffice.

/lgtm

/override ci/prow/v4.10-integration-e2e


Increase tail padding

Original tail padding is not long enough which causes worse performance compared to icefall decoding:
for example in the tedlium_dev evaluation:
...THE ANNUAL ICE IN WINTER AND IT CONTRACTS IN (SUMMER->SU)
...TO TWENTY FEET OF SEA LEVEL AS IS (GREENLAND->GREENLA)
...TO CARBON BASED FUELS LIKE DIRTY COAL (AND->ON) FOREIGN (OIL->O)
...TO WORK MAKE US MORE SECURE AND HELP STOP (GLOBAL WARMING->LOBAL WAR)
...IS BOTH THAT FREEDOM IS IN AND OF ITSELF (GOOD->*)

Increasing the padding from 0.3 to 1.0 seems to bring the WER back to the same as icefall:

Could you make it a command line argument?

Could you make it a command line argument?

Done, set default to 1.0

Thanks!

I am surprised 0.3 secs is not enough, is there anything about Sherpa that
explains this?
On Fri, Sep 1, 2023, 8:48 AM Fangjun Kuang @.***> wrote:

Merged #472 https://github.com/k2-fsa/sherpa/pull/472 into master.
—
Reply to this email directly, view it on GitHub
https://github.com/k2-fsa/sherpa/pull/472#event-10251819542, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZFLO4ZUMFBJ66Y4RZPJCTXYEWF7ANCNFSM6AAAAAA4GSF3YI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@shaynemei
Which streaming model are you using and have you tried other values between [0.3, 1.0]?

this is the model I used to run the evaluation:
https://huggingface.co/Zengwei/icefall-asr-librispeech-streaming-zipformer-2023-05-17
I've also tried 0.5 on some of the utterances (didn't run full evaluation for WER), and got a little bit more BPE units at the end but still missing one or two BPE units.


Ability to pick upnp control url

Sorry for opening this again, in the previous code a check was done for urn:schemas-upnp-org:service:WANIPConnection:1 ; That did not work on my router, I later added a check for a PPPIPConnection:1 and only later realised that the trick was there could be multiple of these strings.
I modified the code so that search_gateway defaults to the first one found, but added a function that can be used to create a Gateway using a particular control url. I tested this in different networks and it worked in those! :)

Ah I see I didn't change the implementations inside of the aio directory, I'll fix that in a bit.

Hey, sorrry. I'm busy this week. Don't hesitate to ping me next week if I forget to review this.

It seems like there's a lack of coherence in this. When I built it I got these warnings:
simon@switch:~/projects/rust-igd$ cargo test --all-features
   Compiling igd v0.9.1 (/home/simon/projects/rust-igd)
warning: function is never used: `get_control_urls`
  --> src/search.rs:51:1
   |
51 | pub fn get_control_urls(options: SearchOptions) -> Result<Vec<String>, SearchError> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(dead_code)] on by default

warning: function is never used: `get_gateway_with_control_url`
  --> src/search.rs:76:1
   |
76 | pub fn get_gateway_with_control_url(options: SearchOptions, url: &str) -> Result<Gateway, SearchError>{
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: function is never used: `get_control_urls`
  --> src/search.rs:51:1
   |
51 | pub fn get_control_urls(options: SearchOptions) -> Result<Vec<String>, SearchError> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(dead_code)] on by default

warning: function is never used: `get_gateway_with_control_url`
  --> src/search.rs:76:1
   |
76 | pub fn get_gateway_with_control_url(options: SearchOptions, url: &str) -> Result<Gateway, SearchError>{
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If you want to use these functions as an end user of the library, you should export them publicly. Can you make another PR to rectify this? Ideally I'd like to pick the best device available for this and avoid making the user choose, but I'm not sure how to proceed. I'll look into this further.


update to GraphQL 17

Currently, the GraphQL.js 17 alpha only ships ESM and no CommonJS.
At my current understanding, this implies that all packages within the mono-repository must be completely converted to ESM-only as you cannot sync-require a ESM module from within a CommonJS context.

Related: https://github.com/graphql/graphql-js/issues/3603

@n1ru4l can you update the regression matrix in github actions then?


[WIP] NA OFI: enable tcp provider using tcp;ofi_rxm

Currently does not pass bulk tests.

3 days ago the new 1.7.1 libfabric version has been released. And the changelog shows a lot of improvement and fixes for both TCP and RXM.  Maybe the bulk-transfer tests will pass with this new version

Any progress on this?

Still on my queue to get back to it but should be relatively soon now. Is there anything that you can't currently do with the sockets provider?

Still on my queue to get back to it but should be relatively soon now. Is there anything that you can't currently do with the sockets provider?
Sockets provider is working flawlessly, it is just a matter of performance. We would like to move to the new TCP provider of libfabbric

Still having the same issues with 1.8.0rc1

Bulk requests fail with following error message:
libfabric:24412:tcp:ep_data:tcpx_validate_rx_rma_data():392<warn> invalid rma iov received
libfabric:24412:tcp:domain:tcpx_get_rx_entry_op_read_req():523<warn> invalid rma data
libfabric:24412:ofi_rxm:ep_ctrl:rxm_eq_readerr():88<warn> fi_eq_readerr: err: Invalid argument (22), prov_err: Success (0)

Opened issue https://github.com/ofiwg/libfabric/issues/5102, that's the reason for RMA transfers failing. Still getting some weird completion event tags afterwards though so need to fix that too...

@ael-code please give a try to the topic_ofi_tcp branch, it should be good to go now. Please let me know if you see any issues.

Actually no you should probably wait, there are multi-threading issues reported by the thread sanitizer with lock order inversion issues. That will need to be fixed in libfabric as well it looks like... I'll open another issue tomorrow.

Opened https://github.com/ofiwg/libfabric/issues/5104, should not prevent from using the tcp provider though.

Let me know when I can test this and I'll give back some feedback.

I just tried to test it with a margo example program, but the server isn't starting up.  Here is the output when I set FI_LOG_LEVEL=debug, just snipping the part that looks relevant to tcp:
libfabric:15354:tcp:core:fi_param_define_():231<info> registered var port_low_range
libfabric:15354:tcp:core:fi_param_define_():231<info> registered var port_high_range
libfabric:15354:tcp:core:fi_param_get_():280<info> variable port_high_range=<not set>
libfabric:15354:tcp:core:fi_param_get_():280<info> variable port_low_range=<not set>
libfabric:15354:core:core:ofi_register_provider():374<info> registering provider: tcp (1.0)
libfabric:15354:core:core:ofi_register_provider():374<info> registering provider: ofi_perf_hook (1.0)
libfabric:15354:core:core:ofi_register_provider():374<info> registering provider: ofi_noop_hook (1.0)
libfabric:15354:ofi_rxm:core:fi_param_get_():280<info> variable use_srx=<not set>
libfabric:15354:tcp:core:fi_param_get_():280<info> variable iface=<not set>
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in6://[fe80::c3e6:eea:cff5:75aa]:0
libfabric:15354:tcp:core:ofi_insert_loopback_addr():1092<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_insert_loopback_addr():1104<info> available addr: : fi_sockaddr_in6://[::1]:0
libfabric:15354:core:core:ofi_layering_ok():794<info> Need core provider, skipping ofi_mrail
libfabric:15354:ofi_rxm:core:fi_param_get_():280<info> variable use_srx=<not set>
libfabric:15354:tcp:core:fi_param_get_():280<info> variable iface=<not set>
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in6://[fe80::c3e6:eea:cff5:75aa]:0
libfabric:15354:tcp:core:ofi_insert_loopback_addr():1092<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_insert_loopback_addr():1104<info> available addr: : fi_sockaddr_in6://[::1]:0
libfabric:15354:core:core:ofi_layering_ok():794<info> Need core provider, skipping ofi_mrail
libfabric:15354:tcp:core:fi_param_get_():280<info> variable iface=<not set>
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_get_list_of_addr():1198<info> available addr: : fi_sockaddr_in6://[fe80::c3e6:eea:cff5:75aa]:0
libfabric:15354:tcp:core:ofi_insert_loopback_addr():1092<info> available addr: : fi_sockaddr_in://<IP_ADDRESS>:0
libfabric:15354:tcp:core:ofi_insert_loopback_addr():1104<info> available addr: : fi_sockaddr_in6://[::1]:0
libfabric:15354:core:core:ofi_layering_ok():794<info> Need core provider, skipping ofi_mrail
libfabric:15354:core:core:fi_fabric_():1084<info> Opened fabric: TCP-IP
libfabric:15354:core:core:fi_fabric_():1084<info> Opened fabric: TCP-IP
libfabric:15354:ofi_rxm:core:fi_param_get_():280<info> variable use_srx=<not set>
libfabric:15354:core:core:ofi_layering_ok():794<info> Need core provider, skipping ofi_mrail
libfabric:15354:core:core:fi_param_get_():280<info> variable universe_size=<not set>
libfabric:15354:ofi_rxm:av:util_av_init():455<info> AV size 1024
libfabric:15354:ofi_rxm:core:fi_param_get_():280<info> variable use_srx=<not set>
libfabric:15354:tcp:core:util_getinfo():157<info> FI_SOURCE set, but no node or service
libfabric:15354:core:core:fi_getinfo_():889<warn> fi_getinfo: provider tcp returned -22 (Invalid argument)
libfabric:15354:core:core:ofi_layering_ok():794<info> Need core provider, skipping ofi_mrail
libfabric:15354:core:core:fi_getinfo_():889<warn> fi_getinfo: provider ofi_rxm returned -61 (No data available)
# NA -- Error -- /home/pcarns/working/src/mochi/mercury/src/na/na_ofi.c:2023
 # na_ofi_endpoint_open(): fi_getinfo((null)) failed, rc: -61(No data available).

I'm using "tcp;ofi_rxm://" as the address string on the server.
Do you see anything obvious I'm doing wrong here?

Oh, the server starts if I give it a fully specified address like "ofi+tcp;ofi_rxm://<IP_ADDRESS>:3000".  Is this necessary?  It looks like I would maybe need to modify my client code to allow it to specify it's own address too.

@ael-code yes please give it a try and let me know if you encounter any issues

@carns with sockets before you could start the server without specifying anything?

alright yes I see, we don't really do anything different in the OFI plugin so sounds like a provider issue

Right, even in this branch I can start without a fully specified address using sockets:
# accepting RPCs on address "ofi+sockets://<IP_ADDRESS>:46265"
^C

But not with tcp:
[pcarns@carns-x1 examples (master)]$ ./margo-example-server "tcp;ofi_rxm://"
# NA -- Error -- /home/pcarns/working/src/mochi/mercury/src/na/na_ofi.c:2023
 # na_ofi_endpoint_open(): fi_getinfo((null)) failed, rc: -61(No data available).
# NA -- Error -- /home/pcarns/working/src/mochi/mercury/src/na/na_ofi.c:3282
 # na_ofi_initialize(): Could not create endpoint for (null)
# NA -- Error -- /home/pcarns/working/src/mochi/mercury/src/na/na.c:356
 # NA_Initialize_opt(): Could not initialize plugin
# HG -- Error -- /home/pcarns/working/src/mochi/mercury/src/mercury_core.c:1135
 # hg_core_init(): Could not initialize NA class
# HG -- Error -- /home/pcarns/working/src/mochi/mercury/src/mercury_core.c:3601
 # HG_Core_init_opt(): Cannot initialize HG core layer
# HG -- Error -- /home/pcarns/working/src/mochi/mercury/src/mercury.c:1092
 # HG_Init_opt(): Could not create HG core class
# HG -- Error -- /home/pcarns/working/src/mochi/mercury/src/mercury_core.c:3679
 # HG_Core_context_create_id(): NULL HG core class
# HG -- Error -- /home/pcarns/working/src/mochi/mercury/src/mercury.c:1188
 # HG_Context_create_id(): Could not create context for ID 0
# HG -- Error -- /home/pcarns/working/src/mochi/mercury/src/mercury_core.c:4452
 # HG_Core_create(): NULL HG core context
# HG -- Error -- /home/pcarns/working/src/mochi/mercury/src/mercury.c:1742
 # HG_Create(): Cannot create HG handle with ID 0
[mutex.c:120] ABT_mutex_free: 20
Error: margo_init()

I have not looked in the libfabric code at all, but FWIW the tcp provider man page makes it sound as if it is supposed to be capable of creating it's own "passive" endpoints:
https://github.com/ofiwg/libfabric/blob/master/man/man7/fi_tcp.7#L58
(that part of the man page describes environment variables that set the bounds on port numbers it will select)

As @carns already mentioned, it is not possible anymore to instantiate mercury by providing just the transport protocol prefix. Instead it is necessary to pass at least the hostname/ip/interface field, thus something like this ofi+tcp;ofi_rxm or ofi+tcp;ofi_rxm:// won't work, while ofi+tcp;ofi_rxm://localhost or ofi+tcp;ofi_rxm://<IP_ADDRESS> works.
While on the server I always pass also the ip address I want Mercury to bind to, for the client I usually pass only the protocol string. This was working till now.
Moreover the lookup of addresses is not working for me, when I try to lookup server address I get the following:
[2019-07-11 11:35:28.223] [debug] Looking up address: 'ofi+tcp;ofi_rxm://<IP_ADDRESS>:43809'
# NA -- Error -- /opt/gkfs/deps_src/mercury/src/na/na_ofi.c:3636
 # na_ofi_addr_lookup(): Unrecognized provider type found from:
# HG -- Error -- /opt/gkfs/deps_src/mercury/src/mercury_core.c:1403
 # hg_core_addr_lookup(): Could not start lookup for address
# HG -- Error -- /opt/gkfs/deps_src/mercury/src/mercury_core.c:4290
 # HG_Core_addr_lookup(): Could not lookup address
terminate called after throwing an instance of 'std::runtime_error'
  what():  Failed to lookup address: HG_NA_ERROR

Yes I'm working on getting the initialization fixed. For your lookup error though that looks like an error on your initialization, can you make sure that you're using the same transport/protocol? You might have been using sockets thinking you were using tcp.

Although in the error message that you get, the provider name seems to be blank so let me check that this is not some sort of bad interaction with the formatting of strings when using the SM routing option.

For your lookup error though that looks like an error on your initialization, can you make sure that you're using the same transport/protocol? You might have been using sockets thinking you were using tcp.

I'm sure I'm using the same transport/protocol on both sides

Although in the error message that you get, the provider name seems to be blank so let me check that this is not some sort of bad interaction with the formatting of strings when using the SM routing option.

I've compiled mercury with SM auto-routing option, but I've disable it at runtime.

@ael-code yes that was related to the SM routing issue that you had entered before. I pushed the fix for it, try again now.

@carns please try again, it should work fine now if you just pass ofi+tcp without any hostname

I've tested the new version and I can confirm that the initialization and lookup now works as expected.
Unfortunately I've discovered another minor problem, If I run the new ofi+tcp transportation layer on top of an Omni-path device the very first HG_forward that is issued will never trigger its callback function. That is really strange since the server is actually responding correctly to that RPC.
If I run the same code on the standard TCP interface, everything works as expected.
The old ofi+sockets transportation layer was working both on TCP and Omni-path interface.

I haven't done any extensive testing yet, but I can confirm that the tcp provider works correctly without a fully specified hostname now too.  Thanks @soumagne !  I also confirmed that I can switch back and forth between using the tcp and sockets provider in the same build by using tcp:// or sockets://.


Added Bootstrap 5  cheatsheet

It is an interactive list of Bootstrap 5 classes, variables, and mixins. It also helps you easily find the differences between Bootstrap 4 and Bootstrap 5. Besides, it is the only Bootstrap 5 CheatSheet you will ever need whether you are upgrading your Bootstrap 4 project or starting a new Bootstrap 5 project.
Furthermore, it is aimed towards a large community of bootstrap users who find it difficult to search for bootstrap classes, variables, and mixins. Thus, you'll surely find it amazing, and very useful.
Key Features🛠
• Search for your class, variable, or mixin
• Highlight Difference Between Bootstrap 4 & 5 Classes
• Also, Live preview of HTML & code snippet
• Update code snippet on the go
• Easily copy the code snippet and use it
Useful links🔗
• Website: https://bootstrap-cheatsheet.themeselection.com/
• GitHub: https://github.com/themeselection/bootstrap-cheatsheet

Hi, I'm closing this pull request and opening a new one with some changes.


[WIP] Fixed #30398 -- Added CONN_HEALTH_CHECKS db setting

This is a proof of concept solution for ticket 30398, with no docs or tests yet.
Introduce a CONN_HEALTH_CHECKS DB setting to Django which can be used to enable database connection health checks for Django's persistent DB connections.
If it's set to False (default), the behavior is the same as without this change.
If it's set to True, then health checks are enabled. They work as
follows (assuming an already existing "persistent" DB connection):

Before each connection reuse, perform a connection test
(eg. SELECT 1 query in case of PostgreSQL).

This only happens once per request, regardless of how many DB
transactions will be performed during the handling of the request.

This only happens for "requests" that do use the database.

If the check fails, close the connection and create a new one.

More info about the rationale and motivation in the ticket 30398.

This is a simpler alternative to #11311 (thanks @apollo13 for the suggestion to drop the checks based on the timer), with the general approach being the same.

Closing due to inactivity.

I wonder why this feature is not being considered! I believe it is a very useful feature when you want to use a high CONN_MAX_AGE or when you might need to do some operations (failover, server restart, etc.) on db side. Also it does not contain a lot of complexity in its implementation.

@emadolsky The patch doesn't seem finished (misses tests etc). Feel free to pick it up and open a new PR.


The backend should do a more thorough validation of pipelines

The backend shouldn't assume that the pipeline file submitted is valid. Currently, the frontend blocks the user from submitting a pipeline if it has issues, but in the future this won't always be true.
We should make the following checks at a minimum:

[x] the file has content
[x] the file is valid json
[x] the pipeline version matches the current version of Elyra (this is dependent on:)

the pipeline contains a primary_pipeline field that is a string
the pipeline contains a pipelines field that is an array
the primary_pipeline is findable in the pipelines array
the found primary_pipeline has an app_data field that is an object containing a version field that is a number
the found primary_pipeline has an nodes field that is an array

[x] check for circular references (does not need to be exhaustive, can bail on first found cycle)
[x] validate node properties (initially we can just test for missing required properties, but we might also want to check the types)

Notes:

We shouldn't make assumptions on what the node properties are (i.e. don't assume the node will have a filename field)
This doesn't include checks for runtime / runtime_config, because they aren't included in a raw pipeline file
In preparation for #500 we need to be prepared for more dynamic validation, where properties are validated based on components required properties.

Edit:
I think we cover most of the basic json validation, but we still don't do any deeper checks like circular references and validating node properties. This will probably require some deeper discussion with the pipeline 2.0 changes. We might want to see how possible it would be to use the language server to do this validation?

Closing since https://github.com/elyra-ai/elyra/pull/1664 seems to satisfy all the requirements here


Refactor tx decoder

What was wrong?

When there's an ABI function selector colliding, sometimes a wrong decoder is used
Closes #638

How was it fixed?
Refactor SafeTxDecoder:

Add a method get_abi_function to get the proper abi for data and an optional contract address.
Pass always the contract address with the data to be decoded

Refactor DbTxDecoder:

If the contract address has an ABI on database and can decode the data it will be used first

Add to for the data decoding endpoint

@rmeissner Added to for the data decoding endpoint


SignalR: Redis Backplane: Change to include versioning

Move to include versioning organization  in prep for #31631

Internal previews

📄 File
🔗 Preview link

aspnetcore/signalr/redis-backplane.md
Set up a Redis backplane for ASP.NET Core SignalR scale-out

Did a diff check between the rendered PR and the published doc for versions 8-7-6-5-3-2,2-2,1.  All were good.


has_one child not being persisted when parent is persisted

Hi.
I'm using Mongoid 4.0.0 in a Rails 4.1.4 app.
Your docs say the following for REFERENCED 1-1 relations:

Model#{name}=
Set the child document. If the parent document is persisted, then the child will be saved immediately.     If setting to nil then the child will be deleted.

Given I have, for example, the following models:
class Parent
  include Mongoid::Document

  has_one :child
end

class Child
  include Mongoid::Document

  belongs_to :parent
end

If I do the following:
p = Parent.new
c = Child.new
p.child = c
p.save

It only persists the Parent, not the Child, contradicting your documentation. Is this a bug?, or am I not clear about something?, or missing something?.
Would appreciate your response.
Best regards.

You need to enable autosave on the has_one side:
has_one :child, autosave: true
should fix the problem.

Got it!. Thanks.


Add zip with props

What type of PR is this?

[x] enhancement

What problem(s) does this PR solve?
Description:
Maybe we can use .zip to combine two collections?
Special notes for your reviewer, ex. impact of this fix, design document, etc:
Documentation:

https://scala-lang.org/api/current/scala/collection/View$$Zip.html
https://www.tutorialspoint.com/scala_collections/scala_collections_zip.htm

Codecov Report
Patch coverage has no change and project coverage change: +0.12% :tada:

Comparison is base (2cf3aba) 31.82% compared to head (2f6a987) 31.95%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@             Coverage Diff              @@
##             master     #115      +/-   ##
============================================
+ Coverage     31.82%   31.95%   +0.12%
  Complexity       74       74
============================================
  Files            31       31
  Lines          1505     1499       -6
  Branches        227      228       +1
============================================
  Hits            479      479
+ Misses          951      945       -6
  Partials         75       75

Files Changed
Coverage Δ

...esoft/nebula/connector/writer/NebulaExecutor.scala
0.00% <0.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Keyboard & focus: 404 Video example

https://www.magentaa11y.com/how-to-test/keyboard-focus/
I started utilizing your examples for devs to reference on a project and noticed this wasn't working.

Thanks for calling this out, Raleigh! Seems like it was looking for a folder that no longer exists. We're working on resolving this with an upcoming pull request.

The "How to test with the Keyboard" video is back online, thanks again @raleighvon for calling out the issue!


Incompatibility with @angular/ssr

In Angular 17 the tokens aren't exported anymore by @angular/ssr.
Steps to reproduce the behavior:

Create a new Angular Project with --ssr option.
Create a UnicersalDeviceDetector like in previous versions.
You can not import REQUEST from anywhere.

Expected behavior
The project should be compatible with this pull request i think.

You can add REQUEST and RESPONSE providers to the server.ts
commonEngine       .render({         bootstrap: AppServerModule,         documentFilePath: indexHtml,         url: ${protocol}://${headers.host}${originalUrl},         publicPath: distFolder,         providers: [           {provide: APP_BASE_HREF, useValue: baseUrl},           {provide: 'REQUEST', useValue: req},           {provide: 'RESPONSE', useValue: res},         ],       })       .then((html) => res.send(html))       .catch((err) => next(err));
And then in your custom DeviceDetectorService you can inject REQUEST like this @Optional() @Inject('REQUEST') request: Request
Full example:
 `@Injectable()

export class SsrDeviceDetectorService extends DeviceDetectorService {
constructor(@Inject(PLATFORM_ID) platformId: any, @Optional() @Inject('REQUEST') request: Request) {
super(platformId);
if (isPlatformServer(platformId)) {
super.setDeviceInfo((request.headers['user-agent'] as string) || '');
}
}
}
`
Probably only README.MD needs to be updated.


Added Ubisoft.Connect v122.1.10474

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@denelon here is another issue where WinGetBot finds the "incorrect" version, however File version and Product version shows the same wrong version..


Rework 'Xenakios/SWS: Rename take source files...' and 'Xenakios/SWS: Rename takes and source files...'

warn when filename already exists
closes #407, closes #1498

fix not working if take is a section or reversed
report: https://forum.cockos.com/showpost.php?p=2300847&postcount=2840
(Tested a bit and seems to work so far..)

clean ups

both actions contained quite a bit of identical code, so I tried to combine them into one

:white_check_mark: Build sws 543-master completed (commit https://github.com/reaper-oss/sws/commit/d971b22ab0 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-d971b22a.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-d971b22a.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-d971b22a.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-d971b22a.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-d971b22a.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-d971b22a.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-d971b22a.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-d971b22a.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-d971b22a.tar.xz

:white_check_mark: Build sws 543-master completed (commit https://github.com/reaper-oss/sws/commit/d971b22ab0 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-d971b22a.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-d971b22a.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-d971b22a.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-d971b22a.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-d971b22a.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-d971b22a.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-d971b22a.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-d971b22a.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-d971b22a.tar.xz

:white_check_mark: Build sws 544-master completed (commit https://github.com/reaper-oss/sws/commit/e5e239b1ce by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-e5e239b1.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-e5e239b1.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-e5e239b1.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-e5e239b1.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-e5e239b1.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-e5e239b1.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-e5e239b1.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-e5e239b1.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-e5e239b1.tar.xz

:white_check_mark: Build sws 544-master completed (commit https://github.com/reaper-oss/sws/commit/e5e239b1ce by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-e5e239b1.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-e5e239b1.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-e5e239b1.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-e5e239b1.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-e5e239b1.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-e5e239b1.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-e5e239b1.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-e5e239b1.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-e5e239b1.tar.xz

Thanks, PR updated.
Though the commit history got a bit effed up as there are several commits that depend on each other so I couldn't rebase anymore without conflicts.

Thanks, PR updated.
Though the commit history got a bit effed up as there are several commits that depend on each other so I couldn't rebase anymore without conflicts.

:white_check_mark: Build sws 548-master completed (commit https://github.com/reaper-oss/sws/commit/8b353967ac by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-8b353967.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-8b353967.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-8b353967.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-8b353967.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-8b353967.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-8b353967.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-8b353967.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-8b353967.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-8b353967.tar.xz

:white_check_mark: Build sws 548-master completed (commit https://github.com/reaper-oss/sws/commit/8b353967ac by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-8b353967.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-8b353967.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-8b353967.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-8b353967.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-8b353967.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-8b353967.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-8b353967.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-8b353967.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-8b353967.tar.xz

updated (I've amended the latest commit), thanks.

updated (I've amended the latest commit), thanks.

:white_check_mark: Build sws 549-master completed (commit https://github.com/reaper-oss/sws/commit/abb42a7411 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-abb42a74.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-abb42a74.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-abb42a74.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-abb42a74.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-abb42a74.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-abb42a74.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-abb42a74.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-abb42a74.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-abb42a74.tar.xz

:white_check_mark: Build sws 549-master completed (commit https://github.com/reaper-oss/sws/commit/abb42a7411 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-abb42a74.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-abb42a74.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-abb42a74.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-abb42a74.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-abb42a74.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-abb42a74.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-abb42a74.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-abb42a74.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-abb42a74.tar.xz

I can confirm it works as expected on macOS and Linux now.
I'm noticing playback cuts off while the message box is shown due to the offlining. Could this only be done when necessary, after the prompt?
Also renaming to the original filename (eg. clicking on OK instead of Cancel) shows overwrite the prompt + does an unnecessary peak rebuild. By the way is there a reason for not renaming the old peak file (wouldn't that avoid a potentially slow rebuild)?

Good ideas, thanks.
Updated (I've made a new commit so you can see the changes at a glance, can then be squashed with previous before merging.)

:white_check_mark: Build sws 550-master completed (commit https://github.com/reaper-oss/sws/commit/0fce7ad497 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-0fce7ad4.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-0fce7ad4.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-0fce7ad4.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-0fce7ad4.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-0fce7ad4.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-0fce7ad4.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-0fce7ad4.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-0fce7ad4.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-0fce7ad4.tar.xz

updated, thanks for your patience.
I've also cleaned up the commit/msgs a bit.

:white_check_mark: Build sws 552-master completed (commit https://github.com/reaper-oss/sws/commit/be38783619 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-be387836.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-be387836.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-be387836.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-be387836.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-be387836.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-be387836.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-be387836.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-be387836.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-be387836.tar.xz

:white_check_mark: Build sws 553-master completed (commit https://github.com/reaper-oss/sws/commit/195fceb959 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-195fceb9.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-195fceb9.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-195fceb9.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-195fceb9.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-195fceb9.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-195fceb9.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-195fceb9.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-195fceb9.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-195fceb9.tar.xz

updated, thanks (tough one :D)

EDIT: Looks like Tim will release next SWS tomorrow. I think this PR will need a bit of pre-release time.

Hm..wouldn't it make sense to add it in its current state? (= most likely fixed but untested vs. unfixed)

I'm worried it might have an uncaught regression (perhaps SetFilename behaves differently than PCM_Source_CreateFromFile in some edge cases?). I feel that would be worse in a rare featured version than fixing the old reverse/section bug, adding the overwrite warning feature and optimizing peak rebuilds.
Well, maybe I'm just too cautious...

Ok, then how about adding a stripped down, overwrite warning feature only version?
That's the most important part of this PR imo.

:white_check_mark: Build sws 557-master completed (commit https://github.com/reaper-oss/sws/commit/a87e20a115 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-a87e20a1.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-a87e20a1.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-a87e20a1.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-a87e20a1.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-a87e20a1.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-a87e20a1.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-a87e20a1.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-a87e20a1.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-a87e20a1.tar.xz

That would be perfect! I created a <IP_ADDRESS> branch earlier, you can add the overwrite warning straight to it.

done. (first time I've pushed to SWS directly btw. :cold_sweat:)

I added another commit to wait until after the prompt to offline all media (otherwise it stays offline when cancelling) and avoid prompting when the new filename is identical.
If that's all right I'll squash the commits and update whatsnew later.

Ah yes, I missed to take these changes over, thanks.

:white_check_mark: Build sws 565-master completed (commit https://github.com/reaper-oss/sws/commit/b8f4131798 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-b8f41317.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-b8f41317.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-b8f41317.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-b8f41317.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-b8f41317.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-b8f41317.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-b8f41317.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-b8f41317.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-b8f41317.tar.xz

:white_check_mark: Build sws 571-master completed (commit https://github.com/reaper-oss/sws/commit/3b1ff68901 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-3b1ff689.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-3b1ff689.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-3b1ff689.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-3b1ff689.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-3b1ff689.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-3b1ff689.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-3b1ff689.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-3b1ff689.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-3b1ff689.tar.xz

updated to make the warning prompt default to Cancel rather than Ok (https://github.com/reaper-oss/sws/issues/1498#issuecomment-779848626)

:white_check_mark: Build sws 581-master completed (commit https://github.com/reaper-oss/sws/commit/5d883c47b2 by @nofishonfriday)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-xen-rename-source-prompt-on-overwrite-5d883c47.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-xen-rename-source-prompt-on-overwrite-5d883c47.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-xen-rename-source-prompt-on-overwrite-5d883c47.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-xen-rename-source-prompt-on-overwrite-5d883c47.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-xen-rename-source-prompt-on-overwrite-5d883c47.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-xen-rename-source-prompt-on-overwrite-5d883c47.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-xen-rename-source-prompt-on-overwrite-5d883c47.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-xen-rename-source-prompt-on-overwrite-5d883c47.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-xen-rename-source-prompt-on-overwrite-5d883c47.tar.xz


Lower php version requirements

This lowers the required PHP version from 5.6+ to 5.4+, although 5.3 might also work fine (depending, I've not evaluated the other parts of mysql.php).

@philip can you update the .travis.yml to test on 5.3+?

Why do you need that in 5.4...? Just load the mysql-ext instead?

@staabm currently if you include it, rather than being benign and doing nothing, it will cause a parse error.

@dshafik done.
@staabm A couple reasons come to mind: not everyone controls the extensions available in their environments, and to make including this library harmless for 5.3+ users.

@dshafik Not sure how to handle this situation, but seems require-dev requires a higher PHP version due to the dependencies within. Sorry for all this extra noise I've caused :)

I have fixed the tests in a different branch to work on 5.3+, the code itself is fine. Going to merge this and then apply my changes on top.

Excellent, thanks @dshafik

Oh wow, yay! You ended up fixing 5.3 support, nice.


add riemann sum integral and add setters

cleans up the model integration method and adds a simple R sum for instruments with very fine energy bins

Codecov Report

Merging #521 (9028c45) into dev (2f22f9e) will decrease coverage by 0.20%.
The diff coverage is 25.53%.

@@            Coverage Diff             @@
##              dev     #521      +/-   ##
==========================================
- Coverage   71.53%   71.33%   -0.21%
==========================================
  Files         121      121
  Lines       15450    15488      +38
==========================================
- Hits        11052    11048       -4
- Misses       4398     4440      +42


Deprecate fromServer options & remove ability to specify model class on relationships  176874011

I'm going to break this up differently see https://github.com/artemis-ag/mobx-async-store/pull/88 for the first part


Build with Xdmf support

Hello,
would it be possible to build vtk with xdmf support?
Cheers,
Antoine.

Could you send a PR? The recipe assumes you build it on this container:  https://github.com/conda/conda-concourse-ci/blob/master/docker/c3i-linux-64/Dockerfile

Hi @nehaljwani,
I just created a PR, unfortunately I cannot use docker, but I was able to build and test locally.
Cheers.

Thanks, I will take a look later today or sometime tomorrow.

Do you also have a way to verify it?

I built the recipe with no rendering backend (it's not commited in the PR) because the build fails otherwise on my machine, also the tests from meta.yaml fail when ran by the conda build but they are OK (but the rendering dependent ones on my machine) when done by hand.

Hello @nehaljwani ,
please kindly let me know if you need more information to update the package.

8.2.0 has been built with Xdmf support.

@nehaljwani  Thanks a lot!