Do we need new syntax?

While reviewing the latest state of this proposal the other day, it struck me that, as the readme mentions, the mechanism to perform block scope finalization already exists in JavaScript today in the form of iterators and for-of statements. This can be leveraged to build a purely API based approach to explicit resource management following closely the patterns adopted by this proposal:
for (const { using } of Disposable) {
  const resource = using(getResource());
  resource.doSomething();
  const other = using(resource.getOther());
  const stuff = other.doStuff();
  using(() => cleanUpStuff(stuff));
} // automatically cleanup, even when something throws

I actually spent this weekend implementing such a library to demonstrate that all use cases covered by the readme can seemingly be adapted to this approach, without the need to add any new syntax to the language.
https://github.com/mhofman/disposator/
While a for-of statement can be awkward at first, the code stays fairly readable. A similar approach was proposed in https://github.com/tc39/proposal-explicit-resource-management/issues/10. As discussed there, JavaScript iterators are essentially the dispose and cursor patterns mixed together, and what this approach does is to neuter the cursor pattern to only leave the dispose pattern.
With a widely adopted library or built-in API, I believe this approach could become pretty natural. I also believe the block scope is more explicit in some regard than the current direction of the syntax additions, especially around the interleaving points for asynchronous code. See https://github.com/tc39/proposal-explicit-resource-management/issues/68
One limitation of using for-of is that errors thrown during iterator close are shadowed by errors thrown during the iteration block (with no way to detect the iterator close is due to a throw). I would argue this is a separate problem that we should consider investigating (e.g. we could add an extra argument to iterator.return()). This is similar (but opposite) of errors thrown in a finally block shadowing an error thrown in the try block.

While novel, there are several things that concern me with this approach:

Abusing for..of for non-iteration purposes
Does not meet goals for Scoping, Lifetime, and Reducing Footguns
Action-at-a-Distance of using in expressions

Abusing for..of
This abuses for..of for something that isn't precisely iteration, which could easily be confusing for anyone unfamiliar with the code or the library in question. By conflating disposal with for..of, it will be more difficult to search for and find answers relating to the behavior on MDN, StackOverflow, etc. I'm very much against reusing for..of for this, as it feels like a hammer in search of a nail, when what we have is a screw.

JavaScript iterators are essentially the dispose and cursor patterns mixed together, and what this approach does is to neuter the cursor pattern to only leave the dispose pattern.

While that's certainly true, every language referenced as Prior Art in the explainer has both a cursor pattern and a dispose pattern:

C# — Cursor: IEnumerable, IEnumerator, yield return, yield break. Dispose: IDisposable, using (...) {}, using x = ....
Java — Cursor: Iterable, Iterator. Dispose: java.io.Closable, try-with-resources.
Python — Cursor: __iter__, __next__. Dispose: __enter__, __exit__, with.

The fact that JavaScript conflates these two patterns does not mean it is necessarily the correct approach, and is one of the reasons that this proposal adds @@dispose to built-in iterators as a forwarding call to this.return().
Scoping, Lifetime, and Reducing Footguns
This also does not meet the stated goals regarding coupling scoping with lifetime and reducing user footguns. While the using expression in your example is scoped to the for..of statement, it can be used anywhere within the block:
for (const { using } of disposable) {
    const x = using(f()); // scoped to for..of
    {
        const y = using(g()); // oops, still scoped to for..of
    }
    // NOTE: y was not disposed.
}

Instead, a developer must be rigorous about ensuring they don't reuse a using inside of a nested block. This also introduces a local binding for using that can escape its block (i.e., () => using), which could cause even more confusing scoping vs. lifetime issues.
Action-at-a-Distance
One of the discussions at an earlier TC39 meeting was around using an expression form for disposal, and there were concerns raised about code that might bury the expression somewhere in a complex operation. Such an expression would have action-at-a-distance side effects that are not obvious at first glance. Having an explicit declarative form mitigates that concern.

In general I would prefer to have distinct syntax with clear rules around lifetime and scoping vs. leveraging an existing feature that doesn't precisely map to the expected semantics:
// source
{
  ...
  using const x = expr1;
  ...
  {
    ...
    using const y = expr2;
    ...
  }
}

// helper (ES2015+)
var __usingScope = function* () {
  var disposables = [];
  var scope = {
    error: undefined,
    using(resource) {
      if (resource !== null && resource !== undefined) {
        const dispose = resource[Symbol.dispose];
        if (typeof dispose !== "function") throw new TypeError();
        disposables.push({ resource, dispose })
      }
      return resource;
    }
  };
  try {
    yield scope;
  }
  finally {
    var errors = [];
    for (var i = disposables.length - 1; i >= 0; i--) {
      try {
        disposables[i].dispose.call(disposables[i].resource);
      }
      catch (e) {
        errors.push(e);
      }
    }
    if (errors.length) throw new AggregateError(errors, undefined, scope.error); // sets cause
    if (scope.error) throw scope.error.cause; // throws cause
  }
};

// transposed
for (const scope_1 of __usingScope()) try {
  ...
  const x = scope_1.using(expr1);
  ...
  for (const scope_2 of __usingScope()) try {
    ...
    const y = scope_2.using(expr2);
    ...
  } catch (e) { scope_2.error = { cause: e }; }
} catch (e) { scope_1.error = { cause: e }; }

Its possible that a transpiler could leverage such a feature for downleveling to ES2015+ and still maintain this proposal's goals, since the user wouldn't have access to the generated scope.using function.

One limitation of using for-of is that errors thrown during iterator close are shadowed by errors thrown during the iteration block (with no way to detect the iterator close is due to a throw). I would argue this is a separate problem that we should consider investigating (e.g. we could add an extra argument to iterator.return()). This is similar (but opposite) of errors thrown in a finally block shadowing an error thrown in the try block.

Its not so simple to just add another error to .return (or .throw). How would you delegate the aggregated errors to a generator? How would that affect existing code, especially if someone writes a custom Iterator using next/throw/return? for..of is very limited when it comes to working with generators: it can't get the return value from the generator and can't send in values to yield (aside from undefined). I'm not sure changing the iteration protocol is the right way to go, especially to overload it with even more responsibilities to suit a use case for which it was not intended.

@rbuckton While I totally agree with what you wrote in "Abusing for … of", I don't think the arguments from "Scoping, Lifetime, and Reducing Footguns" are specific to this syntax, they always apply. Sure, the OP's library has a using() method that allows adding disposers dynamically, but this is not necessary. One could just as well do something where the resources are scoped to the block, like
for (const resource of Disposable(getResource())) {
  resource.doSomething();
  for (const other of Disposable(resource.getOther())) {
    const stuff = other.doStuff();
    …
  }
} // automatically cleanup, even when something throws

And scopes never did coincide with lifetimes in the presence of closures. I doubt that is a problem we could solve without introducing something like Rust's movement semantics… Regardless what syntax for resource management we come up with.
Finally, the example you gave where y is only disposed at the end of the outer block is actually quite common. There are use cases where you need something like that, and Python has the builtin contextlib.ExitStack for this purpose:
{
    using const stack = new ExitStack();
    const x = stack.push(f()); // scoped to the block
    let y = null;
    if (…) {
        y = stack.push(g()); // still scoped to the outer block, on purpose
    }
    // y is still usable here
} // x and y are disposed here

And yes, of course it's a footgun to call stack.push outside of the block (or passing it around etc), but IIRC it would throw when you try to use it after the stack has been disposed.

Your example using for (const resource of Disposable(...)) is something I'd considered as a workaround for years now. It suffers from some of the same issues as the previous try using (const x = ...) syntax in that it requires a new block scope if you need to evaluate code between two resources.

And scopes never did coincide with lifetimes in the presence of closures. I doubt that is a problem we could solve without introducing something like Rust's movement semantics… Regardless what syntax for resource management we come up with.

In C#, the resource lifetime and scope are stilled tied to its block regardless of closures. A callback that is invoked while the resource is still "alive" can access the resource. If that callback is invoked after the resource has been disposed, the binding for the resource is still reachable but its most likely that accessing properties or methods on the object will throw an ObjectDisposedException.
I've been considering the possibility of adding an entry to the binding in the environment record to invalidate the binding, so that accessing the binding once it leaves scope would throw an error not unlike accessing an uninitialized const binding. The problem is that, even if you invalidate the binding, its still possible to copy it to another value so that it can escape the scope:
let y;
{
  using const x = getX();
  y = x;
} // x is disposed
y; // can still access the disposed value from 'x'

Since this isn't a 100% foolproof safeguard, I'm not sure its worth pursuing. In C#, its up to the producer of the Disposable to throw if their object is not in a usable state after being disposed. This also allows some disposables to be reused (such as a database connection with an .Open() method), so its more flexible.

Finally, the example you gave where y is only disposed at the end of the outer block is actually quite common. There are use cases where you need something like that, and Python has the builtin contextlib.ExitStack for this purpose: [...]

With ExitStack you are opting in to this behavior. You can do the same thing with Disposable with some additional user code:
{
  using const void = new Disposable(() => Disposable.from(stack)[Disposable.dispose]()); // scoped to the block
  const stack = [];
  const push = resource => {
    stack.push(resource);
    return resource;
  };

  const x = f();
  stack.push(x);

  let y = null
  if (...) {
    y = g();
    stack.push(y);
  }
  // y is still usable here
} // x and y are disposed here

I've wanted to keep the API surface of Disposable fairly simple (i.e., essentially immutable with only a Symbol.dispose method), but if something like ExitStack (and AsyncExitStack) seems valuable enough it might be worth adopting either as part of Disposable or as a separate class.

By conflating disposal with for..of, it will be more difficult to search for and find answers relating to the behavior on MDN, StackOverflow, etc.

While I agree the for...of syntax is not quite natural, I'm not sure it impair the ability to find answers. I doubt you can find meaningful answers for just the "using const" (nor "for of") terms, but if you see the "Disposable" term, you'll add it to the search and find related answers.

Scoping, Lifetime, and Reducing Footguns

Like @bergus, I disagree with the premise that it's unacceptable to call using in a sub block, or that it's unclear the resource would be disposed when exiting the defining block.
I have however realized that I forgot to invalidate the using function after the aggregated resource has been disposed. That's now fixed by https://github.com/mhofman/disposator/pull/2/commits/616025d4dae258ae7b108d62b11e0c5130a74806.

One could just as well do something where the resources are scoped to the block

Very true, added the shorthand in https://github.com/mhofman/disposator/pull/2/commits/120c2ecc28dfad796ea65a864e3377fbbd0cf7e7
for (const res of Disposable.using(getResource())) {

}

