Improved Directory Structure

Discussed in https://github.com/nuxt/nuxt/discussions/20251

Originally posted by Atinux April 13, 2023
Nuxt 3 is now a fullstack framework thanks to Nitro with the ability to have auto-imported modules and layers, I believe it's time to rethink the directory structure to give more separation for the "app" level.
This is the proposal I am thinking of:
.output/
.nuxt/
app/
  assets/
  components/
  composables/
  layouts/
  middleware/
  pages/
  plugins/
  utils/
  main.vue
  router.options.ts
content/
layers/
modules/
node_modules/
public/
server/
  api/
  middleware/
  plugins/
  routes/
  utils/
nuxt.config.ts

Do you see any downside of this approach?
The minimal starter would then be:
app/
  main.vue
public/
  favicon.ico
nuxt.config.ts

Shouldn't we also move the content/ dir into the app/ dir? I think that way, it would align better with the usage of each dir.

Not sure for content/ as I found it similar to public/ and the data is not bundled.
It also allows having a minimal usage when used with a Nuxt Layer:
content/
  index.md
nuxt.config.ts <-- Using extends: 'my-docs-theme'

(BTW should middleware dir be middlewares?)

Love it! 💚
What will be the best approach to share common utils that can be used in /server and /app e.g some string manipulation utilities.
Put’em in /layers?

Love the new proposal!
Would you need to follow this structure to upgrade from v3 to v4?
Laravel recently changed its boilerplate folder structure. Although the new version works with the previous folder structure, users fear that if they don't adapt to the new structure, future code might break because they have things in the wrong place.

I believe we can easily detect the old format and have a way to upgrade to the new one by running either nuxt dev or with a nuxi upgrade command.

Discussed in #20251
Originally posted by Atinux April 13, 2023 Nuxt 3 is now a fullstack framework thanks to Nitro with the ability to have auto-imported modules and layers, I believe it's time to rethink the directory structure to give more separation for the "app" level.
This is the proposal I am thinking of:
.output/
.nuxt/
app/
  assets/
  components/
  composables/
  layouts/
  middleware/
  pages/
  plugins/
  utils/
  main.vue
  router.options.ts
content/
layers/
modules/
node_modules/
public/
server/
  api/
  middleware
  routes/
  utils/
nuxt.config.ts

Do you see any downside of this approach?
The minimal starter would then be:
app/
  main.vue
public/
  favicon.ico
