Generating Zod schema from TS type definitions

Love this library! I'm just beginning to convert a large TS project with many types, and I'm wondering how feasible it would be to automatically run through a file and convert any TS types to a zod schema and the accompanying inferred type. Or perhaps using the language server somehow would be easier? Either way, it would remove a ton of tedium from adopting zod for an existing project.
I guess I'll just barrel through and convert them one by one, which will probably take me a few hours at least, but figured I'd suggest this for those who might end up in a similar spot.

Hah! Just a few hours ago? Was just about to plead for the same feature!
But Dane, since we already have the TS types, why would we need the inferred types again?

@Birowsky I don't want to duplicate zod and ts definitions, so am replacing all ts types with zod schemas, then using infer to also get the ts type.

Oh, well then, I'll have to make a case for my kind of peoplez. I don't touch code for maybe weeks in a new project. I only model the system with types and try to find all their dependencies. Only after I feel completely comfortable with how the system is modeled, I start implementing it. So not having the types in advance, is not an option for me, which, I hope, makes a stronger case for why we would find use in Zod generator.

Unfortunately I have no idea how to do this sort of thing. Very open to a PR from anyone with experience with this sort of thing.

I'm not sure if this is exactly what @danenania was asking for, but this would be helpful:
type Dog = {
  name: string
  neutered: boolean
}

const dogSchema = z.object<Dog>({
  name: z.string().min(3),
  neutered: z.boolean(),
});

And that would fail to compile if dogSchema did not match Dog

I think Dane was thinking more along the lines of a Babel plugin for generating Zod code, but what you just described is a very powerful idea. Basically it's the inverse how how Zod works. Zod infers static types from a bunch of method calls and data structures. This is the opposite paradigm: "inferring" the internal runtime structure of a Zod schema from the TS type.
I actually already implemented this as a utility for my own purposes. I didn't put this into the Zod library because it needs TS 3.9+ to work. Here's a gist; don't panic when you see it 😛
https://gist.github.com/vriad/074a8509cd506fdc1f96cad27cc20c77
At the bottom you can see an example of it working.
This gets extremely exciting when you start using it on recursive or mutually recursive types.
type User = {
  name: string;
  age?: number | undefined;
  active: boolean | null;
  posts: Post[];
};

type Post = {
  content: string;
  author: User;
};

export const User: toZod<User> = z.late.object(() => ({
  name: z.string(),
  age: z.number().optional(),
  active: z.boolean().nullable(),
  posts: z.array(Post),
}));

export const Post: toZod<Post> = z.late.object(() => ({
  content: z.string(),
  author: User,
}));

User.shape.posts.element.shape.author;

The above uses a z.late.object method that is currently implemented but undocumented.
As far as I know this is the first time any validation library has supported a recursive object schema that still gives you access to all the methods you'd want: pick, omit, extend, partial. I've been using this to implement the API endpoint validations for a new company and it's been a dream. I'm planning to release first-party support for this in Zod 2 in a few weeks.

@vriad beautiful!!! 😍
This will be awesome with Prisma 2 since Prisma provides types all the models in your DB.

@flybayer  Yep, exactly :) I actually have some code lying around that auto-generates Zod schemas from a Prisma 2 client — I'll try to throw that into a separate npm module at some point. I wish the Prisma client provided a nice way of introspecting the schema but currently they don't. So I really had to dive into the guts of the client to make it work.

Prisma does have undocumented introspection tools via @prisma/sdk. We are using them in Blitz.
But not sure if auto generating zod from the DB is worth it, since usually your input is a bit different than what's in the DB, just like you have shown in your example above.

