Upgrade to Vue 3.x

Summary
What is the current strategy / timeline for upgrading Gridsome to use Vue Next (3.x)?
Request for Basic examples
I would love to see an official statement from the Gridsome team about Vue Next (3.x).
Would be great to have some examples of how to use the Vue Composition API ( related to #1270 ),
and some clear recommendations about  when and why to do so.
Motivation
I assume that Gridsome will at some point upgrade to Vue 3.x and as my projects are rather young, I'd like to know how to be as prepared as possible for this (or even to use a Vue 3.x branch from the beginning)

I have most parts in Gridsome working with Vue 3 in a local branch. The only thing that isn't implemented is vue-meta, which haven't published a package for v3 yet. But I hope we'll be able to do the upgrade soon.
Everything will work mostly like before, but we'll do some changes to the Client API (main.js, gridsome.client.js) because of how a Vue 3 app is initialized. And we'll add methods like usePageQuery(), useStaticQuery() to use <page-query> and <static-query> data in setup(). But $page and $static will still be available as computed properties.
And regarding the Composition API plugin for Vue 2. I don't think you'll need to change anything when Gridsome upgrades to Vue 3, except for any changes between that plugin and Vue 3 :)

Congratulations! Would be great to some official communication about the general direction of Gridsome too; it's felt pretty quiet this year, especially in comparison to that other well-known Vue framework!

@davestewart We will update the roadmap soon :)

Is there a timeline for the Vue 3.0 implementation and the 1.0 release?
I'm currently evaluating Gridsome versus Nuxt for a new initiative to start this month - and this could be a defining feature.

@christopherowen if you check in the project board, you can see the "in progress" lists a task for updating to vue 3. Additionally, the vue-next branch includes the gridsome package with vue at 3.0.0-rc.12, which is the next to most recent RC (6 days ago, gridsome's branch updated 5 days ago). As a non-contributor to / watcher of this repo, it looks like this is actively being worked on and is likely waiting on vue's official 3.0.0 stable release and validation after its release.

Just a quick comment here, it might be a good idea to pin this issue so that it's easily found by everyone wondering if/when vue 3 support is coming.

Vue 3 has been released and @hjvedvik have done an incredible work by migrating it (vue-next branch) so far.
Tell us, what we can do to help you? I think you must create a new project board and put the to-do things so we can help and get this project done.

Yes is there any word on the project or has it been documented anywhere in the roadmap? It seems like the most necessary feature request currently and it's a shame to see Gridsome not jumping on Vue 3 as other frameworks have as otherwise Gridsome is practically perfect.

Good idea, @scratchmex! At the moment, I think the only thing left to migrate is the vue-meta integration. Still waiting for a package that is compatible with Vue 3 from them. But there are probably other things that I'm not aware of, so I'll see if I can come up with a board one of the next days.

I think a branch is available here:
https://github.com/nuxt/vue-meta/tree/next

For the vue-meta blocker. Will be worth considering keeping any eye on https://github.com/nuxt/rfcs/issues/19
May open a valid approach also.

For the vue-meta blocker. Will be worth considering keeping any eye on https://github.com/nuxt/rfcs/issues/19
May open a valid approach also.

https://github.com/vueuse/head just got released and I think it's a super nice solution.

https://github.com/vueuse/head just got released and I think it's a super nice solution.

https://github.com/vueuse/head just got released and I think it's a super nice solution.

Does it have identical featureset, subset or superset of vue-meta?

https://github.com/vueuse/head just got released and I think it's a super nice solution.

Does it have identical featureset, subset or superset of vue-meta?

Does it have identical featureset, subset or superset of vue-meta?

I checked just the docs and it seems only the titleTemplate is missing - But this should be easy to integrate a helper function which does the job :)

Does it have identical featureset, subset or superset of vue-meta?

I checked just the docs and it seems only the titleTemplate is missing - But this should be easy to integrate a helper function which does the job :)

<EMAIL_ADDRESS>has been released 👀

Vue3 support for vue-meta is considered in mostly-stable-alpha stage.

Is the plan to wait for Vue-meta or can we jump to using Vue head instead?

@tomtev , @hjvedvik , please provide your preference, this issue has been sticking for quite long time.

Been patiently awaiting vue3 support. I'm happy with either<EMAIL_ADDRESS>or vuehead. I'd like to see some traction to move forward.
If there is anything else or some way I can be of help to make this happen, please let me know. I really want to see this release to 3.

BTW<EMAIL_ADDRESS>has released
https://github.com/nuxt/vue-meta/releases/tag/v3.0.0-alpha.2

Is there a branch that I can help work on to help?

:)

Bumping.

Sorry to bother, any idea when Upgrade to Vue 3 will be complete. Love gridsome, just need Vue 3 for latest project! Thanks for all your work!

Trying to use Tailwind https://headlessui.dev/ and UI component but documents says works only on Vue 3 any workaround until gridsome is ready of Vue 3?

Is there any way we can take development? We can fork and everyone contribute to it. It seems that the lead developers have abandoned this project

@RehanSaeed , what do you suggest? Is it covid effect?

What about just pinging some of the people maintaining the project instead of making a fork?
@hjvedvik , @lovell ? Mind to give us a heads-up on status for moving to vue 3? :)

It seems like this thing is dead, anyone can confirm?

@Miguelklappes I've not really been able to figure out what is going on. For a long time the repo looked more or less dead, though I've noticed that lately some of the core contributors are indeed working again behind the scenes. Not sure where it is all going or how soon newer releases and version bumps will be coming through the pipeline though.
Per my earlier post above, there is something about gridsome that 'just works' in terms of the abstractions, though this only holds if there is enough support to keep the package current, e.g. recently the newer releases of remark plugins have started breaking.
I'm inclined to suggest waiting another 3-6mos in case the currently ongoing work starts to trickle out, otherwise vitepress might be sufficiently generalised by that point.

@songololo
I tried Vitepress, but I am too spoiled by gridsome to use vitepress. And Gridsome has given me so much fun to work on website development.

We're coming up on a year since the last release. I know there's been a little more visible activity of late but I think we're also due for a state of the union report. You can't communicate everything through code alone.

Hey there! Just checking to see if there is any update from the team on this? It has been a year since the last release and I don't mind waiting for an update, but the radio silence is somewhat concerning. I really love the Gridsome development workflow and want Gridsome to succeed/continue (at least in a simple sense - i.e Vue 3 support), but I may have to move over to Nuxt within the coming months if there isnt a major release (which is alright I guess, but I like Gridsome more lol).
Perhaps the community can just get a hint as to what is in the pipeline for Gridsome via twitter or discord from the authors? Again, no need to rush anything - we are all busy with work and life - but I am just curious:)

I've been wondering about this: https://twitter.com/gridsome/status/1436343468717191172

I've been wondering about this: https://twitter.com/gridsome/status/1436343468717191172

I've seen a lot of projects over the years fall apart because the creators tried to do too many different things at once. Not saying it's what's happened to Gridsome, but the longer we go without a real update...
Personally, I'm gutted. Gridsome was the best thing to happen to my site-building practices in years and it was the first new way of doing things that worked for my brain.

Not to use this to take away from any of the Gridsome team's efforts (which may or may not be happening behind the scenes) I used VuePress earlier this year to build my personal site and it was a breath of fresh air.
It took a while to get my head around exactly how to create a custom theme (unfortunately the default theme is too closely bound to the framework itself) but if you want to build a static site built around Vue and Markdown, I say that there is not better way to do it. The DX is phenomenal (way, way easier than messing about with external APIs and Graph QL), it is SUPER FAST (even without Vite, though the new version is powered by Vite) and a piece of piss to deploy.

In addition to Vue 3 support, I'm requesting that the next version also includes Webpack 5, the latest postcss-loader, and PostCSS 8 compatibility. I'm in real need of upgrading these packages but I can't if I'm constrained to Gridsome's current dependencies.

@OzzyTheGiant those are already included/implemented in the latest PRs. I think the changes just need to be pushed into production if I am not mistaken..

At this point it seems baffling that there hasn't been an official release closing off the 0.7.x branch.
If Gridsome's developers want us to start new projects on the forthcoming Vue 3-based version, that's all well and good (but they should say so) but this limbo state is confusing and dismaying.

Yes I lost faith in that project probably because of the absence of communication of the lead team. I don't blame them though, what they did was fantastic in the first place and totally free...
So I just migrated my blog to svelte (after trying nuxt). Also the learning curve was steeper because of the missing data injection and optimization layers (lazy load, images), the overall design without the virtual dom is a lot simpler (no tick and waitfordom dance), and I have now the impression (perhaps false), that I'm in full control and more resilient to unmaintained packages. The site is also a lot lighter and got 100% speed score where I had 60% with gridsome with the same functionalities.
Perhaps gridsome reached a tipping point and showed the limit of blackboxes even for the creators themselves ? Everything is going obsolete so quickly in web tech...

