Update deprecated syntax "{a,b, ...}".

[musm]

Change deprecated syntax in parallel computing section.

[yuyichao]

Please just update the branch instead of opening a new PR everytime you update the commit since all the conversations are lost.

I don't think it's a good idea to use Any[] here (even though that's what the code before was doing). Either removing it or use Matrix{Float64} as I mentioned in the previous PR should be better.

[musm]

Apologies I'm trying to figure out how to contribute. How can I update this branch?

[yuyichao]

If you are using the web interface, I think you can just edit on this branch (https://github.com/mmoh/julia/tree/patch-1). This PR should probably be a squashed to a single commit and for that you might need command line git (https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md#git-recommendations-for-pull-requests) .

[yuyichao]

LGTM but need a squash. The link in the readme section I linked has a pretty complete description of what a squash is and how you can do it.

[musm]

I think I really messed this up. I figured out how to squash the commits in my branch, but then I had merge errors when I tried push origin patch-1 , I read I had to fist pull and then push, but the result is terrible. Maybe someone else can take care of this because clearly I can't figure it out.

[yuyichao]

Assuming origin is the name of your fork and julialang is the name of this repo. What you need to do is to rebase your branch on top of the master branch and squash it to a single commit. You can do this in two steps in order to make it a little easier.

First rebase the branch.

git rebase julialang/master # This rebase your branch on your local copy of the julialang master branch

Then squash the commit

git rebase -i julialang/master # And follow the instruction in the link when the editor window pops up

Finally push out the result

git push -f origin patch-1

Note that the first and the second are really the same command and you can do both at the same time. Separating them make it a little easier to handle IMHO. Also note that since you are overriding the history, you need the -f / --force argument when you are doing the push. Git will ask you to pull if you don't have that since it by default assume you don't want to override the history. Here you actually want to override the history so don't follow that instruction.

[musm]

Thank you. I think got it to work, not exactly sure I understand why it all work, but there it is. In general do I even need to create another branch if I want to make changes for a PR. Looks like I can just make changes to master and then submit a PR as opposed to making it more complicated through a branch.

[eschnett]

If you ever have only a single PR under review, then using master will work fine. If you have several PRs under review, then each of them needs to remain untouched while you make other commits -- hence several branches. (Alternatively, you can use a different Github repository for each of your changes.)

[yuyichao]

AppVeyor win64 is definitely unrelated. I'm wondering we could be hitting a OOM there too. https://ci.appveyor.com/project/StefanKarpinski/julia/build/1.0.11887/job/kfygy0iqfeidxse6

[yuyichao]

I'm not 100% sure if the failure is a OOM (the segfault happens on a process I didn't attach to in rdp) but it does seem like we are running REALLY close to the memory limit. The worker has about 2.4G of memory and we are almost always within 100-150MB after we starts the tests!.

It also seems that AppVeyor very recently increases the number of CPU's on the worker (without increasing the memory accordingly....). Comparing build 11857 to build 11859. The first one has 2 workers (3 processes) and the second one has 4 workers (5 processes) and it is not so surprised to see that the second build is the first build that has the segfault. We should probably limit the number of workers to 2 again (edit: or activate the max rss restart limit), at least on win64.

@tkelman

[yuyichao]

Also the time of the segfault kind of correlates with a bump in memory consumption, which I would interpret as spawning a child process but failed (and segfault) because it couldn't allocate enough memory (causing a null return from malloc in somewhere we are not checking for). I was fighting with the windows sizes on rdp and wasn't looking at the log at that point by they are definitely within a few seconds.