Action-at-a-Distance

In my opinion a declarative form introduces other issues, mainly that the syntax is awkward when you want to ignore the result or destructure it. In general anything left of an = impacts the identifiers in that position. The using const syntax however has an effect to the right hand side of the assignment. This is also a surprising action at distance in its own way, and the mitigation is to disallow patterns that are normally valid in LHS (let, destructure)

every language referenced as Prior Art in the explainer has both a cursor pattern and a dispose pattern

To be clear, I am not 100% opposed to new syntax, I just believe the current binding assignment syntax introduces too much complexity and has too many unresolved issues. On top of the above, I'm still concerned with the hidden async interleaving points.
I'm actually wondering if there isn't a way to support RAII style with a try-with statement block for the dispose pattern, combined with an aggregate runtime helper. That would resolve the concern you have with the abuse of for-of, and my concerns with the using const syntax. I know this is a step back, but I'm not sure if runtime aggregation has been explored with such an approach
try with (const res of getResource()) {

}

try with (const { using } of Disposable) {
  const res = using(getResource());
}

I'm looking to advance this proposal based on discussions I've had with @syg around shared structs and possible future concurrent JS capabilities. I'd really like a clean and concise syntactic solution for handling thread synchronization and locking, as concurrency is going to be complicated enough without wrapping everything in a for..of:
shared struct class State {
  ready = false;
  ...
}
const mut = new Mutex();
const cv = new ConditionVariable();
...
{
  using const lck = mut.lock();
  cv.wait(lck, () => state.ready);
  ...
}

To be clear, I am not 100% opposed to new syntax, I just believe the current binding assignment syntax introduces too much complexity and has too many unresolved issues. On top of the above, I'm still concerned with the hidden async interleaving points.

I'm not clear on where the complexity is. Are you talking about spec complexity or the developer experience?

try with (const res of getResource()) {

}

We just got rid of try using () {} in favor of using const. Are you arguing that we should go back to that? There were more than a few detractors of try using, and using const was the consensus the last time this came to committee (prior to the most recent October meeting). I've also heard feedback from current and past members of the C# team that C#'s new using declaration form is much preferred over the older using (Type x = expr) {} block syntax, for the same reasons.

Its not so simple to just add another argument to .return (or .throw). How would you delegate the aggregated errors to a generator? How would that affect existing code, especially if someone writes a custom Iterator using next/throw/return? for..of is very limited when it comes to working with generators: it can't get the return value from the generator and can't send in values to yield (aside from undefined). I'm not sure changing the iteration protocol is the right way to go, especially to overload it with even more responsibilities to suit a use case for which it was not intended.

Dealing with suppressed errors is a pain, and that's why I believe the problem should be fixed regardless of this proposal. I'm struggling hard with them in my library, and it's plain impossible to do proper error handling in iterators.

At this point I doubt we can change the semantics of suppressed errors, especially in iterators. Aka a finally thrown error will always suppress a try error, and if an iterator is closed due to an error, an error thrown in the iterator's return will always be suppressed. However what we can do is surface the "cause" error, and offer facilities for code that cares to handle the situation.
A strawman I have in mind:

Surface a "cause" error in a finally through a finally.error syntax addition
Add an extra argument to .return and have the iterator close steps provide the cause (.throw is surprisingly never invoked on its own by the spec, only forwarded).
Surface an iterator close error in a generator finally statement through the above finally.error

That still doesn't resolve the issue of surfacing the suppressed error after the iterator close, but at least the iterator logic has more information. For example it could try to attach a suppressed property to the causing error (which may fail on non-objects, or frozen objects), or it could annotate with a side table. I wish we could change the iterator close to suppress the causing error like for try-finally, so that we'd have the opportunity to throw a new wrapping error, but I'm worried some obscure piece of code somewhere is relying on the suppression. Maybe we could make it work through assignment to finally.error = wrappedError.

Are you talking about spec complexity or the developer experience?

Both. The spec changes are extremely broad, with some very surprising interactions as @waldemarhorwat went through last week. And IMO questions like #78 do show the developer ergonomics aren't quite right yet either.

There were more than a few detractors of try using

I need to go through the notes and issue history, I was trying to get a feel of where the objections stemmed from. As I mentioned I don't know if resource aggregation with single block syntax was explored to resolve the nesting issues. I'd also propose to avoid any assignment style syntax inside the clause, like for-of, to steer away from confusion regarding what is the resource tracked (right of of, not left).

going to be complicated enough without wrapping everything in a for..of:

You have to wrap a disposable in a block. The question is whether a new explicit block is needed, or if re-using a regular statement's block is acceptable. My concern is that re-using existing blocks is a problem in the case of hidden async interleaving points. Aka the following should not be allowed, and I doubt there is a way to syntactically mark such block statements:
if (condition) {
  using async const res = getResource()
}

If you need to introduce a dedicated block statement, then there isn't much difference if that statement is for-of or try-with-of, or something else.

Are you talking about spec complexity or the developer experience?

Both. The spec changes are extremely broad, with some very surprising interactions as @waldemarhorwat went through last week. And IMO questions like #78 do show the developer ergonomics aren't quite right yet either.

Waldemar brought up three cases he considered surprising:

Block refactoring
Tail calls
for..in vs for..of

Block refactoring
I've been discussing the block refactoring concern in #74. @ljharb seems to agree that the current approach is correct and what Waldemar considers surprising here is the correct representation.
Tail calls
Tail recursing with using const is equivalent to for..of using the example in the OP:
// with using const
switch (...) {
  case 1:
    return foo(1); // not tail recursive due to `using const` in CaseBlock
  case 2:
    using const x = ...;
    return foo(2); // not tail recursive due to `using const` in CaseBlock
  case 3:
    return foo(3); // not tail recursive due to `using const` in CaseBlock
}

// with for..of
for (const { using } of Disposable) {
  switch (...) {
    case 1:
      return foo(1); // not tail recursive due to containing `for..of`
    case 2:
      const x = using(...);
      return foo(2); // not tail recursive due to containing `for..of`
    case 3:
      return foo(3); // not tail recursive due to containing `for..of`
    }
}

There's nothing surprising to me here, tail call semantics are identical. The only spec complexity is that HasCallInTailPosition needs to check whether the Block or CaseBlock directly contains a using const declaration.
If you wanted prevent case 2 from breaking tail recursion, you would need to move the using const (or for..of) into a case-local block:
// with using const
switch (...) {
  case 1:
    return foo(1); // tail recursive position
  case 2: {
    using const x = ...;
    return foo(2); // not tail recursive due to `using const` in Block
  }
  case 3:
    return foo(3); // tail recursive position
}

// with for..of
switch (...) {
  case 1:
    return foo(1); // tail recursive position
  case 2:
    for (const { using } of Disposable) {
      const x = using(...);
      return foo(2); // not tail recursive due to containing `for..of`
    }
  case 3:
    return foo(3); // tail recursive position
}

for..in vs for..of
Waldemar claims that something is surprising here:
for (using const x in y); // syntax error, `using const` not allowed in `for..in`
for (using const x of y); // no syntax error

I would argue that allowing using const in for..in would be surprising, as the only think a for..in with a using const could do is throw a runtime error, since neither string nor symbol can be an Object with a Symbol.dispose method.

There were more than a few detractors of try using

I need to go through the notes and issue history, I was trying to get a feel of where the objections stemmed from. As I mentioned I don't know if resource aggregation with single block syntax was explored to resolve the nesting issues. I'd also propose to avoid any assignment style syntax inside the clause, like for-of, to steer away from confusion regarding what is the resource tracked (right of of, not left).

for..of is not assignment style syntax. Each iteration produces a new per-iteration environment with a new binding for the declared variable. There are no reassignments. That said, I've debated as to whether to allow using const in for..of. Earlier iterations of the proposal did not allow it, but it is a convenient way to work with disposable resources produces by a generator. I don't have a strong feeling either way.

going to be complicated enough without wrapping everything in a for..of:

You have to wrap a disposable in a block. The question is whether a new explicit block is needed, or if re-using a regular statement's block is acceptable. My concern is that re-using existing blocks is a problem in the case of hidden async interleaving points. Aka the following should not be allowed, and I doubt there is a way to syntactically mark such block statements:
if (condition) {
  using async const res = getResource()
}

If you need to introduce a dedicated block statement, then there isn't much difference if that statement is for-of or try-with-of, or something else.

You only have to wrap the disposable in a block at the top level of a SourceFile. Every other place you could legally write using const has either an implicit or explicit block scope:
// legal:
function f() {
  using const x = ...; // ok
}
const g = () => {
  using const x = ...; // ok
};
if (condition) {
  using const x = ...; // ok
}
class C {
  static {
    using const x = ...; // ok
  }
  method() {
    using const x = ...; // ok
  }
}

// illegal:
if (condition)
  using const x = ...; // already illegal. `Statement` does not include `using const`.

Thanks for reminding me of the concerns raised by Waldemar. I agree those are workable.

for..of is not assignment style syntax. Each iteration produces a new per-iteration environment with a new binding for the declared variable. There are no reassignments.

Exactly. And my reading of the previous try using was that it used assignment syntax try using (const res = ...). What I'm saying is we should steer clear of that with something like try with (const res of ...).

Every other place you could legally write using const has either an implicit or explicit block scope

And that is my problem, as that block now may have a hidden async interleaving point when it exits.

And IMO questions like #78 do show the developer ergonomics aren't quite right yet either.

Multiple members of the committee have different intuitions as to what should be disposed (the value being destructured or the destructured bindings), so I'm not sure there's a right answer aside from outright banning it. Destructuring isn't too bad if consensus is that the thing that is disposed is the result of the Initializer (i.e., the value being destructured).
However, if the destructured bindings are what is to be disposed, then destructuring would be inherently unsafe:
// with `using const`
using const { x, y } = ...;

// with `for..of`
for (const { using } of Disposable) {
  const { x, y } = ...;
  using(x);
  using(y);
}

In the above example if x is not null, undefined, or a disposable object, then y will never be disposed.
Unless we can get consensus on having the thing that is disposed be the result of evaluating Initializer, I don't think destructuring is safe. If we can get consensus on that, then we don't need using const void =  since you could just write using const {} = .
Also in #78 there has been some discussion of dropping the const keyword, which would further block destructuring since using [x] = ... is already legal JavaScript.

And that is my problem, as that block now may have a hidden async interleaving point when it exits.