I haven't lost faith in the project. I know that the progress has been slow in the past year, but there still has been progress, on the bright side, the last commit was last month, which hasn't been that long ago. Gridsome isn't dead, even if it seems to be "barely alive". I think every language goes through such a stage, such as when Nuxt was fairly silent for the longest time. I also think that the pandemic has been pretty hard on everyone - even developers. Luckily, it seems pretty positive that the pandemic is now over, and hopefully the world starts to settle back into where it was. When it comes to me, I tried using Nuxt 3, but because it's in beta and super unsupported to be practical for my use, I decided to drop it - it wasn't worth trying to find ways to work around the incompatibility of the framework. Also, I couldn't stand to use Nuxt 2, because it is way too slow, whereas Gridsome is like 10 times as fast. It can't necessarily compete with Nuxt 3 or Vue 3 for that matter, but Nuxt 3 is still in its early stages and I would never use the actual Vue framework itself (neither would I deviate from using Vue-based frameworks). When it comes to other frameworks, it gets too complex, and sorry, but I can't necessarily allow myself to waste time on something like that. So, I find myself in a place where I am unwilling to move from using anything but Gridsome since I discovered it about a month ago. Yeah, I've used Nuxt quite a bit (even though it doesn't necessarily go to show with the repositories that I have), but it's just terrible to watch Nuxt 2 run through the development task, knowing that there's better than this.
Therefore, I'm going to stick with Gridsome, even if progress doesn't happen that quickly. I don't need the bling of Vue 3, and neither do I need the complexity of Vue. Gridsome opened my eyes, and made the otherwise difficult tasks, easier. When I get around to it, when I do find time, I just imagine the pain that I would have with everything else, and how easy it will be to use Gridsome for my personal website/blog/portfolio project. Gridsome has a lot more potential than most other frameworks. It has features that I would miss if I would use Nuxt, Vue, Vite, or something else. I love the optimized images (g-image), the g-link seems to be better than that of Nuxt's "NuxtLink, NLink, Nuxt-Link" (yes, it's confusing), configuring metadata is simpler, I love the GraphQL features (even if the explorer doesn't appear to work), using the main.js file to push items to the head seems more logical, streamline and easier (and it makes the gridsome.config.js file less cluttered, unlike a nuxt.config.js). There are too many changes, features, differences that I like about Gridsome, that make it unreasonable to return to using Nuxt.
I also look at the progress that has already been made on migrating Gridsome from Vue 2 to Vue 3. It's so close, and it doesn't seem like the progress that would get thrown away out of neglect - and I'm not saying that Gridsome has been all that neglected either. I think the bold intent for the project to move forward is clear, even though it seems abandoned. I think we also have to realize that mostly one person (@hjvedvik) is doing almost all the work. Furthermore, I also know that the head devs have other projects that they work on and maintain, and everyone has personal life problems to deal with - and the "pandemic" hasn't made that part easy. Also, looking at it, I think the numerous "Gridsome is dead"-type proclamations isn't helping. I think we need to give it a bit of time, and if nothing else, encourage the project to continue.
So, in everything, I hope this is seen, and I also hope that this project continues on - because it's not dead yet - and it's amazing. Everything that I have decided to jump to when it comes to frontend development has benefited me. It's made things more interesting, wasted my time, but thoroughly intrigued me and given me more to learn and less to be bored over. It all has changed the way I do things regarding frontend development - and it has made the things I thought that I would never do, possible for me. So I thank the head devs @hjvedvik and @tomtev for Gridsome and I look forward to doing more with the framework in the future (also positive news - Gridsome is still getting around 7,000 downloads off of npm per week, so people are still using it and still care - as I do).
#ReviveGridsome

@dev23jjl That was a really excellent post! I agree with everything you said. Gridsome is phenomenal and the community has so much passion for the project—especially us developers that see the ease and simplicity of using Vue compared to other frameworks (cough React).
For me personally, I can honestly say that Gridsome was the stepping stone I needed in my development practices to finally “get it.” I think every developer has that moment eventually and I do believe that Gridsome provides arguably the easiest way to get there.. the use of APIs to fetch data, laying out that data through Graphql, and finally using said data within the Vue template structure to do basically anything you want.. it’s all so simple. Like you mentioned, the major advantage of Gridsome is how easy it is to make complex tasks work. For instance I am working on a headless Shopify project for a client using Gridsome (as my framework) and Sanity (as my CMS).. I am able to combine the use of 2 plugins (the gridsome flexsearch plugin and the gridsome recommender plugin) to create complex product filtering and search functionality that would literally take a TEAM of developers to figure out (or maybe one senior “know-it-all” developer, but you get the point lol 😂). It really does provide a fantastic ecosystem of plugins and way of doing things that Nuxt or Vue/Vitepress does not currently have.. yes, big things are in store for those projects too and I’m not saying they are bad at all, but Gridsome just gets a lot right.
I think that passion you and I share for this project is what a lot of developers also feel and it’s why we all are so keen as to know what’s in store for the future of Gridsome. Like you said, hats off to the team @hjvedvik and @tomtev for all the work they have both done. If the authors do see these posts, just know that there are a lot of us here to offer support (help with checking over PRs, providing themes, maintaining the plugins, etc.) and wish the best for this project to continue.

Another tip: If you are like me and the main advantages of Vue 3 which you want to utilize are the Composition API, the <script setup> way of writing components and awesome external tooling like VueUse, check out my fork of the default Gridsome starter which enables usage of those: https://github.com/loilo/gridsome-starter-composition-api

