Add the ability to update and redeploy a stack created from a git repository

It would be useful to keep the git url and the credential of a stack deployed with a git url and to provide a api/ui to trigger an update.
Configuration of a stack is as important as code and should be persistent and versioned, git is the perfect tool for that.

Do you mean the ability to trigger a git pull and then redeploy the stack?

Yes

@deviantony  I am thinking of

Slider "Authentication"
- Username
- Password
Rename existing button label from "Update the stack" ==> "Update"
New button with label "Redeploy"
what do you think ?

In my opinion, the credentials should be persisted in the stack data.
If the stack was created from a repository, a new button should be added "Pull and deploy".

@deviantony I didn’t go with this approach because credentials could change Between saving with data and redeploy attempt(rare cases but possible). Also in one of thread you mentioned that portainer does not save these github credentials.

I would also like this feature. Until then I wrote a small script to update stacks and hooked it into git - https://github.com/docker-how-to/portainer-bash-scripts

@rahulruikar if you're adding basic auth it'd be great to also be able to use a (read only) SSH key like how Github has deploy keys.

Following the discussion in https://github.com/portainer/portainer/pull/1793#issuecomment-384302019
As I'm not keen to store unencrypted credentials for git repositories inside Portainer I think that the way to go is to implement https://github.com/portainer/portainer/issues/1752 first and then work on this one.

Ok..I will start working on #1752 this week.
On Thu, 26 Apr 2018 at 12:18 am, Anthony Lapenna<EMAIL_ADDRESS>wrote:

Following the discussion in #1793 (comment)
https://github.com/portainer/portainer/pull/1793#issuecomment-384302019
As I'm not keen to store unencrypted credentials for git repositories
inside Portainer I think that the way to go is to implement #1752
https://github.com/portainer/portainer/issues/1752 first and then work
on this one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/portainer/portainer/issues/1753#issuecomment-384303314,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHXNPSgOjCLCHiH5wMz2reZV7Jg52g8hks5tsIWmgaJpZM4S3Cmi
.

--
Sent from Gmail Mobile

@shyd
Not sure about the sidebar files, but if they're located inside the repository and part of the stack deployment should work.
And yes, webhooks for this feature is in our plans.

Hi @deviantony
Any news on this?
Is it on your road map yet? If yes, do you eventually have any eta?

@somq I am currently working on this feature - will let you know once it's ready for testing :)

@ssbkang great news thanks!
Will be happy to test it, if you need any more help let me know. I can test it as soon as API endpoints are reachable just to let you know.
Just to understand, do you have any idea if it's a matter of days, weeks, more?

@ssbkang Happy to hear this is worked on... we are looking at having a ci/cd with gitlab to deploy stacks but if this is handled by portainer... all the better.
I understand that the functionalities thaht are worked on are:

update stack from compose file in github
webhook to trigger and update of the stack

As i am curious:

how are webhooks foreseen?

like what is done with services
is caller specificities included?
github and gitlab may be able to send webhooks but maybe some degree of filtering may be needed (commit, release, branch, tags, ...). They may send a webhooks for a broader scope of change than what is desired in portainer.

is there a way to follow up the code changes? (https://github.com/ssbkang/portainer?)

@deviantony is there news from this... from what i saw @ssbkang did some work already so i don't want to overstep anything there. I think the first step would be to look at pull request #2972.
--i just want to help on this as this would help us very much keeping a simple workflow. currently the alternative is to go ci/cd which would bypass portainer stack management--

@cblomart yes, I am aware of that and I need to review the backend implementation in #2972
However, I am a busy on other topics at the moment but this is in our backlog.
If you want to help, feel free to give a go to the implementation in #2972, it is available through the API only at the moment and can be tested via portainerci/portainer:pr2972. Ask @ssbkang for more details.

@deviantony  thanks. i am now running on the pr of @ssbkang. I will need to check how to use the api.

@deviantony Any update on this ?

No update yet, wasn't able to do the review of #2972.
Feel free to give a try to portainerci/portainer:pr2972, see the comment above.

Gave a try but not easy to test as you need to go trough api.
We do use portainer but have more and more pression to store our stack definition elswhere (than in portainer). I think storing them in git and using reposistories is a good way to gitops but we need flexibility from this (update/redeploy).

I don't think the PR addresses what @cblomart would like. It creates private/public keys and stores them in boltdb to be then used/configured with your SCM?
Haven't spend too much time in the code, but isn't that somewhat of a security issue? I don't think Portainer should enter the business of creating security keys.
We usually setup deploy accounts and provide them with read-only access to required repositories and then this user can git clone (or git pull).
In order to secure this further, you can use tokens (on Github: Personal Access Tokens) which limit the scope, etc. further. I am sure Gitlab has something similar. These tokens can be revoked. Where to store these (e.g. in vault?) is another question.

I would also like the ability to re-deploy a stack from a git repository as well. But currently the credentials are not saved by portainer.
So a simple "re-deploy" is a bit of a challenge this way. Can be achieved though with various API calls to populate "the fields".
I would like to have the ability though to prevent changes on the UI when this happens so it's always from git. Maybe an explicit override ("You are about to make changes to a git-based configuration. These changes are not permanent and likely overwritten on a re-deploy.")

IMO this feature is important and doesn't need to be blocked on landing git-over-SSH.
There are valid uses for it unauthenticated (public compose config, config repo is public behind the firewall), and even with the user/pass config, the credentials could simply be prompted for each time the redeploy button is hit.

I second the value and importance of having stack config updated from GIT even starting with just unauthenticated git repos. Our teams use local and public github repos that don't require any auth since there are open source projects.

Hi I just tried to find out about the current status of this issue and all its side-issues.
Can I help out somewhere to get this feature.
I would love to have the ability to redeploy a stack based on a compose-file in a git repo.
Maybe even make it possible to poll and auto redeploy in a configurable intervall.

Just saw this - would be nice! It's quite easy to simply copy paste a compose file from github into portainer, so I was surprised that the currently functionality basically only does that.

Hey guys, this seems like a great idea. I'd like to get the ball rolling on this as there seems to be a lot of people interested 👍
@deviantony I don't think #2972 needs to be blocking this feat. IIRC it pertains to ssh cloning, but to begin with we could simply prompt for credentials/PAT for a private repo

If its easier for everyone, we have a slack server where we are quite active. There is a dev channel there that would be a great place to engage with you all and get your input on this

@itsconquest sorry, I simply don't get slack. How is the status on this. It sounds like a critical issue to deal with, since after creating a stack from a git repo you essentially have to remove it.
Or is there a workaround I missed?

Yeah. Slack is a challenge, since most of you are down under. ;)

We still can not auto-update docker-compose from deploy by git repository for now.
It's easy to use in Kubernetes, called GitOps.

How is going on on this improvement?

How is going on on this improvement?

Would this fix the problem which prevents to use the start/stop stack button from the stack page on Portainer 2 ?
in my case, when restarting a stack on a docker swarm cluster, the service using images from private repos do not start (No such image)

will it be one-way (re-deploy) or two-way? I mean, if you change something in the UI, will it commit/push to the repo as well, or it will only be able to pull and re-deploy but not push?

@upcFrost our vision is that Portainer should keep in sync with a git repo and not the other way around, so we'll think about our UX around stacks that are "synced"  but at the moment it was stated to be one-way I think.

deviantony: will be this feature available in 2.2 ? maybe another question, will be in portainer support for notifications/webhooks ? for example, if stack is succesfully synced, out of sync, failed, etc ? thanks

@lukasmrtvy I can't ensure that this will be present in the next release of Portainer at this stage. But with the lot of activity around this topic, you can expect us coming back with some ideas to be discussed in here and we'll consider the existing discussion/ideas in that topic for sure.

For me, it would also be a very useful feature.
Also nice to have a webhook for updates of the stack created from git.

I would certainly use this feature.

will it be one-way (re-deploy) or two-way? I mean, if you change something in the UI, will it commit/push to the repo as well, or it will only be able to pull and re-deploy but not push?

I agree, pushing a commit should save a lot of work as it simplify the project management.

We build a CLI tool to do this. It's not 100% compatible with stock portainer right now (because authentication is a bit messed up when you use SSO), but we are considering opensourcing it later.

will it be one-way (re-deploy) or two-way? I mean, if you change something in the UI, will it commit/push to the repo as well, or it will only be able to pull and re-deploy but not push?

I agree, pushing a commit should save a lot of work as it simplify the project management.

To be fair, with one-way sync I don't really see the point of linking portainer to git. It will make migration to portainer easier, that's true, but it basically means losing the changes history with this migration. Or just using portainer as a read-only UI, which would be a bit strange

This Issue was opened 3 years ago and is very popular. But until now this feature was not implemented.
I read the discussions and @deviantony said it will be there in Q2 of 2021.
Is there a beta version of it at the moment or where can I find that part of code to test it?

@Mr-Markus there is no beta available at the moment, the development on this piece is planned to start next week! We're targeting CE 2.5 at the end of May but as we have many things in our work pipe and a few delays have happened already it might be part of CE 2.6 at the latest.

I was just about to open a new ticket when I deployed a stack using git Repository, and then it didn't offer a re-deploy after I'd made changes option. And I'd made deploy tokens and everything.

It didn't make CE 2.5? When will CE 2.6 be released?

@HazeTheMaze Do yourself a favour and use some proper CI tool ( like concourse ) and https://github.com/docker/compose-cli. Then You will get UI, gitops, autosync, credentials, notifications...

@HazeTheMaze this did not make it to CE 2.5.0 and we're now targetting CE 2.6.0, I will share a preview version of this feature when this is available as we are still working on this.

For those following this thread, we now have a preview version available via the following image: https://github.com/portainer/portainer/pull/5139
Happy to hear your feedback about it if you have some time to give it a try.
This is a development build, it is not recommended to run it in production environment.

