[bug] Running moon in codesandbox ci throws an GLIBC error

Describe the bug

Hello,
I'm not sure if this is an issue with moonrepo or codesandbox ci, but when running moon build via yarn in the codesanbox environment the following error is thrown:
yarn run moon run :build (in /tmp/4d7ea44c)
/tmp/4d7ea44c/node_modules/@moonrepo/cli/moon: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /tmp/4d7ea44c/node_modules/@moonrepo/cli/moon)
{ Error: Process rejected with status code 1
    at ChildProcess.<anonymous> (/app/dist/utils/exec.js:20:27)
    at ChildProcess.emit (events.js:198:13)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12) code: 1 }
/tmp/4d7ea44c/node_modules/@moonrepo/cli/moon: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /tmp/4d7ea44c/node_modules/@moonrepo/cli/moon)
{ Error: Process rejected with status code 1
    at ChildProcess.<anonymous> (/app/dist/utils/exec.js:20:27)
    at ChildProcess.emit (events.js:198:13)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12) code: 1 }

I'm using yarn 3.2.3 and have moon assign to script as:
"moon": "$(yarn bin moon)"

Steps to reproduce
Here is a link to the codesandbox build:
https://ci.codesandbox.io/status/project44/manifest/pr/147/builds/310618
and the PR in question:
https://github.com/project44/manifest/pull/147
Expected behavior
I would assume that the binary when ran via yarn should work in most node environments.
Screenshots

Environment
node -v (in /tmp/4d7ea44c)
v16.13.0
yarn -v (in /tmp/4d7ea44c)
3.2.3

Additional context

@bclark-p44 This is typically caused by the environment running an old Linux distro, probably Ubuntu 18, and the required libc doesn't exist, or is too old. There's not an easy solution to this, these are the options:

Run moon and your repo in a Docker container that has the right environment and libs.
Upgrade the Linux distro to a newer one.
Try and install newer libc: https://stackoverflow.com/questions/72513993/how-install-glibc-2-29-or-higher-in-ubuntu-18-04

Here's some more context on the problem: https://kobzol.github.io/rust/ci/2021/05/07/building-rust-binaries-in-ci-that-work-with-older-glibc.html


Routing service + Router Actor example

Here is a new routing implementation to replace the one proposed in https://github.com/DenisKolodin/yew/pull/187.
It creates a bare-minimum routing service around which an opinionated Router Agent is constructed and then used in a new example.

@hgzimmerman It looks interesting :+1: Could you temporary move RouterService to example/router/src/ folder? Routing is a fragile topic and we need to test the solution before before joining users to it.
I think we also need later:

[ ] Consider adding on_mount method or determine the routing process (the second is safer)
[ ] Consider to use fragment identifier for routing or add support of extra path parameters to cargo-web for testing routing

I agree that an on_mount hook could lead to confusion among users of Yew regarding what operations go in there vs create. It would be better if users could just keep all of their initialization logic in create. I don't think this is a routing-specific example, any agent may be contacted at component start-up time and users may rely on that to affect the state of their component via the update mechanism. An alternative to on_mount could use some queue mechanism to hold outgoing or incoming messages until the component is mounted, at which point the queue is flushed and discarded. This would mean that a some amount of extra computation would have to take place in order to mount components, even if they don't send any messages.

I'm working on a more powerful routing implementation then the one provided here in another branch. It doesn't change much that is already here, but It adds a component that takes as its props, a vector of function pointers to functions that create Components. All the user needs to do is implement a Routable trait on their component and provide the constant function pointers to the YewRouter component to enable routing. Once proc macros land, deriving the Routable trait should be possible as well. I'll update this post with a link to a repo once I set that up.

@hgzimmerman Thank you make brave experiments! We should find elegant implementation of this hard issue. I also want to help solving this issue when I'll get to this topic. You also could send other implementations to examples till we could choose/join the best. This PR is ready to roll! :tada:

bors r+


Improvement/Bug in contextual inference where the call-site is generic.

Feature request / Bug report
🔍 Search Terms
Contextual inference, generic call-site
✅ Viability Checklist
My suggestion meets these guidelines:

[x]  This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x]  This wouldn't change the runtime behavior of existing JavaScript code
[x]  This could be implemented without emitting different JS based on the types of the expressions
[x]  This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x]  This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion / Problem
Let's first study contextual inference in different scenarios. Playground for code below. Highly recommended to view it in the playground so that you can see where are the red underlines, what is the inference and what are the completions.
type X<T = never> = { $: "foo" | T }
declare const $1: <Z>(x: Z) => { $: Z }
declare const $2: <Z>(x: NoInfer<Z>) => { $: Z }
type NoInfer<T> = [T][T extends any ? 0 : never]

let _: X;
_ = $1("")               // s1t1 - Z is inferred as "" and does not compile ........................ ok
_ = $2("")               // s1t2 - Z is inferred as "foo" and does not compile ..................... nice
_ = $1("foo")            // s1t3 - Z is inferred as "foo" and compiles ............................. ok
_ = $2("foo")            // s1t4 - Z is inferred as "foo" and compiles ............................. nice

declare const m1: (x: X) => void
m1($1(""))               // s2t1 - Z is inferred as "" and does not compile ........................ ok
m1($2(""))               // s2t2 - Z is inferred as "foo" and does not compile ..................... nice
m1($1("foo"))            // s2t3 - Z is inferred as "foo" and compiles ............................. ok
m1($2("foo"))            // s2t4 - Z is inferred as "foo" and compiles ............................. nice

declare const m2: <T>(x: InferStringLiteral<T>, _: X<NoInfer<T>>) => void
type InferStringLiteral<T> = T extends string ? T : string
m2("a", $1(""))          // s3t1 - Z is inferred as "" and does not compile ........................ ok
m2("a", $2(""))          // s3t2 - Z is inferred as "foo" | "a" and does not compile ............... nice
m2("a", $1("foo"))       // s3t3 - Z is inferred as "foo" and compiles ............................. ok
m2("a", $2("a"))         // s3t4 - Z is inferred as "foo" | "a" and compiles ....................... nice

declare const m3: (_: { x: X }) => void
m3({ x: $1("") })        // s4t1 - Z is inferred as "" and does not compile ........................ ok
m3({ x: $2("") })        // s4t2 - Z is inferred as "foo" and does not compile ..................... nice
m3({ x: $1("foo") })     // s4t3 - Z is inferred as "foo" and compiles ............................. ok
m3({ x: $2("foo") })     // s4t4 - Z is inferred as "foo" and compiles ............................. nice

declare const m4: <T extends { a?: number, x: X<keyof T> }>(_: T) => void
m4({ x: $1(""), a: 1 })  // s5t1 - Z is inferred as "" and does not compile ........................ ok
m4({ x: $2(""), a: 1 })  // s5t2 - Z is inferred as string | number | symbol and does not compile... ugh
                         //        (quickinfo is incorrect see #44879)
m4({ x: $1("a"), a: 1 }) // s5t3 - Z is inferred as "a" and does not compile ....................... ok
m4({ x: $2("a"), a: 1 }) // s5t4 - Z is inferred as string | number | symbol and does not compile .. ughhh
                         //        (quickinfo is incorrect see #44879)

declare const m5: <T, U extends X<T>>(a: InferStringLiteral<T>, x: U) => void
m5("a", $1(""))          // s6t1 - Z is inferred as "" and does not compile ........................ ok
m5("a", $2("foo"))       // s6t2 - Z is inferred as unknown and does not compile.................... ugh
                         //        (quickinfo is incorrect see #44879)
m5("a", $1("a"))         // s6t3 - Z is inferred as "a" and does not compile ....................... ok
m5("a", $2("a"))         // s6t4 - Z is inferred as unknown and does not compile ................... ughhh
                         //        (quickinfo is incorrect see #44879)

The contextual inference is expected and consistent for s1, s2, s3 & s4. But weird yet consistent for s5 & s6.

I think the following should be the expected behavior...
s5t2 - Z is inferred as "foo" | "a" | "x" and does not compile
s5t4 - Z is inferred as "foo" | "a" | "x" and compiles
s6t2 - Z is inferred as "foo" | "a" and does not compile
s6t4 - Z is inferred as "foo" | "a" and compiles

In s5t4 & s6t4, "a" is one of the completions but they are incorrect because the language server infers the type parameter different from the compiler. This is most probably a bug which might be accommodated in #44879. So all in all the completions are useless and when the language server is fixed there would be no completions.

Generally speaking, a sugar-like abstraction should not result in compromises in developer experience. If you inline $*("")  as { $: "" } in s5 & s6 then the completions and the compiler would work as expected.

My analysis is that when the type expected from calling  $* is generic itself (ie s5 & s6) then compiler can't infer the type parameter Z correctly. It resolves all other generics to unknown hence the type parameter Z is inferred as  keyof unknown and unknown in s5 and s6, respectively.
Aside: Though I would expected other generics to resolve to their constraint meaning I'd have expected (like not ultimately but considering the weirdness itself) the type parameter of $2 in the following scenario as "a" | "b" instead of unknown. Playground.
type X<T = never> = { $: T | "foo" }
declare const m6: <T extends "a" | "b", U extends X<T>>(a: T, x: U) => void
m6("a", $2("a")) // Z is inferred as unknown

declare const $2: <Z>(x: NoInfer<Z>) => { $: Z }
type NoInfer<T> = [T][T extends any ? 0 : never]

#44999 is most probably the consequence of this weirdness as it fits the precondition and it's marked as a bug, so imo this should be also be considered as a bug. It's not apparent because the repros are vague but hopefully the following examples would make it more clear how essential it is to get this right.

Maybe $1should work same as $2

📃 Motivating Example
Library authors provide sugar-like abstractions all the time. Take the following as an example. Playground.
createColors({
  base: { primary: "red" },
  derived: {
    primary400: lightenWithNoInfer("primary", 0.4), // does not compile
    primary500: lightenWithoutNoInfer("primary", 0.5), // does not compile
    primary600: lightenWithoutNoInfer("primary" as const, 0.6),
    primary700: lightenWithoutNoInferWithInferStringLiteral("primary", 0.7)
  }
})

declare const createColors: <C extends string>(theme:
  { base: { [colorIdentifier in C]: Color }
  , derived:
      { [derivedColor in string]:
          { base: NoInfer<C> // `NoInfer` so that `C` is inferred only from `base`
          , operation: (c: Color) => Color
          }
      }
  }) => "TODO"

declare const lightenWithNoInfer:
  <Z>(base: NoInfer<Z>, weight: number) =>
    { base: Z
    , operation: (c: Color) => Color
    }

declare const lightenWithoutNoInfer:
  <Z>(base: Z, weight: number) =>
    { base: Z
    , operation: (c: Color) => Color
    }

declare const lightenWithoutNoInferWithInferStringLiteral:
  <Z>(base: InferStringLiteral<Z>, weight: number) =>
    { base: Z
    , operation: (c: Color) => Color
    }

type Color = string;
type NoInfer<T> = [T][T extends any ? 0 : never]
type InferStringLiteral<T> = T extends string ? T : never

None of the lighten version is good.