That's great! I will say, though, that I haven't necessarily gotten around to using those features of Vue (yet...), but it will likely be useful for a lot of other people that are looking for those features. On the other hand, I'm more excited for Vue 3 support because of the Vite part (it's fast 🚀)! In search of how I could use Vite with Vue 2 to see if I could somehow figure out how to use it with Gridsome (let's just say I knew that it was probably going to end up in failure, but I could at least try to do something), I found something a bit more promising, and even though it seems like we haven't heard much from the head team, I found something that seems to show that the project is still developing. While on my search, I looked up, "how to use vite with gridsome" and found a result for a package on npmjs.com. It must be the start of the Vue 3 version of Gridsome, I would assume. It has been updated numerous times within the past month (as well as yesterday 😊), you can check it out at https://www.npmjs.com/package/gridsome-vite! I don't know necessarily if I am able to use it in any way, however, it is a good sign that Gridsome is still moving ahead (even though, currently behind the scenes)!

Hello Bro @gotjoshua.
One relevant mention: the project for the Company I am currently working for is set with Gridsome.
We have take notice on this exciting initiative, and even have built plans that potentially would take off depending on the success of this endeavor.
It would be great if you can provide an update on the status of this development?
We could even - depending on scope - throw you a helpful hand to get this done, since we are a group of FE devs, and it would be a really cool value added to the project if we can move to the Vue 3 direction.
Let me know and let's see if we can make it happen the sooner the better!! :)

Hi @jm-cano, since you tagged me, wanted to reply personally.
I don't have any bandwidth available for hacking on gridsome core actually.
I opened this issue to ask for support getting started, and I am actually using very different stacks these days!
Good luck in your endeavors ( labster looks cool ) and I am still hoping that the gridsome core team and community manage to roll out a killer Vue3 implementation in the near future!

A long period was past.
How about the upgrading?

no updates :(

This thing is dead like Christy Mack back in the 80s. Time to move on.

The best alternatives are probably Nuxt 3 and Iles.

@fallsimply There's also Astro, that one for sure is about to reach 1.0 and is in beta phase, plus has major backing from Vercel & Netlify. Supports Vue, React, and other component based frameworks for templating

Some kind of "Nuxt for Gridsome developers" primer might be nice then, because Gridsome itself hit a sweet spot for front-end workers like myself who don't consider themselves Javascript experts. It really did take care of a lot of fiddly stuff that the other frameworks don't. Also the remote content source stuff was really good (except for remote images, where it sucked about as much as all the others do).

@fallsimply There's also Astro, that one for sure is about to reach 1.0 and is in beta phase, plus has major backing from Vercel & Netlify. Supports Vue, Svelte, React, and other component based frameworks for templating

URL for Astro? It's not the most specific name for a web tool I've ever heard.

@Rocketpilot https://astro.build. My guess, is that we could just import all of the components as they are and just ensure routing is configured properly and data fetching will be different (no graphql layer)

Astro does look pretty nice, so I'll have to play around in it. I still think it's a shame the front-end development community can't settle on any one next-generation framework because there's a huge amount of value in a deep and established ecosystem. WordPress drives the world for a very good reason.

To each their own, but in my personal preference, I refuse to support
Wordpress for so many reasons: constant vulnerabilities due to plugins,
overly-basic themes, terrible coding practices, poor developer experience,
unoptimized database queries, and complete disorganization and lack of
standards when it comes to data modeling (which makes migrations to other
platforms awful). I wouldn't want to waste my time providing support
services for Wordpress when I can use a much cleaner implementation with a
combination of headless CMS and static site generators. Have had great
experiences with this so far. I know this is a strong opinion but one that
I didn't make lightly because there was so much to consider as far as how
my workflow needs to be, and hopefully this will at least help inform other
developers as to the choice of tools they need to make.
But I agree, we need to have an established system that we can support.
Jekyll and Hugo are some of the longest running platforms but that requires
learning another language if one only knows JS. Then there's Gatsby but it
locks you into React and that's another tool I refuse to use for similar
reasons as wordpress. Astro seems to be the most promising library of all
as it allows you to bring your own components from anywhere, providing a
neat shell of an architecture.
On Wed, May 4, 2022 at 4:54 PM Nick Caldwell @.***>
wrote:

Astro does look pretty nice, so I'll have to play around in it. I still
think it's a shame the front-end development community can't settle on any
one next-generation framework because there's a huge amount of value in a
deep and established ecosystem. WordPress drives the world for a very good
reason.
—
Reply to this email directly, view it on GitHub
https://github.com/gridsome/gridsome/issues/1289#issuecomment-1117970903,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHYJT6F4ZZXKWPZ7ZS36PM3VILWX7ANCNFSM4PHM5YPQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

Oziel Perez

The different datasource plugins and graphql layer are brilliant features for us. It's so easy to grasp. Why hasn't any other framework picked that up?
Anyway: Any live signal from the devs here? Maybe some kind of "I lost interest. Bye."?

Why hasn't any other framework picked that up?

Fundamentally, the modern web isn't a place for people who like making websites. I think it's literally that simple.

Why hasn't any other framework picked that up?

I believe data source plugins with graphql layer was originally from Gatsby

I don't know, but I switched back to Nuxt (which I originally used) and since then I haven't really had time to work on what I would mainly call my “hobby” web development. Either way, in retrospect, I realize why I gave up Gridsome… its structure was similar in one way, but yet various components that were directly “Vue-based” were foreign to me. It was great to start with, but when I couldn't figure out various components, I went back to what I was comfortable with. I couldn't even find any updated or working templates to work off of that used the CMS that I originally intended to use. And being anywhere from beginner to amateur at web development, I don't have the skills where I could integrate a CMS into a framework blindly. Gridsome is faster than Nuxt 2, but Nuxt 3 beats both of those. Even though it's not quite totally supported in every way yet, they're still working on it, and it's far from dead. It, personally, feels more stable and less vulnerable than Gridsome, and it's more useful for a larger variety of situations. For example, if I had the skill, I could build a variety of web apps with Nuxt and create any sort of basic website as well, where Gridsome is more focused on company websites, personal showcases, blogs, ecommerce, etc. (you know, CMS). Nuxt 3 is extremely fast with Vite, and that's something where Gridsome lacks. Basically, what I'm trying to say is that it's a shame that Gridsome is slowly diminishing to nothing, but it wasn't the type of framework that I expected. Maybe I just didn't give enough time into it, but it didn't seem like a good idea to try too hard when the lights could go out on the whole project. In certain cases, you could end up scrambling to nearly rebuild everything if that would happen. I would like Gridsome to stay around, but I can do even more with Nuxt and I have all the supported modules to build what I need. I guess I also feel guilty for cheering Gridsome on, but then going back to Nuxt, but there isn't much I can do about the silence. It's either patience (and they'll get back to it) or the lights are flickering and about to go out.

I'm willing to donate/sponsor further development of this project if that will help (please add GitHub Sponsors). If new contributors are needed, that would also be something I'd be willing to help with.
As an owner of some open source projects myself, I can understand why sometimes it can be difficult to find time to push a project forward. I'd be happy with an open and honest answer of 'I don't have time'. Please consider communicating the future of this project and/or finding additional contributors to help drive things forward.

Sorry @RehanSaeed, I might have been misunderstood. I'm not one of the lead devs, I just was previously a Gridsome user (I was planning on using it for a personal portfolio/blog/showcase that I have recently been too busy to work on). I also have helped a few people with their issues (mainly concerning the version of Node they were using) and tried to provide, I guess, what you could call “moral support” in a previous comment in this discussion/issue. If I was able to, I would help, but being a busy student and not having the skills – I can't. Long story short, I'm a hobby dev that has basically spent the past year learning a better framework than HTML 5 (that was the best I used to know before I found Nuxt and then tried Gridsome). As far as Gridsome and Nuxt goes, I've minimally contributed (even though I have them pinned on my GitHub profile 😅), just bug reports and helping others solve basic problems. While I want to learn more in the future, this dev isn't the most experienced (for now).

Astro looks great.

I would personally argue that Nuxt is better, but that is my opinion 😉

@fallsimply There's also Astro, that one for sure is about to reach 1.0 and is in beta phase, plus has major backing from Vercel & Netlify. Supports Vue, Svelte, React, and other component based frameworks for templating

Thanks for the brief but reliable introduction.

I recently switched to Ilse from Gridsome (due to the lack of progress) and i can recommend it to everyone. Great project with great and helpfull developer.

I recently switched to Ilse

Oooh... I switched to VuePress some time ago, but this looks really nice!

I was  thinking to try gridsome and then I realised it is vue 2 only and that the project looks a little abandoned. Well, nuxt 3 it is I guess. I still would be interested if gridsome publish version 1.0

Nuxt Content v2 for Nuxt 3 was recently released with new querying features. This is probably the closest to Gridsome were gonna get for Vue 3

Vue 2.7 Naruto has been released which allows you to use many Vue 3 features including composition API. This should give Gridsome a new lease of life and give the maintainer more time to figure out what they want to do with this project (continue it or hand it over to the community).

I just found Iles for Vue 3 (https://iles.pages.dev/) which is inspired by Astro, islands architecture, partial hydration, static site generator. There is a special channel for Iles on vite's discord server.
Has anyone tried this? Can this be a viable alternative to Gridsome within the Vue ecosystem?
Astro+Vue seems like an alternative to Gridsome, but at the moment, Astro doesn't expose the vue instance like Gridsome or Iles, so can't use Vue plugins/UI libraries like Vuetify with Astro.
I hope Gridsome is back, or someone replaces Gridsome's place within the Vue ecosystem that establishes best practices, conventions and specialises (unlike Nuxt which has a very broad spectrum) primarily on MPAs. Iles looks promising. Cheers!

I just found Iles for Vue 3 (https://iles.pages.dev/) which is inspired by Astro, islands architecture, partial hydration, static site generator. There is a special channel for Iles on vite's discord server.
Has anyone tried this? Can this be a viable alternative to Gridsome within the Vue ecosystem?

Yes, I've migrated our Gridsome Site to Iles and it works fantastic.

I'm still sad this project died... Probably the best non-official Vue framework ever made. Sure iles is great for simple sites, but in terms of plugin-ecosystem (CMS, ecommerce, random things, etc) and mixing/matching templates nothing has come close to Gridsome. I am moving on to Nuxt3, but I still use Gridsome for Shopify-based stores because its just so damn simple and intuitive. Hopefully the author can one day come back to this.

React has Gatsby, Svelte has Elder, Vue had Gridsome...

Correction: Svelte has SvelteKit. It includes SSG out of the box.
https://kit.svelte.dev/docs/appendix#ssg

True, I left out Next, Nuxt & Sveltekit and listed only those that fit into "do one thing do it well" (ssg) philosophy 😉 I have heard great things about SvelteKit 👍🏽

We just got a Gridsome update a couple days ago for Vue 2.7 👀

And gridsome.org still shows 0.7.23 as the latest release.

There is still hope!

Definitely. Its always good to see Gridsome get updates. For what it is, this is still probably the best independent Vue-based project on Github (for plugin accessibility and template management --- i.e not just using markdown) thats not a part of the core Vue ecosystem. It might be hard for the project to gain the attention/following it once had, but it still works very well and gets a lot "right" in terms of how easy it should be to setup and manage a front-end project. I think thats why most people who use Vue really want the best for this project.

And gridsome.org still shows 0.7.23 as the latest release.

What is the process of creating a new release 0.7.24 ? @hjvedvik

@hjvedvik any update on the release

@rylanharper Just a wild guess, but what you describe sounds like you don't commit your package-lock.json file. Technically, Vue 2.7 is compatible with Gridsome as it does not contain breaking changes, so if you're not being very specific with your dependencies (through such a lock file), Netlify will install the latest Vue 2.x version it can find.

@loilo Ah got it! Yep, that sounds like whats going on. Thanks for the info on that:)

https://www.npmjs.com/package/gridsome-vite?activeTab=versions
https://diff.intrinsic.com/gridsome-vite/0.0.1-alpha.571/0.0.1-alpha.665

I've build a lot of great stuff with Gridsome already. I hope this project does not get abandoned. 🙏🏽  Such a great concept and idea! ❤
Any news @hjvedvik ?
Or, do we have a specific channel of updates? 🤔

I've 10 or more projects using Gridsome - but without Vue3 and not release in years - it's looking like abandon-ware whatever we feel about it - it's becoming obsolete and therefore legacy risk- do we fork, find alternatives or ?

not sure who used to run this project - but I'm hoping to find out. despite this issue being 3 years old @hjvedvik hasn't commented on this thread since Nov 18, 2020 ? I was worried for his health but he is still committing code :-D
I know anyone can fork, but the cost of maintenance is high. I am willing to fund raise and sponsor a team to fork it. I'll certainly lend an hand, and GPT can code nicely too. Anyone interested - reach out to<EMAIL_ADDRESS>if so

I've always been a fan of Gridsome, as I've mentioned in this thread last year. It really helped me learn a lot as a developer when I first started out in 2019 dealing with APIs and all that. The early discord community was full of really helpful developers as well. However, while it's not official, I feel this is definitely a dead(dying) project and would recommend migrating to Nuxt3. Most CMS platforms are supported within the Nuxt(3) Modules ecosystem and if not, you can use nuxt-content for markdown or the nuxt-graphql-client module to connect to graphql (similar to what Gridsome offers).

https://www.npmjs.com/package/gridsome-vite was mentioned in this thread a few times, but those comments are not visible anymore. It's a good starting point, and I've figured out how to build a few pages with it by inspecting the source and following the errors. But without the docs and plugins, it's not feasible to build anything more than that. I've continued to stick with Vue 2.7 just to be able to use Gridsome after I tried the other frameworks. I'm willing to pool 2k USD for further official development of gridsome-vite with some rough timeline.

Thanks for Rylan
Lovely words. I’ve budgeted &5k per quarter for 2 quarters now.
Your the first but I have another to open.
Regards
-Lee-
On Tue, 4 Apr 2023 at 11:42, Rylan Harper @.***> wrote:

I've always been a fan of Gridsome, as I've mentioned in this thread last
year. It really helped me learn a lot as a developer when I first started
out in 2019 dealing with APIs and all that. The early discord community was
full of really helpful developers as well. However, while it's not
official, I feel this is definitely a dead(dying) project and would
recommend migrating to Nuxt3. Most CMS platforms are supported within the
Nuxt(3) Modules ecosystem and if not, you can use nuxt-content for
markdown or the nuxt-graphql-client module to connect to graphql (similar
to what Gridsome offers).
—
Reply to this email directly, view it on GitHub
https://github.com/gridsome/gridsome/issues/1289#issuecomment-1495220446,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A3QGZ22W6SL6A22HQUHHXJTW7N4CBANCNFSM4PHM5YPQ
.
You are receiving this because you commented.Message ID:
@.***>

Hi 👋
Took a look at gridsome-vite, I’ll be somewhat blunt -
I’d not waste more than 5 seconds already invested on that codebase. Sorry.
I need Gridsome with Vue3 and all security fixes. Slim down all
dependencies and take default plugins to 1. That’s mandatory.
Likely I’d whack the app Architecture into shape so it’s easy for future
maintenance. Add more debugging and defensive coding to make building
friendly.
I’d want it complete by July - upgrade v3.x to track Vue current. And make
everyone’s life easier. Daily builds and monthly version releases.
Or I’m not wasting my money.
I use a patched version for debugging, have fixed meta-static and got
semantic SEO plugins for all major entity types already if that helps.
I imagine a slim core and a bundle of -starters that include useful groups
of plugins with all dependencies updated and security patches. They’d need
to Vue3 complaint or not included. Most core plugins are agnostic to Vue3
anyway  - file system, GraphQL,  moat formatters. The one plug-in is the
basic -starter.
Need dependencies clean enough that they don’t conflict, so they all
-starters gotta be updated for a release.
It maybe fairer to rename the codebase with attribution coz I won’t be
gentle.
What do you think?
If you still keen to contribute - I’m all ears. Especially around core bugs
and any essential -starter for you.
—

Reply to this email directly, view it on GitHub
https://github.com/gridsome/gridsome/issues/1289#issuecomment-1495668393,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A3QGZ23TXI7J6FTF2RGVWYLW7PUYJANCNFSM4PHM5YPQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi Rylan. I got my threads crossed.
I sent two people the wrong response. So sorry ….
I have a side project to use Nuxt as replacement.
I’m willing to risk $10k towards Gridsome 3.x  - I have one other $
contributor so I’m happy.
Both have enough value to thrive. it’s kinda like  helping out a old mate
after tough patch.
Maybe rename it too coz I won’t be gentle on the codebase.
Anyways thanks for giving me good advice.
Cheers
-L-
On Tue, 4 Apr 2023 at 11:42, Rylan Harper @.***> wrote:

I've always been a fan of Gridsome, as I've mentioned in this thread last
year. It really helped me learn a lot as a developer when I first started
out in 2019 dealing with APIs and all that. The early discord community was
full of really helpful developers as well. However, while it's not
official, I feel this is definitely a dead(dying) project and would
recommend migrating to Nuxt3. Most CMS platforms are supported within the
Nuxt(3) Modules ecosystem and if not, you can use nuxt-content for
markdown or the nuxt-graphql-client module to connect to graphql (similar
to what Gridsome offers).
—
Reply to this email directly, view it on GitHub
https://github.com/gridsome/gridsome/issues/1289#issuecomment-1495220446,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A3QGZ22W6SL6A22HQUHHXJTW7N4CBANCNFSM4PHM5YPQ
.
You are receiving this because you commented.Message ID:
@.***>

What will gridsome 3 have over Vitesse?

Every new major release locked in to Vue

For those still relying on this incredible framework, I have published a fork with the latest dev of this repo + some minimal fixes and updates on top. @hjvedvik had committed many updates incl. the switch to Webpack 5 and Vue 2.7, but just hadn't published another version since Nov 2020.
I mainly wanted to make things compatible with Node 18 as I got tired of export NODE_OPTIONS=--openssl-legacy-provider and dealing with some sharp/Python related issues on Windows.
To use the fork, update your package.json and gridsome.config.js as such (get the latest versions):

That's about it. If you run into errors, try a clean install.

@a-kriya would other current gridsome packages work with this as well? I have a fork of gridsome-source-shopify which has been updated (2023), but I've made no direct changes to its dependencies from the original

@rylanharper I took a look at the package.json of your fork and it looks fine. Some plugins have a peerDep of gridsome which should be updated, but yours doesn't. I'm also using a few different plugins, but only with the filesystem source/markdown files. They all work. It's possible that there are some minor breaking changes to the data APIs of Gridsome since 0.7.3 that have been made, so you may need to account for them in your plugin if you run into any issues which should be apparent if you start your app with the forked Gridsome.

@a-kriya Thanks for creating this fork! Do you have plans to open up / fomralize development, i.e maintaining a changelog and. accepting pull requests? Because I have patches applied to gridsome locally that I would like to integrate if I were to switch to your fork.

@Narretz I'd think most people have either moved on to other frameworks or will not be aware of this fork, so I only plan to maintain this fork for personal use. My objective is to keep it compatible with the current Node LTS, and fix any bugs I come across. I can also accept PRs for bug-fixes and publish them in a release, but that's about it. If that sounds okay, you're welcome to submit your patches.

Some updates I want to share with those still here. I've been modernizing my fork of this project with the following changes already made:

fully migrate codebase from cjs to esm for core and all sub-packages
upgrade dependencies of all packages (barring some breaking major ones)
switch from yarn classic to latest npm (w/ node v20)
switch from jest to vitest with all unit tests passing

All the changes have been made in a way that lead to minimal breaking changes downstream so the docs will stay relevant. This is still a WIP and the branch is accessible at https://github.com/a-kriya/gridsome/commits/esm/. I'm writing here as a call for help: there are some issues that need to be resolved before the basic Gridsome commands can be tested. With the above changes, it's easy to get started. Simply clone, checkout the esm branch, run npm i and jump in the rabbit hole. I'm currently trying to fix all the e2e tests, so the npm test command is set to run project-simple.build.e2e.js. I will publish when all issues are resolved.

What do you think about getting in touch with the maintainer asking if your repo can be the successor? Whatever this could mean technically, i don't know.

@a-kriya Cool to see that your fork is still going. As for your call of help, I think it would be great if you could be a bit more specific, e.g. open a list of issues in your fork. Otherwise it's kinda cumbersome to see what exactly is missing and may lead to duplicated efforts as well.

What do you think about getting in touch with the maintainer asking if your repo can be the successor?

@chrisrueger The author of Gridsome has not interacted here in over 3 years now. If anyone's interested in my work, they can follow the fork. I am going to stop posting here. My intention is to improve the DX, fix some bugs that have been filed here, migrate to Vue 3 (merging changes that have already been made in vue-next-* branches here), and possibly switch from Webpack to Vite. This will be on my timeline, to help with my projects and my learning, so no promises and why it won't be true to call it a successor, just a fork.
@Narretz Good idea. I've enabled the Issues section and filed a ticket.


1 second delay due to retry occurs on every query

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.

Steps to reproduce
Upstream issue: https://github.com/NuGet/Home/issues/12195
Expected behavior
N/A

Actual behavior
N/A

Error details
No response
Environment data
N/A

Visuals
No response

Thanks for letting us know about this issue, this should be resolved once we move off the NuGet client APIs and onto the HTTP REST based APIs, following issue #653


vespa-deploy prepare writes to /opt/vespa

See https://github.com/vespa-engine/documentation/pull/2561 for details - testing on an EC2 instance with Docker, running as vespa user inside the container:
$ vespa-deploy prepare .
Uploading application '.' using http://localhost:19071/application/v2/tenant/default/session
Session 3 for tenant 'default' created.
mkdir /opt/vespa/.cloudconfig: permission denied
Instead of adding to documentation, we should make sure we do not write to /opt/vespa (see the discussion in https://github.com/vespa-engine/documentation/pull/2561) - the only places vespa writes to should be /opt/vespa/var and /opt/vespa/logs
This was tested using latest on March 14

Work note: in older versions, the Vespa CLI would default to /opt/vespa - this is fixed in recent versions (per @aressem), so just document that users must try with latest.
vespa-deploy still needs a fix, and maybe others

Fixed in 8.145.4 (will write to subdirectory of /tmp instead)


Allow for preloading of remote assets

At the moment we're only able to preload local assets (as the path is passed through the asset manager for resolution into a URL).  Support external assets, such as Google Fonts, would be really useful.

Closing as this repo is no longer maintained and will be marked as read-only.


How can I create a user who cannot view the chatbots and test sets which is created by admin

I am trying to create a user who cannot view or edit the chatbots/testsets created by admin.
How can I do that?
I tried to give the tester/guest role to a new user but the user still able to view the test sets and chatbots created by the admin

The user roles are there for controlling the actions allowed for a user.
For restricting the visibility of records, Botium Box Ultimate supports multi tenancy

Will it be coming in any of the upcoming Enterprise Edition.

It is already part of the Botium Box Ultimate Edition


Posting a comment

As a Ministry Coordinator and IAO analyst
I want a post a comment
so that I can share information on a file for better tracking on a request

Assumptions & Scope
This story is the first step for developing our notes section for the review request view of a particular FOI request. This first build will be focused on the Ministry coordinator view for the purpose of a MVP.
Character limit: 1000
What is IN scope?
This will be the space where the notes will appear on the review request view for Ministry coordinators
This will include the functionality to enter and save a request note by a user
What is NOT in scope?
Editing/deleting of notes by a user will be covered in a separate user story #
System generated messages from the application will be covered in a separate user stories #586, #
Acceptance Criteria
Scenario 1: Add a Comment

GIVEN a Ministry coordinator or IAO analyst is on the Comment page
WHEN he or she clicks on the t"Add a Comment" button at the top
THEN the field will become editable to add text

Scenario 2: Entering text

GIVEN the user has clicked 'Add a Comment'
WHEN the user has has entered text into the notes field
THEN the paper airplane icon turns blue and becomes active

Scenario 3: Posting a Comment

GIVEN the user has has entered text into the notes field
WHEN they click on the paper airplane symbol
THEN the comment will be posted and saved to the request
AND the posted comment will show: the full name of the user (LAST NAME, FIRST NAME, the date and time the comment was created, and the contents of the comment
AND Parent comments will displayed will be from newest to oldest

Scenario 4: Character Limit counter when posting a Comment

GIVEN the user has clicked 'Add a Comment'
WHEN the user has clicked into the text field
THEN a counter will display below the text field stating 'Characters remaining: XXX'
AND the counter will count down as the user adds characters
AND the counter will turn red when there are 25 characters remaining

Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)
Design
https://jacklyn808742.invisionapp.com/console/share/3W2O64AP5C/775202206
Definition of Ready

[ ] Is there a well articulated User Story?
[ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
[ ] If there is a user interface, is there a design?
[ ] Does the user story need user research/validation?
[ ] Does this User Story needs stakeholder approval?
[ ] Design / Solution accepted by Product Owner
[ ] Is this user story small enough to be completed in a Sprint? Should it be split?
[ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
[ ] Has the story been estimated?

Definition of Done

[ ] Passes developer unit tests
[ ] Passes peer code review
[ ] If there's a user interface, passes UX assurance
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Confirm Test cases built and succeeding
[ ] No regression test failures
[ ] Test coverage acceptable by Product Owner
[ ] Ticket ready to be merged to master or story branch
[ ] Developer to list Config changes/ Update documents and designs
[ ] Can be demoed in Sprint Review
[ ] Tagged as part of a Release
[ ] Feature flagged if required
[ ] Change Management activities done?

Just wanted to post here for awareness, spaces and line breaks are currently being counted towards the character count, not sure who is doing QA on this tickets but this is not a show stopper just should be added to a bug

Functioned as expected!


Community Support

love this app can't emphasis that enough. it would be great if it could be extended to support communities.
I got it working with a crude hack:
removed force:hasSObjectName as it's not supported
added in a apex method to get the object name getSObjectType()
equally could have just added a new design element where you get the sobjectname and it would have worked.
had some file visibility issues but on the whole for the demo it worked to give a good idea of the kind of custom code option.

As documented here and here, the interface force:hasSObjectName is not supported in communities.
This enhancement request would remove the interface and determine the sobject type per the record id instead. This may require a call to Apex.


Add Romania support

This PR just add Romania support.
Thanks you for your work.

Pull Request Test Coverage Report for Build 818

53 of 53 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 811:
0.0%

Covered Lines:
8766

Relevant Lines:
8766

💛  - Coveralls

Thank you very much for your brilliant work!
Merged on beta branch.
Cheers!
dr-p


Undocumented dependencies. Require a ~/.aws/config

cfn-lint version: cfn-lint 0.3.2 and 0.4.2 (at least)
Description of issue.
cfn-lint have an undocumented dependencies to the .aws/config file. (You have to run aws configure in order to run cfn-lint).
Otherwise, it fails with these error :
Traceback (most recent call last):
File "/{anonPath}/venv/bin/cfn-lint", line 11, in
sys.exit(main())
File "/{anonPath}/venv/lib/python3.6/site-packages/cfnlint/main.py", line 33, in main
args.override_spec, formatter))
File "/{anonPath}/venv/lib/python3.6/site-packages/cfnlint/core.py", line 53, in run_cli
matches = run_checks(filename, template, rules, regions)
File "/{anonPath}/venv/lib/python3.6/site-packages/cfnlint/core.py", line 312, in run_checks
matches.extend(runner.transform())
File "/{anonPath}/venv/lib/python3.6/site-packages/cfnlint/init.py", line 807, in transform
matches = transform.transform_template()
File "/{anonPath}/venv/lib/python3.6/site-packages/cfnlint/transform.py", line 106, in transform_template
sam_translator.translate(sam_template=self._template, parameter_values={})
File "/{anonPath}/venv/lib/python3.6/site-packages/samtranslator/translator/translator.py", line 57, in translate
deployment_preference_collection = DeploymentPreferenceCollection()
File "/{anonPath}/venv/lib/python3.6/site-packages/samtranslator/model/preferences/deployment_preference_collection.py", line 30, in init
self.codedeploy_iam_role = self._codedeploy_iam_role()
File "/{anonPath}/venv/lib/python3.6/site-packages/samtranslator/model/preferences/deployment_preference_collection.py", line 89, in _codedeploy_iam_role
ArnGenerator.generate_aws_managed_policy_arn('service-role/AWSCodeDeployRoleForLambda')
File "/{anonPath}/venv/lib/python3.6/site-packages/samtranslator/translator/arn_generator.py", line 22, in generate_aws_managed_policy_arn
return 'arn:{}:iam::aws:policy/{}'.format(ArnGenerator.get_partition_name(),
File "/{anonPath}/venv/lib/python3.6/site-packages/samtranslator/translator/arn_generator.py", line 44, in get_partition_name
region_string = region.lower()
AttributeError: 'NoneType' object has no attribute 'lower'
Specifying a region with -r in cfn lint doesnt fix the issue.

Shoot. It’s the AWS SAM package we use to transform servlerless templates.  I thought we had worked a way around this. Let us see if we can do anything there. Our goal has always been to not rely on a network connection to lint.  I would like to also not require that file but need to do some digging. Thanks for pointing this out.

I followed it to SAM too.
I have been able to workaround it by setting an environment variable
AWS_DEFAULT_REGION which will be taken as value if there is no region precised (if i understand correctly the SAM code)

I feel like there's been a discussion on the SAM side about defaulting to us-east-1.  Let me see if I can dig up the issue on their side.

I'll see if we can work around this, or pass along the cfn-lint region to SAM.

Ah, remember this indeed, I'll add a ticket/PR in SAM.
Issue is in this lineL https://github.com/awslabs/serverless-application-model/blob/master/samtranslator/translator/arn_generator.py#L39
If no region is specified is uses Boto to load it. Which uses the "default" aws configuration for this. That method has Region as an input parameter, but in the calling method above (https://github.com/awslabs/serverless-application-model/blob/master/samtranslator/translator/arn_generator.py#L22) it never passes the region.
I'll see if I can open up the flow in this process so we can actually pass along the region

A workaround based on the SAM code could be using an Environment Variable (AWS_DEFAULT_REGION)

@kddejong In what extend is setting the environment variable in the linter an option?

good question @fatbasstard I would need to do some more research on that but I would think if it isn't set and it wouldn't be intrusive maybe we can set it for them... at least to  use the Transform functionality for SAM.

Fixed in v0.5.0.  Please validate and we can re-open if needed.


Add linting for .py

We need linting for PRs with .py scripts

This issue is being closed as a preparation step before archiving the repository.  See the README for more detail.


Add Disable and Enable Mouse Acceleration Tweaks

Adds tweaks to toggle mouse acceleration.

Looks good, very useful when using Windows in a VM as well.


Should we support loading models stored as safetensors files on HF?

I noticed that with certain versions of hugging face hub, above version 0.19 I think that models loaded to HF get saved as safetensors instead of .bin files by default and we don't currently support loading a safetensor model in our from_pretrained method, I don't know a lot about safetensors apart from skimming through the documentation page but seems it might be quicker to load models with them, be a bit more secure and also gives you a bit more model transparency on HF (shows some metadata without opening the file in the HF UI)
Wanted to open a discussion here on whether it would be worth moving to saving models in this new format and supporting loading them? Or at the very least adding support for loading them so we can have an option of which format we save them in? Keen to hear your thoughts @peterdudfield @dfulu @AUdaltsova, thanks

Thats a great idea, would need to update the from_pretrained and the save method? Perhaps worth doing once to see the speed ups.


Improve performance of symlinking

Right now symlinking includes a lot of intensive file operations:
https://github.com/boltpkg/bolt/blob/d2ca298ed057b4b9c2f05fe4e6d45f645ddc04e2/src/utils/fs.js#L48-L109
Basically every single symlink() we create we do the following operations:
await mkdirp(dest)
await lstat(dest)
await rimraf(dest)
await symlink(dest, target)

This is terrible for performance, with 500 Bolt packages needing just 10 symlinks each we have 5,000 symlinks which turns into 20,000 file operations not including the overhead of Node/libuv and internal operations of mkdirp/rimraf/etc
As part of running the install process we aggregate all of the symlinks we need to create, so I think we could make this much more optimized by manually writing out only the operations we need.
We might be able to optimize it even more by doing readdir()'s with withFileTypes and either assuming the symlinks are good or using readlink() to verify them cheaply

Sweet. Just so I understand the idea here is to only link files that aren't already there essentially?
One other thing we could consider, we currently symlink all root bin files into all packages. I think the idea was to go back and only do the ones that were required? This might be a little problematic (or maybe good depending on how you look at it) as it'll probably show a lot of places that we use binaries without declaring their dev deps...

Technically the symlinks we're adding in Bolt are 100% unnecessary, I only wanted them for the potential future of having a .bolt directory with virtual installs. But I'm not sure we're going to go down that route anymore.


Xilinx US+ Configuration Flow Control Interface incorrect

I believe _run_cfg_fc_logic for usp_model.py should be combinational instead of clocked to match xilinx behavior
also it appears the _run_cfg_fc_logic is missing the sel == 0000 case

I wrote that based on the documentation, which TBH isn't really all that clear on the precise behavior.  Do you have a simulation or ILA trace that indicates what the behavior should be?  You're right that the 000 case is missing, but TBH I'm also not sure if all of the other cases are completely correct.  Well, except for TX credit available, which I'm pretty sure is correct (and is the only one that I actually use in designs).  And the UltraScale model presumably has the same issue.
Also, I have not bothered to implement cfg_fc_npd and cfg_fc_nph....these signals do not appear to work correctly on the actual hardware (they get stuck at 0), so there isn't really any point in trying to reverse-engineer exactly how they're supposed to work since AFAICT they're completely useless.

thanks for the clarification of the state of these interfaces
I too agree the precise behavior is not clear from the documentation
This is all I have so far, which suggests the selection is combinational, assuming they aren't double registering it

TBH, double registering would make more sense than combinatorial.  But I guess either is possible, I think some more ILA captures are necessary, particularly under load so the values can be examined as stuff happens.

appears you are correct, that it is double registered

Hmmmm.  It really looks like it's actually only single registered.  Right?  fc_sel of 0 selects "receive credits available to the link partner", which I suspect reports infinite completion credits (cplh/cpld 0).  And that's exactly what you see here: cplh/cpld is zero one cycle after fc_sel is set to 0.

do you mean 2?
fc_sel is set 0 then 2 cycles later cplh/cpld is 0,
possibly my terminology that I use is different to yours,
as I see it,
first capture is fc_sel is held for 2 cycles, and fc_xx changes with it,
second capture is fc_sel held for 4 cycles, and fc_xx is delayed by 2 cycles

Oh, you're holding it for 2 clock cycles?  I guess there is a two-cycle delay, then.  It's not super obvious how long things are held for on the ILA trace.


fixed mods bug

State key is wrong.

Coverage remained the same at 82.026% when pulling faad8f4c55fd9edd24c83efc95e17b4e12f4083c on fix-mods-bug into 5e5ee82a1ce549b0d778d511df4f6a1f884d14ee on develop.

Coverage remained the same at 82.026% when pulling 00e979fa556395048c30a4907f802835dc81e99d on fix-mods-bug into 5e5ee82a1ce549b0d778d511df4f6a1f884d14ee on develop.

Coverage decreased (-0.1%) to 81.877% when pulling ed071bea52fa95c7a75a74e2672e641dd718e705 on fix-mods-bug into 5e5ee82a1ce549b0d778d511df4f6a1f884d14ee on develop.


Upgrade grpcio to 1.37.0

Since grpcio releases a new minor version every week, block upgrades
to before the next major version.

See here for the grpcio frequency: https://github.com/grpc/grpc/releases


Support different cable drivers/settings inside the same supercluster

What would you like to be added:
Support for different cable drivers inside the same supercluster.
Why is this needed:
Once we start supporting cable drivers with meaningfully different features (sorry if I’m insulting any existing cable driver), e.g. #674, various scenarios involve mixing cable drivers. For example, a supercluster could contain three clusters, one of which should only be connected to using encrypted connections, but two of which may be connected to using unencrypted connections (because they’re connected by a private link). So we’d have three connections, one unencrypted and two encrypted, presumably using different cable drivers.

bump

bump

bump

bump

bump

bump

We think this is tracked elsewhere but can't find the Issue live on the Issue scrub.

Related: https://github.com/submariner-io/enhancements/pull/4


fix fix no data error when read hive table on cosn

Proposed changes
Issue Number: close #32779

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run feut

run feut

run external

run external


Camera image is very dark

Take a look at this SO question: http://stackoverflow.com/q/28418962/562769
The reference image (take with JavaScript, but the same webcam and lighting situation) is much brighter and more details are visible. Why is that the case?

This was answered here: http://stackoverflow.com/a/34687991/562769
However, an explanation should be in the docs.


[python-sdk] Remove requests dependency

What type of PR is this?
/kind bug
/kind dependency
What this PR does / why we need it:
It replaces requests dependency with urllib.request from the python standard library in git_release.py (called by setup.py) in the python sdk. We need to get rid of the requests dependency to fix the setup.py bug that calls the requests package before installing it.
Which issue(s) this PR is related to (optional, link to 3rd issue(s)):
Fixes #195
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
NONE

Tested both locally and from the branch:
pip install git+https://git@github.com/gbolmier/ormb.git@hotfix/python-sdk/remove-requests-dependency#subdirectory=extern-sdk/python

works as a charm on my side 🚀

Tested both locally and from the branch:
pip install git+https://git@github.com/gbolmier/ormb.git@hotfix/python-sdk/remove-requests-dependency#subdirectory=extern-sdk/python

works as a charm on my side 🚀


Managed Private Endpoint in Synapse workspace deployment Task

Hi,
We have a scenario where we do not want to deploy Development MPEs into different (Test/Prod) as they point to different resources. However, we also do not want to leave orphaned objects in the target that are not in the deployment.
The following settings remove the MPEs and the orphaned objects not in the build.
DeleteArtifactsNotInTemplate: true
DeployManagedPrivateEndpoints: false

The following settings deploy the Development MPEs to Test/Prod which isn't relevant and also removes the existing MPEs and orphaned objects that are not in the build.
DeleteArtifactsNotInTemplate: true
DeployManagedPrivateEndpoints: true

Removing the settings and allowing for the default ignores the MPEs but leaves in place the orphaned objects that are not in the build.
I need this task to
Remove the orphaned objects that are not in the build and leave the MPEs alone that already exist in Test/Prod and not deploy the development MPEs.
Could you please look into the issue?
Thanks
Toby.

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

ID: de000363-1626-b5b3-2e13-bff9c8855955
Version Independent ID: ff8b1409-77fe-1d98-4131-8ce7bdd16c6d
Content: Continuous integration & delivery in Azure Synapse Analytics - Azure Synapse Analytics
Content Source: articles/synapse-analytics/cicd/continuous-integration-delivery.md
Service: synapse-analytics
Sub-service: cicd
GitHub Login: @liudan66
Microsoft Alias: liud

Thanks for reaching out! We have assigned the issue to the content author to further review this and provide an update as appropriate.
@liudan66 - Could you please review the above requirement from user and share your inputs? - Thank you

Hi guys,
Any update on that issue?
I have the exact same scenario in my current project.
There is definately a need of igoring any private enpoint that is already in the target envirnoment
Thanks
Markus

Hi
"There is definately a need of igoring any private enpoint that is already in the target envirnoment"
I think everyone has this scenario, they just don't know yet.
Any update guys ? Or workaround ?

I realized that this issue is in https://github.com/MicrosoftDocs
not the best place for an application issue. I will open a support ticket and make reference to this one

We also have a need for this feature. What is the current status on this?

@RoBal42  I have updated this thread, hope it will help
https://github.com/Azure/Synapse-workspace-deployment/issues/73

@stetou
Thank you for the update!

@stetou
Thanks for this, this works now.
One this to update is the name of the definition file has changed in synapse from template-parameters-definition-v1.json to template-parameters-definition.json
The newly named template file template-parameters-definition.json now exposes the MPE properties, the old one did not.
Also, the following template works fine and fqdns is only used by the default MPEs and the groupId does not need to change. This reduces the number of parameters produced in the ARM template.
  "Microsoft.Synapse/workspaces/managedVirtualNetworks/managedPrivateEndpoints": {
    "properties": {
      "privateLinkResourceId": "=:-privateLinkResourceId:secureString"
    }
  }


Scorigami Percentage

I'm not sure how the Scorigami Percentage does it's math but it doesn't seem to account for games with very big scores. For Example, 11/19/2018 MNF game was at 51-54 with over 3 minutes to go which should be 100% chance of Scorigami since a score that high from both teams has never happened but instead the percentage was around 96%.

Unfortunately I didn't design the prediction algorithm so I wouldn't know how to fix it. But what I'm guessing the problem is is that it is only checking scores up to a certain limit and the missing 4% was above that limit.


Creating synthesizer for new languages in Merlin

I want to use Merlin to synthesize voices in Bangla (Bengali).
Can anyone guide me to the steps of creating new languages in Merlin? Besides the data-set, what language-specific tasks do we need to perform? I believe the modifications must be done in the front-end (festival).
Any step-by-step instructions, or links to any existing online tutorials would be appreciated. Thanks in advance.

Hi Arif - got your email. Thanks for reaching out to me directly, however I am not an expert in the Merlin package here. So perhaps others will be able to give you better and detailed info. It looks like other issues on this repository report that it can be done in other languages.
Yes you need to set up some front-end pre-processing that is specific to your language. For example, you'll want to have a part-of-speech tagger trained up (I would recommend StanfordNLP tagger) to identify content words. You'll need some lexicons also in the Bangla language. You can do this with G2P (you'll need to train it for your language) or if you already have the lexicons that is fine but you'll want some support for OOV words. Also take a look at your questions file to make sure that the questions matches the pre-processing. Watch out for utf-8 codepoints - I would recommend using SAMPA instead of IPA in your lexicons. Then you will need to use your front-end processing and questions file to generate your label files.

@rhoposit Thank you for your reply. It'd give me some initial ideas. I already have some of the tools (g2p, lexicon). Hopefully, I can get started from this point. Thanks again.

FYI there are some resources here [1], also there is a rough voice here [2]
1 - https://github.com/googlei18n/language-resources/tree/master/bn/merlin
2 - http://tinyurl.com/voice-builder

Thank you @pasindud  for pointing out the resources.
 What changes do I need to make?


"Error: invalid argument at pathToArray" with multi entrypoints and DDL configuration

Hey @glenjamin, I keep getting the following error:
Error: invalid argument
0|react-ap |     at pathToArray (/Users/damz/Desktop/react-app/node_modules/memory-fs/lib/MemoryFileSystem.js:44:10)
0|react-ap |     at MemoryFileSystem.mkdirpSync (/Users/damz/Desktop/react-app/node_modules/memory-fs/lib/MemoryFileSystem.js:139:13)
0|react-ap |     at MemoryFileSystem.(anonymous function) [as mkdirp] (/Users/damz/Desktop/react-app/node_modules/memory-fs/lib/MemoryFileSystem.js:279:34)
0|react-ap |     at asyncLib.forEach (/Users/damz/Desktop/react-app/node_modules/webpack/lib/LibManifestPlugin.js:55:31)

In this setup https://github.com/damianobarbati/react-app/tree/hotreload when developing I have my webpack config exporting an array with:

dll bundles
app bundles (which requires dll bundles)

I followed the steps mentioned in the README with no luck, here what I did differently from master branch:

add entry: https://github.com/damianobarbati/react-app/blob/hotreload/package.json#L39
add hotmodule plugin: https://github.com/damianobarbati/react-app/blob/hotreload/config/webpack.config.js#L177
apply the middleware https://github.com/damianobarbati/react-app/blob/hotreload/index.js#L29

Repro:
git clone https://github.com/damianobarbati/react-app/tree/hotreload
git checkout hotreload
yarn build:dev #run webpack build
yarn serve:dev #run koa server
pm2 logs #watch server logs

I'm totally stuck on this, can anybody help me?

I don’t really have time to look into this, but my initial advice would be to try using the normal command line compiler and see if you get the same error - which is usually the case - then you’ll know the issue is a general webpack config problem

@glenjamin thanks for replying.
I don't quite get what you mean with "try using the normal command line compiler".
Do I have to not fire webpack separately when using webpack-hot-middleware?
I thought the reason for this module was to have a separate webpack running instance and a separate web server working together.
Furthermore if webpack-hot-middleware was launching its own webpack instance whenever the server is restarted/reloaded because of back-end files modifications then webpack would be restarted along with it.
I'm pretty confused now.
BTW: firing webpack as always (from command line) works flawlessly, even with this modifications I listed.

Using the command line compiler was just a debugging suggestion, many of the issues posted here happen regardless of the hot-middleware setup. By running without the server often we can rule out the server as the cause.
Do you still get the error if you omit hot-middleware but keep using dev-middleware?
The stack trace suggests an issue with the way memory-fs and lib manifest plugin interact. Memory-fs is only used by webpack-dev-middleware.
My advice would be look at the code for the lib manifest plugin to check which paths it uses from config, and then carefully check the values of those paths in the generated webpack config.


feat(cli/playbooks): add --for-collection option

--for-collection option generate meta playbooks only for specific collections (can be multiple)
Generate meta for tdp-collection:
tdp playbooks --for-collection tdp

Generate meta for tdp-collection-extras:
tdp playbooks --for-collection tdp_extra

Which issue(s) this PR fixes

Fixes #235
Additional comments

Agreements

[x] I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004.
[x] I hereby agree to grant TOSIT a copyright license to use my contributions.

Not sure why but with tdp-getting-started both tdp playbooks --for-collection tdp and tdp playbooks --for-collection tdp_extra are giving me a meta dir with empty playbooks as a results

Not sure why but with tdp-getting-started both tdp playbooks --for-collection tdp and tdp playbooks --for-collection tdp_extra are giving me a meta dir with empty playbooks as a results

It give me a meta dir with empty playbooks when using tdp playbooks without option but with --for-collection tdp or --for-collection tdp_extra it is working for me. Do you have a correct .env with correct TDP_COLLECTION_PATH defined ?
For push is for fix the problem without option.

Not sure why but with tdp-getting-started both tdp playbooks --for-collection tdp and tdp playbooks --for-collection tdp_extra are giving me a meta dir with empty playbooks as a results

It give me a meta dir with empty playbooks when using tdp playbooks without option but with --for-collection tdp or --for-collection tdp_extra it is working for me. Do you have a correct .env with correct TDP_COLLECTION_PATH defined ?
Force push is for fix the problem without option.

I figured out my issue. I have the collections as symbolic links in my environment:
tdp-getting-started-ln git:(master) ✗ ll ansible_collections/tosit
total 16K
lrwxrwxrwx 1 leo leo 33 Jan 31 10:58 tdp -> /home/leo/TOSIT-FR/tdp-collection
lrwxrwxrwx 1 leo leo 40 Nov  7 14:21 tdp_extra -> /home/leo/TOSIT-FR/tdp-collection-extras
lrwxrwxrwx 1 leo leo 36 Jan 30 16:15 tdp_observability -> /home/leo/TOSIT-FR/tdp-observability
lrwxrwxrwx 1 leo leo 47 Nov  7 14:21 tdp_prerequisites -> /home/leo/TOSIT-FR/tdp-collection-prerequisites

It works when I make a hard copy of the collection in the ansible_collections/tosit dir.

The collection name to use for --for-collection option is the directory name I think so if you use tdp playbooks --for-collection tdp-collection it should works.

tdp-collection

Indeed it works like this :+1:


MissingPluginException (MissingPluginException(No implementation found for method scanBarcode on channel flutter_barcode_scanner))

I'm implementing payments in my app with Stripe which requires the flutter_stripe package (https://github.com/flutter-stripe/flutter_stripe#android).
To work it requires Using FlutterFragmentActivity instead of FlutterActivity in MainActivity.kt: example:
https://github.com/flutter-stripe/flutter_stripe/blob/79b201a2e9b827196d6a97bb41e1d0e526632a5a/example/android/app/src/main/kotlin/com/flutter/stripe/example/MainActivity.kt#L6
When using FlutterFragmentActivity the barcode scanner throws a MissingPluginException:
MissingPluginException (MissingPluginException(No implementation found for method scanBarcode on channel flutter_barcode_scanner))
Flutter doctor:
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.0.6, on macOS 11.4 20F71 darwin-x64, locale pl-PL)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.1)
[✓] VS Code (version 1.57.1)
[✓] Connected device (2 available)
• No issues found!
michalklepaczko@Mac-mini-Michal ios % flutter doctor -v
[✓] Flutter (Channel stable, 2.0.6, on macOS 11.4 20F71 darwin-x64, locale pl-PL)
• Flutter version 2.0.6 at /users/michalklepaczko/flutter
• Framework revision 1d9032c7e1 (8 weeks ago), 2021-04-29 17:37:58 -0700
• Engine revision 05e680e202
• Dart version 2.12.3
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
• Android SDK at /Users/michalklepaczko/Library/Android/sdk
• Platform android-30, build-tools 30.0.2
• 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-6915495)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 12.5.1, Build version 12E507
• CocoaPods version 1.10.1
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 4.1)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
[✓] VS Code (version 1.57.1)
• VS Code at /Applications/Visual Studio Code.app/Contents
• Flutter extension version 3.23.0
[✓] Connected device (2 available)
• LDN L21 (mobile) • 26EBB18626163512 • android-arm64  • Android 8.0.0 (API 26)
• Chrome (web)     • chrome           • web-javascript • Google Chrome 91.0.4472.114
• No issues found!

https://github.com/AmolGangadhare/flutter_barcode_scanner/issues/128
This would resolve the problem.


fix: pkg miss depd punycode

https://github.com/bestiejs/punycode.js/issues/86

Can we close this since original PR not actual and been closed too? Node is about to deprecate embedded punicode sometime, but it still works, and i don't like to change working things.

we depd in react component,  uglify-js compress will failed because of punicode is code with es6

IMHO you have the same problem as author of previous PR - should tune your bundler, to properly stub builtin packages.

I also encountered the same problem, probably when will this pr be merged

For those who come across this post, in my case I solved it for React Native using this: npm install --save-dev rollup-plugin-node-builtins

Same problem when import * as markdownit from 'markdown-it'; to angular, see https://github.com/angular/angular-cli/issues/9508#issuecomment-391490414

I just hit this as well on Node 14, kinda confusing to explain...
I had a webpack plugin that has punycode v2 as an explicit dependency so v2 was the version in node_modules/punycode/. If it wasn't for that webpack plugin, no doubt I'd have hit the "module punycode not found" error - but instead because there is no explicit dependency on punycode package in markdown-it, it was pulling in the v2 found at node_modules/punycode/.
This caused my bundle to blow up in IE11 because punycode v1.4.1 is the last version that works in IE11.
I fixed IE11 support by explicitly adding "punycode": "^1.4.1", to my package.json, because that forced node_modules/punycode/ to be v1.4.1 which is the version now being pulled into markdown-it.
If this MR was merged and the dependency made explicit, it wouldn't have had to spend the last few hours working our what was happening, so this MR gets a :+1: from me.

I just hit this as well on Node 14, kinda confusing to explain...
I had a webpack plugin that has punycode v2 as an explicit dependency so v2 was the version in node_modules/punycode/. If it wasn't for that webpack plugin, no doubt I'd have hit the "module punycode not found" error - but instead because there is no explicit dependency on punycode package in markdown-it, it was pulling in the v2 found at node_modules/punycode/.
This caused my bundle to blow up in IE11 because punycode v1.4.1 is the last version that works in IE11.
I fixed IE11 support by explicitly adding "punycode": "^1.4.1", to my package.json, because that forced node_modules/punycode/ to be v1.4.1 which is the version now being pulled into markdown-it.
If this MR was merged and the dependency made explicit, it wouldn't have had to spend the last few hours working our what was happening, so this MR gets a :+1: from me.

Hi!
I jsut got an issue related to this while trying to use the package on Deno. They have a compatibility layer for node but they do not polyfill any deprecated APIs. This does mean that on deno it is immpossible to run this package, as punycode is missing.
It would be really awesome if this could be fixed!

Also running into this as an issue. I just had punycode randomly resolve to a 2.x version that was coincidentally installed by something else. This should be added as a declaration to the package.json, especially now that punycode in Node has long been deprecated and can no longer be considered "builtin".

Running into same problem:

 ERROR #98124  WEBPACK

Generating development JavaScript bundle failed

Can't resolve 'punycode' in 'C:\Users\alexa\apf2\.yarn\cache\markdown-it-npm-13.0.1-dcb1a8675c-faf5891d38.zip\node_modules\markdown-it\lib'

If you're trying to use a package make sure that 'punycode' is installed. If you're trying to use a local file make sure that the path is correct.

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
        - add a fallback 'resolve.fallback: { "punycode": require.resolve("punycode/") }'
        - install 'punycode'
If you don't want to include a polyfill, you can use an empty module like this:
        resolve.fallback: { "punycode": false }

File: .yarn\cache\markdown-it-npm-13.0.1-dcb1a8675c-faf5891d38.zip\node_modules\markdown-it\lib\index.js:14:19

failed Building development bundle - 72.482s
ERROR in ./.yarn/cache/markdown-it-npm-13.0.1-dcb1a8675c-faf5891d38.zip/node_modules/markdown-it/lib/index.js 14:19-38
Module not found: Error: Can't resolve 'punycode' in 'C:\Users\alexa\apf2\.yarn\cache\markdown-it-npm-13.0.1-dcb1a8675c-faf5891d38.zip\node_modules\markdown-it\lib'

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
        - add a fallback 'resolve.fallback: { "punycode": require.resolve("punycode/") }'
        - install 'punycode'
If you don't want to include a polyfill, you can use an empty module like this:
        resolve.fallback: { "punycode": false }
 @ ./.yarn/cache/markdown-it-npm-13.0.1-dcb1a8675c-faf5891d38.zip/node_modules/markdown-it/index.js 4:0-34
 @ ./src/components/Projekte/Daten/CurrentIssue/index.js 14:0-37 22:19-29
 @ ./src/components/Projekte/Daten/index.js 24:0-42 183:48-60
 @ ./src/components/Projekte/ProjektContainer.js 17:0-28 122:40-45 273:44-49
 @ ./src/components/Projekte/index.js 27:0-50 202:40-56 234:38-54 247:39-55
 @ ./src/pages/Daten.js 15:0-46 131:62-70
 @ ./.cache/_this_is_virtual_fs_path_/$virtual/async-requires.js 16:11-18:5
 @ ./.cache/app.js 17:0-52 30:87-34:1 33:29-42 36:27-40 30:0-34:2

Please solve this!

It makes no sense to not declare dependencies. Only creates problems. These problems can be hard to solve, depending on the dev/build environment.

I understand that there is config you can do for some bundlers to resolve this. If we could move to using the package that would help have less foot guns for the library and make it easier to use.
Please move to using the npm library instead of the other polyfills. At the moment I am hand patching the lib to handle this on my side.


DataRow to Card/Other Widget

Is there any way that we can data rows to cards in the small screen. E.g. mobiles etc

Not sure I got your question

Seems to be duplicate of #63


Does LLaVA's package dependencies conflict with those of MedCLIP?

Question
When I replace the vision encoder of LLaVA with MedCLIP, the following error occurs.
RuntimeError: Error(s) in loading state_dict for MedCLIPModel:         Unexpected key(s) in state_dict: "text_model.model.embeddings.position_ids".

What was the resolution here?
I encountered the same issue:
from medclip import MedCLIPModel, MedCLIPVisionModelViT
# load MedCLIP-ViT
clip_model = MedCLIPModel(vision_cls=MedCLIPVisionModelViT)
clip_model.from_pretrained()
RuntimeError: Error(s) in loading state_dict for MedCLIPModel:
	Unexpected key(s) in state_dict: "text_model.model.embeddings.position_ids".


[ALLUXIO-2706] Specify null variable in BlockInfo.java precondition check

https://alluxio.atlassian.net/browse/ALLUXIO-2706

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/15422/
Test PASSed.


Add olafoo to Contributors list

@olafoo, I can't seem to resolve conflicts in this pull request. This could be because the branch or your fork associated with this pull request has been removed. Could you try this again?


monaco-typescript doesn't provide trigger reasons in signature help

In https://github.com/microsoft/TypeScript/issues/42361, a user reported that signature help pop-ups were showing up unnecessarily in the TypeScript Playground. I believe that this is because monaco-typescript doesn't funnel along a signature help trigger reason, and I think the existing code confirms that:
https://github.com/microsoft/monaco-typescript/blob/5a17ea5a5db63dc63a3c8741db1ce4ed71cb69ee/src/tsWorker.ts#L216-L221
Please let me know if I'm mistaken - I'm not that familiar with the codebase!

Thanks for the fast turnaround @alexdima!

Thanks for the fast turnaround @alexdima!

User with issue reporting in :) I doubt I can be of assistance but if I can let me know, since several people have issues reproducing it. I have no issue reproducing it in the playground or vscode.
I will at the very least report back here when it works :)