I would be happy to add an explicit marker for the async case, if that's necessary to achieve consensus:
// postfix `await using` at end of block;
{
  // note: switch from `using await` to `using async`
  using async const x = ...;

} await using; // explicit marker for block

// postfix probably unnecessary for async function/generator/arrow/method, since function body exit
// (or `return`) is already a potential async interleave point and is essentially unobservable
async function f() {
  using async const x = ...;

} // no explicit marker for body

While async dispose has its use cases, they are far fewer than synchronous dispose. I'm willing to incur a syntax burden for a trailing marker as long as it only affects the async case.
Regarding try using, @leobalter was adamant about not wanting try as part of this when I switched the proposal to align with Java's try-with-resources syntax. The previous try using declaration was a compromise to make the syntax more palatable. Switching to RAII-like declarations via using const was a bigger win with broader support within the committee since the syntax was more convenient and didn't use try at all.
My biggest concern with try with or try using is that we would have to rehash all of these arguments again.

@mhofman I would note that, while I still think syntax is the correct direction for this proposal, I did just publish an update to @esfx/disposable with a .scope() static method inspired by your Disposable[Symbol.iterator] example (though it adds a .fail(error) method to the scope object based on the __usingScope helper in my earlier comment).
I also added DisposableStack and AsyncDisposableStack to @esfx/disposable as approximations of Python's ExitStack and AsyncExitStack:
class DisposableStack implements Disposable {
  // Based on `ExitStack.enter_context`/`ExitStack.push`/`ExitStack.callback`
  enter<T extends Disposable | (() => void) | null | undefined>(value: T): T;

  // Based on `ExitStack.pop_all`
  move(): DisposableStack;

  // Based on `ExitStack.close`
  [Disposable.dispose](): void; // NOTE: would be `Symbol.dispose` if shimmed
}

Though I'm not sure if the functionality should be merged into Disposable/AsyncDisposable, as I was hoping to keep the internal state of those objects immutable (with the only exception being the ability to dispose of them). Also, while a minor point, I was hoping to avoid conflicts in TypeScript when using Disposable as an interface with only a [Symbol.dispose]() method. Adding additional methods to Disposable would result in confusing naming (a. la Promise<T> vs PromiseLike<T> today), though that might be an argument for changing the global class names in this proposal to DisposableStack and AsyncDisposableStack instead.

For the records I retract any of my objections to try using is that's necessary. That doesn't mean I'm +1 but I can't commit with time to support for any alternatives here.

Also, while a minor point, I was hoping to avoid conflicts in TypeScript when using Disposable as an interface with only a [Symbol.dispose]() method.

Right, I definitely overloaded the concepts of a Disposable interface with a concrete Disposable constructor which implements aggregation semantics. The type declarations my package include do make the difference, but that's because I manually typed everything.
It's still unfortunate we have to resort to this type of manual try/catch and .fail() to work around the way iterator close suppresses errors.

I would be happy to add an explicit marker for the async case

How would such a marker work with non standalone statement blocks? One interaction that comes to mind is with if-else.

I would be happy to add an explicit marker for the async case

How would such a marker work with non standalone statement blocks? One interaction that comes to mind is with if-else.

The IfStatement  production uses the Statement non-terminal, which includes Block, so it would be something like:
// NOTE: in [+Await]
if (...) {
  using async const x = ...;
} await using
else {
}

// or

// NOTE: in [+Await]
if (...) {
  using async const x = ...;
} await using else {
}

Another option would be to go back to the mixed syntax with both a block form and a declaration form, but disallow the declaration form for async disposal:
// non-async block form
try using (const x = expr, y = expr) {
}
try using (expr) { // or just `try using (void = expr)`
}

// async block form
try using await (const x = expr, y = expr) {
}
try using await (expr) { // or just `try using await (void = expr)`
}

// non-async declaration form
using const x = expr, y = expr;
using const void = expr;

// no async declaration form 🙁

It has the upside of having an explicit marker at the top of the block to indicate the interleave point at the end of the block, but the downside of not having parallel syntax across both async and non-async cases.

Another option would be to introduce a coupled block syntax, i.e.:
using {
  using const x = ...;
}

async using {
  using await const x = ...;
  // or just make `using const` work with @@asyncDispose in an `async using` block?
}

Though I'm not sure I like this approach, as it complicates the majority case (synchronous dispose) to handle the minority case (asynchronous dispose). I like the convenience of writing using const x = ...; in any block, otherwise we're back to issues with scope-vs-lifetime ambiguity:
// (a)
using {
  using const x = ...;
  // (b)
  {
    using const y = ...; // is this an error or is `y`'s lifetime scoped to (a)
  }
}

One limitation of using for-of is that errors thrown during iterator close are shadowed by errors thrown during the iteration block (with no way to detect the iterator close is due to a throw). I would argue this is a separate problem that we should consider investigating (e.g. we could add an extra argument to iterator.return()). This is similar (but opposite) of errors thrown in a finally block shadowing an error thrown in the try block.

We've previously discussed error suppression in #19 and #63, and more recently in #74. I also sketched out a rough concept for meta properties to access suppressed exceptions in this comment, though @ljharb pointed out that meta properties wouldn't work with rejected Promises.

Also, in #74 we discussed the possibility of passing the exception as an argument to @@dispose/@@asyncDispose.

In my mind the problem is not in catch blocks, but in finally blocks where even if the finally logic is defensive and catches its own errors, it cannot communicate both errors. In that sense, rejected promises have a path where promise.finally would accept an optional argument of any previous error thrown.
Basically my preference would be:
try {
  throw new Error('Initial');
} finally {
  const finallyError = finally.error;
  try {
    cleanup();
  } catch (err) {
    if (finallyError) {
      throw new AggregateError([err, finallyError]);
    } else {
      throw err;
    }
  }
}

Promise.reject(new Error('initial'))
  .finally((finallyError) => {
    try {
      cleanup();
    } catch(err) {
      if (finallyError) {
        throw new AggregateError([err, finallyError]);
      } else {
        throw err;
      }
    }
  });

And for this to be consistent, for-of would pass the iteration block error to the iterator .return and suppress the iteration block error with any iterator close error, so that the following would work too:
function * foo () {
  try {
    yield;
  } finally {
    const finallyError = finally.error;
    try {
      cleanup();
    } catch(err) {
      if (finallyError) {
        throw new AggregateError([err, finallyError]);
      } else {
        throw err;
      }
    }
  }
}

for (const _ of foo()) {
  throw new Error('Initial');
}

I'm actually wondering if we could not simply introduce:
try {
} finally (err) {

}

Anyway this is way off-topic, but I'd be happy to continue this discussion somewhere else.

What would finally.error be if no error was thrown? It can’t be undefined, because you can throw that.

Yeah I know there is that pesky little detail. I believe @rbuckton proposed .hasError for those who care about crazy people throwing undefined.
 It would require significant spec work to make it viable. finally isn't the only clause that would care about suppressed exceptions either:
try {
  try {
    throw new Error("a");
  }
  finally {
    finally.error; // Error("a")
    throw new Error("b");
  }
}
catch (e) {
  // e: Error("b")
  // any way to see Error("a")?
}

I don't think it needs to cross any nesting boundary. It's to each local error handling logic to decide what is best to do.

I've seen plenty of code that does:
let e;
try {
  doStuff();
  doMoreStuff();
} catch(err) {
  e = err;
} finally {
  if (e) {
   // something
  } else {
    //something else
  }
}

@mhofman a metaproperty for hasError wouldn't work for promises.
It's not for us to decide that throwing undefined (or null) is improper; it's something the language has always allowed and must always do.

But for promised and optional argument to the finally callback can definitely be differentiated:
promise.finally((...errors) => console.log(errors.length));

Sure - via arguments.length as well - but then you've got a pretty dramatic difference between how it's done with try/catch vs with Promises, and we've tried pretty hard to minimize differences there.

Which is why I suggested this:

try {
  throw undefined;
} finally (...errors) {
  if (errors.length) {
    console.log('thrown', errors[0]);
  }
}

If we make the errors expression in the finally statement optional for backwards compatibility, we're free to also allow the "rest" form for code that wants to support undefined errors

I agree that resolves the objections I've stated.
It still seems pretty strange to me to have access to the fulfillment status and payload inside a "finally".

Code can already have access if it jumps through scope breaking hoops. Which means these forms can actually be transpiled.
The main problem I still have is the inversion of suppression on iterator closing. If love to figure out if it's be a breaking change we can make, or if we need to find a way to mitigate (I have my ideas, but I'd love to avoid the complication they bring)

There's another issue with using for..of for this that I discovered after discussing TypeScript's control-flow analysis in https://github.com/tc39/proposal-explicit-resource-management/issues/74#issuecomment-958420823: TypeScript's control-flow analysis for loops assumes any loop body might not be executed as an iterable might not have any elemens:
let a: string | undefined;
for (const x of iterable) {
  a = "foo";
}
a; // a: string | undefined

This means that we can't do CFA accurately using the for..of approach:
let a: string | undefined;
{ // normal block
  a = "foo";
}
a; // a: string

let b: string | undefined;
for (const { using } of Disposable) {
  b = "foo";
}
b; // b: string | undefined

I'm not sure there would be a consistent way of handling CFA without new syntax. While this may seem like a TypeScript-specific issue, that's still a fairly sizable population of users we'd like to be able to support with this feature.

We're getting pretty far afield here, but: as a TypeScript user, I would be quite happy if TypeScript's analysis improved to the point where it could keep track of a "definitely nonempty" bit on at least some iterables, which would solve that particular problem (since in this use the analysis would be trivial, and so even a very conservative analysis would handle it). That's currently one of the main sources of my // @ts-ignore comments.
The TypeScript team has made similar improvements to the analysis in the past, so I'm hopeful that someday it'll get there. It would be a shame to introduce new syntax for reasons which became obsolete after some improvements to TypeScript's analysis. (Not to say there aren't other reasons for new syntax; I'm just hesitant to rely on this particular one.)

Note: I've opened #80 to discuss the possibility of a more comprehensive DisposableStack/AsyncDisposableStack API.

Another option would be to introduce a coupled block syntax, i.e.:

I've been considering this, and an option we could consider for the async dispose case is to split the using into two declarations for the async case:
async function f() {
  // (1) change `using await const` to `using async const`
  using async const x = ...;

  // (2) require an explicit `using await;` statement at the end of a block containing `using async const`
  using await;
}

With the following rules:

using await; is only allowed in [+Await].
If present, using await; must be the last statement of the block.