Tried it out! Good start! Deployment and updating functionality worked just fine here.
Minor comments:

Username/access token is not saved so... updating from a private repo isn't too smooth
Seems to a minor bug where if you try to update from a private repo without providing a user/password it loses track of the docker-compose file on the local filesystem (or maybe erases it? Need to experiment)
As previously mentioned, the ability to push changes up would also be awesome 😀
Wondering if a future enhancement to periodically check for changes to the git repo and automatically redeploy would be considered... or would that be stepping too much into the CI/CD realm

Wondering if a future enhancement to periodically check for changes to the git repo and automatically redeploy would be considered... or would that be stepping too much into the CI/CD realm

Would be awesome. We have a repository with all the Compose files we need for the company's internal (IT) services. Of course you can do that with CI/CD, but would definitely be easier if Portainer could do it. And if periodic checks should be implemented, one additional feature request: It would be perfect if you could schedule the check (e.g. every saturday at 3am after the nightly backup and when the employees are rather not working).
Anyway, the ability to redeploy from a git repo is already a big improvement, so thank you!

Aside from a "polling" way to detect a change in the repo, webhook called from github/gitlab/whatever on commit/PR would be nice too.

I think using a webhook would be a more common way. It provides the possibility to deploy changes instantly when changes occurs.

@deviantony certainly looks great! Some questions/feedback:

"prune services" should imho not be hidden in the "Editor" tab. I might want to use that even if I am not editing the stack definition at all
It would be great if we had an option to save the auth for a private github repo. The scenario for us would be that person X with access to the private repo sets up the stack and then person Y without the need to have access to the repo could update the stack. Is that something you want to support?
Setting env variables seems to work only on the initial deployment. If I redeploy, I can still see them in the editor, but the deployment doesn't apply them and they are gone in the editor afterwards as well

Deployment its perfect, the only annoying thing is Git Auth introduction in every pull, adding support of storage a global git credentials or per stack would be perfect! 👌🏻
Apart from that, thank you!!! this feature is something I have been waiting even before knew I needed it.

Thanks a lot for all the feedback everyone!
We're aware that this version is not perfect but we think it is a good base to start and we'll continue enhancing it.
@MooRogue

Username/access token is not saved so... updating from a private repo isn't too smooth

I agree, I'm not a huge fan of the UX but it's a very simple base that we can build on in the future (I would like us to introduce a proper Git provider integration in the future allowing you to authenticate to a 3rd party git provider - github, gitlab...- and persisting only the required information).
In the meantime, we're starting with this and we'll introduce the ability to persist it with a future enhancement.

Seems to a minor bug where if you try to update from a private repo without providing a user/password it loses track of the docker-compose file on the local filesystem (or maybe erases it? Need to experiment)

We'll have a look to see if we can confirm that one, again this is a development build so there might be a few other bugs here.

As previously mentioned, the ability to push changes up would also be awesome

This is not something that we have in our plans, at the moment, our current vision is that if you have a stack definition stored in Git, you should always update it in Git (supporting pushing might introduce sync issues). But I'll keep it in mind.

Wondering if a future enhancement to periodically check for changes to the git repo and automatically redeploy would be considered... or would that be stepping too much into the CI/CD realm

We already have a piece of work in progress that is a continuation of this feature and that will allow you to toggle automatic update of the stack, by toggling this switch on you'll be able to:

Periodically pull and update
Use a stack webhook to be set in your CI/CD - cc @kumy  and @waja

Here's a quick glance at our design for it:

@gabschne this might be of interest for you as well, I'll keep your feedback aside for an enhancement allowing a more advanced schedule.
This enhancement would also allow you to persist git credentials (we recommend the use of a personal access token here) - cc @fdelucchijr
@tfenster

"prune services" should imho not be hidden in the "Editor" tab. I might want to use that even if I am not editing the stack definition at all

Thanks, indeed it might be interesting to have prune action now instead of our previous "Update and optionally prune". I'll keep track of this enhancement.

It would be great if we had an option to save the auth for a private github repo. The scenario for us would be that person X with access to the private repo sets up the stack and then person Y without the need to have access to the repo could update the stack. Is that something you want to support?

Yup, see my comment above regarding our following enhancement of the feature.

Setting env variables seems to work only on the initial deployment. If I redeploy, I can still see them in the editor, but the deployment doesn't apply them and they are gone in the editor afterwards as well

Thanks, we'll investigate that one.
Thanks again for the feedback everyone!

Well... now relative paths are an absolute necessity, aren't they? Talking about #2046
The horror to imagine that doing all the manual leg work to deploy a stack - necessary for every update...
Completely throws out UX, automation and TBH the error was a bit of a challenge to look up in GitHub's search. Google eventually led me to that error being a ticket already, yes, but I've been trying to deploy this particular stack for a LONG time.
Bonus request: alias files like... a repo I'm trying to use utilizes some config files and the '.env' file in the root of the repo directory, but only with '.example' appended to the filenames. You're supposed to normally git clone the repo, 'cp' the files to generate the proper files without the example ending and edit them as you please.
This is complete bonkers of course, would be hella cool if I could tell Portainer to look for the '.env.example' file and use it as '.env' instead. Sadly the creator of the app I'm trying to use doesn't really have more than docker's CLI on their mind.
I doubt this will be the last app of that kind I'll come across. Right now I'm band aiding this by having a personal repo set up for this from which I deploy and intend to switch the repo URL to the official repo later when I got it to deploy because I won't need that initial batch of files anymore. The drawback of my approach vs. just aliasing and overriding the config parts I need changed from within Portainer are that I'll obviously miss out on any official additions to those config files that may be needed later on down the road, not getting new (needed) default settings I may not even need to change.

Is the intention of "Additional Paths" to provide multiple "--compose-file" parameters effectively?
I hope thats what it means.

@GlassedSilver I'll add proper relative paths support to the list of enhancements for this feature.
Regarding the alias files like request, I'm not sure yet as we can enter the realm of custom naming here and it might be tricky to manage (the .env.example not being a standard).
@chrisbecke yes, that's we're also aiming to provide this ability with our following enhancement.
This feature is of importance to us and we have a lot of enhancements that are gonna follow but they will come incrementally. I'll open a separate issue to track all the enhancements and create a new place of discussion after this one is added.

Closed via https://github.com/portainer/portainer/pull/5139
I'll open a separate issue to track and discuss further enhancements on this feature.

wow. do i really need 1000 lines of code to send a docker-compose up to portainer? or am i missing something

@eihns I'm not sure what you're talking about here.
For the others that are interested in continuing the discussion on that topic and potential enhancements, I've opened a separate issue: https://github.com/portainer/portainer/issues/5223 that we can use to discuss!


Remote Client Failing to Register in CloudWatch Logs Master

Hi,
We have followed our standard process to add new accounts to the stack by way of update to the CF template. There are no issues reported and we can see the account ID in the remote_account_ids field in the Dynamo DB Config field. The instance does not appear in the CloudWatch Logs - ec2-instance-scheduler-master-logs. I have tried removing and re-adding but this has made no difference. Can you advise how we can further investigate this.
Many thanks.
Neil.

I'll assume that this is for the v3.0.3 release of the solution. If you are on a different version this same procedure should still work but the log stream names may be different.
Take a look in the {stack-name}-scheduler-logs log group in CloudWatch and look for logs matching Scheduler-{service}-{account}-{region}-{date} for the new account you just on-boarded. you can also look at the SchedulingOrchestratorHandle-{date} logs to see if there were any issues loading schedules or initializing scheduling events for on-boarded accounts.

Thanks CrypticCabub. We are still on v1.5.1. I have checked the scheduler logs and cannot find a log group for EC2 for the account we created. I also cannot find the log group SchedulingOrchestratorHandler-{date}. Has this come after v1.5.1. I wonder if we should update the stack? Thanks.

in 1.5.1 I believe the orchestrator logs are named CloudWatchEventHandler logs
If there are no scheduler logs for the new account created, then I suspect there's a problem in the account registration. In 1.5.1 I know there was a behavior that would deregister an account if the role was inaccessible so it's possible that you just need to re-do the stack update and double check that the account-id is actually registered in the solution's config table.
v3.0.x removed the behavior because of exactly this sort of scenario. It also includes much better logging for scheduling decisions along with a number of bugfixes and security improvements, so I would recommend upgrading as soon as you are able.

I cannot locate the log file above. I have cloned the repository in GitHub but cannot locate a CFN template. I have tried the links here https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/aws-cloudformation-templates.html but just get a browser message with this site cannot be reached.

Are you still getting that browser error? My browser is able to download the CFN templates from the link you provided just fine, so mabe there's a security setting somewhere preventing access for you?
The github repo does not provide CFN templates as they have to be generated within the context of a specific host. The readme on the repo explains how you can deploy directly from the repo using cdk deploy or create your own templates using the build-s3-dist.sh script
And just in case it wasn't clear, the cloudwatch event logs file would be a log-stream within the {stackname}-scheduler-logs log group

Thanks for your help CrypticCabub. Seems to have kicked into life. I will however look to update as well.


Getting console errors when using jest.mock

When I mock a react component like this jest.mock('react-slick', () => 'div'); I get console errors for unknown props passed to <div> tag. I know these errors don't mean anything in this case, but it's quite annoying to see them in the output:

Is there a way to disable these errors? Maybe just don't pass any props to the component when it is mocked?

If you want to bypass console logs you can mock it (e.g. console.log = jest.fn()) in your tests.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions. You'll find more on Jest docs help page. Thank you :)


Builder pattern methods

Throughout the code base there are many methods looking like builder pattern methods. I have three concerns with that:

