How to cancel a running async function

Is it possible to short-circuit a running async function like one can do with a generator by calling its return method?
A use case would be to have a finally block invoked in order to clean up resources, etc.

in a similar vein we have a lot of code that relies on errors coming from outside sources, but I can't find a way to abort a running async function:
async function () {
  // ... get a child process ...

  // caused by some things that do not actually kill the process
  // e.g. stdio causing SIGPIPE
  child_process.on('error', abort);

  // ... do things until .on('exit') ...
}

for a lot of things like streams, where errors are disjoint (not in the same stack as a pending callback) it would be nice to have a clear way to abort.

Throw an error maybe? Instead of aborting.

I'd consider this to be a blocking issue in the current design. If the OP case wasn't addressed (aborting from outside), I would never use async functions and would just stick with the slightly uglier generator+promise option with a runner util.
A possible idea to address:
async function foo() { .. }

var ret = foo();
ret.value;       // promise
ret.done;        // false  <-- optional, could be updated to `true` on completion
ret.return(..);  // analogous to generator return()

so...
foo().value.then(..)

// instead of

foo().then(..)

Not wonderful, but certainly workable compared to no solution.

@getify How does .return() as specified not lead to resource leaks and inconsistent state?
function* () {
    // Set up state and resources
    try {
        yield thing1();
        yield thing2(); // Say you cancel while waiting for this...
        yield thing3();
    } finally {
        // Cleanup
    }
}

If you just cancel that generator with .return() it will leave behind resources and inconsistent state?

The finally block will be executed by .return().
2015-02-19 23:48 GMT+01:00 Petka Antonov<EMAIL_ADDRESS>
@getify https://github.com/getify How does .return() as specified not
lead to resource leaks and inconsistent state?
function* () {
// Set up state and resources
try {
yield thing1();
yield thing2(); // Say you cancel while waiting for this...
yield thing3();
} finally {
// Cleanup
}
}
If you just cancel that generator with .return() it will leave behind
resources and inconsistent state?
—
Reply to this email directly or view it on GitHub
https://github.com/lukehoban/ecmascript-asyncawait/issues/27#issuecomment-75155651
.

@mnieper nothing about that in the es6 spec, and v8 doesn't implement it so cannot test

See here
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator.prototype.return
which relies on
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorresumeabrupt
which in turn resumes a suspended generator in step 11.
Now look at
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-generatorresumeabrupt
where the semantics of yield are given.
-- Marc
(Traceur implements all this.)
2015-02-20 8:32 GMT+01:00 Petka Antonov<EMAIL_ADDRESS>
@mnieper https://github.com/mnieper nothing about that in the es6 spec,
and v8 doesn't implement it so cannot test
—
Reply to this email directly or view it on GitHub
https://github.com/lukehoban/ecmascript-asyncawait/issues/27#issuecomment-75200062
.

As a side note, TBH, I've read those several times before, and I'm still not clear exactly where in there:

the try..finally resumes, and then the finally is given a chance to complete
what happens when a yield is encountered inside the finally.

I don't know if BabelJS is fully up to spec on this return(..) stuff or not, but: bablejs generator yield return finally yield

@getify Babel uses regenerator for generators and async functions. Also important to note that this is also the behaviour of Traceur.

If a yield is encountered inside the finally block, the generator resumes
its normal state.
The return value is saved and returned later (as long as no other return
happens inside the finally block).
See also here: https://bugzilla.mozilla.org/show_bug.cgi?id=1115868
2015-02-20 16:48 GMT+01:00 Sebastian McKenzie<EMAIL_ADDRESS>
@getify https://github.com/getify Babel uses regenerator
https://github.com/facebook/regenerator for generators and async
functions. Also important to note that this is also the behaviour of
Traceur
https://google.github.io/traceur-compiler/demo/repl.html#function *foo() {
  try {
    yield 1%3B
  }
  finally {
    yield 2%3B
  }
  yield 3%3B
}

var it %3D foo()%3B

console.log( it.next() )%3B
console.log( it.return(4) )%3B
console.log( it.next() )%3B
console.log( it.next() )%3B

.
—
Reply to this email directly or view it on GitHub
https://github.com/lukehoban/ecmascript-asyncawait/issues/27#issuecomment-75259707
.

It is the correct behavior, even if it is strange. Just like how finally
may never be invoked if the generator yields during a try block but never
gets resumed. Strange things did happen here. Lots of guarantees have been
thrown out w/ yield.
On Fri, Feb 20, 2015 at 9:48 AM, Sebastian McKenzie <
<EMAIL_ADDRESS>wrote:

@getify https://github.com/getify Babel uses regenerator
https://github.com/facebook/regenerator for generators and async
functions. Also important to note that this is also the behaviour of
Traceur
https://google.github.io/traceur-compiler/demo/repl.html#function *foo() {
  try {
    yield 1%3B
  }
  finally {
    yield 2%3B
  }
  yield 3%3B
}

var it %3D foo()%3B

console.log( it.next() )%3B
console.log( it.return(4) )%3B
console.log( it.next() )%3B
console.log( it.next() )%3B

.
—
Reply to this email directly or view it on GitHub
https://github.com/lukehoban/ecmascript-asyncawait/issues/27#issuecomment-75259707
.

@mnieper i know that's what it does, I was saying I haven't yet been able to fully explain that by the wording I see in the spec. I've read through it carefully several times, and I still keep getting lost.

btw, I just threw together this quick ugly diagram illustrating my point about how a cancelable async function would fit:

The main point is that this doesn't rely on artificially injecting errors through shared scope, nor does it rely on promise cancelation (action at a distance), it instead treats observation and cancelation as separate capabilities (much like early promise/deferreds did, btw!), which only the initiating code (main() in the diagram) receives, leaving the promise to be shared with others in a purely read-only observation role.

other use case that is fairly important that we are using from generator-runner code:
async function () {
  try {
     // init cleanup directives
     let lock = await lockfile(file);
     lock.oncompromised = cancel;
     // stuff that should stop if lock becomes compromised
  }
  finally {
    // cleanup
  }
}