This means it's also an error to have more than one using await in the same block (nested or containing blocks are ok though).

It's an error to declare a using async const in a block that does not have a using await at the end of the same block.

This results in a marker that does not affect normal using const and makes it clear where the async interleave point is.

or, instead of using await; we could use something equally meaningful that isn't currently valid JS, such as await finally (since await using is already legal JS).

await using foo isn’t valid tho.

But what would you put in the place of foo? This would be an interleave point for the entire block. A single keyword statement would be ideal but isn't an option (because identifiers). A two-keyword statement is palatable, but I think three keywords would be a bit much given we already would have to write using async const (or using await const) for this.

oh. then "using" wouldn't make sense anyways, because that's transitive.

oh. then "using" wouldn't make sense anyways, because that's transitive.

I'm not sure I understand what you mean by this statement.

In prose, if i see the word "using", i expect there to be a word after it that answers the question "using what?"

I've been considering this, and an option we could consider for the async dispose case is to split the using into two declarations for the async case:

That would be an acceptable approach. It does however feel like a departure from the other block syntax where the control keywords is lexically outside the block. However if your goal is to allow mixing it with other block based statements like if-else, I'm not sure I see much of an alternative.
I also do like the switch to using async as it always struck me weird that the await keyword was not in fact awaiting anuything.
FYI, I'm still not convinced the syntax cost is justified, but at least it removes some of my strong objections.

I am strongly in favor of syntax for this proposal for a number of reasons, some of which I've outlined in the updated README.md in the root of the proposal. I am also strongly opposed to abusing for..of for this as it serves to conflate two separate capabilities: Resource Management and Iteration.
I'm also strongly in favor of a terse syntax for synchronous dispose that supports RAII-style declarations, i.e.:
using const resource = acquireResource();
using const void = acquireLock();
// etc.

Given prior discussions regarding destructuring, I've opted to err on the side of caution and forbid destructuring. This potentially leaves us the ability to make synchronous resource management even more terse:
using resource = acquireResource();
using void = acquireLock();
// etc.

However, concerns have been raised repeatedly regarding the lack of a marker to indicate the async interleaving point in asynchronous resource management:
{
  using await const resource = acquireResource();
  // ...
} // resource is *asynchronously* disposed

This arguably necessitates some kind of block form to indicate the interleaving point. To that end, we have discussed various mechanisms for achieving this, i.e.:
{
  using async const resource = acquireResource();
  // ...
} using await; // NOTE: `await using` will not work because `{} await using` is already legal JS

While this does clearly illustrate the interleaving point, it seems a bit out of place in JS with the only similar statement being do {} while (...);, and even then the while has a trailing condition.
As an alternative, I am considering reviving the original syntax of the proposal in addition to the RAII-like using declarations for synchronous resource management:
// Synchronous dispose:

// UsingStatement[~Await[:
using (expr) { ... }
using (const x = expr) { ... }

// UsingDeclaration:
using x = ...;
using void = ...;

// Asynchronous dispose:

// UsingStatement[+Await]:
using await (expr) { ... }
using await (const x = expr) { ... }

If go that route then there will be consistency between sync and async dispose via UsingStatement, as well as a simplified RAII form for sync dispose which is often the most-used form in my experience.
We could possibly consider a future proposal to introduce an async RAII-form, such as:
// opt in to async resource management:
using await {
  using const x = ...; // implicitly uses @@asyncDispose instead of @@dispose
}

@waldemarhorwat: You raised objections to using (...) {} in the past due to the need for a cover grammar. However, it seems that the Pattern Matching proposal is also pushing for advancement with a similar requirement (i.e., match(...) { }). If a satisfactory cover grammar is crafted, would you still be opposed to using (...) {}?

I've created #86 with the proposed changes to syntax in my previous comment.

I love going forward with the terse using x = …; syntax, even if that means no destructuring. Not having the const keyword makes it explainable as being something different.
Can you add an FAQ to the readme, please: a) why no destructuring b) why no inline operator?

One final alternative I'm considering is this:
// synchronous `using` declarations
{
  using x = ...; // must be null, undefined, or have a [Symbol.dispose]()
  using void = ...; // must be null, undefined, or have a [Symbol.dispose]()
}

// asynchronous `using` declarations (in a +Await context)
{
  using x = ...; // must be null, undefined, or have a [Symbol.asyncDispose]() or [Symbol.dispose]()
  using void = ...; // must be null, undefined, or have a [Symbol.asyncDispose]() or [Symbol.dispose]()
} await using;

In this version there is no using await declaration. Instead, both sync and async using just use `using` BindingList `;`. To indicate that [Symbol.asyncDispose]() should be considered (and awaited), you must terminate the block with an await using on the same line. A trailing await using is not necessary in an AsyncFunctionBody, since there is already an implicit interleaving point when exiting the function.
This more accurately models the behavior since a using await const declaration doesn't actually perform an await at the declaration site.
This also would avoid resurrecting the discussions over using a cover grammar for using (...) { } or try-with-resources.
Examples:
// normal function, no implicit `await` at body
function f1() {
  using file = createFile();
  ...
} // calls `file?.[Symbol.dispose]()`

// async function, implicit `await` at body
async function f2() {
  using stream = getReadableStream();
  ...
} // calls `stream?.[Symbol.asyncDispose]()`

async function f3() {
  // no implicit `await` at end of Block even if we're in an async function
  {
    using x = createResource1();
    ...
  } // calls `x?.[Symbol.dispose]()`

  // explicit `await` at end of Block
  {
    using y = createResource2();
    ..
  } await using; // calls `y?.[Symbol.asyncDispose]()`
}

As a matter of taste,
{
  using y = createResource2();
  ...
} await using; // calls `y?.[Symbol.asyncDispose]()`

seems worse than any variation of
try async (const y = createResource2()) {
  ...
} // calls `y?.[Symbol.asyncDispose]()`

If we're going to have a special block syntax, I would prefer the specialness be visible at the top of the block.

If we're going to have a special block syntax, I would prefer the specialness be visible at the top of the block.

That is in direct opposition to @erights's stated preference that the interleaving point be annotated at the bottom of the block.

Well, this comment suggests going forward with try using but seeking a better syntax; my position is that a syntax which only makes the specialness of a block visible at the end of the block is not better.

Well, this comment suggests going forward with try using but seeking a better syntax; my position is that a syntax which only makes the specialness of a block visible at the end of the block is not better.

That comment indicated moving forward with try using when achieving Stage 2, but seeking out alternatives during Stage 2, which is what I am investigating currently.

If { ... } await using is controversial, an alternative would be using await { ... } (i.e., moving the modifiers to the top of the block). In this alternative, the syntax would be:
function f() {
  using id = expr; // @@dispose
  {
    using id = expr; // @@dispose
  }
}

async function f() {
  using id = expr; // @@asyncDispose/@@dispose

  {
    using id = expr; // @@dispose only
  } // no implicit Await

  using await {
    using id = expr; // @@asyncDispose/@@dispose
  } // implicit Await

} // implicit Await

NOTE: Here I'm using using await as a prefix form rather than await using to hopefully minimize an potential cover grammar.

As an FYI, we've chosen to postpone async using to a follow-on proposal to focus primarily on synchronous, RAII-style using declarations.
I still strongly believe syntax is warranted here. There are runtime semantics regarding error suppression that aren't easy to replicate purely with API without also breaking TCP since leveraging for..of changes the meaning of break and continue when refactoring. I also believe that the conciseness of using x = ... is a significant improvement over nested try..finally blocks or the boilerplate needed to emulate the intended semantics using for..of.

@mhofman: At this point, would you still object to the introduction of new syntax in the form of using? I'd like to think that https://github.com/tc39/proposal-explicit-resource-management#relation-to-iterator-and-forof sufficiently covers the major themes in this issue, and if so would like to close this issue for housekeeping purposes.

Given the current scope of the proposal I think we are ok with the using syntax, however I want to stress that I have reservation with the current semantics of for await(using ... of ...) and the potential conflicts with future support of AsyncDisposable as explained in #101.


FHIRHelpers

I got an exception in Context.resolveFunctionRef when using FHIRHelpers 1.0.2.
Could not resolve call to operator 'ToConcept' in library 'FHIRHelpers'.
at org.opencds.cqf.cql.execution.Context.resolveFunctionRef(Context.java:332)
at org.opencds.cqf.cql.elm.execution.FunctionRefEvaluator.evaluate(FunctionRefEvaluator.java:24)
at org.opencds.cqf.cql.elm.execution.PropertyEvaluator.evaluate(PropertyEvaluator.java:16)
at org.opencds.cqf.cql.elm.execution.FunctionRefEvaluator.evaluate(FunctionRefEvaluator.java:30)
at org.opencds.cqf.cql.elm.execution.EqualEvaluator.evaluate(EqualEvaluator.java:131)
at org.opencds.cqf.cql.elm.execution.ExpressionDefEvaluator.evaluate(ExpressionDefEvaluator.java:20)
at org.opencds.cqf.cql.elm.execution.ExpressionRefEvaluator.evaluate(ExpressionRefEvaluator.java:14)
at org.opencds.cqf.cql.elm.execution.OrEvaluator.evaluate(OrEvaluator.java:30)
at org.opencds.cqf.cql.elm.execution.OrEvaluator.evaluate(OrEvaluator.java:30)
at org.opencds.cqf.cql.elm.execution.OrEvaluator.evaluate(OrEvaluator.java:30)
at org.opencds.cqf.cql.elm.execution.OrEvaluator.evaluate(OrEvaluator.java:30)
at org.opencds.cqf.cql.elm.execution.ExpressionDefEvaluator.evaluate(ExpressionDefEvaluator.java:20)
at org.opencds.cqf.cql.elm.execution.ExpressionRefEvaluator.evaluate(ExpressionRefEvaluator.java:14)
Basically what was calling it was something like the following:
// A re-usable function to get the response code for a specific question from the occupational factors assessment.
define function Response(QuestionConcept Concept):
FHIRHelpers.ToConcept(MostRecentObservation(QuestionConcept).valueCodeableConcept)
define function MostRecentObservation(QuestionConcept Concept):
Last([Observation: QuestionConcept] O sort by issued)
The problem appears to be the fact that Last() of an empty list is null.  The function resolver tries to match argument types, but fails to match on null because it gets converted to the type represented by Object.class, which is not assignable to a more refined class.
What I wound up doing was modifying FHIRHelpers to deal with nulls as follows:
define function ToCode(coding FHIR.Coding):
if coding is null then null else System.Code {
code: coding.code.value,
system: coding.system.value,
version: coding.version.value,
display: coding.display.value
}
define function ToConcept():
null
define function ToConcept(concept FHIR.CodeableConcept):
if concept is null then null else if concept.coding is null then System.Concept {
display: concept.text.value
} else System.Concept {
codes: concept.coding C return ToCode(C),
display: concept.text.value
}
I also added the following.
define function ToDateTime(): null
define function ToTime(): null
define function ToInteger(): null
define function ToDecimal(): null
define function ToBoolean(): null
I know the first of these was needed, likely because I ran into the same problem with ToDateTime() as a result of probably this expression:
define HasOldResponse:
exists ( MostRecentQuestionObservations O where O.issued before (Today() - 6 months) )
Making these changes resolved my resolution errors, but I think there may be a better solution for these functions related to implicit null conversion.