lightenWithNoInfer has completions but are incorrect and doesn't compile
lightenWithoutNoInfer infers Z as string instead of "primary" hence doesn't compile
lightenWithoutNoInferWithInferStringLiteral compiles but has no completions

If I were to be frank, there is no rocket science going on here, lightenWithoutNoInfer (or at least lightenWithNoInfer) should "just work" with completions and compilation.
And the problem isn't about string literals per se. Here's another real world example from xstate. Playground.
createMachine({
  schema: { event: createSchema<{ type: "FETCH" }>() },
  initial: "idle",
  states: {
    idle: {
      entry: send({ type: "FETCH" }), // does not compile
      on: {
        FETCH: "fetching"
      }
    },
    fetching: {}
  }
})

declare const createMachine: <State extends string, Event extends { type: string }>(m:
  { schema: { event: Event } // we want `Event` to be inferred only from here
  , initial: NoInfer<State>
  , states:
    { [S in State]: // we want `State` to be inferred only from here
        { entry?:
          | { type: "xstate.send"
            , event: NoInfer<Event>
            }
      , on?:
          { [E in Event["type"]]?: NoInfer<State>
          }
      }
    }
  }) => void

declare const send:
  <E>(event: NoInfer<E>) => { type: "xstate.send", event: E }

declare const createSchema: <T>() => T
type NoInfer<T> = [T][T extends any ? 0 : never];

The problem exactly is same as above. And here you can even inline send({ type: "FETCH" }) to { type: "xstate.send", type: "FETCH" } and it compiles and even provides completions.
Aside: If we add { type: string } to the entry union send("") compiles but { type: "xstate.send", event: "" } doesn't, which is kinda weird too because both are equivalent.
💻 Use Cases
Any case where the type parameters of a function are to be inferred from the return type instead of parameters AND location of the function call is a generic; is a use case. I suspect this improvement/bugfix will have a huge impact especially for library authors. Probably there are some folks out there banging theirs heads to make the completions work when they should probably "just work" without having to do anything.
Some "workarounds"
For s5
declare const $:
  < R
  , Z extends R extends { $: infer X } ? X : never>
    (x: Z) => R & { $: Z }

For lighten
declare const lighten:
  < R
  , C extends R extends { base: infer X } ? X : never>
    (base: C, weight: number) =>
      & R
      & { base: C
        , operation: (c: Color) => Color
        }

For send
declare const send:
  < R
  , E extends R extends { event: infer X } ? X : never>
    (event: E) =>
      & R
      & { type: "xstate.send", event: E }

All the above provide completions and compile too. Though complex cases like s4 don't work with this workaround.
Thanks for reading!

Here's a slightly modified but super compact version of my "feature request" -
declare const m: <T extends { $: "a" | "b" }>(x: T) => T
declare const $: <Z>(x: Z) => { $: Z }

let x = m($(""))
// `Z` should be `"a" | "b"` (corollary - user should get "a" and "b" as completions)
// `typeof x` should be `{ $: "a" | "b" }`

let y = m($("a"))
// `Z` should be `"a"`
// `typeof y` should be `{ $: "a" }`

I missed an important nuance in the original proposal that Z derive the constraint from the return type BUT should be derived from the parameter when it satisfies the constraint. This is not possible right now even with NoInfer so 0 out of the 24 cases match this desired behavior. The rational is that this exactly how it works if you inline $ -
declare const m: <T extends { $: "a" | "b" }>(x: T) => T

let x = m({ $: "" })
// `typeof $` is `"a" | "b"` and user gets "a" and "b" as completions
// `typeof x` is `{ $: "a" | "b" }`

let y = m({ $: "a" })
// `typeof $` is `"a"`
// `typeof y` is `{ $: "a" }`

let x = m($(""))
// `Z` should be `"a" | "b"` (corollary - user should get "a" and "b" as completions)
// `typeof x` should be `{ $: "a" | "b" }`

The only plausible implementations of $ and m (identity functions) mean that the value "" would inhabit a reference of type "a" | "b". Some justification is needed here

First off - Let me make myself clear that this was only a "TLDR version" and a minimal "test case" to show the desired behavior. It's not a replacement for the full proposal in the original description (especially the real world examples). So please do give it a read just in case you haven't :)

identity functions

Though it's not always the case, for example lighten in the above example isn't an "identity" function. Or to put in better terms it's not a sugar, the operation implementation is written library-land that comes with lighten.

the value "" would inhabit a reference of type "a" | "b"

I'm not sure what you mean by this? Are you saying the user would mostly never write literals and it would be $(x) where x would have already have a type "a" | "b"? Frankly I'm clueless what are you trying to ask 😅

I think he's pointing out that since $() is necessarily an identify function per its typing (Z has no constraint, therefore could be anything, so there's very little you can do with it other than just pass it along as-is), it wouldn't make sense for the result of $("") to be used as input for something expecting "a" | "b".

I don't think Ryan meant that. But to answer that...
First I'm assuming you meant to write "something expecting { $: "a" | "b" }" instead because that's what m is expecting (as it says T extends { $: "a" | "b" }).

so there's very little you can do with it other than just pass it along as-is

Right but only when there it's not used in-place.
let x = $("") // `Z` is inferred as `""` as expected

But when in cases where contextual inference can be applied typescript does infer Z, like here...
let x: { $: "a" | "b" } = $("") // Z is inferred as "a" | "b" as expected

it wouldn't make sense for the result of $("") to be used as input for something expecting "a" | "b".

That is indeed what I meant.

That is indeed what I meant.

Yeah but it expected { $: "a" | "b" } right? T extends { $: "a" | "b" }. The only two possible values of the first parameter of $ are "a" and "b" so why not constraint Z to "a" | "b" via contextual inference? What am I missing here?

Yeah AFAIK, TS infers type parameters only from the function call itself. The assignment target is not used for type inference except in specific cases, e.g. callback parameters.

Continuing from here...

Though if I were to make a critic, I think the foundational problem is TypeScript (to put it naively) doesn't leverage or understand that some functions are essentially "sugars", it can be very easily identified if I write assign as (f: F) => { type: "xstate.assign", exec: F }. The fact that inlining assign compiles says that compiler doesn't really understand fully that assign is essentially just a sugar. I also lay this out in depth in #45035 (I would LOVE it you can share your thoughts on it, it's a little messy in the beginning because I couldn't point my finger on it but later in the comments it's clear).
It would be cool if TypeScript perhaps using some heuristic to identity sugar-like functions, or if I were to propose a solution it would be that TypeScript provides a type that allows the user to mark an inference site to be of lesser priority so that we can type assign like (f: LowInfer) => { type: "xstate.assign", exec: F }. (It's important that it's LowInfer and not NoInfer I'll add a comment in #45035 to point out how it's different)

If I use NoInfer, it partially allows me to attain my desired behavior
declare const m: <T extends { $: "a" | "b" }>(x: T) => T
declare const $: <Z>(x: NoInfer<Z>) => { $: Z }
type NoInfer<T> = [T][T extends any ? 0 : never]

let x = m($(""))
// Desired behaviour:
// `Z` should be `"a" | "b"` (corollary - user should get "a" and "b" as completions)
// `typeof x` should be `{ $: "a" | "b" }`
// Actual behaviour:
// Same

let y = m($("a"))
// Desired behaviour
// `Z` should be `"a"`
// `typeof y` should be `{ $: "a" }`
// Actual behaviour
// `Z` in unknown (the quickinfo is buggy #44879)
// `typeof y` is `{ $: "a" | "b" }`

I think a LowInfer instead of NoInfer would allow me to attain the desired behavior. It would be super cool if as I typescript is smart enough to identify sugar-like functions and can behave in the desired way out of the box but if not that then the LowInfer is the second ideal solution.

@RyanCavanaugh I see you haven't labelled this I assume that's because you haven't got time to look into it and not because something is pending from my side, right? Just want to make sure I'm right in thinking that the ball is in your court 😅

Here's my current understanding of the issue, summarized in a minimal-yet-not-degenerately-minimal form:
type Box<T> = { value: T }
declare function box<T>(x: T): Box<T>;

declare function eatZeroBox(x: Box<0>): void;
// Passes
eatZeroBox(box(0));

declare function eatZeroBoxG<T extends Box<0>>(x: T): void;
// Passes
eatZeroBoxG(box(0 as const));
// Errors, should pass
eatZeroBoxG(box(0));

Is that right?

Yep that's right. But it doesn't test or explain the desired behavior fully, this one does. Your version is  perhaps the most unsound-looking subset of that.

It's incomplete to error more often than you should, not unsound

It's incomplete to error more often than you should, not unsound

Yeah correct excuse my lack of savviness when it comes to wording such things senpai

LowInfer would also improve types for popular libraries like zustand, a minimal version:
const create = <T>(f: (set: (t: Partial<T>) => void) => T): T => {
  let v = f(nV => v = { ...v, ...nV})
  return v;
}

let x = create(set => ({
  foo: 0,
  bar: () => set({
    foo: "lol" // compiles, shouldn't
  })
}))
x.foo // doesn't compile, should

Here T is inferred as unknown because the compiler gives priority to the T in Partial<T> instead of the T in the return type. With LowInfer we can write Partial<LowInfer<T>> and then T would be inferred as { foo: number, bar: () => void }
As of now, user's have to explicitly pass the type parameter which could have been inferred.

The autocomplete issue mentioned here was fixed in 4.7 - despite the fact that the autocomplete argument didn't end up type-checking correctly: TS playground. This was likely fixed by this PR: https://github.com/microsoft/TypeScript/pull/48410
This started to typecheck OK in 4.8 though - and the same can be said about @RyanCavanaugh 's example from this comment and about the lightenWithoutNoInfer case from the main post. You can verify them in this TS playground. Those cases were fixed by this PR: https://github.com/microsoft/TypeScript/pull/49086
So overall, some cases from here were fixed - but some still aren't. It would be cool to distill the non-working cases to a minimal repro to get a better understanding of the difference between all of those cases and why some were fixed when some remain broken~.
An additional interesting fact is that when the inner call has an argument that doesn't satisfy the outer constraint then the inner type param isn't fixed with the information from the outer inference context. @devanshj was suggesting that it should still get fixed with the outer one (TS playground):
declare const m: <T extends { $: "a" | "b" }>(x: T) => T;
declare const $: <Z>(x: Z) => { $: Z };

// actual Z: ""
// expected Z: "a" | "b"
let x = m($("")); // errors correctly

I think that this is totally OK as it doesn't really matter what is inferred as Z here, as long as we end up with an error.

I think that this is totally OK as it doesn't really matter what is inferred as Z here, as long as we end up with an error.

No it's important because what Z is inferred as will decide the contextual type for the argument of $, in some sense that's the whole point of the issue. I think you're viewing this as a seperative case when the fact is it's a distilled case of what should happen in all the above cases.
To give you an example let's take this case. Here the problem is the type parameter of send get's inferred as { type: string } (equivalent of "" from the distilled case) instead of { type: "FETCH" } (equivalent of "a" | "b" from the distilled case). And hence typescript doesn't have the correct contextual type to infer the "FETCH" value as "FETCH" type and not string type and hence the code doesn't compile. So the fact it infers "" instead of "a" | "b" changes everything.
As you said there are improvements in the compiler so let me revisit the distilled case and tick off what's done...
declare const m: <T extends { $: "a" | "b" }>(x: T) => T
declare const $: <Z>(x: Z) => { $: Z }