I was more hoping for a way to read out a list of models/fields/relations from the Prisma client, instead of having to worry about pulling schema information down from the DB. Prisma's trying to make the .prisma file the single declarative source of truth for your schema but don't provide any easy way to build codegen tools on top of it...drives me up the wall.
imho it still makes sense to generate Zod schemas for your base types (AKA a one-to-one mapping with what's defined in your Prisma schema). That's the ground truth, then you generate the derived types that you need from there. Plus defining the "base types" is the part that requires duplicative static/runtime declarations (because TypeScript can't infer recursive types), so if you can codegen that, you get rid of any syncing headaches.

Are you in the prisma slack? I'm sure they'd love to hear what you need on the codegen front. And/or open an issue on Github.

You could use the typescript compiler api to generate using a transformer.  It's actually quite simple to do.

@flybayer btw I spun out the toZod utility from that gist into its own module. It's not in Zod core because it requires TypeScript 3.9+ (for complicated recursive type reasons).
yarn add tozod
import { toZod } from "tozod";

type Dog = {
  name: string
  neutered: boolean
}

const dogSchema = toZod<Dog>({
  name: z.string().min(3),
  neutered: z.boolean(),
});

Ok thanks! I wonder if there is a way you can add it into core, but then throw an error if someone tries to use this and TS version isn't 3.9+?

Interesting discussion here! We initially redefined most of our TS types as zod schemas, then used z.infer to extract TS types. This works pretty well, but the extra layers of inference seem to sometimes be causing performance issues with complex types, and can also break some IDE features like Go to definition.  So we're now looking at refactoring to use the toZod approach where we'll have the TS type and schema defined side by side. I originally didn't want to do this because I worried about types and schemas getting out of sync, but toZod seems to deal with that nicely.

@danenania I should warn that toZod is limited in what you can express. It doesn't support unions (except the special case of .undefined and .nullable, intersections, tuples, records, enums, or literals. I could add literal and enum support if you need it (I think). In general toZod is pretty fragile since its a generic recursive alias (which also can lead to other performance issues with the TS server).
If you could provide a reproducible example of the "Go to definition" issue I can look into it. I haven't encountered that.

@flybayer I'm not aware of a way to do that. If toZod is in core, then TS compilation will fail for any project<EMAIL_ADDRESS>Don't think there's a way to disable the type checker based on version. :/

Export toZod separately and have them import directly?  At least could just be a choice then.

Unfortunately most users consume zod with import * as z from "zod" so there's no way to export it from index.ts without everyone accidentally importing it and messing up their builds.
It would be nice to enable something like import { toZod } from 'zod/tozod'; but I'm not sure how to do that. @bradennapier Is that what you mean by "export separately"?

Yes, exactly.  It'd be quite easy.

Thanks for the heads up @vriad on toZod's limitations. In that case, we'll hold off on that refactoring.
This is getting pretty far from the original issue, but based on @bradennapier's demonstration that it isn't too hard to translate between TS and zod definitions, I'm starting to think the ultimate workflow here might be for zod to automatically generate schemas for all defined types (probably based on included files in tsconfig), and then allow for extending the auto-generated schemas to add more validations if needed. I'm sure this opens up some other cans of worms, but would make using zod a complete no-brainer in any TS project imo, since currently the only real drawback is needing to define types in zod's DSL instead of in plain TS.

@danenania I should warn that toZod is limited in what you can express. It doesn't support unions (except the special case of .undefined and .nullable), intersections, tuples, records, enums, or literals. I could add literal and enum support if you need it (I think). In general toZod is pretty fragile since its a generic recursive alias (which also can lead to other performance issues with the TS server).
If you could provide a reproducible example of the "Go to definition" issue I can look into it. I haven't encountered that.

@vriad Do these limitations look solvable in the near future or do you think they are just technically infeasible? Trying to assess if I should be waiting on toZod.
Apart from the 3 (or more) use cases described above, I have a slightly tangential (maybe?) requirement which toZod could solve. Basically, some portions of my back-end are in Python and needs data validation. So what I've been doing is auto-converting TS definitions to JSON Schema (for doing validation with say, this library).
After looking at Zod (which looks great for JS based validation), I tried Zod Object Schema --zod.infer--> TS Types --typescript-json-schema--> JSON Schema. This chain works fine but I am getting a JSON schema output which is slightly inferior in quality.
If I define TS interfaces first, then I can end up with better JSON schema (with slightly more advanced validation). It is because typescript-json-schema uses the comments we write alongside the type interface declarations to improve the JSON schema output. With zod.infer, there is no "comment" that I can add to help typescript-json-schema, and hence the validation takes a slight hit.
Now if I have TS interfaces first, then the issue is to keep it in sync with Zod object schema over time as other folks mentioned. So I am kinda split between whether to maintaing both Zod object schema and TS interfaces or move the server side data validation part from Python to JS (and ditch JSON schema) or just be content with whatever JSON schema I am currently getting.

@maneetgoyal @danenania The design goal for toZod is to have a tool that can express database models. My goals were to express the "GraphQL grammar" (or perhaps "Prisma grammar" is a more familiar term!).

you can define models
those models can have primitive fields: strings, numbers, booleans, optionals of each, and arrays of each
models have relations to other models (either to-one or to-many)

Perhaps I should have named it zod-model to better indicate this. In this sense I don't consider tozod "incomplete". You can still use toZod to implement certain "core" types, then hook those core types together with intersections, etc.
Can you elaborate on why you don't want to define your types in Zod and use z.infer? Dane, I'd like to hear more about your issues with "Jump to definition" and maybe see a minimal repro.
Maneet, I think the ideal flow would be to define your JSON Schema types and codegen both Zod validators (for your JS environments) and schemas for whatever Python validation library you choose. Of course, you'd have to implement the JSON-schema => Zod codegen step. If you did, I'd happy to bring it into core and maintain it moving forward. Something like this would make it quite easy, not sure if this works or not though: https://www.npmjs.com/package/json-schema-visitor

I love this idea that @flybayer suggested, which was partially implemented in the tozod library. ❤
I'm looking to implement Zod in my project, but it seems like I need to strip out pretty much all of my current type definitions and replace them with Zod schemas.  One way to do that would be to make the schemas conform to my existing type system in the way flybayer suggested.
tozod was a great step in the right direction, but it isn't sufficient as it is. It either needs to be built out a lot more or we need another solution. Is this something that can be pursued?
To put it a different way, Zod is advertised as "Typescript first", but right now it feels more like "Zod first with Typescript as a close second". I say that because, currently, you have to write the Zod schemas first, then use them to generate types (not doing it this way leads to messy situations). To be truly "Typescript first", the Typescript types have to be king, and the schemas should conform to the types instead of (or in addition to) the types being generated from the schemas.
Would it be helpful to open this as a separate issue? I know it is not really what the author requested and is technically off topic 😜

I love this idea that @flybayer suggested, which was partially implemented in the tozod library. ❤
I'm looking to implement Zod in my project, but it seems like I need to strip out pretty much all of my current type definitions and replace them with Zod schemas.  One way to do that would be to make the schemas conform to my existing type system in the way flybayer suggested.
tozod was a great step in the right direction, but it isn't sufficient as it is. It either needs to be built out a lot more or we need another solution. Is this something that can be pursued?
To put it a different way, Zod is advertised as "Typescript first", but right now it feels more like "Zod first with Typescript as a close second". I say that because, currently, you have to write the Zod schemas first, then use them to generate types (not doing it this way leads to messy situations). To be truly "Typescript first", the Typescript types have to be king, and the schemas should conform to the types instead of (or in addition to) the types being generated from the schemas.
Would it be helpful to open this as a separate issue? I know it is not really what the author requested and is technically off topic 😜

I mean that is pretty much what the project i had started does precisely, @derekparsons718

@bradennapier I love your project, it seems really helpful. However, from what I can see, it doesn't address exactly what I want. It looks like your project replaces Typescript types with equivalent Zod schemas, which is awesome and much more in line with what the original author requested; but I, on the other hand, want to keep all my types as they are and create schemas that conform to them. I do not want to replace my existing type definitions with schemas, I want to create schemas that conform to my existing types. My whole point is that I want to keep my type system in typescript and only use Zod to validate that objects match up with my existing types. (I'm sure your code could be very easily adjusted to do what I want if something like an advanced tozod was available)
I realize that we can't get away from using schemas because of the whole typescript-doesn't-exist-at-runtime thing, and that isn't really what I'm asking for. I'll give an example.
Right now, if I want to validate that an object matches A, I will need to replace my existing code...
export interface A {
   readonly ID: number;
   delayEnd: number;
   userID: number;
   reason: string;
   taskID: number;
   initiationDate: number;
   days?: number;
   userName?: string;
}

...with something like this...
//hopefully this is correct, I am still new to Zod
export const aSchema = z.object({
   delayID: z.number(),
   delayEnd: z.number(),
   userID: z.number(),
   reason: z.string(),
   taskID: z.number(),
   initiationDate: z.number(),
   days: z.number().optional(),
   userName: z.string().optional()
});

export type A = z.infer<typeof aSchema>;

But what I really want is something more along the lines of what tozod does, so instead of replacing my type definitions with a schema I can have both. Something like this:
export interface A {
   readonly ID: number;
   delayEnd: number;
   userID: number;
   reason: string;
   taskID: number;
   initiationDate: number;
   days?: number;
   userName?: string;
}

//The use of toZod ensures that the schema matches the interface
export const aSchema: toZod<A> = z.object({
   delayID: z.number(),
   delayEnd: z.number(),
   userID: z.number(),
   reason: z.string(),
   taskID: z.number(),
   initiationDate: z.number(),
   days: z.number().optional(),
   userName: z.string().optional()
});

//Note: The above code actually would work just fine with the current `tozod` library,
//but more complex examples would easily break. Hence my original comment.

This preserves my original types and has a schema that conforms to those types. This gives me the same strong typing as using infer<> would have, but it leaves Typescript in charge of defining my type system and still gives me all the benefits of runtime validation. I think this scenario gives the best of all worlds and is truly "Typescript-first". I realize that it is slightly more verbose than just having a schema, but I think the benefits are well worth it. It fits much better into the established Typescript paradigm, in my opinion. I can give more extensive reasoning if desired.
Am I the only one thinking along these lines? I'm not even 100% sure that such a system is feasible, which is why I asked earlier if this is something we can even look at pursuing.

Hi everybody,
I finally did have some time to work on this crazy idea last week, and, I think this is ready to get some testers and feedbacks 😁
I'm glad to present the very early version of ts-to-zod, this is working with zod@next only, I let you try & play yourself and I'm waiting for your feedbacks 😃
Have fun folks! 🤘
Pro tips: Since I'm planning to use this in production, you can generate some "types integration tests" with the --tests, to make sure the generated schema are 100% compatible with the original types 😁
PS: Huge thanks to @bradennapier for his POC  https://github.com/bradennapier/zod-web-converter this was a very nice starting point ❤ and @colinhacks to have quickly implement the .required() (https://github.com/colinhacks/zod/issues/357)

That looks awesome @fabien0102! 🎉   Can't wait to test it out. Also hoping blitz update to zod v3 soon to be able to use this in blitz apps!

Since it seems like there are at least a few other people interested in the possibility of typechecking schemas against existing types, I've opened a new issue to discuss it: #372

@maxfi you can update to Zod v3 with Blitz. Blitz doesn't bundle zod, so you own the version in your package json :)

Thanks @flybayer. The problem is if I update to<EMAIL_ADDRESS>it breaks query/mutation resolvers. zod@beta is working though. 👍

You can also do simply this with just TypeScript:
const zodSchema = z.object({
	id: z.string(),
	title: z.string().min(5),
})

type ZodSchemaType = typeof zodSchema._output;

これが正確かどうかはわかりません@danenaniaを求めていましたが、これは非常に役立ちます!:
type Dog = {
name: string
neutered: boolean
}
const dogSchema = z.object({
name: z.string().min(3),
neutered: z.boolean(),
});
dogSchemaそして、一致しない場合、コンパイルに失敗しますDog

This fails in the current zod. ( "zod": "3.20.2")
We need to override the type in some way.
Here is my example.

Is this built into Zod now or in the future? Would be great to have it!

Find a online website: https://transform.tools/typescript-to-zod

It seems the gist is down. Was there any movement to get this baked into Zod? I know we have z.infer but it would be great to have the opposite to create a zode schema from a TS Type or at least couple it and validate it against a TS type.

The gist is now here: https://gist.github.com/colinhacks/074a8509cd506fdc1f96cad27cc20c77 and the related npm package here: https://www.npmjs.com/package/tozod but it's fairly limited and doesn't seem much used.

I know this is old but if you're looking for another simple type to define you could do this
export type TypeToZod<T> = {
    [K in keyof T]: undefined extends T[K] ? z.ZodOptional<z.ZodType<Exclude<T[K], undefined>>> : z.ZodType<T[K]>
}

Then use it like this
import { z } from 'zod'

type A = {
    b:string
}
const properties:TypeToZod<A> = {
b: z.string()
}

const schema = z.object(properties)

@IliyanID it's nice that it binds the two together, but would still be nice if it could auto-magically generate the zod type from the TS type.

It works like a charm! Thanks!

Hi There,
Like the toZod implementation but what I would like to see is a bit more of magic (don't know if it's possible, therefore i'm asking)
I would like to see something like this:
`type User = {
id: string;
name: string;
age?: number | undefined;
active: boolean | null;
posts: Post[];
};
type Post = {
content: string;
author: User;
};
export const UserSchema: toZod = z.late.object((model) => ({
...model,
id: z.string().uuid(), // refinements are fine
}));
export const PostSchema: toZod = z.late.object((model) => ({
...model
}));`
Would this be possible ?

Well, this is a super complex problem unless all of your types are set in schema files somehow. I believe the typescript API may be helpful in reading source files and then generating the Zod schema(s); but, it is no easy task.

Should I create a feature request for this ? Or can we re-open the this ticket ?

This sounds like it would require code generation, which some people are fine with and others may hate.
Folks would need to determine how the generation works. Like does it utilize a glob pattern and generate any type it finds into a zod schema? Would it utilize decorators which would then currently limit it to Typescript? Does it come with a watcher tool that regenerates on changes?

I know this is old but if you're looking for another simple type to define you could do this
export type TypeToZod<T> = {
    [K in keyof T]: T[K] extends (string | number | boolean | null | undefined)
      ? (undefined extends T[K] ? z.ZodOptional<z.ZodType<Exclude<T[K], undefined>>> : z.ZodType<T[K]>)
      : z.ZodObject<TypeToZod<T[K]>>
};

...

An extension to this that fit my use case was something along the lines of:
export type TypeToZod<T> = Required<{
    [K in keyof T]: T[K] extends string | number | boolean | null | undefined
        ? undefined extends T[K]
            ? z.ZodDefault<z.ZodType<Exclude<T[K], undefined>>>
            : z.ZodType<T[K]>
        : z.ZodObject<TypeToZod<T[K]>>;
}>;

This will force you to give a z.default() value to optional properties, so when you go to z.parse() you do not need to worry about undefined properties.
So I can do:
const schema = createZodObject<OpenAIMessagePostRequest>({
    prompt: z.string(),
    size: z.number().default(512),
});

Then do:
const { prompt, size } = schema.parse(body);

And size will be of type number and not undefined.

An extension to @IliyanID comment above is this alternative approach that makes optional fields required with the z.ZodDefault<> type:
export type TypeToZod<T> = Required<{
    [K in keyof T]: T[K] extends string | number | boolean | null | undefined
        ? undefined extends T[K]
            ? z.ZodDefault<z.ZodType<Exclude<T[K], undefined>>>
            : z.ZodType<T[K]>
        : z.ZodObject<TypeToZod<T[K]>>;
}>;

export const createZodObject = <T>(obj: TypeToZod<T>) => {
    return z.object(obj);
};

This forces you to give a z.default() value to optional properties, so when you go to parse() the schema, you do not need to worry about undefined properties.
For example:
Given the type...
type Body = {
    prompt: string;
    size?: number;
};

I can create the schema...
const schema = createZodObject<Body>({
    prompt: z.string(),
    size: z.number().default(512),
});

Then do...
const { prompt, size } = schema.parse(body);

And size will be of type number and not undefined.

when trigger intellisence, this ts code freeze vscode IDE in infinity loop and crash after 2 min !

Just to add for completion, if your typescript declared interface has optional fields you will want to remove that optionality:
export type TypeToZod<T> = {
  [K in keyof T]-?: T[K] extends
    | Date
    | string
    | number
    | boolean
    | null
    | undefined
    ? undefined extends T[K]
      ? ZodOptional<ZodType<Exclude<T[K], undefined>>>
      : ZodType<T[K]>
    : ZodObject<TypeToZod<T[K]>>;
};

Might want to add Date in the mix?
 [K in keyof T]: T[K] extends Date | boolean | number | string | null | undefined

An extension to @IliyanID comment above is this alternative approach that makes optional fields required with the z.ZodDefault<> type:
export type TypeToZod<T> = Required<{
    [K in keyof T]: T[K] extends string | number | boolean | null | undefined
        ? undefined extends T[K]
            ? z.ZodDefault<z.ZodType<Exclude<T[K], undefined>>>
            : z.ZodType<T[K]>
        : z.ZodObject<TypeToZod<T[K]>>;
}>;

export const createZodObject = <T>(obj: TypeToZod<T>) => {
    return z.object(obj);
};

This forces you to give a z.default() value to optional properties, so when you go to parse() the schema, you do not need to worry about undefined properties.
For example:
Given the type...
type Body = {
    prompt: string;
    size?: number;
};

I can create the schema...
const schema = createZodObject<Body>({
    prompt: z.string(),
    size: z.number().default(512),
});

Then do...
const { prompt, size } = schema.parse(body);

And size will be of type number and not undefined.

I think what you mean is, if you would want to remove the optional fields, you can use this approach?
Because removing optional fields, in my view, feels a bit weird because they can be there. They should by typed optionally with their type or undefined, so T | undefined to say it simply.

Just to add for completion, if your typescript declared interface has optional fields you will want to remove that optionality:
export type TypeToZod<T> = {
  [K in keyof T]-?: T[K] extends
    | Date
    | string
    | number
    | boolean
    | null
    | undefined
    ? undefined extends T[K]
      ? ZodOptional<ZodType<Exclude<T[K], undefined>>>
      : ZodType<T[K]>
    : ZodObject<TypeToZod<T[K]>>;
};

Might want to add Date in the mix?
 [K in keyof T]: T[K] extends Date | boolean | number | string | null | undefined

An extension to @IliyanID comment above is this alternative approach that makes optional fields required with the z.ZodDefault<> type:
export type TypeToZod<T> = Required<{
    [K in keyof T]: T[K] extends string | number | boolean | null | undefined
        ? undefined extends T[K]
            ? z.ZodDefault<z.ZodType<Exclude<T[K], undefined>>>
            : z.ZodType<T[K]>
        : z.ZodObject<TypeToZod<T[K]>>;
}>;

export const createZodObject = <T>(obj: TypeToZod<T>) => {
    return z.object(obj);
};

This forces you to give a z.default() value to optional properties, so when you go to parse() the schema, you do not need to worry about undefined properties.
For example:
Given the type...
type Body = {
    prompt: string;
    size?: number;
};

I can create the schema...
const schema = createZodObject<Body>({
    prompt: z.string(),
    size: z.number().default(512),
});

Then do...
const { prompt, size } = schema.parse(body);

And size will be of type number and not undefined.


Update android external extensions layout

XWALK-5746 Move external extensions management framework down into Crosswalk Webview.

Enhance build.sh to support crosswalk versions
Put external extension into app source folder
Migrate external extensions creation framework from xwalk_app_runtime
layer to xwalk_core_library

This PR is needed from crosswalk 18.46.452.0. @zqzhang

LGTM, @rakuco


add updated screenshot and remove outdated infos

https://github.com/MicrosoftDocs/windows-itpro-docs/issues/5634

@JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks.

@Dansimp - PR has been copy edited and is ready for final review. This is based on issue #5634
Thank you.
cc: @kenwith


Get ERR_PACKAGE_PATH_NOT_EXPORTED when using ssi-sdk.oid4vci-issuer-rest-api.

Hi I'm a SSI developer in Japan.
I've been trying to build OID4VCI Issuer using your SDK.
(As an aside, I'm using AFJ for building a OID4VCI wallet.)
Building typescript works, but when I start a node process, I get a following error. Is there a way to fix this?
My package.json is as follows. Thanks,
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in /Users/takahiro-kanuma/VSCodeProjects/sandbox/ssi-sandbox/sphereon-oid4vci/node_modules/did-jwt-vc/node_modules/uint8arrays/package.json
at new NodeError (node:internal/errors:387:5)
at throwExportsNotFound (node:internal/modules/esm/resolve:365:9)
at packageExportsResolve (node:internal/modules/esm/resolve:589:7)
at resolveExports (node:internal/modules/cjs/loader:554:36)
at Function.Module._findPath (node:internal/modules/cjs/loader:594:31)
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1012:27)
at Function.Module._load (node:internal/modules/cjs/loader:871:27)
at Module.require (node:internal/modules/cjs/loader:1098:19)
at require (node:internal/modules/cjs/helpers:108:18)
at Object. (/Users/takahiro-kanuma/VSCodeProjects/sandbox/ssi-sandbox/sphereon-oid4vci/node_modules/did-jwt-vc/node_modules/did-jwt/lib/index.cjs:1:19) {
code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}
{
  "name": "oid4vci-trial",
  "version": "1.0.0",
  "main": "index.js",
  "type": "module",
  "license": "MIT",
  "scripts": {
    "start": "tsc && node dist/index.js",
    "lint": "eslint ."
  },
  "dependencies": {
<EMAIL_ADDRESS>"0.14.0",
<EMAIL_ADDRESS>"0.14.0",
<EMAIL_ADDRESS>"^0.15.1",
<EMAIL_ADDRESS>"^0.15.1",
<EMAIL_ADDRESS>"^0.15.1",
    "@types/node": "^20.6.0",
    "@veramo/data-store": "4.2.0",
    "@veramo/did-manager": "4.2.0",
    "@veramo/did-resolver": "4.2.0",
    "did-resolver": "4.1.0",
    "log4js": "^6.9.1",
    "typeorm": "^0.3.17"
  },
  "devDependencies": {
    "@tsconfig/node18": "^18.2.1",
    "@types/express": "^4.17.17",
    "@typescript-eslint/eslint-plugin": "^6.7.0",
    "@typescript-eslint/parser": "^6.7.0",
    "eslint": "^8.49.0",
    "eslint-config-prettier": "^9.0.0",
    "typescript": "^5.2.2"
  }
}

I did yarn resolution to did-jwt-vc, and it's solved.

Cool. Sorry for the late reply. Indeed you will need resolutions currently for did-jwt and did-jwt-vc, because they moved to ESM in a minor release. did-jwt-vc depends on did-jwt, which means that even if you provide an older version for did-jwt-vc you still might get in trouble. Then there was also an issue with a new Uint8arrays version: https://github.com/decentralized-identity/did-jwt-vc/issues/135
Glad you figured it out on your own 👍


ERROR `/ableplayer/button-icons/white/pipe.png' not found

Discovered while creating another feature

Added missing file, works as expected now


Unauthorized Overlay in Android

Has anyone figured out how to deal with unauthorized overlay error in Android?
Is it an order-placement issue? Should I display it modally? What's the solution here?

The only solution I can come up with is to present it Modally. I would rather not do that.

@dozel To my knowledge the Android YouTube API will always pause if it is covered even partially by other views or cropped inside a scrollable view. You should plan your UI/UX around this limitation.
Another option would be to implement this player in Android as an embedded WebView that holds the generic html iFrame like its being done in iOS. I guess then the iFrame has no knowledge about being covered so you would get the same functionality as in the iOS implementation.
I would might do this in the future in my repository or this one if my version would be merged

@dozel , may I know how you can get around this issue using Modal?
I am trying to implement the same but it just doesn't seem to work

@flowkraD I ended up just using a WebView to show the youtube video. So if iOS, use this library, if Android, use a webview.


/etc handling (overlayfs, with case study on a non-NixOS Nix-based system)

Current NixOS practice
Currently, NixOS activation spends non-negligible amount of time traversing /etc for dangling /etc/static links. Also, when new entries are added, /etc is refilled non-atomically.
Proposed solution
What I use on my current system (which is not NixOS but uses NixPkgs and reuses some parts of the NixOS tooling) is the following construction:
/bin, /usr, /etc/ are symlinks into /run/current-system/global
/run/current-system/global/{bin,usr,etc-static} are just statically built somehow.
/run/current-system/global/etc (target of /etc symlink) is again a symbolic link to (say) /var/etc-overlay/[system-hash]/
/var/etc-overlay/[system-hash]/ is an overlayfs union mount of the corresponding system's global/etc-static from Nix store and /var/etc that keeps the non-Nix-managed parts. overlayfs also wants a so-called workdir which I put into /var/etc-workdir/[system-hash]/. Maybe putting the overlayfs magic into /run is a better idea long term, though.
During activation, an -t overlay mount is established before the current-system link switch, and when the link gets updated, the new mount becomes the current one automatically.
Drawbacks
Currently, I don't see any append-only mode for overlayfs (aufs does have one). So, opening one of the read-only files as root will create a copy in /var/etc and allow changes.
Also, if there is a pre-existing copy in /var/etc, it will take precedence (again, aufs can be configured otherwise, but has its own drawbacks)
The current solution requires explicit replacement of the symlink (slightly more resilient), but cannot stop such replacement.
Pitfalls of a wrong implementation
Two layers of /etc link are actually necessary in this construction as-is. One could just use a mountpoint inside store, but nix-store --gc will happily recursively remove files on an overlayfs mounted inside the store path it collects (should Nix behaviour be changed here, too?)
Another option would be using a staging ground in /run or /var per-system-generation and point /run/current-system link there, but having /run/current-system point into store simplifies GC root management.
Side benefits for Nix-based system coexistence
Multiple Nix-based systems having different ideas about proper /etc/ management but agreeing that /etc/ is a symlink to /run/current-system/global/etc can be used on the same store and the same root FS without interfering too much; /etc/ management as done by NixOS right now has more state.
People who pushed me to write it as an issue as is
@copumpkin @grahamc

Why does atomicity of adding files to /etc matter? Is there any service watching for new files in /etc instead of rereading files when a signal arrives?

With multi-second race windows there is a chance that a random user-started tool will read an intermediate state. Union-mount approach can also be made faster than creating/removing many symlinks, so atomicity is not the only point.

There's also the interruption concern, if there's a bug in the script or some other sort of failure, the etc preparation script can leave the system in a weird state.

I thought about interruption concerns, but they seem to be reboot-fixable, so I didn't mention them in my reply.

A race could happen even if the change is atomic. For example file1 has include 'file2' and /etc is changed atomically after file1 is read but before file2 is read

That's true, but this race can occur even without a switch. Slow switch creates new interesting combinations of states by introducing hanging symlinks, though.

Also, how typical is to have not-nix-managed files in /etc ?
I mean, besides the dozen of workstations we use to hack nix.
On servers, in containers, in nixops deployments?

I would expect that a majority of systems running NixOS have not-store-symlinks files in /etc. Namely, one of the following:

/etc/ssh/ssh_host_rsa_key
/etc/machine-id
/etc/resolv.conf
/etc/passwd
/etc/cups/

I only want to note, that overlayfs does not work on top of zfs.

One improvement, which could be made on Linux is to use the RENAME_EXCHANGE feature of the system call renameat2 to update the static directory with the new version.

Re:ZFS — ouch.
Why FUSE union solutions are so much more predictable and simple… But worse performance, I know.
Well, another approach is enumerating allowed uses of mutable data accessible through /etc/ and creating symlinks for them. SSH and CUPS shouldn't be a problem. machine-id is DBus, after all, but there is a hope.
resolv.conf and passwd get renamed into place on change, which can require annoying patching…

After various experiments (and sometimes issues) I decided that thw way I personally want to go is fully read-only /etc/ with symlinks to mutable paths when needed, and with a separate helper for passwd manipulation.


Hide wallet

[ ] 1. should be a divider line to divide between hidden or unhidden wallet

[x] 2. When the wallet is hidden there should be a toast message (Yes after the passcode entry it should just give a toast message) Currently Login modal comes after the passcode is entered in hide wallet flow

Design

Resolved,

Completed verified on 1.1.6 (252)


Ticker seems to be wrong for ETH-BTC

STEPS TO REPRODUCE

Open a web socket and log the ticker for ETH-BTC

EXPECTED

Ticker is accurate

ACTUAL

Take a look at the following ticker.  Unless I'm misunderstanding something, there's seems to be a bug.  How can the high_24h price be lower than open_24h?

Also, each ticker seems to return drastically different information, only seconds apart!
{ type: 'ticker',
  sequence: 868772381,
  product_id: 'ETH-BTC',
  price: '0.10367000',
  open_24h: '0.10425000',
  volume_24h: '12113.0009517',
  low_24h: '0.10367000',
  high_24h: '0.10367000',
  volume_30d: '848221.84851239',
  best_bid: '0.10367',
  best_ask: '0.10368',
  side: 'sell',
  time: '2018-01-30T03:05:10.890000Z',
  trade_id: 3981807,
  last_size: '0.88000000' }

{ type: 'ticker',
  sequence: 868772602,
  product_id: 'ETH-BTC',
  price: '0.10377000',
  open_24h: '0.10425000',
  volume_24h: '12113.24308329',
  low_24h: '0.10350000',
  high_24h: '0.10377000',
  volume_30d: '848222.09064398',
  best_bid: '0.10367',
  best_ask: '0.10377',
  side: 'buy',
  time: '2018-01-30T03:05:22.886000Z',
  trade_id: 3981811,
  last_size: '1.14213159' }

{ type: 'ticker',
  sequence: 868775990,
  product_id: 'ETH-BTC',
  price: '0.10369000',
  open_24h: '0.10433000',
  volume_24h: '12149.30169254',
  low_24h: '0.10369000',
  high_24h: '0.10550000',
  volume_30d: '848168.14866565',
  best_bid: '0.10368',
  best_ask: '0.10369',
  side: 'buy',
  time: '2018-01-30T03:07:06.348000Z',
  trade_id: 3981812,
  last_size: '0.04326887' }

Did this issue get resolved?

I think this is still broken


MNT:Add cmake flag to fix osx build

➜  Boost.NumPy git:(master) ✗ cmake -D Boost_NO_BOOST_CMAKE=ON MACOSX_RPATH=/opt/local/lib .
-- Detected architecture 'x86_64'
-- Using Python3
CMake Warning at /opt/local/share/cmake-3.6/Modules/FindBoost.cmake:1459 (message):
  No header defined for python3; skipping header check
Call Stack (most recent call first):
  CMakeLists.txt:48 (find_package)

-- Boost version: 1.60.0
-- Found the following Boost libraries:
--   python3
-- Boost Paths:
-- Include  : /usr/local/include
-- Libraries: /usr/local/lib/libboost_python3-mt.dylib
-- Configuring done
CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   boost_numpy

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /Users/arkilic/git/Boost.NumPy

Thanks the contribution; change has been merged (after also bumping the required CMake version).


gretl: 2020b -> 2020e

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/gretl/versions.
meta.description for gretl is: "A software package for econometric analysis"
meta.homepage for gretl is: "http://gretl.sourceforge.net"
meta.changelog for gretl is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2020e with grep in /nix/store/s7fdyw6mq76d63mmk37f2s06l2f6jdq3-gretl-2020e

directory tree listing: https://gist.github.com/0df2a13d4a92224317795d21bbcbd1f7

du listing: https://gist.github.com/33be55dbf4bfa0b0e884e33ade61fa3f

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
gretl

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/s7fdyw6mq76d63mmk37f2s06l2f6jdq3-gretl-2020e \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A gretl https://github.com/r-ryantm/nixpkgs/archive/f9a694106bfd57d4fe9ca2ad580891527ffb7965.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/s7fdyw6mq76d63mmk37f2s06l2f6jdq3-gretl-2020e
ls -la /nix/store/s7fdyw6mq76d63mmk37f2s06l2f6jdq3-gretl-2020e/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

1 package built:

gretl

Maintainer pings
cc @dmrauh for testing.

Result of nixpkgs-review pr 105650 run on x86_64-darwin 1

1 package built:

gretl


[Ethereum]: Add support for abi.encodePacked() | Resolves #3679

Description
This pull request adds support for abi.encodePacked() as described in issue #3679. The implementation follows the non-standard packed mode encoding, which concatenates types shorter than 32 bytes directly without padding or sign extension, encodes dynamic types in-place without the length field, and encodes array elements padded but in-place.
How to test
Reviewers can test the changes by running the included test cases that cover various scenarios for abi.encodePacked() encoding:

cargo test encode_packed_tokens
Specific test cases:

encode_packed_address
encode_packed_bytes
encode_packed_string
encode_packed_int
encode_packed_bool
encode_packed_uint
encode_packed_fixed_bytes
encode_packed_mixed
encode_packed_array

Ensure that all tests pass and verify the encoded outputs match the expected values.
Types of changes

New feature (non-breaking change which adds functionality)

Checklist

[x] Create pull request as draft initially, unless it's complete.
[x] Add tests to cover changes as needed.
[ ] Update documentation as needed.
[x] If there is a related Issue, mention it in the description.

If you're adding a new blockchain

[ ] I have read the guidelines for adding a new blockchain.

Hi, thanks @satoshiotomakan. I have addressed these.
Can you spare time to look at the corrections I made regarding Int and Uint before I open another PR?
Here:
https://github.com/trustwallet/wallet-core/compare/master...theghostmac:wallet-core:add-abi-encode-packed-support.

@theghostmac why not push changes to the same branch to avoid creating new PRs?
Otherwise we lose previous comments and change history

Updated. Everything is in theghostmac:add-abi-encode-packed-support. I hope this matches your expectation.
The specific test case you sent from miguelmota, it passes also.


Update CircleCI image

See https://circleci.com/docs/next-gen-migration-guide/

I'd prefer for this to target stable first, then merge from stable->master.  I was due to trigger a merge any day now, just as soon as @WalterBright answers his emails and gives me access to ftp.digitalmars.com. :-)

Rebased to stable.


Integrate mirrored pages

Previous conversation but against master branch: https://github.com/unboxed/ubxd_web_refresh/pull/86

Heavily tested, merging!


プルリクエストの一覧をステータスに応じてソート

やったこと

プルリク一覧をソート

レビュー待ち、レビュー中、承認済 の順番でソート

close #105

Codecov Report

Merging #109 (7fb45b9) into main (f420b83) will increase coverage by 3.41%.
The diff coverage is 94.73%.

@@            Coverage Diff             @@
##             main     #109      +/-   ##
==========================================
+ Coverage   45.68%   49.10%   +3.41%
==========================================
  Files         107      107
  Lines        2666     2682      +16
  Branches      138      139       +1
==========================================
+ Hits         1218     1317      +99
+ Misses       1385     1308      -77
+ Partials       63       57       -6

Flag
Coverage Δ

unittests
49.10% <94.73%> (+3.41%)
:arrow_up:

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

Impacted Files
Coverage Δ

renderer/src/models/PullRequest.ts
0.00% <0.00%> (ø)

...components/RepositorySection/RepositorySection.tsx
100.00% <100.00%> (+100.00%)
:arrow_up:

renderer/src/components/PullRequestItem/index.ts
100.00% <0.00%> (+100.00%)
:arrow_up:

renderer/src/components/RepositorySection/index.ts
100.00% <0.00%> (+100.00%)
:arrow_up:

...src/components/PullRequestItem/PullRequestItem.tsx
100.00% <0.00%> (+100.00%)
:arrow_up:

...omponents/RepositorySectionHeadingContent/index.ts
100.00% <0.00%> (+100.00%)
:arrow_up:

...HeadingContent/RepositorySectionHeadingContent.tsx
100.00% <0.00%> (+100.00%)
:arrow_up:

Continue to review full report at Codecov.

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


[OFFICIAL] Generated Issue: ConnectionTimeoutException

Please fill out the details below.
Summary:
Steps to reproduce:
Additional Details
Jikan Parser Version: v4.0.2@4df99e0df5a4adf2b92e7c6fc663de8fd4b9c325
PHP: 8.0.19
Redis: Connected
Exception: MongoDB\Driver\Exception\ConnectionTimeoutException
Code: 13053
Message: No servers yet eligible for rescan
Trace: /var/www/jikan-rest/vendor/mongodb/mongodb/src/functions.php on line 487
Request: GET /v4/anime?genres=1&page=238

Resolved. Feel free to re-open the issue if it happens again.


'Created Matches' should be in date order

Verified that Javascript is, indeed, doing a date comparison, not string.


Check cargo fmt from CI

Block merging changes that don't have canonical formatting.

Additionally, we could also execute clippy in CI, resulting in a more ergonomic and standardized code. And in some places, if it is needed and reasonable, we could ignore specific warnings.

Yep, we do already check Clippy:
https://github.com/sourcefrog/cargo-mutants/blob/93a26a0d5468b552f6a58a12e2a98ca6881dff1f/.github/workflows/tests.yml#L39-L40


iOS location access cannot be toggled in-app

Version
1.0.1
Affected Devices
Apple | iPhone 11 Pro | iOS 13.4.1
Affected Languages
English
Steps to reproduce

Progress through onboardingflow to Location Access section
Click "Enable Location Access"
Click "Don't Allow"
Finish Setup
Go to "Dashboard" from "Home"
You will see "Location Inactive"
Tap "Location Inactive" in Red
UI will show "Location Active" in Green
Tap the back arrow to return "Home"
Status screen will show briefly as "green" and after some delay will return to "red"
Click "Enable Location" or go to "Dashboard"
You will see it now says "Location Inactive" in red
Repeat steps 5 through 12

Expected Behavior
I expect toggling "Location Inactive" to toggle my location access, and the UI displaying "Location Active" in green makes me think I have enable location access. The initial prompt in the onboarding flow is the only opportunity I have to enable location access in-app, that is not explained to the user in the UI and the UI gives the false appearance that the user is enabling location when they are not. I would expect clearer indication/separation between the in-app toggle and the current state my iOS location access, as well as a way to fix any issues with OS location access (instructions to adjust in Settings or button to trigger another OS prompt)

I can look into this issue. For Android we have similar issue: if we don't allow tracking location in settings - we can't change it from the app side.

Thanks @denispapakul ! Here is a little prototype of how I would have expected it to work on iOS (would imagine something similar for Android)... not sure whats possible or not so take the flow with a grain of salt (also has some design differences compared to the 1.0.1 release so please just ignore those).
https://www.figma.com/proto/79OwaKqHvSeriExpYzAvVN/PATHS-Exploration-April-and-May-2020?node-id=1726%3A15008&viewport=906%2C785%2C0.5&scaling=min-zoom

Just was checking the app again and (for some reason) it actual did behave as I expected (illustrated in the prototype I posted) - I received an OS prompt by clicking the “enable location” button as well as “location inactive”... but after clicking “don’t allow” it reverted to the behavior I originally describe in the ticket.


iceberg: don't bundle hdfs with iceberg runtime

Tries to fix #217
test plan:
first look at the dependency graph to understand what will be excluded

> Configure project :
org.ajoberstar.gradle.git.release.semver.SemVerStrategyState(scopeFromProp:null, stageFromProp:SNAPSHOT, currentHead:org.ajoberstar.grgit.Commit(0c6afe50def689ec1455a8e11ada45f922fb4bee, [b3d3ab9f69b8f32153068c40fe7460059ec519e4], org.ajoberstar.grgit.Person(Suren Nihalani, snihalani@linkedin.com), org.ajoberstar.grgit.Person(Suren Nihalani, snihalani@linkedin.com),<PHONE_NUMBER>, iceberg: don't bundle hdfs with iceberg runtime

test plan:
./gradlew clean :iceberg-runtime:assemble
vim ./runtime/build/libs/iceberg-runtime-*
and then search for org.apache.hadoop in vim
, iceberg: don't bundle hdfs with iceberg runtime), currentBranch:org.ajoberstar.grgit.Branch(refs/heads/master, org.ajoberstar.grgit.Branch(refs/remotes/origin/master)), repoDirty:true, nearestVersion:org.ajoberstar.gradle.git.release.semver.NearestVersion(0.0.0, 0.0.0, 389, 389), inferredNormal:null, inferredPreRelease:null, inferredBuildMetadata:null)
org.ajoberstar.gradle.git.release.semver.SemVerStrategyState(scopeFromProp:null, stageFromProp:SNAPSHOT, currentHead:org.ajoberstar.grgit.Commit(0c6afe50def689ec1455a8e11ada45f922fb4bee, [b3d3ab9f69b8f32153068c40fe7460059ec519e4], org.ajoberstar.grgit.Person(Suren Nihalani, snihalani@linkedin.com), org.ajoberstar.grgit.Person(Suren Nihalani, snihalani@linkedin.com),<PHONE_NUMBER>, iceberg: don't bundle hdfs with iceberg runtime

test plan:
./gradlew clean :iceberg-runtime:assemble
vim ./runtime/build/libs/iceberg-runtime-*
and then search for org.apache.hadoop in vim
, iceberg: don't bundle hdfs with iceberg runtime), currentBranch:org.ajoberstar.grgit.Branch(refs/heads/master, org.ajoberstar.grgit.Branch(refs/remotes/origin/master)), repoDirty:true, nearestVersion:org.ajoberstar.gradle.git.release.semver.NearestVersion(0.0.0, 0.0.0, 389, 389), inferredNormal:null, inferredPreRelease:null, inferredBuildMetadata:null)
Inferred project: iceberg, version: 0.1.0-SNAPSHOT
Publication nebula not found in project :.

> Task :iceberg-runtime:dependencies

------------------------------------------------------------
Project :iceberg-runtime
------------------------------------------------------------

compile - Dependencies for source set 'main' (deprecated, use 'implementation' instead).
+--- project :iceberg-api
+--- project :iceberg-common
+--- project :iceberg-core
|    +--- project :iceberg-api
|    +--- project :iceberg-common
|    +--- org.apache.avro:avro:1.8.2
|    |    +--- org.codehaus.jackson:jackson-core-asl:1.9.13
|    |    +--- org.codehaus.jackson:jackson-mapper-asl:1.9.13
|    |    |    \--- org.codehaus.jackson:jackson-core-asl:1.9.13
|    |    +--- com.thoughtworks.paranamer:paranamer:2.7
|    |    +--- org.xerial.snappy:snappy-java:<IP_ADDRESS> -> <IP_ADDRESS>
|    |    +--- org.apache.commons:commons-compress:1.8.1
|    |    +--- org.tukaani:xz:1.5
|    |    \--- org.slf4j:slf4j-api:1.7.7 -> 1.7.22
|    +--- com.fasterxml.jackson.core:jackson-databind:2.6.7
|    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.6.0
|    |    \--- com.fasterxml.jackson.core:jackson-core:2.6.7
|    +--- com.fasterxml.jackson.core:jackson-core:2.6.7
|    \--- com.github.ben-manes.caffeine:caffeine:2.7.0
|         +--- org.checkerframework:checker-qual:2.6.0
|         \--- com.google.errorprone:error_prone_annotations:2.3.3
+--- project :iceberg-parquet
|    +--- project :iceberg-api
|    +--- project :iceberg-core (*)
|    \--- org.apache.parquet:parquet-avro:1.10.0
|         +--- org.apache.parquet:parquet-column:1.10.0
|         |    +--- org.apache.parquet:parquet-common:1.10.0
|         |    |    +--- org.apache.parquet:parquet-format:2.4.0
|         |    |    |    \--- org.slf4j:slf4j-api:1.7.2 -> 1.7.22
|         |    |    \--- org.slf4j:slf4j-api:1.7.22
|         |    +--- org.apache.parquet:parquet-encoding:1.10.0
|         |    |    +--- org.apache.parquet:parquet-common:1.10.0 (*)
|         |    |    \--- commons-codec:commons-codec:1.10
|         |    \--- commons-codec:commons-codec:1.10
|         +--- org.apache.parquet:parquet-hadoop:1.10.0
|         |    +--- org.apache.parquet:parquet-column:1.10.0 (*)
|         |    +--- org.apache.parquet:parquet-format:2.4.0 (*)
|         |    +--- org.apache.parquet:parquet-jackson:1.10.0
|         |    +--- org.codehaus.jackson:jackson-mapper-asl:1.9.13 (*)
|         |    +--- org.codehaus.jackson:jackson-core-asl:1.9.13
|         |    +--- org.xerial.snappy:snappy-java:<IP_ADDRESS>
|         |    \--- commons-pool:commons-pool:1.6
|         +--- org.apache.parquet:parquet-format:2.4.0 (*)
|         +--- org.apache.avro:avro:1.8.2 (*)
|         \--- it.unimi.dsi:fastutil:7.0.13
+--- project :iceberg-spark
|    +--- project :iceberg-api
|    +--- project :iceberg-common
|    +--- project :iceberg-core (*)
|    +--- project :iceberg-orc
|    |    +--- project :iceberg-api
|    |    +--- project :iceberg-core (*)
|    |    \--- org.apache.orc:orc-core:1.5.5
|    |         +--- org.apache.orc:orc-shims:1.5.5
|    |         |    \--- org.slf4j:slf4j-api:1.7.5 -> 1.7.22
|    |         +--- com.google.protobuf:protobuf-java:2.5.0
|    |         +--- commons-lang:commons-lang:2.6
|    |         +--- io.airlift:aircompressor:0.10
|    |         +--- javax.xml.bind:jaxb-api:2.2.11
|    |         +--- org.apache.hadoop:hadoop-hdfs:2.2.0
|    |         |    +--- com.google.guava:guava:11.0.2
|    |         |    +--- com.sun.jersey:jersey-core:1.9
|    |         |    +--- com.sun.jersey:jersey-server:1.9
|    |         |    |    +--- asm:asm:3.1
|    |         |    |    \--- com.sun.jersey:jersey-core:1.9
|    |         |    +--- commons-cli:commons-cli:1.2
|    |         |    +--- commons-codec:commons-codec:1.4 -> 1.10
|    |         |    +--- commons-io:commons-io:2.1
|    |         |    +--- commons-lang:commons-lang:2.5 -> 2.6
|    |         |    +--- commons-logging:commons-logging:1.1.1
|    |         |    +--- log4j:log4j:1.2.17
|    |         |    +--- com.google.protobuf:protobuf-java:2.5.0
|    |         |    +--- org.codehaus.jackson:jackson-core-asl:1.8.8 -> 1.9.13
|    |         |    +--- org.codehaus.jackson:jackson-mapper-asl:1.8.8 -> 1.9.13 (*)
|    |         |    \--- xmlenc:xmlenc:0.52
|    |         +--- org.apache.hive:hive-storage-api:2.6.0
|    |         |    +--- commons-lang:commons-lang:2.6
|    |         |    \--- org.slf4j:slf4j-api:1.7.10 -> 1.7.22
|    |         \--- org.slf4j:slf4j-api:1.7.5 -> 1.7.22
|    \--- project :iceberg-parquet (*)
+--- project :iceberg-pig
|    +--- project :iceberg-api
|    +--- project :iceberg-common
|    +--- project :iceberg-core (*)
|    \--- project :iceberg-parquet (*)
+--- project :iceberg-hive
|    \--- project :iceberg-core (*)
+--- org.apache.avro:avro:1.8.2 (*)
\--- org.apache.parquet:parquet-avro:1.10.0 (*)

(*) - dependencies omitted (listed previously)

A web-based, searchable dependency report is available by adding the --scan option.

BUILD SUCCESSFUL in 0s
1 actionable task: 1 executed

./gradlew clean :iceberg-runtime:assemble
vim ./runtime/build/libs/iceberg-runtime-*
and then search for org.apache.hadoop in vim

@rdblue there are some changes over here which are not specific to #217, and there are a couple more unrelated changes I'd like to point out[1]. Let  me know if you'd like it to club it as part of this PR or make those changes as part of a separate PR and keep this PR specific to dependency exclusion. My fine both ways, if we club it as part of this PR we can update the summary in #217 and this PR
[1]. Some other changes I'd like to add

In Presto-runtime we are excluding guava. I think we should include and shade it.

@SurenNihalani and @rdsr, as part of adding user docs and testing with Spark 2.4, I updated the contents of the Spark runtime Jar last night and just opened #250. That work goes a bit beyond the scope of this PR because it removes any library already in Spark's jars folder, relocates all shaded classes, and cleans up some of the problems pointed out here.
It doesn't matter to me which PR we go with, but I think the changes from #250 are a good starting point because that cleans up this area quite a bit. Would you like to combine this PR and that one, or review that one and rebase to get this work in?

Sounds good to me. Lets review #250 and after #250 is committed, we can do the remaining work here if any.

@rdsr and @SurenNihalani, I've merged #250 so this can continue. Thanks for being flexible on the conflict!

@SurenNihalani, any update on this PR? What tasks are still outstanding?

I looked at this the other day. HDFS runtime problem seems to be solved in the master because of the compileOnly strategy. I'll do rest of the tasks tomorrow evening and put up a PR.

@SurenNihalani, is there anything else to do in this PR? If not, would you close it?

hey @rdblue , yeah, I've force pushed the PR here already. We just need to merge it.

@SurenNihalani, thanks for the update. What do these changes do? Can you update the PR description? I want to understand why these changes are needed.

@SurenNihalani, thanks for the replies! The change from compile to compileOnly is my only remaining concern.

I figured out what was happening and I agree with the change, so I merged this. Thanks @SurenNihalani!

yeah, sorry about dropping the ball. I needed time to investigate the difference between maven and ivy plugins to understand compileOnly to explain my change. Thanks for picking this up


defineProps crashes volar

Describe the bug
When the @vue-macros/volar/define-props plugin is enabled, Volar crashes with the following error.
[Error - 11:20:29 AM] Request textDocument/codeAction failed.
  Message: Request textDocument/codeAction failed with message: Cannot read properties of undefined (reading 'defineProps')
  Code: -32603
$PWD/node_modules/.pnpm/@vue-macros+volar@0.5.15_vue@3.2.45/node_modules/@vue-macros/volar/dist/define-props.js:3
  vueCompilerOptions.macros.defineProps.push("$defineProps");
                            ^

TypeError: Cannot read properties of undefined (reading 'defineProps')
    at plugin ($PWD/node_modules/.pnpm/@vue-macros+volar@0.5.15_vue@3.2.45/node_modules/@vue-macros/volar/dist/define-props.js:3:29)
    at $HOME/.vscode-server/extensions/vue.volar-1.0.20-linux-x64/dist/node/server.js:888:10271
    at Array.map (<anonymous>)
    at qOe ($HOME/.vscode-server/extensions/vue.volar-1.0.20-linux-x64/dist/node/server.js:888:10264)
    at Object.WOe ($HOME/.vscode-server/extensions/vue.volar-1.0.20-linux-x64/dist/node/server.js:1017:300)
    at Object.getLanguageModules ($HOME/.vscode-server/extensions/vue.volar-1.0.20-linux-x64/dist/node/server.js:1132:8460)
    at $HOME/.vscode-server/extensions/vue.volar-1.0.20-linux-x64/dist/node/server.js:495:1068
    at Array.map (<anonymous>)
    at Object.f [as getLanguageService] ($HOME/.vscode-server/extensions/vue.volar-1.0.20-linux-x64/dist/node/server.js:495:990)
    at $HOME/.vscode-server/extensions/vue.volar-1.0.20-linux-x64/dist/node/server.js:495:15810
[Info  - 11:20:29 AM] Connection to server got closed. Server will restart.

This appears to only effect remote ssh workspaces. Local and WSL workspaces seems to work fine. I have not tested it with a container workspace.
I am however able to work around it by adding this to vueCompilerOptions.
{
  "vueCompilerOptions": {
    "macros": {
      "defineProps": []
    }
  }
}

Reproduction
N/A
System Info
System:
    OS: Linux 5.15 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
    CPU: (4) x64 Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
    Memory: 11.51 GB / 15.63 GB
    Container: Yes
    Shell: 6.21.00 - /bin/csh
  Binaries:
    Node: 16.16.0 - ~/.nvm/versions/node/v16.16.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.16.0/bin/yarn
    npm: 9.3.0 - ~/.nvm/versions/node/v16.16.0/bin/npm

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

it requires the latest volar. Please upgrade your vue-tsc and vscode extension to 1.0.24.


web

Bug description:
The web fails to inject angular module ui.bootstrap.demo
http://angular-ui.github.io/bootstrap/

@exejutable, per the issue template, please search both open and closed issues prior to entering anything.  The issue is most likely due to a browser extension (say Adblock Plus blocking the FastClick library).  Looking at your console will indicate thus.
We have seen issues with users behind proxy servers as well.

this is now fixed - even with an adblocker installed.


Feature requests: Don't have backup deletion managed by puppet.

I think that I can try to work on this if I get time but am putting it here just to document. The deletion of backups probably shouldn't be handled by puppet but rather a script stored locally. We had to disable the puppet agent on our stash server while troubleshooting the setenv.sh template issue and the backups almost filled the hard drive.

Are you saying that the stash module should not manage the cleanups of the backups? Or that instead of using the tidy type, we should use the cron type with a script to remove old backup files?

Yeah, since there is already have a cron in place I would probably modify the backup_cmd to handle deleting the older files in addition to doing the backup. Not sure whether adding it to a bash script or just adding it to the command would be the better route though.

claflico, would you consider submitting a PR for this? I cant justify implementing it as I feel the current method is working well for my environments.

Closing this issue. Happy to reopen if you would consider submitting a patch for this feature.


[png] link to debug version

Host Environment

OS: MacOS M1
Compiler: cland 12

To Reproduce
Steps to reproduce the behavior:
./vcpkg install png
Failure logs
Building an app in RelWithDebInfo depending on png links to the debug version of libpng instead of release as all the other vcpkg libs:
 /Users/cdc/vcpkg/installed/arm64-osx/debug/lib/libpng.a

Hi @cdcseacave
Thanks for posting this issue.
Could you please provide your project sample? Have you tried debug type and release type?
Note: You may be install libpng instead of png.

@cdcseacave
Is this still a problem for you?

yes, it is

Sorry, I cannot reproduce this on my local.
vcpkg@VCPKGMM-12 build % /Users/vcpkg/Nancy/vcpkg/downloads/tools/cmake-3.19.2-osx/cmake-3.19.2-macos-universal/CMake.app/Contents/bin/cmake -DCMAKE_TOOLCHAIN_FILE=../scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=arm64-osx -DCMAKE_BUILD_TYPE=RelWithDebInfo
CMake Warning:
  No source or binary directory provided.  Both will be assumed to be the
  same as the current working directory, but note that this warning will
  become a fatal error in future CMake releases.

-- The C compiler identification is AppleClang <IP_ADDRESS>00032
-- The CXX compiler identification is AppleClang <IP_ADDRESS>00032
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ZLIB: /Users/vcpkg/Nancy/vcpkg/installed/arm64-osx/lib/libz.a (found version "1.2.11")
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/vcpkg/Nancy/vcpkg/build
vcpkg@VCPKGMM-12 build % /Users/vcpkg/Nancy/vcpkg/downloads/tools/cmake-3.19.2-osx/cmake-3.19.2-macos-universal/CMake.app/Contents/bin/cmake --build .
Scanning dependencies of target main
[ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
[100%] Linking CXX executable main
ld: warning: ld: warning: ignoring file /Users/vcpkg/Nancy/vcpkg/installed/arm64-osx/lib/libz.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64ignoring file /Users/vcpkg/Nancy/vcpkg/installed/arm64-osx/lib/libpng16.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64

[100%] Built target main

Please provide the steps to reproduce. If possible, please also provide your project sample.
Here are my project:
CMakeLists.txt
    cmake_minimum_required(VERSION 3.0)
    project(test)
    find_package(libpng CONFIG REQUIRED)

    add_executable(main main.cpp)

    target_link_libraries(main PRIVATE png_static)

main.cpp
     #include <png.h>
      #include <stdio.h>

      int main()
      {
         return 0;
      }

I can not reproduce it anymore with the latest code, maybe it was fixed, let's close this for now, thank you


Mistranslation in Japanese version

[Enter feedback here]
"Health record" is translated into "正常性レコード" in Japanese version.
As "正常性" means "normality", not "health" in Japanese.
In IRM settings page, we describe it as "健康記録".
This is natual for Japanese and we have to make the notation the same.
English version:
Health record access indicators (preview):
Japanese version:
正常性レコード アクセス インジケーター (プレビュー):

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

ID: 5147f5e8-a267-ee55-de12-d80ab29804c2
Version Independent ID: 945fc70f-1861-d2e9-4d46-f56eafb53766
Content: Insider risk management settings - Microsoft Purview (compliance)
Content Source: microsoft-365/compliance/insider-risk-management-settings.md
Service: o365-seccomp
GitHub Login: @robmazz
Microsoft Alias: robmazz

@tiburd Please help us in resolving this issue. Thanks

Thank you for submitting this localization issue.
I submitted a translation bug: 233747
I'm closing this issue because the Global Services team will handle it from here.


Support resolving a major release on deno.land/x

This discussion started on Discord at this message.
It would be very cool if deno.land/x could support resolving a major release, just how it supports resolving the latest version.
The deno.land/x does not support mutable git tags, despite GitHub itself recommends that approach for the actions on GitHub Actions:

Make the new release available to those binding to the major version tag: Move the major version tag (v1, v2, etc.) to point to the ref of the current release. This will act as the stable release for that major version. You should keep this tag updated to the most recent stable minor/patch release.

git tag -fa v1 -m "Update v1 tag"
git push origin v1 --force

Since that's not likely going to change (but perhaps you could open an exception for these special tags - v1 and v2 for example), the proposal is to support another way to stick with a major release which is resolved by deno.land/x itself.
In npm packages, we can use ^ before the version number to accomplish the same. Perhaps something like that as well? Something like:
deno run<EMAIL_ADDRESS>
That might look a bit weird, but I'm sure we can refine it to something nifty.
This is important, I believe the overwhelming majority of npm modules uses this pattern for example. That's the whole point of semver itself. The semantic-release is a great tool to help projects to enforce this pattern. They say: "release as often as possible" (and they have their reasonings). If we have a module getting bug fixes or performance improvements every day, it would be very boring if we had to create a new commit just to upgrade every single new patch release of it, despite we know that it won't have any breaking change that we have to care about.

The Deno CLI will always be un-opinionated about the URL... it is just a URL.
Support semver matching would be a feature request for the registry, therefore the move of the issue to here.

Closing in favour of denoland/dotland#606


Interior face attributes are not transfered from Mesh to ParMesh

Hi,
I'm trying to set interior face attributes in a serial Mesh, and the construct a ParMesh from it. If I iterate over the serial mesh's faces I can set the attributes (after adding a non-const overload of GetFace to mesh.hpp) as:
for (int i = 0; i < mesh->GetNumFaces(); i++)
{
   auto *face = mesh->GetFace(i);
   face->SetAttribute(10);
}

However, once I create a parallel mesh from the serial mesh with this constructor:
ParMesh(MPI_Comm comm, Mesh &mesh, int *partitioning_ = NULL, int part_method = 1);

these attributes are lost.
Is there a way for them to be retained when creating a parallel mesh?
Thanks,
Tucker

Is your mesh a non-conforming mesh?

Not non-conforming. I create and modify it just like this (again, after adding a non-const overload of GetFace):
// generate a simple tet mesh
std::unique_ptr<mfem::Mesh> mesh(
   new mfem::Mesh(mfem::Mesh::MakeCartesian2D(nxy, nxy,
                                  mfem::Element::TRIANGLE)));

// assign attributes to top and bottom sides
for (int i = 0; i < mesh->GetNE(); ++i)
{
   auto *elem = mesh->GetElement(i);

   mfem::Array<int> verts;
   elem->GetVertices(verts);

   bool below = true;
   for (int i = 0; i < verts.Size(); ++i)
   {
      auto *vtx = mesh->GetVertex(verts[i]);
      if (vtx[1] <= 0.5)
      {
         below = below;
      }
      else
      {
         below = false;
      }
   }
   if (below)
   {
      elem->SetAttribute(1);
   }
   else
   {
      elem->SetAttribute(2);
   }
}

// assign attributes to middle edge
for (int i = 0; i < mesh->GetNumFaces(); i++)
{
   auto *face = mesh->GetFace(i);

   mfem::Array<int> verts;
   face->GetVertices(verts);

   bool on_edge = true;
   for (int i = 0; i < verts.Size(); ++i)
   {
      auto *vtx = mesh->GetVertex(verts[i]);
      if (abs(vtx[1] - 0.5) < 1e-6)
      {
         on_edge = on_edge;
      }
      else
      {
         on_edge = false;
      }
   }
   if (on_edge)
   {
      face->SetAttribute(1);
   }
   else
   {
      face->SetAttribute(0);
   }
}

mesh->SetAttributes();

Then, I try to make a parallel mesh as
pmesh = std::make_unique<mfem::ParMesh>(comm, *mesh);

If I then iterate over the faces of the parallel mesh, the face attributes are all set to 1, but the element attributes remain to what I'd set them to.

Oh, you are setting attributes on (some) face elements -- MFEM does not use these actually.
What you can do, instead, is to add "boundary" elements corresponding to the faces you want. The boundary attributes of these will then be propagated.

Thanks for the reply @v-dobrev. Perhaps it would help if I explained a bit more what I'm really trying to accomplish. Similar to #3415, I'm trying to have two different domains coupled by a "special" model. In my case, I'm solving a temperature field problem with a thermal contact resistance interface between two materials.
Based on the suggestions in that issue, I'm using a DG space for my whole domain, and want a specific interior face integrator active only on the boundary between the two domains. I'm trying to determine when to use that integrator based on the attribute of the FaceElementTransformations passed to it.
If I add these internal boundaries, and then attribute them, will that affect anything else?
Or, can you suggest a more appropriate way to use/not use the interior face integrator?
Thanks,
Tucker

@v-dobrev is there a way, when iterating over the interior faces as I am, to tell MFEM to turn the face into an internal boundary? Or to otherwise programmatically add internal boundary elements? I can't see anything in the mesh.hpp header.
Thanks,
Tucker

Hi @tuckerbabcock,
Based on your point above about these interfaces being between material domains, I think you could use this idiom:
   for (int f = 0; f < smesh.GetNumFaces(); ++f)
   {
      int e1, e2;
      smesh.GetFaceElements(f, &e1, &e2);
      if (e1 >= 0 && e2 >= 0 && smesh.GetAttribute(e1) != smesh.GetAttribute(e2))
      {
         // This is the internal face between attributes.
         auto *new_elem = smesh.GetFace(f)->Duplicate(&smesh);
         new_elem->SetAttribute(5);
         smesh.AddBdrElement(new_elem);
      }
   }

taken from hughcars/ncmesh-interior-boundary-dev in the file test_ncmesh.cpp. This is adding a new boundary attribute 5, on those faces that are discovered as being between different domain attributes. You could change this to check for particular values instead, but I was just looking for difference.
Word of warning, if you're wanting to do AMR adaptivity with internal boundaries, as the PR that introduces that branch suggests, they're not currently supported (but will be very shortly hopefully).

Just to add to @hughcars reply: after adding the new boundary elements, you should call the method Mesh::SetAttributes -- it updates the arrays Mesh::attributes and Mesh::bdr_attributes to be consistent with the current set of element and boundary attributes present in the Mesh.

What integrators are you using and what method(s) do you use to add them to the NonlinearForm?

We had this same issue for a custom integrator in DG. In this PR we tried to provide a solution: https://github.com/mfem/mfem/pull/3422

Okay, I think I understand: you want to apply the DG integrator(s) just to the interior "boundary" faces. With the methods AddInteriorFaceIntegrator and AddBdrFaceIntegrator this is not possible -- the former applies the integrator to all interior faces, and the latter applies to just real boundary faces (i.e. faces that have just one neighboring volume element).
As @lmdiazangulo said, one needs to add a new type of method to handle this case. Take a look at his PR and maybe you can help review and finalize it.

Thanks for the suggestions @lmdiazangulo and @v-dobrev. I've opened a PR (#3777) that implements a potential fix based on #3422. We can move the discussion there.


Mann 2018

Reference
doi or URL: 10.1038/s41598-018-28091-9

This was already added in #21 is there a reason for the re-opening?

Sorry, my mistake!


Reload is called unnecessarily

Bug Description
Currently, every _configure, the charm would either reload configuration
https://github.com/canonical/prometheus-k8s-operator/blob/e75eb0b1a7669c945dabb6b4ba8cfe583697533b/src/charm.py#L272-L273
or replan:
https://github.com/canonical/prometheus-k8s-operator/blob/e75eb0b1a7669c945dabb6b4ba8cfe583697533b/src/charm.py#L281-L282
This means the prometheus service will be unavailable for potentially significant duration (e.g. big wal replay).
To Reproduce
NA
Environment
NA
Relevant log output
NA

Additional context

This came up while adding a call to _configure in update-status as a workaround for https://github.com/canonical/traefik-k8s-operator/issues/78.
Note:  WAL replay can take longer than timeout duration.

Also as part of this change we need to consider comments by @rbarry82 on #349:

"call _configure|_common_exit_hook hoping it will resolve BlockedStatus if an event was emitted before ingress is ready is a sledgehammer which is bad considering we already have an issue about /-/reload being called to often

Agreed, but to limit the scope of this change, and given #342 will be addressed very soon, can live with this for now?

what whatever logic it would take for "is BlockedStatus set during _update_status? Is it still valid? If it is, clear it, if not, move on) would be more explicit, cleaner, and more legible.

This would be in direct contrast to the common exit hook pattern. I'd rather not mix both approaches in the same charm. Also, once #342 is fixed this will be much less painful to look at.

seems wrong that # Reload may fail if ingress ... wold lead to a BlockedStatus(CORRUPT_PROMETHEUS_CONFIG_MESSAGE)

Agreed. I don't particularly like that status comparison pattern and it should be fixed as part of #342.

prometheus_server.Prometheus.* should provide distinctions between timeouts and ConnectionError to flag the "real" status.

Sounds presumptuous at first glance. And what will the charm do with the various exceptions? Just choose one message over another? Maybe, if we have insight, expose a retry setting the charm could use?
Originally posted by @sed-i in https://github.com/canonical/prometheus-k8s-operator/pull/349#discussion_r961335529

Agreed, but to limit the scope of this change, and given #342 will be addressed very soon, can live with this for now?

A little self-referential, since this is #342 ;) Are we addressing it here then?

This would be in direct contrast to the common exit hook pattern. I'd rather not mix both approaches in the same charm. Also, once #342 is fixed this will be much less painful to look at.

I think that's a little bit the point -- the common exit hook cannot cleanly address this, but we actually do need to do so. There are multiple non-_configure places in the charm where we set BlockedStatus (in _generate_command, _on_k8s_...). "Un-setting" it isn't a massive divergence.

Agreed. I don't particularly like that status comparison pattern and it should be fixed as part of #342.

Why would it be changed there? It also affects this. There seems to be three cases where the charm may not be accessible:

Bad configuration (we can check with promtool if there's an exception raised trying to connect)
Timeout because it's replaying/mmaping HEAD chunks which haven't been written to the TSDB
Not reachable due to ingress

The first two are meaningful here.

Sounds presumptuous at first glance. And what will the charm do with the various exceptions? Just choose one message over another? Maybe, if we have insight, expose a retry setting the charm could use?

The exceptions could have a property with a message, or a lookup table in the charm, or whatever. The charm would set a status message to tell the administrator what is happening and why Prometheus may not be reachable which is more useful than a "configuration is invalid" message which may not be true or an ActiveStatus when Prometheus is actually not active/reachable.
A retry mechanism can only be so useful. For /-/reload, though, it won't be, and how we address that can certainly be discussed elsewhere (we already "know" that we'll probably have to sidestep it with @manadart's work to trigger async hooks), but we're well enough aware of the "basic" failure cases, and we need a way to flag the administrator about what the actual status is.


Convert Requirements parsing to Python 2/3

Convert the Requirements parsing scripts to be able to run in both
Python 2 and Python 3.

Run futurize steps
Change type checking for string objects to replace UTF-8 characters
Ensure that byte objects are sent to name generator in DataTableHTML

Change-Id: Ib1570af27ece72f9f71ffc02a07cf77d584c2aa9

Changes have been made.  PTAL when you get the chance, @BetsyMcPhail


sample code for cutting doesnt do anything

var inputFile = new MediaFile {Filename = @"C:\Path\To_Video.flv"};
var outputFile = new MediaFile {Filename = @"C:\Path\To_Save_ExtractedVideo.flv"};

using (var engine = new Engine())
{
    engine.GetMetadata(inputFile);

    var options = new ConversionOptions();

    // This example will create a 25 second video, starting from the
    // 30th second of the original video.
    //// First parameter requests the starting frame to cut the media from.
    //// Second parameter requests how long to cut the video.
    options.CutMedia(TimeSpan.FromSeconds(30), TimeSpan.FromSeconds(25));

    engine.Convert(inputFile, outputFile, options);
}

It does, it cuts out a clip by first seeking to a position specified as a TimeSpan, and then extracts a clip of the specified duration, again expressed as a TimeSpan

I'll check again, but last time I ran it, it didn't work on my machien with
the latest version of MediaToolkit
On Mon, Feb 1, 2016 at 5:41 PM Aydin<EMAIL_ADDRESS>wrote:

It does, it cuts out a clip by first seeking to a position specified as a
TimeSpan, and then extracts a clip of the specified duration, again
expressed as a TimeSpan
—
Reply to this email directly or view it on GitHub
https://github.com/AydinAdn/MediaToolkit/issues/26#issuecomment-178030331
.

--
Sincerely, Daniel.


Enable back log_lock_waits GUC

In commit ffd8acc this parameter became disabled because logic that handles semaphore wakeup inside ResProcSleep() when log_lock_waits is enabled was missed compared with the same thing inside ProcSleep() that incurred some negative side effects.
Current commit minimally adjusts ResProcSleep() logic to ProcSleep() one to enable log_lock_waits GUC for resource queue locks and in general.

Some critical changes in ResLockWaitCancel() function (https://github.com/greenplum-db/gpdb/commit/cf25bc0f0609afeedddcee2c5c1731cef2d648a8 and https://github.com/greenplum-db/gpdb/commit/1688bfd2fd6) will come from renewed backport from upstream. Please, account these upon review.

@InnerLife0 please take a look at this one


Helm Chart deployment

Can you update the helm chart deployment and version bump? I'm still getting after #8 with a fresh install i just started today:
Helm install failed for release default/langflow-ide with chart<EMAIL_ADDRESS>template: langflow-ide/templates/backend-statefulset.yaml:148:35: executing "langflow-ide/templates/backend-statefulset.yaml" at <.Values.zookeeper.volumes.data.existingStorageClassName>: nil pointer evaluating interface {}.volumes
Please and thank you.

Versions after 1.0-alpha have some significant changes. Any chance to upgrade soon? or, are we going to wait 1.0.beta?
BTW, in my case everything installs fine but the frontend cannot reach backend. Error message in UI only, no logs.

Hey @whur and @hakan-77 I'm releasing 0.1.0 for both the charts.
There's still a bug for the frontend in the ´ide´ chart that needs a fix on the docker image side.
https://github.com/langflow-ai/langflow/pull/2887

Does this health check PR fix this issue?

I can't find anything in either pod's logs that identify what's going on.

The specific error is that frontend is checking whether the backend is up or not by calling the health check. Since that endpoint is not reachable it just gets stuck. The request doesn't arrive to the backend at all, so there's no log

Same issue here with the latest charts on GKE. The backend pod in a crashloop without much in terms of logs.
Any ETA for fix?

I'm still getting health check errors on the langflow backend:
  Normal   Pulled     17s   kubelet            Container image "langflowai/langflow-backend:1.0.13" already present on machine
  Normal   Created    17s   kubelet            Created container langflow-ide
  Normal   Started    17s   kubelet            Started container langflow-ide
  Warning  Unhealthy  3s    kubelet            Liveness probe failed: Get "http://<IP_ADDRESS>:7860/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
  Warning  Unhealthy  3s    kubelet            Readiness probe failed: Get "http://<IP_ADDRESS>:7860/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers)```

Which version are you using?

I'm using langflow 1.0.13 and helm chart 0.1.0

@whur Did upgrading to version 1.0.13 solve the couldn't estabilish a connect issue?
I had a same problem on 1.0.11.

version 1.0.14 works fine!

@tkdguq05 no, I still get the health check issues but i have some health check errors on other pods so I can't rule out environment issue at the moment, and I haven't had the time to get into that.

version 1.0.14 works fine for me too, except, frontend to backend communication with http did not work. I had to use https end to end.  FYI- @whur

@whur @hakan-77 did you have a chance to test this out with 1.0.16? I'd like to close this issue

@whur @hakan-77 did you have a chance to test this out with 1.0.16? I'd like to close this issue

i have not, but my issues may be environmental so this can be closed.

@nicoloboschi I have tested with both 1.0.16 and 1.0.17. Everything works, thank you for the great chart!


Almost always hangs on "Install Dependencies"

Describe the bug
Takes long time on "Install Dependencies"
npm install
Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-t2oktb
Steps to reproduce
Almost any prompt will trigger it
Expected behavior
npm install is normal
Screen Recording / Screenshot
No response
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 91.1]

Additional context
No response

npm install times vary based on the size of the npm dependency tree. If npm install hangs, refreshing the page often resolves the issue (but be aware that you will lose your current chat history with a page refresh). Hope this helps!


Add Loaded/Unloaded Events from WinUI/UWP

Is your feature request related to a problem? Please describe.
UWP has the Loaded/Unloaded events which are useful for control authors to connect/disconnect things.

Loaded : "Occurs when a FrameworkElement has been constructed and added to the object tree, and is ready for interaction."
Unloaded : "Occurs when this object is no longer connected to the main object tree."

OnAttachedToVisualTree and OnDetachedFromVisualTree are similar but the sequence these methods/events are called is not the same. OnAttachedToVisualTree is called BEFORE OnApplyTemplate which is a problem if you are connecting events and the like. Therefore, Loaded would be invoked just before (or during) the control is first shown to the user -- after both OnApplyTemplate and OnAttachedToVisualTree.
Describe the solution you'd like
Add closely equivalent Loaded/Unloaded events and new OnLoaded/OnUnloaded methods to Control. This will help control authors and apps coming over from WinUI and UWP. It might also simplify some Avalonia controls.
Describe alternatives you've considered
Additional context
Add any other context or screenshots about the feature request here.

Just to add another use case to this:
For ItemsControls, Loaded fires AFTER the Panel and ItemContainerGenerator has run, thus all items are available. In Avalonia, there really is no way currently to know when an ItemsControl is truly ready. When I ported TabView, they used Loaded to do some stuff that relied on having the items in the underlying ListView available which failed in my port because the ICG hadn't run yet in OnApplyTemplate or OnAttachedToVisualTree. My solution was to listen for the first Bounds change notification as that is when the Panel and ICG are created/run and then treat that as Loaded and unsub from it after first call, which felt hacky.

@amwx This is near the top of my list for next issues to close. I imagine I'll get to it next weekend. Would appreciate a review at that time or even some ideas on good places to raise these events. I'm not very familiar with the control lifecycle in Avalonia at the moment.

@amwx This is near the top of my list for next issues to close. I imagine I'll get to it next weekend. Would appreciate a review at that time or even some ideas on good places to raise these events. I'm not very familiar with the control lifecycle in Avalonia at the moment.

I had a peek at the WPF source and checked a call stack for how this is implemented. Doesn't make a whole lot of sense as its scattered in 10 different places with weirdly named helper classes in typical MS fashion, but it looks like they fire it after the entire layout pass is completed and just before the render pass. The exact details of this are a bit more obscure.
In Avalonia, it probably could be done in LayoutManager.ExecuteLayoutPass as the last step, by keeping track of which elements haven't loaded yet. But, I'm not that familiar with the layout => rendering pipeline other than just generally how it works so one of the core team will probably have better advice.
Unloaded is much less of an issue, and I think DetachedFromVisualTree does the same thing, and Unloaded may not even be needed. Though for parity, it makes sense to include it and can probably be raised at the same time.

Here is the code/API I'm planning (some pseudocode).
public class Control
{
    public event RoutedEventHandler Loaded;
    public event RoutedEventHandler Unloaded;

    private bool _IsLoaded;

    internal void OnLoadedCore()
    {
        _IsLoaded = true;
        OnLoaded();
    }

    internal void OnUnloadedCore()
    {
        _IsLoaded = false;
        OnUnloaded();
    }

    protected virtual void OnLoaded()
    {
        Loaded?.Invoke(this, RoutedEventArgs);
    }

    protected virtual void OnUnloaded()
    {
        Unloaded?.Invoke(this, RoutedEventArgs);
    }
}

WPF also has the public IsLoaded property which I've found useful in the past. Can you also include that property in the implementation?

Yes, forgot to add it, but that's what the _IsLoaded field is for. May be a DirectProperty or a CLR property, haven't decided yet and will check WPF.


Cannot dataprep images, structured by FiJi macros.

Description:
As far as I understand, FiJi macros (for multiple files) do not create a metadata file and therefore cannot be opened by the data prep module.
Way to reproduce:

Create data structure using provided macros (for multiple files, on multiple time-lapse movies).
Run CellACDC data prep module.
Load positions from the created data structure.
Fail miserably.

(Optional) Link to data to reproduce error:
No response
Terminal output:
Initializing Data Prep module v1.2.4rc53...
Loading Y:/lab/Max/EXP3/Segmentation\Position_1\Images/xy01_s01_gray.tif...
Traceback (most recent call last):
  File "E:\ACDC\envs\acdc\lib\site-packages\cellacdc\dataPrep.py", line 2164, in openFolder
    self.loadFiles(exp_path, user_ch_file_paths, user_ch_name)
  File "E:\ACDC\envs\acdc\lib\site-packages\cellacdc\dataPrep.py", line 2017, in loadFiles
    proceed = self.init_data(user_ch_file_paths, user_ch_name)
  File "E:\ACDC\envs\acdc\lib\site-packages\cellacdc\dataPrep.py", line 1195, in init_data
    proceed = posData.askInputMetadata(
  File "E:\ACDC\envs\acdc\lib\site-packages\cellacdc\load.py", line 1352, in askInputMetadata
    if SizeT_metadata>1 and numPos>1 and warnMultiPos:
TypeError: '>' not supported between instances of 'NoneType' and 'int'

Version information:
No response

Hi @dimethylglymaxim
Sorry, I haven't used the Fiji Macros for months, so I never had a Position without the metadata file.
In a recent update, we added a warning when you are trying to load multiple timelapse positions into the main GUI. However, without the metadata, it should not try to check this because it cannot know whether it is dealing with timelapse or not.
Therefore, I just released v1.2.4rc54 which should fix this. To update, please activate the acdc environment and then run the command pip install --upgrade cellacdc. Let me know if it works, thanks!
Cheers,
Francesco
PS: DId you try using the module 0. Create data structure from microscopy/image file(s)...? It should be way more robust than the Fiji macros. It's not mandatory to use anyway, so thanks for reporting this issue that will certainly help other users using the Fiji macros.

Yep, it works now. Thank you very much.


decawave_dwm1001_dev: i2c broken due to pinctrl_nrf fix

Building the sample demo samples/sensor/lis2dh with the  decawave_dwm1001_dev result in
uart:~$ *** Booting Zephyr OS build zephyr-v3.2.0  ***
Device lis2dh12@19 is not ready

It seems to be related to this commit,  according to git bisect, https://github.com/zephyrproject-rtos/zephyr/commit/32a87215d7aa97191097357f602237f7da4a3536  : drivers: pinctrl_nrf: Fix nrf_pin_configure() implementation

If that is the case then the i2c pinctrl lines need bias-pull-up; added.

I changed boards/arm/decawave_dwm1001_dev/decawave_dwm1001_dev-pinctrl.dtsi to include bias-pull-up as defined in the fragment below, but it doesn't fix the problem
	i2c0_default: i2c0_default {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 29)>,
				<NRF_PSEL(TWIM_SCL, 0, 28)>;
			bias-pull-up;
		};
	};

	i2c0_sleep: i2c0_sleep {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 29)>,
				<NRF_PSEL(TWIM_SCL, 0, 28)>;
			bias-pull-up;
			low-power-enable;
		};
	};

