Ingress: Use partial KPR instead of strict

Recommend partial kube proxy replacement, as it is easier to operate. When KPR=strict is used, Cilium agents will not be able to reach kube-apiserver via the well known service IP, rather kube-apiserver address has to be explicitly configured with the --k8s-api-server option.

Recommend partial kube proxy replacement, as it is easier to operate. When KPR=strict is used, Cilium agents will not be able to reach kube-apiserver via the well known service IP, rather kube-apiserver address has to be explicitly configured with the --k8s-api-server option.

It's the presence of kube-proxy that determines whether you need to explicitly pass the kube-apiserver address to the agents. You can run in strict mode with kube-proxy installed, in which case you don't need to pass the address.
We also generally don't recommend users rely on the partial mode. It leads to more complex setups and has very little coverage in our CI.

We also generally don't recommend users rely on the partial mode. It leads to more complex setups and has very little coverage in our CI.

It's the presence of kube-proxy that determines whether you need to explicitly pass the kube-apiserver address to the agents. You can run in strict mode with kube-proxy installed, in which case you don't need to pass the address.

Thanks for the clarification. I have been struggling with this without knowing this :-)

Thanks for the clarification. I have been struggling with this without knowing this :-)

Yep, it's another shortcoming of the so-called "kube-proxy-free" guide: it gives the impression that the only way to run KPR is to remove kube-proxy.


Updating HoloToolkit contents not phone specific

The current content in the phone branch should be pulled into master as it is not strictly phone specific.

resolved with #25


It doesn't work on node@14

Version
5.0.4
Environment info
node-v14.9.0

