refactor(module)!: implement design system with CSS variables

🔗 Linked issue

Resolves #601
Resolves #870
Resolves #1693
Resolves #1721
Resolves #1833
Resolves #1883
Resolves #2026
Resolves #2027
Resolves #2039
Resolves nuxt/ui#2320
❓ Type of change

[ ] 📖 Documentation (updates to the documentation or readme)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality)
[x] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[x] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

With this PR, Nuxt UI v3 embraces a full design system for its components. You will now be able to use primary, secondary, success, info, warning, error and neutral (renamed from gray) in the color prop of components. For example instead of <UButton color="red" /> you will use <UButton color="error" />.

We decided to make this change because it was a mix-up between an half design system with primary and error+ Tailwind CSS colors + a gray alias.

export default defineAppConfig({
  ui: {
    colors: {
      primary: 'sky',
      secondary: 'indigo',
      success: 'green',
      info: 'blue',
      warning: 'yellow',
      error: 'red',
      neutral: 'slate'
    }
  }
})

Note that we no longer define those aliases as Tailwind CSS colors so you can no longer do text-primary-500 dark:text-primary-400. This was changed to prevent overriding your Tailwind CSS colors.
Each alias will generate CSS variables such as --ui-color-${color}-${shade}:
:root {
  --ui-color-primary-50: var(--color-sky-50);
  --ui-color-primary-100: var(--color-sky-100);
  --ui-color-primary-200: var(--color-sky-200);
  --ui-color-primary-300: var(--color-sky-300);
  --ui-color-primary-400: var(--color-sky-400);
  --ui-color-primary-500: var(--color-sky-500);
  --ui-color-primary-600: var(--color-sky-600);
  --ui-color-primary-700: var(--color-sky-700);
  --ui-color-primary-800: var(--color-sky-800);
  --ui-color-primary-900: var(--color-sky-900);
  --ui-color-primary-950: var(--color-sky-950);
  /* ... */
}

I noticed that the Nuxt UI theme mostly use 500 for light mode and 400 for dark mode for colors, so now Nuxt UI generates shortcuts that changes for light and dark mode: --ui-${color}.
:root {
  --ui-primary: var(--ui-color-primary-500);
  --ui-secondary: var(--ui-color-secondary-500);
  --ui-success: var(--ui-color-success-500);
  --ui-info: var(--ui-color-info-500);
  --ui-warning: var(--ui-color-warning-500);
  --ui-error: var(--ui-color-error-500);
}
.dark {
  --ui-primary: var(--ui-color-primary-400);
  --ui-secondary: var(--ui-color-secondary-400);
  --ui-success: var(--ui-color-success-400);
  --ui-info: var(--ui-color-info-400);
  --ui-warning: var(--ui-color-warning-400);
  --ui-error: var(--ui-color-error-400);
}

Those CSS variables are now used all across the theme, for example the Link theme:
export default {
  base: 'focus-visible:outline-[--ui-primary]',
  variants: {
    active: {
      true: 'text-[--ui-primary]'
    }
  }
}

This allows you to change which shade is used for each color on light and dark mode:
<style>
@import "tailwindcss";
@import "@nuxt/ui";

:root {
  --ui-primary: var(--ui-color-primary-700);
}

.dark {
  --ui-primary: var(--ui-color-primary-200);
}
</style>

Now we've handled colors, let's talk about the former gray alias which is now called neutral. For a long time, I wanted to implement CSS variables to easily customize the theme without having to override every component in your app.config.ts.
We used to have --ui-background and --ui-foreground variables in Nuxt UI Pro only but those were only used to change the styles applied on <body>.
This PR introduces new CSS variables in Nuxt UI:
body {
  @apply antialiased font-sans text-[--ui-text] bg-[--ui-bg];
}

:root {
  --ui-text-dimmed: var(--ui-color-neutral-400);
  --ui-text-muted: var(--ui-color-neutral-500);
  --ui-text-toned: var(--ui-color-neutral-600);
  --ui-text: var(--ui-color-neutral-700);
  --ui-text-highlighted: var(--ui-color-neutral-900);

  --ui-bg: var(--color-white);
  --ui-bg-elevated: var(--ui-color-neutral-100);
  --ui-bg-accented: var(--ui-color-neutral-200);
  --ui-bg-inverted: var(--ui-color-neutral-900);

  --ui-border: var(--ui-color-neutral-200);
  --ui-border-accented: var(--ui-color-neutral-300);
  --ui-border-inverted: var(--ui-color-neutral-900);
}

.dark {
  --ui-text-dimmed: var(--ui-color-neutral-500);
  --ui-text-muted: var(--ui-color-neutral-400);
  --ui-text-toned: var(--ui-color-neutral-300);
  --ui-text: var(--ui-color-neutral-200);
  --ui-text-highlighted: var(--color-white);

  --ui-bg: var(--ui-color-neutral-900);
  --ui-bg-elevated: var(--ui-color-neutral-800);
  --ui-bg-accented: var(--ui-color-neutral-700);
  --ui-bg-inverted: var(--color-white);

  --ui-border: var(--ui-color-neutral-800);
  --ui-border-accented: var(--ui-color-neutral-700);
  --ui-border-inverted: var(--color-white);
}

The theme of all components has been rewritten to use those variables, here is the Card theme for example:
export default {
  slots: {
    root: 'bg-[--ui-bg] ring ring-[--ui-border] divide-y divide-[--ui-border] rounded-lg shadow',
    header: 'p-4 sm:px-6',
    body: 'p-4 sm:p-6',
    footer: 'p-4 sm:px-6'
  }
}

Now you can easily change the background of all your components by overriding those variables in your app.vue for example:
<style>
@import "tailwindcss";
@import "@nuxt/ui";

:root {
  --ui-bg: var(--color-gray-100);
  --ui-border: var(--color-gray-300);
}

.dark {
  --ui-bg: var(--color-gray-950);
  --ui-border: var(--color-gray-900);
}
</style>

📝 Checklist

[x] I have linked an issue or discussion.
[x] I have updated the documentation accordingly.

This is really an amazing feat! Dealing with colors currently is confusing and this is the cherry on the cake for v3.
Thanks a lot for your work🙏

I'm cooking something on top of this PR to handle app config colors through CSS variables as well 😊  This will allow to choose shades for light and dark mode!

Just updated the PR with a full design system and a major refactor of colors on top of the gray, let me know what you think!

Can you elaborate on this? Writing bg-[--ui-bg-elevated] for example whenever needed is a bit verbose

Note that we no longer define those aliases as Tailwind CSS colors so you can no longer do text-primary-500 dark:text-primary-400. This was changed to prevent overriding your Tailwind CSS colors.

[...] Writing bg-[--ui-bg-elevated] for example whenever needed is a bit verbose

I would refer a three-key verbose, yet. Especially when you need to consider that you are calling a ui util, that is a background and it is of variant elevated. I would dare to say that it becomes more CSS-esque and easy to remember, even more once this rolls out. Not to mention that there will be your IDE helping with them.
The more I look at this PR the more I want to use it in an actual project....

I want to add that you don't have to use the shortcuts variables, you can use text-[--ui-color-neutral-500] dark:text-[--ui-color-neutral-400] for example (text-gray-500 dark:text-gray-400).
Do you think I should keep the custom Nuxt UI colors as Tailwind CSS colors?

Having to open brackets and write a CSS var would become tedious as you typically write a bunch of utility classes per element. I'm not sure if the Tailwind Intellisense provides autocompletion for CSS vars but if it does it certainly would make it easier.
With that said I think the current behavior is better. Maybe an opt-in option to add utilities for those variables would be best? Enabling the option would generate bg-elevated and bg-accented, etc for --ui-bg-elevated and --ui-bg-accented respectively and so on.

@MuhammadM1998 I can't have a trigger for this, have you looked at the src/theme/ changes? 😬 https://github.com/nuxt/ui/pull/2298/files#diff-5f29f6135235be345dc147df2e517cb5ab2248e70820ce985ea03c45cc05ba25

We could maybe add an option to define our design system colors as Tailwind CSS colors but there would still be a conflict with the neutral (like it was for gray being renamed to cool before).

Do you really think it would be tedious to write bg-[--ui-primary] instead of bg-primary-500 dark:bg-primary-400? With this system, you'll never have to write a dark: class ever again.

Personally, I would much prefer to write bg-[--ui-primary] compared to letting Nuxt UI hardcode some variables for me (especially without the need to write dark: each time and possibly altering all darks at once for an entire project).
After all I usually create my own /assets/css/main.css, and having that customization ability in one file, once per project, is insanely valuable for me.
While I do now understand @MuhammadM1998 perspective, I would much prefer being in control. Also considering a number of requests in the ability to define your own utility class colors without hardcoded variables. For those who really want to we could add a doc section explaining how it should be done via Tailwind utilities. This not only improves free of customization, but also establish a proper use of the tools IMO

@benjamincanac That's my opinion yeah maybe do a poll on twitter? 😂
I agree with @sandros94 though, adding a section in the documentation for those who won't like to use the brackets notation would be sufficient as you'll do that once per project anyway.

It is planned, I'll rewrite the entire Colors page in this PR!
You can easily define the Nuxt UI colors (design system) as Tailwind CSS colors using the @theme directive:
@import "tailwindcss";
@import "@nuxt/ui";

@theme {
  --color-primary-50: var(--ui-color-primary-50);
  --color-primary-100: var(--ui-color-primary-100);
  --color-primary-200: var(--ui-color-primary-200);
  --color-primary-300: var(--ui-color-primary-300);
  --color-primary-400: var(--ui-color-primary-400);
  --color-primary-500: var(--ui-color-primary-500);
  --color-primary-600: var(--ui-color-primary-600);
  --color-primary-700: var(--ui-color-primary-700);
  --color-primary-800: var(--ui-color-primary-800);
  --color-primary-900: var(--ui-color-primary-900);
  --color-primary-950: var(--ui-color-primary-950);
}

This would allow you to use text-primary-500 dark:text-primary-400 and can be done for all the aliases.

You can check the updated documentation here: https://feat-css-variables.ui-6q2.pages.dev/getting-started/theme#design-system. Any feedback is appreciated 😊

You can check the updated documentation here: https://feat-css-variables.ui-6q2.pages.dev/getting-started/theme#design-system. Any feedback is appreciated 😊

Looks amazing and well detailed. I'm really enjoying this "back to css-fist" configs!

What do you think of the default colors? Right now the primary defaults to green and secondary to blue like success and info 😬

What do you think of the default colors? Right now the primary defaults to green and secondary to blue like success and info 😬

I've been using those exact colors for basically every project and test I've done so far.
The only difference is that I tend to use sky for info (secondary still defaults to blue) and add a transparent color (more useful than what you could think of).

What do you think of the default colors? Right now the primary defaults to green and secondary to blue like success and info 😬

Its going to look like Vuetify? Although it helps to create the distinction between Success and Primary. I don't mind.