let x = m($(""))
// 1. `Z` should be `"a" | "b"` (corollary - user should get "a" and "b" as completions)
// 2. `typeof x` should be `{ $: "a" | "b" }`

let y = m($("a"))
// 3. `Z` should be `"a"`
// 4. `typeof y` should be `{ $: "a" }`

When the issue was written ie in 4.4.0-beta only (2) was fulfilled (the quickinfo might deceive that (3) is also fulfilled but it's not). Now with 4.9.4 along with (2), (3) & (4) also have been fulfilled and (1) remains unfulfilled (the corollary of (1) is now fulfilled but that's an irrelevant side-effect as it's only fulfilled for this case and not for the above linked send case for example). So some cases got fixed because (3) & (4) got fulfilled and the other ones remained unfixed because 1 remained unfulfilled.
So we already have the distilled minimal repro you're talking about since day one ;)

No it's important because what Z is inferred as will decide the contextual type for the argument of $

Right, this makes sense - although that only (?) prevents some extra errors to be reported. For example the error at acceptStr(arg) here:
declare const m: <T extends { $: "a" | "b" }>(x: T) => T;
declare const $: <Z>(x: Z, cb: (arg: Z) => void) => { $: Z };

declare function acceptStr(a: string): void

let x = m(
  $(100, (arg) => {
    acceptStr(arg);
  })
);

So the improvement here would be purely related to DX etc - or I'm missing what you are saying.
But either way - we are talking here about the case that shouldn't typecheck. It would still be interesting to get a minimal repro for cases that should typecheck but which still don't.

No you're entirely missing what I'm saying xD. Okay let me explain it by answering this question of yours...

It would still be interesting to get a minimal repro for cases that should typecheck but which still don't.

Okay so let's start with a non-minimal repro of the case that should type check but doesn't, here (this is the same send case from above). Now let's make it minimal...
declare const eatEvent: <T extends { type: string }, U extends T>(t: T, u: U) => T
declare const createEvent: <E>(e: E) => E

eatEvent({ type: "FETCH" as const }, { type: "FETCH" }) // compiles, ok
eatEvent({ type: "FETCH" as const }, createEvent({ type: "FETCH" })) // doesn't compile, should

The second call doesn't typecheck because E gets inferred as { type: string } instead of { type: "FETCH" }. This behavior is same as Z getting inferred as "" and not "a" | "b". That is if you make Z infer as "a" | "b" it would automatically make E infer as { type: "FETCH" }, because the implementation responsible for both behaviors is same afaict. Hence I said the Z case is already a minimal distilled repro for the all cases not just this send one.
Now sure the the Z repro is not great because it would rely on the result of .types file of the test result instead of .errors.txt but that's kinda besides the point.
I hope I made myself clearer.


Text concept exercise

Spiking more of these out to see what the general time commitment and effort looks like for more basic concept exercises if we wanted to have a few before "algebraic effects". This one is about our String type. It's marked as WIP.
Having a Text concept exercise might be nice because I think quite a few of the practice exercises I've already added relate to this topic.

Closing in favor of other Text-concept branch


python312Packages.azure-eventgrid: 4.19.0 -> 4.20.0

Changelog: https://github.com/Azure/azure-sdk-for-python/blob/azure-eventgrid_4.20.0/sdk/eventgrid/azure-eventgrid/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 319769 run on x86_64-linux 1

4 packages built:

python311Packages.azure-eventgrid
python311Packages.azure-eventgrid.dist
python312Packages.azure-eventgrid
python312Packages.azure-eventgrid.dist

Result of nixpkgs-review pr 319769 run on x86_64-linux 1

4 packages built:

python311Packages.azure-eventgrid
python311Packages.azure-eventgrid.dist
python312Packages.azure-eventgrid
python312Packages.azure-eventgrid.dist


Problem with belongsToMany relationship

Note, that I am currently using 0.5.x-dev (as I'm working with Laravel 5.3) so the problem below may not apply to earlier versions of this package.
BelongsToMany relationships leads to the following Exception.
Next Illuminate\Database\QueryException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'helios.model_model' doesn't exist (SQL: select `roles`.*, `model_model`.`model_id` as `pivot_model_id`, `model_model`.`created_at` as `pivot_created_at`, `model_model`.`updated_at` as `pivot_updated_at` from `roles` inner join `model_model` on `roles`.`id` = `model_model`.`model_id` where `model_model`.`model_id` = 1) in /var/www/helios/vendor/laravel/framework/src/Illuminate/Database/Connection.php:761

At first glance, it seems like the package can't figure out the name of pivot table and foreign key in accordance with Laravel naming conventions.
When I manually specify names (i.e. return $this->belongsToMany(\App\JsonApi\Roles\Model::class, 'role_user', 'id', 'role_id')->withTimestamps();), Exception is no longer thrown but I encounter another issue: $resource->roles should be a collection with multiple(!) items but I get the collection with only the very first one in response.
Below is the code that lead to this post.
Model
<?php

namespace App\JsonApi\Users;

use Illuminate\Database\Eloquent\Model as EloquentModel;

class Model extends EloquentModel
{
    /**
     * The table associated with the model.
     *
     * @var string
     */
    protected $table = 'users';

    /**
     * @return \Illuminate\Database\Eloquent\Relations\BelongsToMany
     */
    public function roles()
    {
        return $this->belongsToMany(\App\JsonApi\Roles\Model::class)->withTimestamps();
    }
}

Schema
<?php

namespace App\JsonApi\Users;

use CloudCreativity\LaravelJsonApi\Schema\EloquentSchema;

class Schema extends EloquentSchema
{
    const RESOURCE_TYPE = 'users';

    /**
     * @var string
     */
    protected $resourceType = self::RESOURCE_TYPE;

    /**
     * Whether resource member names are hyphenated
     *
     * @var bool
     */
    protected $hyphenated = false;

    /**
     * The model attribute keys to serialize.
     *
     * @var array
     */
    protected $attributes = [
        'email',
        'first_name',
        'last_name',
    ];

    /**
     * Get resource links.
     *
     * @param object $resource
     * @param bool   $isPrimary
     * @param array  $includeRelationships
     * @return array
     */
    public function getRelationships($resource, $isPrimary, array $includeRelationships)
    {
        return [
            'roles' => [
                self::SHOW_SELF => true,
                self::SHOW_RELATED => true,
                self::DATA => $resource->roles,
            ],
        ];
    }
}

@adiachenko I don't think this is a problem with this package. The package calls the methods on your model class, so it uses the relationships objects that are returned by those methods.
I wouldn't recommend putting the model classes in the JSON API namespaces. This is because Eloquent does a lot of "magic" based on the class names of models, and all your models will be called "Model".
Generally I put all the parts of constructing a JSON API within those JSON API namespaces - as basically JSON API is a "view" layer - i.e. a JSON representation of your application's models.
When it comes to the Eloquent models, I'd follow the Laravel convention and have them in a namespace (normally the "App" namespace), with each class called it's relevant name. In your example it should be User class, not Model.
You can see that in the demo app here:
https://github.com/cloudcreativity/demo-laravel-json-api/tree/laravel-5.3
Models are in the App namespace as per the Laravel convention, JSON API units are in the App\JsonApi namespace.

@lindyhopchris Thank you for quick response. I'll try following different conventions to avoid unexpected problems with Eloquent then.


Pattern refactor

Now:
const addNewTask = async (req, res) => {
 try {
     // LOGIC HERE
  } catch (err) {
    logger.error(`Error while fetching tasks ${err}`)
    return res.boom.serverUnavailable('Something went wrong please contact admin')
  }
}
}

const fetchTasks = async (req, res) => {
  try {
     // LOGIC HERE
  } catch (err) {
    logger.error(`Error while fetching tasks ${err}`)
    return res.boom.serverUnavailable('Something went wrong please contact admin')
  }
}

module.exports = {
  addNewTask,
  fetchTasks
}

Refactor:
// runtimeErrorHandler.js

const _addNewTask = async (req, res) => {
   // LOGIC HERE
}

const addNewTask = runtimeErrorHandler(_addNewTask, [optional 'custom error message]');

module.exports = {
  addNewTask,
  fetchTasks
}

Hi,
I can take a stab at this.
I am assuming we want to decouple the error handling from all the controllers.
This is my understanding of the approach you are suggesting --

_addNewTask handles the business logic.
addNewTask wraps the _addNewTask in a  try-catch and returns the error response.
The required wrapper function is returned by runtimeErrorHandler which takes a handler function and an optional error message.

With this approach, the error response would always be serverUnavailable for any exception thrown by the main handler.
I think we can achieve the same results using a different approach as well.

Let's say catchExceptions is a middleware that wraps each handler call in a try-catch block.
This way, we don't have to add two functions like _addNewTask and addNewTask.
Using a common exception catching middleware will also allow us to catch any specific exceptions thrown by handler and returns appropriate response (and not just serverUnavailable).

Please let me know what you think.

Hi,
I can take a stab at this.
I am assuming we want to decouple the error handling from all the controllers.
This is my understanding of the approach you are suggesting --

_addNewTask handles the business logic.
addNewTask wraps the _addNewTask in a  try-catch and returns the error response.
The required wrapper function is returned by runtimeErrorHandler which takes a handler function and an optional error message.

With this approach, the error response would always be serverUnavailable for any exception thrown by the main handler.
I think we can achieve the same results using a different approach as well.

Let's say catchExceptions is a middleware that wraps each handler call in a try-catch block.
This way, we don't have to add two functions like _addNewTask and addNewTask.
Using a common exception catching middleware will also allow us to catch any specific exceptions thrown by handler and returns appropriate response (and not just serverUnavailable).

Please let me know what you think.

Do I have to refactor this particular piece of code only?

Do I have to refactor this particular piece of code only?


Adding new class for non-keri event SADs.

Allowing SAID generation to ignore certain fields.
Database and REST API for new controller Notifications.
Upgrade to signing data at rest to allow for a more comprehensive and secure solution.
Signaling infrastructure for non-durable signals to the controller of the agent (to reload data, for example).
Integration of new notifier and signaler APIs into agent handlers.
Removed KLI pytests that are brittle, slow and cumbersome to debug.  Excluded the cli directory from coverage for now until we come up with an alternate solution to tests
Signed-off-by: pfeairheller<EMAIL_ADDRESS>

Codecov Report

Merging #259 (023c9fc) into development (0cab7fc) will increase coverage by 2.35%.
The diff coverage is 92.93%.

@@               Coverage Diff               @@
##           development     #259      +/-   ##
===============================================
+ Coverage        89.82%   92.17%   +2.35%
===============================================
  Files              165      114      -51
  Lines            36864    34657    -2207
===============================================
- Hits             33112    31946    -1166
+ Misses            3752     2711    -1041

Impacted Files
Coverage Δ

src/keri/core/eventing.py
78.11% <ø> (+0.03%)
:arrow_up:

src/keri/core/parsing.py
78.42% <ø> (+0.13%)
:arrow_up:

src/keri/end/ending.py
62.83% <0.00%> (-16.87%)
:arrow_down:

tests/demo/test_demo.py
99.68% <ø> (ø)

src/keri/app/challenging.py
29.62% <40.00%> (-70.38%)
:arrow_down:

src/keri/app/kiwiing.py
74.84% <47.56%> (-2.32%)
:arrow_down:

src/keri/app/delegating.py
81.06% <88.88%> (+0.95%)
:arrow_up:

src/keri/app/grouping.py
84.19% <94.11%> (-1.70%)
:arrow_down:

src/keri/app/notifying.py
95.37% <95.37%> (ø)

src/keri/core/coring.py
88.74% <96.29%> (+0.05%)
:arrow_up:

... and 85 more

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


Bug in optimizer code!

Latest commit f80e269  must have introduced a bug. I'm working on this. (Remember to do better testing smartass!)

No... This bug was introduced in  22399aa .... even worse!

Bug found! Lines about 45-is in matrix_multiply.c:
-        for( int j = 0; j < n_cols; j++ )
+        for( ; j < n_cols; j++ )
             y[i] += *v_ptr++ * *m_ptr++;

Bugfix will be commited soon!

So the issue was not in the optimizer at all. It was in matrix_multiply. dfab31f  fixes the issue.
It's really strange that this went under the radar, I should maybe extend my testing algorithms in python-directory.


solved Issue #120

Current coverage is 92.72% (diff: 16.66%)

Merging #164 into master will decrease coverage by 0.52%

@@             master       #164   diff @@
==========================================
  Files            29         29
  Lines           874        880     +6
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            815        816     +1
- Misses           59         64     +5
  Partials          0          0

Powered by Codecov. Last update 2b96f29...8c6b613


Clicking on tab head does not focus tab

Steps to reproduce the problem:

Open mitmproxy
Press - to open two pane layout.
Click on the header of the "Events" tabs.
The "Events" tab does not get focus.

Any other comments? What have you tried so far?
This is particularly annoying on Windows, where "shift tab" to switch tabs does not register under WSL. The only way to switch tabs under Windows right now is to open a command prompt and enter console.panes.next.
System information
Mitmproxy: 3.0.0dev0994 (842c9f7)
Python:    3.5.2
OpenSSL:   OpenSSL 1.0.2g  1 Mar 2016
Platform:  Linux-4.4.0-43-Microsoft-x86_64-with-Ubuntu-16.04-xenial

As I understood, we need mitmproxy to change focus, when we click exactly on the headers(Flows, Events), not on the other places of a tab? Am I correct?

I had the circled area in mind, but I can be convinced for something else :)

What about this?

Can we switch between "Key Bindings" - "Filter Expressions" tabs. while focusing on "Events"?
We can still do it.

If the events pane is focused, we shouldn't be able to modify stuff in the Help pane. So yes, this looks like a (related) bug.

@mhils So, do we need to open new issue or leave this bug for current issue?

@kajojify: This may have been a misunderstanding. If I have the events pane focused as in your example, pressing "tab" (or any other key) does not switch the tab in the left pane. How do you switch between tabs while focusing the right pane?

@mhils by pressing left button of mouse. It is possible because of mitmproxy/tools/console/tabs.py

@kajojify I agree with you but it doesn't works as it is supposed to. Also by pressing left or right key doesn't works as mitmproxy/tools/console/tabs.py
https://github.com/mitmproxy/mitmproxy/blob/eb53cc7ed26f451855755164f061ea9f49014f8d/mitmproxy/tools/console/tabs.py#L36
On the other hand Shift + Tab just works fine for switching between tabs.
PS. This is my System information
Mitmproxy: 3.0.0dev1082 (ddb8f43)
Python: 3.5.2
OpenSSL: OpenSSL 1.1.0g 2 Nov 2017
Platform: Linux-4.10.0-28-generic-x86_64-with-Ubuntu-16.04-xenial


[BUG] Using Prometheus datasource causes internal server error

Describe the bug
Trying to get metrics from prometheus datasource via app/observability-metrics#/ shows nothing and Browser developer tools listing a XHR with: POST "api/ppl/search?dataSourceMDSId=" and 500 Internal Server Error
Related component
Plugins
To Reproduce

Go to Management > Dashboards Management > Data sources
Click on 'Create direct query connection'
Add Prometheus Data source with URI: http://localhost:9090 OR
create one via dev tools:

POST _plugins/_query/_datasources
{
    "name" : "my_prometheus",
    "connector": "prometheus",
    "properties" : {
        "prometheus.uri" : "http://localhost:9090"
    }
}

Click on: query data
No metrics available

Prometheus is reachable via http://localhost:9090.
Expected behavior
Available metrics are listed like shown here: https://opensearch.org/docs/latest/observing-your-data/prometheusmetrics/, no "Internal Server error" XHR requests show up inside developer tools.
Additional Details
Plugins
SQL Plugin
Log messages from Opensearch-dashboards
{"type":"response","@timestamp":"2024-11-26T15:57:26Z","tags":[],"pid":1,"method":"post","statusCode":500,"req":{"url":"/api/ppl/search?dataSourceMDSId=","method":"post","headers":{"host":"XXX","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36","content-length":"72","accept":"*/*","accept-encoding":"gzip, deflate, br, zstd","accept-language":"de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7","cache-control":"no-cache","content-type":"application/json","origin":"https://XXX","osd-version":"2.18.0","osd-xsrf":"osd-fetch","pragma":"no-cache","referer":"https://XXX/app/observability-metrics","sec-ch-ua":"\"Not_A Brand\";v=\"8\", \"Chromium\";v=\"120\", \"Google Chrome\";v=\"120\"","sec-ch-ua-mobile":"?0","sec-ch-ua-platform":"\"Windows\"","sec-fetch-dest":"empty","sec-fetch-mode":"cors","sec-fetch-site":"same-origin","x-forwarded-for":"<IP_ADDRESS>","x-forwarded-host":"XXX","x-forwarded-port":"443","x-forwarded-proto":"https","x-forwarded-server":"monitoring-dependencies-traefik-9887cbfbc-wdg6m","x-real-ip":"XXX","securitytenant":"admin_tenant"},"remoteAddress":"<IP_ADDRESS>","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36","referer":"https://XXX/app/observability-metrics"},"res":{"statusCode":500,"responseTime":302,"contentLength":9},"message":"POST /api/ppl/search?dataSourceMDSId= 500 302ms - 9.0B"}
  response: '{\n' +
    '  "error": {\n' +
    '    "reason": "There was internal problem at backend",\n' +
    '    "details": "Error while fetching metric list for from prometheus: Failed to connect to localhost/[0:0:0:0:0:0:0:1]:9090",\n' +
    '    "type": "RuntimeException"\n' +
    '  },\n' +
    '  "status": 500\n' +
    '}',
  toString: [Function (anonymous)],
  toJSON: [Function (anonymous)]
}
PPL query fetch err:  StatusCodeError: Internal Server Error
    at respond (/usr/share/opensearch-dashboards/node_modules/elasticsearch/src/lib/transport.js:349:15)
    at checkRespForFailure (/usr/share/opensearch-dashboards/node_modules/elasticsearch/src/lib/transport.js:306:7)
    at HttpConnector.<anonymous> (/usr/share/opensearch-dashboards/node_modules/elasticsearch/src/lib/connectors/http.js:173:7)
    at IncomingMessage.wrapper (/usr/share/opensearch-dashboards/node_modules/lodash/lodash.js:4991:19)
    at IncomingMessage.emit (node:events:529:35)
    at IncomingMessage.emit (node:domain:489:12)
    at endReadableNT (node:internal/streams/readable:1400:12)
    at processTicksAndRejections (node:internal/process/task_queues:82:21) {
  status: 500,
  displayName: 'InternalServerError',
  path: '/_plugins/_ppl',
  query: { format: 'viz' },
  body: '{\n' +
    '  "error": {\n' +
    '    "reason": "There was internal problem at backend",\n' +
    '    "details": "Error while fetching metric list for from prometheus: Failed to connect to localhost/[0:0:0:0:0:0:0:1]:9090",\n' +
    '    "type": "RuntimeException"\n' +
    '  },\n' +
    '  "status": 500\n' +
    '}',
  statusCode: 500,
  response: '{\n' +
    '  "error": {\n' +
    '    "reason": "There was internal problem at backend",\n' +
    '    "details": "Error while fetching metric list for from prometheus: Failed to connect to localhost/[0:0:0:0:0:0:0:1]:9090",\n' +
    '    "type": "RuntimeException"\n' +
    '  },\n' +
    '  "status": 500\n' +
    '}',
  toString: [Function (anonymous)],
  toJSON: [Function (anonymous)]
}
{"type":"error","@timestamp":"2024-11-26T15:57:26Z","tags":[],"pid":1,"level":"error","error":{"message":"Internal Server Error","name":"Error","stack":"Error: Internal Server Error\n    at HapiResponseAdapter.toError (/usr/share/opensearch-dashboards/src/core/server/http/router/response_adapter.js:127:19)\n    at HapiResponseAdapter.toHapiResponse (/usr/share/opensearch-dashboards/src/core/server/http/router/response_adapter.js:83:19)\n    at HapiResponseAdapter.handle (/usr/share/opensearch-dashboards/src/core/server/http/router/response_adapter.js:79:17)\n    at Router.handle (/usr/share/opensearch-dashboards/src/core/server/http/router/router.js:175:34)\n    at processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at handler (/usr/share/opensearch-dashboards/src/core/server/http/router/router.js:140:50)\n    at exports.Manager.execute (/usr/share/opensearch-dashboards/node_modules/@hapi/hapi/lib/toolkit.js:60:28)\n    at Object.internals.handler (/usr/share/opensearch-dashboards/node_modules/@hapi/hapi/lib/handler.js:46:20)\n    at exports.execute (/usr/share/opensearch-dashboards/node_modules/@hapi/hapi/lib/handler.js:31:20)\n    at Request._lifecycle (/usr/share/opensearch-dashboards/node_modules/@hapi/hapi/lib/request.js:371:32)\n    at Request._execute (/usr/share/opensearch-dashboards/node_modules/@hapi/hapi/lib/request.js:281:9)"},"url":"http://XXX/api/ppl/search?dataSourceMDSId=","message":"Internal Server Error"}