Remove the pull up from the sleep mode. That should be all you need, it would enable pulling the lines up which i2c needs. You'd need to check with a scope to debug further if that does not work.

Not working better :(
I don't have a scope to perform additional check :(

The changes mentioned above fixes the issue. But there is something fishy with the flash runner, it does not reset core after flashing, you have to press reset switch on the board after the J-Link status LED on the board starts to pulse again.
@sdalu Would you like to continue and open a PR to fix this issue?
diff --git a/boards/arm/decawave_dwm1001_dev/decawave_dwm1001_dev-pinctrl.dtsi b/boards/arm/decawave_dwm1001_dev/decawave_dwm1001_dev-pinctrl.dtsi
index 8e47b5d13c6..8cc231c74b1 100644
--- a/boards/arm/decawave_dwm1001_dev/decawave_dwm1001_dev-pinctrl.dtsi
+++ b/boards/arm/decawave_dwm1001_dev/decawave_dwm1001_dev-pinctrl.dtsi
@@ -23,6 +23,7 @@
                group1 {
                        psels = <NRF_PSEL(TWIM_SDA, 0, 29)>,
                                <NRF_PSEL(TWIM_SCL, 0, 28)>;
+                       bias-pull-up;
                };
        };

*** Booting Zephyr OS build v3.3.0-rc2-51-g4e2bd62b6a95 ***
Polling at 0.5 Hz
#1 @ 416 ms: x -0.229824 , y 0.153216 , z 9.461088
#2 @ 2421 ms: x -0.268128 , y 0.153216 , z 9.499392
#3 @ 4426 ms: x -0.268128 , y 0.076608 , z 9.576000
#4 @ 6431 ms: x -0.229824 , y 0.076608 , z 9.614304
#5 @ 8437 ms: x -0.229824 , y 0.076608 , z 9.576000
#6 @ 10442 ms: x -0.344736 , y 0.114912 , z 9.959040