User with issue reporting in :) I doubt I can be of assistance but if I can let me know, since several people have issues reproducing it. I have no issue reproducing it in the playground or vscode.
I will at the very least report back here when it works :)

The original issue works fine now in VScode 1.53.0! :)
I do have a followup issue however, but I have no idea if it's directly related so I left it in the other thread.


Env based configs

I need to deploy this application in qa and prod environments, how do I add env based configs. mainly I want to change parameters in the utils/config.js (api path etc..)

yes it works thanks, I did something like this
[https://github.com/malinda1986/antd-admin/pull/1/commits/3f1250de2ed84bbad86149a97164bcfa199d610e]

@superlbr  that doesn't work if we host on the s3 bucket, node env is not available
the best way is to override the .umirc.js for each env
https://umijs.org/guide/env-variables.html#how-to-configure

@malinda1986 you‘re right


[FLINK-25041][e2e] Improve error handling for missing environment variables in E2E tests

What is the purpose of the change
There are several points where the E2E tests check that an environment variable is nonempty before proceeding with the tests, such as the E2E_TARBALL_CACHE. Usually, this results in a friendly error message stating "You have to export the E2E Tarball Cache as E2E_TARBALL_CACHE".
However, if running the scripts with nounset during development, this results in an E2E_TARBALL_CACHE: unbound variable error, which is less friendly to the user.
This PR changes these instances to use parameter expansion for these variables, so that even with nounset, the user recieves the friendly error message for a missing environment variable.
Brief change log

E2E test script error handling for unbound environment variables has been improved

Verifying this change
(Please pick either of the following options)
This change is a trivial rework
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

@fapaul Sure, thats a good idea. I will add those.

@fapaul Hey Fabian! Was wondering whether you would be able to take another look at this.


site is blank via Opera Mini Android

At least the old version. 7.6.40234, on my Android 4.1 device. The pages are mostly blank; occasionally some title text gets through. Just downloaded and tried the new Opera Mini and it also failed the same way. 8.0.1807.91281.

Are you able to pin it down to anything more specific than that? Is it possible to check out the console and see if some errors are being thrown? I could imagine some browser API is not supported or something?

Is this true with the new site?

Looks a lot better, seems like most everything is there! Thank you.

Cool, thanks for the report!


Toleration is only applied on first replica

I am deploying cp-helm-charts to AKS with customizations to the Value.yaml file.  I have a nodepool created that I want to dedicate to Broker, and another I want to dedicate to Zookeeper.  I have created these nodepools with the following command (All of my examples are of broker, but the same behavior occurs for Zookeeper as well.):
az aks nodepool add --resource-group [rg] --cluster-name [name] --name broker --node-count 1 --enable-cluster-autoscaler --min-count 1 --max-count 10 --node-vm-size Standard_DS3_v2 --node-taints dedicated=broker:NoExecute
I then have defined a custom value.yaml and passed this file in when installed cp-helm-charts.  This yaml file has the following toleration defined for both broker and zookeeper (I am not including all the configuration, for clarity):
## ------------------------------------------------------
## Kafka
## ------------------------------------------------------
cp-kafka:
  ## Number of Kafka brokers
  brokers: 3

  ## Taints to tolerate on node assignment:
  ## Ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
  tolerations:
    - key: "dedicated"
      value: "broker"
      operator: "Equal"
      effect: "NoExecute"

The first replica that is created applies the toleration rules just fine.  But the replicas that are created after do not apply the toleration.
Here is a screenshot of broker pods as a visual (notice the nodes assigned for first replica is broker, while others defaulted to nodepool):

I checked the yaml of the pods, and toleration is empty on last 2 pods.

I'm facing the same issue, any workaround for this problem?


Support for encoding - CP1145

Can you please add support for .
CP1145 code page

Thanks for the request!
Added https://github.com/AbsaOSS/cobrix/pull/729
Will merge to 'master' today. Will add more related code pages and then release a new version of Cobrix.


read_workbook()

Awesome package!
Have you thought of a read_workbook() that would bring in an entire workbook as a list of data.frames? The use case would basically be doing exploratory work on a workbook which you haven't seen before when you don't want to open the workbook itself. Sometimes those big gnarly excel sheets can be very slow to open or will crash on opening. It might be nice to be able to flip through sheets in R even when you didn't know which sheet you were looking for.

There's an internal xlsx_sheets() function that lists the sheet names. Would you want more than that + lapply()?

As, I didn't know about that function. For myself today I think xlsx_sheets() and lapply() work great,  but when I was first coming to R after doing a lot of Excel work, I was pretty scared of the apply family of functions, so it wouldn't have worked well. I guess I was mostly thinking of a convenience function for new R users. I bet there's a set of people who would appreciate reading in a whole workbook with a one-liner.
Also it helps with the realization that


Serialize float without convertion to double

When serializing float values, fsPrimitiveConverter converts it to double. This adds some very small floating point jitter which leads to saving values using much more space in Json:
0.800000011920929
0.600000023841858
0.300000011920929
instead of normal 0.8, 0.6, etc.
When deserializing this value to float, all this noise won't fit to float and it's actually useless.
You can try it out yorself and see different result with simple code:
Debug.Log(0.1f); // prints 0.1
Debug.Log((double)0.1f); // prints 0.100000001490116
Debug.Log(0.1); // prints 0.1

If serializable type is float, convertion to double must not be preformed.

Okay, I'll try to get this fixed - but it may be a little while before I can get to it. The only solution I can think of right now is a bit hacky.

I should comment that the hacky solution is to store the float inside of the fsData boxed referenced, (and transparently change it to a double as needed - probably use the same logic for long values as well). The JSON printer will be aware that it was a float and would not cast it to a double when emitting JSON.

Thanks. This is not urgent at all, but definetly need to be fixed.


Verify no leaking requests on heavy load

We don't have tests that allow us to verify our cache implementation. In order to do so, I propose:

Setting up a local testnet in the safe-config that would allow us to point to mock servers running locally
Use a mock server to simulate the particular instance of the core service (Link to suggestion)
Stress the local instance of the GW, with high levels of concurrency, in order to verify that we do in fact route the traffic into our redis and not leak requests (Link to tool)

In my opinion it is expected that under heavy load we currently have some duplicate requests.

What we saw as a risk during last week, was that if we have concurrent duplicate requests that result in cache non-hits, all of them would be allow to request against the core-service. Introducing some form of locking mechanism over a pool of connections to redis could help address this. This issue would allow to setup the environment to develop that.

That is why I said with the current implementation.
Before changing to something where we have a lock in redis for ongoing requests and a waiting logic that checks if the request was done, it doesn't make sense to test it. So we should link an issue here that would implement this.

Also since it isnproposed to add a mock service for the core services, why not also for the config service?
Would another first step be to add integration tests for the client gateway based on which this is tested?

That would be a good alternative to adding test data in staging, but as the setup was cheaper, by simply adding a chain_id for our testing, I simply proposed the "cheapest" option

That is why I said with the current implementation.
Before changing to something where we have a lock in redis for ongoing requests and a waiting logic that checks if the request was done, it doesn't make sense to test it. So we should link an issue here that would implement this.

I would be happy to hear about this in more detail because I don't think I follow your meaning.

to clarify I want to make sure how much stress on the system it takes to bypass redis and hit the core service even for requests that should be fetched from the cache, as last week the core service seemed to receive more requests than they should. This is simply a exploratory task.

Does it really make sense to do this in the described way? You can easily estimate this, by looking at internal requests times (as this primarily depends on how fast the core services respond).

To me it does seem to make sense, as I don't think I can come up with that estimation easily.

I think this would take some time to set up and test, and I think it makes sense just testing it with regular rust tests

Decided that we should create an issue about not firing multiple requests to the core services for the same cgw request.


Do you have examples of JupyterCAD working in google colab?

I am able to install JupyterCAD in colab, but unable to display/render any objects.
#@title Create new CAD doc
from jupytercad import CadDocument

doc = CadDocument()

# Create a box, create a sphere, then cut the box using the sphere as a tool
doc = doc.add_box().add_sphere().cut()

display(doc)

This cell would return
<jupytercad_lab.notebook.cad_document.CadDocument object at 0x7f721829c790>

Unfortunately that cannot work in the current state of JupyterCAD.
I guess we could technically implement support for it by making a build of JupyterCAD that does not require jupyter collaboration to run in the front end

Thanks for the quick reply.
Google colab support would be a wonderful support, since it lowers the barrier of entry for sharing :)
Feel free to close as not planned/backlog/etc. Thanks.