nuxt.config.ts
```</div>

I guess also a tsconfig.json is required for the minimal starter

I would say in ~/utils if they are used both in server and app

Is this also the folder to place data types? For example data structures stored in cookies or used in api routes that are used by both server and client? I know there is support for the '~/types' folder but it isn't mentioned anywhere.

Can we keep server/plugins/ for server plugins? 👀

@Lootjs yes, server/plugins will not be removed 👍🏻

sigh of relief

We're also discussing ideas like ui, web, frontend, vue, but still feeling that app is frontrunner here. Other ideas welcome.

app/server - without analyzing what is the role of each directory I think it sounds more natural to say that UserSchema is part of the app. Server importing from app does not sound that bad, right?
client/server - I could choose server as it the source (where user is created) or I might go with a /shared folder from which both will import.
frontend/backend - as above but I think that there will be more preference over a shared folder.

What I like about Nuxt is that it blurs the lines of a traditional frontend/backend, client/server setup. And with server side pre rendering the frontend is not necessarily running on the clients side. So in that line naming it client/server might make you think in that more traditional way. Something like interface/api might work since it doesn't imply where it is run just what it is.

In my mind, Nuxt app is a combination of vue's frontend and the backend. So seeing app and server separately makes me feel like this server is something outside this Nuxt app. But I like the server being separate as it's really server-only thing.
On the other hand, app folder contains lots of stuff that is actually shared across frontend and backend.
.output/
.nuxt/
content/
layers/
modules/
plugins/          <- I've moved plugins out on the same level as modules
node_modules/
public/
client/
  something-really-client-only-but-not-sure-what-it-is/
  assets/
  components/
  composables/
  layouts/
  middleware/
  pages/
  main.vue
  router.options.ts
shared/
  utils/
server/
  api/
  middleware/
  plugins/
  routes/
  utils/
nuxt.config.ts

But I actually prefer the current structure over this 😅
@Atinux

give more separation for the "app" level

could you probably give us more insights on what kind of separation for the app level you meant, and what kind of problems we're trying to solve here?

@danielroe How about nuxt ? :D
Reposting my thoughts from the initial discussion :
I really like the fact that we now have server/routes, and plugin and modules are now clearly separated.
I think that if we are changing the structure, we should consider more changes and bring in more benefits.

app is a generic name
There's now an additional level of nesting
app/router.options.ts feels out of place
content is not a part of nuxt/core, which other modules should be considered ?
difference between utils and composables ?
why not get rid of both utils and use composables everywhere?
what about app.config.ts ? Is it deprecated ?
why main.vue and not index.vue ?
where would tests go ? That should be part of the directory structure imo

Instead of app and server, I suggest nuxt and nitro ?
This makes things clearer imo :

Explicitness of Nuxt and Nitro as TLD
Align standalone nitro and nuxt directory structure
Bootstrap the new .config directory structure proposal

Here's what I'm thinking :
.output/
.build/
node_modules/
nuxt/
 assets/
 components/
 content/ #this should be next to pages
 composables/
 layouts/
 middleware/
 pages/
 plugins/
 tests/ # component tests
 index.vue # could be main.vue
nitro/
 public/ # this is more consistent with how nitro works
 api/
 middleware
 routes/
 tests/ # server only tests can go here.
 composables/ # align with vue conventions
layers/ # layers and modules could be nested under something like extends/
modules/
config/ # To align with Pooya .config proposal
 nuxt.ts
 app.ts  # could be moved to runtime.config.public
 nuxt-router.ts
tests/ # global/integration/e2e tests can go here
nuxt.config.ts # we could support this as well

Minimal starter
nuxt/
  index.vue
nitro/
  public/
    favicon.ico/
.config/
	nuxt.config.ts

This is my current approach

As said by someone above, I feel app is more like an overall name, more like an alias to the word project.
An app could have the client and server side. It makes more science to me.

can you include a src directory?
.
├── ./public
├── ./src/
│   ├── ./app
│   ├── ./middleware
│   └── ./server
└── nuxt.config.js

/app dir is currently using by spaLoadingTemplate, would it be moved somewhere to avoid conflict with this issue?

Before I read this issue fully my gut reaction was it should be app because that is what first jumped into my mind, and now after reading the full issue I think app is still the winner because of ambiguity of the word.
Words that try to be more specific will fall short of encapsulating the full breadth of what is/can be done in the app directory. The narrowest alternative I can come up with is vue (this is where the vue part of the app lives after all) — but even that falls short of describing the full breadth.
I‘ll cast my vote towards app.

I do this already for all my Nuxt apps and find it really helpful.
I use “app” as the top level name

Wonderful points by @manniL and others.
Well I don't know if this will be of any help, but here's what ChatGPT has to say 😅

Link to the chat => https://chat.openai.com/share/50d4f3aa-5f63-4a1b-99ae-13d3a69de1ce

Here's my take:

Initially, I thought about src, as I usually put everything in a src folder and create an alias in nuxt.config This is because there are numerous items at the root level. However, I wouldn't recommend src since the contents of plugins, server, and more are also part of our application's source. (I'm unsure about assets, though.)
Many suggest app, which I agree with, particularly as it has become a de facto of some sorts.
I also appreciate the idea of a client folder existing alongside the server folder.

That said, I believe app would be a more appealing default option.

The "/app" directory name seems the most common, but the server directory is also part of the app, so it might be confusing at first.
What about the "/UI" directory? In the end, regardless of whether some components will be client- or server-rendered, everything in this directory will be connected to the UI and will be a part of it.

What about new ‘routes’ as alternative to ‘pages’, or maybe other option beside it, I really love remix v2 routes directory, I prefer it for big projects to work as vertical slice architecture
I wish see it soon in nuxt

I like it. The root became a little convoluted. This makes clearer what's server and what's client

We're also discussing ideas like ui, web, frontend, vue, but still feeling that app is frontrunner here. Other ideas welcome.

I agree that app sounds like the best one. Unless we split our app into multiple modules, in which case it would be strange to call each layer an app (if doing DDD) because in that case a layer is more of a module than an app.

How about nuxt ? :D

Minimal starter
nuxt/
  index.vue
nitro/
  public/
    favicon.ico/
.config/
    nuxt.ts

@Hebilicious I liked this idea at first but, imho, it brings the same problems as calling them server/client: the "nuxt" part of your code may need nitro. I still think that "nitro" would be a good name for the server part, but I'm not sure it brings any benefits over the current name.

app/ certainly has my vote. Love this proposal, I never found an issue with the structure until I saw this post though honestly.

I totally agree with the app separation, but not with the app separation.
One of my sites is way more separated, but I keep things like middleware out of app:

However, I think the suggestion that layers should be a first class citizen is a great one, so I might suggest:
app/
  main.vue
base/
  public/
    favicon.ico
nuxt.config.ts

ui/
app.vue
server/
routes/
nuxt.config.ts

I agree with the proposed structure, but I also believe that there's the need to have shared utils/ and, of course, types/ between app/ and server/.
I'd like to add that it would be nice if it was acknowledged from the beginning a "monorepo" structure with multiple apps/ for large projects. Sometimes sharing things like layers, content (types), etc, but not necessarily, they could have their own. What do you think?
Also, since content is not part of "Nuxt core", you could showcase a full example with other common modules like [i18n] (https://i18n.nuxtjs.org/docs/guide/lazy-load-translations).
Thank you for your time! 🤗

@manniL
Thanks for replying to everyone !
For now, Nuxt and Nitro are tightly coupled, but I'd like to imagine a (distant) future where it would be possible to configure this, and use a different server engine (Laravel, Django, Elysia ...) officially through a configuration option. Since we support multiple bundlers, we could attempt multiple servers. If that ever happens maybe both Nitro and the other server would be present, so having this directory structure would remain clear.
app/router.options.ts would fit like a glove in the new .config directory, with every other configuration file.
App.vue is a great option too.
You're right with tests, it's very opinionated. We can be flexible as they will be detected anywhere anyways.
One more word regarding the relation between nuxt and nitro : Even though they are worked on by the same people, they are separated projects that lives in different repositories, with separated documentation. Having that distinction present in the directory structure makes it crystal clear.
@AymericB305 I would argue that Nuxt and Client are really different : Nuxt should be understood by all as a meta framework, SSR framework or universal framework, meaning that you can write something in /page that will be SSRd.
To me it feels like thatnuxt would fit a directory name that could contain server code, and is a little bit more specific than app.

For now, Nuxt and Nitro are tightly coupled, but I'd like to imagine a (distant) future where it would be possible to configure this, and use a different server engine (Laravel, Django, Elysia ...) officially through a configuration option. Since we support multiple bundlers, we could attempt multiple servers. If that ever happens maybe both Nitro and the other server would be present, so having this directory structure would remain clear.

@Hebilicious Love this train of thought. My agency's stack is laravel + vue, but as the frontend developer, I would love the DX improvements that nuxt brings.

How about nuxt ? :D

Don't we have a .nuxt folder already? Wouldn't it cause confusion?

I personally stay away from "client/server" these days and especially not "front-end" / "backend", as these terms are getting more and more vague/ somewhat relative.
I'm in the nuxt/nitro proposal camp if anything, although, I don't really see the value upside vs what we already have, I kinda like the flat structure, mostly to avoid having to think about exactly this discussion lol this notion feels a little like fixing something that isn't broken
A default top level base folder might not be a bad idea though for "app" or "src". Mostly just for aesthetics though, so that root repo directories don't look overwhelming/messy.

On the side note, this rfc would be equal to just changing the default srcDir and serverDir, so that people can easily revert to the original flat structure right?

IMO, considering that already Nuxt 3 uses the client/server nomenclature in some places, I guess that would be the correct option. Otherwise, other things such as the ClientOnly component would also have to be changed to whatever new nomeclature we use in V4.
This being said, I guess app wouldn't work well because it would feel like server is outside of the app, and it's not.
Therefore other good options I saw were nuxt (but might be confused with .nuxt), ui and web

I'd love to see pi0's .config proposal implemented in v4!

@dargmuesli It's already implemented!

@danielroe I'm looking the nuxt docs and pi0's proposal but I can't seem to find any documentation about the config dir.
Is there a page I can check or a repo to use as example? (supported files, naming convention, etc)

@NicolaSpadari We support loading Nuxt config from .config/nuxt.ts or .config/nuxt.config.ts.

@NicolaSpadari I believe what you're looking for is written here: https://github.com/pi0/config-dir. 🤗

Since we are discussing directory structure, I would like to bring up an idea about perhaps pages should be called views. Since we are building full-stack apps now not websites. When reading the Nuxt documentation, it often describes building an application (emphasis on application). And when reading the section about pages it says the following:

Pages represent views for each specific route pattern.
https://nuxt.com/docs/getting-started/views#pages

I have always found it a bit odd that these "views" are called pages. Perhaps this comes from the term "webpage" or a classical website where a user browsers multiple pages. But since we are building apps with Nuxt, the term pages seems to be limited to the idea of a webpage. Many modern web apps looks more and more like native desktop apps and they certainly don't have pages so calling them that is a bit misleading. For example - there is no "pages" in Photoshop.
And since Pages represent views, why don't we call them views? I think views would work for both - classical web pages and modern web apps. In fact, I think pure Vue with Vue Router used to encourage to create a views directory for multiple routes. I wonder why Nuxt decided to call them pages instead.
I think this topic deserves a discussion and we should try to approach this with an open mind. Perhaps we're too used to calling them pages by now but I for one would vote for calling them views. What do you think?

@martinszeltins — a quick opinion on pages vs views: I think everything in the current pages folder is intended to be a routable target? Whereas "views" could be seen to include partials (and potentially other non-routable elements), especially if coming from other frameworks like Ruby on Rails where the views folder contains both routable targets and partials.
FWIW, I've made peace with the concept of "pages" in web apps, as I think it best describes what it is: a routable target, and also works well for SSR scenarios (where a request comes in for a path and a particular view is rendered, which can contain other views [aka componentsin Vue/Nuxt]).

Ok i thought it was already implemented in nuxt for multiple config files.
I understand it's a proposal that libraries themselves have to adopt, thanks for the clarification

I think it's change and not a lot of change

Not relevant to directory structure, I personally think that the middleware folder is better named in plural form like the other directories (pages, components, layouts, plugins ...).

I think it's change and not a lot of change

I think Middleware is just more proper English.

I'm also expecting app router like next 14 and route group. now if we need auth routes in auth folder then route become
/auth/login
/auth/register

it will be good if
pages/
    (auth)/
        Login.vue
        Register.vue

route now should be
/auth/login
/auth/register

Only index.vue accessible in router
pages/
    (auth)/
        Login/
            index.vue
            style.css

I believe in the second scenario you wanted the paths to be:
/login
/register

as the (auth) directory is just for grouping purposes, I had the same request, actually, so yes that would be nice.

@mahmoudyusof exactly

@hbilal9 Is there a workaround to do this now? I don't want to define an alias in each page independently.

My 2 cents:
When we check the types for all defineX and addX (module authoring) functions like defineNitroPlugin, defineNuxtRouteMiddleware, addServerPlugin
we consistently find 2 types: NuxtX and NitroX.
I think that's the key🔑: 👉Rename .nuxt (.nuxt-output, .nuxt-generated?), and move app stuff to nuxt and server stuff to nitro inside src. Also add a shared to share types, schemas, utilities, between nitro and nuxt.
And move modules from nuxt to src.
Simple:
.config/
  nuxt.config.ts
  i18n.config.ts
  app.config.ts
.nuxt-generated/
src/
  nuxt/
    public/
      favicon.ico
    app.vue
  nitro/
    tsconfig.json
  shared/
package.json
tsconfig.json

Complex:
.config/
  nuxt.config.ts
  i18n.config.ts
  app.config.ts
.nuxt-generated/
src/
  nuxt/
    lang/
      en-US.json
      es-ES.json
    public/
      favicon.ico
    assets/
    plugins/
    middleware/
    pages/
      index.vue
      profile.vue
      admin-panel.vue
    app.vue
  nitro/
    api/
    routes/
    plugins/
    middleware/
    tsconfig.json
  modules/ (with the option to rename to features or domains)
    post/
    user/
    db/
      runtime/
        nitro/
          middleware/
            index.ts (Injects the models in the H3EventContext)
          plugins/
            index.ts (Initialize db and connect client)
    auth/
      runtime/
        pages/
          login.vue
          register.vue
        middleware/
          auth.guard.ts (Nuxt page middleware. "auth" in definePageMeta middleware array)
        stores/
          auth.store.ts (Pinia store)
        composables/
          auth.composable.ts
        nitro/
          api/
            login.post.ts
            register.post.ts
            profile.get.ts
            logout.delete.ts
          middleware/
            auth.guard.ts
      index.ts
  shared/
    types/
    schemas/
    utils/
 .env.dev
 .env.prod
package.json
tsconfig.json

(Controller/Service classes in place of Pinia stores or composables).
In my case, the whole nuxt app goes inside a client dir in the root of the workspace, because sometimes I work my server with other frameworks and only the frontend with nuxt in SPA mode, and server stuff goes inside server with that framework's own directory structure. So client and server are framework agnostic. I would delete client/src/nitro and client/src/shared, in favor of root/shared and root/server in that scenario:
client/
  src/
    nuxt/
server/
  src/
shared/

🔥👋💚 Ready for Nuxt 4, Nuxt 5, Nuxt 6, Nuxt 7, Nuxt 8. 👀 😁
Lots of health, peace, and success to the team and Nuxters™ (contributors).

Hey all 👋🏻
Thanks a lot for all your input and suggestions! I wanted to comment and share my personal opinion with regard to some of these here ☺
@eunjae-lee

In my mind, Nuxt app is a combination of vue's frontend and the backend. So seeing app and server separately makes me feel like this server is something outside this Nuxt app.

I'd say you could simply take the server folder and run it a standalone Nitro app, yes. But of course, for SSR'ing your Nuxt app, Nitro is "needed", same for running Nuxt plugins on the server side. But this code is all in the app folder anyway. I tried explaining that a bit ago here.

But I like the server being separate as it's really server-only thing.

This exactly!

On the other hand, app folder contains lots of stuff that is actually shared across frontend and backend.
I've moved plugins out on the same level as modules

I think moving plugins up isn't the way to go, as "Nuxt plugins" should stay within the Nuxt app while Nitro plugins belong in the server folder as these are two fundamentally different plugin types. ☺

could you probably give us more insights on what kind of separation for the app level you meant, and what kind of problems we're trying to solve here?

I am not @Atinux but separating the Nuxt app from the server helps understanding the "boundaries" between your "Nuxt/Vue" part (even if it might be SSR'ed) and the "server" part a bit more. Lots of people try using pinia or Vue composables in /server, which could be less tempting with the new structure from my POV.
@wajeht app will be treated as srcDir "internally".
@therealokoro client might suggest that the application is client-only, but as Nuxt is capable of SSR and the content in that folder will be SSR'ed, it could trip off people IMO.
@Hebilicious

How about nuxt ?

Would that mean that Nuxt can "exist" without nitro or that Nuxt "does not include Nitro"? 🤔

* `app/router.options.ts` feels out of place

Where else would you put it? 🤔

* difference between `utils` and `composables` ?
* why not get rid of both utils and use `composables` everywhere?

The difference is a big one semantically (e.g. explained in this video) - happy to see clear separation there.

* why `main.vue` and not `index.vue` ?

The name of the "App.vue" replacement is still to be discussed. I personally think App.vue would still suit the best as index.vue could be confusing (as it is not file-system based routing) and hard to find (when using fs-based routing you have so many index.vue)

* where would `tests` go ? That should be part of the directory structure imo

IMO:

Unit tests folder - nowhere, tests close to your components, ___tests__ if necessary
E2E-tests top-level.

Instead of app and server, I suggest nuxt and nitro ? This makes things clearer imo :

The more I think about it, the more I begin to like that! 🤔 Only the first question (Would that mean that Nuxt can "exist" without nitro or that Nuxt "does not include Nitro"? ) isn't resolved with that.

/app/app.vue -> /app/render.vue
Since it duplicates the name app, it’s not nice, I suggest changing it to render since it renders the server and the client

FWIW I've been doing a lot of work with layers recently (on my 4th project with them) and there are quite a few inconsistencies and gotchas regarding path formats, core config options, auto-imports, etc, etc.
My feeling is that you want complete flexibility, get these problems with layers addressed, then it's a much improved experience for the user, likely a much-improved situation for the codebase, and effectively everything becomes a layer, whether it's one big on in the root, or any other combination you need.

To be honest, my colleagues and many friends around the globe who use Nuxt are totally fine with the current Nuxt folder structure.
Just ask yourself, what would really be the benefit implementing a possible breaking change or more "rules" which some would not follow.
The current system, where you do NOT have dozens of sub-folders is great! I know instantly where everything is. Components is clear, layers, server dir with a few sub-dirs... What would be a not a potential but a REAL benefit changing this with v4 soon?
Please correct if I am wrong, but I just don't see any really improvement by doing that, rather than more downsides and slightly bigger hurdle for new programmers getting used to this.
I would suggest focus on stability, performance and real new features, not wasting everyone's time in learning a new folder structure, while it has no overall benefits, rather than some few individual prefer it one way.

I would suggest focus on stability, performance and real new features, not wasting everyone's time in learning a new folder structure, while it has no overall benefits, rather than some few individual prefer it one way.

@Shooteger the folder structure will be customizable, so you won't need to learn a new structure, you will be able to use your exisitng one. It will be configurable.

@danielroe I think you mentioned the wrong person 😅
Also, I wasn't aware of the performance issues on non-Mac OSes. Does it include Linux too? Or is Windows the only one suffering from it?

@danielroe
Thank you for the clear statement and comment. There was absolutely no offence given. I just thought about if you would "force" the new structure it would waste time learning new (what it would with many, many people).
But as you just stated now, it is optional with automatic fallback and therefore not the case. Thank you very much and  peace 😎

Lots of love, peace, health, and success to the amazing Nuxt team. 💚🔥👏🎉

I hope the new directory structure will bring more raw performance improvements to the various existing javascript runtimes, thanks nuxt team

Where would I place ~/types/index.ts in this new folder structure?

A shared utils folder would be amazing. Would avoid all the re-exporting between server and client folders for sharing code between them.
I hope this clearer separation between client/server would address the issue that the IDE and typecheck command gets confused about what is available where. Right now the .nuxt/types are all mixed up. The IDE will not complain when mistakes happen using auto-imports from the server in client files, and viceversa, neither will typecheck. Those mistakes only blow up on runtime.
I think this was not the case before, but maybe I just noticed it recently.
Layers are amazing btw.

In our monorepo, we have a Nuxt layer-only package (such as ui). Placing components and composables within the app directory feels a bit unconventional.
I have two questions regarding this:

Will the current directory structure be deprecated in the future, meaning it will no longer be auto-detected?
For our ui Nuxt layer, would you recommend placing the directories in rootDir instead of srcDir? Or what would be the best practice considering the future direction of Nuxt UI?

Thank you!

Will the current directory structure be deprecated in the future, meaning it will no longer be auto-detected?

Iirc you can still change back to the original structure by changing the dir config.

A shared utils folder would be amazing. Would avoid all the re-exporting between server and client folders for sharing code between them.
I hope this clearer separation between client/server would address the issue that the IDE and typecheck command gets confused about what is available where. Right now the .nuxt/types are all mixed up. The IDE will not complain when mistakes happen using auto-imports from the server in client files, and viceversa, neither will typecheck. Those mistakes only blow up on runtime.
I think this was not the case before, but maybe I just noticed it recently.
Layers are amazing btw.

Thanks for suggestion, this was indeed missing and now has been added in v 3.14. Thanks @danielroe

A question regarding migration:
Scenario: (say) in my Nuxt 3 project, I configure srcDir: 'app/' already (horrible structure, I know). This means that layers, modules, server, etc, will be in the app/ directory (based on Nuxt 3 docs), correct? To move to the default Nuxt 4 structure, I would move the non-app directories out of app/ back to rootDir, right?
If I do wish to continue with the existing structure of everything within app/, I would additionally need to point dir.modules to app/modules/, right?
I'm a little confused between the notion of a srcDir and an "app" dir. All directories are related to project source. Some directories are related to project's app source; tying app/ as srcDir may be misleading me in this case, while I would expect a large project with this structure:
-| rootDir/
---| node_modules/
---| .config/
---| nuxt.config.ts
---| package.json
---| pnpm-lock.yaml
---| .husky/
---| .eslint.config.js
---| README.md
---| .gitignore
---| src/           # source directory
------| server/
------| modules/
------| content/
------| shared/
------| app/        # app directory
---------| assets/
---------| components/
---------| layouts/
---------| middleware/
---------| pages/
---------| plugins/
---------| public/
---------| store/
---------| app.config.ts
---------| app.vue
---------| error.vue

So the app/ (app) directory is a supplementing separation of the src/ (source) directory. Would my thinking be wrong?

the app/ name is the new srcDir. you are right in terms of how you would move your files/directories...
srcDir ... maybe likely now be thought of as vueSrcDir - we could consider renaming it with backwards compatibility at some point

srcDir ... maybe likely now be thought of as vueSrcDir - we could consider renaming it with backwards compatibility at some point

I mean... why not appDir? Considering that we already have rootDir, serverDir, srcDir?
Also, wouldn't this be a breaking change after Nuxt 4 gets released? Personally I do like the new Nuxt 4 default folder structure, but having optionally the @ineshbose suggested structure in bigger projects could be indeed useful.

I mean... why not appDir? Considering that we already have rootDir, serverDir, srcDir?

I was also going to point out that there are some configuration/schema properties of Nuxt that could also be confusing - there's dir.app dir.modules, then appDir (which I missed is internal) and modulesDir (more for externals). We could take v4 as an opportunity to make it clearer? My thinking is
rootDir,
srcDir,
dir: {
  app: string | {
      pages: string
      plugins: string
      ...
      rootDir: string
  }
  modules: string
  server: string
  etc
}
_internal: { // a bit explicit about private schema props
  modulesDir,
}

hold up, @ineshbose rootDir and dir.app.rootDir? 🤣

hold up, @ineshbose rootDir and dir.app.rootDir? 🤣

badly named probably!
root rootDir is project's rootDir
dir.app as string is app/, or dir.app.rootDir would be app/ if I want to also configure, say, pages to be dir.app.pages to be routes/ for eg, so thats resolved to app/routes/


Library Management System Source Code

I want to add my library management system project. Pls assign this this to  me.

Hi there!
I am the Mentor of this project .
Although this repo is not part of Hacktoberfest 2024, we have some great alternatives for you. Welcome to SkillShow, a repository focused on skill enhancement!
Guidelines:
Please adhere to the existing guidelines.
No additional rules, thanks!
Check it out here: SkillShow.
Note: Start by creating an issue. Once it’s assigned to you, feel free to open a pull request (PR). Directly opening a PR will lead to an invalid label.
Looking forward to your contributions!


Fix Cypress Cloud integration to enable test run recording

After merging https://github.com/remix-austin/remixaustin-com/pull/26 to enable Cypress testing, we're getting an error when attempting to record test runs to Cypress Cloud:
The Record Key is missing. Your CI provider is likely not passing private environment variables to builds from forks.

GitHub integration is setup for the Cypress Dashboard Project
Secrets for CYPRESS_PROJECT_ID & CYPRESS_RECORD_KEY were added to the repo
Cypress tests currently complete with no error code in PRs, but when merging to main, the error code breaks the deploy workflow.

In the meantime, the workflow step has record: false to allow deploys to work.
https://github.com/remix-austin/remixaustin-com/blob/main/.github/workflows/development.yml#L115

Closing at "won't do", as we've implemented Playwright instead.


Code coverage should be analyzed via sonarcloud

The automatic sonarcloud analysis should be upgraded to support code coverage.

Added code coverage is being reported in SonarCloud.


[bug] DOMContentLoaded not triggered in production

Describe the bug
DOMContentLoaded not triggered in production
Reproduction

open https://github.com/4tst/tauri-plugins/tree/bug/DOMContentLoaded
follow README.md

Expected behavior
No response
Platform and versions
windows11
1.3.0

Stack trace
No response
Additional context
No response

From my testing with your repo it looks like it is fired but way too early for the console to be attached already so the console.log gets lost. If i sent it to the rust side (after disabling the windows_subsystem stuff in main.rs so i could print something to the native terminal) i was able to receive the message just fine.
main.rs file for you to confirm:
/* #![cfg_attr(
    all(not(debug_assertions), target_os = "windows"),
    windows_subsystem = "windows"
)] */

use tauri::Manager;

#[tauri::command]
fn print(msg: String) -> Result<(), ()> {
    dbg!(msg);
    Ok(())
}

fn main() {
    tauri::Builder::default()
        .setup(|app| {
            #[cfg(debug_assertions)] // only include this code on debug builds
            {
                let window = app.get_window("main").unwrap();
                window.open_devtools();
                // window.close_devtools();
            }
            Ok(())
        })
        .invoke_handler(tauri::generate_handler![print])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

then in js do invoke('print', { msg: 'DOMContentLoaded' }) in your DOMContentLoaded event handler.


don't use error message but check returncode of the command

using return code to find out if a folder is under git version control.

Hello @olivierverdier
Could you please merge this to fix annoying prompt in each folder on the shell?

The problem is that the git symbolic-ref HEAD command also found the branch name and that is used later. so either I have to add another command to run or figure out how to do this with one command without breaking detached heads.


[5.8] Date validator rules with attribute parameter trigger warnings

Configuration:

Laravel Version: 5.8
PHP Version: 7.2.15

Description:
Using date related validation rules with an attribute name as the parameter logs a silent warning when using NewRelic. Distorting the erroneous amount of requests in NewRelic for Laravel applications using these validation rules.
Code triggering warning (line 249);
https://github.com/laravel/framework/blob/d0a33d4a398f2bd23c2689aac473a3453ece76cc/src/Illuminate/Validation/Concerns/ValidatesAttributes.php#L242-L253
Warning triggered;
E_WARNING: DateTime::__construct(): Failed to parse time string (destination_arrival_date) at position 0 (d): The timezone could not be found in the database
Affected validation rules;

after
after_or_equal
before
before_or_equal
date_equals

Steps To Reproduce:
Any validator using a date rule and another attribute to compare its value to would trigger this warning. Example;
$validatedData = $request->validate([
    'compare_date' => 'date',
    'after_date' => 'after:compare_date',
]);

Suggested solution:
Replace the new DateTime by date_create which should be an alias for the DateTime constructor but silences these kinds of warnings. Since the code catches any thrown exceptions this seems like a valid step that could be taken.
Would love to create a PR for this change if you agree. Let me know!

Can you share sample request payload?

I'll need more info and/or code to debug this further. Please post relevant code like models, jobs, commands, notifications, events, listeners, controller methods, routes, etc. You may use https://paste.laravel.io to post larger snippets or just reply with shorter code snippets. Thanks!

@driesvints Unfortunately, there is not a lot to share. It's a warning which gets caught by the NewRelic PHP agent which runs on the server side. I've created a controller which reproduces this on my containers and added the error and partial trace I receive in NewRelic.
Discovered a little more while building the examples. The rules alone did not trigger the warning but when used together with date_format they do. I try to do some more testing this afternoon.
Gist; https://gist.github.com/LarsGrevelink/c3e0da3f1642b05ff7a185879a19032a

Closing this issue because it's inactive, already solved, old or not relevant anymore. Feel free to reply if you're still experiencing this issue.

Hi Dries,
Indeed, we patched it at our side but it’s not resolved in the framework. I didn’t receive any response on the case that I provided. I can deliver you the patch file we’re using in order to show the actual code change.
Let me know,
L

@Lars can you share the code here?

Hi @driesvints!
These are the contents of the patch file we use to patch the ValidatesAttributes.php in our current production environment which does no longer report the errors.
--- vendor/illuminate/validation/Concerns/ValidatesAttributes.php	2019-03-12 08:12:25.000000000 +0000
+++ vendor/illuminate/validation/Concerns/ValidatesAttributes.patch	2019-03-13 17:25:26.000000000 +0000
@@ -246,7 +246,7 @@
                 return Date::parse($value);
             }

-            return new DateTime($value);
+            return date_create($value);
         } catch (Exception $e) {
         }
     }

The samples can still be found here; https://gist.github.com/LarsGrevelink/c3e0da3f1642b05ff7a185879a19032a

Atm I don't have too much time to deep dive into this so appreciating any help with figuring out if this is a bug or not.

Confirmed here too.
The problem is really a PHP bug, check here: https://bugs.php.net/bug.php?id=67881&edit=1
If we have a rule that uses an attribute eg: after_or_equal:publish_date then ValidatesAttributes does this process to decide whether we are dealing with a date or an attribute.
        if (! $secondDate = $this->getDateTimeWithOptionalFormat($format, $second)) {
            $secondDate = $this->getDateTimeWithOptionalFormat($format, $this->getValue($second));
        }

What it then does is try and create a new DateTime via new DateTime('publish_date') and if that throws an exception, then it assumes we are dealing with an attribute.
The problem here is that due to the above PHP bug, when DateTime throws an exception then it also logs a warning which can't be supressed.
So patch above is a good solution since it avoids the PHP bug although it's technically not a LAravel bug.

Thanks @rossriley for finding the root cause!
@driesvints with the above explanation I would like to create a PR applying the exact patch we currently use in production. It does not seem to have a notable implication on performance and we've not seen any additional errors caused by applying this fix. Good to go on your part?

Thanks @rossriley for finding the root cause!
@driesvints with the above explanation I would like to create a PR applying the exact patch we currently use in production. It does not seem to have a notable implication on performance and we've not seen any additional errors caused by applying this fix. Good to go on your part?

Hello I have same issue.

How can I ignore this issue from newrelic? Because I can not see this warning in local development environment. I can just see this error in newrelic. @LarsGrevelink
I debugged this problem. This warning coming from ValidatesAttributes.php.
When I use validation just like this

This value is for example startDate and there is no type as startDate in Datetime class.
This is a problem but there is try catch. this function which is getDateTimeWithOptionalFormat returns empty when there is error.

This method get data from Input values according to parameter. This is not best practice. @driesvints

Created a pull request which fixes the issue.
@aslanahmet If you want to fix this in the meanwhile I'd suggest you use a similar way to patch the file as I talked about in an earlier comment. Ideally, I would suggest to hold on a little longer and wait for the PR to be merged.

PR is merged; I'm closing the issue.
Thanks, to everyone who took the effort to look into this issue.

@LarsGrevelink thanks for reporting and fixing!


Setup action to check for code formatting

What does this changes
Since pep8speaks has stopped working (temporary?), we may need an alternative way of checking code format for a meanwhile.
What was wrong
Resolve #744
How this fixes it

Format all code according to CONTRIBUTION.md
Setup black formatted as Github action workflow This code will throw error (stop Github workflow) as default if incorrect format detected

Fixes #...
Your checklist for this pull request
🚨Please review the guidelines for contributing to this repository.

[x] Passed code styles and structures
[x] Passed code linting checks and unit test

How I tested this PR
I used Act to test Github actions locally

Prerequisite: docker
Install Act curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash
Run ./bin/act -W .github/workflows/lint.yml
Check if the workflow runs successfully

Should --line-length still be 79? Or should I set it to 127 to match with flake8 config?

Coverage decreased (-0.05%) to 94.237% when pulling e07673f2279dcbfec8394f7ec141a8dfcabf5a20 on new5558:style/format into 97b1a5137c3145f3a176dd15800f4ffd41051dd9 on PyThaiNLP:dev.

Should --line-length still be 79? Or should I set it to 127 to match with flake8 config?

I found line length 79 that It is not enough for write text processing function but I don't sure that what the line length should be, so It should still be 79 until found the line length that enough for write text processing function.


Is there any plan "Yodel" opensource/included?

In this essay there is a system “Yodel", will it be opensource or included in this project?
https://www.toutiao.com/article/7178732909950747191/?app=news_article&timestamp=1672022923&use_new_style=1&req_id=20221226104842F95548F164929DA9D270&group_id=7178732909950747191&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share&share_token=16e72473-88be-4f05-a0ef-9a937b568400&source=m_redirect&wid=1678417976245

we don't have a specific timeline to make Yodel open-sourced for now, but we have plans to do it in the future indeed.

+1 期待Yodel开源


remove min/max zoom from baseclass attribute

ref #509
This PR removes minzoom and maxzoom from the SpatialMixin base class (thus on other classes). The main effect is that now the user can't set min/max zoom as attribute in COGReader.
For STACReader (multibase) and MultiBandReader those attributes are still available.

This PR should save couple ms when opening a new file (avoid PROJ operations).

thanks @geospatial-jeff I've split the zoom calculation method and also confirmed that it doesn't cost us much because rasterio/gdal seem to do some caching so we pay the price of calculate_default_transform only once


Update index.md

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

E2E_Te/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

E2E_Te/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/TestE2E/E2E_Te, working directory: W:\ecd5-s, target branch: master, target branch commit: 7993a6f1f2f02636cf587d4c1b1f2193066f286b, source branch: Test, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/TestE2E/E2E_Te, working directory: W:\szb1-s, target branch: master, target branch commit: 7993a6f1f2f02636cf587d4c1b1f2193066f286b, source branch: Test, source branch commit: .

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


AppBar shows Back Button when EndDrawer is open

Steps to Reproduce

Add an appBar with a title and endDrawer to a Scaffold in a LTR language (English in my case).
Observe the AppBar. No back button.
Open the endDrawer
Observe the AppBar. Back Button appears.

Not an end of the world bug by any means, but overall it looks a bit weird / causes a visual flash in the UI as the Drawer animates in smoothly and then the back button pops in all of a sudden. In addition, it can't be tapped because it's underneath the Drawer layer, so it appears to lack functional value for being there.
Might make sense to simply not show the back button in response to a Drawer being opened? Not sure what other ramifications that would have...
Thanks for your time :)
Screenshot

Flutter Doctor
[✓] Flutter (on Mac OS X 10.13.2 17C88, locale en-US, channel alpha)
    • Flutter at /Users/phillywiggins/lab/flutter
    • Framework revision 8f65fec5f5 (3 days ago), 2017-12-12 09:50:14 -0800
    • Engine revision edaecdc8b8
    • Tools Dart version 1.25.0-dev.11.0
    • Engine Dart version 2.0.0-edge.d8ae797298c3a6cf8dc9f4558707bd2672224d3e

[✓] Android toolchain - develop for Android devices (Android SDK 26.0.2)
    • Android SDK at /Users/phillywiggins/Library/Android/sdk
    • Android NDK at /Users/phillywiggins/Library/Android/sdk/ndk-bundle
    • Platform android-26, build-tools 26.0.2
    • ANDROID_HOME = /Users/phillywiggins/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b08)

[✓] iOS toolchain - develop for iOS devices (Xcode 9.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.2, Build version 9C40b
    • ios-deploy 1.9.2
    • CocoaPods version 1.3.1

[✓] Android Studio (version 3.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b08)

[✓] IntelliJ IDEA Community Edition (version 2017.3.1)
    • Flutter plugin version 20.0.3
    • Dart plugin version 173.3942.31

[✓] Connected devices
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 8.0.0 (API 26) (emulator)

Hah, that's funny. The back button is appearing because you can now go back (to close the drawer!).
We should have the back button be more aware of where it sits on the history stack so that it ignores routes put on top of it (I bet the same thing happens if you show a dialog).

i'm also have same experience, but it's done by setting up automaticallyImplyLeading to false in AppBar.

Persists with current master 1.21.0-6.0.pre.129
Back Button is shown when Drawer is open (isn't shown when dialog is open).

code sample
import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: MyApp()));

class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  @override
  Widget build(BuildContext context) {
    return SafeArea(
      child: Scaffold(
        appBar: AppBar(
          title: Text('title'),
        ),
        endDrawer: Drawer(
          child: Center(child: Text('drawer')),
        ),
        body: Center(
          child: RaisedButton(
            child: Text('show dialog'),
            onPressed: () {
              showDialog(
                  context: context,
                  builder: (BuildContext context){
                    return AlertDialog(
                      title: Text("Alert Dialog"),
                      content: Text("Dialog Content"),
                    );
                  }
              );
            },
          ),
        ),
      ),
    );
  }
}

flutter doctor -v
[✓] Flutter (Channel master, 1.21.0-6.0.pre.129, on Mac OS X 10.15.6 19G73, locale en-GB)
    • Flutter version 1.21.0-6.0.pre.129 at /Users/nevercode/dev/flutter
    • Framework revision 30aef0a3b9 (14 hours ago), 2020-07-30 14:20:21 -0700
    • Engine revision a9910e409c
    • Dart version 2.10.0 (build 2.10.0-1.0.dev 24c7666def)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/nevercode/Library/Android/sdk
    • Platform android-29, build-tools 29.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.6)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.6, Build version 11E708
    • CocoaPods version 1.9.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.47.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.12.2

[✓] Connected device (6 available)
    • Redmi Note 7 (mobile)       • 6345c469                                 • android-arm64  • Android 9 (API 28)
    • Nevercode’s iPhone (mobile) • b668e524315069f3db3661ac11ff1f66afafebdb • ios            • iOS 13.6
    • iPhone 11 Pro Max (mobile)  • 55C8466B-5367-492B-8EFE-EC45D980571F     • ios            • com.apple.CoreSimulator.SimRuntime.iOS-13-6 (simulator)
    • macOS (desktop)             • macos                                    • darwin-x64     • Mac OS X 10.15.6 19G73
    • Web Server (web)            • web-server                               • web-javascript • Flutter Tools
    • Chrome (web)                • chrome                                   • web-javascript • Google Chrome 84.0.4147.105

• No issues found!

@Hixie PR fixing this issue was merged. I think we can close this

Fixed by https://github.com/flutter/flutter/pull/63272

Closing as fixed bu https://github.com/flutter/flutter/pull/63272.

Closing as fixed by https://github.com/flutter/flutter/pull/63272

Simple Way to fix that problem
-> Add Appbar Following Code
  automaticallyImplyLeading: false,
Solve Your Problems


Error: from torch.tensor import Tensor with PyTorch 1.9

I know that the requirements.txt suggests using PyTorch 1.7.0, but just to let you know that there is an issue when using an advanced version like 1.9.
To reproduce: run python run_downstream.py -m train -n test -u fbank -d example with PyTorch 1.9 installed.
Traceback (most recent call last):
  File "run_downstream.py", line 16, in <module>
    from downstream.runner import Runner
  File "/mrnas02/internal/wenchin-h/Experiments/s3prl/downstream/runner.py", line 20, in <module>
    from upstream.interfaces import Featurizer
  File "/mrnas02/internal/wenchin-h/Experiments/s3prl/upstream/interfaces.py", line 8, in <module>
    from torch.tensor import Tensor
ModuleNotFoundError: No module named 'torch.tensor'

The same line also appears in the following files:
./upstream/example/expert.py
./upstream/mockingjay/expert.py
./upstream/pase/hubconf.py
./upstream/wav2vec2_hug/expert.py

I think we import this class only to specify the type of the arguments in the functions, right?
If so, how about from torch import Tensor? I tried and it worked in both PyTorch 1.7 and 1.9. Haven't tried 1.8 yet.

Thanks for reporting!


Fix parser

Using no arguments results in wtpython opening with an index error. Putting a script name that doesn't exist results in wtpython opening with a FileNotFoundError. Also, the help popup no longer shows the script argument.

Fixing the FileNotFoundError is kind of annoying the way the arguments are parsed now. I have the following proposal:

We add back script as a positional argument into the argument parser
Use this to check if the script exists, otherwise give an appropriate error
Then manually add the script name into sys.argv when we are running the code (for sake of correctness).

So something along the lines of:
parser = argparse.ArgumentParser(...)
parser.add_argument('script', help='script name')
...
flags, rest = parser.parse_known_args()

...

if not os.path.isfile(flags['script']):
    exit(1)

...
sys.argv = [flags['script'], *rest]
runpy.run_path(flags['script'])

@briancohan You were last were on this, thoughts?


qat: document kerneldrv mode and build instructions

-mode kerneldrv comes with no documentation. This patch adds few
notes about it and instructions how to get it build if a user chooses
to have it enabled.
Closes: #197
Signed-off-by: Mikko Ylinen<EMAIL_ADDRESS>

Thanks!


Update monitoring and logging addon with template generation

Problem:

https://github.com/harvester/harvester/issues/6289
Solution:

Update template generation
Check image tag

Related Issue:
https://github.com/harvester/harvester/issues/6289
Test plan:

Peer PR: https://github.com/harvester/addons/pull/14 those 2 PRs can be merged independently.
These additional ENVs will be appended to the version_info file when building, no matter addon side PR https://github.com/harvester/addons/pull/14 is merged or not.
RANCHER_LOGGING_CHART_VERSION="103.1.0+up4.4.0"
RANCHER_MONITORING_CHART_VERSION="103.1.1+up45.31.1"
HARVESTER_EVENTROUTER_FULL_TAG="rancher/harvester-eventrouter:v0.3.1"

build output:
logging chart version is updated to 103.1.0+up4.4.0
monitoring chart version is updated to 103.1.1+up45.31.1
harvester-eventrouter image tag is updated to rancher/harvester-eventrouter:v0.3.1
#!/bin/bash
VM_IMPORT_CONTROLLER_CHART_VERSION="0.4.0"
VM_IMPORT_CONTROLLER_IMAGE="rancher/harvester-vm-import-controller:v0.4.0"
PCIDEVICES_CONTROLLER_CHART_VERSION="0.4.0"
PCIDEVICES_CONTROLLER_IMAGE="rancher/harvester-pcidevices:v0.4.0"
HARVESTER_SEEDER_CHART_VERSION="0.3.0"
HARVESTER_SEEDER_IMAGE="rancher/harvester-seeder:v0.3.0"
NVIDIA_DRIVER_RUNTIME_CHART_VERSION="0.1.1"
RANCHER_LOGGING_CHART_VERSION="103.1.0+up4.4.0"
RANCHER_MONITORING_CHART_VERSION="103.1.1+up45.31.1"
HARVESTER_EVENTROUTER_FULL_TAG="rancher/harvester-eventrouter:v0.3.1"
the rendered addon template
      repo: http://harvester-cluster-repo.cattle-system.svc/charts
      version: "0.4.0"
      chart: harvester-vm-import-controller
--
      repo: http://harvester-cluster-repo.cattle-system.svc/charts
      version: "0.4.0"
      chart: harvester-pcidevices-controller
--
      repo: http://harvester-cluster-repo.cattle-system.svc/charts
      version: "103.1.0+up4.4.0"
      chart: rancher-logging
--
      repo: http://harvester-cluster-repo.cattle-system.svc/charts
      version: "103.1.1+up45.31.1"
      chart: rancher-monitoring
--
      repo: http://harvester-cluster-repo.cattle-system.svc/charts
      version: "0.3.0"
      chart: harvester-seeder
--
      repo: http://harvester-cluster-repo.cattle-system.svc/charts
      version: "0.1.1"
      chart: nvidia-driver-runtime

@tserong A good question, why not use addon as a single source:
There are some patches on path https://github.com/harvester/harvester-installer/tree/master/pkg/config/templates/patch, which are related to monitoring and logging. And the monitoring and logging ENVs are also used in some other files.
package-harvester-os:source ${SCRIPTS_DIR}/version-monitoring
build:source ${SCRIPTS_DIR}/version-monitoring

I will spend another time to finally move them all to a single place if possible. thanks.

@mergifyio backport v1.4


Add section for App Store Encryption Export Regulations

Apple developers must affirm whether their app uses encryption when submitting their app to the App Store "—including any third-party libraries it links against—".

Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.

Source: Apple Developer - Article - Complying with Encryption Export Regulations
Can a section be added to the documentation that provides the affirmation to comply with the App Store Encryption Export Regulations for app developers that link the AppCenter SDK(s) in their apps please?
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: c043814c-66b5-4656-087e-0cbcab8d2d27
Version Independent ID: 4edd3772-2eab-083c-2756-27266fce999d
Content: Visual Studio App Center Security and Compliance - Visual Studio App Center
Content Source: docs/general/app-center-security.md
Service: vs-appcenter
Sub-service: app-center-general
GitHub Login: @lucen-ms
Microsoft Alias: lucen

Hello @antonys1 , thank you for reaching out!
We only use Apple's OS built-in encryption CommonCryptor, and save the encrypted file into the App's folder. The encrypted data is saved within an event and error logs until it can be sent over the internet. Before sending over the internet it gets decrypted and then it is sent over the internet with https request using NSURLSession.
Note, the only thing which gets encrypted is a transmission token, see:
https://github.com/microsoft/appcenter-sdk-apple/blob/2214f9ee2476f28af64cb38359defe59e85197a1/AppCenterCrashes/AppCenterCrashes/MSACCrashes.mm#L579
https://github.com/microsoft/appcenter-sdk-apple/blob/2214f9ee2476f28af64cb38359defe59e85197a1/AppCenter/AppCenter/Internals/Storage/MSACLogDBStorage.m#L73
The transmission target API is not documented and thus isn't officially supported. I believe you don't use this API. In such case, encryption is not happening on the AppCenter SDK side.
If you are not sure if you should specify if your app is using encryption I recommend you to reach out to Apple support team and consult on your specific case.

Thank you @DmitriyKirakosyan.


Revertable functions

Currently, changes applied to a jimp object are not revertable. If you want to extract multiple sections from an image or something alike, this might help:
Jimp.prototype.save = function (cb) {
    this.oldBitmap = {}
    this.oldBitmap.height = this.bitmap.height + 0;
    this.oldBitmap.width = this.bitmap.width + 0;
    this.oldBitmap.data = new Buffer(this.bitmap.data);

    if (isNodePattern(cb)) return cb.call(this, null, this);
    else return this;
};

Jimp.prototype.revert = function (cb) {
    console.log(this)
    this.bitmap = _.extend(this.oldBitmap, {});

    if (isNodePattern(cb)) return cb.call(this, null, this);
    else return this;
};

Of course one has to keep an eye on the memory...

You can use the clone method to create "save points", as follows:
var image = new Jimp("./path/to/image.jpg", function (err, image) {
    var original = image.clone(); // clone "image"
    image.greyscale(); // makes "image" grey scale but "original" is unchanged
    image = original; // revert to "original"
});

You can also use the clone method to make changes without affecting the original:
var image = new Jimp("./path/to/image.jpg", function (err, image) {
    var alteredImage = image.clone().greyscale().invert(); // original "image" is unaffected
});


QScintilla support

Updates: #5
Adds bindings for QScintilla. This library is GPL/Commercial only :warning: and is put in a new restricted-extras section.
Blocker:
char* arguments were so far projected as string when going Go->C++, but not vice versa. The types need to match in order for signal/slot argument marshaling to work.
This PR changes char* returns to convert to Go strings for C++->Go as well. However, this makes QByteArray even more useless as the internal .Data() pointer returned a char* that is now no longer null safe.
Possible options to fix:

Allowlist/blocklist on a class by class basis
Customize QByteArray.Data() method to return void* or unsafe.Pointer
Reproject QByteArray as []byte (#20)

I'm not an expert on Qt or C++, but is there any chance for the binding to use Scintilla component (https://www.scintilla.org) which has permissive license directly? I noticed in their source there are Qt components (ScintillaEditBase and ScintillaEdit).

@jamalsa That's really interesting, thank you for pointing it out. ScintillaEdit builds cleanly for me, it seems like a less featureful binding than QScintilla (no signals at all) but the license is definitely preferable.
Let's add both,


TLS error handling broken

Hello,
currently it seems like TLS errors aren't handled in any way.
If I connect to a host with invalid certificate Perform() returns OK error code but the resulting document is empty.
CurlEasy.ErrorBuffer is also always empty.
It seems like it's never initialized and the set method looks like it's not correctly used.
https://curl.haxx.se/libcurl/c/CURLOPT_ERRORBUFFER.html

Same error here. I tweaked the debug function a little, and here is the output:
Connected to www.coinexchange.io (<IP_ADDRESS>) port 443 (#0)
ALPN, offering http/1.1
Cipher selection: ALL
successfully set certificate verify locations:
  CAfile: curl-ca-bundle.crt
  CApath: none
SslDataOut: 5 bytes data
TLSv1.2 (OUT), TLS handshake, Client hello (1):
SslDataOut: 512 bytes data
SslDataIn: 5 bytes data
TLSv1.2 (IN), TLS handshake, Server hello (2):
SslDataIn: 104 bytes data
SslDataIn: 5 bytes data
TLSv1.2 (IN), TLS handshake, Certificate (11):
SslDataIn: 4330 bytes data
SslDataIn: 5 bytes data
TLSv1.2 (IN), TLS handshake, Server key exchange (12):
SslDataIn: 333 bytes data
SslDataIn: 5 bytes data
TLSv1.2 (IN), TLS handshake, Server finished (14):
SslDataIn: 4 bytes data
SslDataOut: 5 bytes data
TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
SslDataOut: 70 bytes data
SslDataOut: 5 bytes data
TLSv1.2 (OUT), TLS change cipher, Client hello (1):
SslDataOut: 1 bytes data
SslDataOut: 5 bytes data
TLSv1.2 (OUT), TLS handshake, Finished (20):
SslDataOut: 16 bytes data
SslDataIn: 5 bytes data
SslDataIn: 5 bytes data
TLSv1.2 (IN), TLS handshake, Finished (20):
SslDataIn: 16 bytes data
SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
ALPN, server accepted to use http/1.1
Server certificate:
 subject: OU=Domain Control Validated; OU=PositiveSSL; CN=coinexchange.io
 start date: Mar  3 00:00:00 2017 GMT
 expire date: Mar  5 23:59:59 2019 GMT
 subjectAltName: host "www.coinexchange.io" matched cert's "www.coinexchange.io"
 issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO
RSA Domain Validation Secure Server CA
 SSL certificate verify ok.
SslDataOut: 5 bytes data
HeaderOut: 75 bytes data
SslDataIn: 5 bytes data
TLSv1.2 (IN), TLS alert, Client hello (1):
SslDataIn: 2 bytes data
Curl_http_done: called premature == 0
Empty reply from server
Connection #0 to host www.coinexchange.io left intact

this is the output for same site from git mingw console:
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [109 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4330 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*        subject: OU=Domain Control Validated; OU=PositiveSSL; CN=coinexchange.io
*        start date: Mar  3 00:00:00 2017 GMT
*        expire date: Mar  5 23:59:59 2019 GMT
*        subjectAltName: www.coinexchange.io matched
*        issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
*        SSL certificate verify ok.
} [5 bytes data]
> GET /api/v1/getmarkets HTTP/1.1
> Host: www.coinexchange.io
> User-Agent: curl/7.46.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Server: PipeGuard
< Date: Wed, 08 Mar 2017 13:11:55 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< Cache-Control: no-cache
< Pragma: public
< Cache-Control: public, must-revalidate, proxy-revalidate
<
{ [16103 bytes data]
100 50483    0 50483    0     0  95250      0 --:--:-- --:--:-- --:--:--  102k
* Connection #0 to host www.coinexchange.io left intact


[SR-14050][Sema] Removing check on subtype validation at matchFunctionRepresentations

For what I could see and test seems is just fine to remove this check and just adding a bit more information. Most relations between function types are handled by conversions.
I'm running the tests to make sure, but let me know if you think there are some situation where the check still be necessary.

Resolves SR-14050.

@swift-ci Please test source compatibility

@swift-ci Please test source compatibility

@swift-ci Please test source compatibility Release

@swift-ci Please test source compatibility Release

@swift-ci smoke test and merge

@swift-ci smoke test and merge


GitHub Actions workflow is disabled, no more shiba posted 😭

Could you re-enable it? https://github.com/chiubaca/shiba-every-hour/actions/workflows/post-shibe.yml
Maybe something like this could help: https://github.com/marketplace/actions/keepalive-workflow

Thanks for letting me know! I re-enable it this morning so shibe bot should be back .
Will look into the keep alive workflow👍


Stand alone code produces incorrectly formated .csv file.

The code does not separate the files as it is creating the csv file correctly.
It mashes them up into 1 field of content that contains all the articles uploaded.
and does not separate the articles into rows with the required fields in it.

Issue Fixed.


Feature Request : add the sTable field to the TDengine Plugin ？

STable in TDengine has the ability to create tables automatically. Using sTable templates, you can create a table automatically without having to create a database before inserting data.

Could you add a sTable option in the future? This will enable the database to build tables without additional connections.Thank you very much！

Check the doc to see if it meets your requirement: https://ekuiper.org/docs/zh/latest/rules/sinks/plugin/tdengine.html#规则-actions-说明


Add support for 128x64 KS0108 / ST7920 LCD

Ebay listing: http://www.ebay.co.uk/itm/302089090235
Datasheet: ST7920.pdf

Refs:

http://www.filipeflop.com/pd-6b7ea-display-lcd-grafico-128x64.html
http://q61.org/en/chibimo/build/

Implementation notes
Code [WIP] on branch: feature/st7920.
Documentation preview: http://luma-lcd.readthedocs.io/en/feature-st7920/

@rm-hull can you open a PR for that branch so people could start testing/take a look?

Hi,
I have a ST7920 LCD. If you need any testing, let me know as there is no python library with i2c for this device

Is there any news about the st7920 support?


[APIM-4.4.0] Upgrade swagger-parser version

Purpose
This PR Upgrades the swagger-parser version to 2.1.22.
Related PRs:
Orbit bundles: https://github.com/wso2/orbit/pull/1133
carbon-mediation PR: https://github.com/wso2/carbon-mediation/pull/1733
carbon-apimgt PR: https://github.com/wso2/carbon-apimgt/pull/12586

Closing this PR as the changes have already been merged with another PR.


Hub75 drivers question

Hi,
I've bought the interstate75 w board and I've started to play with it.
I've looked at the source code of the Hub75 driver and I wasn't able to figure out why in the hub75.cpp - inside Hub75::start (at line 150):
// Same handler for both DMA channels
irq_set_exclusive_handler(DMA_IRQ_0, handler);
irq_set_exclusive_handler(DMA_IRQ_1, handler);

dma_channel_set_irq0_enabled(dma_channel, true);

irq_set_enabled(pio_get_dreq(pio, sm_data, true), true);
irq_set_enabled(DMA_IRQ_0, true);

the function "irq_set_exclusive_handler" is called for DMA_IRQ_1 but only for DMA_IRQ_0 the function "irq_set_enabled" is called.
However, it gets then disabled inside Hub75::stop (at line 169):
irq_set_enabled(DMA_IRQ_0, false);
irq_set_enabled(DMA_IRQ_1, false);
irq_set_enabled(pio_get_dreq(pio, sm_data, true), false);

Is it really needed to set an exclusive handler for DMA_IRQ_1?

Might be a vestigial holdout from an attempt at chained DMA, but either way it looks superfluous.

@Gadgetoid Thanks a lot for confirming that. I'll create a pull request soon to remove the unnecessary code.


Fail to enable sriov, status = fffffffb

Hi All,
I'm trying to set up an AMD Firepro 7150 in proxmox 5.3-11 (which is up to date debian stretch) and I'm getting the following issue when running modprobe gim
[Fri Mar  1 12:31:49 2019] gim info:(enable_sriov:299) Enable SRIOV
[Fri Mar  1 12:31:49 2019] gim info:(enable_sriov:300) Enable SRIOV vfs count = 16
[Fri Mar  1 12:31:49 2019] pci 0000:61:02.0: [1002:692f] type 7f class 0xffffff
[Fri Mar  1 12:31:49 2019] pci 0000:61:02.0: unknown header type 7f, ignoring device
[Fri Mar  1 12:31:50 2019] gim error:(enable_sriov:311) Fail to enable sriov, status = fffffffb
[Fri Mar  1 12:31:50 2019] gim error:(set_new_adapter:668) Failed to properly enable SRIOV
[Fri Mar  1 12:31:50 2019] gim info:(gim_probe:91) AMD GIM probe: pf_count = 1
Hardware wise I am using an ASRock EPYCD8-2T which has an AMD EPYC 7351P processor.
In the BIOS, I have IOMMU, SR-IOV and ACS enabled.
Can anyone please advise why I might be having this issue? Or is there anything I can try?
Thank you!
Mark

Could you check if ARI is enabled in BIOS?
What is the kernel version?

Hi Vignesh,
Kernel is 4.18
There is no option for ARI in the bios that I can find.
Thanks,
Mark

lspci seems to show the compatibility though:
42:00.0 0300: 1002:6929 (prog-if 00 [VGA controller])
Subsystem: 1849:6929
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 5
NUMA node: 2
Region 0: Memory at fce0000000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at fcf4000000 (64-bit, prefetchable) [size=2M]
Region 4: I/O ports at 3000 [size=256]
Region 5: Memory at eb400000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at eb440000 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete+, EqualizationPhase1+
                         EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest-
        Capabilities: [a0] MSI: Enable- Count=1/4 Maskable+ 64bit+
                Address:<PHONE_NUMBER>000000  Data: 0000
                Masking: 00000000  Pending: 00000000
        Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010
Capabilities: [150 v2] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [200 v1] #15
Capabilities: [270 v1] #19
Capabilities: [2b0 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable+, Smallest Translation Unit: 00
Capabilities: [2c0 v1] Page Request Interface (PRI)
PRICtl: Enable- Reset-
PRISta: RF- UPRGI- Stopped+
Page Request Capacity: 00000020, Page Request Allocation: 00000000
Capabilities: [2d0 v1] Process Address Space ID (PASID)
PASIDCap: Exec+ Priv+, Max PASID Width: 10
PASIDCtl: Enable- Exec- Priv-
Capabilities: [328 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 0
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [330 v1] Single Root I/O Virtualization (SR-IOV)
IOVCap: Migration-, Interrupt Message Number: 000
IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy+
IOVSta: Migration-
Initial VFs: 16, Total VFs: 16, Number of VFs: 0, Function Dependency Link: 00
VF offset: 16, stride: 1, Device ID: 692f
Supported Page Size: 00000553, System Page Size: 00000001
Region 0: Memory at 000000fbe0000000 (64-bit, prefetchable)
Region 2: Memory at 000000fcf0000000 (64-bit, prefetchable)
Region 5: Memory at e7400000 (32-bit, non-prefetchable)
VF Migration: offset: 00000000, BIR: 0
Capabilities: [400 v1] Vendor Specific Information: ID=0002 Rev=1 Len=070 <?>
Kernel modules: amdgpu

Oh, try blacklisting amdgpu.

it is blacklisted (lsmod shows it is not loaded)

Hmm, dont see any obvious problems so far.
Any idea where this gets logged from "pci 0000:61:02.0: unknown header type 7f, ignoring device". It doesnt seem to be GIM.

It is when gim is bringing up the card I think. It is the slot the s7150 is in. (sorry it was moved from the slot when it was 61). Updated log with this slot is:
[Mon Mar  4 14:32:19 2019] gim info:(enable_sriov:299) Enable SRIOV
[Mon Mar  4 14:32:19 2019] gim info:(enable_sriov:300) Enable SRIOV vfs count = 16
[Mon Mar  4 14:32:19 2019] pci 0000:42:02.0: [1002:692f] type 7f class 0xffffff
[Mon Mar  4 14:32:19 2019] pci 0000:42:02.0: unknown header type 7f, ignoring device
[Mon Mar  4 14:32:20 2019] gim error:(enable_sriov:311) Fail to enable sriov, status = fffffffb
[Mon Mar  4 14:32:20 2019] gim error:(set_new_adapter:668) Failed to properly enable SRIOV
[Mon Mar  4 14:32:20 2019] gim info:(gim_probe:91) AMD GIM probe: pf_count = 1

The problem was ARI not being enabled. I spoke to ASRock Rack and got an as-yet unreleased BIOS that has the ARI Forwarding option. Enabled it and now all working!
Closing this.


Added more flexibility for related content and combined related links

This component should be used in favour of related links.

Added more control and flexibility for related content
Added documentation and macro options

We should be able to remove the related links component.
Includes multiple row option

Closes #1312

Looks good but all examples seem to have the census theme. Maybe good to have a default

Looks good but all examples seem to have the census theme. Maybe good to have a default

Looks good but all examples seem to have the census theme. Maybe good to have a default

Ok @boxadesign I will get one added.

Looks good but all examples seem to have the census theme. Maybe good to have a default

Ok @boxadesign I will get one added.

 Consider merging related content and related links components

 Consider merging related content and related links components

So can we remove 'related links' component now? It is possible only the Census website using it. Maybe leave it in as we don't know what other services are using is, but we should at least remove component from documentation, so no one uses it going forward. Perhaps put in release notes that this new macro should replace it? Then remove component macro later?

@jrbarnes9 I did want to remove the related links, but wanted to leave it in just in case it was being used elsewhere. In regards to release notes. Good idea. Both @boxadesign and @rmccar do the releases.

So can we remove 'related links' component now? It is possible only the Census website using it. Maybe leave it in as we don't know what other services are using is, but we should at least remove component from documentation, so no one uses it going forward. Perhaps put in release notes that this new macro should replace it? Then remove component macro later?

@jrbarnes9 I did want to remove the related links, but wanted to leave it in just in case it was being used elsewhere. In regards to release notes. Good idea. Both @boxadesign and @rmccar do the releases.


[Launcher] On first start, clicking away doesn't hide launcher

Environment
based on msi on commit 953d835
Steps to reproduce
Only happens every first time running PowerToys

Run PowerToys for the first time
Once cold start finishes, hit alt+space
Clicking away from launcher doesn't hide it

Expected behavior
Clicking away should hide launcher
Actual behavior
Clicking away doesn't hide launcher, only makes the search box out of focus
Screenshots
From @saahmedm

@jyuwono This should also be fixed after focus PR. It was related to that.


on windows 10, devspace keeps exiting and throwing an error after running fine for a few minutes.

What happened?

I run devspace up.
devspace deployed and I'm able to work in the container.
After a few minutes I get kicked out of the container and devspace.

I can use devspace up again to reconnect and keep working, but it keeps happening.

I see this in the logs:
{"level":"error","msg":"Runtime error occurred: error copying from remote stream to local connection: readfrom tcp4 <IP_ADDRESS>:61572-\u003e<IP_ADDRESS>:61574: write tcp4 <IP_ADDRESS>:61572-\u003e<IP_ADDRESS>:61574: wsasend: An established connection was aborted by the software in your host machine.","time":"2018-10-31T11:11:26-05:00"}

What did you expect to happen instead?
I should be able to keep working in the container however long I need to.
How can we reproduce the bug? (as minimally and precisely as possible)
Follow the same steps I did in the "What happened" section.
Local Environment:

Operating System: windows 10
Deployment method: helm

Kubernetes Cluster:

Cloud Provider: Baremetal via Rancher 2.0 rancher
Kubernetes Version: Client Version: v1.10.2 Server version: v1.11.1

Anything else we need to know?
This might be happening during the sync operation, I'm not sure, it seems more stable after everything is synced up. I'll update further when I'm more sure about that.

/kind bug

After doing devspace up a few times to re-enter into the container, I noticed that this stops happening.
So I believe this is happening for some reason during the sync process, when there is a large volume of files to sync.

@KaelBaldwin I think we need more information to reproduce this issue, as it does not happen currently on our machines. I'm not completely sure where this error originates from in the source code. Is there any error in the sync.log when this happens? Is there a fatal message in the console?

@FabianKramm No fatal message or anything in the console, other than I'm suddenly disconnected from the container. The error that was in the error.log is in my original post, but there isn't anything very helpful in the sync.log other than a "Sync stopped" message.
I suspect it only occurs when there is a lot of data to sync? If your repo isn't as large it might not occur. Maybe I could create a public repo with a ton of files and try to reproduce it with that.
It very well could be something specific to my machine, or even a temporary connectivity issue with the server it is syncing to.
Might I suggest just making the sync process more robust? Would there be any drawbacks to having it retry to continue syncing if there is an error that causes the sync to quit? There must be some sort of panic going on somewhere that's causing devspace to quit, but it is weird that the console isn't getting any error message.
I can try to debug this locally and see exactly where it panics out, I'll look into it.

My new theory is that this is related to #343
I think I was running commands before everything was synced and maybe my command and the sync were messing with the same file at the same time or something and caused the sync to quit and also kick me off.

ok, I think this can be avoided by not running any commands until everything is synced.
I can only reproduce this now by running a command to install my project's dependencies while the project is still being synced up. Sorry for missing that detail.
I think #343 will fix this for me. so we can close this one out.

@KaelBaldwin Thanks for all the information! I analyzed the issue a bit and the errors you see in the errors.log actually originates from the portforwarding functionality directly in the kubectl package and is not related to the sync functionality. If you don't see any FATAL: [Sync] Fatal sync error: like message on the console when the terminal exits the sync is not the root cause for exiting the terminal, because if the sync loses connection or encounters any other fatal issue such a message would be printed.
Since you don't see any error message prior to the terminal exiting, I suspect two possible causes for this behavior:

The terminal connection is somehow aborted on your side, either trough firewall/internet outage etc. What you could try is to open a shell through kubectl in parallel to devspace up and check if this terminal is closed too.
The pod is somehow restarted/rescheduled/loses connection. Maybe the sync is the issue that the pod gets restarted/rescheduled, however I'm not really sure why this should be the case.

I guess we need some more information from your side about the circumstances this keeps happening, because I'm not really sure why the terminal should exit without any error and we cannot reproduce it unfortunately.

Sure I'll keep looking into it, thanks

So noticed today while starting it up, that I got kicked out again. The first time I got kicked out, I decided to run exec into the container via kubectl as you mentioned while also running devspace up in another terminal.
I ran devspace up first and it connected fine.
I ran kubectl exec and it failed to connect. I then checked the devspace terminal and it did indeed disconnect.
So this does seem to be a connectivity issue.
Wondering if it's possible to make this connection more robust? There is a lot going on on the cluster, so maybe there was just a CPU usage spike or something due to another install going on causing it to lock up for a second.
I haven't monitored the CPU usage during syncing on the devspace container, but that would be interesting to check and might explain why I mostly have the issue during syncing.

I have just discovered that kubectl exec, if established before devspace disconnects will persist through the disconnect.

So basically I think this goes down to whether or not you all want to try to make devspace more robust to temporarily stalled connections. If that's not feasible, feel free to close this issue and I'll just deal with the disconnects.
@FabianKramm

@KaelBaldwin Thanks for all this detailed information! Regarding your last question, we definitively want to make devspace more robust. You've got really interesting results, because we internally already call the kubectl exec function (The call is in pkg/devspace/kubectl/client.go and the kubectl function is exec.Stream from the kubernetes project (see kubernetes). So this is really weird behavior and I guess as you already assumed is somehow caused by a side-effect of the port-forwarding/sync services. To verify this assumption can I ask you to do another test for us? Could you run devspace up bash, devspace enter bash and kubectl exec ... bash at the same time and tell us which of these three has disconnected, if the disconnect occurs?

Sure thing, I'm trying it out now

@FabianKramm they all failed this time, including kubectl exec, which had persisted every other time. I did some monitoring after getting that result:

Looks like the data transfer is spiking very high at a certain point, which is impressive! Haha. I'm thinking what's happening here is my network interface is getting 100% used by the sync and losing connections.
Further looking into it, I have a rather large file in my repo at the moment that I was using for test data. I'm betting when it gets transferred it's causing the overload.

That file might be what's been the problem all along. Removing it and seeing if that resolves everything.

ok, yeah things were much more tame after removing the file.
Highest it got up to was around 70% usage, and no disconnects.

@KaelBaldwin Thanks for this information! I'm still wondering why exactly this happens though, because the sync opens only two kubectl exec shells to sync all files and I don't really understand why a high network usage would result in the os dropping network connections, that somehow sounds odd, because an usual file down/upload is usually also unrestricted in bandwidth. I would  suspect that the remote provider has maybe a bandwidth limit and somehow aborts the connections if they use up too much bandwidth. I'm not sure how to test that though.

But I guess restricting the sync to use only a certain amount of network bandwidth would probably solve your problem.

@FabianKramm as far as the remote provider goes, this is a baremetal kubernetes cluster so I'm on the same network

I do think your idea for being able to specify an upper limit would resolve it.
As to if the OS is dropping connections or not, I'm not familiar enough with it's handling to speculate on that, other than maybe it doesn't drop the connections, but perhaps there is enough of a delay that for kubectl exec to reach a timeout and disconnect.

Okay I'll open a new issue for that and close this one. That is also the only solution I see currently that we can implement, while we cannot exactly find out who and why the connections are getting closed.


fix issues with Virtualbox provider in Vagrantfile

Use correct "override" statements to:

boot on CentOS 7
use vagrant account with insecure_key
with Virtualbox provider.

Sorry, I didn't see the #268 PR

@nqb Is this a subset of https://github.com/ansible/lightbulb/pull/268
I'm wondering if this should be closed?


Make demo SCA ready

Update SDK and follow docs on docs.builton.dev

We handle payments with stripe test tokens. The reason for that is that in we cannot enforce test cards in the demo store.
Documentation on how to implement SCA has been added to Read Me.


String method return a new line when followed by Exec

Calling String followed by Exec returns a string ending with a new line (i.e. \n).
Example:
out, err := script.Exec("echo hello").String()
if err != nil {
	log.Fatal(err)
}

fmt.Printf("%q\n", out)

It prints: "hello\n"
Is this intended or the \n shouldn't be there?
If I'm not mistaken the issue is that os/exec.Command returns it. Execute this example
package main

  import (
    "bytes"
    "fmt"
    "log"
    "os/exec"
  )

  func main() {
    out := &bytes.Buffer{}

    cmd := exec.Command("echo", "hello")

    cmd.Stdout = out
    err := cmd.Start()
    if err != nil {
      log.Fatal(err)
    }

    cmd.Wait()

    fmt.Printf("%q\n", out.String())
  }

And you see that it prints: "hello\n"

If you run the command echo hello in your terminal, you'll see that it prints exactly hello\n.

Right.
The thing is that I ran into this issue when I was trying to do this shell
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

And how I'm doing with script is
arch, err := script.Exec("dpkg --print-architecture").String()
if err != nil {
	log.Fatal(err)
}

versionName, err := script.Exec("lsb_release -cs").String()
if err != nil {
	log.Fatal(err)
}

_, err := exec.Echo(fmt.Sprintf("deb [arch=%s signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian  %s stable", arch, versionName)).Exec("sudo tee /etc/apt/sources.list.d/docker.list").String()
if err != nil {
	log.Fatal(err)
}

Because Exec("dpkg --print-architecture") and Exec("lsb_release -cs") has a newline at the, it doesn't work as expected and I have to trim the \n for each result.

If you're looking to add a newline -- use printf instead of echo:
script.Exec(printf "Hello There\n\n\n\n").Stdout()
If you're looking to remove the newline from the end of the string you can do it like this:
versionName, err := script.Exec("lsb_release -cs").String()
if err != nil {
	log.Fatal(err)
}
versionName=strings.TrimSpace(versionName)

That will remove all whitespace from both sides of the string.


torch.load() hangs indefinitely when reading OPT pre-trained model weights

I'm trying to use OPT 66B pre-trained model for inference on EnergonAI. After preprocessing the weights by the script of preprocessing_ckpt_66b.py and starting opt server, the service hangs there when loading the weights. I tracked back and found it hangs on torch.load() after reading most of weight files (95% weights are loaded).
https://github.com/hpcaitech/EnergonAI/blob/98a12bc2107b206017c4793380538f9cdec5a5e1/energonai/utils/checkpointing.py#L42
The output before hanging
start loading /root/EnergonAI/ckpt/opt_66b/14-restored.pt...
                    INFO     colossalai - energonai - INFO: Rank1/0 model size = 17.395826688 GB
[10/04/22 02:21:27] INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:195 create_pipeline_model
                    INFO     colossalai - energonai - INFO: ==> Rank 2 built layer 0-64 / total 64
                    INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:200 create_pipeline_model
                    INFO     colossalai - energonai - INFO: Rank2/0 model size = 17.395826688 GB
[10/04/22 02:21:27] INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:195 create_pipeline_model
[10/04/22 02:21:27] INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:195 create_pipeline_model
                    INFO     colossalai - energonai - INFO: ==> Rank 5 built layer 0-64 / total 64
[10/04/22 02:21:27] INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:195 create_pipeline_model
                    INFO     colossalai - energonai - INFO: ==> Rank 7 built layer 0-64 / total 64
                    INFO     colossalai - energonai - INFO: ==> Rank 6 built layer 0-64 / total 64
[10/04/22 02:21:27] INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:195 create_pipeline_model
                    INFO     colossalai - energonai - INFO: ==> Rank 4 built layer 0-64 / total 64
                    INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:200 create_pipeline_model
                    INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:200 create_pipeline_model
                    INFO     colossalai - energonai - INFO: Rank5/0 model size = 17.395826688 GB
                    INFO     colossalai - energonai - INFO: Rank7/0 model size = 17.395826688 GB
                    INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:200 create_pipeline_model
                    INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:200 create_pipeline_model
[10/04/22 02:21:27] INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:195 create_pipeline_model
                    INFO     colossalai - energonai - INFO: Rank4/0 model size = 17.395826688 GB
                    INFO     colossalai - energonai - INFO: Rank6/0 model size = 17.395826688 GB
                    INFO     colossalai - energonai - INFO: ==> Rank 3 built layer 0-64 / total 64
                    INFO     colossalai - energonai - INFO: /root/miniconda3/lib/python3.9/site-packages/energonai/model/model_factory.py:200 create_pipeline_model
                    INFO     colossalai - energonai - INFO: Rank3/0 model size = 17.395826688 GB

By the way, if I run only the code block around torch.load() locally and all weights could be loaded successfully through torch.load().

Hi, could you try the latest code?


Properly ccache github actions

(Partially?) fixes #4963

It seems like other compilers can't simply pick up the ccache from the path, we will probably need to modify CC or create a symlink

+ccache 2>/dev/null -v -v

You should probably pass the arguments before the stderr redirect.

So is there any need to do -s before running the tests?

Is there a disadvantage?

Ok, well, I got ccache working for macos, but not windows 😂

I can hack my way through runtests to be able to modify ccompiler and enable ccache for windows.
But it seems like a generally usefull option to have for cython compilation (to have it work for any platform).
What do you think?

Ok, I probably jumped into the conclution early, maybe I don't need to modify runtests
But this, what do you think, should this option be implemented?

@0dminnimda, could you please try to bring this into a mergeable state? It doesn't have to be complete, any improvement will help. We can add to it at later, any time.

@scoder I can try, also I didn't test other means of doing this like sccache

It doesn't have to be complete

Yeah, I guess I like perfection too much, a destructive addiction huh ..
But ok, I'll make this pr not fail the tests. At least the linux and macos runs will be faster

Is there a disadvantage?

-v -v outputs more informaiton and if I remembder correctly -s overrides the -v -v

Ok, so I can see somewhere around x3 increase in time of the compilation of the same code, this probably will not be significantly worse with reasonable amount of changes in the code, so this is already an improvement
I will try to get read of the broken testes and then this can be merged

I can't spend more time on this right now. ccache works for macos and linux and I left a TODO to set up sccache for windows - both ccache and sccache are already configured to be installed.
This can already bring a value to the project, and
As @scoder said

It doesn't have to be complete

so I would consider this for a merge

Thanks @0dminnimda, this is going to help us a lot by speeding up the CI jobs.