Steps to reproduce
cnpm install
What is expected?
normal operation Normal Running
What is actually happening?
Installing "@vue/vue-loader-v15" will fail on earlier versions of Node, which do not support this installation. It does not support installation with aliases("@vue/vue-loader-v15": <EMAIL_ADDRESS>as dependent version packages.

I could not enter the vue info command on the server, but it was an error when installing dependencies as CNPM under the<EMAIL_ADDRESS>version

It's not because of Node.js v14.
It's your dependency manager that is too outdated.
Package aliases have been supported since NPM 6.9, which was released more than 3 years ago.


Added example about dropping columns on which views are not dependent

Fixes #7849.

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/9c1b2ed2d74eb76542264996180c8bf45dc445bb/
Edited pages:

v20.2/views.md

TFTR @rytaft !

TFTR @lnhsingh !


Release the code and dataset

Could you please release the code and dataset?

code is released now.


[OAP-1541][oap-native-sql] TreeNode children not replaced by columnar…

… operators
Also, add ColumnarPluginTest.
Closes #1541

@rui-mo , just checked with Hongze, he has submitted fastEquals PR, FYI

@zhztheplayer  verified, merge here.


New "built-in options" meson section doesn't work on older meson

Older meson (<0.55) doesn't support the built-in options section introduced in 77af1026e24e8b913459c3dbef485fe7799a6a46. This means the link args get dropped, so the resulting binary depends on mingw-w64's libraries instead of pulling them in statically. E.g. when trying to load d3d11 in Wine:
err:module:import_dll Library libgcc_s_seh-1.dll (which is needed by L"C:\\windows\\system32\\d3d11.dll") not found

Since it's only a deprecation, I suggest reverting the change until newer Meson is more widely distributed. Here's Debian's current distribution, for example: https://packages.debian.org/search?keywords=meson

Cc @Kron4ek

Cc @Kron4ek

sigh...
Apparently reverting this change breaks newer meson versions so we might have a bit of a problem here.

sigh...
Apparently reverting this change breaks newer meson versions so we might have a bit of a problem here.

It doesn't break newer versions, it just printed lots of deprecation warnings
DEPRECATION: c_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: c_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: fortran_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: fortran_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objc_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objc_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objcpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objcpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: c_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: c_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
The Meson build system
Version: 0.56.2

It doesn't break newer versions, it just printed lots of deprecation warnings
DEPRECATION: c_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: c_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: fortran_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: fortran_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objc_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objc_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objcpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: objcpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: c_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: c_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
DEPRECATION: cpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
The Meson build system
Version: 0.56.2


[issue] Cancelling bbrf process keeps running on CouchDB

I have tested this situation many times:

Running a heavy process (deleting over 100k urls or domains)
Press Control + C
Processes on the CouchDB server keep running. Sometimes overloading the server.

I often need to restart the DB in order to get rid of the left over processes.
This might be the cause for the 'unknown error' described in another issue.

I'm having better results removing data using chunks:
This oneliner will remove the urls in steps of 5000 urls
chunk=5000; size=$(bbrf urls|wc -l);  urls="1,${chunk}p" parts=$((size%chunk?size/chunk+1:size/chunk)) ; echo $parts ; for i in $(seq 1 $parts) ; do echo "try $i"; bbrf urls|sed -n "$urls"|bbrf url remove - ; done

Thanks, Philippe. This sounds like it should help me improve performance for large input data.

Your welcome @honoki.
After more testing I can confirm that using chunks works faster and it's more reliable than the regular way.


Updating to version 2.0.4

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Remove quorum hashes from SCP protocol messages

The quorum hashes can be implicitly derived from the node_id and slot_idx fields which are part of every SCPEnvelope message.
This reduces the total network overhead.
Fixes #982

I think the idea is very good.
Access to the quorum set has become more familiar.

However, quorumSetHash (D) removed,  so we need to see more of the effects.

we need to see more of the effects.

I'm not sure what you mean by this.
The quorum set can now be looked up through the Node ID. getQSet (Hash) has been replaced with getNodeQSet (PublicKey), which SCP calls when it needs to find the quorum set of a given message.

I like it, but that's a rather large modification of SCP. As we move in that direction, it's going to become harder to integrate upstream change. I have an idea to deal with it, just need to sit and implement it (hint: patch).

Yes that's one of the problems..
This doesn't need to be merged right now. I tagged it as CoinNet because it would be good to have around that milestone.

We should still do this, but this PR is now quite outdated, so closing.


Emulation of Rust's ? operator

This is what I proposed in #444 , with some superficial modification to match the current APIs.
Closes #444

nice

Any contributors reviewing this?

Sorry, life recently has made it tough to be as attentive as I used to be. I'll see if I can have a look this coming weekend.

Bump

Any updates?

Hello!
This PR is awesome!  I like a lot!
Any news?

https://github.com/supermacro/neverthrow/issues/496

Would anyone here be willing to contribute to the docs / readme? A few examples would be much appreciated for folks who aren't so familiar with generators as well (myself included).

Extremely basic docs have been added in this commit: https://github.com/supermacro/neverthrow/commit/1fd6a05c72b134d46ff76066a7b8768431e6aab0

https://github.com/supermacro/neverthrow/releases/tag/v6.1.0

https://github.com/supermacro/neverthrow/pull/448#issuecomment-1774114657
I'll make a PR.

@tsuburin I know I'm  a bit late to the party, but thanks a lot for this change, it's a great improvement!.
I just have one small question, though: is there a specific reason why safeTry takes a () => Generator<Err<never, E>, Result<T, E>> instead of a () => Generator<Err<never, E>, T>? I'm asking, because the latter would allow to create highly composable functions that all return Generator<Err<never, E>, T> and that can directly be used with safeTry.
In addition, it might also make sense to allow passing arguments to the function passed to safeTry.
Example that shows this in combination:
/* --- signatures for safeTry --- */

declare function safeTry<T, E, Args extends unknown[]>(
  body: (...args: Args[]) => Generator<Err<never, E>, T>,
  ...args: Args
): Result<T, E>;
declare function safeTry<T, E, Args extends unknown[]>(
  body: (...args: Args) => AsyncGenerator<Err<never, E>, T>,
  ...args: Args
): Promise<Result<T, E>>;

/* --- functions returning generators --- */

function myParseInt(input: string): Generator<Err<never, Error>, number> {
  const n = Number.parseInt(input);
  const result = Number.isNaN(n) ? err(new Error("Parsing failed!")) : ok(n)
  return result.safeUnwrap();
}

function random(): Generator<Err<never, Error>, number> {
  const n = Math.random();
  const result = n >= 0.5 ? ok(n) : err(new Error("Random number was too small!"));
  return result.safeUnwrap();
}

function* h(input: string): Generator<Err<never, Error>, number> {
  const n1 = yield* myParseInt(n);
  const n2 = yield* random();
  return n1 + n2;
}

/* --- usage of these functions with safeTry --- */

const result1 = safeTry(h, "42"); // ok(42 + <random number>), if the random number was large enough, otherwise err(...)
const result2 = safeTry(h, "abcdefg"); // err(...), because parsing failed

// but we can also pass myParseInt and random to safeTry directly:

const result3 = safeTry(myParseInt, "0"); // ok(0)
const result4 = safeTry(random); // ok(<random number>), if the random number was large enough, otherwise err(...)

Support for passing in arguments could easily be added without a breaking change. But I believe, if we wanted to change the type of generator function that needs to be passed in according to what I described above, that would require a breaking change :/
Of course, there is ways to do this, too, with the current api, e.g., you could have the composable functions all return Generator<Err<never, E>, Ok<T, never>>, and then always access .value on the result of yield* (and wrap the finally returned value in an ok). Similarly, you could write the composable functions as explained above, and define a lift function:
function lift<T, E, Args extends unknown[]>(fn: (...args: Args) => Generator<Err<never, E>, T>): (...args: Args) => Generator<Err<never, E>, Ok<T, never>> {
  return function* (...args: Args) {
    return some(yield* fn(...args));
  }
}

and use that when passing one of the composable functions to safeParse. (Not sure if you can write a lift function that works both for Generators and AsyncGenerators, or if separate functions are needed)
But both of these solutions are more cumbersome than what I described above, and I don't really see a downside (aside from the fact, that it would now be a breaking change).

@ghost91- Thank you for the comment.

is there a specific reason why safeTry takes a () => Generator<Err<never, E>, Result<T, E>> instead of a () => Generator<Err<never, E>, T>?

Although I haven't tested, technically the latter will also work, I guess. If so, this is a matter of taste. Personally I prefer the current interface, because I think you may want to return Errs from safeTry's body by usual return statements.
For example, lets say you want to add two integers and verify the sum is less than 20. With current interface you can write as follows.
safeTry(function*() {
  const sum = (yield* parseInt("12").safeUnwrap()) + (yield* parseInt("10").safeUnwrap());
  if (sum >= 20) {
    return err("sum is too big")
  }
  return ok(sum)
})

Howereve, with your proposal, because the only way to return Err is by yield*ing, you need to first make Err instance and then call safeUnwrap immediately.
safeTry(function*() {
  const sum = (yield* parseInt("12").safeUnwrap()) + (yield* parseInt("10").safeUnwrap());
  if (sum >= 20) {
    return yield* err("sum is too big").safeUnwrap()
  }
  return sum
})

The latter looks a bit clumsy for me.

I'm asking, because the latter would allow to create highly composable functions that all return Generator<Err<never, E>, T> and that can directly be used with safeTry.

With current interface, you can compose functions like the following.
function h(input: string): Result<number, Error> {
  return safeTry(function*() {
    const n1 = yield* parseInt(input)
    const n2 = yield* random()
    return ok(n1 + n2)
  })
}

Or, if it's still a bit cumbersome, you can write as
const h = (input: string) => safeTry<number, Error>(function* (){
  // The same body as above here...
})

In my opinion, we should keep the generators used in this feature from hanging around in the library's user's code. This is because it can let the users use the generators in wrong ways. The generator made by .safeUnwrap() is intended to be used just once, otherwise throws an Error. So, I think the idea of composing generators directly is not for this library. (Technically it looks interesting, though...)

In addition, it might also make sense to allow passing arguments to the function passed to safeTry.

If your motivation is to feed arguments to the body of safeTry, the h in the above examples already achieved. If you have other reasons, please tell me.

Hey @tsuburin thanks a lot for your response!
The main motivation behind the idea of composing functions that return generators directly is to reduce boilerplate in as many places as possible. With your example for h, you need a safeTry(function* () { ... }) in every function that wants to compose other functions, and on top of that, you could not put the parseInt and random functions into safeTry directly, since they return the wrong kind of generator. If you changed the type of generator as I suggested, you could simply compose them (avoiding an indentation in the code) and only need safeTry at one place at the top, where you really want to convert it back to a Result.

Howereve, with your proposal, because the only way to return Err is by yield*ing, you need to first make Err instance and then call safeUnwrap immediately.
safeTry(function*() {
 const sum = (yield* parseInt("12").safeUnwrap()) + (yield* parseInt("10").safeUnwrap());
 if (sum >= 20) {
    return yield* err("sum is too big").safeUnwrap()
  }
  return sum
})

The latter looks a bit clumsy for me.

It's actually simpler, just yield the Err directly:
safeTry(function*() {
  const sum = (yield* parseInt("12").safeUnwrap()) + (yield* parseInt("10").safeUnwrap());
  if (sum >= 20) {
    yield err("sum is too big");
  }
  return sum;
});

I see your point that it might sometimes be convenient to be able to return a Result directly. But on the other hand, that is also a bit inconsistent: There are 2 ways to "return" errors, either yield them, or return them. With my suggested approach, there is a clear separation: You yield errors, and you return the ok values.
The reason I started to investigate this at all is that I was initially very confused why safeUnwrap returns a different kind of generator than what safeTry expects. I would have expected
safeTry(() => result.safeUnwrap());

to work. But it does not, you need to to
safeTry(function* () {
  return ok(yield* result.safeUnwrap());
});

which (to me) feels confusing.
One other reason for modelling it the way I suggested: This whole functionality is basically Hakell's do notation for the Either monad (Result is just a specific type of Either), in the same way that async/await is more or less just the do notation for the Promise monad. And in the do notation, you also return plain values, and not wrapped values.
async/await in JavaScript is actually bit special in this regard, because it allows you to do both: You can just return a plain value from an async function, and it will be wrapped in a promise automatically. But you can also return a promise from an async function, without getting a promise wrapped in another promise—the promises are automatically collapsed into a single one.
Regardless, to me it seems natural that you can return plain values and don't have to wrap them in ok(...). If it's possible to support returning either T or Result<E, T>, that would also be fine (and would mimic the behavior of async/await in JavaScript, but I'm not sure if that can easily be done in a type safe way, without language/compiler support. Because, how would you handle things if T itself is a Result<U, F>? Maybe it's possible, but it increases the complexity dramatically :sweat_smile:.
I see that you have modeled this more after how Rust's ? works. I didn't have much knowledge about it before and just assumed, it would behave the same as the do notation. But apparently, it does not, it also requires you to still explicitly wrap returned values in Ok. This kind of makes sense, since in Rust, you just have a regular function (returning an Error), so you need to return something that matches the return type of the function. But since we need a special kind of function/notation anyways, we do not need that "limitation".
I also get the point about not using the generators outside of safeTry. If you wanted to prevent that all together, you could even not make safeUnwrap a method on Result, but instead, pass it as a parameter to the generator function within safeTry:
safeTry(function* (unwrap) {
  const a = yield* unwrap(someResult);
  return ok(a); // I'd still prefer return a, though :)
});

That way, this unwrapping functionality is only available inside callbacks safeTry (unless you set it on some global, from inside such a function... But it should be extremely obvious that that's not intended...). This approach has the downside of needing even more boiler plate for safeTry, though (need to specify the unwrap parameter).
When going this route, you don't even really need generator functions anymore. You can also propagate the error by wrapping it inside a specific error class, throwing that in unwrap, and catching it in safeTry. See e.g. Do-notation for Either in Typescript (which interestingly also makes you return Right(...) instead of just ...). With that approach, it would look like
safeTry((unwrap) => {
  const a = unwrap(someResult);
  return ok(a); // I'd still prefer return a, though :)
});

This solution might be an interesting alternative because of its simplicity (generators can be scary for some people).
Anyways, I at least have a better understanding of where you are coming from (Rust's ?). I still think that my suggested alternative would be slightly preferable (I still simply don't really see any downside to it), but maybe that's also just personal preference. I totally get that the small (perceived) benefits might not be worth a breaking change, now that the functionality has already been released (it's unfortunate that I'm just a bit too late...).
The nice thing is: Even if people here don't agree, I can just implement my own safeTry function, since it's just a free standing function that doesn't need any access to internal stuff :)

@ghost91- Thank you for your reply, too. I'm not so familiar with Haskell, so your point is really interesting to me. I have some experience of Rust but not of Haskell so much.
I completely agree on that it's preferable to reduce boilerplate as much as possible.  However, another aspect I had in designing this feature was ease of understanding. In that aspect, I didn't really want to use generator at all. (This depends on individual, and if you argue generators are easy to understand, it is completely fair, but for me, it's not.)
Actually,

safeTry((unwrap) => {
  const a = unwrap(someResult);
  return ok(a); // I'd still prefer return a, though :)
});

this was exactly what I considered first, and gave up because I found it is very difficult to implement this safeTry correctly.  There are two problems I couldn't solve. One is that there is no way to pass type-checking of catch-ed errors. In typescript, caught errors are inferred to be unknown, and even if I wrap the thrown error in a dedicated class and check by instanceof, the compiler can't check its contents' type. Of course, as long as everything are used correctly, we can assert that the contents are what we expect, but it is not acceptable for such kind of libraries, I thought. The other problem is that if someone use try-catch statements in this safeTry the functionality can be completely broken because it is possible that what is thrown by unwraps is caught and not thrown again.
So, finally I decided to use generators, and settled down what it is now. To me, generators are used here because there is no other way (at least as far as I could come up with). And so, honestly, I haven't considered composing generators at all.

It's actually simpler, just yield the Err directly (or if we also removed the Err from the type of Generator, just the error value):
safeTry(function*() {
  const sum = (yield* parseInt("12").safeUnwrap()) + (yield* parseInt("10").safeUnwrap());
  if (sum >= 20) {
    yield err("sum is too big"); // or even just yield "sum is too big"
  }
  return sum;
});

Oh, yes, this should work. But here you use yield* and yield, and it may be confusing for someone as return and yield* are for you. (Again, this is just a matter of taste, and I never mean you are wrong.)

safeTry(function* (unwrap) {
  const a = yield* unwrap(someResult);
  return ok(a); // I'd still prefer return a, though :)
});

That way, this unwrapping functionality is only available inside callbacks for safeTry (unless you "save" it somewhere globally, from inside such a function... But it should be extremely obvious that that's not intended...).  This approach has the downside of needing even more boiler plate for safeTry, though (need to specify the unwrap parameter).

This idea seems worth considering. (Including the downside you mentioned, because it might be as obvious as this is that safeUnwrap should not be used outside safeTry, from its documentation.) For now, I guess we should wait for comments from others.

If it's possible to support returning either T or Result<E, T>, that would also be fine (and would mimic the behavior of async/await in JavaScript), but I'm not sure if that can easily be done in a type safe way, without language/compiler support. Because, how would you handle things if T itself is a Result<U, F>? Maybe it's possible, but it increases the complexity dramatically 😅.

As you pointed out, it is difficult (or may be impossible) to tell whether a Result instance is intended to be T or Result<U, F>, if we want to do it with the same function. However, also as you mentioned, you can implement your own function, and maybe you can make an issue or PR to hear comments from others. (I guess it is better to move to an issue if we continue this conversation, because this is a closed PR.)
Anyways, again, thank you for your comments with a lot of points I haven't noticed. :smile:

One is that there is no way to pass type-checking of catch-ed errors. In typescript, caught errors are inferred to be unknown, and even if I wrap the thrown error in a dedicated class and check by instanceof, the compiler can't check its contents' type. Of course, as long as everything are used correctly, we can assert that the contents are what we expect, but it is not acceptable for such kind of libraries, I thought.

Since the dedicated class can only be thrown by unwrap, I believe it's safe to assume that the contents are correct, unwrap itself is typed so that only the correct kind of result can be passed to it. The only way I can see this breaking is with your next point, which is valid:

The other problem is that if someone use try-catch statements in this safeTry the functionality can be completely broken because it is possible that what is thrown by unwraps is caught and not thrown again.

Here is an example how this combination could break:
export function safeTry<T, E>(body: (unwrap: <U>(result: Result<U, E>) => U) => T): Result<T, E> {
  try {
    return ok(body(unwrap))
  } catch (e) {
    if (e instanceof UnwrapError) {
      return err(e.error) // typed any, but we _know_ that it should be E, because the only way UnwrapError could have been thrown is from unwrap, unless users _somehow_ get a hold of UnwrapError
    }
    throw e
  }
}

function unwrap<T, E>(result: Result<T, E>): T {
  if (result.isOk()) {
    return result.value
  }
  throw new UnwrapError(result.error)
}

class UnwrapError<E> extends Error {
  constructor(readonly error: E) {
    super()
  }
}

const result = safeTry((unwrap: <U>(result: Result<U, number>) => U) => {
  try {
    const result: Result<number, number> = err(42)
    const a = unwrap(result)
    return a
  } catch (e: any) {
    const constructor = e.constructor
    throw new constructor('boom!')
  }
})
// result typed as Result<number, number>, but it actually is Err<never, string> :(

I would argue that getting the constructor from a thrown error and then creating a new instance with different parameters is not something you should ever do, but it's possible. I think it would be acceptable to ignore this problem, because it's so obscure (and you need to use any, or type assertions for the caught error).
The fact that you can have a try catch inside the callback, which does not rethrow the custom error, is a much bigger problem, because try catch is still common syntax, and it completely breaks the functionality. I think this is a killer argument to not do it this way. Thanks for bringing it up, I had not thought of it (since we don't throw any errors, we always use neverthrow :D).

@ghost91-
Sorry if this is unnecessary, but let me make just one more comment for both your information and later references.

Since the dedicated class can only be thrown by unwrap, I believe it's safe to assume that the contents are correct, unwrap itself is typed so that only the correct kind of result can be passed to it.

This assumption is not safe, at least with your example above, because a kind of mistakes like the following is quite possible.
safeTry((unwrap: <U>(result: Result<U, number>) => U) => {
    const result = safeTry((umwrap: <T>(result: Result<T, string>) => T) => { // mistyped as umwrap
        const r: Result<number, number> = err(3);
        const x = unwrap(result); // unwrap from the outer safeTry is called
        return x;
    })
   // result is typed as Result<number, string> but is actually Err<number, number>
})

Fair point. Unless I am missing something, that's solvable by creating the class inside safeParse:
export function safeTry<T, E>(body: (unwrap: <U>(result: Result<U, E>) => U) => T): Result<T, E> {
  class UnwrapError<E> extends Error {
    constructor(readonly error: E) {
      super()
    }
  }

  function unwrap<T, E>(result: Result<T, E>): T {
    if (result.isOk()) {
      return result.value
    }
    throw new UnwrapError(result.error)
  }

  try {
    return ok(body(unwrap))
  } catch (e) {
    if (e instanceof UnwrapError) {
      return err(e.error)
    }
    throw e
  }
}

Because then for every invocation of safeTry, you will have a different UnwrapError class. So with this implementation, in your example, the error would be rethrown by the inner safeParse, and caught by the outer one.
But at this point, it all becomes a bit weird and annoying, and I'm not sure I'm not missing any other edge cases.


Expose & log the precache bundle size

Library Affected:
workbox-build
The code that generates the precache manifest's list of URLs and hashes does not return information about the total size of the precache payload. If we start returning that information, we could then display it as the output of our build tools.
sw-precache currently logs something like Total precache size is about 90 kB for 2 resources. and you could imagine workbox-cli logging something similar by defualt.
Folks who are using workbox-build directly could log the total payload size using whatever mechanism they see fit, as long as we exposed it.

What's the use case for this?

It can serve as a sanity check—if the output is Total precache size is about 90 mB for 2000 resources. then a developer might realize that they're using a globPattern that includes many more files (or larger files) then they intended.
A more speculative use case would be if someone who's using workbox-build directly keeps track of the precache payload size over time, and raises a red flag if it increases more than X% from the previous build. (Similar to our proposed tracking of bundle sizes over time.)

@jeffposnick did you add this in to the current v3 work? I faintly recall seeing size somewhere, but could be dreaming it up.

Yup! It's returned by the relevant workbox-build methods, and the workbox-cli will log it after the build completes.
(Thanks for scrubbing the issue tracker!)


Scraper not working

As of 24th of June 2019, none of the two scrapers are returning any matches, nor throwing any error messages when failing to scrap.

TheGamesDB.net now requires registered API keys and the legacy API has been shut down. I'm not sure this project is actually still maintained, but a good place to start would be modifying the request path in GamesDBScraper.cpp

I'm attempting to fix this in #802 , but I think the maintainer of this project may never be around to merge it.

I propose a Solution for this I am goint to use https://api.igdb.com/ API to engace with the Scrapper on the Emulation Station, sorry for my English.

they have a 10k/month limit on the free version of their API, and probably have rules against disseminating a paid version to the public

So, what you propose?

For now I'm trying to work on giving people a way to configure their own scrapers, but with a default that uses TheGamesDB with my own public API key.

but legacy.thegamesdb.net/api/GetGame.php? is unavailable

sure, but api.thegamesdb.net is available

what?? and works equals, just changeing the String Url and compile Works?

Do you have a working version of emulations station with Scrapper Fix??

Sort of. I have this: #802 which works, assuming you have an API key to put in there. It doesn't have my API key yet, as I'm still testing.

In Retropie setup fork of EmulationStation is Fixed

Yes, Retropie seems to have solved this already. Dunno if they've already opened a PR, but it seems unlikely at this point that it'll get merged at any rate.
Mine works, but also is aiming in the long-term to be much more general, and to support any scraper database that matches a certain behavior pattern.

Is there a way to search and if multiple results choose between those that return? Kinda similar to hakchi?

What about Windows users? Any way to fix that?

What about Windows users? Any way to fix that?

I'm just gonna be honest ES is more worried about ARM builds. I understand why and in the big picture it is fair when you consider there isnt anywhere near as many programs for ARM.


Handler for upgrade client

Blocked by: #420
Crate
ibc
Summary

[x] handler implementation in ics02_client::handler::upgrade_client.rs

raise an issue with cosmos/ics to add canonical algorithm for handling this message? not clear if that's desirable since this is documented and handled mostly in the SDK: https://github.com/cosmos/cosmos-sdk/tree/master/docs/ibc/upgrades
probalby inspired from https://github.com/cosmos/cosmos-sdk/pull/7367 since there is no canonical algorithm in the cosmos/ics spec (yet)

[ ] clarify the use of upgrade_path field in Tendermint client state and include that in tests

For Admin Use

[X] Not duplicate issue
[X] Appropriate labels applied
[X] Appropriate milestone (priority) applied
[X] Appropriate contributors tagged
[X] Contributor assigned/self-assigned

The upgrade client is not specified in the standard, and we don't have a specific user that needs this. Hence, it's currently unclear how to implement this.
We can get back to it once someone needs it.

As for the upgrade_path relevant context APIs are added in PR #673.
Testing these new endpoints should be covered by Basecoin integration tests. For more context see https://github.com/cosmos/ibc-rs/issues/420#issuecomment-1542683384


Windows 10, version1803 Group Policies

There is no information about the new Group Policies in Windows 10, version 1803.
If there are no new/different Group Policies in Windows 10, version 1803 one should drop a short info about it.

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

ID: 9c3e60ec-cf61-c34b-db79-74b13e3ee867
Version Independent ID: fc5079f7-a563-c627-3a3e-eb84a99e4fd3
Content: New policies for Windows 10 (Windows 10)
Content Source: windows/client-management/new-policies-for-windows-10.md
Service: w10
GitHub Login: @jdeckerMS
Microsoft Alias: dongill

@jdeckerms, can you take a look at this one?  Let me know if I need to reassign it :)

That one is Corey’s, thanks!
From: Patti Short<EMAIL_ADDRESS>Sent: Wednesday, October 24, 2018 3:06 PM
To: MicrosoftDocs/windows-itpro-docs<EMAIL_ADDRESS>Cc: Jeanie Decker<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/windows-itpro-docs] Windows 10, version1803 Group Policies (#884)
@jdeckermshttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjdeckerms&data=02|01|jdecker%40microsoft.com|2b390d22429b4496154108d639fcd6e6|72f988bf86f141af91ab2d7cd011db47|1|0|636760155432100031&sdata=E5jzpTTko9ZQ7fd2t%2BO8j0jX33mdjepC9Lt6rKl%2FxHc%3D&reserved=0, can you take a look at this one? Let me know if I need to reassign it :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fwindows-itpro-docs%2Fissues%2F884%23issuecomment-432844502&data=02|01|jdecker%40microsoft.com|2b390d22429b4496154108d639fcd6e6|72f988bf86f141af91ab2d7cd011db47|1|0|636760155432100031&sdata=Cw2jdK0kioGystIuTrtDq4R8JzvhwE%2BJI4v6zGpr7t0%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGA2pDGh1RzMfxP_lGdlef6a4XKoIgnIks5uoOQ1gaJpZM4T37Ya&data=02|01|jdecker%40microsoft.com|2b390d22429b4496154108d639fcd6e6|72f988bf86f141af91ab2d7cd011db47|1|0|636760155432110036&sdata=19PPzCtu5tYu5RmUwdHjMlGnhHvTUOTum9cBRKjVh%2Bc%3D&reserved=0.

@officedocsbot assign @mypil

@mypil Let's link the author since I'm not aware of such changes so I can add the note into the PR :)

@coreyp-at-msft @DaniHalfin @Justinha @mjcaparas @greg-lindsay @jaimeo - Can you please share your insights on this issue?
Thank you.

Adding a link to a spreadsheed where all the changes into policies by versión can be filtered and obtained.
PR #3766

@cas77 - Thank you for submitting feedback.
From our understanding, the issue has been resolved but it may take a few days for the merged content to appear in the article. If you feel it hasn't been resolved, please re-open this issue.
Thank you for your contribution to make the docs better! Much appreciated!

@officedocsbot close


Driver connection documentation

Hi, thanks for providing the package.
I wonder where do I put the information for my cluster? I changed my scout driver to 'elastic' and trying to import the data but not sure how to connect to it.
Should I still use the array on scout.php?

 'algolia' => [
        'id' => env('ALGOLIA_APP_ID', ''),
        'secret' => env('ALGOLIA_SECRET', ''),
    ],

Thanks!

Hey @fernandocoronatomf, thank you for pointing out to the missing part of the documentation!
I've updated the Configuration section of the README file. Check it out!

Thanks. I figured it out after checking composer.json and the dependencies.
But thanks for improving the docs anyway.

Also, @babenkoivan
Can we configure the indexes using this package? What's your recommendation?

@fernandocoronatomf have a look at Elastic Migrations package 🙂


Make the app responsive

First of all, congratulations on creating this awesome app. I know it took hard work and perseverance to build it.
A great welcoming feature would be to make the app responsive for different desktop screen sizes and also mobile devices.
Best of luck!

Yeah it took a lot of work especially since I am just learning JS. Thank you, it means a lot coming from you... I know what you're saying and I agree. It shall be done my lord.


How to resend the confirmation code?

Hello,
After calling:
AWSMobileClient.default().signUp and  AWSMobileClient.default().signIn
we have to call AWSMobileClient.default().confirmSignIn(challengeResponse: code) with the correct code in order to complete the sign in.
What about if we don't receive the message? How can we retry that?
If I call
AWSMobileClient.default().resendSignUpCode(username: "-my phone number-",
I receive:
▿ AWSMobileClientError
  ▿ notAuthorized : 1 element
    - message : "Cannot resend codes. Auto verification not turned on."

Any recommendation?
Thanks a lot.

@Ricardo1980 did you solve your issue?

Not at the moment.
But I will have to do it in the future.

@Ricardo1980 The flow you describe above is more akin to the built-in verification (via email or SMS). With a custom authentication flow, you don't use confirmSignIn or resendSignUpCode. You simply use signIn(mobileNumber) (notice, only one parameter) which triggers the custom auth flow. That ought to trigger the sending of the SMS code. Then you use sendCustomChallengeAnswer with the SMS code to confirm the sign-up/-in. I hope this helps!

@tomaszdudek7
Check this:
https://github.com/aws-amplify/aws-sdk-ios/issues/2261
Basically, call AWSMobileClient.default().signOut() and then start the signUp/signIn sequence again.


Aligned AST interfaces with Ruby definitions

Wile trying to move the reveal.js slim backend to a Groovy MarkupTemplateEngine based approach I needed to make these changes.
The members that are moved from AbstractBlock to AbstractNode are are also defined on AbstractNode in the Ruby implementation.
Some methods like DocumentRuby.doctitle() or AbstractNode.getAttr() were overloaded to mirror the defaults defined in the Ruby implementation.

:+1:
Let's be sure to deprecate the old methods instead of remove so we don't break the API until we are ready to break the API. I realize there will be some gray area, but best to make a smooth transition as possible.

I deprecated the methods that complied to the short naming style and added new getters.

:+1:

It look awesome :) I can't wait until we release the <IP_ADDRESS> to merge this change to master branch. @mojavelinux we need to take a decision about what to do with logging redirection. For me we can remove the piece of code, release the <IP_ADDRESS> and then let's think what to do.

I think we should comment out the logging redirection for <IP_ADDRESS> and
stabilize or refine it for inclusion in 1.5.3.
Before we do the <IP_ADDRESS> release, we study the diff to make sure everything
going into it matches the expectations of a patch release. We can use a
1_5_2 branch if we need to hold other things back. Another option is to
wait for 1.5.3 core to be ready. Perhaps discuss on the list?

Yes on list would be better
El dv., 2 de gen., 2015 a les 20.05 Dan Allen<EMAIL_ADDRESS>va
escriure:

I think we should comment out the logging redirection for <IP_ADDRESS> and
stabilize or refine it for inclusion in 1.5.3.
Before we do the <IP_ADDRESS> release, we study the diff to make sure everything
going into it matches the expectations of a patch release. We can use a
1_5_2 branch if we need to hold other things back. Another option is to
wait for 1.5.3 core to be ready. Perhaps discuss on the list?
—
Reply to this email directly or view it on GitHub
https://github.com/asciidoctor/asciidoctorj/pull/264#issuecomment-68552343
.


IDX10211: Unable to validate issuer. The 'issuer' parameter is null or whitespace

When doing this code in the start up file
app.UseJwtBearerAuthentication(options =>
{

	options.AutomaticAuthentication = true;
	options.TokenValidationParameters.IssuerSigningKey = key;
	options.TokenValidationParameters.ValidAudience = audience;
	options.TokenValidationParameters.ValidIssuer = issuer;
	options.TokenValidationParameters.ValidateAudience = false;
	options.Events = new JwtBearerEvents
	{
		OnAuthenticationFailed = context =>
		{
			context.HandleResponse();
			return Task.FromResult(0);
		}
	};
});

the options are not been honor in the middle ware
Controller Code
JwtSecurityToken securityToken = handler.CreateToken
(
	issuer: _bearerOptions.TokenValidationParameters.ValidIssuer,
	audience: _bearerOptions.TokenValidationParameters.ValidAudience,
	signingCredentials: _signingCredentials,
	subject: new ClaimsIdentity(new Claim[] { new Claim(ClaimTypes.Name, user.Email) }),
	expires: DateTime.Today.AddDays(1)
);

string token = handler.WriteToken(securityToken);

Injection in the controller
private readonly JwtBearerOptions _bearerOptions;
private readonly SigningCredentials _signingCredentials;
private readonly IUserRepository _Repo;
public TokenController(IOptions<JwtBearerOptions> bearerOptions, SigningCredentials signingCredentials, IUserRepository repo)
{
	_bearerOptions = bearerOptions.Value;
	_signingCredentials = signingCredentials;
	_Repo = repo;
}

Can you check if issuer is null or ""?  Would hard coding options.TokenValidationParameters.ValidIssuer resolve your issue?

No they are not empty values, they are constants on my startup class, I debug the application and in the controller when is doing the signature the jtwbaeroptios does not have those values, looks like the middle ware is not honoring the setup in startup

You can't simply use app.UseJwtBearerAuthentication(options => { ... }) and expect the JWT options to be retrievable using IOptions<JwtBearerOptions> since app.UseJwtBearerAuthentication no longer relies on IOptions (nor injects it) in beta8.

@PinpointTownes is right, IOptions is no longer populated in services for this. You're getting a new options instance with a new TVP without any config. You probably need to configure these separately.


MCA replacement and UI fixes

Codecov Report

Merging #399 into master will increase coverage by 6.08%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master     #399      +/-   ##
==========================================
+ Coverage   65.08%   71.16%   +6.08%
==========================================
  Files           6        6
  Lines         779      711      -68
==========================================
- Hits          507      506       -1
+ Misses        272      205      -67

Flag
Coverage Δ

#BluePicApp
71.16% <75%> (+6.08%)
:arrow_up:

#BluePicServer
71.16% <75%> (+6.08%)
:arrow_up:

Impacted Files
Coverage Δ

...c-Server/Sources/BluePicApp/ServerController.swift
70.67% <100%> (+11.85%)
:arrow_up:

...-Server/Sources/BluePicApp/ServiceProperties.swift
100% <100%> (ø)
:arrow_up:

...ePic-Server/Sources/BluePicApp/Configuration.swift
63.75% <54.54%> (+0.45%)
:arrow_up:

BluePic-Server/Sources/BluePicApp/RouteUtils.swift
71.55% <66.66%> (+0.18%)
:arrow_up:

Continue to review full report at Codecov.

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


Testsuite failure in 'bad_cargo_lock' on 32-bit powerpc

cargo 0.25.0 builds on 32-bit powerpc but the testsuite fails with:
failures:

---- bad_cargo_lock stdout ----
	running `/«PKGBUILDDIR»/target/powerpc-unknown-linux-gnu/release/cargo build -v`
thread 'bad_cargo_lock' panicked at '
Expected: execs
    but: differences:
  3 - |  missing field `name` for key `package`|
    + |  could not parse input as TOML|

  4 -
    + ||

  5 -
    + |Caused by:|

  6 -
    + |  invalid number at line 2|

other output:
``', debian/../vendor/hamcrest-0.1.1/src/core.rs:31:12
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: hamcrest::core::assert_that
   8: bad_config::bad_cargo_lock

failures:
    bad_cargo_lock

test result: FAILED. 36 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--test bad-config'

Full build log available at: https://buildd.debian.org/status/fetch.php?pkg=cargo&arch=powerpc&ver=0.25.0-1~exp1&stamp=1519467947&raw=0
If anyone is interested on debugging this issue, you can requests access to a porterbox in #debian-ports on OFTC or by contacting<EMAIL_ADDRESS>

I haven't seen this issue since at least cargo 0.26, latest build log looks fine:

https://buildd.debian.org/status/fetch.php?pkg=cargo&arch=powerpc&ver=0.29.0-1&stamp=1534633186&raw=0

I think we can close this.


Use typed boxes to simplify capture representation in SILGen

Now that SIL has @box T types, we no longer need to capture mutable variables as pairs of box and address. Here's a series of patches that simplifies the way SILGen emits captures so that they're only passed as boxes, along with follow-up changes to capture promotion, SILCombine, and DI to preserve their existing behavior. Until now, we also claimed that capture addresses were passed @inout, which is semantically incorrect—mutable captures are allowed to be mutated simultaneously from the closure and the original context in well-typed, well-synchronized ways. I introduced a new parameter convention @inout_aliasable to represent these semantics for @noescape mutable captures. I'd like some review of the various pieces before mashing into master:
@rjmccall, do the semantics of @inout_aliasable make sense to you? I'm not thrilled with the name, since we were already throwing aliasable around with the different meaning of "allow type-punned aliases through this pointer", which I don't want to allow.
@lattner, I changed SILGen to emit mark_function_escape instructions on variable addresses before they're captured; that way, DI still works on captured variables without having to do concurrent analysis of the box and address value uses. I also adjusted the diagnostics to use the more specific "captured by a closure" diagnostic when this happens, instead of the generic "used before initialized" diagnostic. Is there a better approach you'd prefer?
@rudkx, do the changes to capture promotion look reasonable? Are there any other passes you're aware of that would need updating to avoid optimizer regressions?
@adrian-prantl, there's a regression in debug info that I wasn't sure how to address, since the argument addresses are no longer passed directly. I could have SILGen emit debug_addr instructions to annotate the projections that get emitted on the callee side. Is that the right thing to do, or do we need extra information to flag these as arguments or captures instead of regular variables?

Thanks for the feedback everyone! With @adrian-prantl's recent fixes the proper debug info appears to fall out. Going public seems to have messed with the connection in the pull request; I'll finish this up out of band.


Don't use deprecated Material UI stuff

Seeing this in console:
Warning: Material-UI: you are using the deprecated typography variants that will be removed in the next major release.
Please read the migration guide under https://material-ui.com/style/typography#migration-to-typography-v2

I think we're going to depreciate the wallet module so let's close this for now. If/when the wallet becomes relevant again, we can open new issues on this topic.


Execution rate goes down considerably when the outstanding requests are high

SUMMARY
As a part of scale testing, I have observed that execution rate goes down considerably, when the outstanding requests are high
STACKSTORM VERSION
st2 3.8.0, on Python 3.8.10
OS, environment, install method
Post what OS you are running this on, along with any other relevant information/
Kubernetes HA, installed through helm install (oneline)
Steps to reproduce the problem
Scale up action pods to a certain number. for ex. 17. The default available threads for actions are 17x60
Each action using python runner with a sleep of 5 sec
1000 req, initiated (python threading - http api calls) gets completed in 77sec
Based on above numbers, the test case - [ Send 2500 req with sleep of 250sec, and 500 req with sleep of 250sec ] in loop
Expected Results
Given enough time for executions based on above numbers, there should not be any outstanding requests after each cycle
Actual Results
But there is pending actions, at the end of each cycle(observed in requested state). This count goes higher after few cycles. Then, the execution rate which is at 17x60 goes down to single digits(as the outstanding count goes from 5k to 20k and more)
Observed the same results with a clean mongodb, and size of 5+million docs
st2scheduler does not process requests, and hence actionrunner too. Resources are minimally used when the execution rate goes slower.
Is there a workaround to enforce scheduler to take up more requests  ? When more requests are pending, the pods should work harder, but it goes the other way here
Thanks!

how are you making the Python runner sleep? Is it leveraging the eventlet/green thread capabilities to yield while sleeping?

what is a cycle here?

how are you making the Python runner sleep? Is it leveraging the eventlet/green thread capabilities to yield while sleeping?
Can you show the action that you're running to test?

I have tried shell and python runners for sleep which gets same results. I have not used green thread, as stackstorm should treat each remediation as green thread, or to say(the sleep in remediation does not intervene with OS sleep)
It is simple action ```
from st2common.runners.base_action import Action
import time
class scale_sleep(Action):
def run(self, sleep_time, scale_tag):

    time.sleep(int(sleep_time))
    return scale_tag

what is a cycle here?

A cycle is one full loop as described here.  " [ Send 2500 req with sleep of 250sec, and 500 req with sleep of 250sec ] in loop "

If it really is the scheduler that is the bottleneck then try increasing the execution_scheduling_timeout_threshold to prevent rescheduling of actions that are not running in time.
I am guessing the scheduler is rescheduling actions that haven't started quite yet
Also, increase the pool size so it schedules more.
Generally speaking if it is the scheduler, then try to adjust the settings to get the throughput you need.

I have noticed double runs of actions in a high request volume situation.  setting the execution_scheduling_timeout_threshold to 60 minutes or longer takes care of that.


use ThreadLocalRandom in PinotQueryResource

ThreadLocalRandom:
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadLocalRandom.html

Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 27.85%. Comparing base (59551e4) to head (1330adf).
Report is 917 commits behind head on master.

Files
Patch %
Lines

...t/controller/api/resources/PinotQueryResource.java
0.00%
1 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (59551e4) and HEAD (1330adf). Click for more details.
HEAD has 28 uploads less than BASE

Flag
BASE (59551e4)
HEAD (1330adf)

integration
7
4

temurin
12
6

java-21
7
5

skip-bytebuffers-true
3
2

skip-bytebuffers-false
7
4

unittests
5
2

unittests1
2
0

java-11
5
1

unittests2
3
2

integration1
2
1

custom-integration1
2
0

Additional details and impacted files
@@              Coverage Diff              @@
##             master   #13855       +/-   ##
=============================================
- Coverage     61.75%   27.85%   -33.90%
+ Complexity      207      198        -9
=============================================
  Files          2436     2576      +140
  Lines        133233   142179     +8946
  Branches      20636    22088     +1452
=============================================
- Hits          82274    39603    -42671
- Misses        44911    99524    +54613
+ Partials       6048     3052     -2996

Flag
Coverage Δ

custom-integration1
?

integration
<0.01% <0.00%> (-0.01%)
:arrow_down:

integration1
<0.01% <0.00%> (-0.01%)
:arrow_down:

integration2
0.00% <0.00%> (ø)

java-11
0.00% <0.00%> (-61.71%)
:arrow_down:

java-21
27.85% <0.00%> (-33.78%)
:arrow_down:

skip-bytebuffers-false
27.84% <0.00%> (-33.91%)
:arrow_down:

skip-bytebuffers-true
27.84% <0.00%> (+0.11%)
:arrow_up:

temurin
27.85% <0.00%> (-33.90%)
:arrow_down:

unittests
27.85% <0.00%> (-33.90%)
:arrow_down:

unittests1
?

unittests2
27.85% <0.00%> (+0.11%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


fix: improves type safty for autocomplete when optionLabel is required

This pull request improves autocomplete type safety.
The way it works now is that if the options are different from an array of strings then optionLabel is required. Typescript does not inform the user of this and the only feedback you get is a thrown error when you try and open the dropdown.
This PR makes it so that the optionLabel is optional if the options is an array of string, if not optionLabel becomes required.

Linting and tests are passing fine locally so disregard the failing github actions 👍

This resolves #3007


Open a flow in the flow editor by double-clicking in Test Explorer

This would require an enhancement to https://github.com/hbenl/vscode-test-explorer, which currently implements showSource() this way:
    const document = await vscode.workspace.openTextDocument(vscode.Uri.parse(fileUri));

However, at present there's no mechanism for Test Explorer to know or delegate to Ply's custom editor. So ultimately this requires an enhancement to vscode: https://github.com/microsoft/vscode/issues/113173.


Error: ActionView::Template::Error: couldn't find file 'support/chai' with type 'application/javascript'

I accidentally upgraded from 0.7.4 to 1.1.0. I'm now getting this error:
Error: ActionView::Template::Error: couldn't find file 'support/chai' with type 'application/javascript'
/Users/richardschneeman/Documents/projects/codetriage/test/javascript/js_test_helper.coffee:3
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/resolve.rb:64:in `resolve!'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/directive_processor.rb:399:in `resolve'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/directive_processor.rb:207:in `process_require_directive'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/directive_processor.rb:180:in `block in process_directives'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/directive_processor.rb:178:in `each'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/directive_processor.rb:178:in `process_directives'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/directive_processor.rb:83:in `_call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/directive_processor.rb:68:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/processor_utils.rb:75:in `call_processor'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/processor_utils.rb:57:in `block in call_processors'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/processor_utils.rb:56:in `reverse_each'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/processor_utils.rb:56:in `call_processors'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/loader.rb:134:in `load_from_unloaded'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/loader.rb:60:in `block in load'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/loader.rb:318:in `fetch_asset_from_dependency_cache'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/loader.rb:44:in `load'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/cached_environment.rb:20:in `block in initialize'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/cached_environment.rb:47:in `yield'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/cached_environment.rb:47:in `load'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/bundle.rb:23:in `block in call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/utils.rb:183:in `dfs'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/bundle.rb:24:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/processor_utils.rb:75:in `call_processor'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/processor_utils.rb:57:in `block in call_processors'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/processor_utils.rb:56:in `reverse_each'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/processor_utils.rb:56:in `call_processors'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/loader.rb:134:in `load_from_unloaded'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/loader.rb:60:in `block in load'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/loader.rb:318:in `fetch_asset_from_dependency_cache'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/loader.rb:44:in `load'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/cached_environment.rb:20:in `block in initialize'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/cached_environment.rb:47:in `yield'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/cached_environment.rb:47:in `load'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/sprockets-3.4.0/lib/sprockets/base.rb:66:in `find_asset'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/teaspoon-1.1.1/lib/teaspoon/suite.rb:53:in `block in asset_tree'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/teaspoon-1.1.1/lib/teaspoon/suite.rb:52:in `each'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/teaspoon-1.1.1/lib/teaspoon/suite.rb:52:in `flat_map'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/teaspoon-1.1.1/lib/teaspoon/suite.rb:52:in `asset_tree'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/teaspoon-1.1.1/lib/teaspoon/suite.rb:33:in `spec_assets'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/teaspoon-1.1.1/app/views/teaspoon/suite/_boot.html.erb:1:in `___sers_richardschneeman__gem_ruby_______gems_teaspoon_______app_views_teaspoon_suite__boot_html_erb__3353771346276396505_2226067340'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/template.rb:145:in `block in render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications.rb:166:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/template.rb:333:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/template.rb:143:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/partial_renderer.rb:339:in `render_partial'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/partial_renderer.rb:310:in `block in render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/abstract_renderer.rb:39:in `block in instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications.rb:164:in `block in instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications.rb:164:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/abstract_renderer.rb:39:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/partial_renderer.rb:309:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/renderer.rb:47:in `render_partial'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/helpers/rendering_helper.rb:35:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/teaspoon-1.1.1/app/views/teaspoon/suite/show.html.erb:14:in `___sers_richardschneeman__gem_ruby_______gems_teaspoon_______app_views_teaspoon_suite_show_html_erb___3887593104531129198_2246705480'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/template.rb:145:in `block in render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications.rb:166:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/template.rb:333:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/template.rb:143:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb:54:in `block (2 levels) in render_template'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/abstract_renderer.rb:39:in `block in instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications.rb:164:in `block in instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications.rb:164:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/abstract_renderer.rb:39:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb:53:in `block in render_template'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb:61:in `render_with_layout'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/skylight-0.8.1/lib/skylight/probes/action_view.rb:25:in `render_with_layout'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb:52:in `render_template'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/template_renderer.rb:14:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/renderer.rb:42:in `render_template'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/renderer/renderer.rb:23:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/rendering.rb:100:in `_render_template'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/streaming.rb:217:in `_render_template'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/rendering.rb:83:in `render_to_body'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/rendering.rb:32:in `render_to_body'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/renderers.rb:37:in `render_to_body'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/abstract_controller/rendering.rb:25:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/rendering.rb:16:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb:44:in `block (2 levels) in render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/core_ext/benchmark.rb:12:in `block in ms'
/Users/richardschneeman/.rubies/ruby-2.2.3/lib/ruby/2.2.0/benchmark.rb:303:in `realtime'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/core_ext/benchmark.rb:12:in `ms'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb:44:in `block in render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb:87:in `cleanup_view_runtime'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activerecord-4.2.3/lib/active_record/railties/controller_runtime.rb:25:in `cleanup_view_runtime'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb:43:in `render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/implicit_render.rb:10:in `default_render'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/implicit_render.rb:5:in `send_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/abstract_controller/base.rb:198:in `process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/rendering.rb:10:in `process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/abstract_controller/callbacks.rb:20:in `block in process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/callbacks.rb:115:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/callbacks.rb:115:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/callbacks.rb:553:in `block (2 levels) in compile'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/callbacks.rb:503:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/callbacks.rb:503:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/callbacks.rb:88:in `run_callbacks'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/abstract_controller/callbacks.rb:19:in `process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/rescue.rb:29:in `process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb:32:in `block in process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications.rb:164:in `block in instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/notifications.rb:164:in `instrument'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/instrumentation.rb:30:in `process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/params_wrapper.rb:250:in `process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activerecord-4.2.3/lib/active_record/railties/controller_runtime.rb:18:in `process_action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/abstract_controller/base.rb:137:in `process'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionview-4.2.3/lib/action_view/rendering.rb:30:in `process'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal.rb:196:in `dispatch'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal/rack_delegation.rb:13:in `dispatch'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_controller/metal.rb:237:in `block in action'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/routing/route_set.rb:76:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/routing/route_set.rb:76:in `dispatch'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/routing/route_set.rb:45:in `serve'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/journey/router.rb:43:in `block in serve'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/journey/router.rb:30:in `each'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/journey/router.rb:30:in `serve'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/routing/route_set.rb:821:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/railties-4.2.3/lib/rails/engine.rb:518:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/railties-4.2.3/lib/rails/railtie.rb:194:in `public_send'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/railties-4.2.3/lib/rails/railtie.rb:194:in `method_missing'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/routing/mapper.rb:51:in `serve'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/journey/router.rb:43:in `block in serve'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/journey/router.rb:30:in `each'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/journey/router.rb:30:in `serve'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/routing/route_set.rb:821:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/bundler/gems/omniauth-3c4b79504eb5/lib/omniauth/strategy.rb:185:in `call!'
/Users/richardschneeman/.gem/ruby/2.2.3/bundler/gems/omniauth-3c4b79504eb5/lib/omniauth/strategy.rb:163:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/warden-1.2.3/lib/warden/manager.rb:35:in `block in call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/warden-1.2.3/lib/warden/manager.rb:34:in `catch'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/warden-1.2.3/lib/warden/manager.rb:34:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/etag.rb:24:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/conditionalget.rb:25:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/head.rb:13:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/params_parser.rb:27:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/flash.rb:260:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:225:in `context'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:220:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/cookies.rb:560:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activerecord-4.2.3/lib/active_record/query_cache.rb:36:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activerecord-4.2.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:653:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/callbacks.rb:84:in `run_callbacks'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/callbacks.rb:27:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/remote_ip.rb:78:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/railties-4.2.3/lib/rails/rack/logger.rb:38:in `call_app'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/railties-4.2.3/lib/rails/rack/logger.rb:20:in `block in call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/tagged_logging.rb:68:in `block in tagged'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/tagged_logging.rb:26:in `tagged'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/tagged_logging.rb:68:in `tagged'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/railties-4.2.3/lib/rails/rack/logger.rb:20:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/request_id.rb:21:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/methodoverride.rb:22:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/runtime.rb:18:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/activesupport-4.2.3/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/lock.rb:17:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/actionpack-4.2.3/lib/action_dispatch/middleware/static.rb:116:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/rack-1.6.4/lib/rack/sendfile.rb:113:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/railties-4.2.3/lib/rails/engine.rb:518:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/railties-4.2.3/lib/rails/application.rb:165:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/puma-2.14.0/lib/puma/server.rb:541:in `handle_request'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/puma-2.14.0/lib/puma/server.rb:388:in `process_client'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/puma-2.14.0/lib/puma/server.rb:270:in `block in run'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/puma-2.14.0/lib/puma/thread_pool.rb:106:in `call'
/Users/richardschneeman/.gem/ruby/2.2.3/gems/puma-2.14.0/lib/puma/thread_pool.rb:106:in `block in spawn_thread'

using
  * teaspoon (1.1.1)
  * teaspoon-jasmine (2.3.4)

My file looks like this:
#= require application
#=require support/sinon
#=require support/chai
#=require support/javascript_helpers.js

Are there upgrade guides somewhere?

Chai is still there. I'll look into this. Thanks for reporting.

Oh, sorry, noticing you're using teaspoon-jasmine. Chai ships with teaspoon-mocha. Which framework were you using prior to upgrading?

Upgrade notes to 1.0: https://github.com/modeset/teaspoon/blob/master/CHANGELOG.md#100-5415

That will probably do it, thanks for the quick response!


Application Provides Break Notification Out of Sync With Time

Issue Label: [Bug,Feauture,Enhancement]
Notification at the Wrong Time
Description of bug or feature enhancement:
I set my time to wake up at 6:30am the next day at 12:05 PM today and then closed the app, but the app has two notifications pop up every 2 minutes or so saying my computer needs a break with the option to dismiss or restart.
I installed the application last night and set a time in it and went to sleep, however when I woke up there were 20+notifications and I had to force close the application to clear it.
OS and OS version:
Windows 10
Version of Insomnia Application:
Insomnia Version 1.4.1
Node.js Version 7.4.0
Chromium Version 56.0.2924.87
Electron Version 1.6.6

I have noticed this as well it stems from not shutting down the computer when you go to bed (an assumption I made) although I found I don't really do this either. I've already thought of a fix that includes maximizing the duration of the notification to infinity (you have to click on it, swipe right or click dismiss for it to go away) which will allow me to make sure only one notification of each type can be showing at a time. This will not get rid of the problem but when opening your computer after resting the most notifications you will ever see is 3. Hopefully that's small enough to prevent the need of a force restart.

 The infinity time on the notification sounds like a good fix.
The other issue was the program did not reset itself for the next day. I
tried to use the program for today and it was still notifying me for
yesterday I think cause 2 notifications were popping up every 2 minutes so
I had to shut it off.
On May 6, 2017 12:50 PM, "Alex Epstein"<EMAIL_ADDRESS>wrote:

I have noticed this as well it stems from not shutting down the computer
when you go to bed (an assumption I made) although I found I don't really
do this either. I've already thought of a fix that includes maximizing the
duration of the notification to infinity (you have to click on it, swipe
right or click dismiss for it to go away) which will allow me to make sure
only one notification of each type can be showing at a time. This will not
get rid of the problem but when opening your computer after resting the
most notifications you will ever see is 3. Hopefully that's small enough to
prevent the need of a force restart.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alexanderepstein/Insomnia/issues/35#issuecomment-299652142,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATJh3Prv3gdIUKDkfGk6tF07XU4CG5Dwks5r3KS8gaJpZM4NS0LF
.

Were they rest notifications? That shouldn't happen the way the scheduling works is it uses an exact date not a time so notifications for yesterday should never show up today.

I am not sure if they were actually from yesterday or not.  They seemed to happen after I set my wakeup time for tomorrow. It
was a little annoying that two notifications would show up as well to "
Dismiss" or "Restart."
On May 6, 2017 12:59 PM, "Alex Epstein"<EMAIL_ADDRESS>wrote:

Were they rest notifications? That shouldn't happen the way the scheduling
works is it uses an exact date not a time so notifications for yesterday
should never show up today.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alexanderepstein/Insomnia/issues/35#issuecomment-299652752,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATJh3OUllw_NKfJV9lZ77GcuU289OvCIks5r3KbqgaJpZM4NS0LF
.

I also made sure only one notification of that type should show up. I hope this commit  29f0eb9f100b3e832561e6554adff0ec484a1982 works out all the kinks you described above. It seems to work with the rest notification and should work with the uptime notification as well. I also reset the new sleep times of the day one hour after your last possible rest notification.

I just ran the app and set it again and I'm not getting any notifications
like before.
On May 6, 2017 1:10 PM, "Matt Roberts"<EMAIL_ADDRESS>wrote:

I am not sure if they were actually from yesterday or not.  They seemed to happen after I set my wakeup time for tomorrow. It
was a little annoying that two notifications would show up as well to "
Dismiss" or "Restart."
On May 6, 2017 12:59 PM, "Alex Epstein"<EMAIL_ADDRESS>wrote:

Were they rest notifications? That shouldn't happen the way the
scheduling works is it uses an exact date not a time so notifications for
yesterday should never show up today.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alexanderepstein/Insomnia/issues/35#issuecomment-299652752,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATJh3OUllw_NKfJV9lZ77GcuU289OvCIks5r3KbqgaJpZM4NS0LF
.

Are you using the version i just pushed or the the application version of 1.4.1?

1.4.1 right now. No automatic updates right? When installing yesterday your
download link didnt work for a second, but you must have been updating. How
do I enact the recent update?
On May 6, 2017 1:28 PM, "Alex Epstein"<EMAIL_ADDRESS>wrote:

Are you using the version i just pushed or the the application version of
1.4.1?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alexanderepstein/Insomnia/issues/35#issuecomment-299654342,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATJh3EyUtk1ciA3HKILS3s3zFTEWuCqxks5r3K20gaJpZM4NS0LF
.

Your bug that i hopefully fixed will be version 1.4.2 it hasn't been released yet. I was curious if you were running my application through the electron framework. Hopefully ill have the update released by tonight

I dont know what electron framework is so can't say. Thanks for providing
this app. I have shift work starting next week so I'm hoping this can help
me get good sleep even in weird hours
On May 6, 2017 1:35 PM, "Alex Epstein"<EMAIL_ADDRESS>wrote:
Your bug that i hopefully fixed will be version 1.4.2 it hasn't been
released yet. I was curious if you were running my application through the
electron framework. Hopefully ill have the update released by tonight
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alexanderepstein/Insomnia/issues/35#issuecomment-299654809,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATJh3Jy9ruTV22mUZBUBNvBsPMUHkb-Hks5r3K9rgaJpZM4NS0LF
.

@northern11 I hope it helps as well! Version 1.4.2 was just released with the bugfixes mentioned in this thread


HIVE-21488 Update Apache Parquet to 1.10.1

Fixes two bugs which were discovered in Apache Spark:
https://github.com/apache/parquet-mr/blob/master/CHANGES.md#version-1101

Hi @Fokko
What's the hive Jira number for this...
If Jira is not available, then please create Jira card,

Create git diff patch
Upload the patch to Jira
Then submit patch

I've opened up a ticket: https://jira.apache.org/jira/browse/HIVE-21488

Thanks, please submit the patch file in Jira.

Thanks @rmsmani, I've submitted the patch.
Would it be possible to backport this to Hive 2.x as well?

The master branch is already at Parquet 1.11.0. thereby obsoleting this request:
https://issues.apache.org/jira/browse/HIVE-22648
If however you want this to be in Hive2 then you will need to open a new PR with a PR against Hive branch-2


Have not support ES5 the package published to npm?

So said that only a lib/randexp.js file provided  from NPM.
In most cases we do like that the dependencies is valid on brorwer(build with ES5), like react,vue,jquery and so on.

I have find the problem is that even then my package defined that rely on 0.4.4, but after npm install, what i have download is the latest version of 0.4.9.
But I don't why, maybe it's a problem of npm, but I do hope that the future version still be a browser-able plugin.


File "/public/home/huangchensen/miniconda3/envs/pytorch21/lib/python3.9/site-packages/vllm/executor/ray_gpu_executor.py", line 324, in _run_workers     driver_worker_output = getattr(self.driver_worker,   File "/public/home/huangchensen/miniconda3/envs/pytorch21/lib/python3.9/site-packages/vllm/worker/worker.py", line 100, in init_device     init_distributed_environment(self.parallel_config, self.rank,   File "/public/home/huangchensen/miniconda3/envs/pytorch21/lib/python3.9/site-packages/vllm/worker/worker.py", line 287, in init_distributed_environment     pynccl_utils.init_process_group(   File "/public/home/huangchensen/miniconda3/envs/pytorch21/lib/python3.9/site-packages/vllm/model_executor/parallel_utils/pynccl_utils.py", line 46, in init_process_group     comm = NCCLCommunicator(init_method=init_method,   File "/public/home/huangchensen/miniconda3/envs/pytorch21/lib/python3.9/site-packages/vllm/model_executor/parallel_utils/pynccl.py", line 249, in init     assert result == 0 AssertionError

Your current environment
The output of `python collect_env.py`

How would you like to use vllm
I want to run inference of a [specific model](put link here). I don't know how to integrate it with vllm.

Please provide more information about your environment by running the command shown under "Your current environment" in your post.
(Also, you should put the error message in the post itself, not the title)

Closing as stale. It may be reopened if you provide more information.


[Suggestion] Mirrors Edge Catalyst Animations?

would it be possible to add MEC animations for Beatrun? such as for the Safety roll, jump, slide and maybe running?
or do you only ever plan to have just 2 animation types. the "original animations" and "beatrun reanimated"?
just wondering

only 2 animation types that we will focus on.
unless anyone are willing enough to make their own beatrun MEC animations compatible for beatrun, then go ahead.

it would be super cool tho


Retiring Electrs Wrapper

Task Description
Once the electrum-client and server are established and the modules have been updated to use the JSON-RPC, we'll retire the Electrs wrapper.

As all the apps, Hexa2.0, Pledge, and Keeper are going to use the same Server, if we retire the Wrapper before updating all the apps with electrum-client, the other apps would stop syncing.

Dependencies

#745

We've implemented this.


Horizontal and Vertical Split like Terminator

Is it possible in hyperterm to split the window horizontally and vertically, like in terminator?

No, it's a work in progress - see #56 :)

Closing as duplicate.


Testing

adding testing and specific code to help reviewers, svm analyis not included yet.

This PR is ready for peer review, I hope it will help with the review process
@mikerspencer, @aj2duncan.

This PR is ready for peer review, I hope it will help with the review process
@mikerspencer, @aj2duncan.


error to create a symfony4 project

I am not able to create a symfony4 project in my computer i have this error:
[InvalidArgumentException]
Could not find package symfony/skeleton with stability stable in a version installable using your PHP vers
ion 5.6.25.
create-project [-s|--stability STABILITY] [--prefer-source] [--prefer-dist] [--repository REPOSITORY] [--repository-url REPOSITORY-URL] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [--no-secure-http] [--keep-vcs] [--remove-vcs] [--no-install] [--ignore-platform-reqs] [--] [] [] []

Sure, because this project requires PHP version 7.1.3 or above.
"php": "^7.1.3"

Actually the skeleton supports also 7.0, using branch 3.4. But that wouldn't change the issue for you.
You can start with the standard edition instead: https://github.com/symfony/symfony-standard/
Or upgrade PHP (would be the best).

thank you ,  it work
2018-02-18 15:50 GMT+01:00 Nicolas Grekas<EMAIL_ADDRESS>
Closed #59 https://github.com/symfony/skeleton/issues/59.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/symfony/skeleton/issues/59#event-1479525780, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATzyDawuL78Vx28j4WlSPpttZh3L1xi7ks5tWDidgaJpZM4SJpel
.


[feat]: how to add shadcn

Feature description
how to add shadcn? i can't use shadcn
npx shadcn@latest init
✔ Preflight checks.
✖ Verifying framework.
We could not detect a supported framework.
Visit https://ui.shadcn.com/docs/installation/manual to manually configure your project.
Once configured, you can use the cli to add components.
Affected component/components
No response
Additional Context
Additional details here...
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues and PRs

I use electron vite

please check this!


runToMain should be runToEntryPoint in generated VSCode launch.json

The launch.json file that is generated if Create VSCode Project is selected contains a line:
   "runToMain": true,

The runToMain option has been depreciated in Cortext-Debug for VSCode since v0.3.12 and been replaced with runToEntryPoint.
So the line in launch.json should be:
    "runToEntryPoint": "main",

Fixed


Shipment details does not loaded if user is logged

Current behavior
When the user is in checkout and is logged the shipment details are not loaded from account.
Expected behavior
The shipment detail loaded if shipToMyAddressCheckbox is selected. I need to deactivate and activate after it works.
Steps to reproduce the issue

Login in your account
Add product and go to checkout
Click on personal submit
Shipment detail form is displayed but without the info
Uncheck and check the button and the info is correctly loaded now.

Can you handle fixing this bug by yourself?

[ ] YES
[ x] NO

Environment details

Browser: Chrome, Safari
OS: Windows, iOS
Code Version:  vue-storefront 1.11.4, vsf-default master

Additional information
The info is doesn't loaded from database, need some manual action (check and uncheck).

Fixed by @AdamPawlinski


Add minimal spacing to nodes to prevent overlap

Description

Implementation ideas
No response

Hi, thanks for the feedback. This is most definitely a good idea.


bareflank_astyle_format.sh and bareflank_clang_tidy.sh try to process deleted files

Because these scripts use git ls-files to determine which files to process, they attempt to process files that have been deleted from the working tree but not from the index. git ls-files doesn't appear to have an option to exclude deleted files, but it does have one to emit only deleted files, so the following somewhat long-winded replacement should work:
git ls-files | sort | comm -23 - <( git ls-files -d | sort )

If we're not going to fix this we should at least document it; it took me way too long to figure out where they were getting the names of files I had removed...

I'd love to see a PR here. Although, it would be great if there was a better solution for getting the files.

I'd love to see a PR here.

I was waiting first to see if anyone had input on...

Although, it would be great if there was a better solution for getting the files.

:stuck_out_tongue:

This has been fixed


Fix pytest import

pfnCI, test this please.

Jenkins CI test (for commit 917963e50ca03e81e1682cadd4a9cab90fc4ee86, target branch master) failed with status FAILURE.

Jenkins, test this please

Jenkins CI test (for commit 917963e50ca03e81e1682cadd4a9cab90fc4ee86, target branch master) failed with status FAILURE.

pfnCI, test this please.

Jenkins CI test (for commit ebf3c428dcfdeb25ad88c2a5606b6bc22e747230, target branch master) failed with status FAILURE.


Backend : Search API pagination is not working as expected.

Affected module
Does it impact the UI, backend or Ingestion Framework?
Backend.
Describe the bug
A clear and concise description of what the bug is.
I am making search queries with size=10 but getting all the responses.
https://sandbox-beta.open-metadata.org/api/v1/search/query?q=*&index=table_search_index&size=10
To Reproduce
Screenshots or steps to reproduce
Expected behavior
A clear and concise description of what you expected to happen.
Should return the paginated response.
Version:

OS: [e.g. iOS]
Python version:
OpenMetadata version: [e.g. 0.12]
OpenMetadata Ingestion package version: [e.g. openmetadata-ingestion[docker]==XYZ]

Additional context
Add any other context about the problem here.

@chirag-madlani update the ticket with the details since you were testing this.

@harshach We tested it in local and it's reproducible in local as well with elasticsearch
Sharing screenshot for more context
Request:

Response:


Add support for ChIMES

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Needs conda-forge/chimes-calculator-feedstock#1 to be merged in order to work on all architectures.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Considered in #24


Cannot change directory to mapped network drive (only inside of Windows Terminal)

Windows Terminal version
1.21.2911.0
Windows build number
10.0.19045.5073
Other Software
No response
Steps to reproduce

Open the "command prompt" profile inside of windows terminal
cd /d X:\, where X:\ is a mapped network drive

Expected Behavior
No response
Actual Behavior
Receive the following error message:
The system cannot find the drive specified.

However, if just running cmd.exe, the directory is changed to the mapped network drive as expected.

Issue is actually that wt is running as admin. Closing, sry


Translations update from Weblate

Translations update from Weblate for mattermost-languages-shipped/mattermost-webapp_master.

Hello @weblate,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.


Missing Fields from Payload Version Format v2.0

Framework version: 1.5.2
Implementations: Spring Boot 2
Scenario
Setup springboot Lambda handler for HttpApiV2 using SpringBootLambdaContainerHandler.getHttpApiV2ProxyHandler
Deploy to AWS.
Invoke lambda.
Expected behavior
Lambda successfully executes for resource specified.
Actual behavior
Jackson deserialization error:
com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "resource" (class com.amazonaws.serverless.proxy.model.HttpApiV2ProxyRequest), not marked as ignorable (12 known properties: "requestContext", "rawQueryString", "body", "queryStringParameters", "isBase64Encoded", "routeKey", "version", "stageVariables", "rawPath", "cookies", "headers", "pathParameters"])
Steps to reproduce
Deploy lambda using JerseyLambdaContainerHandler.getHttpApiV2ProxyHandler to AWS environment and invoke with valid request via ApiGateway.
Full log output

@rockey5520 what's the trigger to your lambda?

This lambda is wired to http API gateway for invocation

HttpApiV2ProxyRequest request model only accepts requests coming from the API gateway of type HTTP and will always throw this exception when the request is coming from any other source.

But requests are made via http in my case

use any logger/converter and check what data is coming to the lambda in the input stream, it might help.
Additionally, just to be sure check the payload version that u are setting when defining in apigw

I agree with @srp321, see https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html for Payload version 2.0 and 1.0. Resource sounds like version 1.0 and in this case getHttpApiV2ProxyHandler is the wrong method.
Therefore I'm closing this issue for now, feel free to reopen with additional information.