I think this question is really just about what the de facto or de sure standard will be for Promise cancellation.
I personally think a token-based cancellation model that is passed in separately from the Promise instances is a good option for this, that also works great with async/await (see C# precedent for what this looks like at scale).
But I'm not sure there is anything that can/should be changed in the async/await proposal separate from what needs to be done in furthering the models for cancellation around Promise-based APIs.

@lukehoban my concern is when you need to pass the ability to cancel to APIs in use by the async function like the lockfile example I put up.

Having to pass around a cancelation token definitely harms the composability of many async functions, unless some de facto standard emerges where the first (or last) argument is always this token, kinda like the ugly "error-first" style of callbacks in node.
Cancelation of promises is way, way far away from a given. A lot of high-visibility folks are already assuming it'll happen, but there are others (like me) who are ready to die on a sword to try to stop that from happening.
This is not as simple as just "wait for promises to figure it out". Promises shouldn't be cancelable. If that means that async functions shouldn't / won't be cancelable, fine. Just say that. It means some of us won't use them, at least not in all cases, but that's a better outcome than just following the cancelation crowd.

Consider this for a moment: let's say that promises do become cancelable. What does that mean for a running (paused) async function instance if such a signal were somehow received? Is it going to end up doing something almost like what generators do, where it aborts the running context, but then still lets any waiting finally's run? If that's true, then why not actually follow generator's lead design wise and go the direction of having an async function return a controller (as I suggested earlier in the thread) of some sort, which includes both the promise and an abort/cancel/whatever trigger?
This spec could take the lead and come up with something that makes more sense than cancelable promises, and then maybe the fetch(..) crowd could follow that. I tried providing feedback into the fetch(..) thread, but my concerns were mostly disregarded. I have a naive hope that maybe this spec/process will have a more sensible outcome.

I would just like to reinforce, it is not always the outside (where a controller would be) that wants to be able to stop execution, sometimes conditions that compromise a task need to be hooked up inside of the function itself. For this use case I am not sure promise cancellation is even a viable solution, though things like generator's .return are how we are doing this right now.

@bmeck perhaps I missed it, but if the cancelation signal needs to come from inside the async function, why can't throw (from inside a try..finally) work?

@getify timing is the issue, right now you can throw which will work if you do not have out of band cancellation.
In my example, we need to allow the lock to fire a callback to cancel our function. This is because the lockfile library is the authority on when the lock is compromised. If we want to emulate this with try/catch/finally we would need any await to be followed with a check for any cancellations. This would be more akin to return than throw.

out of band cancellation.

Nods. I guess I was assuming all such out-of-band-cancelation could be given access to the controller. which, as you said, already maps to essentially what you're doing now. I can't envision another way of that working.

Just wanted to add another piece of information in support of my suggested "controller" object pattern: Revocable Proxy.
Proxy.revocable(..) returns an object with two properties, the proxy itself and the revoke() function. This is exactly analogous to what I'm suggesting should be the return value from an async function, except instead of revoke() we could call it return() or cancel().

I'm closing this for now. Once the library space figures out how cancellation should work we can start talking about syntax.

Imo promises and async/await is an abstraction to make async code look sync. 99% of times it will be enough - like replacing node errbacks. If the abstraction doesn't fit the use case, than something else than promises (and therefor async/await) should be used, like observables.
Ben Lesh gave a great talk about observables at ng-europe last month and why promises just don't work for ajax requests, for example because they can't be canceled. https://www.youtube.com/watch?v=KOOT7BArVHQ

I'm totally in agreement that if you want it to be cancellable, that promises aren't the correct primitive to use, and therefore async functions aren't the correct primitive to use.

async functions don't have to return promises. that's a choice (and a bad one IMO). this is tail-wagging-the-dog behavior to work backwards from "i want to cancel" to "promises shouldn't be cancelable" to "async functions are the wrong primitive for cancelable actions".

@getify how would you propose async functions encapsulate asynchrony in an alternate reality where they didn't return a promise?

@ljharb please see earlier in this thread (as well as others) where I already suggested a general way how to deal with that.

@ljharb Jafar Husain has a proposal for "Composition Functions" where you could use an arbitrary primitive to handle async functions via a similar syntax:
https://github.com/jhusain/compositional-functions
Example how final code could look like:
https://github.com/jhusain/compositional-functions#refactoring-promise-code-to-use-tasks

I can tell you that right now people are using async/await as it is without any issues. Cancellation is indeed an important thing to consider for async actions, but people are already using es6 promises in the wild, and promises really look like they're here to stay for some time to come. Cancellation can totally be acheived in tandem with using async functions, you just won't have as clean a syntax for it and might need to invent some stuff.
If promise cancellation becomes a part of the spec, then it'd be easy to apply apply it to async functions as well, until then I think that arguing over some fancy cancellation semantics or making up a new primitive for async values is just standing in the way of getting this out and usable.

people are using async/await as it is without any issues

yep, but it's not finalized in the spec yet, so it doesn't have to be permanently set in stone that we made a bad decision (again, IMO) about the return value design.

people are already using es6 promises in the wild, and promises really look like they're here to stay for some time to come

sure. not in contention at all. nothing I suggested does away with (or even changes) them. only changes async functions to return both a promise AND a cancelation trigger, as separate entities.

If promise cancellation becomes a part of the spec, then it'd be easy to apply it to async functions as well

i'm already well on record as thinking cancelable promises is a bad idea. so the argument of, "just wait for this future bad design decision" holds no water for me.

until then I think that arguing ... standing in the way of getting this out and usable.

this is certainly not the first time that we've rushed to get some cool fancy toy out to developers and then circled back later to address "important thing"s and ended up making poor design decisions as a result. but just because we've done that plenty doesn't mean we have to be doomed to repeat that here.

If we waited for each of everyone's concerns to be addressed before shipping a standard we'd not have a standard. Addressing today's 99% use case with syntax (and if necessary circling back later) seems rational in this environment.

async functions to return both a promise AND a cancelation trigger, as separate entities.
I could see that being useful, however as I understand one of the useful things about async functions is that you can seamlessly have something like

async function foo(){
// something
}

async functiion bar(){
  await foo();
}

Wouldn't that have to change to something like
async functiion bar(){
  await foo().promise;
}
```

Which makes it a lot less clean and less usable, IMO.

Would you perhaps then propose that the returned object has a `.then` which calls `.then` on the promise to make the syntax clean again?

How do you make the cancellation nestable?

Would await have to also take the cancelaltion of the async function you're awaiting somewhere? Or does await now take a strange object with a promise and a cancel function instead of a regular promise?

If we waited for each of everyone's concerns

cancelation of async tasks is hardly some niche personal concern.
you'll note that this issue was opened almost 10 months ago, long before async functions were stage 3 and gaining widespread usage in the wild. the concerns were raised long enough ago that there was time to address these concerns before holding up the shipping of the feature.
the problem is this thread was largely ignored. scheduling pressure is a poor excuse for not doing the right thing here.

cancelation of async tasks is hardly some niche personal concern.

Never said it was, nor do I believe that in any sense.

the problem is this thread was largely ignored

I'm sorry you feel that way. In reality, this thread (and many others around GitHub and the web) were discussed repeatedly. You can search the notes for cancellation if you don't believe me, and that's just plenary notes and doesn't take into account the many many conversations that occurred between the champion and interested parties.

scheduling pressure is a poor excuse for not doing the right thing here.

You misstate my argument. Principle of charity would go a long way here.

a lot less clean and less usable, IMO

I don't think it's "a lot less" by any stretch. Whether the property is .pr or .promise, it's only a few extra characters.
BTW, considering the significant complications that the other cancelation approaches introduce (like promise cancelation, etc), it doesn't hold any sway to suggest that .pr is going to be too onerous. There's no zero-impact way to address these concerns, but this is by far the least impactful, IMO.

cancelation of async tasks is hardly some niche personal concern.

I agree with that, however async functions aren't about some concept of "async tasks" they're about having syntactic sugar for working with promises. If you want something cancellable, then we need to either have a primitive that supports that, or have promises support it.

don't think it's "a lot less" by any stretch. Whether the property is .pr or .promise, it's only a few extra characters.

It's totally code smell. And it doesn't address the issue of how the cancellation gets nested. The reason async functions return a promise and await takes a promise is that it makes it very easy to compose async functions. If you can't just await the result of an async function, then it means that fundamentally something was overlooked for making them easily composable.
Is there anything wrong with making the resulting object a thennable that points to the returned promise? (Other than the fact that the cancellation won't be able to be propagated that way)

cancelation of async tasks is hardly some niche personal concern.
Never said it was, nor do I believe that in any sense.
You misstate my argument.

That's not my intention. I'm operating in good faith, and assuming the same of others here.
You said:

Addressing today's 99% use case

I interpret that as to say that, in the context of this thread, that it's been deemed that cancelation of async tasks is at most a 1% concern. I strongly disagree with that assertion.
Then you said:

If we waited ... before shipping a standard

Which I interpreted as falling in line with @RangerMauve's assertions that we just need to ship this thing now, as if it's some un-due burden that everyone's expecting this feature and we can't afford any more delay in getting it to them.
If I'm interpreting those impressions wrongly, I'm happy to be corrected.

as if it's some un-due burden that everyone's expecting this feature and we can't afford any more delay in getting it to them.

Well to be fair, browsers are starting to implement it so there is a bit more urgency in having it stable. Not to say that browsers haven't been too hasty in implementing stuff that was eventually withdrawn.

I want to point out that cancellation means different things.
We could want cancellation to signal stopping and action, we could want cancellation to signal that the result is not necessary (but to continue). I would like to voice my concern that people think some magical cancellation directive will suite all needs. And the tone of some people in this thread is very additive in the case of an error. I feel that when/if Promise cancellation does not fit the need, they will add another extension to Promise to make it suite that need. Promise should not be treated as a piece of data we can staple all behavior to.
Controllers like what are in the Compositional Functions by @jhusain , and controller approach like @getify 's and others have suggested are both more flexible, and feel less like they want to keep adding buckets of bolts to a single data structure.

they're about having syntactic sugar for working with promises.

actually, let's me more clear here. they're about syntactic sugar for the generators+promises case. I'm a huge fan of that usage, I teach it all the time, and use it myself in all my code.
but there's a huge difference between writing ES6 generators + promises and writing ES2016'ish async .. await. With generators, I have an external control to cancel/abort the "task" (whatever term you use for it). I actually have this built into my async lib (asynquence), and regularly use it. Generators afford the ability to call .return(..) or .throw(..) on a paused generator. There are many cases where my system design leverages that.
The syntax sugar design of async .. await completely paves over that capability.
The net result is that in those cases I won't be changing from generators + promises to async .. await. That represents the majority of my usage of that pattern.
So we have a design that's supposed to replace the 99% of generators + promises, but at least in my code, it's only going to replace about 5-10% of those usages.
It's tempting to dismiss my concern as the tiny 1%. And if that's the inclination, I suppose there's not much I can do to change that. But I observe that external cancelation forces are extremely common in my coding style, and that I'm not alone in feeling that async .. await falls short of considering that rather important detail.

@getify quite simply stated, vast amounts of promise-using code written today could be improved with async functions. That is a huge, measurably positive impact on the ecosystem. Standards should not let the perfect be the enemy of the good, and sometimes that means not addressing new use cases (especially extremely contentious ones like cancellation) when we can do something now to address legitimate pain points developers are facing.

sometimes that means not addressing new use cases

And what I fundamentally dispute is that cancelation of async is a "new use case".
I am well aware of how powerful the promises+generator (aka async .. await) pattern is in improving promise'd code. That's central to all my teaching on JS and async programming. But cancelation of those tasks is not some rare thing that is only encountered on the corners of applications. It's absolutely central to proper system design, IMO.
I've observed a wide variety of "work-arounds" for external cancelation when working with callbacks, or with promises. I codified those into a "standard" way of dealing with it in the promise+generator pattern. And now async .. await takes a step back and suggests that detail as rather unimportant (1%'er).

Controllers ... are both more flexible, and feel less like they want to keep adding buckets of bolts to a single data structure.

I agree that they're useful, but I don't really see the point in having new syntax for them when you can already easily use function composition with generators for it since it seems like promises aren't necessarily needed for await in its use case and yield already fills the niche for returning an arbitrary value and pausing execution.

already easily use function composition with generators

The major argument for async .. await is that the generator+promise pattern presents a burden to coders in that they need a lib to drive the pause/resume cycle. So I think "easily use" is misappropriated here.
If it's "easily use", then we don't need async .. await. If it's a burden, then we need it syntactically to relieve lib burden. But then we shouldn't be so quick to throw out an important function that the lib-driven pattern affords.

BTW, it's not clear to me that a future "lib + async .. await" will even be sufficient for handling cancelation, but rather that more than likely it'll be a "lib + generators/promises" answer. As I said, that's going to the majority of my usage, so it feels to me like async .. await is really missing an important piece.

If it's "easily use", then we don't need async .. await.

The controllers/ compositional functions mentioned require external libraries to define the controllers, so I'm not sure I understand where you're going with that.

require external libraries

My suggestion of a simple "controller object" with a .pr and cancel() properties on it certainly doesn't require any kind of lib for any developer to use.
If they care about cancelation, they use destructuring to assign off both properties and use each as necessary. If they don't care about cancelation, they simply keep chaining with the extra .pr in the chain, and move on.

@getify It's clearly a new use case since promises are not cancellable. No one even agrees on what cancellation means so to claim there is some well-established "use case" that is cancellation seems fallacious. Yes, in general, people would like to cancel promises. Yes, it would be great to cancel async functions as well. Addressing that problem will require much effort and IMO now is not the time to do it when we have a proposal that will address (for most people) huge pain points in writing promise code today.
Async functions are not sugar for generators + promises, they are sugar for promise returning functions. The generator is an implementation detail of the async function body.

My suggestion of a simple "controller object" with a .pr and cancel() properties on it certainly doesn't require any kind of lib for any developer to use.

.pr definately clashes with the naming conventions in the rest of the language, so it'd likely need to be .promise
However it still seems like what you want is just something that isn't promises. It's fine to want cancellation, and I genuinely would see use in having cancellable async tasks. However async functions are really about dealing with promises, which don't have cancellation semantics.
If anything it'd be cool if there was a spec specifically for cancellable things like async iterators or observables which has syntactic sugar for working with them. However that would be a different spec with a different primitive at its core.

It's clearly a new use case since promises are not cancellable.

No, no, no. You're still tail-wagging-the-dog here. People have been writing async code and affording external cancelation of those operations, for decades before promises landed in JS.
The fact that long ago someone decided that async function had to return a promise is why you're saying that the promise cancelation is new. But I'm talking about async operation cancelation, which far predates such.

Yes, in general, people would like to cancel promises.

Actually, I don't think that many people want this. I think most want to be able to cancel some async operation, when all they have in hand to represent that operation is a promise for its completion. So, the tail-wagging-the-dog gets us to, "oh, I need a cancelable promise to signal (backpressure like) into the operation that it should stop."

No, no, no. You're still tail-wagging-the-dog here.

No, it's very clear that the people want to have a more pleasant way to work with promises, and this is serving those needs,
If you want a cancellable async task, then you're looking for a new proposal that deals with cancellable async tasks at it's core, not one that aims to make functions that return promises easier to work with.

when we have a proposal that will address (for most people) huge pain points in writing promise code today.

And you're apparently discounting the "cost" that circling back to address it later (if ever!) will afford. It will be far too late to have a "simple" solution like the one I'm suggesting, and instead we'll be forced into some sub-optimal solution like a cancelable promise.
Of course, if you think those solutions are awesome, you don't agree with my concern. But my concern is driven by the fact that "rushing" async .. await out as-is ties our hands for future addressing of the concern.
You've eloquently articulated how the standards process is supposed to concern itself with the majority cases. In general, I agree. But standards processes should also carefully consider the future-cost. We often do that in these standards. I think we should be doing so here.
And that's the part of this discussion I feel hasn't been properly attended yet.

If you want a cancellable async task, then you're looking for a new proposal

I already have one in ES6. I'm saying this new async .. await falls short of what its goal ostensibly was, to obviate most of the need for the generator + promise pattern.

to obviate most of the need for the generator + promise pattern

Yeah, the pattern in popular libraries such as co which makes no mention of cancellation.
Your personal library, asyquence is cool, however it's not nearly as prevalent.

it still seems like what you want is just something that isn't promises.

That's just not true. I consider promises an observation of a future-value completion. That's a read-only operation. I don't think promises should have any external notion of change or cancelation.
But that's entirely orthogonal to the idea that the set of tasks that an async function performs might need to be externally interrupted. Cancelation is an entirely separate capability and concern from wanting to observe if that function finished or not.

@getify What is the standard cancellation mechanism people exposed? It doesn't exist, there are many conventions. And those uses are far outweighed by people who don't care about cancellation and use promises as they are. Async functions as they are now are for this vast majority.
I understand you consider cancellation a critical scenario but I simply disagree with you that cancellation is so important that it needs to be addressed before shipping async functions.
Many people clearly want cancellable promises (it has been added to many libraries and discussed far and wide). Future cost has certainly been discussed (search the meeting notes). I also agree with your concern (as I've stated), I just disagree with your proposed solution (again, as I've stated). I don't know where you read that the goal of async functions is to obviate generator+promise pattern (as I've stated, the goal is to replace promise-returning functions).

I don't think promises should have any external notion of change or cancelation.

Async functions should have the same semantics of promises since they're trying to be the same as other functions that return promises, just with nice syntax for doing more async actions internally if needed.

as I've stated, the goal is to replace promise-returning functions

That makes absolutely no sense to me. Would you say that the design motivation behind generators was to replace iterator-returning functions? That completely discounts all the power/magic of locally-pausable stacks that both of them afford.
The predominant view of the generators + promises pattern is that it's primary goal has nothing to do with the return value being an iterator -- that's an implementation detail -- but rather than yield lets you wait on a promise in a synchronous fashion, meaning you don't need nested callbacks or promise chains to express asynchronous series of operations.
The only problem is that this pattern requires a lib to hook up the yielded promise to the iterator.next() call.
Then enters async .. await, which does exactly that for you. I don't see how anyone can argue that async .. await is predominantly about its return value and not about the localized sync-looking semantics inside it.
I'm utterly lost on that assertion.

I simply disagree with you that cancellation is so important

cancelation of async operations has been long precedented before any of the current mechanisms we're discussing arrived on the scene. The most common example would be cancelable Ajax, which has been around a long time (even longer in libs).

I don't see how anyone can argue that async .. await is predominantly about its return value and not about the localized sync-looking semantics inside it.

Again, if we look at the comparisons the community is predominantly using the pattern without cancellation semantics.

@RangerMauve --

relative metrics of my lib versus some other lib are not relevant to the conversation. i never said my lib was somehow a sufficient argument for language design. I only mentioned it as a side note.

you missed my point entirely.  the statement you quoted has zero to do with cancelation and everything to do with literally everyone is currently using async .. await and generators+promises... localized pause-resume over promise continuations.

@getify

Would you like to show me real world statistics about how your proposed semantics are more popular within the community?

Yeah, I got the wrong quote there, sorry! I agree with the point that people are mostly using generators for the pausing ability. However I don't agree with the idea that your particular use, with cancellations, is what everyone is using.

@RangerMauve this brings up a good question though, how many people actually want cancellation, and how many can cancel operations. A lot of existing code does not even have a means for cancellation since all the existing libraries using callbacks etc. could easily place cancellation inside of the control flow code. I would like to avoid using the "everyone is doing it, so it must be better" approach when things such as Compositional Functions are a superset of async...await and can be opted in (heck async could just be a reserved one).
I am on the list of people who actually use cancellation, I have my own generator task library. That being said, most people don't even understand the use case for cancellation since most DOM/npm APIs don't have cancellation abstractions. That said, all of the Promise cancellation abstractions are interesting, but have yet to find one that handles my use cases or those involving resource locks.

Yes async functions make async code look sync. It does not accomplish this with a generator, the generator is just your chosen implementation detail (and conceptual model) of the async function body.
I've already addressed most of your above points and I'm not interested in continuing to restate them.

What is the standard cancellation mechanism people exposed?

If you're looking for language precedent (which I'd argue is stronger than user-land precedent), look at the iterator returned by generators. It's a compound object that returns methods for observing (and controlling) the output of the operation (aka next(..)). It also returns another capability: the throw() and return() methods, for interruption/cancelation.
I drew my inspiration for the controller object returned from an async function directly from the design of generators returning iterators. To me, they're isomorphic.

Would you like to show me real world statistics about how your proposed semantics are more popular within the community?

My proposed semantics meaning how people use my lib? I didn't argue that. As we're all clearly aware, relatively few people use my lib.
My proposed semantics meaning the design of a controller object coming back from an async function? Zero, since the language hasn't done it.
However, there's a whole lot of people using the iterator controller object coming back from generators, and that's the direct inspiration and (language) precedent for that idea.

@bmeck

how many people actually want cancellation, and how many can cancel operations

In terms of node, the only things that are particularly cancellable are things with streaming APIs
In the browser it's pretty much the same with XHR and Websockets that are cancellable.
Really, this leads me to re-enstate that Observables or the such are a better primitive for working with cancellable actions.

@RangerMauve I agree, and just want an option to use alternatives with similar syntax to async/await. There is a proposal that allows this already without trying to be as inflexible. While being inflexible is often an advantage to specifications I will continue to talk about it rather than let the idea of flexibility be cast aside.

which I'd argue is stronger than user-land precedent

New language features should exist to better development for the users, not to satisfy what someone considers to be "a stronger language precedent". The usage of language features by the community should definitely be considered more heavily in development of new features, otherwise who are those features being made for? Just to add bloat?

@RangerMauve using language precedent for future design is one way of achieving language design consistency, which leads to better learnability, etc.
Paving the temporary hack cowpaths that userland comes up with while waiting around impatiently on the language actively does not aid in that particular goal.

is there anyone seriously saying right now, "that iterator-returned-from-generator design decision was bad, because for example it made chaining multiple sequential generators together harder/more awkward"?
If not, then I think the design of iterator-controller-object-as-return-value is just as valid a suggestion for language design as anything else userland comes up with.

Just because a function isn't labelled async doesn't mean it is not async. That's how it is in javascript. Everywhere you do a setTimeout a normal function goes async. You can do everything in an async function - call callbacks, chain promises, subscribe to events, cancel an observable, ...
But one of the most common usecases is just returning a single value async, throwing async, catching that async exception. Just like we do in synchronous code. And for that simple usecase, async/await provides syntactic sugar. But for everything else, where it goes beyond what sync code would do - everything other than return, try, catch, throw - cancellation, multiple return values, retrying, streaming, progress events - use objects like Observable, Streams, EventEmitter, whatever.
These objects could still be awaited if they implement a then() method and if you're only interested in the return value. Or, you could even first manipulate the object and then await them anyway. But this is not what async functions are for.

@getify I just stumbled ac cross this discussion because I need to make things cancellable in a project that makes heavy use of async/await. If they had gone with your suggestions, my life would have been tremendously easier now.

async programming in js is not just one possible path (as it is in other languages) it's the only path, so its async primitives should be designed to be more than demoware.
That async functions can create huge chains of resumable code blocks that can't be externally cancelled by simply not resuming, which is low hanging fruit, is just ridiculous.
Has tc39 ever done a retrospective on this? Any acknowledgement that this was a mistake?

For anyone who's stumbled on this looking for a solution, I found this to be a great solution and great article:
https://dev.to/chromiumdev/cancellable-async-functions-in-javascript-5gp7
I also wrote a stackoverflow answer about it as well, with additional functionality included:
https://stackoverflow.com/a/59636152/2180570

@vincerubinetti FWIW, I'm not a fan of the approach in that article, as it doesn't truly proactively cancel the functions immediately, only silently when they later resume. I wrote and now use CAF for managing async functions with true-cancellation semantics.

@getify That looks like a good library, I will definitely look into using it for my project.
I'm not exactly sure what you mean by the statement "it doesn't truly cancel". Do you mean it doesn't cancel in-flight requests like fetches? If so, it does kinda mention that at the bottom as an after thought (not super helpful, I know). In my stackoverflow post I give an example of how to integrate AbortController into the request as well. Do you mean that your library can also "in-flight" cancel things besides fetches, like computationally intensive arbitrary asynchronous functions?
It seems to me that there's really nothing wrong with the article's approach, and would still be useful to a lot of people. If I understand how it works correctly, it just makes you split up your function into break points (in between yields) that you can cancel (essentially instantly) between. You of course can't can't cancel things running in-between the yield markers. But it still allows you to break up things that might take long into smaller pieces so you can break in between them and save some time.
But this is just from a very cursory look at your library docs and src, I might be missing something. I'll look into it more later.

I don't want to get too OT for this thread, but briefly...

not exactly sure what you mean by the statement "it doesn't truly cancel".

I mean that the article's concept of comparing nonces doesn't do the comparison until after the await/yield has resolved, meaning that the ajax request (or whatever) has fully completed. If it stays pending, potentially forever, this async function/generator is just left in that pending state and not cleaned up.
Generators are nice for this use-case precisely because they can be stopped immediately using the return/throw methods.

Do you mean that your library can also "in-flight" cancel things besides fetches, like computationally intensive arbitrary asynchronous functions?

CAF uses AbortController cancellation tokens, so they can indeed be passed along to any other utilities that know what to do with AC instances, such as fetch(..). I'm hopeful that the JS community follows the lead of fetch() (and CAF) and standardizes widely on AC for cancellation.

generic promise cancellation is not possible and doesnt make sense.
i told you but you dont want to listen - you want to write texts.

generic promise cancellation is not possible and doesnt make sense.
i told you but you dont want to listen - you want to write texts.

9 down votes say it does


Help tip for enable "Promiscuous mode" for changing MAC address in VLAN interface

Is this commit acceptable?
#6491

I do think visibility is an issue here as well as bouncing a very old translation. Let me think about it.

I've modified it slightly and added more help to it.

Thanks!


Programatically adding description to commands/subcommands

We are programatically adding subcommands to parent command. Using addSubcommand, we could add the name as well as instance of subcommand, but were unable to add the description.
Is there any mechanism to add the description dynamically.

I found the mechanism. Its via
CommandSpec myCommand = CommandSpec.forAnnotatedObject(new MyCommand());
myCommand.usageMessage().description("description").

forAnnotatedObject helps to get all annotation information and then other information can be overridden via usageMessage.
Nice... thanks picocli team. :)


XL9535 relay board power suply

Could you please tell me if it is necessary to supply power in addition to the I2C interface power? The power indicator lights up after only the I2C interface is connected.

Option 1: Power the board and all relays with the input JST (next to USB), as pictured. VIN supports 3.3 or 5V. Not 12V!
Keep J1 jumper connected to bridge the input JST VIN->all other 5V pins and relays.
Disconnect the terminal block, unless you want 3.3/5V out.
Option 2: Dual power rails. Input JST powers the XL9535 IO expander only. None of the relays.
Disconnect J1 jumper to remove input JST's VIN from 5V rail.
Connect a 5V power source to either of the 2 JSTs at the top, the DC jack or the USB-C connector. They are all connected.
All of the relays are powered by this secondary source, with a common ground.
The I2C SDA/SCL/GND pins on all 3 JSTs are connected.

@mcauser Thank you a lot for the clarification!


Allow up/down arrows for input incrementation

I don't really get why they're text inputs and not number inputs

Sure, good idea.
They're text inputs because number inputs don't allow fractions, which some of the controls need.
I just noticed that if you focus on the slider, left/right will adjust it. But now up/down will adjust it if you're focused on any part of the control.


Call Park for Teams Phone Devices

This page says that Call Park is Coming Soon for Teams IP phones. This feature is now available in Teams Phones. Please update the documentation.

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

ID: 3e03ef3d-81d8-c98f-8427-fe7c008ea30f
Version Independent ID: 17af3418-b94d-f233-60c0-778b2e8dc02b
Content: Call park and retrieve in Microsoft Teams - Microsoft Teams
Content Source: Teams/call-park-and-retrieve.md
Service: msteams
GitHub Login: @LolaJacobsen
Microsoft Alias: lolaj

@MySkypeLab Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

@MySkypeLab Thank you for submitting feedback. We understand that this issue has been resolved.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


Support for variables

To add support for variables no new instructions are required. But the memory needs to be divided into two chunks - data space and program space. The program space is where the instructions will be loaded for the processor to execute and the data space is where the data will be loaded. The data can be made into a HashMap with string as key and InnerData as the values. There will be a new offset added now which will be 300 (for data memory) which will be used by both LOAD and POP instructions. There will be no identifiers in the binary and they will be referred to using locations in data memory. For now. For now, the scope of all variables will be global.

Changing the offset to 1, 2, and 3 instead of 100, 200, and 300. As 300 goes out of scope for u8.


Nyla crashes during startup

Hi guys,
new to Nyla - just installed your fork via AUR (I'm on Arch).
Nyla crashes during startup - I see it popping up for 2 secs and it closes again.
nodejs 8.6.0
npm 5.4.2
any logs that would be helpful for you?

Not sure why you're dropping the s in Nylas lol.
I guess your nodejs and npm versions don't matter because you're not building from source correct?
Can you send us the AUR link you're using? Some other members (not NML main contributors) put together the AUR.
Running Nylas from command line and piping the stdout and stderr streams to a file would be helpful.

theres also log files in /tmp i believe that could help


Add babel in devDependencies

Build failed when run npm run buid.
% npm run build
...
sh: babel: command not found

I will take a wild guess and said you didn't do npm install before running npm run build.
But then again, why would you have to, maybe build should run npm install for you too.
What do you think?


VGE Hybrids - Game Crash

My game crashes when it tries to load vgehybridoffspringdefs. Is there a solution?

Hi @SpicyMeat157 ,
I tried to start the Game with VGE-Hybrids but I do not get any errors, and no crashes.
Can you make sure that your mods / game are up-to-date and if it persists I'd need a error log and hugslog.

I use lazy installer and i tried to update again after crashes. It says it is up-to-date.
How do i send an error log?

Lazy installer is a good place to start.
This Wikipage has a general overview, also if you are in the Discord we have the Troubleshooting and Help Channel, which might be a very quick way to solve your problem.

Player.log
I don't have any issues with steam or loading order.I tried Steam file integrity check. I use rimpy and laz installer.It's probably a incompatibility issue but i don't know how to read logs and i don't remember what mod did i install last.

I know my mod list is a little too much but i never had any issues before. This is the first time i am encountering a crash.

I believe this might not have anything to do with RJW-Genes. I don't see anything happening in your log that points to some of my content.
This Error:

b.4104:5/23/2024 12:00:00 AM:1.5.4104 rev435
b.4104:5/23/2024 12:00:00 AM:1.5.4104 rev435
b.4104:5/23/2024 12:00:00 AM:1.5.4104 rev435
b.4104:5/23/2024 12:00:00 AM:1.5.4104 rev435
SOYUZ: target type HediffComp_GenHashInterval_Replacement with error System.TypeLoadException: Could not resolve type with token 01000016 (from typeref, class/assembly rjw.CompHediffBodyPart, RJW, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null)
[Ref 3FCFCF69]
 at (wrapper managed-to-native) System.Reflection.MethodBase.GetMethodBodyInternal(intptr)
 at System.Reflection.MethodBase.GetMethodBody (System.IntPtr handle) [0x00000] in <eae584ce26bc40229c1b1aa476bfa589>:0
 at System.Reflection.MonoMethod.GetMethodBody () [0x00000] in <eae584ce26bc40229c1b1aa476bfa589>:0
 at HarmonyLib.MethodBaseExtensions.HasMethodBody (System.Reflection.MethodBase member) [0x00000] in <abec11463bc04855a5322a0a868aeb22>:0
 at Soyuz.Patches.HediffComp_Patch+HediffComp_GenHashInterval_Replacement+<TargetMethods>d__0.MoveNext () [0x000a5] in <44152e074e9342b6b73476f0e99919e9>:0
 at System.Collections.Generic.LargeArrayBuilder`1[T].AddRange (System.Collections.Generic.IEnumerable`1[T] items) [0x0005e] in <351e49e2a5bf4fd6beabb458ce2255f3>:0
 at System.Collections.Generic.EnumerableHelpers.ToArray[T] (System.Collections.Generic.IEnumerable`1[T] source) [0x00033] in <351e49e2a5bf4fd6beabb458ce2255f3>:0
 at System.Linq.Enumerable.ToArray[TSource] (System.Collections.Generic.IEnumerable`1[T] source) [0x00018] in <351e49e2a5bf4fd6beabb458ce2255f3>:0
 at <0x28aa92d35b0 + 0x00842> <unknown method>
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 39)

However looks like your RJW is not up-to-date or one of your mods is not yet updated.  (CompHediffBodyPart has been renamed / repurposed in the RJW 5.5)

Do you have any idea what mod it could be?

@SpicyMeat157  2 recommendations:

Remove all RJW Mods and add them 1-by-1 in order how much you want to play with them, until you have your error.
For general issues / if you do not know what's going wrong the Trouble-shooting and help channel in the discord is usually very friendly and helpful :)

okay thanks for everything


When computing diagnostics, ignore servers without input ranges

I ran into this crash while running both texlab and ltex-ls on the same
latex file. Logging seems to show that at some point ranges only contain
one entry for ltex-ls when requesting code action, so kak-lsp crashes.
I will try to dig deeper later if needed.
Le dim. 30 juin 2024 à 09:51, Johannes Altmanninger <
@.***> a écrit :

@.**** commented on this pull request.
In src/language_features/code_action.rs
https://github.com/kakoune-lsp/kakoune-lsp/pull/755#discussion_r1660094666
:

@@ -72,7 +72,11 @@ fn code_actions_for_ranges(
{
buff_diags
.iter()

       .filter(|(server_name, d)| ranges_overlap(d.range, ranges[server_name]))

       .filter(|(server_name, d)| {

           ranges

               .get(server_name)

               .is_some_and(|r| ranges_overlap(d.range, *r))

I don't understand how this crash can happen.
ranges should always contain all eligible servers.
How to reproduce the problem?
—
Reply to this email directly, view it on GitHub
https://github.com/kakoune-lsp/kakoune-lsp/pull/755#pullrequestreview-2149973343,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACFEK2PMX7CHABO4GW7JETTZJ62HHAVCNFSM6AAAAABKDS3P56VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCNBZHE3TGMZUGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

I had missed that we're looking at diagnostics here, which may include servers that don't support code actions


Args instantiation update, context-bound Field, rename get* to build*

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Release Date for Version 2.0.0

Hello,
I've read through various issues and noticed mentions of an upcoming version 2.0.0. I am about to start a new project and need to decide whether to wait for the new release or proceed with the current version of the Android-Ble-library with Java. Could you please provide an estimated release date for Version 2.0.0?
Thank you for your help.

Hi,
I'd recommend the current Android-Ble-library with Java. I hoped to have an alpha version before I go for vacation (end of next week), but some other tasks are popping up like mushrooms after a rain, so it has a high risk.
The Java BLE library is popular and went through lots of fixes, so should be stable. I can't say when the Kotlin BLE 2.0 will reach similar status.
Try to keep BLE API isolated so future migration will be possible :)

And sorry for the delays! We're doing everything we can to push projects fast.

Hello,
I pushed my changes to version/2.0 branch.
Supported features:

Client

Scanner
Service discovery
Reading / Writing / Subscribing to values
Reading RSSI
Reading / setting preferred PHY
Subscribing to / requesting connection parameters
Refreshing cache (probably, maybe some delay may be required)
Stub implementation for @Previews, etc.

Server

Not stable API, but no implementation.

Advertiser

Not (yet) supported features:

Client

Bonding / GATT operations when bonded / subscribing to bond state
Mock client implementation

Server

Implementation
Mock implementation

Scanning sample:
https://github.com/NordicSemiconductor/Kotlin-BLE-Library/blob/264f9b5843a75094eab883a3f2e20f18e18b43ee/sample/src/main/java/no/nordicsemi/kotlin/ble/android/sample/scanner/ScannerViewModel.kt#L75-L112

Connection sample:
https://github.com/NordicSemiconductor/Kotlin-BLE-Library/blob/264f9b5843a75094eab883a3f2e20f18e18b43ee/sample/src/main/java/no/nordicsemi/kotlin/ble/android/sample/scanner/ScannerViewModel.kt#L115-L225

How to get an instance of a CentralManager?
Here's how:
https://github.com/NordicSemiconductor/Kotlin-BLE-Library/blob/264f9b5843a75094eab883a3f2e20f18e18b43ee/sample/src/main/java/no/nordicsemi/kotlin/ble/android/sample/di/CentralManagerModule.kt#L66
There's also CentralManager.Factory.mock:
https://github.com/NordicSemiconductor/Kotlin-BLE-Library/blob/34e04bfbc84e32fe5ae3c1f8a96f5e4ff3b40f2d/client-android-mock/src/main/java/no/nordicsemi/kotlin/ble/client/android/mock/MockCentralManagerEngine.kt#L53-L67
but it's not working yet.
The idea is that using the environment one may emulate any platform and possible issues.


Support Foundry v0.7.8

Let's add support for Foundry v0.7.8!

Added in latest series of commits and release v0.3.0.


Add timestamp in results

Problem Statement
In the "results" tab, it's currently impossible to determine what timestamp corresponds to a given entry.

Proposed Solution
Add a special column that contains the timestamp (hour, day, week, etc.)

Developer Notes

Any potential roadblocks or concerns: [e.g. dependencies on other features, limitations in technology]

Example of Results view:
It's currently impossible to determine what timestamp corresponds to a given entry.

Proposed Solution
Add a special column that contains the timestamp (see below the debug view of the same matrix)
Probably just remove the colum Time as it is already registered in the matrix index.

Developer notes
The API call raised when going on the view Results for this example is the following :

GET /studies/study_id/raw?path=matrix_path

The APi calls raised when going on the Debug  view are the following :

GET /studies/study_id/raw?path=matrix_path
GET /studies/study_id/matrixindex
GET studies/study_id/matrixindex?path=output/matrix_path

I do not see the real use of the 2nd API call here but at least we see the matrix index.
The same API call should be raised in both cases to solve this issue (investigate about the 2nd API call which seems odd).

Actually this is the same issue as https://github.com/AntaresSimulatorTeam/AntaREST/issues/1670

Matrix indexes/frequency
The row labels (indexes) are a function of the frequency of the time series.
hourly matrix:
The index data is a date-time string with the format "MM/DD HH:MM".
For example: '07/01 00:00', '07/01 01:00', '07/01 02:00', '07/01 03:00'…
In the legacy IHM, the index format is "DD MMM HH:MM  I", where I is the 1-based index of the time series in the matrix.

daily matrix:
The index data is a date string with the format "MM/DD".
For example: '07/01', '07/02', '07/03', '07/04', '07/05'…
In the legacy IHM, the index format is "DD MMM  I".

weekly matrix:
The index data is a week number with the format WW, where WW is the week number.
For example: 26, 27, 28, 29, 30, 31, 32, 33, 34, 35…
In the legacy IHM, the index format is "WW.

monthly matrix:
The index data is a month number string with the format 'MM', where MM is the month number.
For example: '07', '08', '09', '10', '11', '12', '01', '02'…
In the legacy IHM, the index format is "MMM  I", where I is the 1-based index of the time series in the matrix.

yearly matrix:
The index data is the string "Annual".
In the legacy IHM, the index format is "Annual".


Typo in title of notebook

https://github.com/AIM-SE/DIF-SR/blob/b60005275579b050bcab6af2c3a2c10c015b5d8b/benchmarks/DIF_yelp.md?plain=1#L1
Here it should be Yelp I guess.

Thanks!


Add timestamp extension

Description

Screencast

Checklist

[ ] I read the extension guidelines
[ ] I read the documentation about publishing
[ ] I ran npm run build and tested this distribution build in Raycast
[ ] I checked that files in the assets folder are used by the extension itself
[ ] I checked that assets used by the README are placed outside of the metadata folder

Hi 👋
Thanks for your contribution 🔥
This is already possible in Raycast, did you try<PHONE_NUMBER> to date or now to timestamp


Scaling Problem Fix on iPhone 6 Plus and 6S Plus.

BUG : The problem happened in iPhone 6 Plus and 6S Plus as the scaling is hardcoded for 2x (0.5). So I'm getting the scale dynamically from the device and using.
This fixes the Scaling Problem.

Thanks @iranjith4!


add carrier property to Work

Changes to support adding carrier property to Work using a post-commit hook in Banjo.
@danielbaker @MingtaoSun @JonathanShaw @AaronCMuller @scoen @bsingh-nla

I don't really know about the advisability of this, but if this is a requirement then so be it.


Fix atexit() usage

atexit() takes a function that returns void, so fix cleanup_mem_atexit()
to match.
Signed-off-by: Anton Blanchard<EMAIL_ADDRESS>

Hi Anton,
Thanks for pointing it out. I've already fixed all the warning seen in bin/hxefpu64 and this is one of them. I hope you wont mind if we drop all those changes under one commit.
Thanks,
Manish

As per Manish's comment, rejecting this request. His changes are in pull request #27.


Cannot open components files that break out of layout on Windows

Describe the bug
SvelteKit allows page/layout files to be suffixed with @ followed by the path name of the layout you wish to use, instead of the default one (breaking out of layouts). Svelte Inspector cannot open this file because '@' is not an allowed character.
Reproduction URL

Reproduction
Use Ctrl + Shift and click on a component located in a +page<EMAIL_ADDRESS>Logs
Could not open<EMAIL_ADDRESS>in the editor.

When running on Windows, file names are checked against a safe file name pattern to protect against remote code execution attacks. File names may consist only of alphanumeric characters (all languages), periods, dashes, slashes, and underscores.

System Info
-

This issue belongs to the launch-editor-middleware project


SwiftUI Updated -> Shapes: Shape

Doc: https://developer.apple.com/documentation/SwiftUI/Shape

We have support for this already


M3-859 - Mountebank integration - record/replay api calls under test

Added --record and --replay cli flags to yarn e2e each does the following:

Record Mode

Before test execution starts, it creates an imposter that matches all app requests and proxies them to a proxy host defined in wdio.conf.js mountebankConfig.
Runs the test, the imposter receives each request/response the app makes during the test run
After the test, makes a GET request to mountebank with the "removeProxies" flag to get all requests/response stubs made during the test run.
Saves JSON output from previous GET request to a file matching the path+name of the test spec, but now ending in -stub.json
Deletes the imposter in mountebank. (teardown)

Replay Mode

Before test execution starts, POST the imposter config found in the file matching the path+name of the test spec ending in -stub.json.
Runs the test, each request/response now comes from mountebank and none of the requests make their way to live API's.
After the test, deletes the imposter in mountebank. (teardown)

Running the tests on the recordings raises some interesting issues. I managed to solve generating timestamps (which would be different on every test run.. As in, Test generates timestamp A, but the test "recording" responds with timestamp B (the one at the time of recording). I created a timestamp function that, when running under "record" or "replay" mode, increments whenever it is called. That way, you will always get a known, unique value that can be replicated under record/replay.
To Test

Update your .env file to point to Production services OR  update mountebankConfig.proxyHost to point to dev services.
Update the following .env variable to:

## MOUNTEBANK IMPOSTER API PATH
REACT_APP_API_ROOT=https://localhost:8088/v4

(mountebank path)

restart your local manager

yarn && yarn start
yarn mb # starts mountebank
yarn selenium
yarn e2e --file e2e/specs/search/search.spec.js --replay

@rjstires it's a good question.
I have thought about having a repository just for these mock files and include it in the manager project as an optional sub-module. I will create a tech spike story for that, but I think I will need some support to find the best path forward.


React mounting checksum error doesn't show actual error

I'm using React-Engine backend and webpack on the frontend (https://github.com/paypal/react-engine/blob/master/example/webpack.config.js) that uses mounting (https://github.com/paypal/react-engine#usage-on-client-side-mounting).
If I get a checksum error (we've all seen it before: Uncaught Error: You're trying to render a component to the document using server rendering but the checksum was invalid. This usually means you rendered a different component type or props on the client from the one on the server, or your render() methods are impure. React cannot handle this case due to cross-browser quirks by rendering at the document root. You should look for environment dependent code in your components and ensure the props are the same client and server side: (client) ... (server) ....) it never shows at  (client) (server)  the actual div/span/element where the error is. Mostly it just shows my  or  tags, even though i'm sure i just made an error in a deeply nested component.
An easy error to create is {new Date().toString()}, this will (mostly) render something different on server and client.
Is this because of the single line html string ReactEngine creates on the backend?

@laurenskling I have gotten that error previously. The reason is the "new Date()", and happens when the server and the client have different timezones configuration, which causes the server generate a different DOM than the client does, which leads to the warning you are getting.

I know that's why I created this example error :)
my ticket is about the checksum error not giving me the actual code where the error is happening on.

Any chance of help with this? This is really making me step away from React Engine sadly :(

@laurenskling react-engine is just executing the bootstrapping and the error that you've pasted is directly from react and its not a side effect of using react-engine

I just upgraded to React 16, which has better handling of the checksum error, so now it will tell me:
"Warning: Expected server HTML to contain a matching text node for "Sat Nov 04 2017 16:17:37 GMT+0100 (CET)" in ." 🌈
Having checksum errors (which is not quite uncommon while developing) is an absolute pain with React Engine and React 15. I would advice everyone to get to React 16 as soon as possible and enjoy coding again! 😄


EPIX East

Source
https://www.tvpassport.com/tv-listings/stations/epix-hd-east/7610
Notes
No response

Is it on iptv-org.github.io/epg/guides/us/directv.com.epg.xml.gz ? It didnt show on my tv guide.

Please fix it. Its not working properly.

At the moment, everything is working fine:
https://iptv-org.github.io/epg/guides/us/tvpassport.com.epg.xml.gz

Thank you! I forgot to added "East".


Compute graph support

Bump essential-base and handle the compute graph stuff.
The change is mostly documented in the code to a certain extent. Really the approach involves building the data flow graph (from variables to other variables and constraints) and then compile things in topological order. Also handle the memory hand off between nodes in a reasonable way that matches what essential-check expects.
The change also improves validation_tests to not need to hard code contract and predicate addresses in the JSON solution objects.

This is ready but still requires some extra cleanup post merge. Keeping track of a few things here: https://github.com/essential-contributions/pint/issues/1016

Really most of the changes are in tests. For asm gen tests, these have become a pain so I'm proposing a refactor here, but that's not simple to do.


Update Teams Maximum

Since September 12th the limit is 20 teams -> https://learn.microsoft.com/en-us/azure/devops/release-notes/2022/sprint-209-update?tabs=yaml#increase-delivery-plans-team-limit-from-15-to-20

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

#sign-off


Use awnumar/memguard for protecting secrets at rest

https://github.com/awnumar/memguard

This is difficult to some degree as liboqs-go as well as circl to allocate []byte-slices for storing secrets themselves:

liboqs: https://pkg.go.dev/github.com/open-quantum-safe/liboqs-go/oqs#KeyEncapsulation.GenerateKeyPair

Duplicate of #46


Tailwind JIT not detecting changes (Angular 12).

Which @angular/* package(s) are the source of the bug?
@angular/cli
Is this a regression?
No
Description
I updated from Angular 11 to 12, and now Tailwind JIT is not applying style changes when I add make changing in the HTML.
Please provide a link to a minimal reproduction of the bug
https://github.com/BlockeySports/BlockeyHockeyWebApp
Please provide the exception or error you saw
No response
Please provide the environment you discovered this bug in
Angular CLI: 12.2.5
Node: v12.14.1
Package Manager: npm 7.23.0
OS: Windows 10 x64

Angular: 12.2.5
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1202.5
@angular-devkit/build-angular   12.2.5
@angular-devkit/core            12.2.5
@angular-devkit/schematics      12.2.5
@angular/cdk                    11.2.13
@angular/material               11.2.13
@schematics/angular             12.2.5
rxjs                            6.6.7
typescript                      4.3.5

I'm sorry, but we can't reproduce the problem using the reproduction provided.
Remember that we have a large number of issues to resolve, and have only a limited amount of time to reproduce your issue.
Short, explicit instructions make it much more likely we'll be able to reproduce the problem so we can fix it.
If the problem persists, please open a new issue following our submission guidelines.
A good way to make a minimal repro is to create a new app via ng new repro-app and add the minimum possible code to show the problem. Then you can push this repository to github and link it here.


HSEARCH-2063 Review the pending TODOs

Rebased and merrged https://github.com/hibernate/hibernate-search/pull/1093


mysql reserved words BulkInsertOrUpdateAsync fails

I'm trying to use BulkInsertOrUpdateAsync  and I receive an error: ```You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'Order, `````
Query produced is the following
CREATE TEMPORARY TABLE TradeTemp40a77901 SELECT * FROM Trade LIMIT 0;
INSERT INTO Trade (Id, Account, Order)
SELECT Id, Account, Order
FROM TradeTemp9d1afb60 AS EXCLUDED ON DUPLICATE KEY
UPDATE Account = EXCLUDED.Account,
Order = EXCLUDED.Order;

It seems that the problem is with Order column  which is a reserved word and it fails somehow.

Fixed with 7.0.4


⚠ Samsung has degraded performance

In 97b1796, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2713 ms

Resolved: Samsung performance has improved in e4b7782.


CMS form validation requires fields that should be optional

Problem description
CMS will not allow page creation without "External Webinars" = TRUE. This field should be optional.

@isaac-pulumi can you add more details to this? i didn't even know we used a cms..  heh

This is old - we had a CMS form for posting events that was retired.


Suppport fallback cluster

Ⅰ. Describe what this PR did
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #575 (378cd33) into main (be85637) will not change coverage.
Report is 1 commits behind head on main.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #575   +/-   ##
=======================================
  Coverage   37.46%   37.46%
=======================================
  Files          65       65
  Lines        9215     9215
=======================================
  Hits         3452     3452
  Misses       5497     5497
  Partials      266      266


error: overlap is not transmuted!

Hello,
Thank you for writing this very useful program.  I hope you can help me with this problem.  I see other issues about this error but I haven't gotten it to work.
I ran minimap2 on reference.fasta and target.fasta.
minimap2 -a reference.fasta target.fasta > out.sam
Followed by racon:
racon reference.fasta out.sam target.fasta
I also tried with minimap2 output in paf format.
In each case I get an error:
error: overlap is not transmuted!
Can you suggest how to fix this?  Any advice will be appreciated.

A = reads
B = reference
You can run racon --help to see the arguments (also minimap2 --help).

Thanks again.
I appreciate your help.

Asking for your advice again...
My target sequence is: 2,117,597,479 (haploid)
My reference sequence is: 5,596,238,300 (diploid)
The racon output is: 657,072,055
The paf file (from minimap2) contains 2019406 unique contigs from the target (cut -f 1 | sort | uniq).    But the target has 3678064 contigs, so about half couldn't be mapped, which is fine and not unexpected.
So, my plan is to take all the unmapped contigs from the target and append them to the racon consensus so nothing is lost.   I wanted to ask your opinion on this in case I am not understanding this correctly.

Update: I did some tests on this and it looks correct.

You can use option -u (--include-unpolished) in Racon to get all contigs back.

Great!
Thanks again.


Stop testing way older versions. build/test with go1.19

Signed-off-by: Ville Aikas<EMAIL_ADDRESS>Summary

Stop testing unnecessary older versions.
build/test with go1.19 since that's what our go.mod sez
test with k8s v1.25.x

I think we'll need to also go change the required tests since the matrix is changing? @cpanato
Release Note

Documentation

Will update


💡 [style]: Text is not visible

The text is not visible because of the white blur background color which decreases the visiblirty of text in a small device

Hi @dheeraj1129
Thank you for creating the issue. Please go ahead and start working on it. If you have any questions or need assistance during the process, feel free to ask.
Thank you for your contribution, and I'm excited to see your progress in resolving the issue.

hi, @abhijeet141 I am a beginner in open source contribution, but as I can see, no HTML, CSS, JAVASCRIPT, or REACT files are present. Please tell me how I can run this project, I am struggling with this problem.


Build: NuGet pack errors NU5125 (licenceUrl) and NU5048 (iconUrl)

 Issue by tylerd
Friday Dec 13, 2019 at 18:09 GMT
Originally opened as https://github.com/Wyamio/Wyam/issues/6

URL locations for licence and icon are being deprecated in favor of embedding files inside the NuGet package.
NuGet Warning NU5048
NuGet Warning NU5125
This appears in 2 places during the build.
Create-Library-Packages - Uses the DotNetCorePack cake function, which pulls the configuration from the Directory.Build.props file. This show up in the build as errors.
<PackageLicenseUrl>https://github.com/Wyamio/Wyam/blob/master/LICENSE</PackageLicenseUrl>
<PackageIconUrl>https://wyam.io/Content/images/logo-square-64.png</PackageIconUrl>

Create-Theme-Packages - Uses the NuGetPack cake function with a NuGetPackSettings input object. Only the NU5125 licenceUrl Warning, not the IconUrl.
    IconUrl = new Uri("https://wyam.io/assets/img/logo-square-64.png"),
    LicenseUrl = new Uri("https://github.com/Wyamio/Wyam/blob/master/LICENSE"),

 Comment by tylerd
Friday Dec 13, 2019 at 18:45 GMT

Packing a license expression or a license file
Packing an icon image file

 Comment by daveaglick
Saturday Feb 29, 2020 at 20:59 GMT

FYI - the original Wyam project is being moved to statiqdev to continue work there as Statiq Web (the successor to Wyam and the Wyam blog recipe). Since this issue relates specifically to Wyam, I've transfered it to a new replacement project for legacy Wyam issues.
(This is an automated message)


Actually additions' farmer skips seedling stage

I planted some rice seeds in my farm that was looked over by an AA farmer , and when it harvests it gives 2-3 seeds,and 1 seedling, instead of 3 seedlings
I don't have other farmers  in my pack,but im guessing others may do similar things.
(I havent tested what  it does with the rice in the  paddies, I'll do that later today if I have the time.)

I think it isn't my fault. And it's difficult to solve it, because the way to plant rice is quite different to the vanilla.

I think if I tell them about it they'll just say you just have to add support for the farmer
however im not quite certain how that's done =/

tested with seedlings, they get planted on any water , in any biome (if they don't have farmland under the water they pop off however)

I'll finished it in two days.

https://github.com/Ellpeck/ActuallyAdditions/tree/master/src/main/java/de/ellpeck/actuallyadditions/api/farmer does this help you at all? I can't really read code =/

It may help.


JAV-65, JAV-66 Small issues fixed

JSDOC typo fixe #298
OperationRestriction filter list typo fixed #299

Pull Request Test Coverage Report for Build 746

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 740:
0.0%

Covered Lines:
10

Relevant Lines:
10

💛  - Coveralls


Setup for deployment to heroku

The codebase uses the sphinx search engine and the ruby thinking sphinx library, it looks like there is an add-on for heroku called flying sphinx that provides support for this
http://info.flying-sphinx.com/


Unable to generate Client on Windows VM

Bug description
I installed Windows 10 on a VirtualBox VM, and I'm unable to generate Client.
I see this error:
Error: Unable to require(`C:\Users\me\Desktop\prisma\node_modules\prisma\query_engine-windows.dll.node`)
 \\?\C:\Users\me\Desktop\prisma\node_modules\prisma\query_engine-windows.dll.node is not a valid Win32 application.
\\?\C:\Users\me\Desktop\prisma\node_modules\prisma\query_engine-windows.dll.node
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Running prisma generate via cmd and via GitBash throws the same error. The VM is very new, the only things I installed were Node and GitBash.
How to reproduce

yarn init --yes
yarn add prisma @prisma/client
yarn prisma init
Change the Prisma schema to:

datasource db {
  provider = "sqlite"
  url      = env("DB_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
        id String @id
        name String @default("DefaultName")
}

Create a SQLite file
yarn prisma generate

Expected behavior
yarn prisma generate throws no errors.
Prisma information
Added it in the reproduction steps
Environment & setup

OS: Windows 10 (installed on VirtualBox on macOS)
Database: SQLite (although I don't think this matters)
Node.js version: v14.17.6

Prisma Version
I also cannot run prisma -v, I see this error:
Error: Command failed with exit code<PHONE_NUMBER><EMAIL_ADDRESS>--version
error Command failed with exit code 1.

But my Prisma version is 3.0.2

I tried installing Visual C++ as suggested by https://github.com/prisma/prisma/issues/6508#issuecomment-919483693 (you can do this by checking the box thatsays Automaically install necessary tools during Node.js installation) and that seems to fix this issue.
Not entirely sure why, but leaving this comment for reference and closing this!

List of everything I did:

Create a new VirtualBox VM
Install Windows 10
Install NodeJS, do not check the Automatically install necessary tools during installation
Install GitBash (this is likely not relevant)
Install yarn (also not relevant probably)
In GitBash:

cd ~/Desktop
mkdir prisma
cd prisma
yarn init --yes
yarn add prisma @prisma/client
yarn prisma init

then change the prisma/schema.prisma, and add a model to it. Use the schema I used in the original post, if lazy

In GitBash: yarn prisma generate

I faced this just now and the issue was fixed after installing @prisma/client


Opacity on scrollbar

How would I make any of the scrollbar elements opaque? For instance I want to make the scrollbar thumb opaque. Additionally, I'd probably like to do a hover state to remove the opacity.

Assuming you mean transparent, you could just define a couple of rgba colours in your theme. I'm not sure if I want to go through the process of supporting (e.g.) scrollbar-opacity utilities at this point.

Alternatively, while migrating over to Tailwind 3, I added support for Tailwind's opacity modifiers - so you're free to use something like scrollbar-thumb-red-500/50 to get 50% opacity. Hope that helps!


[Suggestion] Allow mappacks to prevent portal resetting

Include an option to a mappack that prevents players from resetting their portals by pressing "R" (or whichever other key is bound). This allows for more control over portal-based mappacks.

Moved to #59


KAFKA-2098: gradle files

gradle files, tiny footprint.lets have it in.thanks

gradle files, tiny footprint.lets have it in.thanks

gradle files, tiny footprint.lets have it in.thanks

gradle files, tiny footprint.lets have it in.thanks

gradle files, tiny footprint.lets have it in.thanks


[#1982] Add support for ranged communication like telepathy

Adds communication data to the languages data model that tracks distances and units for features like telepathy.

Also includes a large refactor of how trait data models are constructed to match the custom field pattern the system has adopted elsewhere.
Closes #1982

Should it not display as "Telepathy | 120" rather than "Telepathy 120 ft" to match senses?


Tag old releases

There are dozens of releases in https://crates.io/crates/lazy_static/versions that do not appear in https://github.com/rust-lang-nursery/lazy-static.rs/releases. It would be good to track down the git commit corresponding to each one and push the right tags.

Here's most of them:

Version (crates.io)
Commit

0.1.0
76f06e4

0.1.1
missing, but almost 68c4f2a

0.1.2
43739b0

0.1.3
10499f4

0.1.4
0e8b270

0.1.5
bf7a4cb

0.1.6
31a7aa0

0.1.7
b48b0c5

0.1.8
56b4be4

0.1.9
46d69dc

0.1.10
1366fce

0.1.11
94dda0a

0.1.12
0460832

0.1.13
73df714

0.1.14
0cef85e

0.1.15
missing, nothing very close

0.1.16
bdd5fdd

0.2.0
c96788a

0.2.1
ffe65c8

0.2.2
f026ac2

0.2.3
90abea9

0.2.4
f30eb51

0.2.5
73236af

0.2.6
e5e36f1

0.2.7
5f147eb

0.2.8
da32d72

0.2.9
0f4821b

0.2.10
22f755a

0.2.11
5acf245

1.0.0
ecabd81

1.0.1
3fd7d00

1.0.2
9a1f83c

1.1.0
19b57ec

I wrote a small script that checks out versions from the source tree and compares them to the released versions on crates.io. It confirms these versions and commits, modulo the compiletest subdirectory and a mistaken file liblib.so in 0.1.16 through 0.2.1.
I really don't know where 0.1.1 and 0.1.15 went.
Some of these might have merge children that should be tagged instead.
Special note: Currently v0.2 is on 20037705ae9b6ea40889adfd266dd38d0db90466, but the released version 0.2.0 is actually c96788a.


Add node 16 to test matrices

closes #72

Codecov Report

Merging #74 (3b2e8af) into main (c8b5f6c) will increase coverage by 0.35%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #74      +/-   ##
==========================================
+ Coverage   44.47%   44.82%   +0.35%
==========================================
  Files          26       26
  Lines         407      406       -1
  Branches       81       80       -1
==========================================
+ Hits          181      182       +1
+ Misses        206      205       -1
+ Partials       20       19       -1

Please rebase, tests are fixed.

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

npm package (@next-major dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


New smooth mixed l21 norm

I just noticed that you added a commit  which relates to #523.
Please revert that commit and do not mix it with the current PR. If #523 is blocking you finishing this PR, please tackle #523 in a different branch and do a PR closing it. Then you can come back to this one.

see #541 which fixes #523

I just noticed that you added a commit  which relates to #523.
Please revert that commit and do not mix it with the current PR. If #523 is blocking you finishing this PR, please tackle #523 in a different branch and do a PR closing it. Then you can come back to this one.

#523 has been closed in current master by merging #541

Comparing smoothL21norm with GD, FISTA and with the non-smooth version with PDHG, all 10000 iterations. Code and screenshots of results below. Also showing in loglog plots of the objective values, including the dual objective for PDHG. Also a zoom to the 1000-10000 iteration range to emphasize final behaviour.
PDHG shows clear convergence as the primal and dual objective converge nicely to the same value from above and below. This serves as a reference value that the smooth versions should approximate, more closely so if the smoothing parameter epsilon goes to zero.
Note GD uses small step size and appears to continue to converge, albeit slowly.
FISTA uses a manually set small value of the Lipschitz value that may not be valid. FISTA appears to approach to the same value, it shows the characteristic non-monotone wavy behaviour. Also it appears to not improve further, so the manually chosen Lipschitz value may not have been large enough. Nevertheless, this is well-understood behaviour.
In terms of the images, overall they are very similar with some small variations seen in the rightmost central line profile plot, however this is likely due to still not being completely converged.
From this experiment I am sufficiently convinced that the SmoothMixedL21norm TV is a valid approximation of MixedL21norm TV.

import numpy as np
import numpy
import matplotlib.pyplot as plt

from ccpi.optimisation.operators import Gradient, Identity
from ccpi.optimisation.functions import SmoothMixedL21Norm,  L2NormSquared, FunctionOperatorComposition, MixedL21Norm
from ccpi.optimisation.algorithms import GradientDescent, FISTA, PDHG

from ccpi.framework import TestData
import os
import sys

loader = TestData(data_dir=os.path.join(sys.prefix, 'share','ccpi'))
data = loader.load(TestData.SIMPLE_PHANTOM_2D, size=(512,512))
ig = data.geometry
ag = ig

#%%

n1 = TestData.random_noise(data.as_array(), mode = 'gaussian', seed = 10)

noisy_data = ig.allocate()
noisy_data.fill(n1)

alpha = 3
epsilon = 1e-6

Grad = Gradient(ig)

f1 = FunctionOperatorComposition( alpha * SmoothMixedL21Norm(epsilon), Grad)
f2 = 0.5 * L2NormSquared(b=noisy_data)
objective_function = f1  +  f2
step_size = 0.00001

x_init = noisy_data
gd = GradientDescent(x_init, objective_function, step_size,
                     max_iteration = 100000,update_objective_interval = 100)
gd.run(verbose=True)

## Show results
plt.figure(figsize=(20,5))
plt.subplot(1,4,1)
plt.imshow(data.as_array())
plt.title('Ground Truth')
plt.colorbar()
plt.subplot(1,4,2)
plt.imshow(noisy_data.as_array())
plt.title('Noisy Data')
plt.colorbar()
plt.subplot(1,4,3)
plt.imshow(gd.get_output().as_array())
plt.title('GD Reconstruction')
plt.colorbar()
plt.subplot(1,4,4)
plt.plot(np.linspace(0,ig.shape[1],ig.shape[1]), data.as_array()[int(ig.shape[0]/2),:], label = 'GTruth')
plt.plot(np.linspace(0,ig.shape[1],ig.shape[1]), gd.get_output().as_array()[int(ig.shape[0]/2),:], label = 'TV reconstruction')
plt.legend()
plt.title('Middle Line Profiles')
plt.show()

objective_function.L = 1000000

fi = FISTA(x_init, objective_function, max_iteration = 100000,update_objective_interval = 100)
fi.run(verbose=True)

## Show results
plt.figure(figsize=(20,5))
plt.subplot(1,4,1)
plt.imshow(data.as_array())
plt.title('Ground Truth')
plt.colorbar()
plt.subplot(1,4,2)
plt.imshow(noisy_data.as_array())
plt.title('Noisy Data')
plt.colorbar()
plt.subplot(1,4,3)
plt.imshow(fi.get_output().as_array())
plt.title('FISTA Reconstruction')
plt.colorbar()
plt.subplot(1,4,4)
plt.plot(np.linspace(0,ig.shape[1],ig.shape[1]), data.as_array()[int(ig.shape[0]/2),:], label = 'GTruth')
plt.plot(np.linspace(0,ig.shape[1],ig.shape[1]), fi.get_output().as_array()[int(ig.shape[0]/2),:], label = 'TV reconstruction')
plt.legend()
plt.title('Middle Line Profiles')
plt.show()

####################### PDHG

method = 1

operator = Grad
f =  alpha * MixedL21Norm()
g = f2

# Compute operator Norm
normK = operator.norm()

# Primal & dual stepsizes
sigma = 1
tau = 1/(sigma*normK**2)

# Setup and run the PDHG algorithm
pdhg = PDHG(f=f,g=g,operator=operator, tau=tau, sigma=sigma)
pdhg.max_iteration = 100000
pdhg.update_objective_interval = 100
pdhg.run(100000)

## Show results
plt.figure(figsize=(20,5))
plt.subplot(1,4,1)
plt.imshow(data.as_array())
plt.title('Ground Truth')
plt.colorbar()
plt.subplot(1,4,2)
plt.imshow(noisy_data.as_array())
plt.title('Noisy Data')
plt.colorbar()
plt.subplot(1,4,3)
plt.imshow(pdhg.get_output().as_array())
plt.title('PDHG Reconstruction')
plt.colorbar()
plt.subplot(1,4,4)
plt.plot(np.linspace(0,ig.shape[1],ig.shape[1]), data.as_array()[int(ig.shape[0]/2),:], label = 'GTruth')
plt.plot(np.linspace(0,ig.shape[1],ig.shape[1]), pdhg.get_output().as_array()[int(ig.shape[0]/2),:], label = 'TV reconstruction')
plt.legend()
plt.title('Middle Line Profiles')
plt.show()

plt.figure()
plt.loglog(gd.objective,label = 'GD')
plt.loglog(fi.objective,label = 'FISTA')
pdhg_obj = []
pdhg_dobj = []
for sublist in pdhg.objective:
    pdhg_obj.append(sublist[0])
    pdhg_dobj.append(sublist[1])
plt.loglog(pdhg_obj,label = 'PDHG primal')
plt.loglog(pdhg_dobj,label = 'GTruth dual')
plt.legend()
plt.xlabel('iterations')
plt.ylabel('objective')
plt.show()

Excellent comparison, could you please move it to theCILdemos

Comparing smoothL21norm with GD, FISTA and with the non-smooth version with PDHG, all 10000 iterations.

For what regards gradient descent you could leave step_size=None and it'll try to find it with the Armijo rule. Also, if you know the Lipschitz constant, the step_size = L/2 is the theoretical maximum step size, however I've seen step_size = L/3 to work consistently, while the former may be too high (maybe due to numerical errors).

Thanks. I think we need to update the documentation of GradientDescent to
make it clearer that Armijo line search is available.
Yes, larger step sizes can work and one might not get into problems unless
running a lot of iterations, but lack of convergence can go unnoticed if
just looking at the final image.
On Wed, 8 Apr 2020 at 01:10, Edoardo Pasca<EMAIL_ADDRESS>wrote:

Comparing smoothL21norm with GD, FISTA and with the non-smooth version
with PDHG, all 10000 iterations.
For what regards gradient descent you could leave step_size=None and
it'll try to find it with the Armijo rule. Also, if you know the Lipschitz
constant, the step_size = L/2 is the theoretical maximum step size,
however I've seen step_size = L/3 to work consistently, while the former
may be too high (maybe due to numerical errors).
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/vais-ral/CCPi-Framework/pull/521#issuecomment-610663861,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACMDSCB6HWXYY6ITECVPKFTRLOXFPANCNFSM4LU55LBQ
.


While trying to open the context menu on mWeb(Safari) on links, it shows a blue box on the app - reported by @parasharrajat

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Send a message with link on any Chat on Safari mWeb.
Hold press the link to open the context Menu.

Expected Result:
Context Menu should be shown and no blue boxes.
Actual Result:
No Context menu is shown instead a blue box covers most part of the screen.
Workaround:
unknown
Platform:

Where is this issue occurring?

Mobile Web (safari)

Version Number: 1.1.43-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:
Issue reported by: @parasharrajat
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1646674013763799
View all open jobs on GitHub

Yo, yo! I can't reproduce this @parasharrajat, @sophiepintoraetz - can you guys?
Safari mWeb
iOS 15.3.1
v1.1.46-1 (staging)

Did you try it on a link? Any link.
Try this

https://github.com/Expensify/App/issues/8245

Yes, I tried it with this link.. https://goo.gl/maps/xhdJyXp3Kbdr9um27

Testing it again.

@trjExpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

My Mac has issues in running the IOS simulator. I can't test it ATM. I will try to fix the issues and test them asap.

Cool, sounds good. I still can't reproduce this on staging. 👍

@trjExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Any luck?

No Luck. Still can't run the app. I will update you by Monday.

Testing shortly....

I can still reproduce this.
https://user-images.githubusercontent.com/24370807/161832077-4d0b14d7-d84b-4638-ace6-52197f98e577.mp4

@trjExpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

Looking it today.

👋 back from OOO today.

I suggest we open this issue to others for testing on the real device and see if they can reproduce this.

What do you mean by open the issue, do you want to post in #expensify-open-source or something?

Yeah, ask in the open-source slack channel or someone else to test it.

Cool, I'm going to tag a few people here directly that I know are iOS users. @JmillsExpensify @kevinksullivan @MitchExpensify can you guys perform the below steps and let me know the results, please?

Go to mWeb safari on staging.new.expensify.com
Paste any URL into a chat, like this one: https://goo.gl/maps/xhdJyXp3Kbdr9um27
Long press the URL to bring up the context menu
Does it open as you'd expect like this video, or do you get the blue highlighted overlay like @parasharrajat illustrated here using a simulator?

Thanks!

I also cannot reproduce this

Same, worked well for me.

Cool, thanks both. Closing this out then!

QA team was able to reproduced the issue on build <IP_ADDRESS> on mweb/safari
https://user-images.githubusercontent.com/93399543/203415520-89658220-8cf7-4b37-844c-3d120fd73747.mp4

@trjExpensify Created a new ticket per your request https://github.com/Expensify/App/issues/13040


DSWO-4: Hosts and speakers for event page

Ticket URL: paste URL here
About these changes
Creates a re-usable 'people' component that shows a list of people - used for both people and speakers on the event page. Down the line this may need some refactoring if it is to work with other listings that may use different naming in the back-end.
Notes

The heading style for 'Your hosts and speakers' is not correctly matching the design at the moment, and instead uses the default heading styles. We may need to do some work on the heading styles globally to ensure that they match the designs - at the moment there is no change of font-size between mobile and desktop, for example.
The user icon if there is no image uses font-awesome rather than exactly matching the icon in the design - Nick is aware.

How to check these changes
Create an event page, and ensure you add some speakers and hosts. Make sure to check what it looks like if there is no image supplied.
Before assigning to reviewer, please make sure you have

[x] Checked things thoroughly before handing over to reviewer
[x] Checked PR title starts with ticket number as per project conventions to help us keep track of changes
[x] Ensured that PR includes only commits relevant to the ticket
[x] Waited for all CI jobs to pass before requesting a review
[ ] Added/updated tests and documentation where relevant

Merging PR guidance
Follow docs\developer-guide\contributing.md
Deployment guidance
Follow docs\infra\environments.md

@ahosgood fyi I have assigned this to @janehughes for review, but do take a look if you would like to.


Remove build dependency on source force repositories

Seeing a lot of these in recent builds:
[error] SERVER ERROR: Service Unavailable url=http://freemarker.sourceforge.net/maven2/org/codehaus/plexus/plexus/1.0.11/plexus-1.0.11.jar
[error] SERVER ERROR: Service Unavailable url=http://freemarker.sourceforge.net/maven2/org/slf4j/slf4j-parent/1.6.1/slf4j-parent-1.6.1.jar
[error] SERVER ERROR: Service Unavailable url=http://freemarker.sourceforge.net/maven2/org/eclipse/jetty/jetty-parent/18/jetty-parent-18.jar
[error] SERVER ERROR: Service Unavailable url=http://freemarker.sourceforge.net/maven2/org/eclipse/jetty/orbit/jetty-orbit/1/jetty-orbit-1.jar

Connectivity issues aside, Source forge distributes malware and is a pretty crap player nowadays.

yanked for no good reason except yeah I can do this now.

so.. I am trying to just remove the repository references for started. Running what I think is clean process locally.
# supernuke to redownload all the things
$ rm -rf ~/.sbt/staging/  ~/.ivy2/cache/ ~/.m2/repository
$ sbt clean test

that worked.. will raise a PR

actually hold on.. testing that a related example still builds

k https://github.com/openzipkin/zipkin/pull/471


Add a count method to Source

Adds a Source::count(&self) -> usize method to figure out how many key-value pairs to expect.
I've also tried to clarify the expectation that subsequent calls to Source::visit will yield the same key-value pairs unless the visitor fails. A buggy Source::visit with the default implementation of count may yield a different number of key-value pairs. Given that, we could make the method something like Source::size_hint(&self) -> Option<usize> instead, but I think the fundamental requirement that Source::visit passes the same pairs to the visitor unless the visitor itself fails is reasonable and lets us add more useful methods like for_each that don't have to return results. The reason visit itself is fallible is so that a formatting or serialization error can be passed upstream for a logging framework to surface in some way.

r? @Thomasdezeeuw


Add reset block chain and replace voting countdown thread with running in foreground service thread,to solve the operating system's restrictions on background threads and events.

Description
1.Add reset block chain
2.Replace voting countdown thread with running in foreground service thread,to solve the operating system's restrictions on background threads and events.
3.Add close wallet server check box choose view

Thank you @snakewaypasser


Camera can only be read during installation setup

Hi, I am using a Tobii 5 camera. During installation setup, it was turned on (When I was asked if the camera is working, I could see IR blinking), however later when I tried to add my face it no longer worked.
I have tried different device_path and different recording plugins but none of them worked.
I can't find the source code of that setup script, but that implementation seems working for me. Can anyone paste it here? Thanks.

I've searched for similar issues already, and my issue has not been reported yet.
Linux distribution: Ubuntu 22.04
Howdy version (sudo howdy version): 2.6.1

You can find the preinst script here, but in short is just reads input from all devices found in /dev/v4l/by-path/ with streamer


fix: format numbers greater than 9,999,999 correctly

This pull request fixes a bug in the code responsible for formatting numbers for the statistics overlay. For example, one would expect the number 14,000,000 to be displayed as “14M”, but due to the bug the most recent release displays the number as “14,000M” instead.

🙌


partial ts added

Hey, folks!
Thanks for a great library! I've done some ts mapping, it's not yet fully covered (eg. all messages types), but the main api is there.

@Maaasyn thanks for the PR! Checking it out now.


ci: set GitHub Actions on.push.branches-ignore

Set on.push.branches-ignore in lint.yml and test.yml in .github/workflows/ in order to eliminate some duplicated runs.
This change will effectively

exclude dependabot/** branches from push event. That should be fine, because those branches are always connected to pull requests which are then tested in pull_request event.
exclude tags from push event. That should be fine, because the same commit is tested as a branch.

Lint and Test workflows worked fine in this pull request.