[Catch All Triage - 1, 2, 3]

@vmmusings can you take a look at this? Related to #3197 that you're also working on (no Prometheus metrics list available)


mio support in third_party

It would be fantastic if it were possible to leverage the tokio ecosystem from within SGX (I am particularly interested in gRPC support).
The first step is mio which provides a pure Rust abstraction for synchronous I/O multiplexing, and on Linux wraps the epoll_*(2) family of system calls.
I think for this SDK you'd need to do something like forking mio into third_party/ and adding OCALL wrappers which invoke the epoll_*() system calls from untrusted userspace, much in the same way std::io has been wrapped.
It's something I'd be interested in contributing if there aren't existing plans to work on it.

Next step is to mio.

Sounds like solved. Closing it now :-)


Error while simulating spot-resolution spatial data for cell-type deconvolution

Hi,
I am trying to run the tutorial for simulating spot-resolution spatial data for cell-type deconvolution but I am getting error while running this block of code:
Error: Error in xtfrm.data.frame(x) : cannot xtfrm data frames
MOBSP_data <- construct_data(
  sce = MOBSP_sce,
  assay_use = "counts",
  celltype = NULL,
  pseudotime = NULL,
  spatial = c("spatial1", "spatial2"),
  other_covariates = NULL,
  corr_by = "1"
)

