Missing "Off Work" Activity in custom API

Describe the bug
When I change status to Appear Offline,

PresenceLight sets activity to "Off Work", but only 2 options in the activity are available (Off and Offline).

To Reproduce
Steps to reproduce the behavior:

change status to Appear Offline,

Click on 'Teams Status'
"Off Work" is not an option in "Custom API Setup"

Expected behavior
Provide option for "Off Work" in API.
Screenshots
See above.
Further details

OS: [e.g. iOS]
PresenceLight App Type (Desktop)
PresenceLight Build (Store)
PresenceLight Version (5.0.19)

There is an option in the Activity Section (you will need to check the "Use Activity Statuses" box

If this is not in the store version, check the nightly
https://presencelight.blob.core.windows.net/nightly/index.html

@ykktrcb7 can you please test?

I got the following error, even after uninstalling the previous version:
Merge failure for shared merged PRI file : error 0x80070490 : Cannot register the 37828IsaacLevin.197278F15330A.Nightly_<IP_ADDRESS>_x64__jvewcxq8vj8qt package because there was a merge failure with the following file: C:\Program Files\WindowsApps\37828IsaacLevin.197278F15330A.Nightly_<IP_ADDRESS>_neutral_split.language-pt_jvewcxq8vj8qt\resources.pri (0x80070490)

If that error happens, a restart usually fixes it.

It happens even after restart. is there anything else i can try?

So you have ALL version of PL uninstalled? And you try to install the Nightly it gives you this error? What is your version of Windows? Also do you have the WebView2 runtime?
https://go.microsoft.com/fwlink/p/?LinkId=2124703

Yes, I have WebView2 and Windows 10. Everything was working before I tried the nightly build. I cleaned all directories and uninstalled PL completely.

Are you able to install the store version or you get the error as well?

The store version installs correctly.

Odd, well I will update this issue when the Store version gets updated

Please try latest version from the store


compose box max height changed from static to 30% of screen height

I changed the screen max height to 30% of the screen height

I see you've replaced this PR with #1056. In future, when you have changes to make, please update the existing PR instead of replacing it with a new one.


Update test results for SortSite

I have re-tested all of our test cases on 15 December 2017 with version 5.27 of SortSite (online and desktop) and updated the results accordingly.
This changes 26 results, mostly to the positive, so that SortSite will climb from the (tied) 7th to the 1st place! That's thanks to the many great changes they did.
Because some issues are only found with the downloadable desktop tool, we introduced a new result category: "Issue found (paid)". That was used for 7 of the results.

@selfthinker when you say 'with the downloadable desktop tool' does that include CI?

@greenc05, the downloadable desktop tool includes the CI version but I have only tested the GUI and not the CI version. I would hope that there is no difference between the results?


js build tool.

Would a gulp-file, or any other js-based tool that is usefull be accepted here ?
Something like watching js/css file and build or are we still in a everything-should-be-in-setup.py ?

I'm not sure, let's talk about it tomorrow.

Added on notes.

From the meeting - let's give gulp a go.


qwen2 fails on MacOS

What is the issue?
ollama run qwen2
Error: llama runner process has terminated: signal: abort trap error:error loading model vocabulary: unknown pre-tokenizer type: 'qwen2'
OS
macOS
GPU
Apple
CPU
Apple
Ollama version
ollama --version ollama version is 0.1.38

Never mind.  it runs on 0.1.42


Add new AsyncContext.callingContext() API

This is a small helper function that allows you to temporarily restore the previous ambient context state (like a snapshot.run(fn) call). This allows us continue with registration-time being the recommended behavior for every API, but allows call-time usecases in the cases that it's necessary.
const asyncVar = new AsyncContext.Variable();

const obj = new EventEmitter();

asyncVar.run("registration", () => {
  obj.on("foo", () => {
    // EventEmitter restored the registration time context before
    // invoking our callback. If the callback wanted to get the context
    // active during the `emit()` call, it would have to receive a
    // Snapshot instance passed by the caller.
    console.log(asyncVar.get()); // => 'registration'

    // But with `AsyncContext.callingContext()`, we're able to restore
    // the caller's context without changing EventEmitter's API.
    // EventEmitter can continue to assume that registration is default
    // that is most useful to developers.
    AsyncContext.callingContext(() => {
      console.log(asyncVar.get()); // => 'call'
    });
  });
});

asyncVar.run("call", () => {
  obj.emit("foo");
});

In yesterday's meeting, we identified a few general cases:

Async queueing APIs (like setTimeout())

These APIs are registration-time, and there is no useful call-time context

Eventing APIs that can invoke sync (like EventEmitter/EventTarget) or async

When it's being invoked sync (obj.emit('foo') or el.dispatchEvent(click)), either registration-time or call-time could be needed.
When it's triggered async (user click interaction, out-of-band loading), then registration-time is appropriate

unhandledrejection

This API is special, and only call-time makes sense. https://github.com/tc39/proposal-async-context/issues/16

This API allows us to handle all use cases, without requiring extensive API changes (eg, accepting an options bag that allows the dev to choose at registration time).

This also allows us to settle https://github.com/tc39/proposal-async-context/issues/18. Async/Generators will capture their init-time context and restore it during every call. But, the generator body itself can restore the call-time context easily:
function* gen() {
  console.log(asyncVar.get()); // => 'init'

  yield 1;

  // Generators and AsyncGenerators always restore the context that was
  // active when they were initialized.
  console.log(asyncVar.get()); // => 'init'

  // The generator can easily restore the calling context's state without
  // requiring the caller to do anything special.
  AsyncContext.callingContext(() => {
    console.log(asyncVar.get()); // => 'second'
  });
}

const it = asyncVar.run("init", () => {
  return gen();
});

asyncVar.run("first", () => it.next());
asyncVar.run("second", () => it.next());

One thing we haven't discussed is what to do with Promises. @mhofman had requested being able to receive both the resolve() call-time context and the p.then(fn) registration time context when invoking fn. With a bit of extra spec work, we could expose that with this same API. I just haven't done the work to propagate the call-time through the Promise reaction jobs yet.

Microsoft attempted to describe a similar formalization of context in this two paths scenario many years ago which sadly didn't go very far unfortunately, but I do think it's a good idea.
Personally I'm wondering if we actually need to restore the context for a window or just be able to read the context. We could alternatively just have a different getter rather than needing the extra closure:
const asyncVar = new AsyncContext.Variable();

const obj = new EventEmitter();

asyncVar.run("registration", () => {
  obj.on("foo", () => {
    // EventEmitter restored the registration time context before
    // invoking our callback. If the callback wanted to get the context
    // active during the `emit()` call, it would have to receive a
    // Snapshot instance passed by the caller.
    console.log(asyncVar.get()); // => 'registration'

    // But with `store.getCallingContext()`, we're able to restore
    // the caller's context without changing EventEmitter's API.
    // EventEmitter can continue to assume that registration is default
    // that is most useful to developers.
    console.log(asyncVar.getCallingContext()); // => 'call'
  });
});

asyncVar.run("call", () => {
  obj.emit("foo");
});

I'm wondering if this satisfies the needs or if there's a specific scenario for actually restoring the context that you have in mind? 🤔

If there are more tools (e.g. OTel tracing, some security monitoring and some context enabling logger,...) around in an application it might happen that there are nested .run() calls.
As a result I doubt a static AsyncContext.callingContext might fit here in all these cases.

@Flarna

If there are more tools (e.g. OTel tracing, some security monitoring and some context enabling logger,...) around in an application it might happen that there are nested .run() calls. As a result I doubt a static AsyncContext.callingContext might fit here in all these cases.

I think the idea is that if you need it, you use it immediately inside the function body, rather than expecting some more deeply-transitive function to check it.  The point is that it provides plumbing that can "undo" the (usually correct) registration-context default in cases where that's necessary.  Just like Snapshot is awkward to use directly, I expect something akin to wrap to show up for this:
function wrapWithCallingContext(fn) {
  return function() {
    return AsyncContext.callingContext(() => fn.apply(this, arguments));
  }
}

Now if you've got a scheduler that you know is going to call your callback in the registration context but it needed to access the calling context, you can instead schedule(wrapWithCallingContext(callback)) and it does the right thing.
I also don't think calls to run are particularly relevant here - if you need to preserve the pre-run context, you can take a Snapshot at the appropriate time.  What we're talking about is when context changes due to a snapshot being restored (either implicitly or explicitly).

@littledan

I'm very skeptical of this proposal as a general solution.

There are more than 2 relevant contexts as @Flarna pointed out. This means I don't know how the API itself should look or be implemented

I think it's pretty straightforward: when the current context ends, the engine knows what context it's going to restore.  That's the context that callingContext should expose.  If you think about it from a polyfill perspective, it's basically just
Snapshot.prototype.run = function(fn, ...args) {
  const savedCurrentContext = $currentContext;
  const savedCallingContext = $callingContext;  // (added)
  $callingContext = $currentContext;  // (added)
  $currentContext = this.context;
  try {
    return fn.apply(null, args);
  } finally {
    $currentContext = savedCurrentContext;
    $callingContext = savedCallingContext; // (added)
  }
}

I don't know whether a similar change should be made to Variable.prototype.run, but either way the analogue is clear.

This proposal would not save us any work on the integration into environments--we still need to find a good default answer which will be used most of the time. And for tasks that are scheduled by the host (so there's no enclosing JS code), they'll now have to provide multiple answers--making integration even more complicated.

You're right that this doesn't save work - good defaults are definitely still important.  I don't think it will produce significant extra work.  The only cases where we might possibly choose anything other than the obvious "immediately surrounding caller" would be cases where there's already something interesting enough going on that we'd already not be using the registration context - so we're already thinking about the relevant non-registration context.  In those cases, the calling context should probably just be null, and the interesting third context should be the default.

I'm really not sure how anyone using AsyncContext will decide whether they want to refer to currentContext() or not. The current snapshot is supposed to be the current context. What is it that they're opting into/out of? How should this be understood?

Allow me to turn this question around somewhat.  As the proposal stands today, this is already an issue: if we're talking about making a decision for every callback-accepting API in the web platform, then we will likely end up with some functions going with registration context and some going with calling (or some other) context.  Even if every builtin API uses registration context, there will inevitably be userland scheduling libraries that end up defaulting into using the calling context (or something even less relevant) because that's what you get without updating the library to account for AsyncContext.  But we recognize that this choice may not always be what the user actually needs, and that's why we provide Snapshot and wrap in the first place - so that developers can get the context they need when the default isn't right.  But as it stands, there's a weird asymmetry where you can wrap a calling-context API to run your callback in the registration context (or some other pre-existing context available at registration time), but there's no way to go the other direction.  If we believe there are APIs that make sense to default to calling context then we're acknowledging that that context is sometimes correct - yet it becomes effectively unavailable if the API defaults to registration context.  I'm in complete agreement that this is the correct default in many cases, but when that doesn't work for a particular usage, there needs to be some sort of escape hatch.

The big example here was events, where there are two relevant contexts: registration time (the only option when the system is the one dispatching it) or calling time (when explicitly dispatching events). These are well-defined.
One idea for handling events sent from JS: making the ambient snapshot be registration time, but passing the call-time snapshot (or undefined when it's missing) as a property of the event.

I disagree with this approach: it's a much more invasive solution that requires updating one or more disparate APIs and doesn't solve the general case, whereas keeping the

@jridgewell

One thing we haven't discussed is what to do with Promises. @mhofman had requested being able to receive both the resolve() call-time context and the p.then(fn) registration time context when invoking fn. With a bit of extra spec work, we could expose that with this same API. I just haven't done the work to propagate the call-time through the Promise reaction jobs yet.

Is this another case where there's more than two possibilities?  What about the following?
const check = () => console.log([v.get(), callingContext(() => v.get())]);
const p1 = v.run(1, () => Promise.resolve());
const p2 = v.run(2, () => p1.then(() => {
  // main context: 2; calling context: 1?
  return v.run(3, () => Promise.resolve());
}));
const p3 = p2.then(() => {
  // main context: null; calling context: 2 or 3?
});

May be worth following up in a separate issue so as not to derail this discussion.

@shicks

Is this another case where there's more than two possibilities?

Basically. There are 3 possibilities:

.then(fn) registration time (absolutely the default)
resolve() call-time (deferred.resolve() or the internal resolve() of a .then(() => promise))
Empty execution stack call-time, which is what AsyncContext.callingContext() will currently use.

What about the following?

I think 2? But I haven't put much thought into it besides "it's possible".

EventEmitters are often used deep inside libraries. There are a lot case where registration/calling happens quite distant from code in your control. There can be several layers/wrappers between the emitter and the handler.

I think this doesn't apply? The cases that I imagine is first party code, where the emitter and the handler are controlled by the same dev. It could even be inside library, where the library is in control of the emitter and handler.
The default should be registration time (and that's directly under the control of the dev when using 3p code). If they're using 3p code, then the calling context may or may not be relevant depending on if that code has snapshotted something unexpected. But this isn't any different than the code today where you only have access to the registration–time context.

A snapshot restore is done via snapshot.run() which is not really different to asyncVar.run().

This API is specifically to help with registration-time or call-time problem. So it's directly tied to snapshot.run(). I don't think asyncVar.run() is relevant here because it's not used to restore the registration-time context at a later point.

This API is specifically to help with registration-time or call-time problem. So it's directly tied to snapshot.run(). I don't think asyncVar.run() is relevant here because it's not used to restore the registration-time context at a later point.

I could see going either way on this: treat them the same for consistency, or don't do anything for asyncVar.run because it's less relevant. It doesn't make a ton of difference in my opinion, as long as there's some workable way to restore the calling context after a snapshot is swapped.

I think this doesn't apply? The cases that I imagine is first party code, where the emitter and the handler are controlled by the same dev. It could even be inside library, where the library is in control of the emitter and handler.

ok. for this very specific scenario it might be fine. But docs should clearly state that this API is only useful is such special cases.
I'm also not sure if registration time is the correct time to capture context for EventEmitters in general.
e.g. OpenTelemetry instrumentation for node.js http module instrument the HTTP request/response objects (which are EventEmitters internally) to bind their context on the emitter more or less on emitter creation time (actually when they first get it).

Making this statically-scoped further suffers from the grafting problem. If we follow the longest path through the internal machinery of everything, which loses relevance in cases like connection pools, we can graft around those internals to produce a more optimal graph for the use case of following user intent. However by applying that graft globally we risk breaking store users which don't want that grafting decision and we lose the possibility to restore that branch of the tree. With callingContext(...) we sort of resolve that problem, but only if we also avoid mutating the graph globally.
I think this is another case where we need to think more at instance scope rather than static scope. As with my prior suggestion of having an instance-scoped bind(...), it would be advisable to have an instance-scoped way to follow the calling context path. In fact, this sort of case is specifically why I made that previous suggestion. Instance-scoped bind(...) and callingContext(...) are actually solving the same problem, just from different sides of the problem.
By always following the internal path and providing tools to reduce the graph where needed we provide a graph which can always be reduced to the more optimal graph for a given case, but we can't do the reverse if a path taken has already orphaned a branch. However the callingContext(...) concept, if done right, which by that I mean instance-scoped, can actually do both directions, allow us to define a suggested path while still enabling following that opposite path where necessary.
The following graph shows an example of a scenario where both interpretations of the graph may be valid depending on the desire of the store owner. This graph corresponds to a call to fs.readFile(name, callback) in Node.js.

The solid line represents the user-facing execution path which may be the path a user desires to take for context management of application data. However there's a bunch of inner calls which actually led to the callback being called and each of those calls could be setting their own context data. A tracing product may want to produce spans for that inner behaviour which flow back to the user code, but that link would be broken if context is forced to flow only via the solid line.
If viewing this problem with static scope we make a choice for all stores to follow--either the solid path or the dotted path. If we approach the problem with instance-scoped tools, we can follow either path per-store and the other user can either instance-scoped bind(...) in or instance-scoped callingContext(...) out to the other path.
I think perhaps I would change it slightly though to just return the snapshot it was in prior to the current snapshot restoring.

If we want to focus on "instance-scoped" snapshots (#25), then we have an m x n problem that I see as really unsolvable programming model wise: If you have m variables, and n contexts where you queue a closure (so you need to AsyncContext.Snapshot.wrap it), then how is it possible for each of these things to know about the other to determine which one it should propagate? It seems unscalable, like for each variable you need to be an APM which monkey-patches all the modules in the world.

Thinking through this a bit... there are two contexts to be concerned about here.

The context that is current when the event is dispatched, e.g. acval.run(2, () => et.dispatchEvent(ev)) (call context)
The context that is current when the handler is registered, e.g. acval.run(3, () => et.on(() => {}) (registration context)

Both are important in different scenarios, and both may be important at the same time depending on use case. So if I am understanding the issue in this PR correctly, the question is how we should propagate all of them?
For this, based on experience with AsyncLocalStorage, I think it's best if, by default, the handler is invoked in the call context, or, in other words:
als.run(1, () => et.addEventListener('foo', () => {
  console.log(als.get());  // 2
});
als.run(2, () => et.dispatchEvent(new Event('foo')));

And if the code that is registering the event listener explicitly opts in to wanting the registration context preserved, they would use snapshot:
als.run(1, () => et.addEventListener('foo', AsyncContext.Snapshot.wrap(() => {
  console.log(als.get());  // 1
}));
als.run(2, () => et.dispatchEvent(new Event('foo')));

This makes using both options possible. If the registration context were the default, then there would otherwise be no actual way of preserving the call context without it being a more convoluted mess.
But what if we want both? That's certainly a tad trickier but not impossible using AsyncContext.Snapshot. Since the call context would be the default, we'd simply need to capture the AsyncContext.Snapshot and close over it in the event handler
als.run(1, () => {
  const snapshot = new AsyncContext.Snapshot();
  et.addEventListener('foo', () => {
    const callContextValue = als.get(); // 2
    snaphot.run(() => {
      const registrationContextValue = als.get(); // 1
    });
  });
});
als.run(2, () => et.dispatchEvent(new Event('foo')));

For an event emitter and EventTarget, I think this approach would make the most sense. Making the registration context the default here, and introducing AsyncContext.callingContext() would be a mistake.

@jasnell What about events which are not dispatched from JS? There are still sometimes multiple answers. One example (where maybe the registration time is the only possibility): https://github.com/tc39/proposal-async-context/issues/22

It likely just needs to be recognized that in some cases, events are going to be triggered from the null-context ... that is, where no context is in scope when the event is actually dispatched. In such cases, either there is no value or the object that is emitting the events (in the case of #22 the XMLHttpRequest) has to capture the AsyncContext.Snapshot when it is created and propagate that.
Looking at the example from #22,
function makeRequestThen(callback) {
  const req = new XMLHttpRequest();
  req.addEventListener('load', AsyncContext.Snapshot.wrap(() => callback(null, req.responseText)));
  req.addEventListener('error', AsyncContext.Snapshot.wrap((err) => callback(err)));
  req.open('GET', url);
  req.send();
}

From a quick skim, I think adding two contexts will significantly increase the overhead of AsyncContext because it would potentially keep them alive longer, increasing memory consumption and GC work. The pattern in https://github.com/tc39/proposal-async-context/pull/77#issuecomment-2043723089 makes sense to me.

@jasnell

For a sync generator, the body of the generator itself should capture the async context that exists when the generator is created and should have no visibility into the async context of whatever code is calling next().
function* foo() {
  yield acval.get();
}

const gen = acval.run(123, () => foo());

acval.run(321, () => {
  console.log(gen.next().value);  // 123
});

Can you elaborate on your reasoning here?  As mentioned in https://github.com/tc39/proposal-async-context/issues/75#issuecomment-2008119267, there are also cases where a generator wants to run each continuation in the next's calling context, and your suggestion would render that case impossible (without terrible workarounds).  It's possible to write a wrapper to restore the init snapshot, but the reverse requires invasive changes to the generator body.

@Flarna

I'm also not sure if registration time is the correct time to capture context for EventEmitters in general.
e.g. OpenTelemetry instrumentation for node.js http module instrument the HTTP request/response objects (which are EventEmitters internally) to bind their context on the emitter more or less on emitter creation time (actually when they first get it).

In my head, OpenTelemetry would instrument the http.createServer() method, and run a new context before invoking it:
const requestContext = new AsyncContext.Variable();

http.createServer = (handler) => {
  const server = new Server(); // or whatever;
  server.handlerRequest = () => {
    const { req, res } = internalStuffToCreateReqRes();
    requestContext.run({ req, res }, handler);
  };
};

It doesn't matter that req/res's event emitter binds at registration-time, because their registration-time is effectively the creation time's context.
Does this match what you're thinking?

@Qard

The solid line represents the user-facing execution path which may be the path a user desires to take for context management of application data. However there's a bunch of inner calls which actually led to the callback being called and each of those calls could be setting their own context data. A tracing product may want to produce spans for that inner behaviour which flow back to the user code, but that link would be broken if context is forced to flow only via the solid line.

I think this case is neatly handled by defaulting to registration-time, and using callingContext()? I'm imagining there's a openSpan() before the fs.readFile() call, and an closeSpan() within the handler:
function handleRequest() {
  const span = openSpan();
  fs.readFile('foo.txt', (err, data) => {
    closeSpan();
  });
}

closeSpan() could itself use callingContext() to retrieve data provided by open()/read()/close() calls.
But from the dev's perspective, I think registration-time is still correct. I don't care how OTel adds data, just that any context data that I put there is available in my callback once the file is read. Yes, they could wrap, but it seems better ergonomics to do it by default.

@jasnell

It likely just needs to be recognized that in some cases, events are going to be triggered from the null-context ... that is, where no context is in scope when the event is actually dispatched.

I think that if we make the null-context something that developers routinely encounter, then we've really failed on the ergonomics. What I imagine is that nearly everything is going to be calling Snapshot.wrap(…), to the point where it becomes a cargo-cult style.
And this will lead to friction. We reintroduced Snapshot.wrap(…) to make it more ergonomic for devs to pass one-off callbacks to libraries (and your code sample uses it!). But if you wrap a callback, how do you get the calling context back to solve @Qard's example? The ergonomic choice breaks it, and to solve the problem we have to go back to new Snapshot() and running that within our callback to get the data the dev put there. Or we'd end up reintroducing callingContext() anyways.

@mcollina

From a quick skim, I think adding two contexts will significantly increase the overhead of AsyncContext because it would potentially keep them alive longer, increasing memory consumption and GC work.

Can you explain where you see them being kept alive longer? callingContext() only restores the context that is already being kept alive by an enclosing snapshot.run(…) call (because the snapshot has to restore that previous context when run() exits).

@jridgewell :

I think that if we make the null-context something that developers routinely encounter, then we've really failed on the ergonomics. What I imagine is that nearly everything is going to be calling Snapshot.wrap(…), to the point where it becomes a cargo-cult style.

I'm not sure how we can reasonably avoid the null-context entirely. But the point is well taken,
Let's see if we can tease things out a bit more. Let's imagine a case where we actually have multiple AsyncContext.Variable instances at play.
const requestId = new AsyncContext.Variable();
const processId = new AsyncContext.Variable();

function log(msg) {
  console.log(`${processId.get()}::${requestId.get()} - ${msg}`);
}

processId.run(123, () => {
  addEventListener('error', (event) => {
    log(`There was an error: ${event.error.message}`);
    return true;
  });
});

requestId.run('abc', () => {
  reportError(new Error('boom'));
});

What should log(...) print in this case? We have two variables, one set in the registration context, another in the calling context. How would log(...) know that it needs to grab callingContext(...) for requestId? In order to make this ergonomic, we'd need either both variables to be entered at registration or both to be entered at call.

... But if you wrap a callback, how do you get the calling context back to solve @Qard's example?

Perhaps we're thinking about it the wrong way. Consider my example where we access both the calling context and registration context:
als.run(1, () => {
  const snapshot = new AsyncContext.Snapshot();
  et.addEventListener('foo', () => {
    const callContextValue = als.get(); // 2
    snaphot.run(() => {
      const registrationContextValue = als.get(); // 1
    });
  });
});
als.run(2, () => et.dispatchEvent(new Event('foo')));

What is clear within the event handler callback is that there is an initial context (in this case the calling context), and we enter a new context, effectively forming a stack. What if we modeled it as such?
als.run(1, () => {
  const snapshot = new AsyncContext.Snapshot();
  // Let's define this such that the snapshot is automatically taken when addEventListener
  // is called. Then, when we emit, we enter the registration context. The calling context will
  // naturally be the parent on the stack...
  et.addEventListener('foo', () => {
    console.log(als.get());  // 1  ... registration context
    context.log(als.parent.get());  // 2 ... calling context
  });
});
als.run(2, () => et.dispatchEvent(new Event('foo')));

It's worth considering that if we always propagate by calling context by default and then bind around registration points (including within the language itself) then the calling context will always be synchronously available at the point when the bind would change the context and we therefore only need to capture the value when the bind occurs and store it only for the synchronous window of the scope function. In any nested async code that would no longer be the calling context, something else will become the calling context.
I don't think it's nearly as expensive to hold as people are thinking.

IIUC,
async function* gen() {
  console.log(AsyncContext.callingContext(() => v.get()));
  yield;
  console.log(AsyncContext.callingContext(() => v.get()));
  await 0;
  console.log(AsyncContext.callingContext(() => v.get()));
}
const it = v.run(1, () => gen());
await v.run(2, () => it.next()); // logs 2
await v.run(3, () => it.next()); // logs 3, null

The fact that callingContext is more or less meaningless after an await in an async generator is maybe somewhat concerning?

It doesn't matter that req/res's event emitter binds at registration-time, because their registration-time is effectively the creation time's context.
Does this match what you're thinking?

The life cylce of a HTTP operation and all the inner operations (like DB requests triggered) is a bit more complex.
Anyhow, I think the easier to read samples above from @jasnell describe the problem also very well.
My main point is that EventEmitters are used in that a lot different ways that it's mostly not possible to select a single correct solution. e.g.

in HTTP use case above instances are created for exactly the lifetime of an "operation"
other cases use instances within an queue/shared connection/... where the instance is used for quite different "operations"

As a result I question why they should capture context on default just to force users to restore the original context to workaround the default.
Node for example offers a non capturing EventEmitter and a creation time capturing EventEmitterAsyncResource to allow users to choose.

Can you explain where you see them being kept alive longer? callingContext() only restores the context that is already being kept alive by an enclosing snapshot.run(…) call (because the snapshot has to restore that previous context when run() exits).

@jridgewell consider the example of https://github.com/tc39/proposal-async-context/pull/77#issuecomment-2048897179. callingContext() is essentially useless after an await, so the only thing users would do (or would ask us to do), is to keep it around for longer / essentially as the "parent" that caused the transition from one context to another.
Developers unfortunately like to "fork" the promise/context chain further, so I expect the calling context to always leak over its original lifetime

The context would already flow to that point anyway though, unless you're proposing cutting off a branch at the start of a bind point, which would mean internals would all be context-less and unable to connect to anything useful. Referencing my graph in https://github.com/tc39/proposal-async-context/pull/77#issuecomment-2043637043 that would mean breaking the link between fs.readFile and fs.open which would result in all that internal behaviour being untraceable as it would have no parent context to link. We could introduce an equivalent to the callingContext API for that other end of the bind graph reduction, but that would be storing pre-async-barrier to access post-async-barrier and so would be even more costly to retain the data to be able to escape from that scenario.
From both performance and flexibility perspective the best possible choice is to always follow call context path and then allow snapshot restores to bind around internal paths where desired but with an escape hatch for individual stores to restore the calling context path for their case. This also means the calling context only needs to be stored for the cases where a bind graph reduction is applied as every other case the calling context and the stored context would be the same.
Internals can do snapshot restores by default around cases where it makes sense, but any internal paths, where observable, would continue to follow the calling context and so would not have an unexpected null context. It would only have an immediate switch at the point of the snapshot restore.

@jasnell

What should log(...) print in this case? We have two variables, one set in the registration context, another in the calling context. How would log(...) know that it needs to grab callingContext(...) for requestId? In order to make this ergonomic, we'd need either both variables to be entered at registration or both to be entered at call.

If we're imagining that log should not need to change (I agree), it seems like this falls on the error handler to stitch these together? But this scenario seems specific because we're not running the request handlers within the scope of the processId.run().
(This might be a case where error is a special global event listener like unhandledrejection, but that would mean you need you'd need to get the process id some other way…)

... But if you wrap a callback, how do you get the calling context back to solve @Qard's example?
Perhaps we're thinking about it the wrong way. Consider my example where we access both the calling context and registration context:

Both of these code samples work fine, because the first is using new Snapshot() and not Snapshot.wrap (and so can control when it enters the registration context), and the second is using essentially callingContext().
But my scenario from https://github.com/tc39/proposal-async-context/pull/77#issuecomment-2048434599 was that devs will reach for Snapshot.wrap(…) because it is easy and ergonomic. And if this becomes cargo-cult style to wrap all your callbacks (that way the data the devs set is always propagated), then we still need callingContext() in some form so that we can retrieve call data.

@shicks

The fact that callingContext is more or less meaningless after an await in an async generator is maybe somewhat concerning?

Oh, I missed that. That  is concerning, I would expect the final log to be 3.

@Flarna

My main point is that EventEmitters are used in that a lot different ways that it's mostly not possible to select a single correct solution. e.g.

Is it known when the event emitter is constructed whether it will always be registration or call time?

As a result I question why they should capture context on default just to force users to restore the original context to workaround the default.

Because the registration-time one has the dev's data from when the called on or addEventListener, and the other's data is unknown. We'll need to switch contexts in one direction or the other, so I think the default should be the one with the dev's data.

@Qard

The context would already flow to that point anyway though, unless you're proposing cutting off a branch at the start of a bind point, which would mean internals would all be context-less and unable to connect to anything useful.

My example was a bad because I didn't nest the callbacks. openSpan(() => { /* read here */ }).

It seems everyone is arguing for call-context by default. We'll need to discuss this in the next meeting.
The issue is that we have https://github.com/tc39/proposal-async-context/issues/22 arguing that switching from a fetch promise to using xhr.send() event listeners shouldn't cause a refactoring hazard, and that only works if we use registration by default. We'll need decide if we can get past this concern from committee delegates.

I'm just now realizing that #22 is handled if send()'s call-time context is used when invoking the event handlers. Maybe call-time isn't an issue at all.

I think the conversation around call-time vs registration time is a bit fuzzy and could use some clarification.
Call-based context is technically what you have by default if you don't do anything to manage propagation. Data "flows" in that way because the application execution itself flows in that way and the data doesn't change. Registration time is simply the act of capturing context at some point and swapping out the state that already flowed along with the calling path to begin with and replacing that with the value capture earlier. Capturing context and restoring it around registration time flows makes perfect sense in certain cases.
What I'm saying is that if access to calling context is done right the argument of which one is "correct" no longer matters because you can always just follow calling context out of a bound context or manually bind a context as-needed. Accessing calling context is essentially a way to undo the context you just restored and return to the one you would have been in if not for the bind, which means both paths are accessible and the "correct" path becomes a purely user experience default, not a critical decider of what is possible to do with the graph.

Having instance-scoped bind doesn't mean we remove static bind. We should have both. The instance-scoped version is just useful for the handful of scenarios where the correct path is use-case dependent.

Having instance-scoped bind doesn't mean we remove static bind. We should have both and generally path decisions will be made statically. The instance-scoped version would exist as an escape hatch for the handful of scenarios where the correct path is use-case dependent and a particular store user disagrees. They can, with some additional effort, follow a different path where preferred.
An instance-scoped bind lets them route around internal paths they don't want to follow, like the implementation details of a connection pool. An instance-scoped calling context provides the ability to go the other direction where a bind has been applied statically and a particular store disagrees with that default selection they can return to the internal path which was orphaned when the snapshot was restored.
As for feasibility and runtime cost, it absolutely can be done as it has been done before with AsyncLocalStorage. I have put significant effort into ensuring it is capable of these things as the primary use case it targets is observability providers which need this capability. To reach calling context all you need to do is have a snapshot of the state before a bound snapshot is restored so you can return to that snapshot, effectively undoing the bind for a limited scope.

@Qard

An instance-scoped calling context provides the ability to go the other direction where a bind has been applied statically and a particular store disagrees with that default selection they can return to the internal path which was orphaned when the snapshot was restored.

Can you provide some example code showing what this (would/could/does) look like?  In my imagination you're stuck digging around a complex graph, which seems infeasible, so I think I'm missing your point.  To put it concretely, suppose I have the following scheduler outside of my control:
class Scheduler {
  callbacks = [];
  register(callback) {
    this.callbacks.push(AsyncContext.Snapshot.wrap(callback));
  }
  call() {
    this.callbacks.forEach(fn => fn());
  }
}

Now I want to call register in such a way as to get the calling context inside the registered function:
scheduler.register(() => console.log(v.get()));

How do I change that register call such that it logs the variable from the context that called call() rather than the registration context?  @jasnell suggested a v.parent.get() - is that (analogous to) what you're talking about, or do you have something else in mind?  What would it look like if there's additional indirection (with more vars being set in between).  IIUC you're suggesting we can traverse multiple graph edges - what specifically would that look like?

No, not multiple graph edges. We just need one level up to restore the orphaned branch because, if it's following call context by default it will have already propagated through that branch on its own anyway. In the graph I posted earlier the fs.readFile would propagated through the dotted line branch all the way up until the callback to fs.readFile is reached as a snapshot restore will swap out the context that flowed through the dotted path for the one which it captured at the start of the fs.readFile call. Capturing a snapshot will not cause the fs.readFile to stop propagating by call path through that branch up until that point, it will only stop propagating at the exact moment it goes to restore the snapshot. So at that exact moment you can just get whatever the current context is and that will be the calling context.
If there are multiple levels of binds then it would just be up to the user to handle each to follow the path it wants to follow. There's no reasonable way to describe the full path a context propagation should take, it needs to be handled on a case-by-case basis. This is why we define a best-effort default path which propagates automatically and then provide tools to bind or restore away from that path.
In that scheduler case you use AsyncContext.Snapshot.wrap(...) which is essentially something like:
function wrap(fn) {
  const snapshot = new AsyncContext.Snapshot()
  return (...args) => snapshot.run(fn, ...args)
}

This does nothing to change the propagation behaviour of the async tasks scheduled within the call receiving this wrapped function. All it does is replace what has already been propagated when that snapshot.run(...) is called. Inside that snapshot.run(...) you can just capture the current context before running the snapshot, which we already do to restore the context after it finishes running, and use that prior context value to get the state of the store in the calling context path from that prior snapshot.
I think people are expecting this to be a lot more complicated and expensive than it actually needs to be.

I'd prefer that we adopt the direction described in https://github.com/tc39/proposal-async-context/pull/100 where we instead provide explicit APIs to access certain snapshots, rather than try to define a general one as in this PR.

That doesn't help APMs though as we would then still need to patch everything to get at those context objects and flow them ourselves when they're passed around on event objects. We need an interface decoupled from the execution itself to be able to know what contexts are current. For example, say we instrument something that somewhere internally deals with events, and we instrument something that would trigger in an event handler, but we don't have any specific awareness of the event emitter itself we would have no way to establish the link between those two points unless the event object was passed directly through to that inner API, which is generally not the case. This sort of scenario is the whole point of context in the first place--to be able to pass data through the execution graph without needing explicit access to anything in particular between the two points.


Fixed the build error

Summary
This fixes the build error introduced by https://github.com/zaporylie/composer-drupal-optimizations/issues/18#issuecomment-704187300
This also removes the scaffold's outdated composer.lock file before installing so everything is up to date with the latest.
Coding standards have been fixed to appease phpcs.
Metadata

Question
Answer

Did you use a meaningful pull request title?
yes

Did you apply meaningful labels to the pull request?
yes

Did you perform a self review first?
yes

Documentation reflects changes?
no

CHANGELOG reflects changes?
no

Unit/Functional tests reflect changes?
no

Did you perform browser testing?
yes

Risk level
Low

Relevant links
n/a

Ok it looks good
/approved


PATCH: Update PII question description

This PR:

Addresses and updates the PII question as mentioned in #46

Waiting to resolve unicef/publicgoods-candidates#669

@lacabra unicef/publicgoods-candidates#669 has been resolved now. The PR has been closed. Pending review of this one.

I have the same comment I made there: no single entry in the schema should have two "if yes - then question". Each such statement should be its own entry.

The underlying issue has been resolved in #60. This PR is no longer valid.


MoQ URI Handling

Setting up and saving of client setup parameters. Added a new field in Peer to save role and path parameters from client when Server listens from a new peer.

Please could you check if the code changes make sense.
Two things missing from this implementation is:

A parsing function available to the application to retrieve the value of the parameters from the string representation (which is being saved in Peer)
Closing the connection when Path parameters are being sent by the Client if WebTransport is being used. I haven't yet figured out how to do this in the best way possible. If you have an idea please let me know. One naive approach is if we could add arguments to Listen() to figure out a Quic/WT connection.

For now the behaviour when a path parameter is not required but still received over the QUIC connection is undefined in the draft I guess. With the latest commit this just errors out with errUnexpectedPathParameter. For WT, that is the expected behaviour, however for QUIC still unsure what to do


Determine changes needed for DiT

https://wiki.earthdata.nasa.gov/pages/viewpage.action?spaceKey=ENS&title=PI+24.1+Tenant+Action+Items

hydrocron uses API Gateway backed by lambda which is already HTTPS from cloudfront.
Question still exists about whether the connection from lambda to dynamodb (via boto3) is https or not. Dynamodb does have https endpoints available in all regions but it is unclear if this is the default when starting a dynamodb session or not.
http://docs.aws.amazon.com/general/latest/gr/rande.html#ddb_region
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/network-isolation.html

Adding VPC endpoint will guarantee HTTPS traffic from lambda -> DynamoDB
https://github.com/podaac/hydrocron/issues/78

Closing as duplicate of #78


Send test results for minors

Description
Start texting/emailing test results for all patients, not just adults. Currently we do not allow test results to be texted for anyone under the age of 18.
Proposed solution
Figma: https://www.figma.com/file/NPSPM5SBzQ7Ra3mmr9M9cB/SimpleReport-Public-Site?node-id=3519%3A13931

[x] Allow test results to be texted/emailed for anyone under the age of 18 (this is currently restricted)

[x] Add a warning that the user is required to follow all applicable laws and regulations for these test results which are for a minor. The warning should be added below the header "Contact Information"
- In Add new patient/Registration
- In Time of Test questions

[x] Update the copy for:
- "Would you like to receive your results via text message?*
- "Yes, text all mobile numbers on file."

[ ] Update Spanish translations for strings

Warning message:
“It’s your responsibility to enter the correct contact information for the person receiving test results, following all applicable federal and state laws.”
Screenshot

Additional context
We originally pushed out texting test results as an MVP and wanted to see if the feature had traction before solving the problem of minor's health data. Now we have seen a LOT of traction and have received a LOT of feedback from schools and others that they need to be able to text test results for minors.

Feedback from Maya:
I'm wondering if you even need to call out the minors issue or if we could just have a general notice to the user along the lines of: "It is your responsibility to enter accurate  contact information for the individual receiving access to this information, in accordance with all applicable federal and state law." You could also maybe add a link back to our TOS. (e.g. "Please visit our Terms of Service for more information.")
Bc i think a double check on accuracy of info is probably good for any patient access
including but not limited to minors.

@kenieh @Rebecca-LM - need to figure out how this warning should look in the self-registration/add new patient workflow.

@aliciabeckett-gov @Rebecca-LM
This is pretty close to finished but we need Spanish translations for the following sentences:

You're responsible for entering the correct contact information, following applicable federal and state laws
Yes, text all mobile numbers on file.

@nickscialli-usds

Usted es responsable de ingresar la información de contacto correcta, siguiendo las leyes federales y estatales aplicables.

Sí, envíe un mensaje de texto a todos los números registrados de teléfonos móviles.


Expand meta= error message

Fixes #3342

[ ] Tests added / passed
[ ] Passes flake8 dask
[ ] Fully documented, including docs/source/changelog.rst for all changes
and one of the docs/source/*-api.rst files for new API

This error isn't only thrown for custom functions, this also shows up when the user does an operation that's invalid:
In [1]: import dask.dataframe as dd

In [2]: import pandas as pd

In [3]: df = pd.DataFrame({'a': ['x', 'y', 'y'], 'b': ['x', 'y', 'z'], 'c': [1, 2, 3]})

In [4]: ddf = dd.from_pandas(df, npartitions=1)

In [5]: ddf.a + ddf.c
---------------------------------------------------------------------------
...
ValueError: Metadata inference failed in `add`.

Original error is below:
------------------------
TypeError("ufunc 'add' did not contain a loop with signature matching types dtype('<U21') dtype('<U21') dtype('<U21')",)

Traceback:
---------
  File "/Users/jcrist/anaconda/envs/dask/lib/python3.5/site-packages/dask-0.17.1-py3.5.egg/dask/dataframe/utils.py", line 137, in raise_on_meta_error
    yield
  File "/Users/jcrist/anaconda/envs/dask/lib/python3.5/site-packages/dask-0.17.1-py3.5.egg/dask/dataframe/core.py", line 3062, in elemwise
    meta = partial_by_order(*parts, function=op, other=other)
  File "/Users/jcrist/anaconda/envs/dask/lib/python3.5/site-packages/dask-0.17.1-py3.5.egg/dask/utils.py", line 879, in partial_by_order
    return function(*args2, **kwargs)
  File "/Users/jcrist/anaconda/envs/dask/lib/python3.5/site-packages/pandas/core/ops.py", line 739, in wrapper
    result = wrap_results(safe_na_op(lvalues, rvalues))
  File "/Users/jcrist/anaconda/envs/dask/lib/python3.5/site-packages/pandas/core/ops.py", line 710, in safe_na_op
    lambda x: op(x, rvalues))
  File "pandas/_libs/algos_common_helper.pxi", line 1212, in pandas._libs.algos.arrmap_object
  File "/Users/jcrist/anaconda/envs/dask/lib/python3.5/site-packages/pandas/core/ops.py", line 710, in <lambda>
    lambda x: op(x, rvalues))

I recommend adding a flag to raise_on_meta_error to optionally add this suggestion, and then set it appropriately in the proper places.


Elaborate on ResponseEntity and working with request and response objects in slides

Discussion on Twitter about this discussion
https://twitter.com/therealdanvega/status/1599814600463355906?t=fSoo9zEo9kwNno_UsOrgSw&s=19


Current test of createMuiTheme to deep merges multiple arguments is ineffective

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
I believe the current test to deep merge arguments is ineffective. I am finding that I'm getting errors in this behavior, but before creating an issue with those, I've decided to first fix the test. (There seems to be a lot of code changes around this area anyway, so this might be a more productive way to go. I note that the api went from being undocumented to documented in the last couple of days.)
Expected Behavior 🤔
I'd expect one of the two following mutually exclusive options:

It is agreed that the behavior is unwanted, the test is removed, and the functionality is removed from the docs.
It is agreed that the behavior is wanted, and the tests are updated. Any failing tests should be fixed shortly after.

My vote is for option 2, and a pull request will follow shortly after this.

Here's the pull request: #18543


Problem With Text

Hi niklasvh. I have drawn d3 charts in my project. When I take screenshot using html2canvas some texts/legends in the charts come blurry.
I used beta4, beta3, beta2, beta1, alpha1 versions of html2canvas. The same issue is coming with all the versions.
The issue is coming with many charts. I am sharing the link of one of the charts I am drawing.

Link : https://jsfiddle.net/gipsydangerv2/4geokqLj/14/

Is this still an issue with v1.0.0? If so, could you please share an example on jsfiddle.

I have the same problem,when my font-size is under 8px~


Docstrings for four functions

Function that creates identifier using text extraction from url @mikeguron
Extracts raw text from url optional (filtered by class provided by user) @DMerigo
Converts raw text dataframe to bag of words @mehdi-naji
Allows you to record the counts of a specific list of words @elenagan

I have created a python script for the first function and added the docstring to the file.  Can one of you please review and merge the pull request when you have a chance?


Remove GUC for setting migration mode for TestSpatialPoint testfiles

Description
As part of https://github.com/babelfish-for-postgresql/babelfish_extensions/pull/3096, we ignored these files to revisit the migration mode testing.
With this commit we have:

Removed GUC for setting migration mode to multi-db for TestSpatialPoint testfiles.

cherry-picked: https://github.com/babelfish-for-postgresql/babelfish_extensions/pull/3197
Authored-by: Anikait Agrawal<EMAIL_ADDRESS>Signed-off-by: Anikait Agrawal<EMAIL_ADDRESS>Check List

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 74.722%

Totals

Change from base Build<PHONE_NUMBER>2:
0.01%

Covered Lines:
45759

Relevant Lines:
61239

💛  - Coveralls


fix(node): abort no bin defined

ref #715
Change to create version directory after downloading files.

We can make the default not just check if there is a folder but also if there are files in it for a quick fix.

Thanks!
I think in terms of determining whether a file is already installed by its existence.

sure, that is also possible, but then we need to check the version of the tool and because they all have different ways to get the version we would need to override it for every tool.
With that check we are checking the tool and the version, so the new solutions needs to have both as well.

@korosuke613 please don't open PR from org next time, so we can update your branch with latest changes from main

@viceice
Sorry for the late reply.
I was not aware of the specification that prevents the maintainer from updating branches in the case of org. I will be careful in the future.
I did update the branch once with my privileges, but I think the same problem may occur again, depending on the timing. In that case, I will either fork and recreate the pull request myself, or close my pull request and wait for a better way.

@viceice I can start to convert some tools as prototype to check if if the tool is installed in the correct version for the check_tool_installed function

sounds good


WinUI 3 Preview 1 – Featuring Desktop App Support 💻🎉

WinUI 3 Preview 1 – Featuring Desktop App Support
As mentioned in the recent community call, and this morning at //BUILD, today we are releasing WinUI 3 Preview 1.
We are excited to bring you this release, which includes the following high-level feature additions:

Ability to create Desktop (Win32) Apps with WinUI

Including using .NET 5 (for Win32)

Feature additions from WinUI 2.4

RadialGradientBrush
TabView updates
Dark Theme updates

Improvements and updates to the WebView2

Support for High DPI
Support for window resizing and moving
Updated to target more recent version of Edge
No longer necessary to reference a WebView2-specific Nuget package

SwapChainPanel
Improvements needed for open source migration

Please note that WinUI 3 Preview 1 remains a an early pre-release style product. As such it has known issues and missing functionality. It is not ready for production apps. In particular there are some considerations to make when making Desktop (Win32) apps.
Please take some time to review the instructions for getting started with Desktop apps.

We welcome feedback on all areas of the release by filing issues here on GitHub. Please let us know about any issue, no matter how large or small.
What's next?
We're hard at work getting WinUI ready for open source development, which will be released later this year. We will be continuing our preview releases with increased quality and stability moving forward.
Installation info
For download please go to the download page and release notes

Congrats!! Btw it would be nice to have the Win2D support, I need it for my project unfortunately.

Is there any plans to support it on VS Code? And I mean, without needing to install full VS.
UWP SDK + .NET + VS Code only?

I'm trying to use ANGLE.WindowsStore and SwapChainPanel in WinUI 3, this is the function I'm using:
public EGLSurface CreateSurface(SwapChainPanel panel)
{
if (panel == null)
{
throw new ArgumentNullException("SwapChainPanel parameter is invalid");
}
        EGLSurface surface = EGL_NO_SURFACE;

        int[] surfaceAttributes =
        {
				// EGL_ANGLE_SURFACE_RENDER_TO_BACK_BUFFER is part of the same optimization as EGL_ANGLE_DISPLAY_ALLOW_RENDER_TO_BACK_BUFFER (see above).
				// If you have compilation issues with it then please update your Visual Studio templates.
				EGL_ANGLE_SURFACE_RENDER_TO_BACK_BUFFER, EGL_TRUE,
                EGL_NONE
            };

        // Create a PropertySet and initialize with the EGLNativeWindowType.
        PropertySet surfaceCreationProperties = new PropertySet();
        surfaceCreationProperties.Add("EGLNativeWindowTypeProperty", panel);

        surface = eglCreateWindowSurface(mEglDisplay, mEglConfig, surfaceCreationProperties, surfaceAttributes);
        if (surface == EGL_NO_SURFACE)
        {
            throw new Exception("Failed to create EGL surface"); <--- ERRORS HERE
        }

        return surface;
    }

Using a Universal Windows app the function works fine, but moving to WinUI 3 it fails to create a EGL surface.

Hey @adambarlow, is it possible to add WinUI 3 to an existing Win32 C++ desktop app? I have installed the preview and the WinUI extension as explained here https://docs.microsoft.com/en-us/windows/apps/winui/winui3/get-started-winui3-for-desktop#create-a-winui-3-desktop-app-for-cwin32 but I am not sure how to add the WinUI 3 nuget package to my existing project...for some reason searching for Microsoft.WinUI does not display anything on Nuget.
Am I missing something?

I've tried the Win32 support (basically wanted to created an WPF app which is using WinUI features & controls) and I have a question: Are there any plans to make it work natively? I mean without all these side-load / app package / UWP-thing, that makes me feel this is more like a wrapper, something like XAML Island is, which takes some UWP-thing and host it inside WPF. Is this is only because its the first alpha or is this the way to go?
Also on following step 7 to create a new blank WinUI page, the first one, everything crashed. So I cannot give any other feedback.


Getting this Error(1) "after each" hook in "{root}") and not progressing further

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior
Expected behavior
A clear and concise description of what you expected to happen.
Logs
If applicable, add logs to help explain your problem.
** Operating system, Node.js an npm versions, or browser version (please complete the following information):**

OS: CentOS 7
Node.js: v14.16.0
npm: 6.14.11
Browser: Firefox-91
Cypress: 6.4,0

Additional context
Add any other context about the problem here.
I given the sample code here.
plugin/index.js:
module.exports = (on, config) => {
const failfastObj = require('cypress-fail-fast/plugin')(on, config);
console.log('failFast:',failfastObj);
}
support/index.js:
import "cypress-fail-fast";
cypress.json:
env:{
"FAIL_FAST_STRATEGY": "spec",
"FAIL_FAST_ENABLED": true,
"FAIL_FAST_BAIL": 1,
}
integration/spec1.js:
I have these below of how my spec file looks like.
describe('test", ()=>{
before("", ()=>{
Getting value from fixtures and assign into global variable
});
beforeEach("", ()=>{
setting cookies
})
it("test1", ()=>{
cy.log('Test1");
});
it("test2", ()=>{
cy.log('Test2");
});
.
.
.
});

Hi @senthiltr, it seems that you have an error in your code: You are calling to before and beforeEach hooks passing two parameters instead of one. You can check hooks usage examples in the Cypress docs.

Thanks for the reply. With that it worked sometime. Sometimes not. I have removed "" from before and beforeEach.
Also now after first failure getting below statements but not starting second testsuite(spec).
[fail-fast] Failed tests: 1/1
[fail-fast] Enabling skip mode
Kindly suggest.
THanks
Senthilkumar TR

here is my run command.
./node_modules/.bin/cypress run --browser /usr/bin/firefox --env DEFAULT_ENVIRONMENT_NAME=auto_cluster_18313 --spec "spec1.js,spec2.js" --headless true

Hi again. Are you sure that the issue is related to the usage of this plugin? You could check it uninstalling it completely and then trying again.

Closed due to inactivity


Unable to install package in laravel 9

Problem 1
- Root composer.json requires nao-pon/flysystem-google-drive ~1.1 -> satisfiable by nao-pon/flysystem-google-drive[1.1.0, ..., 1.1.x-dev].
- nao-pon/flysystem-google-drive[1.1.0, ..., 1.1.x-dev] require league/flysystem ~1.0 -> found league/flysystem[1.0.0-alpha1, ..., 1.x-dev] but the package is fixed to 3.10.2 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

same issue

Problem 1 - Root composer.json requires nao-pon/flysystem-google-drive ~1.1 -> satisfiable by nao-pon/flysystem-google-drive[1.1.0, ..., 1.1.x-dev]. - nao-pon/flysystem-google-drive[1.1.0, ..., 1.1.x-dev] require league/flysystem ~1.0 -> found league/flysystem[1.0.0-alpha1, ..., 1.x-dev] but the package is fixed to 3.10.2 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

same issue any ida?

Here is a demo on laravel 9.x
https://github.com/ivanvermeyen/laravel-google-drive-demo/issues/108

Without support since Jul 29, 2020


Enable reconnection for restarted remote host

Motivation
I am running the vscode server and I am connecting to it via the web ui (in my case using code-server).
Unfortunately, the new connection cannot be continued if the server is terminated or stopped without the browser window being reloaded.
The logs show the following:
log.ts:421  INFO [remote-connection][ExtensionHost][7745d…][reconnect] starting reconnecting loop. You can get more information with the trace log level.
log.ts:421  INFO [remote-connection][ExtensionHost][7745d…][reconnect] resolving connection...
log.ts:421  INFO [remote-connection][ExtensionHost][7745d…][reconnect] connecting to localhost:8081...
log.ts:421  INFO Creating a socket (renderer-ExtensionHost-7745d818-f9fc-423d-8fb7-f37f4ed43589)...
log.ts:441   ERR [remote-connection][Management   ][171f9…][reconnect][localhost:8081] received error control message when negotiating connection. Error:
log.ts:441   ERR Error: Connection error: Unknown reconnection token (never seen)
    at G (remoteAgentConnection.ts:812:17)
    at remoteAgentConnection.ts:338:17
    at g.invoke (event.ts:723:17)
    at r.deliver (event.ts:936:22)
    at l.fire (event.ts:892:24)
    at c.fire (ipc.net.ts:671:19)
    at k.E (ipc.net.ts:1115:28)
    at ipc.net.ts:1042:72
    at g.invoke (event.ts:723:17)
    at r.deliver (event.ts:936:22)

I noticed that it occurs because on startup the remoteExtensionHostAgentServer creates a new empty list of _allReconnectionTokens and the remoteAgentConnection generates a new uuid reconnectionToken.
Since the _allReconnectionTokens are empty for the new server, it can not recognise the reconnectionToken and will reject it.
Being able to	reconnect to a backend without having to reload the browser window would enable rolling updates/zero downtime deployments and therefore would be a huge win for the user experience (especially when running against a remote host).
Ideas

Instead of storing the _allReconnectionTokens in memory we could store it in a shared storage. For example the local filesystem.

For sure it would have to be behind a flag.

Instead of generating a uuid reconnectionToken we could add an option to set it to a constant value. For example using some environment variable value if provided.

We would have to add the value also to the _allReconnectionTokens set.

Maybe I am missing something else and there are other parts of the code that need to be changed.
NOTE: I would be open to contribute the code after some alignment.

Unfortunately, the new connection cannot be continued if the server is terminated or stopped without the browser window being reloaded.

This is by design. A window and an extension host live together, and you can't connect the same window to a new remote extension host process.


limit the number of "Not Made" options

is it posible to artificialy decrease the number of molecules that show as not made on their pIC50 as while their good to keep for realisim, they do make gameplay very boring if they just keep coming up.
maby replace the R group most likely to cause a "Not Made" with a new option if the number of possible not made combiniations is greater then a set threshold (eg 15% of all outcomes from the presented options being "Not Made")

"Assay Failed" seems much less prevalent in the output of the selection function and is more relevant to the real world so don't include it in any system to catch not made


MinecraftTransitRailway got shut down

I can't use Joban Client Mod or London Underground with the mod updater. If you are able to fix the site please do. Thanks!
https://www.minecrafttransitrailway.com/libs/lets-play-mods.json

It's working for me and other players as well. Please check your network connection.


fix: prettier opt in

Makes prettier opt in for existing users + switches prettier to warning.

Test failing


[Core] Refactor llms code using OOP, and model registry

refactor llms code using OOP, and model registry, you need to inherit baseLLM and registry model when you want to add a new model

@dongyuanjushi  please review


[DO NOT MERGE]: Testing GPU presubmits.

Thanks, @av8ramit -- @seanpmorgan , @facaiy : we now have GPU tests running as well.

Awesome, thank you, Amit, Karmel! So I think we need to add cuda_py_test later, right?

Yes, related is this issue which implements GPU op in our template:
https://github.com/tensorflow/custom-op/pull/10/files


Problem with the nodes of ElasticSeach

Hi Arey,
My name is Alvaro and I am a 23 years old student from Madrid who has just finished a Telecommunications Engineering degree.
I am writing to you because now during the summer I am working in a project trying to develop MusicBrainz and Discogs databases in Elastic Search to learn about ES, where I am a beginner.
To index MusicBrainz I am following your tutorial, however now I had a problem that I did not know how to solve in several days. I hope that you can help me, I will be so grateful.
I followed the tutorial working with Docker and Compose, and the first part of this (the docker part) I think that worked fine.
The problem appears  in the Quick Start part. After do "mvn install", the next command: mvn exec:java return the next error:
ERROR org.springframework.batch.core.step.AbstractStep [229] - Encountered an error executing step deleteIndexIfExists in job musicAlbumJob org.elasticsearch.client.transport.NoNodeAvailableException: None of the configured nodes are available: []
at org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable(TransportClientNodesService.java:305) ~[elasticsearch-1.7.1.jar:na]
at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:200) ~[elasticsearch-1.7.1.jar:na]
at org.elasticsearch.client.transport.support.InternalTransportIndicesAdminClient.execute(InternalTransportIndicesAdminClient.java:86) ~[elasticsearch-1.7.1.jar:na]
2019-07-18 17:18:43,551 [com.javaetmoi.elasticsearch.musicbrainz.batch.IndexBatchMain.main()] INFO  org.springframework.batch.core.launch.support.SimpleJobLauncher [136] - Job: [FlowJob: [name=musicAlbumJob]] completed with the following parameters: [{}] and the following status: [FAILED]
2019-07-18 17:18:43,551 [com.javaetmoi.elasticsearch.musicbrainz.batch.IndexBatchMain.main()] INFO  org.springframework.context.support.ClassPathXmlApplicationContext [984] - Closing org.springframework.context.support.ClassPathXmlApplicationContext@66d6172a: startup date [Thu Jul 18 17:18:11 CEST 2019]; root of context hierarchy
2019-07-18 17:18:43,564 [com.javaetmoi.elasticsearch.musicbrainz.batch.IndexBatchMain.main()] INFO  org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor [202] - Shutting down ExecutorService
2019-07-18 17:18:43,564 [com.javaetmoi.elasticsearch.musicbrainz.batch.IndexBatchMain.main()] INFO  org.springframework.data.elasticsearch.client.TransportClientFactoryBean [59] - Closing elasticSearch  client
I think that it should be a problem with Elasticsearch but I dont know what. I have another version of it more recent (maybe it cause trouble but I dont think so).
Do you know how can I fix that?
Thanks a lot for your time and for this project which is very cool.
I wait for your answer soon.
Alvaro.

Hi @alvaro-lopezgarcia. Elasticsearch regularly changes its API. The version used by this project is an older one:  1.7.1
Regarding to this blog post https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport-client.html, the TransportClient has been removed starting from ES 8. It could explains. Which version of ES are you using?

Hello @arey, thanks for answering I am very grateful.
The version of elastic that I used to work was 6.2, but this project didn't work in that version for me so I installed version 1.7.1 which is very old but works for this project.
I have resolved the problem that I explained you, I have got to change in the file es-musicbrainz-batch.properties the elasticsearch and postgres addresses to localhost (<IP_ADDRESS>) and it resolved the trouble.
However, now a new error appears to me in the step IndexMusicAlbum because reading the dates appears an unskippable exception beacause of the gender of the artist. I haven't got any idea of how to resolve it. It doesn't seems to be a configuration problem but I don't really know. I copy here the logs for if you could explain me more about it and maybe how to fix it...
Executing step: [indexMusicAlbum]
2019-07-22 16:56:23,824 [batchTaskExecutor-1] ERROR org.springframework.batch.core.step.AbstractStep [229] - Encountered an error executing step indexMusicAlbumPartition in job musicAlbumJob org.springframework.batch.core.step.skip.NonSkippableReadException: Non-skippable exception during read
at org.springframework.batch.core.step.item.FaultTolerantChunkProvider.read(FaultTolerantChunkProvider.java:105) ~[spring-batch-core-3.0.10.RELEASE.jar:3.0.10.RELEASE]
at org.springframework.batch.core.step.item.SimpleChunkProvider$1.doInIteration(SimpleChunkProvider.java:116) ~[spring-batch-core-3.0.10.RELEASE.jar:3.0.10.RELEASE]
at org.springframework.batch.repeat.support.RepeatTemplate.getNextResult(RepeatTemplate.java:374) ~[spring-batch-infrastructure-3.0.10.RELEASE.jar:3.0.10.RELEASE]
Caused by: java.lang.IllegalArgumentException: Unrecognized artist gender: 4
at fm.last.musicbrainz.data.model.Gender.valueOf(Gender.java:52) ~[musicbrainz-data-3.1.0.jar:na]
at com.javaetmoi.elasticsearch.musicbrainz.batch.mapper.AlbumRowMapper.mapRow(AlbumRowMapper.java:51) ~[classes/:na]
at com.javaetmoi.elasticsearch.musicbrainz.batch.mapper.AlbumRowMapper.mapRow(AlbumRowMapper.java:29) ~[classes/:na]
2019-07-22 16:56:23,825 [batchTaskExecutor-1] INFO  com.javaetmoi.core.batch.listener.LogStepListener [75] - Step indexMusicAlbumPartition:partition0 - Read count: 201 - Write count: 0 - Commit count: 0
Thanks a lot again for your time!

The exception cause show that the MusicBrainz database has introduced a new gender : java.lang.IllegalArgumentException: Unrecognized artist gender: 4
The last version of the musicbrainz-data artefactId does not reference it:
https://github.com/lastfm/musicbrainz-data/blob/master/src/main/java/fm/last/musicbrainz/data/model/Gender.java
We have to found the corresponding label of the ID number 4, then submit a PR to musicbrainz-data. By waiting, you could copy/paste the class and use this temporary copy


[Feature-12456][task plugin] Add new task plugin for apache linkis

Purpose of the pull request
close #12456
Brief change log
Add new task plugin for apache linkis

Codecov Report

Merging #12693 (a5f8c03) into dev (dcb8070) will decrease coverage by 0.04%.
The diff coverage is 0.64%.

@@             Coverage Diff              @@
##                dev   #12693      +/-   ##
============================================
- Coverage     39.05%   39.01%   -0.05%
- Complexity     4186     4210      +24
============================================
  Files          1043     1051       +8
  Lines         39506    39843     +337
  Branches       4544     4574      +30
============================================
+ Hits          15430    15543     +113
- Misses        22319    22530     +211
- Partials       1757     1770      +13

Impacted Files
Coverage Δ

...dolphinscheduler/plugin/task/linkis/Constants.java
0.00% <0.00%> (ø)

...nscheduler/plugin/task/linkis/LinkisJobStatus.java
0.00% <0.00%> (ø)

...olphinscheduler/plugin/task/linkis/LinkisTask.java
0.00% <0.00%> (ø)

...cheduler/plugin/task/linkis/LinkisTaskChannel.java
0.00% <0.00%> (ø)

...r/plugin/task/linkis/LinkisTaskChannelFactory.java
0.00% <0.00%> (ø)

...scheduler/plugin/task/linkis/LinkisParameters.java
33.33% <33.33%> (ø)

...erver/master/processor/queue/TaskEventService.java
69.64% <0.00%> (-10.72%)
:arrow_down:

.../dao/repository/impl/ProcessDefinitionDaoImpl.java
4.34% <0.00%> (-5.66%)
:arrow_down:

...er/master/dispatch/host/assign/RandomSelector.java
77.77% <0.00%> (-5.56%)
:arrow_down:

...hinscheduler/plugin/alert/script/ScriptSender.java
70.58% <0.00%> (-1.64%)
:arrow_down:

... and 37 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

please review again @caishunfeng

Please add the doc in this pr too. @shangeyao


UtilWorld#getRandomPosition's y level always being zero

Fixes UtilWorld#getRandomPosition's y level always being zero. This change sets the y-level to be the position's surface level

Implemented myself


docs: Fix user documentation

Summary:

Remove Chat with Zulip button doc; the images referenced in this doc have been
deleted for some reason, rendering it almost useless with the missing
images.

Fix formatting errors in various docs.

Change wording in various docs for better clarification.

Conform old and new docs to documentation styling guidelines.

Automated message from Dropbox CLA bot
@synicalsyntax, it looks like you've already signed the Dropbox CLA. Thanks!

For the "Chat with Zulip" button one; we should probably not delete it but instead fix it.

Thanks for working on this @synicalsyntax!
I merged everything but removing the "Chat with Zulip" button and docs: Update *Verify that you message has been successfully sent* doc..  For the latter, I think you misunderstood what the previous version was saying in:
-Zulip is designed to store locally echoed message content in local
-storage and replay it when your browser reconnects to the Internet, to
-avoid issues where messages users thought they sent are lost.

We don't expect most users to be watching for the subtle missing-timestamp property; that is primarily to make it possible to debug visually whether a message has been sent (and have something that users who are carefully inspecting a message can identify).  The thing to protect users from losing messages is that we store them in browser local storage and attempt to retransmit them when the client is back online.  This feature seems to be not working properly right now (and will probably be transmuted into an integration with the "drafts" feature), but we'll probably fix it soon.  The new framing makes it sound like the timestamp thing is there to prevent users from losing messages (and you're supposed to be on the lookout for this as a user!), which is an unreasonable thing to be expecting users to do and makes the doc feel a bit out of touch.
You should be able to just rebase your branch (which will automatically drop all but the 2 remaining commits), fix those 2 commits up, and then ping me on this PR to merge the cleaned up versions of the rest.  Thanks @synicalsyntax!

@timabbott I've fixed the Join Zulip Chat button doc, but I'm unsure if I fixed what you requested in docs: Update *Verify that you message has been successfully sent* doc. Can you please review it to see if your requested changes were fixed?


fix: Infinity scroll is slow

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context

[x] Closes #5394
[x] Closes #5461
[x] Closes #5457
[ ] Requires deployment <>

Before submitting pull request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[ ] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </bsx/collection>
[ ] I've tested PR on mobile
[ ] I've written unit tests 🧪
[ ] I've found edge cases

Had issue bounty label?

[x] Fill up your KSM address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot 📸
tested on /rmrk/explore/items?page=6

Would it not be better to integrate nuxt-img instead of vue-lazyload?
I ask this because I would like to avoid adding new plugins until we've done Nuxt3 migration

Thanks. I will take a look.

I have tried to integrate nuxt-image into our project. It does works, but I found there still be something strange left to handler.

ipx provider https://image.nuxtjs.org/providers/ipx
full image url -> relative image url
nuxt.config.js  the target config should be stay static instead of server
related error:

I guess we could make another issue for someone else to pick it. Here is the demo PR
https://github.com/kodadot/nft-gallery/pull/5440

I have tried to integrate nuxt-image into our project. It does works, but I found there still be something strange left to handler.

thank you for your investigation and sorry to see that it did not worked

ipx provider https://image.nuxtjs.org/providers/ipx

Is this the solution for our case? Maybe custom provider is more in line with our needs?

full image url -> relative image url

from what i understand images are served by the same domain https://image(-beta).w.kodadot.xyz/...

nuxt.config.js  the target config should be stay static instead of server

yep this changes implies many modifications and could break stuff

I guess we could make another issue for someone else to pick it. Here is the demo PR #5440

maybe #4426?
btw in #5440 I can see that you use nuxt-image in libs/ui or this folder shouldn't have access to nuxt (not installed over here)

Agree w @preschian
@Jarsen136 please remove vue-lazy, we will make it in separated PR

I have tried to integrate nuxt-image into our project. It does works, but I found there still be something strange left to handler.

thank you for your investigation and sorry to see that it did not worked

ipx provider https://image.nuxtjs.org/providers/ipx

Is this the solution for our case? Maybe custom provider is more in line with our needs?

Yes, it's the solution for the incorrect URL prefix.

full image url -> relative image url

from what i understand images are served by the same domain https://image(-beta).w.kodadot.xyz/...

Yup, but when I set static to the target in nuxt.config.js file, the nuxt-image would not work with full image url like https://image(-beta).w.kodadot.xyz/{id}. It need the src to at the format like /privoide/{id}.

nuxt.config.js  the target config should be stay static instead of server

yep this changes implies many modifications and could break stuff

I guess we could make another issue for someone else to pick it. Here is the demo PR #5440

maybe #4426?
btw in #5440 I can see that you use nuxt-image in libs/ui or this folder shouldn't have access to nuxt (not installed over here)

There are more details that could be continued by #4426

Agree w @preschian
@Jarsen136 please remove vue-lazy, we will make it in separated PR

OK, I will make it.

Updated. I have removed the vue-lazyload plugin. Though scrolling process would be more smooth with the help of image lazyload.

seems it's doing weird gltiches when scrolling down and returning me back?
https://user-images.githubusercontent.com/5887929/229222786-fc4963d1-8a7f-4c12-b5c3-91d95fda4951.mov

seems it's doing weird gltiches when scrolling down and returning me back?

I could not reproduce that bug may because it would happen on a higher screen. And I make a fix based on that strange behaviour. Is it better now?

Should fix all of these issues #5394 #5457 #5461.

👀 You just used your one-per-month-force-push token

👀 You just used your one-per-month-force-push token

My bad. It's because I pushed something unrelated commit to this branch by mistake. : )

hmm, cannot open the deploy link, Am i doing something wrong?

@yangwao 👀

hmm, cannot open the deploy link, Am i doing something wrong?

https://deploy-preview-5429--koda-canary.netlify.app/
been changing deployments and old PRs might get wacky, koda-nuxt changed to koda-canary, at least know netlify retroactive doesn't update :p

#5420

changing deployment while things are running

Lets fix @roiLeo stuff and let it roll

wow amazing fix @Jarsen136 seems infinity scrolling is back to great state! :)
thank you!

Lets fix @roiLeo stuff and let it roll

✅  Updated

can we merge it 🥹

Yup let it roll, and @roiLeo issue will be resolved in next one


agm-snazzy-info-window error on rendering

Issue description
I am  trying to use agm-snazzy-info-window without marker but getting error on rendering of this window
here is code:
<div *ngIf="selectedMarker" >
    <agm-snazzy-info-window
         [latitude]="selectedMarker.latitude"
         [longitude]="selectedMarker.longitude"
         [isOpen]="true">
      {{selectedMarker.id}}
    </agm-snazzy-info-window>
</div>

What steps should we try in your demo to see the problem?
add agm-snazzy-info-window ui component, set input parameter [isOpen]="true"
Current behavior
error in console:
core.es5.js:1020 ERROR Error: Uncaught (in promise): TypeError: Cannot read property 'createEmbeddedView' of undefined TypeError: Cannot read property 'createEmbeddedView' of undefined     at<EMAIL_ADDRESS>(core.es5.js:10056)     at<EMAIL_ADDRESS>(snazzy-info-window.js:154)     at snazzy-info-window.js:140     at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:392)     at Object.onInvoke (core.es5.js:3890)     at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:391)     at Zone.webpackJsonp.../../../../zone.js/dist/zone.js.Zone.run (zone.js:142)     at zone.js:844     at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:425)     at Object.onInvokeTask (core.es5.js:3881)     at<EMAIL_ADDRESS>(core.es5.js:10056)     at<EMAIL_ADDRESS>(snazzy-info-window.js:154)     at snazzy-info-window.js:140     at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:392)     at Object.onInvoke (core.es5.js:3890)     at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:391)     at Zone.webpackJsonp.../../../../zone.js/dist/zone.js.Zone.run (zone.js:142)     at zone.js:844     at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:425)     at Object.onInvokeTask (core.es5.js:3881)     at resolvePromise (zone.js:795)     at zone.js:847     at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:425)     at Object.onInvokeTask (core.es5.js:3881)     at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:424)     at Zone.webpackJsonp.../../../../zone.js/dist/zone.js.Zone.runTask (zone.js:192)     at drainMicroTaskQueue (zone.js:602)     at <anonymous>
angular2 & angular-google-maps version
    "agm/core": "1.0.0-beta.1",
    "agm/snazzy-info-window": "1.0.0-beta.1",
    "snazzy-info-window": "1.1.0",

Other information
Interesting think that when I remove parameter [isOpen] from template the error disappear.

Same here...

Had the same problem. After checking the docs here
https://angular-maps.com/guides/snazzy-info-window/custom-info-windows-with-snazzy-info-window/ I've noticed that you need to have <ng-template> wrapping the content of <agm-snazzy-info-window> in order to work.
And it worked :)


[YBUG.IO] sovryn wont load today on google...

sovryn wont load today on google chrome installed on a macbook
Source url: https://live.sovryn.app/
Reported by<EMAIL_ADDRESS>Reported at: 28 Apr at 11:20 UTC
Location: GB, England, Bolton
Browser: Chrome 90.0.4430.93
OS: macOS 10.15.7
Screen: 1280x800
Viewport: 1200x620
Screenshot:

For more details please visit report page on Ybug:
https://ybug.io/dashboard/reports/detail/ah0cacr35z9wa0mnktth

Issue should now be resolved


Set the correct APP_URL for the image-server deployment

The image-server APP_URL would have the URL of the base host. This works fine when this URL linked to an openstad-frontend site, but this is not applicable to every environment.
Another issue arises when there are multiple sites, the image server would still always return the URL of the base host, which is not an ideal situation.
This commit changes the image-server deployment to use the URL of the image server by default, which is https://img.BASEHOST

Has been fixed in https://github.com/Amsterdam/openstad-kubernetes/commit/c260bf73e232edc21cecdb1fed548f1efea75f30


Drifting/unstable formatting when using a macro in an attribute inside a macro definition

The following snippet has weird/partially unstable formatting:
macro_rules! foo {
    () => {
        #[doc =
            concat!("hello world")
        ]
        pub struct Foo;
    };
}

(playground)
Formatting it once makes the contents of the doc attribute and its closing bracket drift right:
macro_rules! foo {
    () => {
        #[doc =
                    concat!("hello world")
                ]
        pub struct Foo;
    };
}

This happens again and again with every format until it hits the line length limit (I think):
macro_rules! foo {
    () => {
        #[doc =
                                                                        concat!("hello world")
                                                                    ]
        pub struct Foo;
    };
}

This does not happen outside of a macro_rules body or if the doc attribute does not contain another macro.

Thanks for reaching out. This is likely a duplicate of #5489, #5062

Right, that looks likely, didn't find those while searching.
Should I close this issue?

Yeah, let's close this.


Version 1.3.1

[x] #33
[ ] #36
[ ] Minor improvements

The only thing remaining is Android, the player works on iOS. @vkhobor I may provide a beta release once I fix the player on Android.


Read and modify Cargo.toml

The current version number needs to be fetched from the project's Cargo.toml
The new version number needs to be written to project's Cargo.toml

Resolved in #8


Blog rendering needs fixing

Fixes in commits : https://github.com/geotagx/pybossa/commit/b7f6e1a0e8214ae9f39e0e9893a3bcd98bef33d1 and https://github.com/geotagx/geotagx-theme/commit/23087fc4839a23a8dc2cd675c73a243bc57a184f

@spMohanty looks good ill close this now


Saplings disappear when bonemealed

Explain the bug:

Both Inver and Blackwood saplings disappear when bonemealed.

To Reproduce:

Place a sapling
Right-Click it with bonemeal

Environment

Modernity: [Indev-0.3.0]
Forge: [28.1.104]
Minecraft: [1.14.4]

This is weird because I have fixed this multiple times... But I'll look at it...


please add breadcrumbs at top of doc for page ancestors

Now that we are getting more hierarchy, it would be useful to have a single line at the top of a document showing the hierarchy, with links to parent pages. Example
Reference -> Protocol Specification -> Physical Layer

Added


feat(*): Added set command and some system commands

set command
scan command
system command

That's cool, thank you very much.


Color and home page layout changes

Closes https://github.com/datadryad/dryad-product-roadmap/issues/3432
Closes https://github.com/datadryad/dryad-product-roadmap/issues/2607
Loaded to sandbox for feedback

@ryscher Need to merge this in because I'm making even more css changes now. I'll deal with any merge conflicts in the README branch as they come up.


feat(ci): refactor workflows

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

[ ] The commit message follows our guidelines: https://refine.dev/docs/guides-concepts/contributing/#commit-convention

Bugs / Features

[ ] Related issue(s) linked
[ ] Tests for the changes have been added
[ ] Docs have been added / updated
[ ] Changesets have been added https://refine.dev/docs/guides-concepts/contributing/#creating-a-changeset

What is the current behavior?
What is the new behavior?
fixes # (issue)
Notes for reviewers

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal

/deploy app-crm-minimal, with-nextjs, finefoods-client, win95

/deploy app-crm-minimal


Remove type parameter from Natural (WIP)

The only reason this type parameter is currently necessary is because of the design of the comparator adaptors. Without the parameter (and replacing the natural function with a unit struct), the extremely common
let cmp = Natural.rev();
assert_eq!(cmp.compare(&1, &2), Greater);

fails type inference:
error: type annotations required: cannot resolve `_ : core::cmp::Ord` [E0283]
     let cmp = Natural.rev();
                       ^~~~~

This is because the rev method is defined on the Compare trait itself, which has two type parameters (for the left- and right-hand sides of the comparison), and the specific impl to use here is unconstrained.
However, the behavior of the rev method is always the same, regardless of the concrete comparator type or the type parameters involved. Therefore, there should really only be one way (impl) to reverse a comparator, which leads to a few possible solutions. They cannot involve type parameters on Compare.
1. Use separate constructors

Freestanding function:
pub struct Rev<C>(C);
pub fn rev<C>(cmp: C) -> Rev<C>);

Constructor method:
pub struct Rev<C>(C);
impl<C> Rev<C> {
    pub fn new(cmp: C) -> Rev<C> { Rev(cmp) }
}

Public field:
pub struct Rev<C>(pub C);

This approach has the following downsides:

The user must import an additional type or function for each adaptor. (This is potentially negated by the custom prelude RFC).

Chaining is no longer possible, which can make things confusing. For example:
let cmp = then(extract(SliceExt::len, rev(Natural))), extract(SliceExt::first, Natural));

versus
let cmp = Natural.rev().extract(SliceExt::len).then(Natural.extract(SliceExt::first));

2. Use a separate trait
pub trait CompareExt: Sized { // note that it does not extend `Compare`
    fn rev(self) -> Rev<C> { Rev(self) }
    ... // methods for other adaptors
}

With a blanket impl:
impl<C> CompareExt for C {} // note that we cannot specify `C: Compare<L, R>`
```

With specific impls:
impl CompareExt for Natural {}
impl<C> CompareExt for Rev<C> {}
...

TODO: Other options.

CC me (need to think about this a bit more...)

I've only looked at this crate for a very short while. How to handle the .get<Q: ?Sized>() model that maps have?
Without a type parameter on Natural, at least it is fine to use with both Compare<K> and Compare<Q>
I tried the following, which fails because the default comparator is C = Natural<K> so the restriction C: Compare<Q> forces K == Q  :(
    pub fn contains<Q: ?Sized>(&self, key: &Q) -> bool
        where K: Borrow<Q>,
              C: Compare<Q>,
    {

With this said, I think for this use case a phantom-type based approach works better. Custom closure comparators can't cope with the Q vs K scheme anyway.

This is super out of cache but I think the Borrow adaptor is supposed to be for that...?
https://github.com/contain-rs/compare/blob/master/src/lib.rs#L215-L234

aha thanks!

Hm I can't figure out how to use it. I don't think I can, if I require my Bmap<K, V, C> to have a C: Compare<K>, then that can't be converted in any way into something that can compare two borrowed Q values (where K: Borrow<Q>).


rewrite messages to group and subcommands

This is a rewrite of the Messages move commands.  It add them all to a Move group which uses more meaningfully named subcommands and aliases.
It also adds a range/between option for move select blocks of messages.

Had missed updating a help message.  New PR coming shortly.


removed param-persist docs

@dcaro , @jiasli , @Jacekey23, @jsntcy, this PR now reflects an update of all dependent objects and is ready for your review.

The documents for param-persist appear in 3 places:

docs-ref-conceptual/azure-cli-configuration.md
docs-ref-conceptual/azure-cli-variables.md
docs-ref-conceptual/manage-azure-groups-azure-cli.md

Contents in these articles are highly duplicated.
Simply mentioning param-persist and link to docs-ref-conceptual/param-persist-howto.md or docs-ref-conceptual/param-persist-tutorial.md will just do the job.

Most of my comments except https://github.com/MicrosoftDocs/azure-docs-cli/pull/3933#discussion_r1377157207 are for the old content. Please ignore them as those contents will eventually be gone.

@jiasli, Thank you for your feedback; however, this PR will remove these docs so I am not taking steps to update them.