Its going to look like Vuetify?

Could you elaborate on this? 🤔

Its going to look like Vuetify?

Could you elaborate on this? 🤔

So Vuetify and Element plus use the blue colors by default. While Shadcn uses Grays by default as primary colors. Nuxt UI is currently green by default, which I like, in line with the Nuxt website and Vue color scheme.
export default defineAppConfig({
  ui: {
    colors: {
      primary: 'sky',
      secondary: 'indigo',
      success: 'green',
      info: 'blue',
      warning: 'yellow',
      error: 'red',
      neutral: 'slate'
    }
  }
})

According to this snippet. The new primary color would be sky? Its not ugly but its not unique anymore. I would prefer "green" or "emerald" combine with "gray" as neutral for deafults.

It's an error in the PR description, you have the default colors in the documentation: https://ui3.nuxt.dev/getting-started/theme#colors

I just tried the new design system approach and it's amazing!
Had a small problem though with styling the button foreground, currently it defaults to --ui--bg. It works okay in light mode where the background is white, but in dark mode where the background is black it looks a bit off. Is there a way to update the button (and other similar components) text color globally without updating the app config for each component?
Also I added my colors to @theme to be able to use them directly as utility classes without arbitrary values and they automatically change in light & dark mode so I don't have to use text-xxx1 dark:text-xxx2. Here's how my main.css looks like
@import 'tailwindcss';
@import '@nuxt/ui';

/* My app's design system*/
:root {
  --app-font-family: 'Readex Pro', sans-serif;
  --app-font-size: 14px;
  --app-background: #ffffff;
  --app-foreground: #09090b;
  --app-primary: #1d5252;
  --app-secondary: #f4f4f5;
  --app-border: var(--app-secondary);

 /* Dark Mode Overrides */
  &.dark {
    --app-background: #09090b;
    --app-foreground: #f5f5f5;
    --app-primary: #32ada8;
    --app-secondary: #1e1e1e;
  }
}

/* Overriding Nuxt UI default to use our design system */
:root {
    --font-family-sans: var(--app-font-family);

  /* Colors */
  --ui-bg: var(--app-background);
  --ui-text: var(--app-foreground);
  --ui-primary: var(--app-primary);
  --ui-secondary: var(--app-secondary);
  --ui-border: var(--app-border);
}

/* Declaring our variables as `theme` to add them as utility classes (e.g `text-primary`, `bg-muted`, etc..) */
@theme {
  --color-background: var(--app-background);
  --color-foreground: var(--app-foreground);
  --color-primary: var(--app-primary);
  --color-secondary: var(--app-secondary);
  --color-border: var(--app-border);
}

With the above CSS file, the following works in both light and dark modes
<template>
  /** Automatically uses #1d5252 in light mode and 32ada8 in dark mode */
  <p class="text-primary"> Hello </p>
</template>

The button foreground text defaults to text-[--ui-bg] only for the solid variants. To override such specific variant, you have no choice than to use the app.config.ts and the compoundVariants key as it's not a global setting.
It is how we designed the button:

I've concluded the same after some reviewing. Thanks a lot for this PR really great work 🙏

hey guys,
I'm currently deciding which UI library to use for my next major project. I quite like Nuxt UI v2, but it has some weaknesses that are now much improved in v3. Veery nice. Design tokens are really important for me :)
I just don't quite understand how components are (globally) customised now.
In v2 i could just add all the props stylings in the app.config:
export default defineAppConfig({   ui: {     primary: 'blue',     gray: 'slate', 		strategy: 'override', 		button: { 			default : { 				color: 'blue', 				size: 'xl', 			}, 			padding: { 				xl: 'px-8 py-4', 				md: 'px-4 py-2', 			}, 			size: {         xl: 'text-lg rounded-full',  				md: 'text-md rounded-lg',  				xs: 'text-xs rounded-lg',        }, 			variant : { 				outline: 'border border-slate-100  dark:border-slate-600', 			}, 			color: { 				blue: { 					solid: 'bg-blue-900 dark:bg-blue-800 text-white' 				}, 			}     }   } })
But that doesn't seem to work in v3 now. Is there an synthax error in my code, or did you change the whole logic?
Sorry if this doesn't belong here. I'm just a bit pressed for time to make a decision :D Thanks!
 export default defineAppConfig({   ui: {     colours: {       primary: ‘blue’,       neutral: ‘slate’     },     strategy: ‘override’,     button: {       default: {         size: ‘lg’       },     }   }, })

hey guys,
I'm currently deciding which UI library to use for my next major project. I quite like Nuxt UI v2, but it has some weaknesses that are now much improved in v3. Veery nice. Design tokens are really important for me :)
I just don't quite understand how components are (globally) customised now.
In v2 i could just add all the props stylings in the app.config:
export default defineAppConfig({
  ui: {
    primary: "blue",
    gray: "slate",
    strategy: "override",
    button: {
      default: {
        color: "blue",
        size: "xl",
      },
      padding: {
        xl: "px-8 py-4",
        md: "px-4 py-2",
      },
      size: {
        xl: "text-lg rounded-full",
        md: "text-md rounded-lg",
        xs: "text-xs rounded-lg",
      },
      variant: {
        outline: "border border-slate-100  dark:border-slate-600",
      },
      color: {
        blue: {
          solid: "bg-blue-900 dark:bg-blue-800 text-white",
        },
      },
    },
  },
});

But that doesn't seem to work in v3 now. Is there an synthax error in my code, or did you change the whole logic?
Sorry if this doesn't belong here. I'm just a bit pressed for time to make a decision :D Thanks!
export default defineAppConfig({
  ui: {
    colors: {
      primary: "blue",
      neutral: "slate",
    },
    strategy: "override",
    button: {
      default: {
        size: "lg",
      },
    },
  },
});

@philippwienes No this behaves the same as in v2, the strategy option is gone though. Not sure it's related but one mistake I see people make is not putting their app.config.ts inside app/ when using the future.compatibilityVersion: 4 option.

Ah nice - thanks for the link. Classic RTFM.


Add a noise model analysis pass for LWE/CGGI

The tfhe-rs project tracks noise standard deviation along with the ciphertext. They seem to have a "nominal" noise level (equal to 1), bootstrapping resets the noise to the nominal level, and adding adds the noise, multiplying multiplies the noise, and scaling by a constant scales the noise. There is not a clear indication in tfhe-rs about how to determine what is the max allowable noise, but IceTDrinker pointed me to section 5 of https://eprint.iacr.org/2022/704.pdf which contains the detailed approach they use in tfhe-rs.
I'd like to port the noise analysis from https://jeremykun.com/2023/11/15/mlir-a-global-optimization-and-dataflow-analysis/ to HEIR, and try bootstrap injection while also retaining some of the low-degree addition operations, so that the circuit can be made smaller. The same analysis should be useful for noise tracking in arithmetic schemes.

I think the above formula (without the FFT modification) is the right baseline for the noise reset after a bootstrap

Also: they pointed me to the implementation of the concrete parameter selection optimizer https://github.com/zama-ai/concrete/tree/main/compilers/concrete-optimizer


Hacakthon list/get, HackathonNotice list/get works

Hackathon list/get and HackathonNotice list/get works, with some hard code and some simplification that needs to be rewritten in the near future.
TODO list:

get_hackathon_list
get_hackathon_notice_list
__get_hackathon_detail
get_registration_detail

Before use, please run sudo python open-hackathon-server/src/setup_db.py in which 2 hackathon has been directly added to mongodb.

Update pagination and remove some unused code.
functions that still TO MODIFY in the future:
get_hackathon_list
__get_hackathon_detail
get_registration_detail


RATIS-975. Fix failed UT: testRaftLogMetrics

What changes were proposed in this pull request?

MetricsStateMachine is instance of DataApi, so data() return this, and data().flush (i.e. this.flush) call the method self, the dead recursion happens.

  default DataApi data() {
    return this instanceof DataApi? (DataApi)this : DataApi.DEFAULT;
  }

assertCommitCount always fail. @anshkhannasbu Could you explain why stmCount + configCount + metaCount == expectedMsgs i.e. 2 ?  Sorry, I can not get the point.

What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/RATIS-975
How was this patch tested?
Existed tests.

Thanks @runzhiwang for the contribution. I have committed this.

assertCommitCount always fail. @anshkhannasbu Could you explain why stmCount + configCount + metaCount == expectedMsgs i.e. 2 ?  Sorry, I can not get the point.

@runzhiwang , u r right. The number client msgs should be equal to the stateMachine entries.
StateMachine + config + metadata should be equal to the total count of raft log entries.

@bshashikant Okay, I see, thanks for explanation.

@runzhiwang @bshashikant thanks for pointing this out. I assumed that in this case, the number of entries sent by client would be the total number of entries committed in the Log.


Bb2 1133 use node sdk

JIRA Ticket:
SOMEPROJECT-42
User Story or Bug Summary:

What Does This PR Do?

What Should Reviewers Watch For?

If you're reviewing this PR, please check these things, in particular:

TODO

What Security Implications Does This PR Have?
Submitters should complete the following questionnaire:

If the answer to any of the questions below is Yes, then here's a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence: N/A.

Does this PR add any new software dependencies? Yes or No.
Does this PR modify or invalidate any of our security controls? Yes or No.
Does this PR store or transmit data that was not stored or transmitted before? Yes or No.

If the answer to any of the questions below is Yes, then please add a Security Engineer and ISSO as a reviewer, and note that this PR should not be merged unless/until he also approves it.

Do you think this PR requires additional review of its security implications for other reasons? Yes or No.

What Needs to Be Merged and Deployed Before this PR?

This PR cannot be either merged or deployed until the following pre-requisite changes have been fully deployed:

CMSgov/some_repo#42

I have gone through and verified that...:

[ ] This PR is reasonably limited in scope, to help ensure that:

It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
There isn't too much of a burden on reviewers.
Any problems it causes have a small "blast radius".
It'll be easier to rollback if that becomes necessary.

[ ] I have named this PR and its branch such that they'll be automatically be linked to the (most) relevant Jira issue, per: https://confluence.atlassian.com/adminjiracloud/integrating-with-development-tools-776636216.html.
[ ] This PR includes any required documentation changes, including README updates and changelog / release notes entries.
[ ] All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
[ ] All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
[ ] Reviews are requested from both:

At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
Any relevant engineers on other projects (e.g. BFD, SLS, etc.).

[ ] Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.

Please review the standards every few months to ensure you're familiar with them.

clean up after demo


Card face history view doesn't show variation

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version):
.49.0
Python release (python3 --version):
3.5.2
Component/platform:
frontend/card face/history
Description of problem:

As you can see this binary motion sensor reports that it ha not been triggered but it most defnitely has (it controls the lights in the bedroom)
The state of the sensor changes to a moving person, but the history on the card face doesn't indicate that. This was working in .48.x
Expected:
The history is current