Not all properties have corresponding builder methods. I'd suggest to make them mandatory, thus consistent, but it's not the most important thing :)
They are inconsistent in naming. MSBuildSetting has 3 different namings already (Set, With, and Use). I suggest to agree on a common naming, and change the existing methods (with a new major version; and maybe issue warnings upfront?!).
They are not returning a new object. Let me explain why returning a new instance is important/useful:

First, the builder pattern should work like that. So the status quo is a bit surprising.
Secondly, it supports use cases where a common instance is shared with multiple invocations of the same task

var commonNuGetPackSettings = new NuGetPackSettings {
    Authors = new[] { "..." },
    Owners = new[] { "..." },
    Symbols = true,
    BasePath = "...",
    OutputDirectory = "...",
    ... // many more
}
var firstPackageSettings = commonNuGetPackSettings
    .WithFiles(...);
var secondPackageSettings = commonNuGetPackSettings
    .WithFiles(...);

I hope this outlines the benefit good enough. It also applies to MSBuildSettings, for instance if you want to separate Compile from CodeAnalysis  for reasons of parallelism. Please note that the builder pattern doesn't necessarily require immutability.

So this received quite some approval. I think it is a general design decision that should be made, also for new code. @patriksvensson, @phillipsj, I remember you guys had something to add, so I'd like to kindly bump this issue.

I can't officially speak for the team, but my recommendation, and the one by @patriksvensson, is to create an addin with the additional functionality. This will give everyone access to it and will also serve as a proof of concept.  It would also help clarify it to others how it works

@phillipsj this is actually no additional functionality. The methods are already there. Both, with inconsistent naming and surprising behavior. Also I don't think it's a good idea to put this into an add-in. The builder pattern is a well-known and straightforward pattern. Nothing fancy about it. Just modifying properties of objects in a fluent way. However, splitting only guarantees a harder time finding that functionality.

@matkoch Yes, there are some inconsistencies, but that is something we have to live with. We should however not introduce more inconsistencies in the code base without thinking it through how we want to APIs to be used. That's why it's better to battle test API improvements as addins until we know that is the way we want to go. (ping @phillipsj)

@matkoch I am participating in something very similar with the MSBuild 15 (Visual Studio 2017) integration. It is a very conservative approach, but the Cake API has been very stable, IME, and that is why they are taking this approach.  I know for a fact that I would more than likely use your addin in some of my builds.

Sorry but I don't understand 🤔 So far your response has been do it as an addin. But this doesn't solve anything.
First, it doesn't tackle the status quo. You've mentioned a stable API. At the same time you should ask yourself if you want to carry this burden with you. There will always be people asking:

Okay, this is called UseXXX, and that WithXXX...  UseToolVersion.

Breaking an API is per se nothing bad. You can always help fixing the problem early upfront by issuing warnings (ObsoleteAttribute). Plus - UseToolVersion as an example - there are usage counts of around 150 on GitHub. I think under those circumstances, changes are very acceptable.
Second and more importantly, it doesn't encourage any guidelines for the future. Given the fact that addins can be created any time by any developers, there will always be inconsistencies. Again and again. And because there is no consistency, you'll either never integrate any of them, or introduce breaking changes for those, who have been using the addins.

not introduce more ... without thinking it through

Delegating to 3rd parties, doesn't mean to think it through. After all, I've tried very hard to make this issue the place of thinking it through 😄

@matkoch I think we use With when you can set multiple values and Use when it's a single value.

@patriksvensson can you give an example? You mean multiple arguments?
What about the return a new instance stuff? Does it make sense for you?

@matkoch in general reasoning behind starting as an addin/module is that we can test & bake the API before we merge it into the main project. Addins can also be reved more quickly and in a safe way without risking bloating or creating unnecessary breaking changes in the core,
And if it proves to be consensus around the API then we can pull in a fully baked API. This is especially good when weren't 100% sure yet on value of refactoring.

@matkoch Example:
var settings = new MSBuildSettings()
   .UseToolVersion(..)
   .WithTarget("Clean")
   .WithTarget("Build");

Not sure I agree with the return a new instance stuff. Will need to think about it some more and talk with the rest of the @cake-build/team about it since it would require this change for all tools, and it's too big of a change.
Changes to this approach could be implemented as addins and make it opt-in for now.


[QA] Minigames | Unable to see the preview of Next Reward on quest system

Explorer Alpha build versions:
v0.34.0
Issue Description:

After unlocking the Mosaic Mania Watch, the Next Reward image is missing from the quest system menu.
In order to reach this issue we need to unlock a series of daily quests. So far, this issue was only presented after the watch but it might happen forward with other items as well.
STR:

Use te command /loadpx pejo to reach the Mosaic Mania Watch reward
Complete the quests
Check the image for the next quest reward

Evidence:

Additional Notes:

The image for the Color Pop Gun was missing. It should be appearing now after the Mosaic Mania Watch mission.

Checked on database and thumbnails folder, everything seems to be ok.
This issues could be probabily related to deployment not fully refreshed during orchestrator data updates.


Modern Web Acronyms list

Inspiration: https://twitter.com/kosamari/status/822199478115586052
We could do a better job of summarizing what our 12,000 acronyms mean in a single place :)
Initially, thinking:

H/2 - HTTP/2
PRPL - The pattern
RAIL - Response, Animation, Idle, Load
FLIP - First, Last, Invert, Play
SPA - Single-Page App
SW - ServiceWorker
TTI - Time To Interactive
FMP - First Meaningful Paint
FCP - First Contentful Paint
TTFP - Time to First Paint
PWA - Progressive Web App
TTFB - Time to first byte

PUSH (not an acronym, but often used without much context)
IE
FF
LOL
A2HS

rAF
rIC

came here to add rAF and found it already listed ;)

@petele would love to see this live under something like /web/glossary and work out a way to auto link to them when mentioned on the site (a stretch goal maybe)

Totally on board with this, will add it to the plan. Can I ask folks to please add definitions to their comments. I know most of them, but there are a few even I don't know!

Also adding Joe's list

OK, I've started the initial work for this in #4160. The glossary is a JSON array of terms and acronyms. It doesn't build the glossary yet, that'll be a next step.
Format for a term is:
{
 "term": "Add to Home Screen", // required
 "wordKind": "noun", // required for localization team
 "termType": "technical term", // required for localization team
 "acronyms": ["A2HS"], // optional
 "description": "TODO", // required to provide definition and for localization team
 "primaryLink": "/web/fundamentals/engage-and-retain/app-install-banners/" // optional, but link to key docs
}

Please feel free to add new terms and update any existing ones in the glossary branch.

Here's what a tech writing staff would do. In general:

Official and well-known acronyms should always be used and never shortened.
If an acronym is intended to help developers remember a concept it should be spelled out on first use with the acronym in parentheses, and the acronym used thereafter. For example an article about FLIP would on first use say, "First, Last, Invert, Play (FLIP)" and "FLIP" after that.
If it's just saving the writer from typing then it needs to go away completely. An example of this would be add to home screen. The abbreviation doesn't convey the concept and is completely opaque to anyone encountering it for the first time.

If I were king, here's how I'd apply these guidelines to the listed items.
H/2 - HTTP/2 - Always use HTTP/2.
PRPL - The pattern - Spell out on first use.
RAIL - Response, Animation, Idle, Load - Spell out on first use.
FLIP - First, Last, Invert, Play - Spell out on first use.
SPA - Single-Page App
SW - ServiceWorker
TTI - Time To Interactive - Spell out on first use.
FMP - First Meaningful Paint - Spell out on first use.
FCP - First Contentful Paint - Spell out on first use.
TTFP - Time to First Paint - Spell out on first use.
PWA - Progressive Web App - Spell out on first use.
TTFB - Time to first byte - Spell out on first use.
PUSH (not an acronym, but often used without much context) as in HTTP/2 Push Don't use. Always be specific about what kind of push and don't capitalize as though it were an acronym."
IE - Internet Explorer - I would generally avoid the abbreviation all together, though I suspect there's little harm in using it.
FF - Firefox - Same.
A2HS - Add to Homescreen Don't use

Glossary is a great idea, look forward to seeing it.
+1 to everything Joe said.

+1 to spelling out acronyms the first time they're used in a section

This landed in #5003 - To add new terms or definition, edit src/data/glossary.yaml


Initial Commit:  Plugin works for my single speaker system. I attempted ...

I attempted to build this for multiple speaker systems, but I have no way to test/troubleshoot it.
I'm not sure if this fits your programming style, but I tried my best.  I would love for someone with multiple speakers to test/add to this.  It may be a little while before I add speakers to my system.
The main purpose of this for me is to link it with my DIY home automation system.  I wanted to contribute to what I feel is a great project instead of just branching out on my own.
-Jeff McGehee

Version 0.10 of SoCo has all the stuff you need (snapshot, whole lot of fixes etc.)
It can be installed as any other Python package: https://pypi.python.org/pypi/soco/
The speaking bit needs to  either be in you own code, based on the examples out there, or be made into a plugin for general use.
Hope this helps, Cheers David

Version 0.10 of SoCo has all the stuff you need (snapshot, whole lot of fixes etc.)
It can be installed as any other Python package: https://pypi.python.org/pypi/soco/
The speaking bit needs to  either be in you own code, based on the examples out there, or be made into a plugin for general use.
Hope this helps, Cheers David

Hi @jlmcgehee21 and thanks for putting the stuff out here.
I'm a little in doubt about the status here, and the text-to-speech stuff is not my strong suit. Does this plugin represent functionality not already in SoCo (@jlmcgehee21, @robwebset, @DPH). At first glance I would say that it does, since it seems most of the existing text-to-speech stuff has been external scripts and this is made as a proper plugin. It might of course be very useful for @jlmcgehee21 to have a look at the code @robwebset published in #99, so if you want to continue working on the plugin and make a PR later, we can also do that.
I just wanted to check before I started reviewing.

