Tuples/Objects and Falsy errors.

Additional post on twitter
As you might've seen in some issues around here. There's a discussion about the usage of [tuples] or {objects} as the result for this operator, as well as falsy errors, like throw undefined or more common cases like throw functionThatMightReturnUndefinedOrAnError().

Here's things that this proposal will NOT solve for you.

This proposal does not aims to create a Result<T> like object class with unary operations like .unwrap(), .mapError(fn) and/or .orElse(data). This can be easily achievable by current JS code and I'm pretty sure there's tons of libraries like this one out there.

This proposal will not change the behavior of any function or its return type. The safe assignment operator (or future try expression as of #4) is to improve the caller experience and not the callee.

Return type syntaxes

I'll be using the chosen syntax at #4 for these examples.

Tuple:
Tuples are easier to destructure and follows the concept of error first destructuring.
Simple use case:
const [error, data] = try fn();

if (error) {
  console.error(error);
  return;
}

console.log(data);

Complex use case:

const [reqErr, response] = try await fetch('url')

if (reqErr) {
  console.error(reqErr);
  return;
}

const [parseErr, json] = try await response.json();

if (parseErr) {
  console.error(parseErr);
  return;
}

const [validateErr, validatedData] = try validate(json);

if (validateErr) {
  console.error(validateErr);
  return;
}

return validatedData;

Objects:
Simple use case:
const { error, data } = try fn();

if (error) {
  console.error(error);
  return;
}

console.log(data);

Complex use case:

const { error: reqErr, data: response } = try await fetch('url')

if (reqErr) {
  console.error(reqErr);
  return;
}

const maybeJson = try await response.json();

if (maybeJson.error) {
  console.error(maybeJson.error);
  return;
}

const { data: validatedData, error: validatedError } = try validate(maybeJson.data);

if (validatedError ) {
  console.error(validatedError );
  return;
}

return validatedData;

Both of them
An Object with error, data property and Symbol.iterator is also a valid solution.
Later we would need to improve the TS typings for that Symbol.iterator result to not mix error | data types on both destructure values, but since TS already did that for tuples ([1, 2, 3]) it won't be a problem.
Falsy values
Ideally, we should have some sort of wrapper against falsy errors, as in the end having falsy values wrapped are much helpful in such problems.
Besides intended use cases, no one expects to face a null inside a catch(error) block or neither will know how to handle that correctly.
Since errors are now treated as values, in both return types, we should have a way to differentiate them.
We have two main approaches:
helper property
Just like on Promise.allSettled's status property, we could have a .ok or something to tell the user that if the operation failed or not.
// obviously ok, could have as syntax like `fail` or a `status === 'err' || 'ok'`
const [ok, fnError, fnData] = try fn()
const { ok, error: fnError, data: fnData } = try fn()

if (!ok) {
  console.log(fnError)
}

const maybeResult = try fn()

if (!maybeResult.ok) {
  console.log(maybeResult.error)
}

Error wrapper
Wrapping the falsy value (0, '', null, ...) into a NullableError class or something could arguably be presented as a good feature of this proposal as well, where we reduce the amount or burden that these errors would mean into a more useful value.
For example, an application crashing with undefined and nothing more in the terminal is way worse than having an error like the following is much more useful in all meanings:
NullableError: Caught false error value
    at REPL20:1:1
    at ContextifyScript.runInThisContext (node:vm:136:12)
    at REPLServer.defaultEval (node:repl:598:22)
    at bound (node:domain:432:15)
    at REPLServer.runBound [as eval] (node:domain:443:12)
    at REPLServer.onLine (node:repl:927:10)
    at REPLServer.emit (node:events:531:35)
    at REPLServer.emit (node:domain:488:12)
    at [_onLine] [as _onLine] (node:internal/readline/interface:417:12)
    at [_line] [as _line] (node:internal/readline/interface:888:18) {
  value: ''
}

Was 'falue' a typo, or is it a portmanteau of "falsy value"?

I'd make a few arguments for an instance of some object type.

Could in the future vary the object type like AggregateError expanded Error; it is possible { error, expectedError, value } could be setup in a way to help deal with the dreaded untype catch problem in TS potentially. (either via Duck or nominal typing). Would want some input from TS team on this though to confirm.
Use of getter/setters from a shared prototype avoids extraneous allocation.

Even w/o TS the ability to extend Iterables (not tuples per JS spec nomenclature!) is more limited and requires iteration of all keys to get to the value desired, compare:
let foo = () => { /*...*/ ; return undefined; }
let obj ?= foo()
if (obj.threw) {
  // ...obj.error
}
let [err, value] ?= foo()
if (err) {
  // potentially was thrown for falsy values
}

Helpers for specific case detection would not really have API space in the iterator form.

aesthetically I prefer tuple

aesthetically I prefer tuple

That's interesting, because I find them aesthetically unpleasant. There have been arguments throughout for why they are functionally better for this purpose, so I'm not saying they are wrong, but aesthetically, they look dumb to me. Because they assume what the operation/expression will return. It's like a fun "let's just see if this works" style of setting variables. Maybe this is part of what I find disjointed about the entire proposal, is that deconstructed assignment doesn't look stable or sensible to me (from a distance).
I'm sure they'll carve all of my personal opinions about coding on my tombstone.  But as long as you bring up what we prefer aesthetically, I figured I'd chime in.

i kinda see what you tryna say, but the same apply for a object, maybe your problem are with destructuring

I think it would be safer to use an exotic object or constructor like Error or Response due the positional nature of "tuples". I don't know... SafeOperation?

extensible
easily testable/mockable
instant TS compatibility

const n: SafeOperation ?= fn();

Where:
type SafeOperation = { error, result };

Allowing:
const { error, result } = ?= fn(); // SafeOperation type/constructor infered by the operator

I think an exotic object also does make sense since JS doesn't really have tuples (just another exotic object: Array). SafeOperation In the future can extend its own properties depending on the context, e.g.: Error which may have a response property in a network operation context (not the case of the context here, but just for the sake of the example).
Also as I mentioned, would be cool to use it like a Error or Response constructor:
const n = new SafeOperation(error, result); // constructs a new SafeOperation object which error and result properties

Or
const n = new SafeOperation(fn()); // constructs a new SafeOperation resultant of the fn();

I'm drawn to the idea of wrapping non-Error thown values in a dedicated Error and returning a tuple. I think it would be a very nice way to deal with sync errors. I just can't see the TC39 committee going for it. I'm not exactly sure why but something about coercing thrown values doesn't feel JavaScript.

Even though I aesthetically prefer the object, I would go with tuples for a few reasons:

This is already a known standard (from React useState)
Tuples allow you to change the names of the error and data properties as you wish without the need of explicitly stating the original: { error: errObject, result: fetchResult } vs [errObject, fetchResult]

However, to @felippe-regazio's comment, I think it's also a possibility to think, either adding it as Result like Entries does for Maps and Sets, but instead of retuning the object, it returns a tuple.

Exactly, I also think that tuples could be a nicer option than using object destructuring because this lets people re-assign value names, thus allowing the following pattern to emerge:
const [authorsError, authors] ?= await fetch("/authors")

if (authorsError) { /* handle error */ }

const [booksError, books] ?= await fetch("/books")

if (booksError) { /* handle error */ }

const { error: authorsError, result: authors } ?= await fetch('/authors');

const { error: booksError, result: books } ?= await fetch('/books');

One thing I keep thinking about is this existing pattern for async error handling. Something like this for synchronous errors would be really nice.
const books = await fetch("/authors").catch((error) => {
  /* handle error */
})

await fetch("/authors").catch((error) => {
The problem with the above pattern is that it mixes the success and rejection into the same variable, making it hard to differentiate afterwards in case a default value could not be provided.

const { error: authorsError, result: authors } ?= await fetch('/authors');

const { error: booksError, result: books } ?= await fetch('/books');

Yeah that's my point number 2, we have to repeat the original names on both objects to change the names whereas with tuples we could use:
const [authorsError, authors] ?= await fetch('/authors');
const [booksError, books] ?= await fetch('/books');

const [reqErr, response] = try await fetch(url);

This is beautiful syntax 😄❤
It's much more readable and self-explanatory than the cryptic two-for-one ?= operator.

const [response, error] = try await fetch(url);

This syntax is optimal as it aligns well with the throw expression proposal, which is currently in Stage 2. The proposed syntax is self-explanatory, making error handling more concise and readable.

await fetch("/authors").catch((error) => {
The problem with the above pattern is that it mixes the success and rejection into the same variable, making it hard to differentiate afterwards in case a default value could not be provided.

I work with async functions a lot and if I can't return a default value in a catch statement then I either throw an error or return undefined. If I return undefined, I can just check for that with an if statement and gracefully exit the parent function. Usually the catch is where I handle the error and if I can't handle it there I probably can't handle it anywhere. So it's essentially the same thing.
It's doubtful that I would use this for most async functions since the async...await syntax usually handles that beautifully.

Throwing undefined or null, although it can be considered anti pattern, can and will happen.

The latter is not an option; if a value is thrown, that's the error value, full stop.

I think if we did that it should be [error,data,ok]. But the error value needs to be returned exactly as-is.
The only other option would be to return a TryError with the error as a property whenever an error gets thrown. The TryError stacktrace would be to the point of the try keyword, and the error property would contain whatever value was thrown by the code (usually an Error instance).

@mindplay-dk
Actually it makes sense to throw an error if try expression caught nullish (or falsy) value.
But with non-Error could be issues, because some errors could be originated in another realms,
and the err instanceof Error returns a false negative result.
Additionally we can get an issue with test-runners: https://github.com/jestjs/jest/issues/2549

Actually it makes sense to throw an error if try expression caught nullish (or falsy) value.

 It's intended for catching errors.
This would make no sense to me.

But with non-Error could be issues, because some errors could be originated in another realms, and the err instanceof Error returns a false negative result.

What I'm suggesting is, the try operator would convert a non-Error into an Error subtype, such that err instanceof Error would always return true - or rather, so you wouldn't need to type-check it in the first place, because it'll always be an instance of Error.

Additionally we can get an issue with test-runners: jestjs/jest#2549

What issue? (what you linked to is something about type-checking arrays?)
Test runners wouldn't need to use the try operator, they can use it if it simplifies things for them - a regular try statement (and manual type-checking) is of course still an option. I'm not suggesting any change to the try statement.

@mindplay-dk

Actually it makes sense to throw an error if try expression caught nullish (or falsy) value.

 It's intended for catching errors.

oh! My bad, I ment to return the one in this case.

What I'm suggesting is, the try operator would convert a non-Error into an Error subtype, such that err instanceof Error would always return true - or rather, so you wouldn't need to type-check it in the first place, because it'll always be an instance of Error.

err instanceof Error can return false negative result. Meaning it can return false for error, if this error has been originated in another REALM (iframe or nodejs vm)
We can wait for the Error.isError proposal to resolve this.
However it is better to affect the flow as less as possible, in this meaning to return explicit discriminator is the most robust option.
To wrap only nullish values -- the second one, to wrap the falsy values -- third and to wrap everything that is not an error -- the last one.
To wrap falsy values could be safer because it will allow to check if (error), when wrapping only nulish values requires at least weak comparision: if (error != null)

Additionally we can get an issue with test-runners: https://github.com/jestjs/jest/issues/2549

What issue? (what you linked to is something about type-checking arrays?)

Oh, the #2549 is too large ) But it is the root one. You can consider smaller
https://github.com/jestjs/jest/issues/15269

I think it has to be all or nothing. Either we always return the exact error value, or we always return it wrapped in a TryError (or whatever it gets called). Otherwise it would be far simpler to just use a normal try statement and grab the error value in the catch.

@Arlen22

... or we always return it wrapped in a TryError

Actually it is an interesting option. )
But there is a problem:
const [error, value] = try await doSomething();

if (error != null) {
  console.warn('We got an error trying to doSomething");
  throw error;
}

We can get our original error wrapped in too many layers. So to avoid it we have to do something like that:
const [error, value] = try await doSomething();

if (error != null) {
  console.warn('We got an error trying to doSomething");
  throw error.originalError;
}

Or we should prevent this with "join" the TryError-s:
class TryError extends Error {
  constructor(originalError) {
    super('TryError');
    while (originalError instanceof TryError) {
      orignalError = originalError.originalError
    }
    this.originalError = originalError;
  }
}

Error constructor has an options argument where you can pass an object with cause property that is the original error object.

Error constructor has an options argument where you can pass an object with cause property that is the original error object.

yes, it has.
But actually, the cause is not only an original error. It also could be any other data.
As instance MDN also offers to pass some structured data:
Providing structured data as the error cause
But the originalError is not an optional and it is exactly what has been thrown and wrapped to be safely returned.

The first lines of the Error: cause MDN page you linked to:

The cause data property of an Error instance indicates the specific original cause of the error.
It is used when catching and re-throwing an error with a more-specific or useful error message in order to still have access to the original error.

It's primary intended use is specifically wrapping a thrown value in an Error object.
It can also be used for adding additional custom context to an Error but that doesn't invalidate it as the correct property for wrapping a throw value.

I've been playing with the type for a while and have been liking it.
type Result<T> = [ok: true, error: null, data: T] | [ok: false, error: unknown];

I know most of people here is not even trying the pasted examples or only trying in sample codes, but the above seemed very ugly and unpleased to work in my mind but after trying it a bit I have to say that its awesome:
const [ok, cause, data] = await fn()

if (!ok) {
  Sentry.captureException(cause)
  throw httpErrors.badRequest('Error!')
}

// continue service code.

It does not let error handling implicit ok variable. It does not breaks when undefined/null is thrown (ok) variable.
What do you guys think?
(Please try testing it out for about 1-2 days before actually having a opinion, how many JS features you didn't have a good first impression but ended up actually liking it after using it?)

The first lines of the Error: cause MDN page you linked to:

The cause data property of an Error instance indicates the specific original cause of the error.
It is used when catching and re-throwing an error with a more-specific or useful error message in order to still have access to the original error.

It's primary intended use is specifically wrapping a thrown value in an Error object.
It can also be used for adding additional custom context to an Error but that doesn't invalidate it as the correct property for wrapping a throw value.

@garretmh, @crazytonyi
ok, you win ) Let it be cause. I hope we will not need to wrap errors at all. The explicit discriminator is better

@arthurfiorette

It does not let error handling implicit ok variable.

Only for Typescript. For JS the issue with implicit error ignoring is still present.

how,?

For me, this is not implicit at all. [,, is screaming that something was done wrong. Again, this is not implicit also because there's the try operator.

For me, this is not implicit at all. [,, is screaming that something was done wrong. Again, this is not implicit also because there's the try operator.

yes, the old discussion.
Ok, let's look on the following case:
const [ok, error, fileName] = try await getFilename();

fs.writeFileSync(`__dirname/${fileName}`, 'Hello World');

Are something screaming here? Actually TS also accepts this broken code

let filename

try {
  filename = await getFilename()
} catch(error) {
  console.log(error)
}

fs.writeFileSync(`__dirname/${fileName}`, 'Hello World');

Will also pass on TS checks but a lot of linters have rules to prevent this problem. Even though only string, number, boolean + (objects with symbol to string tag) should work fine when being concatenated, however TS accepts anything:
let filename /* undefined */

if (conditionThatNeverMets) {
  filename = 'something'
}

fs.writeFileSync(`__dirname/${fileName}`, 'Hello World');

I see that the above is a problem because fileName can be undefined but this is an instinct problem in JS land that can happen in a lot of different places as well, its correlated with the bad usage of try expressions but not only caused by it. And I don't think we have an actual solution to that, in the same way as if someone writes a try/finally it wont caught errors even though there's a try keyword there. Maybe its a problem for a linter to solve, the same way:
const [ok, error, fileName] = try await getFilename();

if (!ok) {
  console.log(filename.toString())
}

Should be a problem for TS to solve (which is somewhat a linter os steroids xd)

@arthurfiorette
yes, there are a lot of way to shoot yourself ...
But with try catch the code looks like the following:
try {
  const fileName = getFilename();
  fs.writeFileSync(`__dirname/${fileName}`, 'Hello World');
} catch (err) {
  console.error(err);
}

and this a most expected way to write the code.

Not necessarily, the main reason for why this proposal was created is for this super common usecase:

let fileName;

try {
  fileName = getFilename();
} catch (err) {
  console.error(err);
}

// do a lot more stuff (and a lot more possible try/catch/finally)

fs.writeFileSync(`__dirname/${fileName}`, 'Hello World');

Where you need more than 1 try catches (so you can distinguish where the error is coming from) and maybe to write more code after the handlings and only then do what you want to do with the original file.
I don't think this proposal is aiming to replace try blocks the same way let replaced var usage almost everywhere. Your example above is a fine use case to be kept with try catch blocks.
For example, this below code (thanks chatgpt) is very common inside business code:
function processData(data: string) {
  try {
    console.log("Outer try block");

    // Simulate a potential outer error
    if (!data) throw new Error("Outer Error: No data provided");

    try {
      console.log("Middle try block");

      // Simulate a parsing error
      const parsedData = JSON.parse(data);
      console.log("Parsed Data:", parsedData);

      try {
        console.log("Inner try block");

        // Simulate a validation error
        if (!parsedData.valid) throw new Error("Inner Error: Invalid data");

        console.log("Data is valid:", parsedData);
      } catch (innerError) {
        console.error("Caught in inner catch:", innerError.message);
      }

    } catch (middleError) {
      console.error("Caught in middle catch:", middleError.message);
    }

  } catch (outerError) {
    console.error("Caught in outer catch:", outerError.message);
  }
}

where either you use multiple nested catches to handle different errors or you only use one and isn't able to distinguish where specifically the error was being thrown.
And using this approach gives a much more readable verison: (thanks chatgpt again)
function processData2(data: string) {
  console.log('First step block');

  // Simulate a potential outer error
  if (!data) throw new Error('Outer Error: No data provided');

  console.log('Middle try block');

  const [ok, error, parsedData] = try JSON.parse(data);

  if (!ok) {
    console.error('Caught in middle catch:', error.message);
    return;
  }

  console.log('Parsed Data:', parsedData);

  // Simulate a validation error
  const [ok, innerError, valid] = try validateData(parsedData);

  if (!valid) {
    console.error('Caught in inner catch:', innerError.message);
    return;
  }

  console.log('Data is valid:', parsedData);
}

type Result<T> = [ok: true, error: null, data: T] | [ok: false, error: unknown];
What do you guys think?

@arthurfiorette this still leaves a bad taste in my mouth - I know the ok flag isn't exactly duplicating error, but it's very close, except for the ugly marginal edge case where some evil genius throws a null or undefined.
I just don't like the idea of adding complexity to design/optimize for (or even cope with) an anti-pattern - remembering the exact order of those 3 return values is going to be the sort of thing I'd have to look up on a daily basis, I think. 😔
I still think it would make more sense to wrap non-Error values in an Error instance. The engine knows at the throw-statement what's being thrown - it can capture a stack-trace internally (which it does already for uncaught errors) and provide it via the Error-instance to the try-operator, which would be an improvement overall, and probably something test-frameworks would want to use, so they can provide a stack-trace for errors where currently no stack-trace is captured.
@DScheglov based on your comment here I think you misunderstood me the second time again - I am not suggesting every error be wrapped. Only non-Error values would be wrapped, in an Error-subtype with a value property. You won't have nested errors. You will have just have an Error where previously you had a non-Error value. (You also won't have any change to regular try/catch statements.)

@arthurfiorette
the exceptions are expected to be used in the way to get the proccessData function as follows:
function processData(data: string) {
  try {
    validateInput(data);
    const parsedData = parseJson(data);
    return validateData(parsedData);
  } catch (err) {
    if (handleDataProcessingError(err)) return false;
    throw err;
  }
}

See in Playground
Actually your refactored with try-expression code compiles with errors:
console.error('Caught in middle catch:', error.message);
//                                       ^^^^^  'error' is of type 'unknown'.

 console.error('Caught in inner catch:', innerError.message);
 //                                      ^^^^^^^^^^ 'innerError' is of type 'unknown'.

And worning:
  const [ok, innerError, valid] = try validateData(parsedData);
  //     ^^ 'ok' is declared but its value is never read.

see in Playground
In the real word knowning where the error is caught means nothing. More then, trying to conclude any decision basing only on the place of caught could be dangerous -- you examples shows that. TS founds the error! JS doesn't.
More then, because we have unknown type for the error, we don't have a worning, that error is possibly undefined.
Let's guess, the validateData in some moment will return false instead of throwing an exception -- the code becomes broken

@mindplay-dk

@DScheglov based on your comment https://github.com/arthurfiorette/proposal-safe-assignment-operator/issues/30#issuecomment-2371853843 I think you misunderstood me the second time again - I am not suggesting every error be wrapped. Only non-Error values would be wrapped, in an Error-subtype with a value property. You won't have nested errors. You will have just have an Error where previously you had a non-Error value. (You also won't have any change to regular try/catch statements.)

I never told that you suggested to wrap everything we caught. ) It did @Arlen22 in the comment#2371679490

I still think it would make more sense to wrap non-Error values in an Error instance. The engine knows at the throw-statement what's being thrown - it can capture a stack-trace internally (which it does already for uncaught errors) and provide it via the Error-instance to the try-operator, which would be an improvement overall, and probably something test-frameworks would want to use, so they can provide a stack-trace for errors where currently no stack-trace is captured.

Let's guess we have some evel framework, where we call a framework api inside of our code, and the framework calls our code.
This framework expected to catch a recieved Promise or null, or undefined ... -- wrapping everything in this case will automatically results:

we cannot use try-expression with the framework
we cannot use the framework because it throws non-error values.

Yes, it is an anti-pattern, but it is allowed by ES and TS. It is better to find the solution that doesn't breaks an existing code.

@arthurfiorette
even the JSON.parse can throw not-own error:
const none = {
  toString() {
    throw new ReferenceError('Attemt to resolve none as a string')
  },
};

console.log(
  JSON.parse(none as any)
);

Playground
So, never, never, and one more time never rely on the place where you caught the exception.
There is another entity that allows us to rely on the "place" where it is received.
It is a return value.
Meet Rust's Result<T, E>.

@DScheglov it still sounds like you don't understand what I'm suggesting.

Let's guess we have some evel framework, where we call a framework api inside of our code, and the framework calls our code.
This framework expected to catch a thrown by its api Promise or null, or undefined ... -- wrapping non-Errors in this case will automatically results:

we cannot use try-expression with the framework
we cannot use the framework because it throws non-error values.

Neither of those things would happen.
If a non-Error value is thrown, it isn't wrapped at the throw site - that would be a breaking change.
It would get wrapped at the try expression site, immediately before it gets returned - so this only affects the try expression. From there, if you need to rethrow, you could choose to throw the value again, or re-throw the Error-subtype wrapper.
(Either way, it would be an extremely strange framework or error-handler that only expects and handles non-Error values.)

I'm not really a fan of the "ok" syntax; it makes the code unnecessarily verbose for handling edge cases. I would prefer using the try expression as a day-to-day feature because it has a more friendly syntax than having to destructure three values.
When discussing the order of values, I believe having the result first is more practical. In everyday work, a result that equals null typically indicates something went wrong, which is sufficient information to handle the case (yes, it means discarding the error, but hey, I'm talking about how people will use the feature, not what it should be 😜).  So the [,,result] syntax will be seen very often I'm affraid, like people handling errors only by writing console.log in their catch clause (yes, I've seen that a lot, in many companies). I mean, you could try to force them to use the error by placing it as a first value in the returned tuple, but we all know what they'll do 👀
I like to compare this feature to promises and async code. An expression could either succeed and return a value or throw an error, similar to how promises work with (resolve, reject). Having only [result, error] is much more explicit and familiar for those encountering this feature for the first time.
Also, for example:
let result;
try {
    result = await fetch("https://api.example.com");
} catch (error) {
    return toast("Something went wrong");
}
// Do something with the result

This could be simplified to:
const [result] = try await fetch("https://api.example.com");
if (!result) return toast("Something went wrong");
// Do something with the result

The second solution:

Is much shorter, which usually means more maintainable, more readable, and thus less prone to logic errors, making it more productive.
Avoids declaring multiple scopes and nesting them.
Provides a way to discard the error value if we don't care about its actual content.

I'm also convinced that the error should be the exact same as the error thrown by the try await clause. The try await should be a simple, transparent JavaScript feature that doesn't alter the behavior or the API of what was thrown. Don't let the feature do more than what it is intended for.
Though, I do agree that this code makes JavaScript look a bit like Go! 😄

@mindplay-dk
I got you correctly
_try is kind of polyfill for try-expression and it looks like as follows:
export const _try: {
  (fn: () => never): Failure;
  (fn: () => Promise<never>): Promise<Failure>;
  <T>(fn: () => Promise<T>): Promise<ResultTuple<T>>;
  <T>(fn: () => T): ResultTuple<T>;
} = <T, >(fn: () => T | Promise<T>): any => {
  if (typeof fn !== 'function') {
    return failure(new TypeError('Parameter fn is not a function', { cause: fn }));
  }

  try {
    const result = fn();
    return isPromise(result)
      ? result.then(success, failure)
      : success(result);
  } catch (error) {
    return failure(error);
  }
};

Where the success and failure are defined as:
export type Failure = readonly [error: Error];
export type Success<T> = readonly [error: undefined, value: T];
export type ResultTuple<T> = Failure | Success<T>;

const success = <T, >(value: T): Success<T> => [undefined, value] as const;
const failure = (err: unknown): Failure => [TryError.ensureError(err)] as const;

And finally the TryError class:
class TryError extends Error {
  static ensureError(value: unknown): Error {
    return Error.isError(value) ? value : new TryError(value);
  }

  constructor(public readonly cause: unknown) {
    super('Non-Error has been thrown.', { cause })
  }
}

See Playground

It would get wrapped at the try expression site, immediately before it gets returned - so this only affects the try expression. From there, if you need to rethrow, you could choose to throw the value again, or re-throw the Error-subtype wrapper.

So, the pointed above solution affects already existing code
Let's suppose we have some framework, that allows us to write the following code:
type UseFn = <T>(fn: () => Promise<T>) => T;

const HelloComponent = (use: UseFn) => {
  const name = use(() => Promise.resolve('World'));

  return `<h1>${name}</h1>`
}

To render the component HelloComponent we have a function render:
async function render(
  fnComponent: (useFn: UseFn) => string,
) {
  let useCounter = 0;
  const useValues: unknown[] = [];

  function use<T>(fn: () => Promise<T>): T {
    if (useValues.length <= useCounter) throw fn();
    return useValues[useCounter++] as T;
  }

  const run = async () => {
    try {
      useCounter = 0;
      return fnComponent(use);
    } catch (err) {
      if (isPromise(err)) {
        useValues[useCounter] = await err;
        return run();
      }
      throw err;
    }
  }

  return run();
}

And rendering the Component:
render(HelloComponent).then(console.log);

Now, let's change the const name = use(... to const name = try use(...:
const HelloComponent = (use: UseFn) => {
  const [error, name] = _try(
    () => use(() => Promise.resolve('World'))
  );

  if (error) {
    console.log('We got an error', error);
    throw error;
  }

  return `<h1>${name}</h1>`
}

We will get an error.
Just because we are wrapped the Promise with error.
Full Example
Why am I talking about this affects an existing code.
Fast of all the framework mantainers will receive a lot of issues, that it is not possible to use new syntax with the framework,
and what will they do? Exactly they will add the correspondent case in the catch block in render function:
    } catch (err) {
+      if (err instanceof Error && isPromise(err.cause)) {
+       useValues[useCounter] = await err.cause;
+        return run();
+      }
      if (isPromise(err)) {

So, despite we are using new syntax only in new code, we have to update an existing as well.

@TheUniqueMathemagician
it looks like you need another kind of expression:
const response = try? await fetch(...);
// or
const response = try! await fetch(...);

if (response == null) ...

In general, to ignore error -- is an anti-pattern, so it is not a good idea to encourage this by introducing new "concise" syntax.

@arthurfiorette The example you gave can very easily be rewritten in a cleaner way (since errors can't escape the catch block unless rethrown):

function processData(data: string) {
  try {
    console.log("Outer try block");

    // Simulate a potential outer error
    if (!data) throw new Error("Outer Error: No data provided");

    try {
      console.log("Middle try block");

      // Simulate a parsing error
      const parsedData = JSON.parse(data);
      console.log("Parsed Data:", parsedData);

      try {
        console.log("Inner try block");

        // Simulate a validation error
        if (!parsedData.valid) throw new Error("Inner Error: Invalid data");

        console.log("Data is valid:", parsedData);
      } catch (innerError) {
        console.error("Caught in inner catch:", innerError.message);
      }

    } catch (middleError) {
      console.error("Caught in middle catch:", middleError.message);
    }

  } catch (outerError) {
    console.error("Caught in outer catch:", outerError.message);
  }
}

Becomes:
function processData(data: string) {
  try {
    console.log("Outer try block");

    // Simulate a potential outer error
    if (!data) throw new Error("Outer Error: No data provided");
  } catch (outerError) {
    console.error("Caught in outer catch:", outerError.message);
  }

  try {
    console.log("Middle try block");

    // Simulate a parsing error
    const parsedData = JSON.parse(data);
    console.log("Parsed Data:", parsedData);
  } catch (middleError) {
    console.error("Caught in middle catch:", middleError.message);
  }

  try {
    console.log("Inner try block");

    // Simulate a validation error
    if (!parsedData.valid) throw new Error("Inner Error: Invalid data");

    console.log("Data is valid:", parsedData);
  } catch (innerError) {
    console.error("Caught in inner catch:", innerError.message);
  }
}

Plus the processData2() version you gave as example doesn't match the behavior of the processData(), so here's processData2() but with try .. catch:
function processData2(data: string) {
  console.log('First step block');

  // Simulate a potential outer error
  if (!data) throw new Error('Outer Error: No data provided');

  console.log('Middle try block');

  let parsedData; // the `let` can become `const` if the [write-once const proposal](https://github.com/nzakas/proposal-write-once-const/) is accepted
  try {
    parsedData = JSON.parse(data);
  } catch (error) {
    console.error('Caught in middle catch:', error.message);
    return;
  }

  console.log('Parsed Data:', parsedData);

  // Simulate a validation error
  try {
    const valid = validateData(parsedData);
    if (!valid) throw new Error("Inner Error: Invalid data");
  } catch (innerError) {
    console.error('Caught in inner catch:', innerError.message);
    return;
  }

  console.log('Data is valid:', parsedData);
}

@zaygraveyard
In your first snippet, the parsedData is not accessible in the next try block.
This is exactly a case for the try expression -- to achieve a "flat" flow without
using a let declaration (as in your second snippet), mostly to get a single point
where the variable's value is defined.

@DScheglov Thanks for catching that small oversight, its fixed now 😄

@DScheglov And as I mentioned in the code snippet, the let can be replaced by const if/when write-once const proposal is accepted.
Can you explain what you mean by a "flat" flow?

@zaygraveyard

@DScheglov And as I mentioned in the code snippet, the let can be replaced by const if/when write-once const proposal is accepted.
Can you explain what you mean by a "flat" flow?

"Flat" -- without nested "try"-s
About the write-once const proposal: it is on the "Stage: -1".
Let's consider it at least on the "Stage: 0".
We also have a "do"-expression proposal, it is in the Stage 1.

I'm not arguing against the do-expression proposal nor against this one.
I'm just trying to weigh the pros/cons or cost/benefit of this proposal.
The write-once const proposal is much more limited in scope and I believe has more benefit.
It's still unclear to me what exactly is the problem this proposal is trying to solve (I asked on multiple occasion but got no answer)...
A list of use cases showing problems and how this proposal solves them would be grand 😄

@zaygraveyard

It's still unclear to me what exactly is the problem this proposal is trying to solve (I asked on multiple occasion but got no answer)...

That’s a great observation.
What I’m noticing is that some developers prefer to have a default nullish value in case of an unsuccessful computation. Typically, these developers also favor the data-first tuple approach.
The popularity of such approach we can see on the how many downloads the nice-try library has: ~13.5M/week:
const [data] = try JSON.parse(input); // data undefined or parsed json

So, it is definitelly the case, that must be considered for the proposal.
The second one is pointed by @arthurfiorette's comment#2374175054:

get rid of nested try-s without using the let declarations.

The most popular lib for that (that I found) is safely-try with ~9k/week downloads.
But the safely-try doesn't correctly support falsy values thrown as exceptions, so its usage can lead to bugs.
The difference between these two cases: 1.5k times!!!
The reason for this difference could be explained by the findings from a survey conducted by the TypeScript team regarding exception usage:

Generally speaking, JS code goes into exactly two paths: the happy case, or the "something went wrong" case, in which meaningful introspection as exactly what went wrong is quite rare.

Source:  #13219 (commnet)
cc: @arthurfiorette

@DScheglov
I agree that "default nullish value in case of an unsuccessful computation" can be useful in some cases (I have multiple those most projects), but it feels to me like it should always be explicitly clear that the error is being ignored (which this proposal doesn't yet enforce).
As for the "get rid of nested try-s without using the let declarations", the write-once const proposal also solve that problem and with a much more limited scope.
BTW, I'm all for the "do"-expression proposal and would love to see it added to JS 😄

@zaygraveyard

I agree that "default nullish value in case of an unsuccessful computation" can be useful in some cases (I have multiple those most projects), but it feels to me like it should always be explicitly clear that the error is being ignored (which this proposal doesn't yet enforce).

100%! Joining to this. But the Champion of the proposal is disagree with that even error-first approach
const [, data] = try JSON.parse(input);

is an implicit error ignoring.
So, it looks very debatable issue.

As for the "get rid of nested try-s without using the let declarations", the write-once const proposal also solve that problem and with a much more limited scope.

I'm not sure about that. I'd prefer to avoid discussing the "write-once const" here, but if this proposal is implemented, we might end up with one place where the variable is declared and multiple places where it is assigned a value, which could make the code harder to read and understand. In this sense, let seems more honest.

BTW, I'm all for the "do"-expression proposal and would love to see it added to JS

I guess it makes sense to extend the "do"-expression proposal with adding a catch block after the do-block:
const data = do { Parse.json(input) } catch { null };

It looks much more concise then:
const data = do {
  try { Parse.json(input) } catch { null }
}

@DScheglov
I also agree that we should avoid discussing other proposals here, but we also can't discuss this proposal in isolation when other proposals might solve the same problems. 😅
But just to clarify, the "write-once const" proposal would only allow detaching the initialization of a const from its declaration, while still forbidding any assignment to it.

@arthurfiorette
what do you think about the following approach:
const [caught, result] = try mayThrow();

if (caught) {
  console.error(caught.error);
  throw caught; // or throw caught.error;
}

handleTheResult(result);

Where the caught implements the following interface:
interface Caught {
  readonly error: unknown;
  readonly [Symbol.exception]: unknown;
}

and the Symbol.exception is a new well-known symbol, that must be handled by throw and Promise in the following way:
Let throw value and "Symbol.exception" is in the value, then throw the value[Symbol.exception], otherwise throw value.
And for promise:
if rejected reason has Symbol.exception then rejected raeson is reason[Symbol.exception].
The approach covers unknown type for errors, covers falsy errors, making if (caught) safe, and avoids undesired wrapping of error on the manual its propagation.

A symbol protocol is imo a nonstarter and not a good idea, especially since a getter for Symbol.exception could itself throw.

@ljharb
actually, we can start without Symbol.exception and later add an internal slot [[exception]] to avoid throwing on the getting the property value

@DScheglov to be clearer, i think throw x doing anything other than throwing x is a bad idea and a nonstarter.

@DScheglov to be clearer, i think throw x doing anything other than throwing x is a bad idea and a nonstarter.

@ljharb
So, do you think a tuple or an object with an explicit discriminator are the only options we have for the try expression return?

Yes.

I was playing with [ok: boolean, error?: unknown, data?: T] format and its very pleasant to use.

for not mutating the original thrown error


"error" in training - AttributeError: 'CastOutputToFloat' object has no attribute 'weight', RuntimeError: Only Tensors of floating point and complex dtype can require gradients

WSL2 Ubuntu, new install, I get the following error after it downloads the weights and tries to train.
Sorry I can't give more details, but I'm really not sure what's going on.
Number of samples: 534
Traceback (most recent call last):
File "/home/ckg/.local/lib/python3.10/site-packages/gradio/routes.py", line 394, in run_predict
output = await app.get_blocks().process_api(
File "/home/ckg/.local/lib/python3.10/site-packages/gradio/blocks.py", line 1075, in process_api
result = await self.call_function(
File "/home/ckg/.local/lib/python3.10/site-packages/gradio/blocks.py", line 884, in call_function
prediction = await anyio.to_thread.run_sync(
File "/home/ckg/.local/lib/python3.10/site-packages/anyio/to_thread.py", line 31, in run_sync
return await get_asynclib().run_sync_in_worker_thread(
File "/home/ckg/.local/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 937, in run_sync_in_worker_thread
return await future
File "/home/ckg/.local/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 867, in run
result = context.run(func, *args)
File "/home/ckg/.local/lib/python3.10/site-packages/gradio/helpers.py", line 587, in tracked_fn
response = fn(*args)
File "/home/ckg/github/simple-llama-finetuner/main.py", line 164, in tokenize_and_train
model = peft.prepare_model_for_int8_training(model)
File "/home/ckg/.local/lib/python3.10/site-packages/peft/utils/other.py", line 72, in prepare_model_for_int8_training
File "/home/ckg/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1614, in getattr
raise AttributeError("'{}' object has no attribute '{}'".format(
AttributeError: 'CastOutputToFloat' object has no attribute 'weight'

What hardware are you running on? Any other console traceback?

Windows 11 (but in WSL2), otherwise working WSL install for diffusers and GPT-Neo finetuning (but, in their own environments)
A 5900x, 32GB ram, 100GB swap for WSL2 (I needed a lot for GPT-Neo stuff), and a 4090 for the gpu.
Nothing else to the traceback, everything else in the console is, what I think is, just normal stuff before
(llama-finetuner) ckg@Ryzen9:~/github/simple-llama-finetuner$ python main.py
===================================BUG REPORT===================================
Welcome to bitsandbytes. For bug reports, please submit your error trace to: https://github.com/TimDettmers/bitsandbytes/issues
CUDA SETUP: CUDA runtime path found: /home/ckg/anaconda3/envs/llama-finetuner/lib/libcudart.so
CUDA SETUP: Highest compute capability among GPUs detected: 8.9
CUDA SETUP: Detected CUDA version 117
CUDA SETUP: Loading binary /home/ckg/.local/lib/python3.10/site-packages/bitsandbytes/libbitsandbytes_cuda117.so...
Running on local URL:  http://<IP_ADDRESS>:7860
To create a public link, set share=True in launch().
Loading base model...
Loading base model...
The tokenizer class you load from this checkpoint is not the same type as the class this function is called from. It may result in unexpected tokenization.
The tokenizer class you load from this checkpoint is 'LLaMATokenizer'.
The class this function is called from is 'LlamaTokenizer'.
The tokenizer class you load from this checkpoint is not the same type as the class this function is called from. It may result in unexpected tokenization.
The tokenizer class you load from this checkpoint is 'LLaMATokenizer'.
The class this function is called from is 'LlamaTokenizer'.

Also, quick question that doesn't need its own issue. What's the significance of the 2 empty spaces in between each entry in the training data?
I had finetuned GPT-Neo a bunch, and I'm trying to wrap my head around the differences. And I haven't been able to find out if finetuning LLaMA uses <|endoftext|> tokens or not, or if there's another way to do it. Is that what the two empty lines are adding?

Also, quick question that doesn't need its own issue. What's the significance of the 2 empty spaces in between each entry in the training data?

If you want to have newlines or empty lines in each of your samples, it helps. It's just the easiest way to format samples.

I just rewrote the whole thing. Still seeing the issue?


All filenames with a dot need to add .html at the end

In the original search.js, these lines:
{ category: "infix", value: "..", url: "/routine/.." }
,
{ category: "Routine", value: "...", url: "/routine/..." }

added .html at the end. That URL is not really valid, and leads to unexpected pages.

Mm, documentable does not add .html to any file. Why . and .. cannot be redirected to ..html and ...html as the other pages?


[Event Request] Table 38 "Purchase Header" - OnBeforeInitRecord

Hello. In table 38 Purchase Header, in the procedure InitRecord, I would like to use the event publisher OnBeforeInitRecord to add my own code instead of the standard one. But I need the parameters PurchSetup and GLSetup in this event. Like this :
procedure InitRecord()
var
    ArchiveManagement: Codeunit ArchiveManagement;
    IsHandled: Boolean;
begin
    GetPurchSetup();
    IsHandled := false;
    OnBeforeInitRecord(Rec, IsHandled, xRec, PurchSetup, GLSetup);
    ...

With this event integration :
[IntegrationEvent(false, false)]
local procedure OnBeforeInitRecord(var PurchaseHeader: Record "Purchase Header"; var IsHandled: Boolean; xPurchaseHeader: Record "Purchase Header";  PurchSetup: Record "Purchases & Payables Setup"; GLSetup: Record "General Ledger Setup")
begin
end;

Do you think it could be possible ?
Thank you for your work.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Chocolately was updated to v0.11.3

Description
Starting to get this error on my Windows build that run cpack (part of CMake). Previous commits that were executing this step successfully are no longer working.
Run cpack
  cpack
  shell: C:\Program Files\Git\bin\bash.EXE --noprofile --norc -e -o pipefail {0}
  env:
    CMAKE_BUILD_TYPE: Release
Chocolatey v0.11.3
No .nuspec files (or more than 1) were found to build in 'D:\a\libfoo\libfoo\build'. Please specify the .nuspec file or try in a different directory.
Error: Process completed with exit code 1.

Virtual environments affected

[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[ ] macOS 10.15
[ ] macOS 11
[ ] Windows Server 2016
[X] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
Current runner version: '2.283.3'
Operating System
Microsoft Windows Server 2019
10.0.17763
Datacenter
Virtual Environment
Environment: windows-2019
Version: 20211018.0
Included Software: https://github.com/actions/virtual-environments/blob/win19/20211018.0/images/win/Windows2019-Readme.md
Image Release: https://github.com/actions/virtual-environments/releases/tag/win19%2F20211018.0
Virtual Environment Provisioner
<IP_ADDRESS>-master-20211007-1
Is it regression?
<IP_ADDRESS>-master-20211007-1
Expected behavior
No response
Actual behavior
No response
Repro steps
Chocolately was updated to 0.11.3 today (Oct 27) and the Windows image is already using it but README/json does not reflect this
https://docs.chocolatey.org/en-us/choco/release-notes

We are removing cpack during images generation. That said, whenever you are updating choco manually you must remove it too. Newer version will be available next week so you don't have to update it manually.
I am now going to close this issue, feel free to ping us or open another one if you have questions.

@mikhailkoliada
I was wondering about this. In our images we do not update choco, yet we run into the issue cpack is back. So I was browsing through how images are generated, and found this snippet:
https://github.com/actions/virtual-environments/blob/main/images/win/post-generation/Choco.ps1
I don't know much about how these images are actually generated, but to me that reads you (not us) are updating choco (not manually, but the image generation does this). Isn't that the actual problem here? And shouldn't that remove the cpack.exe again afterwards?
And just to highlight: I could be way off, as I really was just browsing through the image generation and ran into this :) So please do excuse me if I got this all wrong :)

@TrueBrain good catch, thanks! These post-generation scripts are run on hosted VM preparation step and indeed can update chocolatey if there is a new version available. We will take a look at what can be done to fix that.

The post-generation script has been merged and the fix merged.

I am still having this issue with the following version. I presume I just have to wait to get the latest provisioner?
Current runner version: '2.283.3'
Operating System
Virtual Environment
  Environment: windows-2019
  Version: 20211018.0
  Included Software: https://github.com/actions/virtual-environments/blob/win19/20211018.0/images/win/Windows2019-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/win19%2F20211018.0
Virtual Environment Provisioner
  <IP_ADDRESS>-master-20211022-1

@rishid the new image with the updated chocolatey will be deployed today — that should resolve the issue


Allow variable tab number on jsx-indent-props

Just setting up some eslint rules for React today and we realized that our style didn't quite work.
We are using prop-aligned for jsx-closing-bracket-location and tab for jsx-indent-props. This leads to a somewhat hard to parse line of code:
<Hello
    firstName="Matthew"
    lastName="Heck">
    <Status />
</Hello>

We tried this, but putting the nested component on the same line as the props just doesn't work for us (and we also don't like the alternative closing bracket locations).
I was hoping to propose that this be allowed:
<Hello
        firstName="Matthew"
        lastName="Heck">
    <Status />
</Hello>

I believe the solution would be fairly trivial (allowing a number of tabs) and can be implemented in a way that ensures backwards compatibility. I am happy to implement this change myself, but wanted to get feedback from you all first.

Does something like #398 can suit your need ?

I think that if you're choosing tabs (which imo is the proper choice), you've already chosen to not use line-aligned, tag-aligned, or prop-aligned anything - because the only way anything should be "aligned" is by semantic indentation level.
It's only with space-based indentation that it would be feasible to have arbitrary indentation amounts (in a granularity smaller than a whole number of indentation levels).


Fine grained partition writer optimization

What problem does this PR solve?
Issue Number: close #6157
Problem Summary:

Current FineGrainedShuffleWriter allocates new memory for scattered columns each time when batchWrite is triggered.
"Long tail problem", cached blocks under thres won't write until readSuffix, which's executed in a single thread.

This PR aims to reuse memory for scattered columns and "Long tail problem".
Referenced PR: https://github.com/pingcap/tiflash/pull/3787
What is changed and how it works?
Check List
Tests

[x] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-unit-tests

/run-unit-tests

/run-unit-tests

/merge


Added Save Setting

Added compress and quality in save the setting builder

@burhanrashid52 When is this planned to release? Any timeframe? Really need this fix asap for my app.
thanks,  great library btw 🗡

The release is ready. But I am adding test cases as much as I could in #146 .After completing that I'll merge that in release and will release 0.4.0 version with this changes. You can also help by adding tests for the library. It will help to speed up the release @majid701


Introduce unit tests for GH actions scripts

Proposed changes:

Setup target test-gh-actions in Makefile, specify category
Add poetry dev-dependencies and update poetry.lock
Prepare modules under test: Drop strict dependence of environment variables so the module is testable without
Add two test modules

Potential caveats (Feedback from reviewers encouraged):

I currently use sys.path.append because .github/scripts/ is not yet in the PYTHONPATH. Any ideas?
The test coverage (reported after running unit tests in CI) only for rasa/, but not .github/scripts

Status (please check what you already did):

[x] added some tests for the functionality
[ ] updated the documentation
[ ] updated the changelog (please check changelog for instructions)
[x] reformat files using black (please check Readme for instructions)

/modeltest
include:
 - dataset: ["financial-demo"]
   config: ["Sparse + BERT + DIET(seq) + ResponseSelector(t2t)", "BERT + DIET(seq) + ResponseSelector(t2t)"]

I thought about running it on every PR in the beginning. If it turns out to be annoying for others, we can restrict it of course

@wochinge Sure, making it required would be great. I am not sure if I have enough permissions to configure this in GitHub though. Could you set the check as required?


debian compile issues with tarsnap-gui

Hello,
Please don't hold this against me, but I have a debian based desktop system that I'm trying out with tarsnap and when I got the latest updates, it looks like there's a few compiling errors.
You may see the log here:
https://gist.github.com/jungle-boogie/1f0c4ba2d484960c2c71

You're using the master branch right? Check out the latest commit and retry.

Yes, using master but same messages are appearing.

Can you please try out with the second fix? This should resolve it.

Hi Shinnok,
Much better! Nice work.
Thanks,
jungle

Disclaimer: I do advise you to use the v0.5 version though, master is being actively developed and is a moving target.
If you're using master I'm assuming you are interested in the development process/code or are using some non-released yet feature and thus you know what you're doing. :-)

If you're using master I'm assuming you are interested in the development process/code or are using some non-released yet feature and thus you know what you're doing. :-)

Right, I'm highly interested in the progress of your project so I'm following head. The compiling issues weren't a big deal but it was great you fixed so quickly.


Don't create PR if you can't finish them

To avoid too much noise on this repo, don't open PR's if you can't or will finish them. At the moment we have 5 open PR. One of this PR have been inactive for the last 15 days - https://github.com/cherow/cherow/pull/153
We also have two PR - closed now - for string literals and ecmaVersion option. This also make up some noise on the repo.
Just be 100% sure before you open a PR. Also be sure that you get reviewers with knowledge enough to understand your way of thinking and the code flow.
https://github.com/cherow/cherow/pull/175 is my last PR. I will from now on push directly due to lack of reviewers and too keep the repo noise down.
cc / @fkleuver @g-plane @Aladdin-ADD

I really don't recommend to push directly.

I have pushed directly from start. As long as I'm only dealing with src folder there is no issue.

I still recommend to open PR. Once you opened a PR and there are no any reviews in several days, you can merge by yourself.

The issue is that somneone open PR and 1) never finish them or 2) never merge them


Initial OneWifi changes from stable2 commit id - b88e61f5dd0445cc3f5f987c54aeeeca8acfc948

Initial OneWifi changes from stable2 commit id - b88e61f5dd0445cc3f5f987c54aeeeca8acfc948

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 6 committers have signed the CLA.:white_check_mark: ksanth850:white_check_mark: rohantom016:x: rranga540:x: Leela-Charumathi:x: VikasBagora:x: Sivagami27-Rasurranga540 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

b'## Copyright scan failure
Commit: b88e61f5dd0445cc3f5f987c54aeeeca8acfc948
Report detail: https://gist.github.com/rdkcmf-jenkins/3bc6912c5002afc8583c0d11b5949099'


Paid Enterprise version without cloud integration

What would you like to be added:
I would like to have a dedicated enterprise channel with a paid tier that remove the logingate from lens and restricts -all- cloud communication and that comes with signed binaries for all operating systems.
Why is this needed:

Data compliance is important and the kubeconfig is literally the keys of the kingdom. As a Freelancer i am unable to use lens for my customers because I dont have a data processing agreement with mirantis. (https://gdpr.eu/what-is-data-processing-agreement/)

I dont need the cloud syncing features at all: Enterprise auth is based on SSO and MFA and thus there is no need to share the kubeconfig over a cloud service. It is literally the same for all of us. But keeping the cluster CA safe is important!

I realize that  there has to be a revenue stream in order to support an amazing product like this, yet unless all contracts under GDPR are validated its stimply illegal to use

I would like to make sure that lens stays in the market forever and in fact grows, therefore a revenue stream is inevitable.

Environment you are Lens application on:
All of them.

#5444 In reference also to this problem, I additionaly believe it would be a swift and easy solution.
Finally it does not mean that the enterprise version would not include the premium plugins at all, but an Implantation where we can download them manually, would be preferable and could be extended to include OIDC and SAML


Is it possible to use this architecture to deploy to ECS in another account?

I would like to use a similar architecture to deploy my application to ECS in another account, that way I would have the source (in my case, CodeCommit) and CodeBuild project in one account and the deployment on an ECS in another account. I found something similar in this article, but it uses CloudFormation to deploy to Lambda and since things can vary greatly from service to service, I decided to ask your opinions. Is it can be done with CodePipeline integration with ECS? If not, CloudFormation should work, right?
Thanks in advance for the help!

You can. You just have to add a cross-account role as the RoleArn for the Actions like you do for Lambda, and the pipeline role needs permissions to assume that role.

@joehillen Thank you for the answer!
You mean here, right? Like in this snippet.
- Name: Deploy
          Actions:
            - Name: Deploy
              ActionTypeId:
                Category: Deploy
                Owner: AWS
                Version: 1
                Provider: ECS
              Configuration:
                ClusterName: !Ref Cluster
                ServiceName: !Ref Service
                FileName: images.json
              InputArtifacts:
                - Name: BuildOutput
              RunOrder: 1
              RoleArn: [ROLE ARN]

On ClusterName and ServiceName I put the ARN, right? Since it is in another account.

No, you can use the simple names for the ClusterName and ServiceName. I don't know if the ARNs will work, it's worth a shot.

No, you can use the simple names for the ClusterName and ServiceName. I don't know if the ARNs will work, it's worth a shot.

Okay, I will try and I will give feedback here which one works. Thanks!

Sorry for asking one more question, but I think I'm stuck on the deploy stage.  I did exactly what I said above, I added the RoleArn on the deploy stage as illustrated below:
- Name: Deploy
          Actions:
            - Name: Deploy
              ActionTypeId:
                Category: Deploy
                Owner: AWS
                Version: 1
                Provider: ECS
              Configuration:
                ClusterName: !Ref Cluster
                ServiceName: !Ref Service
                FileName: images.json
              InputArtifacts:
                - Name: BuildOutput
              RunOrder: 1
              RoleArn: !Sub arn:aws:iam::${DevAccount}:role/toolsAccountRole

The pipeline goes just fine until the deploy stage where it gives this error:
Unable to access the artifact with Amazon S3 object key 'XXXX' located in the Amazon S3 artifact bucket 'YYYY'. The provided role does not have sufficient permissions.
I think it is referring to the role the pipeline assumed describe in the snippet above, but I'm sure it has all the permissions required to access the bucket. I gave full access to S3 on the policy itself, I gave full access to this role on the Bucket Policy as well and I gave permission to the role to use the KMS key the pipeline is using to encrypt and decrypt the artifacts. Am I missing something?
Thanks again for the help!

I was able to make it work after deleting the role I was using above and redoing it with CloudFormation (have done the previous one with the visual editor). I don't know what was the difference exactly, but it worked. Very strange... Anyway, thank you for the help so far!

May I know something detail how it worked

i also have a problem, like ''The cluster xxx does not exist', any idea? thanks

I have same issue. I get "The AWS ECS cluster ****** does not exist." even though my pipeline role has enough permissions. Any one who can provide a working sample?

I had to delete the action (temporarily remove from cloudformation/cdk) and then add it back in order to work around the "cluster does not exist" issue so it would respect the account/region props I added late. Still stuck on the permission issue mentioned here.


Workaround for SPARK-41448 to keep FileWriterFactory serializable

Why are the changes needed?

SPARK-41448 make consistent MR job IDs in FileBatchWriter and FileFormatWriter in Apache Spark 3.3.2, but it breaks a serializable issue, JobId is non-serializable.
And this pr aims to rewrite FileWriterFactory to circumvent the problem
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Codecov Report

Merging #4359 (2452ae0) into master (0be3cbf) will decrease coverage by 0.09%.
The diff coverage is n/a.

:exclamation: Current head 2452ae0 differs from pull request most recent head 1e5164e. Consider uploading reports for the commit 1e5164e to get more accurate results

@@             Coverage Diff              @@
##             master    #4359      +/-   ##
============================================
- Coverage     53.71%   53.63%   -0.09%
  Complexity       13       13
============================================
  Files           562      562
  Lines         30786    30786
  Branches       4149     4149
============================================
- Hits          16537    16511      -26
- Misses        12697    12723      +26
  Partials       1552     1552

Impacted Files
Coverage Δ

...e/kyuubi/jdbc/hive/ClosedOrCancelledException.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...kyuubi/server/trino/api/v1/StatementResource.scala
50.66% <0.00%> (-8.00%)
:arrow_down:

.../kyuubi/server/mysql/constant/MySQLErrorCode.scala
13.84% <0.00%> (-6.16%)
:arrow_down:

...ache/kyuubi/server/mysql/MySQLCommandHandler.scala
77.77% <0.00%> (-4.05%)
:arrow_down:

...in/spark/authz/ranger/SparkRangerAdminPlugin.scala
64.47% <0.00%> (-2.64%)
:arrow_down:

...g/apache/kyuubi/operation/BatchJobSubmission.scala
75.27% <0.00%> (-2.20%)
:arrow_down:

...ache/kyuubi/server/mysql/MySQLGenericPackets.scala
76.59% <0.00%> (-2.13%)
:arrow_down:

...ain/scala/org/apache/kyuubi/engine/EngineRef.scala
70.96% <0.00%> (-0.81%)
:arrow_down:

...he/kyuubi/ha/client/etcd/EtcdDiscoveryClient.scala
69.02% <0.00%> (-0.55%)
:arrow_down:

...in/scala/org/apache/kyuubi/config/KyuubiConf.scala
97.44% <0.00%> (-0.07%)
:arrow_down:

... and 1 more

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

Thanks, merged to master/1.7

Thanks @pan3793


Form gives wrong validation error on number field

// schema of a number field
numberField; {
  type: Number
}

When I wrote a letter in the field and triggered validation, it gave me the required error instead of the expectedNumber error.

Duplicate of #496 and #385. Unfixable.


Add other platforms

Check the following site possibility to embed them in our player.
Also we should decide if we want to focus on video game streaming or if we want to broaden our scope.
API for video :

[ ] Youtube
[ ] Dailymotion
[ ] Vimeo

API for game streaming :

[ ] Dailymotion games
[ ] Hitbox
[ ] Youtube Gaming

@nugetchar

That would add too much complexity on the extension and be time consuming.


Xcode build failed for Particle photon tinker iOS

Got source from: Github > spark/photon-tinker-ios > Releases > v1.6_appstore
Tried to build on Xcode 7.3.1 on OS X El Capitan 10.11.6 MacBook Pro
Got build error: "Command failed due to signal: Segmentation fault: 11"
Maybe this is an Xcode 7 Swift v2.

Did you try to install pods as frameworks? That might cause it because pods I use in this project are still in Obj-C

I have not installed pods.  Ah, hah!  Actually, I'm presently wrestling with installing the pods to support the SDK.  So, I assume they'll support Tinker v1.6 as well.  Thanks!


Deleted duplicate code fragments and Added abstract class

Hi, I realized a duplicate code fragment. I edited it with an abstract class.

Hi @talhacevik,
Thanks for this contribution.
May I ask you to first create an issue here: https://github.com/gravitee-io/issues/issues/new
Then link this PR to the issue.
Also, I see other place where we could use this abstract class, for example: AuditParam, LogsParam...
Why not changing it also? And add a note if the default value changed in the API (and not in UI).
Azize

Hi @aelamrani , I created AbstractSearchParam.java for SearchParam classes. All of them had the validate() method. I reviewed AuditParam.java. I saw it has not the validate() method. I think only *SearchParam classes can use AbstractSearchParam.java.

Hi,
You can create issues ont the repository issues (link provided earlier).


Quick Find for Lookup Columns that are Virtual Entities Not Producing Correct SQL

This is a known issue ATM. If you have a lookup to a SQL Virtual Entity you won't be able to add that column as a Quick Find Searchable Column

Dear Mike, congratulations for the Sql Virtual Entity DataProvider.
I've installed it and came around a problem concerning a lookup field based on a Virtual Entity.  It is giving only 25 of the total records ( I guess 25 is the page size which is specified on the form). The pagination also not working. So not at all able to see records other than first 'n' number of records .
Could you help to solve this problem?
BR,
Rubens Pereira

Hi Rubens,
You are correct about the behavior of subgrids when using Virtual Entities. It will only show the number of records specified in the row count of the subgrid. I'll look into the paging issue and get back to you.

Hi Mike.
Thx for you reply.
I've attached two screens to help you understand the behaviour.
First screen - the SIGTAP VE - the virtual entity - data with the load more option showed
Second screen - A model-driven form with one lookup field based on SIGTAP VE and the 25 records only.
Please let me know if you need additional information about this topic.

Hi Mike! Happy New Year.
Did you look into the paging issue?

Hi Mike! Happy New Year.
Did you look into the paging issue?


Stackdriver sink: fix export duration/timestamp metrics

Add anonymous functions to calculate correct export duration and last export time.
cc @piosz

This change is

/lgtm
/approve
Feel free to merge on green.


Missing documentation for iron-icons

From @adrifelt on July 9, 2015 16:23
There's no information about iron-icons in the element catalog for polymer 1.0. In contrast, 0.5 documentation has a great page with examples of all the different icons.

Copied from original issue: Polymer/polymer#2055

From @kevinpschaaf on July 9, 2015 16:50
This issue tracker is for the core Polymer library, not elements created with it.  We'll move this issue to the correct tracker.

I might add that in the iron overview page the non-existing doc is linked, but the demo containing all icons is not. It is available, but not linked : https://elements.polymer-project.org/elements/iron-icons?active=iron-icons&view=demo:demo/index.html

This has been long fixed: https://elements.polymer-project.org/elements/iron-icons


Remove default exclusions

Something that has come up a few times via @getsentry support is the unawareness of the default exclusions. Specifically I'm talking about IGNORE_DEFAULT.
I'm opening this ticket to start a discussion around removing defaults and simply documenting a suggested pattern instead.

That would probably deserve a major version bump.
I think it'd make sense to put it in the getting started documentation, where you'd set both dsn and exclude
Raven.configure do |config|
  config.dsn =<EMAIL_ADDRESS>  config.exclude = [
    'ActiveRecord::RecordNotFound',
    'ActionController::RoutingError',
    'ActionController::InvalidAuthenticityToken',
    'CGI::Session::CookieStore::TamperedWithCookie',
    'ActionController::UnknownAction',
    'AbstractController::ActionNotFound',
    'Mongoid::Errors::DocumentNotFound'
  ]
end

By the way, why does the documentation suggest that the DSN not be kept in the source code? I'd expect it only allows sending data, not reading data, so the worst-case scenarios would be that someone posts bogus data, or posts so many events that legitimate events don't get recorded.
Obviously open source projects should never keep any secret keys in the source code, but for a closed-source project, the risk seems minimal.

By the way, why does the documentation suggest that the DSN not be kept in the source code? I'd expect it only allows sending data, not reading data, so the worst-case scenarios would be that someone posts bogus data, or posts so many events that legitimate events don't get recorded.

Sounds pretty bad to me. Also Sentry plans are based on events/minute, so keeping the "writing" of events secure is important. I believe Sentry also has "public" DSNs now (intended for JS I think) to mitigate all this.

@dcramer I don't like making the default exclusions opt-in rather than opt-out. Half of developers probably don't even know what all of those error types are and whether or not they care about excluding them. They just don't have the knowledge to make the decision.

Yeah I dont have a strong opinion either way. Maybe this is just something that we should improve in docs so people are clearly aware there are defaults.

I don't think ActionController::InvalidAuthenticityToken should be in a default excluded list of errors

@prem-prakash Why?

@nateberkopec because this error can reveal about session incorrect handling or store. We are facing a problem now with ActionController::InvalidAuthenticityToken token in which it is essential to have full log, including user information (from Rack env), in order to be able to dig and fix.
We are using memcache service as session store that seems to be failing sometimes, and it fails this error was hidden because it is in IGNORE_DEFAULT.

Hmm. Well, the reason it's excluded by default is because we assume that the most common reason for this error to be raised is either an attacker or a bad client (bot, etc).
There are always going to be times when the default exclusions will hide actual, meaningful errors, like in your case. A common one I've seen is ActionController::NotFound errors being raised because of a bad link somewhere in your application. However, most of the time, the errors in the exclusion list are noisy.
Because of this, and since the list of exceptions we ignore is called out in the Readme and it is easy to change, I think it's appropriate to keep ActionController::InvalidAuthenticityToken in the exclusion list.


Add built in way to efficiently look up line numbers for a large number of nodes/tokens?

This may be useful in the next phase (Making this easy to consume).
Currently, I only see one method, which counts the number of newlines up to that byte in the file.
If an application determined line numbers for a majority of nodes, it would be slow (O(n*m), n being number of nodes, m being file size)
Example use cases:

Language server which reports line number in error message, completion, etc.(?)
Converting to other ast formats (https://github.com/Microsoft/tolerant-php-parser/issues/113)

Example API:
class LineNumberLocator {
    // Example strategies: eager (E.g. walk the tree and build a map from offsets to line numbers), or support binary search (E.g. in an array mapping line numbers to offsets), or the slow search.
    // Or cursor (assume the next requested node/token will be next to the previously requested one).
    public static function create(string $file_contents, Node $sourceFileNode, int $strategy = ...) : LineNumberLocator;

    public function getStartLine($node) : int;

    // can determine from getStartLine if an array mapping lines to offsets is built
    public function getStartColumn($node) : int;

    public function getEndLine($node) : int;

    public function getEndColumn($node) : int;
}

Other considerations:

Will this API's design be affected by incremental rebuilding?

I'm implementing something similar for https://github.com/TysonAndre/tolerant-php-parser-to-php-ast/blob/master/src/TolerantASTConverter/FilePositionMap.php (needs to be tidied up and documented, and is specific to one use case)
Haven't benchmarked it yet, looping over only tokens (full start+start) might be a more efficient way to do the same thing.
https://github.com/TysonAndre/tolerant-php-parser-to-php-ast/blob/master/src/TolerantASTConverter/FilePositionMap.php


TF >=1.13 doesn't support CUDA 9.0

System information

OS Platform and Distribution: Linux Ubuntu 16.04
TensorFlow installed from (source or binary): build from source
TensorFlow version: 1.13.1, 1.14.0, 2.0.0a, 2.0.0b1
Python version: 3.5
Installed using virtualenv? pip? conda?: ...
Bazel version (if compiling from source): 0.25.2
GCC/Compiler version (if compiling from source): 5.4.0
CUDA/cuDNN version: CUDA 9.0, cudnn 7.6.1
GPU model and memory: Tesla V100

Describe the problem
I want to compile newer versions of TF from source to support CUDA 9.0 . I tried building all versions after 1.12.0 and always get the same error. Bazel build sucessfully finishes but after I install the resulting pip file and try to import TF it doesn't use GPU's
Could not dlopen library 'libcusolver.so.9.0'; dlerror: /usr/local/cuda-9.0/lib64/libcusolver.so.9.0: undefined symbol: GOMP_critical_end; LD_LIBRARY_PATH: /usr/local/cuda-9.0/lib64
2019-07-16 14:37:23.856339: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudart.so.9.0
2019-07-16 14:37:23.857504: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcublas.so.9.0
2019-07-16 14:37:23.858807: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcufft.so.9.0
2019-07-16 14:37:23.859066: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcurand.so.9.0
2019-07-16 14:37:23.859437: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Could not dlopen library 'libcusolver.so.9.0'; dlerror: /usr/local/cuda-9.0/lib64/libcusolver.so.9.0: undefined symbol: GOMP_critical_end; LD_LIBRARY_PATH: /usr/local/cuda-9.0/lib64
2019-07-16 14:37:23.860627: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcusparse.so.9.0
2019-07-16 14:37:23.864452: I tensorflow/stream_executor/platform/default/dso_loader.cc:42] Successfully opened dynamic library libcudnn.so.7
2019-07-16 14:37:23.864478: W tensorflow/core/common_runtime/gpu/gpu_device.cc:1663] Cannot dlopen some GPU libraries. Skipping registering GPU devices...

Provide the exact sequence of commands / steps that you executed before running into the problem
I use configure script with all parameters at default except specifying CUDA version. Then I build with:
bazel build --config=opt --config=cuda //tensorflow/tools/pip_package:build_pip_package
Any other info / logs
This problem was already reported before: #30389
I also found discussion, where people had the same issue with cusolver library:
https://groups.google.com/forum/#!topic/kaldi-help/8OThZ1lwE9I

Try updating your Cuda version to 10.0 exact (also not 10.1). It should support training on GPUs.

@rishabhsahrawat updating CUDA on the server is not an option for multiple reasons. I want to compile TF specifically for CUDA 9.0

@bonlime ,
Please take a look at software requirements for TF installation.Thanks!

If TensorFlow only support CUDA 10.0, I think configure script should prevent from using other CUDA versions.

@anush-o  it says "TensorFlow supports CUDA 10.0 (TensorFlow >= 1.13.0)". I supposed it meant TF should support old versions of CUDA 9.0 as well as new 10.0

@bonlime ,
This is Tested and existing compatibility of CUDA and TF versions. In order to use CUDA 9.0 you can downgrade the TF version to 1.12.Thanks!

The reason why opened this issue is because I expected TF 1.13 to support lower versions of CUDA as well. Looks like it doesn't.
I'll close the issue, but if anyone finds a way to compile from sources for CUDA 9.0 feel free to comment here

@oanush how do you downgrade to 1.12? I got the error message
ERROR: Could not find a version that satisfies the requirement tensorflow==1.12 (from versions: 1.13.0rc1, 1.13.0rc2, 1.13.1, 1.13.2, 1.14.0rc0, 1.14.0rc1, 1.14.0, 2.0.0a0, 2.0.0b0, 2.0.0b1)

You need to downgrade Python to 3.6. TF 1.12 does not support Python 3.7.

On Aug 17, 2019, at 02:41, kk325ic<EMAIL_ADDRESS>wrote:

@oanush how do you downgrade to 1.12? I got the error message
ERROR: Could not find a version that satisfies the requirement tensorflow==1.12 (from versions: 1.13.0rc1, 1.13.0rc2, 1.13.1, 1.13.2, 1.14.0rc0, 1.14.0rc1, 1.14.0, 2.0.0a0, 2.0.0b0, 2.0.0b1)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@bonlime
import ctypes
ctypes.CDLL("libgomp.so.1", mode=ctypes.RTLD_GLOBAL)

This two lines might allow you to run CNN networks with TF 1.14 + CUDA 9.
But it might cause strange behavior with LSTM models, where TF tries to allocate extensive VRAM and fails).

@004307ec Can you please describe where to add this? Also, do I have to build this from source in order to run TF 1.14 with CUDA 9.0?

@smr97 Yes you have to build from source in order to use TF 1.14 with CUDA 9.0. You need to add the lines above to the beginning of your scripts which use TF

@bonlime , can you confirm that those two lines really affect LSTM behaviour?

@sudonto No. I was only using TF for computer vision tasks, didn't check the LSTM behavior


WASD to move, IJKL to place webs. Bugs move one tile every time you move. Catch them by placing a web directly on them or in their path for them to fly into. Step on bugs stuck in webs to eat them and gain points. You can also step on webs that haven't caught a bug to "jump" over a tile, making crossing pits possible.

Code
Check off the items that are true.

[x] The game was made using the Sprig editor.
[x] The game is placed in the in the /games directory.
[x] The code is significantly different from all other games in the Sprig gallery (except for games labeled "demo").
[x] The game runs without errors.
[x] The name of the file/game contains only alphanumeric characters, -s, or _s.
[x] The game name is not the same as the others from gallery

Image (If an image is used)

[x] The image is in the /games/img directory.
[x] The name of the image matches the name of your file.

Thanks for your PR!

Nice work on this game! The spiderwebs mechanic was really cool to play with. I'm merging this, and you should see it in the gallery next week.
If you're a teenager, you can request a free Sprig console at this link and join our online Slack community to chat with other people making Sprig games.


issue1673 matrix profile

https://github.ibm.com/wiotp/monitoring-dashboard/issues/1673
Other PR for keeping packages cosistent

https://github.ibm.com/IoT-Enterprise/analytics-service-library/pull/334
https://github.ibm.com/IoT-Enterprise/analytics-service-pipeline/pull/204

@pkohlmann

For as-library: while the push build #1601 failed, the PR build #1602 passed. Similarly for pipeline the push build #5457 failed and PR build #5458 passed. Under the assumption that iotfunctions packages are the same across there three (all iotfunctions packages are in library and pipeline requirements) is this not enough evidence that pip won't cause conflicts?

No, stumpy is not pre-approved, but I was under the impression that we perform package checks after building images now. To be honest I'm not sure how this process works and if it's okay to include the package and ask for approval later or do we have to do this first

@singhshraddha I'm not sure if I understand our build system completely: A successful PR-build of analytics service pipeline and of library tells us the new code works with the current iotfunction code. But you want to add new code to iotfunctions as well.  Do we have the proof analytics service pipeline and library work with the new code in iotfunctions? Maybe this is  a general issue we have with pull requests for iotfunctions because we do not check the compatibility with pipeline/library.
I have asked Wolfgang about the approval process for new components. There is no process for it. He will get in touch with you about it.

I took the liberty to use the wicked tool for a pedigree search and couldn't find stumpy (no surprise)
https://taas.cloud.ibm.com/tools/wicked
CSAR scan of the stumpy code in github is found here
Result: Nothing suspicious, plain BSD-3 license.
I've asked Kelly to proceed with the open source approval process (OSSC).


Start Julia / Stop Julia fails sometimes in the newer versions

In recent versions of Julia Client, the Restart Julia Client command fails in Juno-Plus. I am not sure if this is related to Julia-Client, but I didn't have this issue before, so I want to know if anything has changed regarding Start Julia, Stop Julia commands.
https://github.com/aminya/juno-plus/issues/8

I'm having the same issue. If I want to restart the REPL, I have to restart Atom. Very frustrating.

We're looking into this, but it's fairly hard to figure out what's going on since the crash doesn't show a stacktrace (or an error, for that matter).

This. The exact same happens to me. I am using the latest Atom, Juno and Julia. I used to face this issue occasionally (which in itself was frustrating) but in the past few days (after the update I guess) this got worse and I have to manually close and open Atom to restart REPL

@pfitzseb
This. The exact same happens to me. I am using the latest Atom, Juno and Julia. I used to face this issue occasionally (which in itself was frustrating) but in the past few days (after the update I guess) this got worse and I have to manually close and open Atom to restart REPL. I get the error "Can't interrupt Julia without a Julia client running. Start a client with Packages -> Juno -> Start Julia." and when I try to start nothing happens. The minibar at the bottom left gets stuck on "working" mode too

For now, you can use Ctrl+P + Reload to reload Atom without openning and closing.

@aminya Thanks for the tip but it doesn't work for me. Ctrl + P opens a window with some random files from my pwd I guess. Also, is there any other way to clear workspace besides stop and restart?

@aminya Thanks for the tip but it doesn't work for me. Ctrl + P opens a window with some random files from my pwd I guess.

Sorry Ctrl+Shift+P that opens the command window.

Also, is there any other way to clear workspace besides stop and restart?

For development, you can use Revise.jl. There is a Revise button in Juno-Plus: https://github.com/aminya/juno-plus

Well, for this juno-plus case, the code that needs to be modified is not in julia-client, but in juno-plus.
I remember I told @aminya  how to "implement" Restart Julia command, but now the atom.dispatch command doesn't return a Promise anymore and that just causes this error.
You can see my current implementation here and this should work for your package as well (it's really ad-hoc, though).

Separate from that, there is certainly issues of crashes on killing->restarting Julia process within the latest releases. But I would like to open an separate issue for that at Juno.jl, since this issue is originally for the one within juno-plus.

Let me close this in favor of https://github.com/JunoLab/Juno.jl/issues/510.


[Contact service android] Split the projection for contact info. Allow apps to configure the contact info they wants.

Querying all contact columns results in the error: "Row too big to fit into CursorWindow". That is because some columns are referring to the same internal column (data1, data2 .... data6 etc). We get duplicate columns for single row. So we split the cursors for querying different contact info. Add an optional parameter for apps to configure what contact info they wants.

@lukasgit Hi Lukas, can you take a look at this PR?

@zhenqiu1101 will do, thanks

@lukasgit Hi Lukas, can you take a look at this PR?

Apologies for the delay @zhenqiu1101 . Is this PR tested are ready?  Is there anything instructions needed to be added to the readme ?


Geocoder is not working if I provide true value explicitly

Geocoder is not working if I provide true value explicitly.
Please take a look on the following code:
Not working example:
var viewer = new Cesium.Viewer('cesiumContainer',{     geocoder: true, });
Working example:
var viewer = new Cesium.Viewer('cesiumContainer',{     /*geocoder: true,*/ });

Thanks for reporting this @SurajitChowbey!  We currently expect either a GeocoderService or false for the geocoder property, which is confusing.  We either need to update the documentation to reflect this, or use a separate property to set a custom geocoder service.
@mramato do you have an opinion here?  I feel like overloading the geocoder argument in this way was the wrong decision and we should have options.geocoder be a boolean and add options.geocoderServices.

A better solution is to remove geocoder and just have geocoderServices. If it's defined then the feature is enabled, just like with imageryProvider and terrainProvider.

@mramato do you have an opinion here? I feel like overloading the geocoder argument in this way was the wrong decision and we should have options.geocoder be a boolean and add options.geocoderServices.

I believe this mirrors similar SDKs at the time it was written, but it was so long ago I don't remember for sure.  I would recommend just handling the case where the value is true and call it a day.  This has never been a problem before and it would create an immense amount of churn to change because all of the Viewer options follow this paradigm.

A better solution is to remove geocoder and just have geocoderServices. If it's defined then the feature is enabled, just like with imageryProvider and terrainProvider.

The geocoder is enabled by default, so it already works like imageryProvider and terrianProvider.  There's technically no bug here, it's documented behavior, but it's an easy usability improvement to make true work for all of the widgets.

In retrospect we probably should have used null instead of false back in the day, then people wouldn't have thought to switch it to true, they would understand to supply an instance.

Thanks @SurajitChowbey!  This was fixed and will be included in the Cesium 1.48 release available August 1st

Welcome


AVRO-3839: [Rust] Replace lazy_static crate with std::sync::OnceLock

AVRO-3839
What is the purpose of the change

Replaces a dependency with functionality that is part of the Rust standard APIs since 1.70.0

Verifying this change

Build and tests still pass

Documentation

Does this pull request introduce a new feature? no

The PR will be Draft until MSRV is bumped to 1.70.0+


stable/nfs-server-provisioner Add ability to specify pod Security Context settings

Some situations require that client pods of the NFS server run as non-root users. It's useful to be able to specify uids/gids that the server should allocate on the export. For example, one can pass "--set securityContext.fsGroup=34765" to specify that the NFS PV created by the provisioner will be owned by group id 34765.
Signed-off-by: Zoram Thanga<EMAIL_ADDRESS>
Is this a new chart

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @kiall

Please bump chart version @zoramthanga

Hi Naseem,
Thanks for your comment. I am not sure what the new version should be. Is
it 1.0.1 or 1.1.0, or something else?
Thanks,
Zoram
On Tue, Jun 2, 2020 at 4:36 PM Naseem<EMAIL_ADDRESS>wrote:

Please bump chart version @zoramthanga https://github.com/zoramthanga
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/helm/charts/pull/22642#issuecomment-637862142, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHNL2GJ2JOXTM7RRQI7M5ELRUWEHBANCNFSM4NRFAGCQ
.

--
Zoram Thanga
Cloudera Inc.
395 Page Mill Road
Palo Alto, CA 94306

Hi Naseem, Thanks for your comment. I am not sure what the new version should be. Is it 1.0.1 or 1.1.0, or something else? Thanks, Zoram
…
On Tue, Jun 2, 2020 at 4:36 PM Naseem @.***> wrote: Please bump chart version @zoramthanga https://github.com/zoramthanga — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22642 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHNL2GJ2JOXTM7RRQI7M5ELRUWEHBANCNFSM4NRFAGCQ .
-- Zoram Thanga Cloudera Inc. 395 Page Mill Road Palo Alto, CA 94306

Good question, I think a minor bump is suiting in this case.

Also, it seems that it is being added at the pod level, as such could you call the value podSecurityPolicy please?

Hi Naseem, Thanks for your comment. I am not sure what the new version should be. Is it 1.0.1 or 1.1.0, or something else? Thanks, Zoram
…
On Tue, Jun 2, 2020 at 4:36 PM Naseem @.***> wrote: Please bump chart version @zoramthanga https://github.com/zoramthanga — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22642 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHNL2GJ2JOXTM7RRQI7M5ELRUWEHBANCNFSM4NRFAGCQ .
-- Zoram Thanga Cloudera Inc. 395 Page Mill Road Palo Alto, CA 94306

Good question, I think a minor bump is suiting in this case.

Bumped the minor version. Thanks!

Also, it seems that it is being added at the pod level, as such could you call the value podSecurityContext please (to distinguish from container level https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container)?

Changed the name to podSecurityPolicy as suggested. Thanks!

Also, it seems that it is being added at the pod level, as such could you call the value podSecurityContext please (to distinguish from container level https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container)?

Changed the name to podSecurityPolicy as suggested. Thanks!

That was a typo on my end 🤦  Sorry. It's podSecurityContext

Also, it seems that it is being added at the pod level, as such could you call the value podSecurityContext please (to distinguish from container level https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container)?

Changed the name to podSecurityPolicy as suggested. Thanks!

That was a typo on my end 🤦 Sorry. It's podSecurityContext, heh I see you repeated the typo in your comment.
We should probably add the value to the README if there is a values table

I think the typo is mine 😆 Hopefully linking to the k8s documentation would suffice, as far as what values can be set in a pod Security Context.

/lgtm


Improve display of favorites for ties

Currently, we display favorites like so:
1. Marie Curie              (3 activities)
2. George Washington Carver (3)
3. Elizabeth Cady Stanton   (3)
4. Someone Else             (2)

When in reality the top three friends are all tied for first place, so they should be displayed either like this:
1. Marie Curie              (3 activities)
1. George Washington Carver (3)
1. Elizabeth Cady Stanton   (3)
4. Someone Else             (2)

or possibly like this:
*1. Marie Curie              (3 activities)
*1. George Washington Carver (3)
*1. Elizabeth Cady Stanton   (3)
 4. Someone Else             (2)

Food for thought: http://stackoverflow.com/questions/25042260/convert-sorted-ruby-array-to-ranks-with-possible-repeats

I think my leaning is for simplicity's sake to not have asterisks or any special indication for the tied numbers.

This is released in v0.30.


Fi lists rewrite

added todo and fixed shopping list so they both should work now

I'll create a new branch and create a new PR from there, this isn't working...


[BUG] Watchlist Module - Account Entity Escaping

When running the playbook on demand, the enriched entities that are received may include data that is not sufficiently escaped when executing the KQL query

Passed Entities data should be string literal
Filter Entities data to necessary properties only to reduce further parsing risks

This issue was already fixed in a previous PR