Hi Sumeer,
Thanks for your interest in our work and for pointing out this issue! I pushed the fixed code and now you should be able to run the tutorial for simulating spot-resolution spatial data for cell-type deconvolution with no issue.
Best,
Qingyang


Doesn't work with Firefox

The country flag over spans into the entire page and doesn't let you do anything:
Here's a Screenshot for the reference:

Here's the minimum reproducible code and here's the sandbox.
UI Link <- Open this in firefox and it just messes up everything.
import MuiPhoneNumber from "material-ui-phone-number";

export default function App() {
  return (

Hello CodeSandbox

Start editing to see some magic happen!

      <MuiPhoneNumber
        variant="outlined"
        name="phone"
        data-cy="user-phone"
        required
        label="Phone Number"
        size="small"
        defaultCountry={"in"}
      />

  );
}

Can confirm. Temporary workaround fixes an issue:
              <PhoneField
                onChange={(value) => setFieldValue("phone", value)}
                name="phone"
                label={t`Phone number`}
                variant="filled"
                margin="dense"
                size="small"
                required
                fullWidth
                sx={{
                  svg: {
                    height: "20px",
                  },
                }}
              />

Can confirm. Temporary workaround fixes the issue:
<MuiPhoneNumber
  sx={{
    svg: {
      height: "20px",
    },
  }}
/>

this temporary workaround works like a charm, thanks for the quick response!

Hello all, I forked this library, fix Firefox and Safari bug (and plan to fix other issues and rewrite to fn component) and published it to npm as material-ui-phone-number-2
https://github.com/justdvl/material-ui-phone-number-2
https://www.npmjs.com/package/material-ui-phone-number-2
I recommend everyone who needs to use this library, but working version, to make a simple switch. I will also actively maintain this version 2 library.


feat: add autonomys testnet shortname

I would like to add short name for Autonomys Tesnet

recheck

Added in #936


Updates Game to check SoundManager muteOnPaused when Game's paused property is set

This PR

is a bug fix (closes #572)

Game now checks SoundManager's muteOnPause property whenever the game's paused property is set so one can control whether sounds play when the game is paused. Previously, the property was only used when the game focus was lost in the DOM.
CodePen example of changes using generated build: https://codepen.io/giniwren/pen/ajqMGX

The reason why I didn't do the same check on unmute is that if muteOnPause is changed between pause/unpause, it can cause the sound to exhibit unexpected behavior. For example:

Initial state: game is not paused, muteOnPause is true.
User pauses the game. The sound stops playing as expected.
User sets muteOnPause to false.
User unpauses the game. Because muteOnPause is now false, the code to unmute the sound is skipped, and the sound doesn't start playing again when the game is running.


[Windows] Strange behavior with FocusNode

Steps to Reproduce
Full code:
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'test',
      theme: ThemeData.dark(),
      home: HomePage(),
    );
  }
}

class HomePage extends StatefulWidget {
  @override
  _HomePageState createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  final focusNode = FocusNode();
  final txtController = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: TextField(
          focusNode: focusNode,
          autofocus: true,
          controller: txtController,
          onSubmitted: (token) => setState(() {
            txtController.clear();
            focusNode.requestFocus();
          }),
        ),
      ),
    );
  }
}

Just run it. Input "aaa" and press Enter, then input "bbb". Do not touch mouse.
Expected results:
TextField's content: bbb
It works correctly on Andorid.
If delete code focusNode.requestFocus();, it works correctly too.
Actual results:
TextField's content: aaabbb

Logs
flutter doctor -v
[√] Flutter (Channel master, 1.21.0-6.0.pre.17, on Microsoft Windows [Version 10.0.17763.1039], locale en-US)
    • Flutter version 1.21.0-6.0.pre.17 at D:\Software\flutter
    • Framework revision e64fe11542 (18 hours ago), 2020-07-23 18:11:17 -0700
    • Engine revision 626244a72c
    • Dart version 2.9.0 (build 2.9.0-21.0.dev a3815b6590)

[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at D:\Software\AndroidSDK
    • Platform android-29, build-tools 29.0.2
    • Java binary at: D:\Software\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
    • All Android licenses accepted.

[X] Chrome - develop for the web (Cannot find Chrome executable at .\Google\Chrome\Application\chrome.exe)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[√] Visual Studio - develop for Windows (Visual Studio Enterprise 2019 16.6.5)
    • Visual Studio at D:\Software\VS2019
    • Visual Studio Enterprise 2019 version 16.6.30320.27
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 4.0)
    • Android Studio at D:\Software\Android Studio
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[√] Connected device (3 available)
    • Android SDK built for x86 (mobile) • emulator-5554 • android-x86    • Android 10 (API 29) (emulator)
    • Windows (desktop)                  • windows       • windows-x64    • Microsoft Windows [Version 10.0.17763.1039]
    • Web Server (web)                   • web-server    • web-javascript • Flutter Tools

! Doctor found issues in 1 category.

Duplicate of https://github.com/flutter/flutter/issues/59140


path referencing a windows environment variable containing multiple paths, parsing error

Great tool, thanks for developing it!
Noticed a small error on Windows 11, when an enviroment variable contains multiple paths:
10:24:57.283 ** ERROR: Error from Git.Git.on_execute: <class 'OSError'>: [WinError 123] The filename, directory name, or volume label syntax is incorrect: 'D:\\WorkArea\\developer\\code;d:\\temp'
Traceback (most recent call last):
  File "C:\apps\keypirinha\portable\Profile\InstalledPackages\Git.keypirinha-package\git.py", line 404, in on_execute
  File "C:\apps\keypirinha\portable\Profile\InstalledPackages\Git.keypirinha-package\git.py", line 187, in _rescan
  File "C:\apps\keypirinha\portable\Profile\InstalledPackages\Git.keypirinha-package\git.py", line 163, in _scan_path

The ini file settings:
[main]
[scan_path/SpacebandsStuff]
paths =
    ${env:MY_GIT_REPOS_FOR_AUTO_SYNC}
depth = 1

The environment variable settings:
SET MY_GIT_REPOS_FOR_AUTO_SYNC=D:\WorkArea\developer\code;d:\temp

This kind of configuration is not supported... yet. I see what I can do

It should be working now. Have a look at the new version :)

absolutely amazing, thaks so much for the epic speedy turnaround, that works perfectly. thanks again


Loaded environment isn't exposed to Terminal or Tasks

This extension says it's loaded environment variables, but they aren't being exposed to Terminal or Tasks. I even tried in a brand new folder that just contains
> cat .envrc
export FOO=1

If I open this folder in VSCode, the direnv extension reports "direnv: 2 overriden variables". And yet, the FOO variable is not available to Tasks, and if I open the integrated terminal, it promptly loads the direnv environment again in the shell.
For comparison, if I run code . from a terminal that's already loaded direnv, VSCode inherits those env vars and everything is great. Tasks have the vars, and the integrated terminal doesn't even try to reload direnv as it already has all of the env vars it needs.
I can't figure out what's going on. Surely this must work for other people, otherwise what's the point? I also tried the original 2016 extension, same problem.
Reproduced with VSCode 1.59.1, cab404.vscode-direnv v1.0.0 from the extension marketplace, and direnv 2.28.0.

The Developer Tools console includes

Extension Host
direnv: loading ~/Dev/Scratch/abc/.envrc
direnv: export +FOO ~XPC_SERVICE_NAME

[Extension Host] NOTE: executing command synchronously direnv export json

but process.env["FOO"] is undefined.

It's kind of strange. I do understand problem of shell context — it's hard to expose shell variables without modifying workspace settings — but it looks like it's not working at all for you.

Not yet sure though how to expose this terminal profile to tasks though

This might be related to the issue: https://github.com/Microsoft/vscode/issues/46696
In the terminal, direnv says that it exports:
direnv: export +DEVSHELL_DIR +DEVSHELL_ROOT +IN_NIX_SHELL +NIXPKGS_PATH ~PATH ~XDG_DATA_DIRS
maybe we can just add the PATH with what direnv change? @zimbatm would you mind to give us your thoughts here?

I guess I am closing this for now.

it seems the way to do this is by using EnvironmentVariableCollection, see this sample extension or my own direnv extension (apologies for the plug)
variables set there are available in tasks and terminals , and i think they obviate the need for a terminal profile

variables set there are available in tasks and terminals , and i think they obviate the need for a terminal profile

Will try that out, thanks)


Wordpress

I'd like to use this in my Wordpress based website since PHP is the language for Wordpress. Can you tell me where I install this client and how to use it in Wordpress? Thanks.

Sorry, I am not using Wordpress.
But most likely you need to create a Wordpress Plugin which has a composer dependency to this library.


[DO NOT MERGE][MINOR] Debug TestCleaner failure 2

Change Logs
TBD
Impact
TBD
Risk level (write none, low medium or high below)
none
Documentation Update
N/A
Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

@hudi-bot run azure


Using itemProperties directive does not allow configuration of required item fields

Currently using the following config:
myProp: [] # @schema description: cool prop ; uniqueItems:true ; item:object ; itemProperties:{"prop1": {"type": "string"}, "prop2": {"type": "string"}}

results in the following schema:
    "myProp": {
      "description": "cool prop",
      "items": {
        "properties": {
          "prop1": {
            "type": "string"
          },
          "prop2": {
            "type": "string"
          }
        },
        "type": "object"
      },
      "type": "array",
      "uniqueItems": true
    },

This schema does not define required fields of the item elements.
It would be helpful if there would be a directive to define the required item fields which would result in a schema like that:
    "myProp": {
      "description": "cool prop",
      "items": {
        "properties": {
          "prop1": {
            "type": "string"
          },
          "prop2": {
            "type": "string"
          },
        },
        "type": "object",
        "required": ["prop1", "prop2"]
      },
      "type": "array",
      "uniqueItems": true
    },

for now, required works as boolean and key is declared in yaml. I'll think about it if that behaviour should be changed
https://github.com/losisin/helm-values-schema-json/tree/main/docs#required


Test failures on openjdk8_hs_extended.openjdk solaris hotspot

Failure link https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_extended.openjdk_x86-64_solaris_testList_0/16/
javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh.BadPluginConfigurationTest
Error:
jdk/jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh: syntax error at line 183: PLUGINDST_DIR=$' unexpected
Trss link https://trss.adoptium.net/output/test?id=61e87a86a7df1a292402d899
sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java.ImpactOnSNI
EDIT: Found an upstream issue for this test case https://bugs.openjdk.java.net/browse/JDK-8155049
Error:
[2022-01-19T18:58:19.678Z] java.lang.Exception: No expected Server Name Indication
[2022-01-19T18:58:19.678Z] 	at ImpactOnSNI.doServerSide(ImpactOnSNI.java:143)
[2022-01-19T18:58:19.678Z] 	at ImpactOnSNI.access$100(ImpactOnSNI.java:40)
[2022-01-19T18:58:19.678Z] 	at ImpactOnSNI$1.run(ImpactOnSNI.java:341)
[2022-01-19T18:58:19.678Z]
[2022-01-19T18:58:19.678Z] JavaTest Message: Test threw exception: java.lang.Exception: No expected Server Name Indication