After some review of the code in #99 and more testing with my pull request,
I think the best solution would be to modify #99 to function as a proper
plugin.  The use of the Snapshot class (which I didn't even realize existed
until I got some responses to my pull request) is much better than what I
tried to hack together.
My plan is to implement #99 as a plugin when I find some free time and
submit a new pull request then.  I think I'll go ahead and close this one.
Thanks for the awesome work you guys are doing!
On Fri, Jan 16, 2015 at 2:46 AM, Kenneth Nielsen<EMAIL_ADDRESS>wrote:

Hi @jlmcgehee21 https://github.com/jlmcgehee21 and thanks for putting
the stuff out here.
I'm a little in doubt about the status here, and the text-to-speech stuff
is not my strong suit. Does this plugin represent functionality not already
in SoCo (@jlmcgehee21 https://github.com/jlmcgehee21, @robwebset
https://github.com/robwebset, @DPH https://github.com/DPH). At first
glance I would say that it does, since it seems most of the existing
text-to-speech stuff has been external scripts and this is made as a proper
plugin. It might of course be very useful for @jlmcgehee21
https://github.com/jlmcgehee21 to have a look at the code @robwebset
https://github.com/robwebset published in #99
https://github.com/SoCo/SoCo/issues/99, so if you want to continue
working on the plugin and make a PR later, we can also do that.
I just wanted to check before I started reviewing.
—
Reply to this email directly or view it on GitHub
https://github.com/SoCo/SoCo/pull/267#issuecomment-70218603.

That sounds like a great plan.
One thing that might help you, with your next PR. We tend to stay pretty close with the python programming style defined in pep8 and by pylint, and I noticed quite a few style problems when I glanced this PR, which you would have to fix to get a PR pulled. So I would advice you to run pylint and pep8 checks on your code as you develop, to get to know the guide lines and to not have to worry about that in the review. You should note though, that we don't follow pylint religiously. Checks can be disabled, and there can be valid reasons to do so, but not very many ;)
Let us know if you run into problems running pylint and pep8 checks, that you can't information on with google.

Thanks for the tips. I have been developing with PyCharm which makes pep8
based suggestions.  I guess it's time that I stop ignoring them ;)
I do scientific coding professionally, so for the most part, any given
piece of code only needs to live long enough for me to get an answer.  It's
good for me to see/learn some proper developing techniques.
I saw that the existing plugins are coded with a heavy use of decorators.
Is that preferred styling for SoCo as well?  Just want to make any future
pull requests as painless as possible.
On Sat, Jan 17, 2015 at 5:24 AM, Kenneth Nielsen<EMAIL_ADDRESS>wrote:

That sounds like a great plan.
One thing that might help you, with your next PR. We tend to stay pretty
close with the python programming style defined in pep8 and by pylint, and
I noticed quite a few style problems when I glanced this PR, which you
would have to fix to get a PR pulled. So I would advice you to run pylint
and pep8 checks on your code as you develop, to get to know the guide lines
and to not have to worry about that in the review. You should note though,
that we don't follow pylint religiously. Checks can be disabled, and
there can be valid reasons to do so, but not very many ;)
Let us know if you run into problems running pylint and pep8 checks, that
you can't information on with google.
—
Reply to this email directly or view it on GitHub
https://github.com/SoCo/SoCo/pull/267#issuecomment-70361955.

I have a similar background to you (scientific and not trained as a software developer ;)), so feel free to take it with a grain of salt when regarding any advice that I give as "proper developing techniques" :D
I'm not sure which decorators you are referring to @staticmethod and @classmethod serve a particular purpose, but most likely what you have noticed are @property decorators. No, we have no preference for using decorators especially much, we use them when they serve a purpose. The @property for instance, is useful if you have a method, that essentially acts like a property (i.e. essentially just for reading out a value of something) but where the value needs to be calculated. I think probably the best example of the use of @property is the fictional Circle class, where you store the radius internally, but implement the diameter as a property. So, to put it shortly, no, we just use them when it makes sense (the cases above or any other time you need to wrap a functions in a start and end). Also, one should be careful about not overusing decorators, because they 'hide' code from plain sight and therefore can make it more difficult to read.


Update leicester codes

Asif and I have modified Lokesh's test classes to work with spack
We have also updated them to work with reframe v>=4.0
We have moved them out from the dirac folder to the same level as the other apps.
We have tested the new classes on our system here at Leicester and they produce similar results to the ones Lokesh ran before.
There is still some work to do, but this contains the most important changes.
Further work includes:

moving from University of Leciester private github repos (see corresponding spack recipes) to the repos managed by respective PIs (I will submit a PR for our spack recipes in the next week).
Expanding tests to run with more compilers. Currently they have only been tested for intel. We think some of the codes will require source code changes to run with gnu compilers.

First of all, it's great to see this coming together! However, a quick comment: I'd prefer to keep logically distinct changes separated. For example, upgrade to reframe 4 is already part of #111 (which is waiting on #102 to avoid conflicts, but the latter should be very close to be merged).
Heads-up: #102 will reorganise the tree structure of the benchmarks a bit, but also simplify some stuff: installation of dependencies will be more straightforward, and we don't need to use the horrible sys.path hack anymore to access the SpackTest module.

That's great to hear. Perhaps I will wait for #111 and #102 to be merged and then I can tidy our changes up a little bit.

Hi @giordano , do you have any update on the progress for #111 ?
Should I make a branch off of mg/reframe-v4 and make the changes there? Or should I branch off main?
In your previous comment you said:

First of all, it's great to see this coming together! However, a quick comment: I'd prefer to keep logically distinct changes > separated. For example, upgrade to reframe 4 is already part of #111

I did create a separate branch for upgrading to reframe 4 (TomMelt:update-for-reframev4) which I then created the branch TomMelt:update-leicester-codes from. However, maybe because I submitted the merge from my fork, the information is lost as the other branch doesn't exist here.
Unfortunately, we can't really separate our new tests from the update because our new tests rely on reframe v4 features. The old ones don't work at all. Let me know what you think is best :+1:

I am replacing this PR with #131 due to big changes in the layout of the repo.


Make List.generate() generator function optional, like Iterable.generate()

To get a sequence of integers in a List, we must do either of two suboptimal choices:

Start from Iterable<int>.generate() and use toList():

List<int> list = Iterable<int>.generate(n).toList();

Start from List<int>.generate() and explicitly type the identity function:

List<int> list = List<int>.generate(n, (x) => x);

I propose List.generate() on integers has the identity function by default, like Iterable.generate().

I propose the opposite: that Iterable.generate makes the argument required.
It's a bad design for a strongly typed language that Iterable<String>.generate(5) is allowed (and fails to cast an int to String at runtime).
To create a range of integers, there should be a function, method or class somewhere specialized for that.
Say
class Range extends Iterable<int> {
  final int _start, _end;
  const Range(int start, int end) : _start = start, _end = start <= end ? end : start;
  int get length => _end - start;
  bool get contains(Object? other) => other is int && _start <= other && other <= end;
  Iterator<int> get iterator => _RangeIterator(_start, _end);
}
class _RangeIterator implements Iterator<int> {
  int _next, _end;
  int? _current;
  RangeIterator(this._next, this._end);
  int get current => _current ?? (throw StateError("No element"));
  bool moveNext() {
    if (_next < _end) {
      _current = _next;
      _next++;
      return true;
    }
    _current = null;
    return false;
  }
}

That could be useful in many ways, and doesn't need an unsoundly typed constructor on Iterable.


Build against hnix master

The motivation for this branch is so that hocker and dhall can both be
used within the same dependency tree.
The context for this is that dhall requires megaparsec-7.0.0 or newer
whereas the latest hnix on Hackage only supports up to megaparsec < 7.0.
Since hocker depends on hnix that means that hocker is incompatible with
dhall if hocker depends on an hnix from Hackage.
However, the master branch of hnix on GitHub supports megaparsec-7.*, so
this change updates hocker to build against that.
Note that this shouldn't be merged until hnix pushes out a new release to
Hackage.

hnix-0.6.0 came out recently; it requires megaparsec 7.

Note that #44 was merged; you might wish to keep the Semigroup-related changes from it even if you discard its conditional compilation against older dependencies.

Suggested merge and #46 .


Add global flag for combining before contracting QN ITensors

This adds a global flag for reshaping QN ITensors into matrices before contracting, which can improve the efficiency for contracting high order block sparse tensors. It is basically the technique described in this comment: https://github.com/ITensor/ITensors.jl/issues/266#issuecomment-629369474
Here is a benchmark using the technique, which you can turn on and off with the functions enable_combine_contract!() and disable_combine_contract!():
using BenchmarkTools
using ITensors