If the board doesn't reset then it's probably because nRESET is not correctly wired. Can work around the issue by adding board_runner_args(nrfjprog "--softreset") to the board.cmake file

If the board doesn't reset then it's probably because nRESET is not correctly wired. Can work around the issue by adding board_runner_args(nrfjprog "--softreset") to the board.cmake file

It uses jlink runner, but thanks for the hint, I just opened PR now to get this issue out of the way.

If the board doesn't reset then it's probably because nRESET is not correctly wired. Can work around the issue by adding board_runner_args(nrfjprog "--softreset") to the board.cmake file

Is there something equivalent for openocd ?


fix(@angular-devkit/build-angular): only add module script types to actual module scripts

ng serve was errantly adding a module type to custom script bundles.  These scripts may contain ES5 and non-strict compatible code and can therefore not be marked as module scripts.  ng build already correctly operates in this fashion.
Fixes #14952

Third-party dependencies part of the main bundle might not be strict mode compatible either. My concern with such fix is that we introduce different behavior for the scripts based on how the application depends on them.

It’s actually already different.  Build operates this way and serve did as well up until 8.1. Serve behavior was changed due to a fix for the main bundles that unintentionally changed this as well.
This also allows people to use those third party libraries that would otherwise be unable to be included in the main application bundles, if needed.  Without it, there would be no clean way to do so.

Sounds good


#118

#118, Add geoid_name and geopotential_datum_name to the list of
Attributes.

That's fine, thanks. As with all tickets, it needs a comment in the revision history too. I suppose it would make sense to put those updates in the same pull request, wouldn't it? Jonathan


Add SSL and auth support for Elasticsearch checks

Great library! Any plans to make so that the elasticsearch checks can go over SSL for folks who are using the Shield plugin?

+1 to that!

I will definitely do this, it's not hard to so as I do this for a lot of other technologies, but right now I'm just stretched on time so it'll be a little while.

Been so busy but thanks to @ted3 pull request #24 addresses this so closing.