WebSocket connection to 'wss://host/websocket' failed:

Hi Julian,
I was trying to setup chat server on local, and able to done it, but I'm getting a websocket error for chat.
PFA

Could you please help me what I'm doing wrong.
Server is up in 3000 port.
-Neelesh

Closing working fine :)


rdt/config: allocate cache lines up to requested total

Commit b302441eb1bfd08c92c4ef5d42537f6a7d71797c was too aggressive in
saving cache lines. We want to allocate up to the requested total
percentage of cache lines requested. Excess cache lines made available
by rounding errors in the previous passes are "donated" to the last to
be resolved (i.e. biggest) partition.

Codecov Report

Merging #24 (2aac94d) into main (cb5e1a6) will increase coverage by 0.20%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
+ Coverage   77.38%   77.59%   +0.20%
==========================================
  Files           6        6
  Lines         955      955
==========================================
+ Hits          739      741       +2
+ Misses        143      142       -1
+ Partials       73       72       -1

Impacted Files
Coverage Δ

pkg/rdt/config.go
97.14% <100.00%> (+0.47%)
:arrow_up:

Continue to review full report at Codecov.

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


It is impossible to search for big zip file, the error code 504 appears

Steps to reproduce:

Ingest big zip file with ~5M size
Make following search query via DNS or HAProxy:
http://<>/<>/1.0/?op=search&qp=system.path:/<>/1.0/config-cse.zip,system.indexTime%3E1516626820916&with-data&format=json

Actual results:

the response is stuck
The response time is 80 sec as results the request is cut by HAProxy and failed

Feels like it is related to #436