No history data but this has been collecting history data since December 2016

I have confirmed that my database still has state entries for days that do not seem to show up in the front end. I wonder if this should be directed to the front end repo?


[GOBBLIN-825] Initialize message schema at object construction rather than creating a new instance for every message

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[ ] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-825

Description

[ ] Here are some details about my PR, including screenshots (if applicable):
An issue with a schema registry client caused this issue. This issue fixes the creation of new instances of the same schema for every message sent. Instead we now create an instance of the schema during object construction and use the same schema instance for all the messages.

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:
overrideSchemaNameAndNamespaceTest in AvroUtilsTest.java
KeyValueEventObjectReporterTest.java
KeyValueMetricObjectReporterTest.java

Commits

[ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

@zxcware


Chore: Add Shuttle.toml description

Good morning,
I added a new section to the docs called "Configuration" and within that a new article called "Shuttle Service Name".  This article covers the purpose of Shuttle.toml.  Please let me know what you think.  Will make any edits/changes if needed.
:)
Thanks,
~Jeff Mitchell

Ok, have updated as suggested above.  I also took the liberty of fixing a typo I saw in the FAQ entry regarding Shuttle.toml. I also made a minor edit to point to the revised article in the new Configuration section.  Looks like I might have created merge conflict by doing that though...oops. :(

Thanks, the changes look good! A merge conflict can be daunting, but it's usually not as scary as it looks. It just means that someone else made changes to main after you created your branch, and their changes conflict with yours. So to merge your branch into main, you need to decide whether to keep your or their change (or a combination). Here is an article on git merge conflicts: https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts
For this particular conflict, what you would need to do is merge main into your branch, then choose which change to keep for that conflict, which in this case would be your change. Then push the changes to your branch like normal. It takes a while to get used to git, but take your time and you'll get there. And if you need help with this, feel free to reach out to me on discord!

Alright!  I think I did it.  Seems like it's all clean now.  I abandoned my proposed changes to the FAQ, can redo it later if needed.


Plugin seems to disable formatting inside link text

Hello, thank you for a very nice plugin...
I just wanted to report an odd display problem I had, that via bisecting, I tracked down to this plugin.
I am using this markdown for the demo:
[samwarnick/**obsidian-simple-embeds**](https://github.com/samwarnick/obsidian-simple-embeds)

Expected behaviour
With these settings...

no plugins
with default theme
no snippets
legacy editor (no live preview)

... the previewed display in Obsidian 0.13.15 is as expected:

Actual behaviour
With these settings, however...

only Simple Embeds 1.6.1 installed
with default theme
no snippets
legacy editor (no live preview)

... the previewed display in Obsidian 0.13.15 is missing the bold text:

In other words, the formatting seems to have been lost.
The behaviour is the same if I turn Live Preview on (I turned it off for the purposes of bug-reporting)

Thanks for letting me know and the excellent write-up. I think I know what's going on here, so hopefully won't be too difficult to fix. I'll get to this soon.

Super - thanks very much indeed!

Confirmed that this is fixed via 1.6.2, after Obsidian is restarted.
Very many thanks for fixing it!


Question of async process in Robot Test Case

Hi, i want to run a socket linstener in a test case,
the test case as following:
Submit Test Event
    ${task}  Run Keyword Async  Socket Listen
    Sleep  1s
    # trigger event
    Redfish.Post  /redfish/v1/EventService/Actions/EventService.SubmitTestEvent
    ...  body={'OriginOfCondition':'/redfish/v1/Systems/1/LogServices/StandardLog'}
    ...  valid_status_codes=[${HTTP_NO_CONTENT}]
    Sleep  1s
    ${resp}  Get Async Return  ${task}
    log  ${resp}
    ${line} =  Get Lines Containing String  ${resp}
    ...  Event Counter for Host ${OPENBMC_HOST} =
    should not be empty  ${line}
    [Teardown]  run keywords  Stop All Async
    ...  AND  Test Teardown Execution

The keyword Run Keyword Async will new a process to create socket server and listen from another keyword Socket Listen.
But sometimes output.xml parsing got error, the cause exists two XML tag names - Submit Test Event.
So does robot write xml thread safe or not?
If not how to avoid this error?
Thanks.

From my experience running asynchronously will most often than not break the output.xml, so I would recommend against it. Better idea is to run the asynchronous code in python and jsut call it from Robot.

@databobek
Yes, i do this in python file.
Run Keyword Async and Socket Listen define in python,
Run Keyword Async will create a thread pool to execute Socket Listen of socket server .bind() and .accept().
But still write duplicated tag name in report.xml probability.
...
...
...
<kw name="Run Keyword Async" library="runKeywordAsync">
<arguments>
<arg>Socket Listen</arg>
</arguments>
<assign>
<var>${task}</var>
</assign>
<msg timestamp="20220207 18:04:52.808" level="INFO"></doc>
<arguments>
...
...
...
<kw name="Run Keyword Async" library="runKeywordAsync">
<arguments>
<arg>Socket Listen</arg>
</arguments>
<assign>
<var>${task}</var>
</assign>
<kw name="Socket Listen" library="EventListener">${task} = 1</msg>
<status status="PASS" starttime="20220207 18:04:52.788" endtime="20220207 18:04:52.808"></status>
</kw>
...
...
...

Sorry I think I wasn't clear. You should have the entire async logic in python, and call the whole Python thing from Robot
def my_async_stuff():
....
assert result
My Asynchronous Test Case
My Async Stuff
Basically you have to omit a situation in which your test might cause Robot to write stuff to output asynchronously. It's not even Robot's fault tbh, it's just how those data files work (XML/json)

Writing output.xml isn't thread safe. If you need to leave keywords running on background, you must make sure they don't use things like BuiltIn.run_keyword when other keywords are executing. Basically such keywords should work silently until there's another keyword querying results. It seems you have Get Async Return for querying results so the overall setup looks fine.
With this example only it's impossible to tell where the problem is. This issue tracker probably isn't the best place for this kind of discussion either. It's reserved mainly for bug reports and concrete enhancement requests and, for example, our Slack is better for general discussion.

Well, i refer to @databobek.
All test step write in .py file and remove BuiltIn.run_keyword().
But still keep logger.info()
Run 50 rounds and get the error:
robot.errors.DataError: Reading XML source 'output.xml' failed: Incompatible XML element 'doc'.
When replace logger.info() to logger.debug(), it'll be pass for 200 rounds.
P.S. from robot.api import logger


example config files

Hi! @hoechenberger this is amazing work! Congrats!!
Do you think it could be useful to have the config files for your example data?
I know they are in the web, but maybe it could be useful to have them already here?
Something like mne-study-template/example-config-files

config_ds000246.py
config_ds000248.py
etc
If you want I can help with this.

Talk soon,

it's all here
https://github.com/mne-tools/mne-study-template/tree/master/tests/configs

Oh! Cool! I haven't seen it!! Super thanks!!


How to set up wayvnc headless ? in nixos

Hello.
I am a nixos module user. (not in home-manager)
How to set up wayvnc headless ?
in my case,
After connection, gray or black screen...but able to Mouse control only.
The remote monitor comes out.
In sway, wayvnc headless is being used.
in config-code
programs.sway.extraPackages = with pkgs;[
sway
swaylock
swaylock-effects
sway-unwrapped
];
You must enter these four packages to make wayvnc headless work at sway.
Is the hyprland nix project still unpatched like sway? (sway-unwrapped... is it patched right?)
...and one thing I'm curious about is that in wayland
Like x11vnc, I wonder if it is impossible to synchronize the screens of both the remote and original local computers at the same time. (I want to see the screen on the local computer in the room while controlling it on the remote computer concurrently. This is very inconvenient.)
Thanks.

@fufexan for nix

programs.sway.extraPackages = with pkgs;[ sway swaylock swaylock-effects sway-unwrapped ];
You must enter these four packages to make wayvnc headless work at sway.

No? sway only should be needed. sway-unwrapped isn't used anyway if you include it there. The other two have nothing to do with wayvnc.

Is the hyprland nix project still unpatched like sway? (sway-unwrapped... is it patched right?)

Patched in what way? Hyprland is patched to work with HiDPI and optionally Nvidia. sway-unwrapped does not have any patches relevant to wayvnc (see here).

Like x11vnc, I wonder if it is impossible to synchronize the screens of both the remote and original local computers at the same time. (I want to see the screen on the local computer in the room while controlling it on the remote computer concurrently. This is very inconvenient.)

That's just display mirroring. It's explained in the wiki.
Apart from the above, I don't see anything NixOS specific about wayvnc. You can run it just like you would on any other distro.

sway
swaylock
swaylock-effects
sway-unwrapped
It's strange, I put only the above in programs.sway.extraPackages (At first, I put everything related to wayland, such as wayland to wayvnc, and ran it,  i'm tested filtering only four of them must be put in extraPackages to avoid errors such as collision and vnc works.)
So, hyprland is also wrapped like sway (I mistakenly thought that there was a case where the nix code was patched. Because, anyway, hyprland flake also has a similar module configuration internally.)

Since the question was answered - prolly close?

https://discourse.nixos.org/t/hyprland-screen-sharing/43658/7
It seems that it still doesn't work on NixOS. I hope Hyprland supports screen sharing soon.

Hyprland has supported screen sharing for a long while now.

@fufexan "You're right; after trying again with the AMD GPU and Hyprland as you mentioned in your comment, I successfully set up Hyprland WayVNC. The issue now is that on my NVIDIA computer, it only shows a gray screen when connecting. I'm currently looking for a solution to this."


parent.children().last() cannot be used as a layout reference for the first child

The last widget is undefined if the parent has no children, which now cannot be set as a layoutData reference. The following error gets thrown: Ignored unsupported value for property "layoutData": Invalid value for '...': first element must be a percentage or a widget reference.
Using "prev()" as a reference instead works as expected.
Example:
var page = tabris.create("Page", {topLevel: true}).open();
console.log(page.children().last());
tabris.create("Composite", {layoutData: {left: 0, top: [page.children().last(), 0]}}).appendTo(page);

The documentation never states that null or undefined is accepted as the first array parameter. It's also not a good idea to allow that since an edge can also be a widget, percentage or offset without array, in which case "null" or "undefined" mean "unset"/"reset".
This is a small braking change on the behavior of layoutData outside of the properties contract.


PyArrow Flight DoAction does not return results as available

Describe the bug, including details regarding any error messages, version, and platform.
In short, when using PyArrow Flight server and client, messages are received by the program using the client after the do_action function has returned, rather than as available.
This seems like a bug because the RPC defines the return type of DoAction as stream Result.
I have not tried reproducing this using C++.
I'm using PyArrow 10.0.1, Python 3.10.8, MacOS Monterey 12.2.1.
This example program:
import time
from datetime import datetime

from pyarrow.flight import Action
from pyarrow.flight import FlightClient
from pyarrow.flight import FlightServerBase

class ActionServer(FlightServerBase):
    def do_action(self, context, action):
        for i in range(5):
            now = datetime.utcnow().isoformat()
            print('Server time', now)
            yield now.encode()
            time.sleep(1)
        else:
            print('Exited at', datetime.utcnow().isoformat())

def test_results_immediately_available():
    with ActionServer() as server, FlightClient(('localhost', server.port)) as client:
        action = Action(b'', b'foo')
        for result in client.do_action(action):
            print('Message', result.body.to_pybytes().decode('utf-8'), 'received at', datetime.utcnow().isoformat())

if __name__ == '__main__':
    test_results_immediately_available()

outputs the following:
Server time 2022-12-22T18:06:23.424057
Server time 2022-12-22T18:06:24.429895
Server time 2022-12-22T18:06:25.434969
Server time 2022-12-22T18:06:26.437020
Server time 2022-12-22T18:06:27.442276
Exited at 2022-12-22T18:06:28.443606
Message 2022-12-22T18:06:23.424057 received at 2022-12-22T18:06:28.444388
Message 2022-12-22T18:06:24.429895 received at 2022-12-22T18:06:28.444424
Message 2022-12-22T18:06:25.434969 received at 2022-12-22T18:06:28.444437
Message 2022-12-22T18:06:26.437020 received at 2022-12-22T18:06:28.444449
Message 2022-12-22T18:06:27.442276 received at 2022-12-22T18:06:28.444460

Ideally each message would be received by the client before the next one is sent.
Component(s)
FlightRPC, Python

cc @lidavidm

This is already reported on Jira and is just a Python-side implementation thing, it needs to wrap the C++ iterator into a proper Python iterator

https://issues.apache.org/jira/browse/ARROW-12767

@lidavidm how difficult do you think this would be? Considering doing it over the holiday.

I think it just needs some Cython code.

@lidavidm DoAction actually does materialize the results in the Grpc transport: https://github.com/apache/arrow/blob/master/cpp/src/arrow/flight/transport/grpc/grpc_client.cc#L742-L752, so making it streaming would involve changing its interface to be more similar to DoGet/Put/Exchange.

For now, I'll probably just not implement the service with these actions in Flight. I'm using Flight for lots of adjacent services, but this one doesn't do a lot of data transfer, just Protobuf messages.

Ah, whoops. I'll see if I can get to it when I have some spare time, but yeah, Flight isn't all that useful if you just have a normal RPC service. I would love to have Flight interoperate with grpcio in Python but I don't believe it's possible due to how grpcio/grpc++ is designed


Notifications on CLI releases

Is there any abilities to get notification or some kind of mailing about new releases of yc tool?

@zamulla Any feedback?

You'll get a notification right in the YC CLI after command result, if CLI detects that the newer version is available.
There is a new yc version '0.102.0' available. Current version: '0.101.0'.
See release notes at https://cloud.yandex.ru/docs/cli/release-notes
You can install it by running the following command in your shell:
	$ yc components update

@nikolaymatrosov Sure. How to subscribe to new releases?

As the CLI is developed in the private repo, there is no native way to subscribe to new releases. But you can check https://storage.yandexcloud.net/yandexcloud-yc/release/stable periodically to find out if a new version is available as the CLI do.

@nikolaymatrosov Yes, this is exactly what I regularly do. I noticed that the changelog of yc is updated in accordance with each release. So, is there any way to create a release or a tag specific to release of yc in public repo? Is it possible to revive the old machinery which used ticket keys as tags two years ago.
BTW It would be great to add a flag to disable new release warning in CLI (like --no-python-version-warning  in pip) for better experience.

Hi @daskol, and thank you for the suggestion!
In the docs, there are CLI release notes. This English version can sometimes fall slightly behind the Russian one.
Other channels of notification are out of scope of the docs and this repo. You can add you suggestion to our features space (Russian). The Yandex Cloud teams keep an eye on that page and implement popular proposed features.


Check the hash for the challenge of the Fiat-Shamir heuristic

Attempts to fix #20
Changes:

SpkGen returns the computed challenge for Fiat-Shamir.
SpkVerify checks that the challenge is correct.

Discussed on WG call Jan 10th, waiting on a review from @mikelodder7 as the underlying issue was raised by him.

@BasileiosKal apologies but we have renamed the spec file name so we leverage existing tooling around managing ID drafts, can you please rebase your PR accordingly?

Discussed on WG call 7th Feb, awaiting review from @mikelodder7 for progress

It would likely be more efficient to check the challenge hash before doing the pairing operations, in case that fails.

Sure it could be. I don’t have a preference

updated

@mikelodder7 can you review these latest changes please

PR open for multiple weeks, discussed on WG call multiple times, multiple approvals, merging.


Improve write logic

Right now a backend setup is generated, and if any 1 zdb fails, the entire write fails. It should at least be possible to do a "degraded write" if at least data_shards backends are online. In this case, we should probably also mark the metadata in a separate tree as "degraded" for this file, thus knowing that it later needs to be fixed (when config changes).
While we are at it, it might also be possible to further improve the backend selection. We could generate new configs in a loop, removing backends which aren't healthy as we discover them, and remember the least degraded config in case we can't find a fully healthy one. This solution should find a fully healty setup if one is available at all given the constraints

With the development of a monitoring daemon, this issue is reduced to just pruning unhealthy backends before writing to them. If a degraded write feature is needed in the future, a new tracking issue can be opened for it


zson formatting for zng.Type interface

A method should exist on zng.Type to produce ZSON formatted strings and the zsonio.Writer should be updated to use it (and any other places that need it).

This doesn't make so much sense anymore since we have zson.FormatType(zng.Type) and such a formatter would need to track typedefs to property format an arbitrary type in canonical form.  Closing as zson.FormatType is sufficient.


Build issue while installing with yarn 2

Describe the bug
I Tried installing packages on a svelte project using the newly released yarn 2 and got this error on svelte=preprocess install

Logs
# This file contains the result of Yarn building a package (svelte-preprocess@virtual:d7ed1848a21c820ecedeeb8d612b3590fd625b1c6481824b087a78535b107fd21109966aa2635f5580f2b9f4905e7ec8dab5233b4e9a0b835de69dcbaffc7063#npm:3.3.0)
# Script name: postinstall

[eval]:1
console.log('u001b[36mu001b[1m[svelte-preprocess] Don't forget to install the preprocessors packages that will be used: u001b[22mu001b[39mu001b[34mnode-sass/sass, stylus, less, postcss &  postcss-load-config, coffeescript, pug, etc...u001b[0m')
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SyntaxError: missing ) after argument list
    at new Script (vm.js:88:7)
    at createScript (vm.js:262:10)
    at Object.runInThisContext (vm.js:310:10)
    at Object.<anonymous> ([eval]-wrapper:10:26)
    at Module._compile (internal/modules/cjs/loader.js:1139:30)
    at evalScript (internal/process/execution.js:94:25)
    at internal/main/eval_string.js:23:3

To Reproduce
install yarn 2
yarn add svelte-preprocess in your sveltte project
Expected behavior
A clear and concise description of what you expected to happen.
Information about your project:

Your browser and the version: Brave 1.2.43

Your operating system: OSX 10.15.2

svelte-preprocess version: 3.3.0

Whether your project uses Webpack or Rollup: Rollup

Tested with 3.3.1. Fixed. Many thanks @kaisermann!!


Ineligible devices are returned by Device.all() with include_disabled: false

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
We've encountered an Apple Device state which I haven't seen before. The Devices dashboard on the Apple Developer Portal reports "Ineligible for 14 days".

Querying the device status with Spaceship::Device.find_by_udid returns a status of n.
device = Spaceship::Device.find_by_udid '<DEVICE_ID_REDACTED>'

[{"deviceId"=>"<REDACTED>",
   "name"=>"<REDACTED>",
   "deviceNumber"=>"<REDACTED>",
   "devicePlatform"=>"ios",
   "status"=>"n",
   "deviceClass"=>"iphone"
   "model"=>"iPhone X",
   "dateAdded"=>"2023-01-08T18:27:43Z",
   "dateCreated"=>"2023-01-08T18:27:43Z",
   "serialNumber"=>"<REDACTED>"}]

It looks like only two statuses are currently considered: c for enabled or r for disabled.
https://github.com/fastlane/fastlane/blob/19ab9fad34392514f99b51462e9eec346b197339/spaceship/lib/spaceship/portal/device.rb#L165-L171
I have no idea why a device is ineligible. We do weird things so I could speculate but I haven't found any docs or forums discussing this state.
In any case, the emergent problem is that match is trying to create provisioning profiles for this device and it fails. Additionally, we cannot disable the device while it is in this state. At this point, we're unable to run match at all.
Command executed
devices = Spaceship::Device.all

Complete output when running fastlane, including the stack trace and command used

This is spaceship problem so I can only include the result of the Spaceship request.
device = Spaceship::Device.find_by_udid '<DEVICE_ID_REDACTED>'

[{"deviceId"=>"<REDACTED>",
   "name"=>"<REDACTED>",
   "deviceNumber"=>"<REDACTED>",
   "devicePlatform"=>"ios",
   "status"=>"n",
   "deviceClass"=>"iphone"
   "model"=>"iPhone X",
   "dateAdded"=>"2023-01-08T18:27:43Z",
   "dateCreated"=>"2023-01-08T18:27:43Z",
   "serialNumber"=>"<REDACTED>"}]

Environment

I can gather this if it is helpful but it seems unrelated (and I don't have it readily available).

Facing a (kinda) similar issue. Is it possible to check if a device is ineligible using fastlane?


fix workspace actions

What is this fixing?

It was using the wrong interface, not a functional fix but a code fix.


Install Python bindings via pip

I've gotten a request by a user to install Legion's Python bindings via pip (e.g., python -m pip install .) instead of via setup.py.
This is how we currently install the bindings in our CMake build:
https://github.com/StanfordLegion/legion/blob/b853aa5d8623ff7a52a5a473593c06c7de2bea56/bindings/python/CMakeLists.txt#L46
For more context, you can see the application bug report below. The application is currently working around the issue by pinning a rather old version of setuptools (46).
https://gitlab.osti.gov/mtip/spinifel/-/issues/48
I'd like input from the Legate folks, since you may have experienced something similar to this.

Pinging @bryevdv @trxcllnt @jjwilke, who are currently in the process of updating the legate build workflow: https://github.com/nv-legate/legate.core/pull/323. In a nutshell, we are switching to:

using cmake to automatically retrieve our dependencies and compile our C++ code
using pip install to installs the binaries, libraries and python bits into the currently active python environment.
providing a convenience install.py script that does both steps (in the spirit of what setup_env.py does for regent)

I assume something similar could be done for Legion-python standalone (and then we could potentially break Legion off from the legate workflow)?

There is a small wrinkle: setup.py must be able to find everything required to import legion.h. This includes files like legion_defines.h that are generated by the build (i.e., it's not only source files). I guess this is fine if we're going to only do this on installation (as installing Legion should create all necessary files), and we can specify the Legion prefix to setup.py. Just mentioning it here because it might cause someone trouble while they're building this.

@elliottslaughter I assume that's because that's where the CFFI bindings are generated?
That was actually one reason we're using scikit-build -- the CMakeLists.txt called by scikit-build now generates the CFFI header and install_info.py file (see the new setup.py to verify). Legion could do the same thing to generate legion_cffi.py (and we could delete legion_cffi_build.py).
This is a better place for it, because CMake knows the build/install location of legion.h (via find_package(Legion)) and can call the preprocessor as part of pip install legion/bindings/python.

For Legion, I think I'd rather not have pip install drive the CMake build—though I get why you'd do that in Legate.
For example, Regent has an option to integrate with Python, and that involves driving the Python build from the Regent install. I do not think we want to teach Python how to install Regent (or any other system besides itself), nor do I think we want to force Regent (or any other system) to completely switch their build flow when Python is enabled (i.e., use cmake directly when USE_PYTHON=0, use pip install when USE_PYTHON=1).
So it seems to me the options are:

Remove any Python installation glue from bindings/python/CMakeLists.txt. Now the installation flow will look something like:
cmake ... # build Legion as usual
LEGION_BUILD_DIR=... pip install -e bindings/python # separately, install Python bindings, passing any required paths

I'm not sure if there is a better way to pass arguments to pip install.

Keep the glue but rewrite it to use pip (internally calling ${PYTHON_EXECUTABLE} -m pip install ...).
To help Legate, we could put this behind a flag (opt-in or opt-out, depending on what seems best). Legate could shut this off and do what it needs on its own in this case.

@elliottslaughter apologies, I could have been clearer in my explanation. scikit-build doesn't change anything about how the C++ library is built. You would not need to drive the C++ build via pip (that is an option, but it is implemented via CMake's add_subdirectory(), not via python). scikit-build just glues setuptools and CMake together in a clever way.
The following is a simplified version of the logic here:
# top-level CMakeLists.txt

# This file is the entrypoint for both C++ and Python bindings. The difference is
# scikit-build invokes CMake with `-DSKBUILD=ON` so we can know which one to do

if(SKBUILD) # If cmake is run by scikit-build, configure the python bindings
  include(legion_py.cmake)
else() # otherwise configure the C++ like normal
  include(legion_cpp.cmake)
endif()

Legion's existing CMake stays the same, just moves into a file called legion_cpp.cmake:
# legion_cpp.cmake
project(Legion LANGUAGES C CXX)
# <contents of the current Legion CMakeLists.txt>

And normal way to configure and build Legion is the same:
cmake -S . -B build <Legion C++ CMake options>
cmake --build build

Then we can define the CMake logic that runs when scikit-build invokes CMake:
# legion_py.cmake
project(Legion_Python LANGUAGES C CXX)

find_package(Legion)

if(NOT Legion_FOUND)
  # If Legion wasn't found, configure it in `./build` and
  # compile it as part of the `pip wheel/install` command
  add_subdirectory(. "${CMAKE_CURRENT_SOURCE_DIR}/build")
endif()
# ... do things that need information from the Legion CMake target

The Python bindings can be built via regular pip wheel/install. Passing -DLegion_ROOT= ensures the find_package(Legion) in legion_py.cmake locates the Legion targets in the build dir we created above.
SKBUILD_CONFIGURE_OPTIONS="-DLegion_ROOT=./build" \
    pip install --editable .

# Or if a user doesn't care about building Legion C++ and Python
# bindings separately, they can do both in a single command:
SKBUILD_CONFIGURE_OPTIONS="<Legion C++ CMake options>"
    pip install --prefix=/usr/local .

Under the hood
scikit-build does this when a user runs pip install .:

runs cmake -S . -B _skbuild/<plat>/cmake-build -DSKBUILD=ON
runs cmake --build _skbuild/<plat>/cmake-build
runs cmake --install _skbuild/<plat>/cmake-build --prefix _skbuild/<plat>/cmake-install

The final cmake-install dir is used to construct the python package -- including libs, package config metadata, etc.
At the end you have a real CMake build dir that you can pass to cmake --build _skbuild/<plat>/cmake-build if you want.
Ok but why
If the python build needs information about native libs, compiler toolchains, etc., that build logic can exist in CMake.
For example, Legion, Legate, and cuNumeric all have logic in their setup.py to generate the CFFI bindings from the C++ build's header. But because the python build doesn't inherently know anything about C++ build and packaging toolchains, the agent invoking setup.py must provide the C compiler to use and where the respective C++ header is.
This approach is brittle, difficult to integrate with ecosystem build tools, and causes confusion for new devs or users trying to build the project on their own.
scikit-build would allow us to put this sort of logic in CMake (and setup.py now looks is a lot more boring).
The advantages here are that CMake knows the C/C++ compilers used, it can use the same ones that were used to compile Legion to preprocess the header for the CFFI bindings.
It also knows the path to (via find_package) legion_defines.h and can use things like add_custom_command COMMAND_EXPAND_LISTS to expand out to the full INTERFACE_INCLUDE_DIRECTORIES of the Legion target, regardless of where Legion was found.
Anyway, I'm sure you get the picture -- adding CMake can normalize and simplify a bunch of stuff about the Python bindings build, and shouldn't disrupt hardly anything about the usual CMake/C++ build or dev workflow.

Is there a way to do this without messing with the C++ build? E.g., can the CMakeLists.txt you describe live under bindings/python (or something)? I realize that may seem backwards to you, but it does not seem reasonable to me to contort the C++ build just for Python. Python is not the only language we may ever add bindings for; it should be the submodule, not the other way around.
I guess the rest is fine, but I am a bit intimidated by the complexity to be honest. Yes, in theory, CMake has all this information. The integration with scikit-build seems like a bunch of opaque build stuff that happens magically behind your back; and while you can explain it here, it just gives me a bad feeling. Build complexity you don't control is often a recipe for unexpected results later on.
I agree the motivation behind this change, and maybe this really is the best path, but at a minimum I think we should isolate what we do here as much as possible so the blast radius is as small as possible if something goes bad. And if there are simpler ways to do these things than that would be even better.

Also, could you please address how scikit-build itself gets installed? Ideally, we would not add a separate line you'd need to run just to get the build dependencies. Since it gets imported by setup.py, it seems like we can't rely on the normal mechanisms for specifying dependencies.

@elliottslaughter it is configured as a build-dependency in pyproject.toml and installed by setuptools:
https://github.com/nv-legate/legate.core/blob/ad493f111c96a5d008c809f740a75c0995807575/pyproject.toml#L15-L22
The option for build isolation is another good reason to move away from setup.py install but I'd also remind that calling setup.py install directly is deprecated, and will definitely be going away as an option at some point

@elliottslaughter can the CMakeLists.txt you describe live under bindings/python (or something)?

Oh yeah, absolutely can be (that's how RAPIDS does it too). I was describing what legate.core/cuNumeric do, because they're the examples we're referencing and because they don't have separate TLD's for C++ and Python. We can 100% have a python/CMakeLists.txt that's entirely isolated from the top-level CMakeLists.txt.

Sorry if I'm being dense, does pip install ... read the pyproject.toml file?
My point about setup.py is not that we'll be literally invoking python setup.py .... My understanding is that setup.py is still present in projects that use pip install and that it's still at the core of the install process, even if you never call it directly anymore.
I guess one last question about integration. I think there are four use cases we want to support:

Install Legion C++. This should not have anything to do with Python at all, should not require skbuild or touch any of that. This is what most C++ applications will continue to do.
Install Legion C++ and then build Legion Python bindings on top of that as a separate project. This is what you might do if you have a pre-existing Legion and you want to add on the Python bindings. Sounds like skbuild handles this fine.
Install Legion Python as a top-level project and let skbuild internally build Legion C++ as a subcomponent of that. This is what you might do if you only care about using Python and you just want things to work. Sounds like this should also work.
Install Legion C++ with Python bindings as a subproject. I'm not sure if this is possible because it makes our build cyclic in a weird way, but if it's possible it might be nice. This would be useful for projects like Regent that optionally include Python and don't want to have a completely different way they build when Python gets enabled.

Is option (4) a possibility? (And also, if I've misunderstood any of (1–3), please correct me.)

does pip install ... read the pyproject.toml file?

I could have elaborated. Not pip, per se. But pip install makes use of setuptools (by way of setup.py) and it is  setuptools that reads the build configuration out of pyproject.toml.  (ref: https://peps.python.org/pep-0518/#build-system-table)

My understanding is that setup.py looks like this:
https://github.com/jjwilke/cunumeric/blob/7b9cb5589263322c6450e9e1f68ccd56f6b02a98/setup.py#L18-L19
I.e., there is a from skbuild import setup line at the top of the file. This happens (by definition) before any setup() call is made. Therefore, I don't see how there is an opportunity to install that dependency, if pyproject.toml gets read by some part of that setup process. It looks like a cyclic dependency.
I do see a from setuptools import find_packages line before that. If that line, as a part of importing setuptools, reads the file and installs the dependency, then I guess that works. However, I'd be surprised because it seems very un-Pythonic and very magic.
So the only things I can figure is that some part of the pip install process actually reads pyproject.toml before we ever get to this file, or else this is a use case that is broken, and it is actually not possible to pip install cuNumeric if you do not already skbuild installed.

So the only things I can figure is that some part of the pip install process actually reads pyproject.toml before we ever get to this file

Yes, this is how pip interacts with pyproject.toml since PEP517 and PEP518. pip makes a virtualenv for doing a build, installs the [build-system] requirements into it, then runs the rest of setup.py.

Is this change on the schedule? Asking because recursive installation of the Legion python bindings during legate.core build continues to be a fragile process, and having a pip-based installation for the Legion python bindings would go a long way towards making this more robust.

I'm going to defer to @elliottslaughter on what he thinks is best for this one, but I'm going to mark it as an enhancement and not a bug currently since what we have is functional, just less than ideal.

Noting another non-standards-compliance issue that @trxcllnt brought up: Libraries are not supposed to copy .py files directly under site-packages, but under an appropriately named directory. This way e.g. editable installations can work, because python can create a directory "symlink" like site-packages/my_lib.egg-link ->> /source/to/my_lib (it can't do that with individual python files).
Ideally Legion would put its .py files under a directory, e.g. legion/cffi.py, legion/top.py instead of legion_cffi.py, legion_top.py. This would require that we rewrite the Legion imports in examples, downstream libraries etc.

Ideally Legion would put its .py files under a directory, e.g. legion/cffi.py, legion/top.py instead of legion_cffi.py, legion_top.py. This would require that we rewrite the Legion imports in examples, downstream libraries etc.

This would create a backwards breaking change right? All Pygion users and Regent+Python users would have to upgrade at the same time as Legate.

Libraries are not supposed to copy .py files directly under site-packages, but under an appropriately named directory

Does "are not supposed to" mean "can't"? Add the new proper legion/cffi.py and legion/top.py and keep (for now) legion_cffi.py and legion_top.py that just transitively import everything from the real module, as well as issue a FutureWarning they they will be removed in a year (or whatever).

Paraphrasing from an offline discussion with @vyasr: It is very unusual (but not prohibited) for a single wheel to install multiple files at the top level. If a project is complex enough to have multiple Python files, I would expect a package, not a set of disjoint modules.
So IMHO if we're going to be building a proper wheel, we might as well follow best practices. And as @bryevdv & @elliottslaughter suggest, we can avoid causing major disruption.

Another alternative (credit @trxcllnt) would be to replace legion_top.py with legion_top/__init__.py, which would allow import legion_top to work still (though IMHO if we’re doing all the work to make Legion pip-compliant, might as well do this properly as well).

If I understand correctly, this change requires changes inside of Pygion, but does not break any code that uses Pygion.

Sure, but it does require users to keep their Pygion install in sync with their Legion install, which is what I meant by it being a backwards breaking change.
If we're going to do a backwards breaking change and get everyone to get on board with it then I think we should abide by the established directory conventions.


Why are nonce, onResize, onResizeCapture required for some component?

I am using "react": "^18.2.0", typescript, "@material-tailwind/react": "^1.2.5" and "tailwindcss": "^3.2.1".
For most of components, e.g. Button, requires none, onResize, onResizeCapture at least "undefined", unless there is type error on compiling
Here's my sample code.
import { Button } from '@material-tailwind/react'

<Button nonce={undefined} onResize={undefined} onResizeCapture={undefined}>
   Save
</Button>

Did I miss something on configuration?

I am experiencing this same issue after upgrading from 1.2.4 to 1.2.5 and can't seem to resolve it. Is their a known solution for this currently? Or updated config setting?

I have to strictly set to "1.2.4" to avoid this.

same issue here, even using the 1.2.4 version. I'm using NextJS 12 and tailwind 3.2.1

@andreasawires, i am fine on v1.2.4. I would check your lockfile to make sure what version(s) you have installed. I had some trouble there!

Hey everyone,
I was super busy with the html version of the project, I'll fix this issue on the next update ASAP.
Cheers,
Sajad

Any update on this? Let me know would love to contribute.

@rakshit087 this month I'll release an update with all the fixes.

@ical10 @luckymaniac @Mwi-Mat @EilifAkerjordet @andreasawires @rakshit087 guys I want to reproduce this issue but can't do that could anyone share some small reproduced version of this issue?
Cheers,
Sajad

I'm facing the same issue. I have created a simple Next.js project and followed the doc: npm i @material-tailwind/react.
Many components show this error:

I can dev like this, but npm run build is yelling at me when it's time to deploy 😓
As reference,

Thanks @sajadevo

As of now, either install version 1.2.4 or you can also fill the required
props (nonce, onResize, etc) and keep them undefined.
On Wed, 15 Feb, 2023, 2:51 am Ivan Morgillo, @.***>
wrote:

I'm facing the same issue. I have created a simple Next.js project and
followed the doc: npm i @material-tailwind/react.
Many components show this error:
[image: image]
https://user-images.githubusercontent.com/19003/218865160-d20d8f7f-badc-44b2-8791-6088f911175b.png
I can dev like this, but npm run build is yelling at me when it's time to
deploy 😓
As reference,
[image: image]
https://user-images.githubusercontent.com/19003/218865510-642dcd26-04ac-4503-8f0b-0ac0a7c20f55.png
Thanks @sajadevo https://github.com/sajadevo
—
Reply to this email directly, view it on GitHub
https://github.com/creativetimofficial/material-tailwind/issues/277#issuecomment-1430394144,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMEKP4CIOO65P35AZV7PWQ3WXPZMPANCNFSM6AAAAAAT2GIE3E
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @rakshit087, I can surely fill the required props, even if it gets very noisy quickly. When I do, I get errors on the client side, about non-existent properties like onResize.

It seems to be a problem caused by the version of @types/react. They are addressing the same issue with mui.
https://github.com/mui/material-ui/issues/35287

This issue only happens if you use React 17 to fix it please update to React 18 this will fix the issue it't not an issue with the library it's an issue with the React it self. but still if you want to use React 17 with the library do the following:

Create a new index.d.ts file in the root of your project.
Then put the following code into that file.

declare global {
  namespace React {
    interface DOMAttributes<T> {
      onResize?: ReactEventHandler<T> | undefined;
      onResizeCapture?: ReactEventHandler<T> | undefined;
      nonce?: string | undefined;
    }
  }
}

Thank you for the directions. I updated Next and React:

but I'm still seeing this:

What really did the trick was installing the types:
    "@types/react": "^18.0.28",
    "@types/react-dom": "^18.0.11",

No more errors, and now I have such a nice button! 😍


Move-Monitor-Calico-Components

Move doc from Security tab to Maintenance tab

Approved by Alex

Deploy preview for calico ready!
Built with commit ca101712d591b84c3bcf50c196e862b42ddf3ed9
https://deploy-preview-2870--calico.netlify.com


kube-client should hide exec functionality by default

What problem are you trying to solve?
Want to avoid potential security advisories being landed against controllers built with kube that try to rely on local auth inside of a cluster. If those controllers are compromised then they can in theory be used as an escalation point.
Here is a security advisory for flux for allowing just that.
Describe the solution you'd like
Require some Config setting to explicitly enable Exec, and warn! when a kubeconfig is found with exec and it's not been enabled.
Not quite sure how best to disable Exec as it's an enum on RefreshableToken and it's kind of awkward to push that type of state in there. Maybe we can trim that bit out of the AutoInfo struct.
Thoughts welcome.
Describe alternatives you've considered
feature flags. not great, needs recompilation of apps.
Target crate for feature
kube-client

Maybe we can trim that bit out of the AutoInfo struct.

That should be pretty easy to do.
let mut config = Config::infer().await?;
// Set a field with `#[serde(skip)]` in `config.auth_info` to opt-in.
config.dangerous_auth_exec();

Then impl TryFrom<&AuthInfo> for Auth can check the flag, and either warn! + Ok(Auth::None) or Err(ExecDisabled).

another option: if we can make the use of a local kubeconfig opt-in for in-cluster use, then the burden of sanitising will fall on the app.
that we we are not actually destroying all our examples for people who rely on this type of auth.

Relying on the Kubeconfig itself to decide this would solve nothing, no?
The reasoning behind doing this makes sense, but it's awkward that this pretty much breaks any cluster that uses OAuth for authn.. :/

Relying on the Kubeconfig itself to decide this would solve nothing, no?

yeah, it's a big if; it won't solve anything unless we have a foolproof way. i can't think of a good way to lock-out local authentication for in-cluster, unless we make local-auth a build flag.

We could let users enable it via an env variable (in addition to the API).
That still wouldn't help for cases where users load both a trusted and an untrusted Kubeconfig, but generally OAuth and other exec plugins should only be relevant during development anyway...


CAMEL-14607: support negative acknowledge in pulsar message receipt

Addresses Camel-14607
Motivation
Recently the pulsar version got updated to 2.5.0. In the new version of Pulsar, the negative acknowledgement is now a supported operation and we want to add support for that in Camel as well. This replaces the UnsupportedOperationException with the now supported negativeAcknowledge call.
Verifying the change
A test has been added to the PulsarConsumerAcknowledgementTest class which verifies that the negativeAck call redelivers the message. The test which verified the negativeAck call threw an UnsupportedOperationException has also been removed.
Additional Change
There are minor changes in other test files which just remove deprecated Camel testing features. These were simply done to remove the warnings during the mvn build.

I just realized there is a negative Ack redeliver delay property that would probably be nice to be able to configure. It isn't listed in the concept section so I didn't know that it was there until I was doing some more local testing and nothing was getting redelivered. Apparently the default is a minute which makes it very surprising that the test passes.

I'll wait for the fix suggested here

The failure is from a sourcecheck error for a file in camel-core. Should I address that or is it fine? Same goes for my other PR

No problem. I'll fix that after merging.

Merged on master. Thanks


[Feature request] Add or document command for kernel restart

I've been developing a Python module in one Atom instance, and using Hydrogen and a script in another to do some rough debugging. It's a really nice workflow!
Since Jupyter does not re-import imported modules when the import line is re-run, and it is (AFAICT) not possible to use IPython magics in Jupyter, I end up needing to restart the kernel repeatedly.
It would be useful to be able to keybind the command which is available from the Command Palette as "Hydrogen: Show Kernel Commands" > "Python kernel: restart". Or, if this is already possible, the documentation should list the command which can be used in the keymap.

I've been developing a Python module in one Atom instance, and using Hydrogen and a script in another to do some rough debugging. It's a really nice workflow!

so very nice feedback, thank you!

Thanks for your great feedback! I'll have a look at the restart command next week.
That said, IPython magics work in jupyter as well. There are several options you can use to achieve auto reloading of the imported modules:

add these lines to your python file or to your startup code in the hydrogen setting (http://ipython.readthedocs.io/en/stable/config/extensions/autoreload.html):

%load_ext autoreload
%autoreload 2

or add this to your ipython_config file (http://ipython.readthedocs.io/en/stable/config/intro.html):

c.InteractiveShellApp.exec_lines = ['%autoreload 2']
c.InteractiveShellApp.extensions = ['autoreload']

add these lines to … your startup code in the hydrogen setting
Ah, sorry—I read this comment and so assumed magics were not available at all, so I must have overlooked them in the settings.

I also find very inconvenient that restart kernel can't be assigned a key binding. I'd like to split the command Hydrogen: Show Kernel Commands into:

Interrupt Running Kernel
Restart Running Kernel
Switch Kernel ...

@n-riesco That split was approved by @willwhitney, but wasn't done - I was waiting to have a time to refactor and move to async code in menus. But that time never came :)

@slavaGanzin Would you like to make a PR for it? It should be a matter of adding two new commands Interrupt Running Kernel and Restart Running Kernel, and renaming Hydrogen: Show Kernel Commands to Switch Kernel ....

@n-riesco Ok. I'll do

@khaeru If you are on master branch(or wait for next release), you can map restart kernel in your keymap.cson, for example:
 'ctrl-shift-r': 'hydrogen:restart-kernel'

Excellent, thank you!


Reorder statistics page to have the same order as Table of Contents

The statistics file was massively out of date, as atm it isn't generated automatically. I've updated the config file, which was the real cause of the inconsistency, and pushed those changes, together with the updated statistics, instead.


Customizing dataset

❓ Questions and Help
Hi, I have created a graph from my own text dataset with DGL.
I wanted to ask what is the easiest way to use it (can I use it directly)?

@icocoder you can have a look here https://graph4ai.github.io/graph4nlp/guide/graphdata/construct.html#importing-from-other-sources
You can import data from other sources.
Look into the GraphData import API like from_dgl().

@nashid
It's great, I didn't know about it. Thanks for your help.

@icocoder @nashid Thanks a lot for your reply. I just missed it.

@firqaaa to the best of my knowledge we can only import from
from_dgl(), from_dense_adj(), from_scipy_sparse_matrix() and from_graphdata()

Link: https://graph4ai.github.io/graph4nlp/guide/graphdata/construct.html#importing-from-other-sources

@firqaaa to the best of my knowledge we can only import from
from_dgl(), from_dense_adj(), from_scipy_sparse_matrix() and from_graphdata()

Link: https://graph4ai.github.io/graph4nlp/guide/graphdata/construct.html#importing-from-other-sources
Hi, nashid. @nashid
I have a question about it.
when constructing a graphdata obj, only providing node feat is valid?

This is my error log:
`Traceback (most recent call last):
File "/opt/graph4nlp/examples/pytorch/semantic_parsing/graph2seq/Demo.py", line 48, in
seq_out, _, _ = graph2seq(batch_graph=batch_graph, tgt_seq=tgt_seq)
File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/opt/graph4nlp/graph4nlp/pytorch/models/graph2seq.py", line 228, in forward
batch_graph = self.graph_initializer(batch_graph)
File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/opt/graph4nlp/graph4nlp/pytorch/modules/graph_embedding_initialization/graph_embedding_initialization.py", line 38, in forward
return self.embedding_layer(graph_data)
File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "/opt/graph4nlp/graph4nlp/pytorch/modules/graph_embedding_initialization/embedding_construction.py", line 247, in forward
token_ids = batch_gd.batch_node_features["token_id"]
File "/opt/graph4nlp/graph4nlp/pytorch/data/views.py", line 147, in getitem
return self._graph._get_batch_node_features(item)
File "/opt/graph4nlp/graph4nlp/pytorch/data/data.py", line 947, in _get_batch_node_features
raise Exception("Node feature {} doesn't exist!".format(item))
Exception: Node feature token_id doesn't exist!
Process finished with exit code 1
`
My code:
`opt = get_basic_args(graph_construction_name="node_emb", graph_embedding_name="gat", decoder_name="stdrnn")
opt["graph_embedding_name"] = "gat"
opt["graph_construction_name"] = "custom"
vocab = torch.load("/opt/graph4nlp/examples/pytorch/semantic_parsing/graph2seq/jobs/processed/DependencyGraph/vocab.pt")
graph2seq = Graph2Seq.from_args(opt=opt, vocab_model=vocab)
batch_graph = []
g1 = dgl.graph(([0, 1], [1, 2]))
g1.ndata['node_feat'] = torch.randn((3, 300))
print(g1)
g1 = from_dgl(g1)
g2 = dgl.graph(([0, 1], [2, 3]))
g2.ndata['node_feat'] = torch.randn((4, 300))
print(g2)
g2 = from_dgl(g2)
batch_graph.append(g1)
batch_graph.append(g2)
batch_graph = to_batch(batch_graph)
tgt_seq = torch.Tensor([[1, 2, 3], [4, 5, 6]])
seq_out, _, _ = graph2seq(batch_graph=batch_graph, tgt_seq=tgt_seq)
print(seq_out.shape)`

Looking forward to your reply, thanks. @nashid @AlanSwift


SDC-9202 Allow Oracle CDC recovery option when missing LogFile

The purpose of this Pull Request is to allow the Oracle CDC Client to "recover" in the event a log file goes missing.
Specifically, in my use case, our RDS rolls its log file over every 5 minutes.  Therefore, if I stop the pipeline to do some maintenance, and restart after the rollover window has passed, CDC generation fails. (Note, this fix also solves SDC-9006 where no StageException was being logged if LogFile was missing on startup).
This PR adds functionality to allow the plugin to find the first available current Redo Log entry and resume from that position in the event the log file for the current offset is unavailable.
I am open to other approaches to fixing this issue, but hope this can at the minimum spark discussion.

Hey @JSlowik, same question as the other PR, time to review this as well?

I will resolve the pull request for now since we haven't heard back for several months. Feel free to reopen the pull request when you get chance to get back to it @JSlowik !


pass options through to validate, only fixes #674

This is a fix for the issue #674

Closing as a dupe of 674.


Integration with Storybook and custom styles

This is a feature request.
It seems that now react-sketchapp could only be used only when all styles are inlined in JSX. This significantly limits its applicability for existing projects that often have separate CSS/SASS/LESS/PostCSS stylesheets and/or use something like Bootstrap.
What if there will be some tool that can parse existing demo site (including ones built with Storybook), grab all actual computed styles from DOM (which means app has to be truly rendered by a headless browser or similar) and then produce a temporary react-sketchapp app which in turn can be converted to Sketch file.
Sounds monstrous but should be quite viable.

Being able to use custom CSS in any sort of way would make this tool 100x more useful

We're building for a future of React-as-a-platform, and looks increasingly like React Native-style abstractions are the right model for that.
That leaves some difficult design decisions, such as standardizing around flexbox (for compatibility & reuse, and because we're just a couple of people and implementing every single browser layout model).
I have a feeling this might be the same category of issues — if there's a good solution in the React Native / React VR / React Native Web / React Primitives ecosystem then we can learn from it / use it.

Even if it's true I really hope there will be a way to onboard existing old-style projects with separate custom CSS stylesheets. A converter tool would be a good start anyway.

Like @jongold mentioned above, I also think the style abstraction designed by react-native are a good way to express UI for other platforms then web, this because you don't need to think about css specific inheritance and other things useful for creating documents (This is totally a personal opinion). It enables you to write specific styling for your specific components.
About the react-storybook integration, you would to create a storybook-sketchapp binding or something, same as how the react-native one works, this is something totally doable, did already some experimentation with it, only got stuck with adding Socket communication within cacaoscript, will try further if I have any time left.

Indeed, but doing that we are excluding web environments.
react-native ecosystem using View, Text and inline css is good but I really feel that if we forget about web ( JSX + CSS ) we will lose a lot of value for this tool

I'm going to say this a #wontfix — for the foreseeable future we're focusing on React-as-a-Platform (for more, see this talk by @intelligibabble at React Europe). React Native and React VR equally don't support DOM components or CSS, and I'd rather side with the API that a vast majority of new renderers are using. The DOM has so many edge cases!
That's not to say it's unachievable, I just think there's a smarter solution than including it in core — maybe a codemod, babel plugin, abstraction over the DOM, abstraction over styled-components etc etc.
Happy to leave this PR open for visibility and to spitball ideas / projects that could enable this, if y'all wanna keep discussing :)

let's close this in favor of https://github.com/brainly/html-sketchapp


Font overrides other character sheet modules

When Wildjammer is enabled, the font on other sheets, such as https://foundryvtt.com/packages/compact-beyond-5e-sheet, is overridden. I use a custom UI with fonts I prefer to the default, which makes this particularly jarring.
Without Wildjammer enabled:

With Wildjammer enabled:

I've got a fix on the v10 branch for this. Will pull into a v9 maintenance release.

I added a fix to the 0.4.3 release. Please update let me know if it resolves the problem for you.

Fixed in v9/0.4.3 and v10/0.5.0


Suppress message when run with admin permissions

Is is possible to suppress the question "[WARNING] You are running LxRunOffline with administrator privileges. It may cause problems." when run using an account that has admin permissions? Also what type of problems can come as a result of running with admin rights?
Thanks,
~MC

My  bad.  I missed the wiki entry. Maybe that will help.
Set the environment variable LXRUNOFFLINE_PROMPT_ANSWER to y or n to answer confirmations automatically. Set LXRUNOFFLINE_VERBOSE to 1 to enable verbose output.


use --openssl-legacy-provider flag when running node 17

Closes #2108
Node 17 uses openssl 3 by default, which is not
compatible with webpack 4. This change adds a check to see if
the user is running node 17, and if they are, we add the appropriate
flag to the call to node (https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V17.md#openssl-30)

What if we just always pipe this argument? Will node complain that it does not exist in older versions?

node throws on bad options, so the check is required.

Note that this feature is causing a lot of trouble for some, including with Homebrew on macOS and with Arch Linux: https://github.com/cloudflare/wrangler/issues/2155#issuecomment-996678947
To quote https://github.com/cloudflare/wrangler/issues/2155#issuecomment-992264119:

It looks like wrangler makes an assumption for a key openssl-legacy-provider based on nodejs version, but the heuristic is a bit more complex.


[$500] LHN - Task name not displayed in chat preview in LHN after re-logging

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.13-4
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @
Action Performed:

Open the app and log in
Navigate to any chat
Assign a task
Log out
Log in to the same account or as another user with whom the task was shared

Expected Result:
The task name is displayed in the chat preview in LHN as the last message
Actual Result:
Only "Task for" is displayed until the chat is opened
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/115492554/6fc1f749-c26c-423f-8dee-bbfac1835c1c

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01dfcd1e43b6e247d3
Upwork Job ID:<PHONE_NUMBER>066258944
Last Price Increase: 2023-12-15

Proposal
Please re-state the problem that we are trying to solve in this issue.
Task name not displayed in chat preview in LHN after re-logging
What is the root cause of that problem?
The root cause lies in here
https://github.com/Expensify/App/blob/8bef4bbd123fb6aa8d36e91c3012677208670793/src/libs/TaskUtils.ts#L46-L47
Until the report is opened by the user the reportAction has neither childReportID nor childReportName
What changes do you think we should make in order to solve the problem?

We should fallback to the lastMessage whenever there is  neither childReportID nor childReportName
https://github.com/Expensify/App/blob/8bef4bbd123fb6aa8d36e91c3012677208670793/src/libs/OptionsListUtils.js#L418-L419
to
    } else if (ReportActionUtils.isCreatedTaskReportAction(lastReportAction) && (lastReportAction?.childReportName || lastReportAction?.childReportID)) {

What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
The name of the task on the LHN is not correct when re-login
What is the root cause of that problem?
When we first log in, we get the empty title of the task here because we dont have a childReportID, Until we open the report https://github.com/Expensify/App/blob/ab138ee48f200e7d65bbb00f8fc2161e1f0c80fb/src/libs/TaskUtils.ts#L45-L49
What changes do you think we should make in order to solve the problem?
Since we updated the method to get the title of the task here we want to translate it.
So we can update the logic get the taskReportID.
const taskReportID = reportAction?.childReportID ?? (reportAction as OriginalMessageAddComment)?.originalMessage?.taskReportID ?? '';

What alternative solutions did you explore? (Optional)
N/A

Hi, Will review today.

TY! @abdulrahuman5196 what's our findings?

Re-checking again now

@namhihi237 's proposal here https://github.com/Expensify/App/issues/33165#issuecomment-1858022203 looks good and works well.
For some reason, the childReportID is not populated during initial OpenApp api call, but populated after OpenReport API call. But the taskReportID is present in originalMessage of the reportAction even after OpenApp API call, so the above frontend fix is also working.
We can also fix it in backend by making sure childReportID is being populated.
But I think frontend fix is enough for now, anyways will let the internal engineer confirm on this as well.
🎀 👀 🎀
C+ Reviewed

Hmm, I think I disagree with the recommended proposal as it does not seem like it would fix the problem.

When we first log in, we get the empty title of the task here because we dont have a childReportID, Until we open the report

Sounds like a backend issue then.

For some reason, the childReportID is not populated during initial OpenApp api call, but populated after OpenReport API call. But the taskReportID is present in originalMessage of the reportAction even after OpenApp API call, so the above frontend fix is also working.

Ok but that's a problem because now the title is getting populated two different ways. Which way is the right way? Let's pick one and make sure it works vs. having various fallbacks and workarounds.
cc @thienlnam

@marcaaron currently in the originalMessage we always has a taskReportID if the reportAction is task. So i think we can only use it from here

Hmm I think this was broken recently - historically we had it populate either the task report or the reportAction because if you never open the task report, you don't ever have the task report fetched.
We've made a lot of BE changes but every task change should now also update the parent reportAction and if not we should make sure to update that flow. So because the scenario where you can have someone that never opens the task report and therefore never gets those task pusher updates, we should use the reportAction data

@thienlnam We use reportAction data here but in this case, When the task has the last reportAction as CreatedTaskReportAction  we want to get the taskReportID to get the title.  And we consider 2 ways. Use
reportAction.childReportID or get from  originalMessage. Currently reportAction.childReportID In case of re-login it does not return data childReportID so can we get originalMessage? Can you confirm this

We should probably update the BE so it always returns the childReportID

@thienlnam Here we use the condition in originalMessage to check whether the created report action is created.
https://github.com/Expensify/App/blob/7b836cfcee79084177191e3dfb4a927698b09eb4/src/libs/ReportActionsUtils.ts#L612-L614
And we use it in a few places, like here:
https://github.com/Expensify/App/blob/7b836cfcee79084177191e3dfb4a927698b09eb4/src/libs/OptionsListUtils.js#L419-L420
That's why I think why we should consistently use it to get the taskReportID, what do you think?

Not overdue. Discussing on potential fixes from backend.

Not overdue. Discussing on potential fixes from backend.

Pending on the same

@thienlnam Mind if I hand this one off to you? You have more experience with tasks and I am not 100% sure what we are holding on.

@abdulrahuman5196 can you push this conversation forward somehow? Perhaps bring it to Slack with the details and tag in the relevant people who have worked with this feature before?

We should probably update the BE so it always returns the childReportID

@thienlnam Could you kindly check on this? Are we going to update Backend to solve this issue?

Yeah I can take this, looks like we should be passing back the childReportID parameter when loading chats

Updating the priority as it's not by any means urgent

@thienlnam do we think this fits in #vip-vsb?

Yeah, this could be a good low polish for vip-vsb

added appropriate designation

no movement

Same as last week.

same

Thoughts on closing this? Doesn't seem valuable to work on at this time


What is the unit of size?

/**
 * @var int
 */
protected $size = 300;

What does size mean? Is it in ciceros, didots, French picas, American picas, points, pixels, inches, meters, light years?
Without knowing what the number represents, it's hard to compute the right size to fit inside a fixed size area.

It's in kilojoule (kJ)

Here I was thinking I was going to get an answer that would make it easier to use this package.
I guess I can be thankful that it's not in gigawatts.


$volumeSizeBytes =<PHONE_NUMBER>776 # 100GiB

[Enter feedback here]
$volumeSizeBytes =<PHONE_NUMBER>776 # 100GiB
Please double check that. It create a volume with 1TB quota.
Should it be<PHONE_NUMBER>00

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

ID: 2ecb551a-3b78-df78-cefd-cd07614e043f
Version Independent ID: 9bbe39e4-8813-7e06-1c1d-9e07d3704435
Content: Quickstart: Set up Azure NetApp Files and NFS volume
Content Source: articles/azure-netapp-files/azure-netapp-files-quickstart-set-up-account-create-volumes.md
Service: azure-netapp-files
GitHub Login: @b-juche
Microsoft Alias: b-juche

@olt1892 Thank you for [pointing this out . We will have this reviewed and updated as needed.

@olt1892 - Thank for your feedback.  Can you tell me where you see "1099511627776" that needs to be replaced with "<PHONE_NUMBER>00"?  Thanks!

@olt1892 - Thank for your feedback. Can you tell me where you see "1099511627776" that needs to be replaced with "107374182400"? Thanks!

@olt1892 - Would you mind clarifying?  Thanks much!!
If you are an ANF team member and would like further discussion through email, feel free to reach out at<EMAIL_ADDRESS>

@olt1892 - Haven't gotten clarification from you about this request, but I don't want to miss any further input you might have.  If you are an ANF team member, you can reach out at<EMAIL_ADDRESS> For now I'm closing this issue.  Thanks!
#please-close


@stylify/bundler does not work since new version 0.6.0

Describe the bug
I updated this stackblitz project from 0.5.0 to the new version 0.6.0 and the bundler does not work anymore. I get the error "RangeError : Invalid string length...".

"selectorsAreas" with an empty array = no problem
"selectorsAreas" with an array = problem
Reproduction
https://stackblitz.com/edit/stylify-remix-example-eqmg9w?file=package.json
Logs
❯ npm run stylify:build
$ node stylify.js
01:24:40 AM [stylify] "RangeError: Invalid string length\n    at Compiler.compile (file:///home/projects/stylify-remix-example-eqmg9w/node_modules/@stylify/stylify/lib/index.cjs:502:35)\n    at bundleRunner (file:///home/projects/stylify-remix-example-eqmg9w/node_modules/@stylify/bundler/lib/index.cjs:574:55)\n    at async execBundleRunner (file:///home/projects/stylify-remix-example-eqmg9w/node_modules/@stylify/bundler/lib/index.cjs:665:9)\n    at async Promise.all (index 0)\n    at async Bundler.bundle (file:///home/projects/stylify-remix-example-eqmg9w/node_modules/@stylify/bundler/lib/index.cjs:301:7)"
01:24:40 AM [stylify] No bundle was processed.

System Info
"@stylify/bundler": "^0.6.0"

Node.js v16.14.2 on stackblitz link (but I use Node v18.12.1 on my local computer and I've the same issue)

Hi @micisse.
The 0.6 contains a few changes that are described within the getting started migration guide
https://stylifycss.com/en/docs/get-started/releases/
I have updated your example so it works with the 0.6: https://stackblitz.com/edit/stylify-remix-example-cwpuvn?file=stylify.js,index.txt,app%2Fstyles%2Fstylify.css
selectorsAreas
These areas are receive regular expression instead of string
    selectorsAreas: [
      /(?:^|\s+)className="([^"]+)"/,
      /(?:^|\s+)className='([^']+)'/,
      /(?:^|\s+)className=\{`((?:.|\n)+)`\}/,
      /(?:^|\s+)className=\{((?:.|\n)+)\)\}/,
      /(["].*["])/,
      /(['].*['])/,
      /(?:^|\s+)backdropClassName="([^"]+)"/,
    ],