FHIRHelpers-1.0.2.cql.txt

OK, forget all the previous.  This seems to be the resolution in the Context class:
private boolean isType(Class<?> argumentType, Class<?> operandType) {
    return operandType.isAssignableFrom(argumentType) ||
    		// handle nulls appropriately
    	   (argumentType.equals(Object.class) && !operandType.isPrimitive());
}

Since: resolveType() will only return Object.class when the value given it is null, we can basically use that as a signal that null is involved.  In cases where null is involved and the object isn't a primitive object, then null will be assignable to it, and so we can return true in that case.
I see a lot of issues in resolveFunctionRef which look like they need to be addressed.  The argument matching is imperfect because if the number of arguments is greater than the number of operands, it will still match the function reference.  I'm not sure that's intentional.  I also wonder what the behavior should be with regard to multiple conversions for classes in a hierarchy.  For example: if ToX(Model.SuperType) and ToX(Model.Type) are both defined, the resolution order is apparently indeterminate, as resolveFunctionRef will match the first or second one depending on the order in which they appear in the list.  I also wonder about what should happen with regard to implicit type conversions in this area.

Not sure how this got closed.

For the functionRef resolve, there is an STU comment #1432 that will add the resolved overload signature to the FunctionRef so that the engine doesn't have to perform that resolution at run-time. That's the root of the problem here, the engine doesn't have all the context it needs to determine the appropriate resolution (nor should it, it's a compile-time concern). The simplest workaround is to define unqiue functions, rather than overloading the same function name with different signatures. Would that work in this case?

That's the workaround I've tended to use @brynrhodes, but IIRC, FHIRHelpers uses overloaded functions -- and since CQL-to-ELM provides the FHIRHelpers it compiles against, I'm not sure if it's possible to provide a modified version of it.  Probably the best that could be done is re-implement the needed functions in a separate library and call them instead of FHIRHelpers -- but that doesn't help for any cases in which the translator applies an implicit conversion using FHIRHelpers.

BTW -- I'm really looking forward to those signatures in the FunctionRefs.  Glad that will be happening!

Included in the 1.3 CQL Ballot release.


proposed schema 1.2 changes

This includes all manifest changes from winget manifest schema 1.2 and 1.3.
This is a draft pr for review only(easier to show the intended changes between rest 1.1 and 1.2). Once reviewed, I'll send a new pr with a new winget-1.2.0.yaml to get officially merged.

Why would we add the 1.3 stuff into a 1.2 for REST? I'd be concerned about deltas a 1.3 client couldn't handle with a 1.3 schema like .zip as an installerType.

Why would we add the 1.3 stuff into a 1.2 for REST? I'd be concerned about deltas a 1.3 client couldn't handle with a 1.3 schema like .zip as an installerType.

1.3 client can't handle either 1.2 or 1.3 manifest entries in rest, because 1.3 client can only handle rest 1.1.
This change is for 1.4 client, which will handle 1.2 and 1.3 manifest entries (mapped as rest 1.2)


Add FindNonBlankWhitespace to YamlParserTest

Add the FindNonBlankWhitespace method to YamlParserTest.

Closing the issue.
Whitespace in Yaml is a String and the Strings may contain comments.


Validate standard user transferring body user group access for detail browse views

Changes in this PR

Validate standard user transferring body user group access for detail browse views:
(transferring body, series and consignment browse views)

Note: top level browse view will be dealt with similar to how search view will be dealt with.
JIRA ticket
https://national-archives.atlassian.net/browse/AYR-574

Also looks good 👍


Block codegrepper.com

@sinchang
Thank you for your interest in contributing to this project.
I need some time to decide if we should add this site to the block list or not. Please wait a moment.


fix(tracking data) - Honor data sharing

Utilizes the Data Sharing preference to determine what data is sent to the notification endpoint

Closes #3255

@pcjmfranken are you able to test this PR?  I am doing so now, anyway, but thought it would be ideal if you could verify that this fixes the problem you described.

@DMarby Mind just doing a sanity check for me on the API side? I read through it and I believe I have provided all the variable necessary to do the other parts of the notification endpoint.

@pcjmfranken are you able to test this PR? I am doing so now, anyway, but thought it would be ideal if you could verify that this fixes the problem you described.

Will check it out tomorrow when back in the office. This quick action response is greatly much appreciated!

hey @pcjmfranken we didn't want to wait on this one, but although we merged it before you got a chance to report back - please feel free to do so anyway.  if there is still more work to be done on this we can gladly open up a new PR.

@dimitropoulos I discovered yesterday that none of my mail-in replies have actually made it onto GH. Apologies for the late response. Good call merging this when you did.
Just going through all of this again, and I'm still amazed by the quick pickup and solution! Thanks again!


Remove secondary dependencies, update dependencies

Please note: at the moment RPi.GPIO errors on some platforms. This needs to be replaced by gpiozero anyways

After accepting this pull request, this project can be installed locally using
(this has to be done in a terminal which should look at the directory of the project:)
python3 -m venv .venv
source .venv\bin\activate.bat
pip3 install -r requirements.txt


update extension headers for cl_intel_device_attribute_query

Updates extension headers for cl_intel_device_attribute_query.
See: https://github.com/KhronosGroup/OpenCL-Docs/pull/657

This has been open for a while, assuming no other comments so merging.


Creating an R2 resource with a Location hint will error on subsequent runs

What happened?
When creating an R2 resource with a Location hint, the resource it created fine the first time. But in subsequent runs, Pulumi will try to replace the R2 resource. This ends with the error message:  failed to create R2 bucket: The bucket you tried to create already exists, and you own it. (10004)
If you don't have a Location hint, the resource will not be replaced in subsequent runs.
Expected Behavior
The R2 resource should not be replaced.
Steps to reproduce

Create a C# Pulumi project with the following code

using System.Collections.Generic;
using Pulumi;
using Pulumi.Cloudflare;

return await Deployment.RunAsync(() =>
{
    var apiToken = "uqtiSyipZtn6Tr2I-RbZUl3_NeZfZ_GzG_Bh3Kqd";
    var accountId = "43384b2dacb3c8d5a846f9eb53ef3aef";

    var provider = new Provider("my-cloudflare-provider", new ProviderArgs
    {
        ApiToken = apiToken
    });

    var name = "my-bucket";
    var bucket = new R2Bucket(name, new()
    {
        Name = name,
        AccountId = accountId,
        Location = "enam",
    }, new CustomResourceOptions
    {
        Provider = provider
    });

    return new Dictionary<string, object?>();
});

Update the apiToken and accountId variables
Add a reference to the Pulumi.Cloudflare NuGet, version 5.8.0
Run pulumi up. Everything will be created correctly
Run pulumi up again. The preview will say the R2 resource will be replaced. If you choose to run it anyway after the preview, the above mentioned error message will appear.

Output of pulumi about
CLI
Version      3.77.1
Go Version   go1.20.6
Go Compiler  gc

Plugins
NAME        VERSION
cloudflare  5.8.0
dotnet      unknown

Host
OS       Microsoft Windows 11 Home
Version  10.0.22621 Build 22621
Arch     x86_64

This project is written in dotnet: executable='C:\Program Files\dotnet\dotnet.exe' version='7.0.400'

Current Stack: ProgrammerAl/pulumi-cloudflare-r2-bug/dev

TYPE                                URN
pulumi:pulumi:Stack                 urn:pulumi:dev::pulumi-cloudflare-r2-bug::pulumi:pulumi:Stack::pulumi-cloudflare-r2-bug-dev
pulumi:providers:cloudflare         urn:pulumi:dev::pulumi-cloudflare-r2-bug::pulumi:providers:cloudflare::my-cloudflare-provider
cloudflare:index/r2Bucket:R2Bucket  urn:pulumi:dev::pulumi-cloudflare-r2-bug::cloudflare:index/r2Bucket:R2Bucket::my-bucket

Found no pending operations associated with dev

Backend
Name           pulumi.com
URL            https://app.pulumi.com/ProgrammerAl
User           ProgrammerAl
Organizations  ProgrammerAl