Trss link https://trss.adoptium.net/output/test?id=61e87a86a7df1a292402d872
compiler/floatingpoint/8165673/TestFloatJNIArgs.sh.TestFloatJNIArgs
compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.sh.TestFloatSyncJNIArgs
Error:
[2022-01-19T18:15:10.183Z] TEST RESULT: Failed. Execution failed: exit code 1
Trss link https://trss.adoptium.net/output/test?id=61e87a86a7df1a292402d85a
gc/concurrentMarkSweep/GuardShrinkWarning.java.GuardShrinkWarning
EDIT: found an upstream issue https://bugs.openjdk.java.net/browse/JDK-8023356 for this test failure
Error:
[2022-01-19T18:19:50.233Z]  stdout: [#
[2022-01-19T18:19:50.233Z] # A fatal error has been detected by the Java Runtime Environment:
[2022-01-19T18:19:50.233Z] #
[2022-01-19T18:19:50.233Z] ];
[2022-01-19T18:19:50.233Z]  stderr: [openjdk version "1.8.0_322"
[2022-01-19T18:19:50.233Z] OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
[2022-01-19T18:19:50.233Z] OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)

Trss link https://trss.adoptium.net/output/test?id=61e87a86a7df1a292402d85a

Fails for sparc too
https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_extended.openjdk_sparcv9_solaris_testList_0/25/testReport/

Rerunning xSolaris failures https://ci.adoptopenjdk.net/job/Grinder/3274/console

Some of the failures in this list look like issues with running some of the tools and sh scripts on these platforms.  It may be useful to log onto the machines and try to run the scripts directly to see how they do.  We have had the situation before where openjdk tests that are shell scripts are not written with solaris in mind and do not run well.  If this is the case with some failures, we should report upstream (with suggested amendments if we have them) and exclude the tests against the upstream issues.
GuardShrinkWarning failure ... is it actually hiding a crash (fatal error)?  Will have to look at what this test is actually doing.
13:19:50  STDERR:
13:19:50   stdout: [#
13:19:50  # A fatal error has been detected by the Java Runtime Environment:
13:19:50  #
13:19:50  ];
13:19:50   stderr: [openjdk version "1.8.0_322"
13:19:50  OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
13:19:50  OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
13:19:50
13:19:50  ]
13:19:50   exitValue = 0
13:19:50
13:19:50  java.lang.RuntimeException: 'error' found in stdout
13:19:50
13:19:50  	at com.oracle.java.testlibrary.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:176)
13:19:50  	at GuardShrinkWarning.main(GuardShrinkWarning.java:51)
13:19:50  	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
13:19:50  	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
13:19:50  	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
13:19:50  	at java.lang.reflect.Method.invoke(Method.java:498)
13:19:50  	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
13:19:50  	at java.lang.Thread.run(Thread.java:750)

While testing javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh.BadPluginConfigurationTest on build-packet_esxi-solaris10u11-x64-1 in an ssh environment, it still fails with
jdk/jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh: syntax error at line 183: PLUGINDST_DIR=$ unexpected
https://github.com/adoptium/jdk8u/blob/master/jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh#L183
The failed command is
PLUGINDST_DIR=$(mktemp -d ${TMP}/iio_test.XXXXXXXX), where ${TMP} is /tmp
This command runs fine outside of the test. When running this shell script test on its own (without jtreg), the output suggests that it does not hit the same error. So I am uncertain as to why it is only hitting this error when run in the test suite. The error suggests that everything between the ( ) is ignored

@Haroon-Khel I would run the commands manually outside of the script in a ksh instance to confirm their correctness. Based on the error and my quick read of ksh syntax, I'd suspect the mktemp command is failing, but I don't have ideas on what might cause it to failure. Permissions of the user running jtreg? No space in /tmp?

(Apologies - I typed this immediately after our call earlier but apparently didn't hit the "comment" button)
This will be because the test is running under sh which does not support tthe $() syntax. I would normally suggest replacing it with backticks e.g.
PLUGINDST_DIR=`mktemp -d ${TMP}/iio_test.XXXXXXXX`

but that will probably fall foul of the linter, so perhaps we'd have to feed it to a different shell (I'll be honest I throught we resolved such problems before but perhaps not universally, or it got retracted)

Can machines be setup with ksh? That's the intended shell for this script and would reduce occurrences of these issues.

Can machines be setup with ksh? That's the intended shell for this script and would reduce occurrences of these issues.

They all have ksh and bash available and in general I would expect the scripts to be fine with either, but for some reason the automation is not feeding them to the correct shell. We may have lost some of the configuration that helped secondary plaltforms such as Solaris from executing properly in recent months (Seen elsewhere...) which has caused this.
@Haroon-Khel Did you manage to retry the failure you saw running over an ssh connection using ksh? as per @jiekang's suggestion?