stylify.js
In the Stylify config you have in the example, update the line with mangling, so it mangles selectors only, when not in a watch mode
mangleSelectors: !isDev,

I have tested the build and dev commands and it seems it all works after these changes.
Please try it out and let me know, if it works for you as well.

Hi @Machy8
I was able to read the changelog and apply the changes but nothing is said about the changes to do for the "selectorAreas". Maybe it should be mentioned in the changelog also. Compared to version 0.5 where you had to use strings. The documentation is also not up to date as I write this comment (https://stylifycss.com/en/docs/stylify/compiler/#selectorsareas). I've tested and it's ok 👍 ! I close the ticket

Sorry, I have overlooked that. I will add that into the changelog. Thanks. And ok.


ci: disable testing python 3.6 on macos as it is no longer supported

⚠ Pull Requests not made with this template will be automatically closed 🔥
Prerequisites

[ ] Have you read the documentation on contributing? https://github.com/bee-san/pyWhat/wiki/Adding-your-own-Regex

Why do we need this pull request?
This repository has automatically switched to macos-11 from macos-10.15 as it has macos-latest specified.

https://github.com/bee-san/pyWhat/runs/3938576787#step:1:4: macos 11

This means that Python 3.6 is no longer available in GitHub Actions runners:

actions/virtual-environments#4060 -> Python toolcache:

Tool name
macOS-10.15
macOS-11
Notes

Python toolcache
<IP_ADDRESS>.73.83.9
<IP_ADDRESS>
EOL python versions were deprecated

I had this commit on my fork as all actions would fail because of this issue. Looks like GitHub automatically updated my new fork to macos-11 but kept this repo on macos-10.15, but now this repo has been updated to macos-11.
What GitHub issues does this fix?

Closes #217

Copy / paste of output
Please copy and paste the output of PyWhat with your new addition using an example that tests this addition below:

Codecov Report

Merging #237 (324d7b6) into main (2589780) will decrease coverage by 1.90%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #237      +/-   ##
==========================================
- Coverage   94.50%   92.59%   -1.91%
==========================================
  Files          14       15       +1
  Lines        1729     1216     -513
==========================================
- Hits         1634     1126     -508
+ Misses         95       90       -5

Impacted Files
Coverage Δ

tests/test_regex_identifier.py
96.55% <0.00%> (-2.03%)
:arrow_down:

pywhat/__init__.py
90.00% <0.00%> (-0.91%)
:arrow_down:

pywhat/regex_identifier.py
92.50% <0.00%> (-0.19%)
:arrow_down:

tests/test_regex_formatting.py

tests/test_regex_database.py
88.88% <0.00%> (ø)

conftest.py
100.00% <0.00%> (ø)

tests/test_click.py
98.36% <0.00%> (+0.05%)
:arrow_up:

pywhat/helper.py
90.00% <0.00%> (+0.44%)
:arrow_up:

pywhat/filter.py
87.30% <0.00%> (+2.45%)
: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 2589780...324d7b6. Read the comment docs.

Updates and support for 3.6 seems to be ending at the end of the year, so that may be the reason. While we are at it could we add 3.10? :)

While we are at it could we add 3.10?

I added that in #221 :smile:

I added that in #221 :smile:

Oh amazing thank you! I was looking at the test file in this PR where there is no 3.10. 😅

We shall re-evaluate what Python version things use (Ubuntu, Remnux, etc etc) and see if we can up this limit in the new year :)


Create a troubleshooting guide for Cluster Autoscaler.

And explain how various failures in the cluster affect CA.
cc: @fgrzadkowski @piosz

Created FAQ.