Dependencies:
NAME               VERSION
Pulumi             3.56.0
Pulumi.Cloudflare  5.8.0

Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Hi @ProgrammerAL , thanks for opening this issue. Can you confirm that the resource is recorded in state correctly – just want to confirm that it somehow wasn't corrupted.
Also, as a workaround for now, you may be able to use the ignoreChanges property (https://www.pulumi.com/docs/concepts/options/ignorechanges/).

This sounds like this upstream issue: https://github.com/cloudflare/terraform-provider-cloudflare/issues/2608
Unfortunately, it has been closed with no action. But I'm curious @ProgrammerAL - does it help if you capitalize the location when initially creating the resource? Also, could you show the exact diff that you are seeing on update?


Support FutureOn texture mapping

Is your feature request related to a problem? Please describe.
FutureOn uses a technique for pattern mapping that generates UV coords in the fragment shader to tile the texture and blend it, interpolating between two levels of detail. iTwin.js currently does not support this mode.
Describe the solution you'd like
Implement support for this mapping mode.
Describe alternatives you've considered
Continue to use UVs pregenerated by the FutureOn connector. This produces a less desirable result. It also prevents us from using different UV coords for normal mapping.
Additional context
The technique is described here.

On track for 4.0. (Still need to come up with a name).

Still on track.

Currently working the backend -- ready to make PRs for these things.


chore: a bunch of package upgrades

A general package (not CDAI, Automation or Security) of minor versions.
Jest bumped a major version to match other Jest packages. Tests still run successfully.
Changelog
M       package.json
M       packages/babel-preset-ibm-cloud-cognitive/package.json
M       packages/cli/package.json
M       packages/core/package.json
M       packages/experimental/package.json
M       packages/jest-config/package.json
M       packages/rollup-config/package.json
M       yarn.lock

Thanks @lee-chase ! My only thought here is how do you propose we remain mindful of open source clearance (https://pedigree-service.wdc1a.cirrus.ibm.com/) on production dependencies in any of the packages we update via this method?
For this PR, I can only foresee packages/experimental as being a potential issue, as @babel/runtime (I think) is the only change that would make its way into production.

Thanks @lee-chase ! My only thought here is how do you propose we remain mindful of open source clearance (https://pedigree-service.wdc1a.cirrus.ibm.com/) on production dependencies in any of the packages we update via this method?
For this PR, I can only foresee packages/experimental as being a potential issue, as @babel/runtime (I think) is the only change that would make its way into production.

Hadn't considered it @SimonFinney it would be a bizarre thing if we could not update minor versions as and when needed.
Can we raise this as a question. We also have added open source packages to experimental.

Yeah, AFAIK patch version bumps are exempt from an additional review but minor aren't - I'd love to bring it up as a discussion point during the technical sync for a wider perspective as it's regularly communicated as a requirement on our side, but in my experience, I haven't come across a situation in which there had been an issue! 🤞 With that, I normally opt not to touch production dependencies aside from Carbon until there's a good reason to do it, just in case 😅


Is there a way to take attendance...

I cannot take attendance...

see POST /:urlname/events/:id/attendance


BCPGInputStream readPacket() inconsistently calls read()

Hey!
While trying to implement verification of nested OnePassSignatures, I stumbled across a peculiarity of the BCPGInputStream.
For my use-case I need to tee out sections of the underlying byte stream to update signatures with it.
My initial idea was to inherit from the BCPGInputStream, overriding the read() method to tee the byte out.
That way, I could call readPacket() and have the packet bytes being automatically written to my signature verifier.
Once a certain packet is reached, I could disable signature updating granularly.
Initially I thought this worked, but for some reason the signatures would not validate properly.
It took a while to find the cause of the issue: For packets with 2byte length encodings, the second length byte would not be written out to my signature verifier.
The reason is that BCPGInputStream.readPacket() internally calls a mix of read() and in.read(), the latter bypassing my overwritten method.
I wonder if it would be worthwhile changing this behaviour in BC. I know this is perhaps a very exotic use-case, and I managed to work around it in PGPainless by using a custom delaying TeeInputStream to wrap the BCPGInputStream around.

This is reasonable, #1250 now merged. Thanks!


DEP: deprecate fallback to sklearn after onedal in LogReg

Description
deprecate fallback to sklearn after onedal in LogReg. There is no need for this in LogRegression estimator.

Checklist to comply with before moving PR from draft:
PR completeness and readability

[x] I have reviewed my changes thoroughly before submitting this pull request.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have updated the documentation to reflect the changes or created a separate PR with update and provided its number in the description, if necessary.
[x] Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
[ ] I have added a respective label(s) to PR if I have a permission for that.
[x] I have resolved any merge conflicts that might occur with the base branch.

Testing

[x] The unit tests pass successfully.
[x] I have run it locally and tested the changes extensively.

Performance

[ ] I have measured performance for affected algorithms using scikit-learn_bench and provided at least summary table with measured data, if performance change is expected.
[ ] I have provided justification why performance has changed or why changes are not expected.

/intelci: run

@icfaust @ethanglaser @md-shafiul-alam @avolkov-intel @Alexsandruss Dear reviewers this PR pretty ready for the review and merge. Please take a look

Could you provide some additional context? I am not familiar with the original conditional

What is the need for the removal? We have some places in oneDAL Log Reg implementation where we throw exceptions. We haven't observed such exceptions before but they potentially might happen. I think it is better to keep such fallback to ensure user will get the result computed.

What is the need for the removal? We have some places in oneDAL Log Reg implementation where we throw exceptions. We haven't observed such exceptions before but they potentially might happen. I think it is better to keep such fallback to ensure user will get the result computed.

So far I see that the logistic Regression itself throws errors on malformed inputs (not sufficient in my opinion for the fallback). However, it also depends on the lapack and logloss/blas implementations (which use GEMV) which may also throw errors. If we don't expect errors to be thrown from logloss then the PR can move forward, otherwise I agree with @avolkov-intel that the PR should be closed.

@avolkov-intel @samir-nasibli status on this discussion?

@avolkov-intel @samir-nasibli status on this discussion?

I don't see any reason why we should not go forward, we are not expecting specific failures for LogRegression.
Even more if we are expecting some failures this kind of flows should be controlled by config params. So probably for LinReg (here https://github.com/intel/scikit-learn-intelex/pull/1907) make sense add to into config_contex params sklearn_after_onedal, smth like this.

/intelci: run

What is the need for the removal? We have some places in oneDAL Log Reg implementation where we throw exceptions. We haven't observed such exceptions before but they potentially might happen. I think it is better to keep such fallback to ensure user will get the result computed.

If we have some exceptions, so it is better  to catch them and investigate. Exact cases should be properly dispatched, not after onedal backend. So this reason it make sense to remove it here. At least for Log Reg it is safe, both of CIs are green. So I strongly prefer to go with changes.

LogisticRegression is less faulty than Linear but common approach for all algorithms with runtime errors is required before making any changes. I guess PCA is applicable here too.

I will combine these changes with #1907 and bring common solution

Closing this PR. Please follow proposals on #1907


Improve handling of padding and margin

This pull request improves the handling of padding and margin.  They now set and clear the -top, -right, -bottom, and -left properties properly, and validate the value they are set to.  It also adds some tests to verify that this works.
As part of the update, the implicitSetter() function is simplified, and made more efficient (the parser function is only called once on any of the parts).  Also, unneeded empty parts are not retained in the _values array.  Finally, getParts() now allows multiple spaces as separators.

Awesome, I'll review this in the morning CST and then merge and push a new version to npm


README add example for how to pass arguments

README add example for how to pass arguments

@ThomasKuhlmann Thanks, I changed the pull request.


feat: Add snapshot testing for CLI.

Adds snapshot testing with 'cargo insta' for the CLI, to help catch future regressions in CLI output.
Fixes #134

Turned off clap's wrap_help feature, which was causing spurious test failures due to different wrapping locally vs. in CI. This feels like a worthwhile trade-off to be able to protect against regressions.

Aha! An opportunity has arisen to apply a filter. On Windows the command is omnibor.exe instead of omnibor, but that's not really an important distinction, so we can filter it out.


adding changes to rt-2.13

added the deviations:
interface_ref_config_unsupported:true
rib_wecmp: true
created the deviation:
wecmp_auto_unsupported
added var of fixedPackets with value of 1000000 to keep a fixed value packets
added cli support for wecmp, Cisco supports ucmp which the weights for each BE needs to be changed manually, added the first CLI for completeness with the expected weights.
added function VerifyISISTelemetry to verify ISIS adjecencies formed, as well as, used VerifyDUTBGPEstablished to check for bgp peer established.
configured ISIS loopback interfaces and advertised them via ISIS to be able to use ecmp on ISIS in the test.
Increased UDP packets to increased entropy which helps with the load balancing.
Increased timeout for Bgp_Neighbor_SessionState_ESTABLISHED from 1 min to 2 min.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls

Pull Request Functional Test Report for #3070 / 18ff3f6aa715b5b157aaa9dceaf2e14beca4f320
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

RT-2.13: Weighted-ECMP for IS-IS

Cisco 8000E

RT-2.13: Weighted-ECMP for IS-IS

Cisco XRd

RT-2.13: Weighted-ECMP for IS-IS

Juniper ncPTX

RT-2.13: Weighted-ECMP for IS-IS

Nokia SR Linux

RT-2.13: Weighted-ECMP for IS-IS

Openconfig Lemming

RT-2.13: Weighted-ECMP for IS-IS

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

RT-2.13: Weighted-ECMP for IS-IS

Cisco 8808

RT-2.13: Weighted-ECMP for IS-IS

Juniper PTX10008

RT-2.13: Weighted-ECMP for IS-IS

Nokia 7250 IXR-10e

RT-2.13: Weighted-ECMP for IS-IS

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls


Metric is not reset with "ResetOnReporting = true" and scheduler

I've defined all my metrics with "ResetOnReporting = true", examples like:
CounterOption = new CounterOptions
            {
                Name = "HeartBeat",
                MeasurementUnit = Unit.Events,
                ResetOnReporting = true
            }

and here is how I setup the scheduler:
var metrics = metricBuilder.Build();
var scheduler = new AppMetricsTaskScheduler(
                    TimeSpan.FromSeconds(3),
                    async () =>
                    {
                        await Task.WhenAll(metrics.ReportRunner.RunAllAsync());
                    });
scheduler.Start();

My code is running and I can see my metrics flowing, but the numbers are accumulating, the ResetOnReporting is not working in the case. Any idea I set it wrong, or anything is missed?
Thanks! Please help!

Doesn't look like there is a reporter set?


Help me with FCNPC code bug

My log:
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_Destroy
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_UseInfiniteAmmo
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_SetWeapon
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_SetVirtualWorld
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_SetInvulnerable
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_Spawn
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_GetPosition
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_IsValid
[2023-03-16T02:17:36-0300] [Error] Function not registered: FCNPC_GetPluginVersion

Plugin isn't loaded or old plugin where used.

Plugin version is 2.0.3

Show full log

*** Streamer Plugin v2.9.5 by Incognito unloaded ***
[2023-03-16T02:28:37-0300] [Info]
[2023-03-16T02:28:37-0300] [Info]  ===============================
[2023-03-16T02:28:37-0300] [Info]
[2023-03-16T02:28:37-0300] [Info]      sscanf plugin unloaded.
[2023-03-16T02:28:37-0300] [Info]
[2023-03-16T02:28:37-0300] [Info]  ===============================
[2023-03-16T02:28:37-0300] [Info]
[2023-03-16T02:28:37-0300] [Info] plugin.mysql: Unloading plugin...

Loading component Fixes.dll
Successfully loaded component Fixes (<IP_ADDRESS>9) with UID b5c615eff0329ff7
Loading component GangZones.dll
Successfully loaded component GangZones (<IP_ADDRESS>9) with UID b3351d11ee8d8056
Loading component LegacyConfig.dll
Successfully loaded component LegacyConfig (<IP_ADDRESS>9) with UID 24ef6216838f9ffc
Loading component LegacyNetwork.dll
Successfully loaded component RakNetLegacyNetwork (<IP_ADDRESS>9) with UID ea9799fd79cf8442
Loading component Menus.dll
Successfully loaded component Menus (<IP_ADDRESS>9) with UID 621e219eb97ee0b2
Loading component Objects.dll
Successfully loaded component Objects (<IP_ADDRESS>9) with UID 59f8415f72da6160
Loading component Pawn.dll
Successfully loaded component Pawn (<IP_ADDRESS>9) with UID 78906cd9f19c36a6
Loading component Pickups.dll
Successfully loaded component Pickups (<IP_ADDRESS>9) with UID cf304faa363dd971
Loading component TextDraws.dll
Successfully loaded component TextDraws (<IP_ADDRESS>9) with UID 9b5dc2b1d15c992a
Loading component TextLabels.dll
Successfully loaded component TextLabels (<IP_ADDRESS>9) with UID a0c57ea80a009742
Loading component Timers.dll
Successfully loaded component Timers (<IP_ADDRESS>9) with UID 2ad8124c5ea257a3
Loading component Unicode.dll
Successfully loaded component Unicode (<IP_ADDRESS>9) with UID 8ffb446f8353922b
Loading component Variables.dll
Successfully loaded component Variables (<IP_ADDRESS>9) with UID 75e121848bc01fa2
Loading component Vehicles.dll
Successfully loaded component Vehicles (<IP_ADDRESS>9) with UID 3f1f62ee9e22ab19
Loaded 21 component(s) from C:\Users\ROBERTINO\Desktop\Servidor-AfterLife\components
loading server.cfg generated by sampctl - do not edit this file by hand.
Parsing obsolete legacy option conncookies
Parsing obsolete legacy option output
[2023-03-16T02:35:18-0300] [Info] Loading plugin: chrono
[2023-03-16T02:35:18-0300] [Info] Loading plugin: streamer
[2023-03-16T02:35:18-0300] [Info]
*** Streamer Plugin v2.9.5 by Incognito loaded ***
[2023-03-16T02:35:18-0300] [Info] Loading plugin: mysql
[2023-03-16T02:35:18-0300] [Info]  >> plugin.mysql: R41 successfully loaded.
[2023-03-16T02:35:18-0300] [Info] Loading plugin: PawnPlus
[2023-03-16T02:35:18-0300] [Info]  PawnPlus v1.4.1 loaded
[2023-03-16T02:35:18-0300] [Info]  Created by IllidanS4
[2023-03-16T02:35:18-0300] [Info] Loading plugin: sscanf
[2023-03-16T02:35:18-0300] [Info]
[2023-03-16T02:35:18-0300] [Info]  ===============================
[2023-03-16T02:35:18-0300] [Info]
[2023-03-16T02:35:18-0300] [Info]       sscanf plugin loaded.
[2023-03-16T02:35:18-0300] [Info]
[2023-03-16T02:35:18-0300] [Info]          Version: 2.13.8
[2023-03-16T02:35:18-0300] [Info]
[2023-03-16T02:35:18-0300] [Info]    (c) 2022 Alex "Y_Less" Cole
[2023-03-16T02:35:18-0300] [Info]
[2023-03-16T02:35:18-0300] [Info]  ===============================
[2023-03-16T02:35:18-0300] [Info]
[2023-03-16T02:35:18-0300] [Error] Function not registered: FCNPC_Destroy
[2023-03-16T02:35:18-0300] [Error] Function not registered: FCNPC_UseInfiniteAmmo
[2023-03-16T02:35:18-0300] [Error] Function not registered: FCNPC_SetWeapon
[2023-03-16T02:35:18-0300] [Error] Function not registered: FCNPC_SetVirtualWorld
[2023-03-16T02:35:19-0300] [Error] Function not registered: FCNPC_SetInvulnerable
[2023-03-16T02:35:19-0300] [Error] Function not registered: FCNPC_Spawn
[2023-03-16T02:35:19-0300] [Error] Function not registered: FCNPC_GetPosition
[2023-03-16T02:35:19-0300] [Error] Function not registered: FCNPC_IsValid
[2023-03-16T02:35:19-0300] [Error] Function not registered: FCNPC_GetPluginVersion
[2023-03-16T02:35:19-0300] [Error] File or function is not found
[2023-03-16T02:35:19-0300] [Info] Legacy Network started on port 7777
[2023-03-16T02:35:19-0300] [Info] Failed to announce legacy network to open.mp list

Read the log, the plugin isn't loaded:
Loading component FCNPC.dll
	Failed to load component: it is a SA-MP plugin, put it in plugins/ folder.

Also open.mp isn't supported, FCNPC works only on SA-MP.

The log throws me this error when uploading it to the plugins folder:
[Error] Skipping legacy plugin 'FCNPC'; It requires memory hacking to run and is therefore broken on open.mp. There should be a replacement component supported by open.mp

Yes, as I have already written: open.mp isn't supported, FCNPC works only on SA-MP.

Yes, thanks :D


Batch normalization should behave differently in training and testing phase.

I notice that you involve batch normalization in both discriminator and generator. As we all know, batch normalization should behave differently in training phase and testing phase. But according to your implementation, I don't see the differences.
Looking forward to your reply.

Model() has an argument, 'is_train', which gets passed to batch_norm() to control training/test. Currently is_train is set to True by default in evaler.py when it creates a Model(). I tried is_train=False in evaler.py, which I found results in a slightly better test accuracy. So I guess the original author didn't put correct argument for evaluation.

During testing, we do not update the moving average and moving variance of batch norm layers.


npm WARN enoent ENOENT: no such file or directory, open '/circos/package.json'

Hi,
npm install --save circos

npm WARN enoent ENOENT: no such file or directory, open '/home/mictadlo/projects/circos/package.json'
npm WARN circos No description
npm WARN circos No repository field.
npm WARN circos No README data
npm WARN circos No license field.

What did I miss?
Thank you in advance.

Where did you write this command? It looks like it is in your project directory and that you didn't initialize npm. To initialize npm: npm init. If this was the case you should first learn what is npm (https://www.sitepoint.com/beginners-guide-node-package-manager/) or follow the installation guide without npm.


Adding basic gh-actions

Adding automatic builds

thanks for doing this! I definitely want to define these to use the repo-level test/build scripts, but I can take it from here to adjust further

Thanks!


Fix createSortitionHash description

Resolves #1509

Codecov Report
Patch coverage: 20.00% and project coverage change: -0.32 :warning:

Comparison is base (57c6bbd) 40.18% compared to head (c85fbaf) 39.86%.

:exclamation: Current head c85fbaf differs from pull request most recent head cf58be4. Consider uploading reports for the commit cf58be4 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1512      +/-   ##
==========================================
- Coverage   40.18%   39.86%   -0.32%
==========================================
  Files         147      147
  Lines        9651     9791     +140
==========================================
+ Hits         3878     3903      +25
- Misses       5144     5255     +111
- Partials      629      633       +4

Impacted Files
Coverage Δ

pkg/config/genesis/config.go
0.00% <ø> (ø)

pkg/core/consensus/agreement/checkcert.go
6.97% <0.00%> (ø)

...nsensus/blockgenerator/candidate/blockgenerator.go
0.00% <0.00%> (ø)

...core/consensus/blockgenerator/candidate/genesis.go
0.00% <0.00%> (ø)

...kg/core/consensus/blockgenerator/candidate/mock.go
0.00% <0.00%> (ø)

pkg/core/consensus/user/sortition.go
58.25% <ø> (ø)

pkg/core/data/block/block.go
8.97% <0.00%> (-1.48%)
:arrow_down:

pkg/core/data/block/certificate.go
0.00% <ø> (ø)

pkg/core/data/block/header.go
0.00% <0.00%> (ø)

pkg/core/data/ipc/transactions/fixtures.go
13.76% <0.00%> (-0.21%)
:arrow_down:

... and 16 more

... and 2 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Link to JetStreamListener doesn't get navigated to the proper page

Description
The link to JetStreamListener doesn't get navigated to the proper page
link: https://lib.ballerina.io/ballerinax/nats/latest#JetStreamListener gets navigated to the deleteStream in JetStreamClient.

This is fixed with the revamp.


Use vscode workspaces, default to client watcher pattern ala LSP

We have a nice custom watcher built into our server using fb-watchman, however vscode and other LSP oriented IDE clients would expect to be able to provide their own, and for this server to respond to workspace watch/file change notifications sent from the IDE client.
Thus, we need to decouple this watcher from the server such that it doesn't bring many additional dependencies, and the fb-watchman dependency itself would become an optionalDependencies entry that we can suggest to the user if they are working with an IDE that expects a server watcher, and they aren't using an LSP client compatibility layer with a built-in watcher for their IDE (which is probably common). Using a server side watcher is possible, but is against the reccomendation of the microsoft LSP docs.
We could also ship it as an additional wrapper package, of the server bundled with fb-watchman. no harm in adding more packages to the monorepo. It could also move to a contrib space

@zth do you want to weigh in here as well? it seems that LSP reccomends against server side watchers, so we can move that logic to a vscode client lib of some kind

I think this approach sounds good! I actually think it'll be fine to just remove watchman/the server side watcher entirely, and then wait for the need for a server side watcher to actually arise before building one. What do you think about that?

@zth thats what i'm hoping for, yeah! we can just reccomend that they use an lsp-oriented client implementation, like vim-lsp, emacs-lsp, sublime-lsp, etc. if we need to revive the watcher by popular demand we can in a contrib space

https://github.com/sublimelsp/LSP i actually really want to create an example extension with this, it looks very mature and would be a great example.  as for the multi language regex parser, i think we could export that as a shared module to use for this interface https://code.visualstudio.com/api/references/vscode-api#2532


Fix case and adds react-native option to jsx argument

Fixes typos in the compiler options page to be consistent with JSX page and also to avoid errors in IDE's.

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


Challenge Escape Issues

Challenge Escape Sequences in Strings has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:
var myStrr;
myStr = "FirstLine\n\\SecondLine\\\rThirdline";

Solved.


release V2.1.356

Codecov Report

Merging #328 (91c56a9) into V2.1.X (0c25959) will increase coverage by 0.66%.
The diff coverage is 72.80%.

@@            Coverage Diff             @@
##           V2.1.X     #328      +/-   ##
==========================================
+ Coverage   61.88%   62.55%   +0.66%
==========================================
  Files         224      245      +21
  Lines       19456    19930     +474
==========================================
+ Hits        12041    12467     +426
- Misses       7415     7463      +48

Impacted Files
Coverage Δ

...s/backend/components/collections/bulk_job_redis.py
75.82% <ø> (ø)

apps/node_man/handlers/debug.py
90.32% <ø> (ø)

apps/node_man/handlers/iam.py
24.43% <0.00%> (ø)

apps/node_man/iam_provider.py
21.76% <0.00%> (ø)

urls.py
100.00% <ø> (ø)

apps/node_man/handlers/permission.py
29.32% <20.00%> (ø)

apps/node_man/periodic_tasks/update_proxy_file.py
38.46% <28.30%> (+13.06%)
:arrow_up:

apps/node_man/periodic_tasks/utils.py
32.60% <32.60%> (ø)

apps/node_man/serializers/host.py
77.96% <33.33%> (-8.58%)
:arrow_down:

apps/backend/subscription/serializers.py
89.26% <35.29%> (-7.17%)
:arrow_down:

... and 60 more

Continue to review full report at Codecov.

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


regexp/syntax: add examples for flag parsing

Reading the description of grouping and flags, I'm confused about how those flags would apply to theoretical strings. An example or two would be good to demonstrate the use and placement of flags, as well as the resulting capture groups.

@kevinburke. I would like to tackle it, but have a couple of questions.
Maybe you meant the regexp package? It also lacks examples for Perl/POSIX syntax and groupings. I am asking because for me it's hard to see how to show a concise example based on regexp/syntax only. The output of regexp/syntax functions are structures indented for machine consumption.


[UI Fix] - Ripple of profile section in logged in drawer layout goes outside of the bounds of the view.

What ❓

changed the container attribute from background to foreground so the ripple stays within the view.

How to QA? 🤔

Log into the app -> open the drawer -> long press the profile row.

Story 📖
Ripple of profile section in logged in drawer layout goes outside of the bounds of the view.
See 👀

Looks like there's about 16dps of white space going around the ripple. I think the ripple should take up as much space as possible

Ok cool I'll make the fix! Thanks

@eoji  Here's the updated screenshot.


Validate support for limiting concurrent user sessions

Tracking test cases for Validation for https://github.com/rancher/rancher/issues/8639

Test plan for the concurrent user session restriction feature:
1- Enable any authentication type (Loacl, Github, Ldap, etc.) and open two or more sessions with the same user, you should be able to open different sessions with the same user.

2- Open two sessions with the same user, in the first session try to create a new environment, you should be able to see the new environment in the second sesions, and you should be able to login to the new environment and add resources (add hosts/containers/stacks/services/catalog items), any changes should be immediately reflected in the other session.

3- With the admin user navigate to `/v2-beta/settings/api.auth.restrict.concurrent.sessions` and then set the option to true, try to open one or more sessions with the admin user, you should see that when openining a new session, you will be logged out from the other sessions.

4- Open multiple sessions with the same user and then enable the restriction option in one of the sessions, the other sessions will continue to work normally and you can create resources in them until any new login happens, then the other sessions will have an invalid token.

5- Open one session and then enable the restriction and then open new session, in the first session you will not be logged out immediately, and you will still see the resources created until you refresh or request a new url or after 5 minutes.


Update windows-analytics-get-started.md

Vortex endpoint name tweak: Telemetry->Diagnostic
Clarified that KB3150513 is optional
Clarified that SSL inspection must be disabled

Thanks, Marc!


Add tag for published version of ED-318

Since ED-318 is now published, it would be useful to add a tag to this repository identifying the canonical content of that standard.  Otherwise, it will be difficult for users to differentiate between "the best that we currently have" and "what is specifically included in the standard".

How would that work in relation with the correction to be made in ED-318, see #27 ?


Use skl::SkipMap as the sidecar lookup map instead of crossbeam_skiplist::SkipMap and std::collections::BTreeMap

While crossbeam_skiplist::SkipMap and std::collections::BTreeMap are solid choices for a general-purpose ordered map, they may not be ideal for a database environment. This is primarily due to its reliance on dynamic memory allocations for each entry, leading to non-contiguous memory layouts. In a database scenario, where performance and efficient memory usage are critical, this can become a bottleneck.
The lack of contiguous memory means that pointer chasing occurs frequently during lookups, increasing cache misses and search times. This added overhead can significantly impact performance when performing large-scale or frequent queries.
In contrast, skl::SkipMap provides a more suitable approach for database environments because it stores entries in a continuous memory buffer, reducing the need for frequent allocations. This leads to better cache locality and faster search operations, making skl::SkipMap a more performant choice in cases where minimizing memory overhead and maximizing search efficiency are crucial, such as in database systems.
Hence, in 0.5, the sidecar of the write-ahead log will be changed to skl::SkipMap.

The benchmark of skl shows that crossbeam_skiplist is faster than skl, need to figure out what happens in skl implementation

Find the problem, see https://github.com/al8n/skl/issues/41

In #22, which supports using different memtables, either based on crossbeam-skiplist or skl. However, the performance regression problem on skl has not been solved.

Finished in https://github.com/al8n/orderwal/commit/f49130a2f59cf9cefc6b47fa3b31e3aae44d33fb.


adding support for RSpec expect syntax

Fixes #24

@andrewculver it would be nice to see this merged ;)

Probably we need to do the same improvement here https://github.com/bullet-train-co/magic_test/blob/a2b40cddee0605992ae69fe6c5628bd2bd7d3bbb/lib/magic_test/support.rb#L12 but I would love to see this merged. What can we do to have this into main? @andrewculver

This is pretty sweet. I love this. I took it for a test run and it works great.


Request for direct openshift support

Is there any opportunity to provide another build for openshift natively?

Hi @Sbrenthughes
Are there any plans to implement this enhancement?
Thanks
Don


OTR:GO:0008527 taste receptor activity

GO:0008527 taste receptor activity
This term is a child of "GO:0004930 G-protein coupled receptor activity"
And has the synonym "gustatory receptor"
There are a lot of fly gustatory receptor genes annotated with taste receptor activity .... but although they have a 7TM domain they are not GPCRs. PMID:19660932.
From a quick glance, most of these annotations are quite old and may reflect that fly Gr's were one thought to be GPCRs or that taste receptor activity was made a child of GPCR activity because the mammalian taste/gustatory receptors are GPCRs - a bit of both I suspect, looking at the log.
I guess there are two options:

A new term the describing non-GPCR taste receptor activity (contact chemoreception is a term often used in insects);
Placing taste receptor under the more general term "GO:0004888 transmembrane signaling receptor activity" - good for fly, but probably not good for everyone else who'll lose GPCR activity ancestry.

I'll defer to you.
Thanks,
Helen
Reported by: hattrill
Original Ticket: geneontology/ontology-requests/11171

@hattrill

@hattrill: Well, there was a resounding silence in response to my email almost a year ago.  I guess we will proceed with this plan:
"leave the current term [GO:0008527 taste receptor activity ] defined as is, move it up to 'GO:0004888 transmembrane signaling receptor activity' and create two new children terms, one that will go under GPCR  [GPCR taste receptor activity, GO:new1, is a child of "GO:0004930 G-protein coupled receptor activity"] and [contact chemoreceptor activity? or contact chemosensation receptor activity?, GO:new2]. We'd need to figure out where the current children (bitter, sweet, sour, salty, umami) would fall under these two new child terms and whether GPCR and non-GPCR children are necessary for those (example, bitter GPCR and bitter non-GPCR). "
We could leave all the children directly under 'taste receptor activity' .  It looks like bitter and sweet should have a GPCR variant.
  Yes, it's been ages.

Hi Tanya. Better late than never - I was just thinking about this the other day, so good timing! Your solution looks sound and certainly workd for me!
Helen

Proposed defs:
GPCR taste receptor activity: A G-protein coupled receptor activity that is responsible for the sense of taste.
GPCR bitter taste receptor activity: A G-protein coupled receptor activity that is responsible for the sense of bitter taste.

I'm not entirely clear on the link between 'chemoreception' and 'detection of chemical stimulus'.  What type of synonym?  Is 'chemoreception' specific to 'tasting'?  If so, then should we add the synonym to 'detection of chemical stimulus involved in sensory perception of taste' instead?  Should 'contact chemosensation' be a synonym of the same term? 'contact chemoreception'?
I'm trying to hammer out the details so that I can sit down in a mega editing session and get this all done tomorrow.
Thanks for your help.

Interesting article on evolution of taste receptors in vertebrates, and convergent evolution of sweet taste reception in hummingbirds: http://evolution.berkeley.edu/evolibrary/news/140903_hummingbirds
This would be relevant if we do a coordinate pass at PAINT annotation while working on this part of the ontology

Hi Tanya,
Sorry, I managed to miss your questions before.
I prefer "contact chemoreceptor activity", with "contact chemosensation receptor activity" as the synonym. (purely based on frequency of use)
Perhaps the definition should spell out the key distinction - that this is a non-GPCR signalling mechanism.
Def: A non-GPCR transmembrane signaling receptor activity that is responsible for contact chemoreception.
Chemoreception covers any detection of chemical stimulus - i.e. odorant (volatile) and gustatory/taste (non-volatile).
"taste receptor activity" has the synonym "gustatory receptor", which is a good thing. While we use the term "taste", it would be good to keep in mind that this covers the detection of non-volatiles such as contact chemoreception of pheromones and well as yummy things.

Added:
[Term]
+id: GO:0090681
+name: GPCR taste receptor activity
+namespace: molecular_function
+def: "A G-protein coupled receptor activity that is responsible for the sense of taste." [GOC:hat, GOC:tb]
+synonym: "G-protein coupled taste receptor activity" EXACT []
+is_a: GO:0004930 !  [GOC:hat, GOC:tb]
+synonym: "G-protein coupled receptor bitter taste receptor activity" EXACT []
+is_a: GO:0033038 ! bitter taste receptor activity
+is_a: GO:0090681 !   GPCR taste receptor activity
+[Term]
+id: GO:0090684
+name: contact chemoreceptor activity
+namespace: molecular_function
+def: "A non-GPCR transmembrane signaling receptor activity that is responsible for contact chemoreception."  GPCR taste receptor activity
name: taste receptor activity
-is_a: GO:0004930 ! G-protein coupled receptor activity
-intersection_of: GO:0004930 ! G-protein coupled receptor activity
+is_a: GO:0004888 ! transmembrane signaling receptor activity
+intersection_of: GO:0004888 ! transmembrane signaling receptor activity
name: detection of chemical stimulus
+synonym: "chemoreception" RELATED []