Bash and ksh are able to run the falling command successfully, that is to create the temp directory. I've just now found that running the script with sh causes the failure
-bash-3.2$ sh jdk8u/jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh
JDK under test is: /export/home/jenkins/test_dir/jdk8u322-b06/
cp: cannot access /*.class
cp: cannot access /*.java

------ PREPARE TEST PLUGIN ---------
jdk8u/jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh: syntax error at line 183: `PLUGINDST_DIR=$' unexpected

(Ignore the cp errors since I'm running this script outside of a test suite)
So I guess the jtreg runs the script with sh? An exception should be made for Solaris

In the jtreg test report, it suggests the shell used is user specificed
run=USER_SPECIFIED compile IIOPluginTest.java\nUSER_SPECIFIED compile DummyReaderPluginSpi.java\nUSER_SPECIFIED shell  BadPluginConfigurationTest.sh\n

The question is therefore where do we specify it? :-)

Same error. I used both bash and ksh

re: https://github.com/adoptium/aqa-tests/issues/3242#issuecomment-1025686169 - the default shell for jenkins user profile on that system (guessing this does not currently get explicitly set via ansible when a machine is initially set up?).

re: #3242 (comment) - the default shell for jenkins user profile on that system (guessing this does not currently get explicitly set via ansible when a machine is initially set up?).

Looks like we do fix it to bash. I thought we left it as the OS default :-)

From the jtreg report, it still uses sh to execute the script

OK that really needs to be fixed then. I thought we'd resolved all of those in the past.

The jtreg shell action looks to execute with 'sh': https://github.com/openjdk/jtreg/blob/17bbd21a805ff0ee3a7b197613a899bd9b4b45c5/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java#L273
But I doubt this the only test that mentions being written for 'ksh'. I'm hoping there's more to it, or maybe I'm looking at the wrong place. I imagine we can modify it to run with a different shell, but would have to ask more experienced jtreg users. We're not the only ones running these jtreg tests right?

For the purposes of this release have we verified that all the failing tests on Solaris X64 and SPARC pass when run through an alternate shell?

I have been running the remaining failing tests on x64 solaris in both bash and ksh shell environment. They still fail since jtreg insists on running the tests using sh
I'll run them on a sparc solaris machine right now

While running the test javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh.BadPluginConfigurationTest in a bash environment (still on x64), Is get this stack trace
Sm is java.lang.SecurityManager@7852e922
java.util.ServiceConfigurationError: javax.imageio.spi.ImageReaderSpi: Provider BadReaderPluginSpi not found
        at java.util.ServiceLoader.fail(ServiceLoader.java:239)
        at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
        at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:372)
        at java.util.ServiceLoader$LazyIterator.access$700(ServiceLoader.java:323)
        at java.util.ServiceLoader$LazyIterator$2.run(ServiceLoader.java:407)
        at java.security.AccessController.doPrivileged(Native Method)

But I do not think this is a failure/error since the test still passes
image/gif
image/test_5076692
The test passed!!!

Removing PLUGINDST_DIR /tmp/iio_test.XX7LaGcc

Re compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.sh.TestFloatSyncJNIArgs
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/2544d2a351eca1a3d62276f969dd2d95e4a4d2b6/hotspot/test/compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.sh#L44 suggests that this test is only to be run on linux aarch64
Either way, the test returns
"Test passed; only valid for linux-aarch64"

Test compiler/floatingpoint/8165673/TestFloatJNIArgs.sh.TestFloatJNIArgs (x64 solaris) passes too
VM_OS=solaris
VM_CPU=amd64
Test passed; only valid for linux-aarch64

I got the same exact result for sparcv9.
@sxa I don't think any of the tests in this issue are now blocking solaris, both x64 and sparc

Based on the test @Haroon-Khel tried looks like those three tests https://github.com/adoptium/aqa-tests/issues/3242#issuecomment-1026118025 passed when running without jtreg and failed running with jtreg, which meant running by jtreg VM_OS and VM_CPU can not be detected correctly. Could we open an issue in upstream?


Fix AppVeyor build

Visual 15.9 has a regression. Because AppVeyor forces us to use that particular build, we need to have this workaround. To be removed when we upgrade to 16.0 or when forcing 15.8 toolset is possible.
See https://developercommunity.visualstudio.com/content/problem/395993/159-regression-error-on-valid-c-code-constexpr-if.html

Done : https://github.com/luna/Dataframes/issues/132


Add data community section to gov.uk developer docs

To centralise the newly-produced technical documentation for the data community, this PR creates a data community section in the GOV.UK developer docs. The first two pieces of documentation are:

View or extract feedback data in BigQuery
Zendesk and SmartSurvey feedback data pipeline

Looks good @jonathanglassman! Not reviewed the tables in source/manual/zendesk-smartsurvey-feedback-data-pipeline.html.md.erb in detail. Also wanted to add a comment about this file, but GitHub isn't letting me! Think there's a stray double quotes for EMAIL_ADDRESS in this:

PERSON_NAME,
EMAIL_ADDRESS",
DATE_OF_BIRTH,
STREET_ADDRESS

Thanks @ESKYoung I've made changes where I can and will check your unresolved feedback when I get back from annual leave.

@ESKYoung I've addressed your feedback with @st-alice and asked for her review. Once she approves, I think we're good to go.

Hi @jonathanglassman, I've double checked the SQL code again and can confirm it works, and the Data Studio instructions are clearer now.
I noticed that all the numbered points start with '1' - not sure if that's what is expected

@st-alice thanks for checking. Yes, the numbered points will render as correctly sequential bullet point


Build failed while updating carthage

*** Building scheme "ImageSlideshow_framework" in ImageSlideshow.xcworkspace
Build Failed
Task failed with exit code 65:
/usr/bin/xcrun xcodebuild -workspace /Users/.....
This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/z7/n4ny4l_n15lbhcgrysf35kk40000gn/T/carthage-xcodebuild.cRfy4y.log

yep, got the same
ImageSlideshow/Classes/Core/ImageSlideshow.swift:66:37: error: use of undeclared type 'PageIndicatorPosition'
    open var pageIndicatorPosition: PageIndicatorPosition = PageIndicatorPosition() {
                                    ^~~~~~~~~~~~~~~~~~~~~
ImageSlideshow/Classes/Core/ImageSlideshow.swift:66:14: error: could not infer type for 'pageIndicatorPosition'
    open var pageIndicatorPosition: PageIndicatorPosition = PageIndicatorPosition() {
             ^

** ARCHIVE FAILED **

Same here

*** Building scheme "ImageSlideshow_framework" in ImageSlideshow.xcworkspace
Build Failed
Task failed with exit code 65:
/usr/bin/xcrun xcodebuild -workspace /Users/username/iOSRTR/Carthage/Checkouts/ImageSlideshow/Example/ImageSlideshow.xcworkspace -scheme ImageSlideshow_framework -configuration Release -derivedDataPath /Users/username/Library/Caches/org.carthage.CarthageKit/DerivedData/9.4_9F1027a/ImageSlideshow/1.6.0 -sdk iphoneos ONLY_ACTIVE_ARCH=NO BITCODE_GENERATION_MODE=bitcode CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/jl/cwd7f_tn0z10hgzqfmv8xt5r0000gn/T/ImageSlideshow SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in /Users/username/iOSRTR/Carthage/Checkouts/ImageSlideshow)
This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/jl/cwd7f_tn0z10hgzqfmv8xt5r0000gn/T/carthage-xcodebuild.z8odoG.log

I submitted a PR with a patch to fix the build process:
https://github.com/zvonicek/ImageSlideshow/pull/258

Fixed in #258.


SliverCrossAxisConstrained but align left?

This is what I try to do:

class WidgetThatReturnsASliver extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return SliverStack(
      insetOnOverlap: false, // defaults to false
      children: <Widget>[
        SliverPositioned(
           top: 0,
            right: 0,
            width: 300,
          child: Container(
            width: 300,
            height: 600,
            decoration: BoxDecoration(
              color: Colors.red,
              ],
              borderRadius: BorderRadius.circular(8),
            ),
          ),
        )

        SliverList(...), // I want this SliverList stay left, with a width of 700
      ],
    );
  }
}

I try wrap SliverList With A SliverPositioned(top: 0, left: 0, width 700), my sliverList take up the whole screen
I try SliverCrossAxisConstrained(max: 700) then my sliverList stay in the middle.
How can I achieve the UI?

You can try using SliverCrossAxisPadded and give it a paddingEnd of the size of the box you want on the right.

@ChauCM can you test with PR #47

@ChauCM this feature is now included in v0.2.6


Rename VSPackage to StringResourceVisualizerPackage

Installed product versions

Visual Studio: 2017
This extension: 1.6.70

Description
VSPackage is generic name and it took me some time to understand that this is your extension, so rename it for better recognition.
Steps to recreate

install extension in VS2017
start VS2017 and you get error message that  VSPackage failed to load

Current behavior
error message that  VSPackage failed to load
Expected behavior
after rename it would show directly that StringResourceVisualizer failed to load.
You use VS2019 SDK so the well known VisualStudio.Shell.15.0 in Version 16 failed to load error occurred. So lower SDK version or limit VS support in extension manifest to >= VS2019

I haven't used it on VS2017 for a long time but will take a look.
It seems odd that VS would report the name of the type as the source of the issue, rather than the name of the extension, but I can rename it.
From memory, this was the default name generated.

It seems odd that VS would report the name of the type as the source of the issue, rather than the name of the extension, but I can rename it.

VS reports this generic name:

VS2017 = 15 and your extension uses the 16 Version which is VS2019 so the loading fails.

Closing as the name was previously changed

thanks, later commits make it VS2022 only, so I can no longer use your extension.

Closing as the name was previously changed

thanks, later commits make it VS2022 only, so I can no longer use your extension.

There is a separate version for VS2019 but sadly I'm no longer able to build this for earlier versions :(

There is a separate version for VS2019 but sadly I'm no longer able to build this for earlier versions :(

that version works. I was confused as you did not changed the ID for the new 2022 version, so VS always offered an update to the 2022 version from the old 2017/2019 version that I had installed.

@MagicAndre1981 It sounds like you've got this working yourself. As you're the only person asking for this, do you really need me to repeat what you've done so I can publish it too?

@MagicAndre1981 It sounds like you've got this working yourself. As you're the only person asking for this, do you really need me to repeat what you've done so I can publish it too?

Ok, I also needed to downgrade Microsoft.CodeAnalysis to 2.10.0, now the missing DLL issue is gone. I need to use the version that Rosyln of this VS version uses. Should I can create a PR?


Nice to have - Yii2 serverside and Yii2 clientside packages instead of all in one

Yii2 package comes by default bundled with clientside package including jquery, etc. Although this is not really an issue it would be nice if the framework was split in - say serverside and clientside packages. This way, when building RESTful API and web services that are only serverside our codebase would be clean of stull like jquery keeping our composer install and update runs also significantly smaller.

#9525

there is also this open discussion about re-designing the RESTful API : #3635

+1


Strip non functional trailing whitespace

Strip trailing whitespace if it serves no function. At least code blocks (perhaps some other block too?) may have whitespace that should not be stripped

Removed some unwanted whitespace in ed155953fdbff9b4d7de56298da1c9b1710579f3 and f8b9ed168c333fc50e44cd041835b87e2b6c2a54
Reopen or open a new issue if another known case shows up.


BREAKING: Correct the capitalization on ResposeBuilder export

If you have been including ResponseBuilder using the export Responsebuilder, with this commit you will now need to include it using ResponseBuilder.

Coverage remained the same at 100.0% when pulling 73355b0345349b433e4b6428448d8f53b41ffa68 on fix_response_builder_export into ca9a6616c9cc805429c796d6f90edcca5abded10 on master.

That is - typo in the commit message / PR title.


59244 doctrine data models yaml export

Added doctrine support.  You can now create doctrine entities from the database by calling app/console chameleon_system:autoclasses:dump

Summary by CodeRabbit

New Features

Introduced a new auto class bundle for backend theme management.
Added new CMS functionality with a range of data models for comments, cron jobs, export profiles, and more.
Implemented a new search bar component in the CMS interface.

Enhancements

Improved logic for exporting table configurations.
Updated naming conventions in TCMSFields classes for consistency.

Bug Fixes

Fixed issues with property fields in the database migration script.

Documentation

Added comments indicating future tasks and logic shifts in code.

Refactor

Removed unnecessary dependencies and streamlined code for directory creation.
Transitioned to using LegacyTableExportConfig for table configurations.

Style

Applied new styles for the search bar component in the CMS.

Chores

Added new configuration nodes for directory management in the configuration class.

Closing for further review on gitlab


Configuration to make Markdown rendering similar to GitHub

I personally like the markdown rendering style used by Github. I recently forked this repository to make my own blog. However, the markdown rendering is not looking so nice to me.
Please see below the screenshot of GitHub markdown rendering-
https://www.dropbox.com/s/0769cygtnih8p7g/GitHub-md.png?dl=0
Please see the similar screenshot of Jekyll-Now markdown rendering-
https://www.dropbox.com/s/rzsurq4t5pzx85v/Website-md.png?dl=0
Is there any way to change the rendering style to the one used by GitHub? Thank you very much.

Hi,
I think you are asking how you can remove the double borders (which is actually a bug).
You can achieve this by editing the _sass/_highlights.css file. At the very top of that file, where it says:
.highlight {

…change that to:
pre.highlight {

This will remove the double border. For reference, you can see the commit I made to fix the bug on my own blog.
You might also want to change overflow: scroll; to overflow: auto; as in this commit to hide the scrollbars unless they are needed.
I hope this helps.

Wonderful! it works like a charm. Thanks a lot.


Fix ostestroptions option for running mangnum tests.

We need to address the existence of ostestroptions also in cloud-mkphyscloud-qa-test-tempest-smoke-job where this param is actually used. Putting in into mkcloud.config which is sourced on the admin node at the job start might be the way to go.

+1

+1


Pin travis npm version to 4.6.x to fix build

Our build doesn't work with npm 5, so need to pin to 4.6 to make build working again.

Changes Unknown when pulling 57e580c598f48db3575ba779b156e730d740cca7 on duk3luk3:fix-build-npm-version-pinning into ** on codecombat:master**.

Build failure is due to a broken test - this can be merged imo. (and should be merged asap to get the build from completely broken back to basically working)

We're going to pin it to 3.x for now just to minimize changes (since that's what our deploy stuff uses), but feel free to take some credit and pretend we merged this! ^_^


Export to USDZ

Thanks for the amazing repo!
After several operations, I try to export the scene to a USDZ file using USDZ exporter. One issue I encounter is that the material of each mesh is actually an array of MeshStandardMaterial, however, the USDZ exporter can only take MeshStandMaterial rather than an array.
Is there any way to fix this so we can export the mesh?
Thanks!

The produced mesh is just a three.js object so you can set the mateial to be whatever you want afterward. Or, as the docs state, you can set the useGroups field to disable the generation of a multimaterial geometry.

I try to set the useGroups to false, however, it will generate a mesh without any material.
Also, is there any way that can merge the array of materials? I want the mesh to be the same, so I think I still want to use the current array of materials.

I try to set the useGroups to false, however, it will generate a mesh without any material.

This isn't the case. It generates a mesh with the single material used by the first brush.

Also, is there any way that can merge the array of materials? I want the mesh to be the same, so I think I still want to use the current array of materials.

This depends on the differences between the materials used. If you have general three.js questions about how to handle and process objects or materials I'd ask at the forum

I know this might be irrelevant to the repo, just curious if you know any good way to add joints/articulations in three.js and export it to usdz or any other file formats?

Again if you have general three.js questions pleas use the forum. Unfortunately I don't have the bandwidth for general three.js support on tangential topics.


Prepare to release a patch version for azure-security-keyvault-jca and  azure-spring-boot-starter-keyvault-certificates.

Prepare to release a patch version for azure-security-keyvault-jca and  azure-spring-boot-starter-keyvault-certificates.

/azp run java - sprint - tests

/azp run java - spring - tests

/azp run java - keyvault - tests

The pipeline failure is not related to this PR. So merging this PR.

/check-enforcer override


URL doesn't change when tabs on a form are clicked in MJ Explorer

When you click on a tab on a record viewing form in MJ Explorer, the URL is supposed to update to reflect that, and until some recent version, it worked. This allowed deep linking down to the tab level and was very useful for bookmarking and sharing links. I suspect this is still in the code but somehow an event handler got unwired or something like that. Should be easy to diagnose and fix.
@JS-BC  can you review and knock this out please?

closed with https://github.com/MemberJunction/MJ/pull/621


win-simple with Domino on Windows

Hello folks,
I'm a Domino admin and like to certify my SSL communication using Let's Encrypt. There are several instructions out there explaining how to do put certificates into Domino, e.g. this one, but non mention a combination with fabulous letsencrypt-win-simple.exe. So far, only the installation of the keyring part in Domino is clear to me.  ;)
If my host, for example, is "agga.it", then I'll own the addresses 'agga.it' and 'www.agga.it'. Logically, I want letsencrypt-win-simple create trusted certificates for both.
This is my current call, maybe I miss something:
letsencrypt.exe --emailaddress<EMAIL_ADDRESS>--usedefaulttaskuser --accepttos --manualhost agga.it --webroot "F:\Domino\Data\html" --warmup
win-simple output:
The global logger has been configured
Let's Encrypt (Simple Windows ACME Client)
Renewal Period: 60
Certificate Store: WebHosting
ACME Server: https://acme-v01.api.letsencrypt.org/
Config Folder: C:\Users\Administrator\AppData\Roaming\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org
Certificate Folder: C:\Users\Administrator\AppData\Roaming\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org
Loading Signer from C:\Users\Administrator\AppData\Roaming\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org\Signer
Getting AcmeServerDirectory
Loading Registration from C:\Users\Administrator\AppData\Roaming\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org\Registration

Authorizing Identifier agga.it Using Challenge Type http-01
Writing challenge answer to F:\Domino\Data\domino\html\.well-known/acme-challenge/Y7O_LljdmQJ-f61aShTnLhLFoRDpQlGDcs2bRQRqY7Y
Waiting for site to warmup...
Answer should now be browsable at http://agga.it/.well-known/acme-challenge/Y7O_LljdmQJ-f61aShTnLhLFoRDpQlGDcs2bRQRqY7Y
Submitting answer
Authorization Result: valid
Requesting Certificate
Request Status: Created
Saving Certificate to C:\Users\Administrator\AppData\Roaming\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org\agga.it-crt.der
Saving Issuer Certificate to C:\Users\Administrator\AppData\Roaming\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org\ca-0A0C419800000154857B6A0B85ECA718-crt.pem
Saving Certificate to C:\Users\Administrator\AppData\Roaming\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org\agga.it-all.pfx
Installing Non-Central SSL Certificate in the certificate store
Opened Certificate Store My
 Set private key exportable
Set private key exportable
Adding Certificate to Store
Closing Certificate Store
Installing Non-Central SSL Certificate in server software
 WARNING: Unable to configure server software.
Opened Certificate Store My
Closing Certificate Store
Adding renewal for Manual agga.it (F:\Domino\Data\domino\html)

Do you want to replace the existing letsencrypt-win-simple httpsacme-v01.api.letsencrypt.org task? (y/n)
Deleting existing Task letsencrypt-win-simple httpsacme-v01.api.letsencrypt.org from Windows Task Scheduler.
Creating Task letsencrypt-win-simple httpsacme-v01.api.letsencrypt.org with Windows Task scheduler at 9am every day.
Removing existing scheduled renewal Manual agga.it (F:\Domino\Data\domino\html) Renew After 01.09.2017
Renewal Scheduled Manual agga.it (F:\Domino\Data\domino\html) Renew After 02.09.2017

This creates several files:
agga.it-all.pfx
agga.it-chain.pem
agga.it-crt.der
agga.it-crt.pem
agga.it-csr.pem
agga.it-gen-csr.json
agga.it-gen-key.json
agga.it-key.pem
ca-0A0C419800000154857B6A0B85ECA718-crt.pem

I think, that only the .pem files are required, right? The -chain.pem even contains two certificates.
I think the -key.pem is my privatekey; -chain.pem is my chain.pem; -crt.pem ist my cert.pem. For the others I don't have an idea. What are the two -crt.pem for?
I also copied these root and intermediate certificates from https://letsencrypt.org/certificates/:
"SRG Root X1 (self-signed)", "Let’s Encrypt Authority X3 (IdenTrust cross-signed)" and "Let’s Encrypt Authority X3 (Signed by ISRG Root X1)".
Next I'd copied all certificates into a file "server.txt" and verified it using IBM's kyrtool:
kyrtool.exe ="C:\Program Files\IBM\Domino\notes.ini" verify "F:\Cert\server.txt"
      KyrTool v1.1

Successfully read 2048 bit RSA private key
INFO: Successfully read 4 certificates
INFO: Private key matches leaf certificate
INFO: IssuerName of cert 0 matches the SubjectName of cert 1
ERROR: IssuerName of cert 1 does NOT match the SubjectName of cert 2
INFO: IssuerName of cert 2 matches the SubjectName of cert 3
INFO: Final certificate in chain is self-signed

Reason for the ERROR comes from the second certificate in the -chain.pem! When removed, the error is gone.
Anyway, after installing to Domino and restarting the HTTP task, opening a SSL page I get using:
Firefox:
https://agga.it/                -> no problem! Certificate is OK
https://www.agga.it/        -> SSL_ERROR_BAD_CERT_DOMAIN
Chrome:
https://agga.it/                -> don't accept the certificate: not save!
https://www.agga.it/        -> don't accept the certificate: not save!
IE:
https://agga.it/                -> not save! Certificate error, but allows to accept it
https://www.agga.it/        -> not save! Certificate error, but allows to accept it
So, there must be something missing in the whole chain. Any idea? Probably something very simple...

Could it simply be, that letsencrypt-win-simple does not support the creation of certificates for multiple addresses? E.g. agga.it and www.agga.it? This would explain the error code SSL_ERROR_BAD_CERT_DOMAIN.
Or, is there is a way to create certifier for multiple host names?

Problem had been solved meanwhile. KyrTool has an option to display the certifier structure to clarify the hierarchy. In addition multiple certifier can be created using --san plus --manualhost.


Changing a number value turns it into an integer value

I've seen this happen in one .sol file I tried to edit. Haven't yet tested others. The only solution is to just delete the original value and create a new number value with the number you want.

Whenever you edit a number/integer, it sanitizes the input to make sure nothing invalid is entered. When it does that it calls parseFloat to make sure it's a valid number. If you enter 1.0 it will then be converted to just 1. If there is no period detected it will assume you're working with integers and save it as such. So the only way around this is to enter your number (for example) as 3.000000000001 (or something to that effect) in order to not get converted to an integer. Alternatively i could try to add a UI to force the data type but I don't know when i'll have time to do that. I'm just triaging bugs at the moment.

Kind of a duplicate of https://github.com/gmariani/minerva/issues/76


Migrate psql incident store to use an ORM

The PSQL incident store is unwieldy. Migrating it to an ORM would be good for maintainability.

Development at https://github.com/JonahSussman/kai/tree/200

Added in https://github.com/konveyor/kai/pull/211


Error with PortBinding Remote API v1.23

When trying to get a container by it's name, I'm getting the following exception:
ErrorException in PortBindingNormalizer.php line 42:
First parameter must either be an object or the name of an existing class

in PortBindingNormalizer.php line 42
at HandleExceptions->handleError('2', 'First parameter must either be an object or the name of an existing class', '/opt/terraformer/vendor/docker-php/docker-php/generated/Normalizer/PortBindingNormalizer.php', '42', array('data' => array(object(stdClass)), 'class' => 'Docker\API\Model\PortBinding', 'format' => 'raw', 'context' => array('rootSchema' => object(Container)), 'object' => object(PortBinding)))
at property_exists(array(object(stdClass)), 'HostPort') in PortBindingNormalizer.php line 42
...

which looks to me like the normalizer is expecting the PortBinding from the array.
Section of the JSON string passed to PortBindingNormalizer::deserialize():
"Ports":{"8080/tcp":[{"HostIp":"<IP_ADDRESS>","HostPort":"80"}]}

Adding the following code at line 32 of generated/Normalizer/PortBindingNormalizer.php as a test fixes the problem and no other exception is thrown.
        if (is_array($data))
            $data = $data[0];

Unfortunately my knowledge of swagger and jane-openapi is lacking and I'm not quite sure how to sort this issue in a proper way.
Extra Info
Docker PHP Version: docker-php/docker-php (dev-master 969b7da)
~$ docker version
Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:38:59 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:38:59 2016
 OS/Arch:      linux/amd64

I think it's this part of the docker-swagger that needs updating:
 230         "PortBindings": {
 231           "type": "object",
 232           "additionalProperties": {
 233             "$ref": "#/definitions/PortBinding"
 234           }
 235         },

Hi that should be updated in dev version, or better say 4ea4afd03008f41894582e69fe470d060e616bdf

I see that commit on the branch 1.22 but I can't figure out how to get that version with composer.
I've tried

Try "docker-php/docker-php": "dev-master#4ea4afd03008f41894582e69fe470d060e616bdf" and set stability flag to dev.

That's worked a treat! Thanks!

No problem ;-) Can you please close the issue?

Just tag 1.22.3 with last commits, so you can go back to stable version if you prefer


[BUG] FAIL: test_beta (cpp_stl_cmath_cpp17)

Describe the bug
I see these test failures with Cython 3.0.0:
======================================================================
FAIL: test_beta (cpp_stl_cmath_cpp17)
Doctest: cpp_stl_cmath_cpp17.test_beta
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.9/doctest.py", line 2205, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for cpp_stl_cmath_cpp17.test_beta
  File "$(BUILD_DIR)/TEST_TMP/run/cpp/cpp_stl_cmath_cpp17/cpp_stl_cmath_cpp17.cpython-39.so", line unknown line number, in test_beta

----------------------------------------------------------------------
File "$(BUILD_DIR)/TEST_TMP/run/cpp/cpp_stl_cmath_cpp17/cpp_stl_cmath_cpp17.cpython-39.so", line ?, in cpp_stl_cmath_cpp17.test_beta
Failed example:
    test_beta(1.0, 2.0)
Expected:
    0.5
Got:
    0.49999999999999994

======================================================================
FAIL: test_beta (cpp_stl_cmath_cpp17)
Doctest: cpp_stl_cmath_cpp17.test_beta
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.9/doctest.py", line 2205, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for cpp_stl_cmath_cpp17.test_beta
  File "$(BUILD_DIR)/TEST_TMP/run/cpp/cpp_stl_cmath_cpp17_directives_cpp_locals_True/cpp_stl_cmath_cpp17.cpython-39.so", line unknown line number, in test_beta

----------------------------------------------------------------------
File "$(BUILD_DIR)/TEST_TMP/run/cpp/cpp_stl_cmath_cpp17_directives_cpp_locals_True/cpp_stl_cmath_cpp17.cpython-39.so", line ?, in cpp_stl_cmath_cpp17.test_beta
Failed example:
    test_beta(1.0, 2.0)
Expected:
    0.5
Got:
    0.49999999999999994

Code to reproduce the behaviour:
tox --current-env --no-provision --recreate -e py39

Expected behaviour
Tests pass
OS
OpenIndiana
Python version
3.9.16
Cython version
3.0.0
Additional context
Maybe this is platform bug (see also #5198), but I'm not sure how to confirm that.

This just looks like a small rounding error so I wouldn't worry about it - nothing significant is wrong. That's kind of an issue with doctests that a small difference in output can lead to test failure.
We're only really testing that we've wrapped the functions to the extent that we can call them. We're not really interested in testing the C++ standard library. So if you want to submit a PR to change the test so it passes for you that'd be fine.
Either way, not a big issue


fix(analyzer): NodeTable now uses a ConcurrencyDictionary

As discussed this uses a ConcurrencyDictionary in the Analyzers' NodeTable.
Tests are passing locally.
Regards,
Leo.

Thanks!