function main(; Nmax = 8)
  # Don't warn about large tensor orders
  disable_warn_order!()

  for N in 1:Nmax
    println("#################################################")
    println("# order = ", 2 * N)
    println("#################################################")
    println()

    d = 1
    i = Index(QN(0,2) => d, QN(1,2) => d)
    is = IndexSet(ntuple(n -> settags(i, "i$n"), Val(N)))
    A = randomITensor(is'..., dag(is)...)
    B = randomITensor(is'..., dag(is)...)

    # Use standard algorithm, without combining first
    println("Contract:")
    C_contract = @btime $A' * $B samples = 5
    println()

    # Reshape the ITensors into matrices before contracting
    println("Combine then contract:")
    enable_combine_contract!()
    C_combine_contract = @btime $A' * $B samples = 5
    disable_combine_contract!()
    println()

    @show C_contract ≈ C_combine_contract
    println()
  end
end

which gives the results (using NDTensors#master which has some block sparse optimizations):
julia> main(Nmax = 8)
#################################################
# order = 2
#################################################

Contract:
  2.410 μs (76 allocations: 5.70 KiB)

Combine then contract:
  48.111 μs (899 allocations: 92.98 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 4
#################################################

Contract:
  11.329 μs (311 allocations: 24.73 KiB)

Combine then contract:
  111.227 μs (1628 allocations: 182.69 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 6
#################################################

Contract:
  119.332 μs (2125 allocations: 200.11 KiB)

Combine then contract:
  284.701 μs (4019 allocations: 470.45 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 8
#################################################

Contract:
  1.291 ms (16988 allocations: 1.75 MiB)

Combine then contract:
  1.250 ms (18801 allocations: 1.75 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 10
#################################################

Contract:
  13.555 ms (138908 allocations: 16.22 MiB)

Combine then contract:
  6.233 ms (103211 allocations: 8.28 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 12
#################################################

Contract:
  165.222 ms (1261274 allocations: 141.49 MiB)

Combine then contract:
  37.353 ms (492436 allocations: 41.43 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 14
#################################################

Contract:
  2.256 s (10387274 allocations: 1.24 GiB)

Combine then contract:
  187.437 ms (2158837 allocations: 187.26 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 16
#################################################

Contract:
  28.637 s (104661017 allocations: 14.86 GiB)

Combine then contract:
  1.416 s (17813407 allocations: 1.32 GiB)

C_contract ≈ C_combine_contract = true

You can see the crossover is now around order 6-8 ITensors, which is a bit better than the last time I checked.
An immediate way to make this work better, besides low-level optimizations of the combiner code, would be to fuse the two combiners/uncombiners into one operation. Currently, the QN ITensors are turned into matrix-like (order 2) ITensors by contracting two combiners sequentially. We could fuse that operation into a single operation and minimize the amount of work the combiner step has to take (minimize the number of permutations needed, for example). My guess is that, at least for this example, that could make this combining technique match the speed of the standard contraction method for all of the ITensor orders. Note that this example of parity symmetry is particularly suited for this technique, since the order 2 ITensors end up with only 2 dense blocks to contract, so for other symmetries like U(1) this may not help as much (for example I see a crossover at order 8-10 for this same example when I switch to U(1) symmetry).

(Also credit to Glen Evenbly for pointing out this alternative QN contraction technique.)

Great, this will be useful for testing at the very least, or as an advanced feature. Let's think in the future about whether we can toggle this option automatically for people using some heuristic (like the crudest one would be counting the number of indices involved in the contraction, whether contracted, uncontracted, or both; a better one might involve estimating or fully calculating the sizes and number of blocks before versus after combining, though that could be too expensive or tricky). It might be a difficult thing to get right or too much of a research frontier, though.
We should keep this in mind, by the way, for having discussions with the broader tensor computation community in the sense of showing that there are a lot of non-trivial things to think about regarding performance of block-sparse tensor contraction and it would be good for someone to make a common low-level library that incorporates tricks like these internally one day.

Right, it would be nice to have a heuristic, but I think it could be quite complicated (since it would depend on the order of the tensor, the number of QN sectors within each index, the number of nonzero blocks in each ITensor before and after combining, the type of symmetry, etc.). I was picturing that for now, a user would keep this off for something like DMRG, but then turn it on for algorithms that involve higher order tensors like MERA, TTN, and PEPS.
My hope would be that we could just make it so that it is always as fast or faster than not combining (Glen said he always uses this technique in his code, but he is often working with very high order tensors).
A complication with making this technique more general is that, at least right now, this relies on information about the QNs, which tells you what blocks can get combined. However perhaps this could be made blind to the QNs in some way.

Codecov Report

Merging #536 (1a44c36) into master (fc51de7) will increase coverage by 0.10%.
The diff coverage is 26.47%.

@@            Coverage Diff             @@
##           master     #536      +/-   ##
==========================================
+ Coverage   80.67%   80.78%   +0.10%
==========================================
  Files          41       41
  Lines        4192     3997     -195
==========================================
- Hits         3382     3229     -153
+ Misses        810      768      -42

Impacted Files
Coverage Δ

src/ITensors.jl
22.22% <20.00%> (-2.78%)
:arrow_down:

src/itensor.jl
75.11% <25.00%> (-1.81%)
:arrow_down:

src/decomp.jl
88.62% <100.00%> (-0.76%)
:arrow_down:

src/broadcast.jl
65.54% <0.00%> (-9.09%)
:arrow_down:

src/physics/site_types/tj.jl
58.92% <0.00%> (-6.08%)
:arrow_down:

src/physics/sitetype.jl
89.65% <0.00%> (-3.51%)
:arrow_down:

src/mps/dmrg.jl
74.57% <0.00%> (-3.04%)
:arrow_down:

src/physics/site_types/spinone.jl
84.31% <0.00%> (-1.97%)
:arrow_down:

src/indexset.jl
72.80% <0.00%> (-1.33%)
:arrow_down:

src/physics/autompo.jl
91.95% <0.00%> (-1.24%)
:arrow_down:

... and 27 more

Continue to review full report at Codecov.

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

Here are some updated benchmarks using the improvements in https://github.com/ITensor/NDTensors.jl/pull/53:
julia> main()
#################################################
# order = 2
#################################################

Contract:
  2.407 μs (64 allocations: 5.42 KiB)

Combine then contract:
  47.069 μs (887 allocations: 92.70 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 4
#################################################

Contract:
  10.741 μs (215 allocations: 22.23 KiB)

Combine then contract:
  108.055 μs (1616 allocations: 182.41 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 6
#################################################

Contract:
  101.901 μs (1357 allocations: 188.11 KiB)

Combine then contract:
  284.599 μs (3991 allocations: 467.80 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 8
#################################################

Contract:
  1.074 ms (10844 allocations: 1.63 MiB)

Combine then contract:
  1.291 ms (18789 allocations: 1.75 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 10
#################################################

Contract:
  9.830 ms (89756 allocations: 14.97 MiB)

Combine then contract:
  6.418 ms (103135 allocations: 8.23 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 12
#################################################

Contract:
  121.839 ms (868058 allocations: 138.49 MiB)

Combine then contract:
  38.362 ms (492424 allocations: 41.24 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 14
#################################################

Contract:
  1.675 s (7241546 allocations: 1.15 GiB)

Combine then contract:
  199.868 ms (2158697 allocations: 186.37 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 16
#################################################

Contract:
  22.563 s (79495193 allocations: 14.61 GiB)

Combine then contract:
  1.493 s (17813395 allocations: 1.32 GiB)

C_contract ≈ C_combine_contract = true

That mostly improves the uncombined version, since those optimizations focused on contraction optimizations for very small blocks.

Here are the same benchmarks after the changes introduced in (https://github.com/ITensor/NDTensors.jl/pull/54):
julia> main()
#################################################
# order = 2
#################################################

Contract:
  1.580 μs (51 allocations: 4.83 KiB)

Combine then contract:
  50.242 μs (877 allocations: 94.34 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 4
#################################################

Contract:
  4.091 μs (60 allocations: 9.66 KiB)

Combine then contract:
  110.874 μs (1620 allocations: 186.27 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 6
#################################################

Contract:
  30.831 μs (83 allocations: 55.81 KiB)

Combine then contract:
  290.229 μs (3867 allocations: 464.59 KiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 8
#################################################

Contract:
  290.239 μs (99 allocations: 467.00 KiB)

Combine then contract:
  1.060 ms (13371 allocations: 1.54 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 10
#################################################

Contract:
  3.534 ms (115 allocations: 3.21 MiB)

Combine then contract:
  5.125 ms (76588 allocations: 7.12 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 12
#################################################

Contract:
  39.490 ms (131 allocations: 21.20 MiB)

Combine then contract:
  28.124 ms (369079 allocations: 37.02 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 14
#################################################

Contract:
  726.577 ms (150 allocations: 184.92 MiB)

Combine then contract:
  156.128 ms (1576503 allocations: 165.32 MiB)

C_contract ≈ C_combine_contract = true

#################################################
# order = 16
#################################################

Contract:
  13.567 s (12583081 allocations: 4.12 GiB)

Combine then contract:
  1.229 s (14995579 allocations: 1.22 GiB)

C_contract ≈ C_combine_contract = true

Note that only part of the speedup is strictly because of the new Dictionary design (maybe about half of the speedup). The rest of the speedup is from optimizations particular to blocks of size 1 which we have in this case, for example now there is a special code path when contracting blocks of size 1 to avoid all of the contraction logic and simply do arithmetic on the single elements of the block.
Also, again the optimizations were primarily focused on optimizing block sparse contractions, not combining, so the combiner could could be optimized quite a bit.


refactor env structure

when local run this command in local env, the default-2.0.yml can't be found by ursula
ursula envs/test site.yml --ursula-sudo

in this PR, the following changes are made

add print log if default variable file can't be found
add soft link from example/defaults-2.0.yml to defaults-2.0.yml
only modified /envs/test/group_vars/all.yml instead of defaults-2.0.yml

Why would you do local run using - ursula envs/test site.yml --ursula-sudo?
There is no envs/test ...  local runs would be envs/example/


[FEATURE REQUEST] Many to Many Association add, not to return error even though it already have the same data

If I try to add instance which is already exist at many association, save returns error which I appreciate if it's not!!
[ { type: 'insert',
    collection: 'serials_owners__users_serials',
    criteria: { serials_owners: 3, users_serials: 31 },
    values: { serials_owners: 3, users_serials: 31 },
    err: 'Trying to \'.add()\' an instance which already exists!'  Was very confusing for someone new to sails.


Add support for system-level config in /etc/xdg/wluma/

Thanks! I learn a lot from you, somehow I didn't know about /etc/xdg at all until now...
I think to do this right we should properly support $XDG_CONFIG_DIRS, the current library doesn't support it, but there is another one which we perhaps should just switch to, which for example has this neat helper:
https://github.com/whitequark/rust-xdg/blob/1e2020a763e6b30d6bf9f4a69ab68d008a937f59/src/lib.rs#L405-L408
Let me know if you want to do it, otherwise I'll do it myself.

Hi there! I'd be very interested in this change, so we could ship a vendor config with manjaro sway. Sadly I am a bit out of my league regarding rust - any way I could help getting this functionality shipped?

Implemented in #66 🙂 👍


Verify network address in sig.json fixes #1596

This change is

Reviewed 1 of 3 files at r1.
Review status: 1 of 3 files reviewed, 1 unresolved discussion (waiting on @lukedirtwalker and @kormat)

go/sig/config/config.go, line 86 at r1 (raw file):

}

func verifyNetworkAddr(ip net.IP, mask net.IPMask, rawCIDR string) error {

I think this can be simplified. Something like:
nip := ip.Mask(mask)
if !nip.Equal(ip) {
   return common.NewBasicError(...)
}
return nil

Comments from Reviewable


Question : Does this support importing other React components from node Js

Yes you can use existing React components implemented in JS. I will add some documentation giving an example of how to do this.

Ok cool thanks.

We do it mostly, instead of staying tied to Java/GWT. We even have TypeScript + React + Webpack spitting out a UMD module that we invoke via JsInterop. This tool gave us the hookups to tie those in (so we aren't using a lot of this tool's other features.)

Make sure the component you want to use is exported
Import the module it's in via a JsInterop class

Add a JsInterop Props class for the component
Expose it in the JsInterop class that imports the module, via a getter.

Make a GWT "widget" that invokes the tools here to render the/a react component
Use it like any other GWT widget, just re-render when "props" change.

Per

integrating webpack devserver and superdev mode
IFAIK while super-dev mode seems to serve from the GWT projects target directory, webpack dev server hosts everything in memory and does not produces files on the file system at all, so I'm not sure there would be a way to integrate the two.
you could have two processes going, one running webpack dev server, and the other with the target-punching build running in watch mode. We actually have an npm script to do this, but in practice don't need it much. It's usually either one or the other, but I can see how what kind of component/view etc. you are working on and how you get data into it for a particular use case could drive a different workflow.


Incorrect sorting for entities

It seems that entities are not sorted alphabetically, even though some of your commits say they should be?
This one is from the sensor list.

Fun thing is most are sorted, there are just some rogue incorrectly sorted sensors in the list. :)
Might they be possible sorted by the user friendly name (the .text in your sorting script) in hass and not by .name or whatever is available for the entities?
I have seen the same for the buttons/switch/automation lists.

Any plans to release 2.1?


[stable/airflow]: Configurable initialDelay for starting Webserver

What this PR does / why we need it:
When running locally, it is nice to have a delay initially to make sure postgres and redis are available. However, in the case you are interacting with an external redis or postgres, it is expected that they're already available, so the wait time isn't necessary.
This change makes the intial sleep delay before starting airflow configurable and the initialDelay before a healthcheck configurable so it possible to start up the webserver faster.
Signed-off-by: Brian Nutt<EMAIL_ADDRESS>Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/ok-to-test

/lgtm


Keyboard

Hi,
I have a aspire a515-52g and i used your package in my hackintosh, and everything went well, including the keyboard works, the problem happens a few moments after login, that the keyboard just stops working.
EDIT
I realized that it stops working after using the trackpad

You need to patch your own DSDT or use my repository and replace it with Opencore.


GPU Fragmentation Issue with Distributed Inference on Multi-Node Setup

Our current implementation supports distributed inference for extremely large models which run on 2 or more GPUs. However, this requires those GPUs must be on the same worker node.
Assume in a multi-node setup, each node is equipped with two GPUs. Assume one GPU on each node is utilized, leaving one GPU per node idle. When users attempt to deploy a large model requiring distributed inference across 2 GPUs, the system is unable to accommodate this request despite having a total of 2 idle GPUs across the nodes. This is due to the requirement that these GPUs must reside on the same node, leading to ineffective resource utilization and GPU fragmentation.
Edit: seems VLLM supports distributed inference accross GPUS if we support infini band.

Resolved in commit bd2d715


Operator reliably creates zombie namespace

kubectl get namespaces
NAME          STATUS        AGE
default       Active        82d
jenkins       Active        10d
kube-public   Active        82d
kube-system   Active        82d
monitoring    Terminating   2h
monitoring2   Terminating   26m
rabbit        Active        2d

I first started operator deploy script, and it hang at
Waiting for Operator to register custom resource definitions.........................................................................................................................................................................................................................................................................................................................................................................................................................^C
So I interupted it. Ran teardown script. But namespace is stuck at terminating phase. I can not run the script again until I change namespace variable to monitoring2.
{
    "apiVersion": "v1",
    "kind": "Namespace",
    "metadata": {
        "creationTimestamp": "2017-09-24T21:05:34Z",
        "deletionTimestamp": "2017-09-24T21:14:27Z",
        "name": "monitoring2",
        "resourceVersion": "11461478",
        "selfLink": "/api/v1/namespaces/monitoring2",
        "uid": "1b94baae-a16c-11e7-8350-02a930332a2a"
    },
    "spec": {
        "finalizers": [
            "kubernetes"
        ]
    },
    "status": {
        "phase": "Terminating"
    }
}

Try kubectl get all -n monitoring then erase all the objects there. Then, kubectl delete ns monitoring --grace-period=0 --force

Tried that, also tired deleting the controller pod. Doesn't helo.


Support x86_64-w64-mingw32 target ?

I find musl.cc support x86_64-w64-mingw32 target. But current seems it's no longer maintains.
Would you please support to add this ?

https://github.com/musl-cross/musl-cross/releases/tag/20241028


failed deployments

deployments in canadacentral kick back an error.

deployments in eastus also kick back an error.
│ Error: creating Agent Pool (Subscription: **"REDACTED"**
│ Resource Group Name: "rncfos-eastus-aks-rg"
│ Managed Cluster Name: "rncfos-aks-eastus"
│ Agent Pool Name: "gpu"): polling after CreateOrUpdate: polling failed: the Azure API returned the following error:
│
│ Status: "SkuNotAvailable"
│ Code: "SkuNotAvailable"
│ Message: "Code=\"SkuNotAvailable\" Message=\"The requested VM size for resource 'Following SKUs have failed for Capacity Restrictions: Standard_NC6s_v3' is currently not available in location 'eastus'. Please try another size or deploy to a different location or different zone. See https://aka.ms/azureskunotavailable for details.\" Target=\"sku.name\"\nThe requested VM size for resource 'Following SKUs have failed for Capacity Restrictions: Standard_NC6s_v3' is currently not available in location 'eastus'. Please try another size or deploy to a different location or different zone. See https://aka.ms/azureskunotavailable for details."
│ Activity Id: ""
│
│ ---
│
│ API Response:
│
│ ----[start]----
│ {
│  "name": **REDACTED**
│  "status": "Failed",
│  "startTime": "2024-09-12T18:34:51.7028789Z",
│  "endTime": "2024-09-12T18:34:54.3341411Z",
│  "error": {
│   "code": "SkuNotAvailable",
│   "message": "Code=\"SkuNotAvailable\" Message=\"The requested VM size for resource 'Following SKUs have failed for Capacity Restrictions: Standard_NC6s_v3' is currently not available in location 'eastus'. Please try another size or deploy to a different location or different zone. See https://aka.ms/azureskunotavailable for details.\" Target=\"sku.name\"",
│   "details": [
│    {
│     "code": "SkuNotAvailable",
│     "message": "The requested VM size for resource 'Following SKUs have failed for Capacity Restrictions: Standard_NC6s_v3' is currently not available in location 'eastus'. Please try another size or deploy to a different location or different zone. See https://aka.ms/azureskunotavailable for details.",
│     "target": "sku.name"
│    }
│   ]
│  }
│ }
│ -----[end]-----
│
│
│   with azurerm_kubernetes_cluster_node_pool.node-pool["rncfos-aks-eastus"],
│   on kubernetes_cluster.tf line 60, in resource "azurerm_kubernetes_cluster_node_pool" "node-pool":
│   60: resource "azurerm_kubernetes_cluster_node_pool" "node-pool" {

errors related to resource availability/capacity in regions relating to the selected instance.
This is covered in the template with various options:

I will consider a PR where "vm size = var.size" on line 12 of terraform/locals_kubernetes_cluster.tf and add variable in terraform/variables.tf
This issue will be closed.


Chatbot

Currently, i have added the CS20SI Chatbot source from Stanford. There are problems with it though, the folowing checklists has been made to indicate if you fixed them.

[ ] Chatbot core has to be refactored to dynamically train while chatting.
[ ] Make it independent from the Cornell corpus

Adding this too

[ ] Merge data processor, Chatbot Model and main file in one class in JS rewrite

@Ovyerus you meme I need updates

Put this on hacktober Agile TODO for Clara. Due date is until the end of the month.

Neural network based chatbot is being shifted to 1.0.0. 0.4.X is being left with a Markov string based system for now.

Re-opened as a milestone for 1.0.0
We can use MonikaDesu/Rebecca for this

TensorFlow now has an official JavaScript wrapper, and so this'll now be done in Node.
(https://js.tensorflow.org/)

Set to 0.4.4 => Pending feature parity with MonikaBot


Fix for #6153 Allow MongoDB cursor streaming via each()

Fix for https://github.com/yiisoft/yii2/issues/6153 Allow MongoDB cursor streaming via each()

Note: this enhancement breaks the BC cahnging the signature of Query methods.

can you explain why removing indexBy is necessary?

It is not necessary - it is an optimization. I can revert it, but there is still matter around buildCursor, which visibility has changed.

I see.

Migrated to #12


was executed "false" times

Testing #208463
The API allows for false instead of 0:

Fixed in https://github.com/microsoft/vscode/pull/208740

Have something that uses the test coverage API (like the selfhost test provider)
Use boolean counts rather than numbers for execution (e.g. by setting booelanCounts: true in https://github.com/microsoft/vscode-selfhost-test-provider/blob/main/src/coverageProvider.ts#L7)
Verify the labels on things are correct


imp(types): Add crypto and encoding packages

This PR moves the crypto package to the evmOS repository.
The PR has to be merged after #19.

Did you branch out of PR 19? 😅 this contains also code for the wallet

I base these PR sequentially on each other and point to main for this PR but it was supposed to be to the parent PR :D now that PR is merged to main it's fine


[BUG] Disable cache saving on load failure

Deregister shutdown hook

PR: https://github.com/carrotdata/carrot-cache/pull/437
load failed from data store with long format 1_234_567

@kzheludkov elaborate please


Italic partial or upright partial?

I found that katex display mathjax-like italic partial sign here.
But I remember there is a ugly, shortened upright version of katex partial. (I searched it for an hour but failed)
OK, maybe like this: (https://katex.org/docs/supported.html)
the documentation says that direct input will render as upright partial

And this is the main reason I do not use katex.
How to force katex to display italic partial sign?

\frac{∂y}{∂x} already produces italic partials:

With my fonts, the documentation also looks italic:

We're actually just displaying Unicode characters there so that you can copy/paste to test them out. But before claiming there's a bug in KaTeX, you might actually try it out by pasting into the demo app...

I think ∂∇ℑℲℵℶℷℸ⅁ℏð differs because I installed Latex Modern math, depending on my installed fonts. Thanks!

KaTeX uses its own fonts and should render the same on all devices. The only confusion was that line of the documentation, which doesn't use KaTeX fonts.


Replace machine state sync with libvirt lifecycle event subscription

Proposed Changes

delete argument for machine-state-sync
replace machie-state-sync logic with handling libvirt events

Fixes #177

@hardikdr i applied all of your suggestions


A request to open source subsequent experiments on robots

Great job, thanks for your hard work! May I ask whether the subsequent experimental code on the robot can be open sourced? I wanted to try to reproduce those exciting operations.

Which ones specifically? The jackal or spot?
In either case, the high level design is quite straightforward and I can explain it here.
First, we generate the map of the environment using ConceptGraphs, and then the map can be queried in natural language to return the xyz location of the desired object. The code to do this is released. (And we are working on making it cleaner and nicer to use, see the ali_dev branch for now.)
For the jackal, it creates its own 3D map, which is purely geometric (i.e. no semantic information) and then this is synced to the 3D pointcloud from ConceptGraphs via the ICP algorithm. Clearpath robots come with some software for this. This is so that when ConceptGraphs returns an xyz location for an object, the jackal can navigate to that xyz location in its map.
We also just have a simple check using the onboard camera of the jackal to check if the desired object is indeed present at the location returned from ConceptGraphs, we use LaVA to check that, and if its not present the given location, we again query the conceptgraphs map for an alternate location where the desired object may be present.
Note that the ConceptGraphs map and the LLava model are running on a separate computer than that of the jackal navigation system. This is simply just because the computer onboard the jackal is not that powerful.
Hope that helps! We may release the code for this, but at the moment it is not a priority because it will change from robot to robot and we are focusing on just making the core mapping system better for now.

@sachaMorin also worked on the real robot experiments, he may have some more thoughts on this.

If you have more questions, feel free to ask and I will do my best to help.

Happy to share the Jackal code, I'll do so later this week. I'm not the owner of the Spot code but iirc this one cannot be open sourced.

Shared the code here. It's quite rough around the edges, but I hope it will prove useful!

Hi! Is there someone who has the spot code/could I contact anybody for access/to open source the spot code?

Hi @ayushzenith, our collaborators at JHU handled the spot robot experiments. Recently they released a newer paper called ConceptAgent with several improvements in planning and manipulation. Feel free to contact them for details.


Destroy CMS.Plugin instances

Summary
At moment we can create new CMS.Plugin instances in runtime but it's not clear how to destroy them removing all DOM nodes and all the events creaded with the Plugin.
Expected behaviour
I expect that a plugin can be created and destroyed for example:
const plugin = new CMS.Plugin(name, options)

// remove DOM and events without side effects
plugin.destroy()

Actual behaviour
A plugin can only be created
Environment

Python version: 3.5.4
Django version: 1.10.7
django CMS version: 3.4.4

p.s.
This method could also return an array of the plugins created using $.map instead of $.each

In 3.5 we kinda will have the plugin registry available https://github.com/divio/django-cms/blob/develop/cms/static/cms/js/modules/cms.plugins.js#L2156
We will likely add the destroy method as well in 3.5, as we now handle the page changes without reloads and will need destroying in the core, but likely not for 3.4.x, you'll have to roll your own there

@vxsx thanks I am looking forward to it.  Please let me know if I could help you on anything on this task and I will be glad to make a PR

The PR would be most welcome!

@vxsx it seems you don't use any js unit test... am I right? Any hint about knowing if I will break anything 😄 ?

Ok I will use and add a new test here in the integration tests never mind

There are also unit tests available https://github.com/divio/django-cms/tree/release/3.4.x/cms/tests/frontend/unit
Integration tests are currently broken on develop so might be a bit tricky


Destroy the plugin properly when exiting the app

According to my analysis, when using multiple plug-ins as shown below, only the last registered plugin is destroyed normally when exiting app. This is causing a crash at the end of the app.
I guess that there are something wrong with implementations that deals with plugins in Tizen Embedder
//
// Generated file. Do not edit.
//
using System;
using System.Runtime.InteropServices;
using Tizen.Flutter.Embedding;

namespace Runner
{
    internal class GeneratedPluginRegistrant
    {
        [DllImport("camera_plugin.so")]
        public static extern void CameraPluginRegisterWithRegistrar(IntPtr registrar);
        [DllImport("integration_test_plugin.so")]
        public static extern void IntegrationTestPluginRegisterWithRegistrar(IntPtr registrar);
        [DllImport("video_player_tizen_plugin.so")]
        public static extern void VideoPlayerTizenPluginRegisterWithRegistrar(IntPtr registrar);

        public static void RegisterPlugins(FlutterApplication app)
        {
            CameraPluginRegisterWithRegistrar(app.GetPluginRegistrar("CameraPlugin"));
            IntegrationTestPluginRegisterWithRegistrar(app.GetPluginRegistrar("IntegrationTestPlugin"));
            VideoPlayerTizenPluginRegisterWithRegistrar(app.GetPluginRegistrar("VideoPlayerTizenPlugin"));
        }
    }
}

Should I move this issue to the engine repo?

Should I move this issue to the engine repo?

Not necessarily but you can as this is an embedder issue.
Probably the behavior is caused by the following code:
https://github.com/flutter-tizen/engine/blob/31279eae37874150064da5983425c7769f0b0f40/shell/platform/common/cpp/client_wrapper/include/flutter/plugin_registrar.h#L106-L107
https://github.com/flutter-tizen/engine/blob/31279eae37874150064da5983425c7769f0b0f40/shell/platform/tizen/flutter_tizen.cc#L68-L72
I just followed other platform implementations (especially windows) when I was implementing the destruction handler for Tizen, although I also thought it's incorrect to overwrite existing handler when registering a new plugin. Now it's time to deal with this issue!

Does Windows have the same problem? If not, why?
Having a list of callbacks in the embedder and calling them one by one when stopping the engine will resolve the issue?

Does Windows have the same problem? If not, why?

I've never checked it on Windows, but I guess that they might have mistaken that there is no problem.
Because a typical plug-in behavior is operated passively by a method handler. On the other hand, the camera or video plugin is constantly calling engine API in the child thread of plugin side to pass media packets.
I hope someone who is familiar with the Windows environment can experiment.

Having a list of callbacks in the embedder and calling them one by one when stopping the engine will resolve the issue?

I'll try it later.

This seems to be a tool issue and I'll prepare a fix soon. Until then, you can use the native app host (--tizen-language cpp) which doesn't have this issue. The issue is only reproducible with the .NET app host due to its unique plugin architecture.

https://github.com/swift-kim/flutter-tizen/commit/b13462d7093c1b36330bf18dba678effd8fa2be2
This is a really quick fix for this issue (compiling all plugins into a single .so) but I actually have to re-design the entire architecture.


Comments can shift around or become taller on hover

Testing Microsoft/vscode#69321
Repo

Open a file with some reaction comments
Hover over the comment

Bug

should be fixed now.


Email finder

Changes this pull request makes :
Checklist :

[X] I have added the relevant documentation.
[X] My branch is up-to-date with the upstream master branch.
[X] I have fully tested the changes locally.

Development environment
OS: Linux
Python Version: 3.4.6

@nahuelhm17 Great work!, next time when sending a PR do mention the issue number, it'll close the issue automatically after PR is merged :)


Drop In Component Pay button not working in android APK's.

We successfully implemented the adyen drop in component in our development builds and have been able to make payments to the test environment on both IOS and Android devices.
However when we created our QA build the pay £xx.xx button within the component (after entering card details) seems to
be inactive. Nothing at all happens when we press the button, we cannot even generate a 'hello world' log when pressing the button. (See screenshot of button below)

This was tested across multiple android emulators and multiple android devices using multiple android versions, and all resulted in this button not responding when clicked.
In our IOS QA builds it works as expected and we can make payments to the test environment.
It does not seem to be an issue to do with debug versus release builds either as we tried a local react native release mode run and this allowed us to make a payment to the test environment, so we are at a loss as to what could be causing this issue.
Is this an issue you have encountered before and do you have any advice on how to resolve this issue?

Hey @jbcampbell1
Have you follow all steps on Android integration guidelines?

Hey @descorp,
It appeared we forgot to update our AndroidManifest.xml for each environment, hence why it was working in develop and on IOS!
Thanks for the quick response! Issue is now resolved :)


fixes single line comments in jsdoc parser

alternative implementation to https://github.com/qooxdoo/qooxdoo-compiler/pull/636

Merging, thank you @johnspackman !


Payed Transport

Kind of like teleportation I guess but you have to pay gold for it.

Closing this. If this is comes up naturally it will be added -- for now this seems more like a 'game' enhancement (something you'd write for your game). The way to do this would be to write an ai script that lets the mob open a portal or teleport something (switching the player.roomid and player.area to the wanted room, taking some gold, giving a message, and then firing the look command).
Teleport will be a part of base.

Ok thanks!


Failed to resolve Kotlin extensions in beta5

I'm unable to get my build.gradle to recognize the Kotlin extensions package.
Error:Failed to resolve: com.github.Raizlabs.DBFlow:dbflow-kotlinextensions:3.0.0-beta5

Any ideas?

me too.

I'm having the same issue with beta4 and beta5. @agrosner can you please check

@MrDeus
@sigmabeta
I think you should use greendao instead.

sorry guys. itll be in beta6

@LiHanGuang libs are a personal choice and promoting other libs inside this one prob isn't best idea ;).


BSOD: cp -rv ./* ~ when .=/mnt/c/Users/...

If you're reporting a BSOD, don't post here!  Instead, e-mail<EMAIL_ADDRESS>and if possible attach the minidump from "C:\Windows\minidump".
This is a BSOD, but it has now been investigated by secure, and was harmless, but it still needs to be fixed.

Your Windows build number:  Microsoft Windows [Version 10.0.16257.1]

What you're doing and what's happening:  (Copy&paste specific commands and their output, or include screen shots)
I run https://www.microsoft.com/en-us/store/p/ubuntu/9nblggh4msv6

pi@lenovo5:/mnt/c/Users/pi/Downloads/home$ cp -rv ./* ~
Writes a few lines
BSOD

What's wrong / what should be happening instead:
It should write all files and copy them. After BSOD the computer reboots and when I start Ubuntu again, no files or directories were copied.
I have rather many files and directories in home. The reason I copied all files from ~ to home was to install Ubuntu in the new way from scratch from Windows Store (this worked and Ubuntu has newest dist-upgrade, and then copy them back.

Strace of the failing command, if applicable:  -

It is probably related to https://github.com/Microsoft/BashOnWindows/issues/2392 .

@mobluse - I suspect you are right that this is the same underlying issue as #2392 for which we have a fix inbound.  Will you reply to the mail that secure sent you and let them know that benhill would like to see the dump so I can confirm that the issue is fixed?

Yes, I did that now.

@mobluse - I was forwarded the dump and confirmed it is the same issue as #2392, thanks for sending that along.  I'm going to close this as a duplicate, it looks like the fix will be in the next Insider build (next week).


Obtaining column names in FROM COLUMNS OF is not obvious

The user must use
ESTIMATE *[, ...] FROM COLUMNS OF <generator>

in order to obtain the names of the columns. This wasn't immediately obvious to me. The returned table appears to have a field "name", but the following command produces an exception:
ESTIMATE name FROM COLUMNS of satellites_cc
  File "build/bdist.macosx-10.9-x86_64/egg/bayeslite/bayesdb.py", line 158, in execute
  File "build/bdist.macosx-10.9-x86_64/egg/bayeslite/bql.py", line 59, in execute_phrase
  File "build/bdist.macosx-10.9-x86_64/egg/bayeslite/bql.py", line 644, in execute_wound
  File "build/bdist.macosx-10.9-x86_64/egg/bayeslite/bayesdb.py", line 176, in sql_execute
sqlite3.OperationalError: ambiguous column name: name

Note that this does not produce an error:
SELECT name FROM (ESTIMATE * FROM COLUMNS satellites_cc)

RE ambiguous column name: name -- try ESTIMATE c.name?

It is a bug that you can't say ESTIMATE name FROM COLUMNS OF <gen> (and an accident that ESTIMATE c.name FROM COLUMNS OF <gen> works).  Writing * to get everything that the old syntax ESTIMATE COLUMNS FROM <gen> WHERE ... formerly gave was an expedient kludge.
Fixing the bug requires restructuring the SQL that ESTIMATE ... FROM COLUMNS OF <gen> compiles into so that it uses the wrapped query you suggested.  I don't think it's a hard or unprecedented task -- just a little tedious.  If anyone would like to take a stab at it, I'd be happy to help, so that I'm not the only person willing to touch compiler.py (which is a large and perhaps consequently intimidating file, but which is conceptually rather vapid).

Hmm.  Correction: it is a somewhat harder task if you want to be able to use the name inside expressions -- simply wrapping the query is insufficient for it, and that's probably why I didn't do it before.  We could put in an extra kludge to make ESTIMATE name, ... FROM COLUMNS OF <gen> work, but making ESTIMATE 'foo: ' || name, ... FROM COLUMNS OF <gen> work is considerably trickier.

We should have some well-publicized decision and solution for this before we officially support analysis.

If I recall correctly, this is basically blocked on #38.

I mean: doing this correctly is blocked on #38.


How to implement DKIM

I want to implement DKIM in the config, But cannot find a proper document.

I want to do a CIRS-seq analysis and I am doing rf-count-genome, but the job is not finished after three days.
”rf-count-genome -m -p 64 -wt 64 -r -o ./XXX -fh -f genome.fa XX.bam”
The outfile has
[+] Making output directory...
[+] Guessing file types:
Sample          Type    5'-end trimming    Library type
XX   BAM     Ignored            unstranded
[+] Importing chromosomes from reference, and building count table base structure...
[+] Inspecting SAM/BAM file headers...
[+] Assuming that provided SAM/BAM files are already sorted. Skipping sorting...
[+] Calculating per-base mutation counts and coverage. This may take a while...
[-] Processing sample "XXXX" (PID: 26829)


Error while updating dependencies

Problem statement
I use swagger version 0.5.0-145-g163c0cd and I updated all my project dependencies (go get -t -u ./...). I'm seeing the following error when trying to start my REST API server.
# github.com/go-openapi/runtime/middleware
../../../github.com/go-openapi/runtime/middleware/router.go:233: cannot use parameters (type map[interface {}]spec.Parameter) as type map[string]spec.Parameter in field value
../../../github.com/go-openapi/runtime/middleware/router.go:235: cannot use parameters (type map[interface {}]spec.Parameter) as type map[string]spec.Parameter in argument to newUntypedRequestBinder

Any ideas or maybe this is not related to swagger?

are you vendoring your dependencies by any chance?
I think this is caused by a PR that got merged this morning. So if you're vendoring, i want to ask if you can go back to go-openapi/analysis#9f487a0bf7e69478955d3a8bd1642d1a1edddcc4
That is prior to the change in signature being merged.

Thanks for the quite reply. Not yet, but I guess the time has come.

Thanks that fixes it.

I fixed it on master of that library now too, so you don't strictly need to vendor anymore


Can't run vuelectro init

When I follow the getting started instructions i'm stuck on 'vuelectro init', Windows(powershell) returns a ObjectNotFound exception.
When I run 'npm install vuelectro --save-dev' I get the following warnings:
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.

Hi @allard-potma,
Have you created a Vue project first? If you did please link to a copy of your existing package.json file before the installation of Vuelectro. And that's also before any failed installation too. Because a failed installation can also alter your dependency tree.

When i just run vue create in a empty directory, this is the resulting package.json:

Can you try to create a Vue project without any extra plugins like sass or any other third party loaders? Because this definitely isn't an issue with Vuelectro since those dependencies are not associated with Vuelectro. All the other versions satisfy required versions.

When I run with the default Vue3 preset, the problem persists. When I run npm install postcss-reporter postcss before installing vuelectro it seems to work. I think it is a strange NPM thing. I will continue using the plugin, thank you!

Edit: updating node and NPM resolved the issue completely.

Glad to know. That was my suspicion. NPM has been acting completely bonkers for the past few weeks. Lemme know if there's anything else I can assist you with.


Attempt to send record type in gRPC throws Null Pointer Exception in compiler

Description:
I am trying to create a gRPC service that doesn't send and receive strings (JSON), I want to use real protobuf messages. My first attempt to do so (found in this
gist), when I try and compile, produces a null pointer exception.
Steps to reproduce:
Run ballerina build on the file in the gist.
ballerina-internal.log
OS, DB, other environment details and versions:
Ubuntu 18.04 (Pop! OS)
Suggested Labels (optional):
bug

This is due to an issue in deriving response message type when passing complex types like optional, union, tuple etc. Current implementation doesn't support passing those values.
We need to validate it correctly and send proper error messages.

Closing since the relevant PRs are merged as per @daneshk 's input.


Init cluster admin content with proxies for Indonesian translation

This is translation of proxies page into Indonesian language.
/language id

/lgtm
/approve

/assign @girikuncoro

/approve


How to add shaders to backgrounds??

how tho

just use code from D&B https://github.com/MoldyGH/VsDave

ok


example: add an example for encrypted volume in block mode

Longhorn/longhorn#4883

@derekbit Please help update this, then we can merge it.

@derekbit Please help update this, then we can merge it.

Updated. Thank you.


Add accountId field to context

To have handy access to accountId.
Discussion https://github.com/metarhia/Example/discussions/144

See solution here: https://github.com/metarhia/Example/pull/155