Code Release: Gallium.jl - The julia debugger

[Keno Fischer]

Hello everyone,

it is my great pleasure to announce the release of the first alpha version of

Gallium.jl, the julia debugger. This is still an early work-in-progress and meant as a developer release for those interested, but I think I've gotten it to a point that other people can meaningfully start playing with it and trying it out. That said, do expect rough edges and perhaps occasional crashes (though I'll do my best to fix them).

As usual, the Gallium.jl source code is available at https://github.com/Keno/Gallium.jl and the README has some instructions on how to get everything set up. I've also recorded a short video to walk you through the major features and show off what's available right now: https://youtu.be/Kv6TO_gm2yw.

I've been working on this for some time now as many of you probably know,

and I'm really happy to be able to release this version to you today. However,

getting this done wouldn't have been possible without the help of everybody at Julia Computing, who has helped get my open source project into releasable shape. My very special thanks also goes to BlackRock and in particular Michael Turok and Michael Francis, who had generously agreed to sponsor development

of the debugger to make this happen sooner than it otherwise could have.

Now, it's up to you. Try it out, let me know what you like, what you don't, file issues, and perhaps also send me pull requests :). I hope you enjoy!

Keno

[Stefan Karpinski]

[Tim Holy]

Woot! Definitely feels like Christmas! Thanks to Keno and also to the sponsors.
Many of us will benefit from your contributions of time and money to this
project. It's a huge step forward in the maturation of julia.

Can I be greedy and ask for a couple of things?
- It would be nice to know whether this is tracking julia 0.5-dev, or if this
will be runnable on the 0.4 series.
- I would characterize the README as developer-oriented. It might benefit by
starting with a tutorial:
+ create a function with a bug
+ fire up julia, run the function, get the error
+ use the debugger to break-on-error and examine what caused the bug. Also
demonstrate setting a manual breakpoint, stepping, etc.

--Tim

[Tony Kelman]

Not the most unambiguous choice of names, there's a 3d graphics library called gallium.

[Tim Holy]

That was my first thought, too.

--Tim

[Jacob Quinn]

Offhand, I wonder if this will work with 0.4 as long as you have > LLVM 3.3 (or possibly 3.7 required). Just a guess.

[Stefan Karpinski]

To be honest, at this point I think it would be pretty hard for a non-developer to use this. The main point of getting it out there and announcing it on julia-dev is to get people to try it out on different systems and report and fix issues.

In the near future, it would be good to get to a point where you can use Gallium with Julia master; then we can consider backporting the necessary changes to 0.4 and evaluate whether it's practical – I hope the answer is yes.

[Isaiah Norton]

+Inf

@Keno: I read through the design document, and I am wondering if you have any thoughts on the feasibility of supporting some of the extended Gallium functionality via (LLDB's support of) GDB-MI. The advantage being that many IDEs already support GDB-MI out of the box. Some customization would still be required to teach an IDE to support the extended commands, but that is a vastly smaller task than interfacing via the Julia embedding API.

- It would be nice to know whether this is tracking julia 0.5-dev, or if this
will be runnable on the 0.4 series.

kf/gallium appears to be based against Jameson's codegen rewrite branch.

A couples other notes for folks who are trying this:

- the launcher script in the demo video is OS X-only at the moment as it relies on AppleScript

- I believe the README example of setting ARGS["1234"] refers to the PID of an already-running Julia process (https://github.com/Keno/Gallium.jl/pull/26)

- on Ubuntu, the `ptrace_scope` setting at end of Gallium README seems to be undone if the directory is changed by the julia process

- LLDB does not build on Windows with our current toolchain

On Fri, Sep 11, 2015 at 7:49 PM, Keno Fischer <kfis...@college.harvard.edu> wrote:

[Scott Jones]

Now, it's up to you. Try it out, let me know what you like, what you don't, file issues, and perhaps also send me pull requests :). I hope you enjoy!

Keno

Hat's off again to you, Keno, for making this (and all the other stuff you've done), and to BlackRock for sponsoring this!

I would like to be able to send pull requests, but you've currently got me blocked on GitHub 😞

Could you please undo that so I'll be able to fork / test & perhaps submit PRs on Cxx.jl and Gallium.jl?

Thanks, Scott (@ScottPJones on GitHub)

[Keno Fischer]

Fair enough, but the name just fit too well. I'm  hoping the `.jl` will disambiguate.

[Keno Fischer]

We might be able to use an 0.5 runtime with an 0.4 standard library, which should work fine.

[Keno Fischer]

On Sat, Sep 12, 2015 at 10:56 AM, Isaiah Norton <isaiah...@gmail.com> wrote:

+Inf

@Keno: I read through the design document, and I am wondering if you have any thoughts on the feasibility of supporting some of the extended Gallium functionality via (LLDB's support of) GDB-MI. The advantage being that many IDEs already support GDB-MI out of the box. Some customization would still be required to teach an IDE to support the extended commands, but that is a vastly smaller task than interfacing via the Julia embedding API.

I'd have to look into LLDB's implementation of the MI API. I think it's probably possible, but will require a decent amount of code (i.e. I don't think it'll just work out of the box).

[Keno Fischer]

I checked and I don't think this is true. Try again?

[Scott Jones]

Unfortunately, still not able to get this to build, but may be just my system (I'm running El Capitan Beta 8, with XCode 7.1 beta).

I'm using the latest out of master, merged in kf/gallium (had 2 conflicts, one just an extra space in codegen.cpp, other in test/core.jl, that I had to fix)

codegen.cpp:177:8: error: reference to 'FunctionPassManager' is ambiguous

static FunctionPassManager *FPM;

       ^

/j/julia/usr/include/llvm/IR/PassManager.h:258:31: note: candidate found by name lookup is

      'llvm::FunctionPassManager'

typedef PassManager<Function> FunctionPassManager;

                              ^

/j/julia/usr/include/llvm/IR/LegacyPassManager.h:68:7: note: candidate found by name lookup is

      'llvm::legacy::FunctionPassManager'

class FunctionPassManager : public PassManagerBase {

      ^

In file included from codegen.cpp:662:

./cgutils.cpp:472:5: error: reference to 'PassManager' is ambiguous

    PassManager PM;

    ^

/j/julia/usr/include/llvm/IR/PassManager.h:180:35: note: candidate found by name lookup is 'llvm::PassManager'

template <typename IRUnitT> class PassManager {

                                  ^

/j/julia/usr/include/llvm/IR/LegacyPassManager.h:49:7: note: candidate found by name lookup is

      'llvm::legacy::PassManager'

class PassManager : public PassManagerBase {

      ^

In file included from codegen.cpp:662:

./cgutils.cpp:477:9: error: use of undeclared identifier 'PM'

        PM.add(new TargetLibraryInfoWrapperPass(Triple(TM->getTargetTriple())));

        ^

./cgutils.cpp:490:37: error: use of undeclared identifier 'PM'

        if (TM->addPassesToEmitFile(PM, FOS, TargetMachine::CGFT_ObjectFile, false)) {

                                    ^

./cgutils.cpp:513:9: error: use of undeclared identifier 'PM'

        PM.run(*clone);

        ^

codegen.cpp:4126:23: warning: unused variable 'SP' [-Wunused-variable]

        DISubprogram *SP = main_ctx->dbuilder->createFunction(CU,

                      ^

codegen.cpp:5802:15: error: reference to 'FunctionPassManager' is ambiguous

    FPM = new FunctionPassManager(m);

              ^

/j/julia/usr/include/llvm/IR/PassManager.h:258:31: note: candidate found by name lookup is

      'llvm::FunctionPassManager'

typedef PassManager<Function> FunctionPassManager;

                              ^

/j/julia/usr/include/llvm/IR/LegacyPassManager.h:68:7: note: candidate found by name lookup is

      'llvm::legacy::FunctionPassManager'

class FunctionPassManager : public PassManagerBase {

      ^

codegen.cpp:5829:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createTypeBasedAliasAnalysisPass());

    ~~~  ^

codegen.cpp:5829:14: error: use of undeclared identifier 'createTypeBasedAliasAnalysisPass'

    FPM->add(createTypeBasedAliasAnalysisPass());

             ^

codegen.cpp:5831:14: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

        FPM->add(createBasicAliasAnalysisPass());

        ~~~  ^

codegen.cpp:5831:18: error: use of undeclared identifier 'createBasicAliasAnalysisPass'; did you mean

      'createCostModelAnalysisPass'?

        FPM->add(createBasicAliasAnalysisPass());

                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

                 createCostModelAnalysisPass

/j/julia/usr/include/llvm/Analysis/Passes.h:60:17: note: 'createCostModelAnalysisPass' declared here

  FunctionPass *createCostModelAnalysisPass();

                ^

codegen.cpp:5833:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createCFGSimplificationPass()); // Clean up disgusting code

    ~~~  ^

codegen.cpp:5834:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createPromoteMemoryToRegisterPass());// Kill useless allocas

    ~~~  ^

codegen.cpp:5837:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createInstructionCombiningPass()); // Cleanup for scalarrepl.

    ~~~  ^

codegen.cpp:5839:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createScalarReplAggregatesPass()); // Break up aggregate allocas

    ~~~  ^

codegen.cpp:5841:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createInstructionCombiningPass()); // Cleanup for scalarrepl.

    ~~~  ^

codegen.cpp:5843:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createJumpThreadingPass());        // Thread jumps.

    ~~~  ^

codegen.cpp:5848:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createInstructionCombiningPass()); // Combine silly seq's

    ~~~  ^

codegen.cpp:5852:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createReassociatePass());          // Reassociate expressions

    ~~~  ^

codegen.cpp:5857:10: error: no member named 'add' in 'llvm::PassManager<llvm::Function>'

    FPM->add(createEarlyCSEPass()); //// ****

    ~~~  ^

fatal error: too many errors emitted, stopping now [-ferror-limit=]

1 warning and 20 errors generated.

make[1]: *** [codegen.o] Error 1

make: *** [julia-src-release] Error 2

-----------------------

Also, still blocked from forking from any of your repositories - had the same problem with Jake,

he was able to unblock me.

Thanks, Scott

[Jameson Nash]

Sometimes you need to manually cd to deps/llvm-svn, deps/llvm-svn/tools/clang and deps/llvm-svn/tools/lldb and do `git checkout kf/gallium`. The build rule for this is currently not robust.

[Scott Jones]

On Saturday, September 12, 2015 at 10:03:02 PM UTC-4, Jameson wrote:

Sometimes you need to manually cd to deps/llvm-svn, deps/llvm-svn/tools/clang and deps/llvm-svn/tools/lldb and do `git checkout kf/gallium`. The build rule for this is currently not robust.

Tried that, got this error:

Scotts-Retina-MBP:julia scott$ cd deps/llvm-svn

Scotts-Retina-MBP:llvm-svn scott$ ls

CMakeLists.txt README.txt lib

CODE_OWNERS.TXT autoconf llvm.spec.in

CREDITS.TXT bindings projects

LICENSE.TXT build_Release+Asserts python2_path

LLVMBuild.txt cmake resources

Makefile configure test

Makefile.common docs tools

Makefile.config.in examples unittests

Makefile.rules include utils

Scotts-Retina-MBP:llvm-svn scott$ git checkout kf/gallium

error: pathspec 'kf/gallium' did not match any file(s) known to git.

I must be misunderstanding something :-(  Feel like an idiot.

I *really* want to get Keno's stuff working on my machine, been wanting it since JuliaCon.

[Elliot Saba]

be sure to `git fetch` to update the branches and such available to your local copy of git.  Perhaps worthwhile to check that your `git remote show origin` is still pointed at the right remote URL.

[Viral Shah]

Or we should try and make sure that 0.5 has a fast release cycle with only the array changes and whatever makes its way in simultaneously.

-viral

[Scott Jones]

I would hope that 0.5 will have support for all of Keno's goodness, out of the box, in addition to array changes. Debugging and better C/C++ integration I think are very important for a lot of the Julia community.  (I think Blackrock's funding of this wonderful debugging work shows that).

Also a lot of Jameson's stuff that wasn't merged in 0.4, such as codegen rewrite.

[Scott Jones]

On Sunday, September 13, 2015 at 1:58:14 AM UTC-4, Elliot Saba wrote:

be sure to `git fetch` to update the branches and such available to your local copy of git.  Perhaps worthwhile to check that your `git remote show origin` is still pointed at the right remote URL.

Is this not correct?

(in deps/llvm-svn):
* remote origin
  Fetch URL: http://llvm.org/git/llvm.git
  Push  URL: http://llvm.org/git/llvm.git
  HEAD branch: master
(in deps/llvm-svn/tools/clang)
* remote origin
  Fetch URL: http://llvm.org/git/clang.git
  Push  URL: http://llvm.org/git/clang.git
  HEAD branch: master
(in deps/llvm-svn/tools/lldb)
* remote origin
  Fetch URL: http://llvm.org/git/lldb.git
  Push  URL: http://llvm.org/git/lldb.git
  HEAD branch: master

[Isaiah Norton]

You are still on upstream. The best approach is to do a fresh clone of Julia and checkout the kf/gallium branch before you start the build. Please see the instructions at https://github.com/Keno/Gallium.jl#building-gallium

The easiest way to obtain these is to checkout the kf/gallium branch of julia, which will attempt to check out the correct branches and build everything from scratch. Note that this only works on a fresh install.

[Scott Jones]

OK, the bit about "fresh install" I didn't understand, I had done a "make cleanall ; make ; make install", thinking that's what it meant.

This time I made a new clone of JuliaLang/julia, and did "git checkout kf/gallium" as per Keno's instructions, then did a "make".

Still doesn't work though, either with my old Xcode 6.4 release, or the Xcode 7.1 beta.

This is a gist with the errors I saw with Xcode 7.1 beta:

https://gist.github.com/ScottPJones/4aa5d2001ccf6c89dbf1

Any ideas?

Thanks, Scott

[Michael Francis]

Exciting times. Thankyou

[Michael Francis]

That gets a firm thumbs up from me - I'd like to see 0.5 out of the door in short order so that the flow of breaking changes can slow down. 

On Sunday, September 13, 2015 at 4:28:56 AM UTC-4, Viral Shah wrote:

[Stefan Karpinski]

Agree with that wholeheartedly, but I also think that support Cxx on master Julia is a plausible goal. The codegen rewrite is entirely back-portable to 0.4 once it proves stable on master.

[Tony Kelman]

Let's be cautiously optimistic on that. There are a few big (though theoretically not disruptive) things that we held up on until branching that might be a good idea to backport once thoroughly shaken out and proven to be stable on master for some time. But this will require careful tracking of all the followup bugs and later related commits on master to be sure we catch those too.

Upgrading LLVM is the biggest issue where it remains to be seen whether it will be possible to backport sanely.

[David Anthoff]

Thanks to Keno, this is great news!

 

+++1 for a fast 0.5, for two reasons: 1) get it over with the major breaking changes quickly, 2) that was the communicated plan for a whole long time. I think there is value in sticking to such pronouncements so that people build expectations that they can believe such pronouncements in the future.

[Michael Francis]

Feb is a long way off and there are a whole lot of issues tagged into 0.4.x and 0.5. Is there something we could do to make this more expedient? At the very least it would be nice to have master be tracking the breaking changes very early in the cycle.  

[Tony Kelman]

Help implement and test the major feature-defining (and/or breaking) changes. Codegen rewrite was just merged, so now experimenting with the threading and debugger branches should be easier and we could hopefully get those merged into master in some form (behind a non-default build option if necessary, just to lessen the rebase hassle). The codegen performance and memory consumption of LLVM 3.7 will need to be worked on.

Further array changes have been on hold, now design work will need to resume on that. This should be doable entirely in parallel with work on the codegen/LLVM/threading/debugger fronts.

[Stefan Karpinski]

On Monday, September 14, 2015, Michael Francis <mdcfr...@gmail.com> wrote:

At the very least it would be nice to have master be tracking the breaking changes very early in the cycle.

Not sure what that means. Can you elaborate?

[Michael Francis]

My preference is to have breaking changes in the code base very early - that could well be what we are doing. Anything breaking which isn't ready now'ish possibly shouldn't be in 0.5 

Note : I come from a mentality of two week release cycles with overlapping build, test, release cycles. So in that model code in master now ( or in a short deadline from now - we had a few day open season) would be the candidate for the next release. That release is then locked down (tagged) stabilized, tested and released. 0.6 would be cooking before 0.5 even hit the road. This is predicated on the notion that people can be encouraged to move forward to new versions - I guess that's where the LTS style of overlap schedule comes in, where you lock down a periodic release as the LTS one. 

[Stefan Karpinski]

On Mon, Sep 14, 2015 at 3:51 PM, Michael Francis <mdcfr...@gmail.com> wrote:

My preference is to have breaking changes in the code base very early - that could well be what we are doing. Anything breaking which isn't ready now'ish possibly shouldn't be in 0.5 

Yes, we definitely want to frontload as much breakage as possible. However, there's all the array stuff, which is going to be quite breaking and is clearly nowhere near ready.

 

Note : I come from a mentality of two week release cycles with overlapping build, test, release cycles. So in that model code in master now ( or in a short deadline from now - we had a few day open season) would be the candidate for the next release. That release is then locked down (tagged) stabilized, tested and released. 0.6 would be cooking before 0.5 even hit the road. This is predicated on the notion that people can be encouraged to move forward to new versions - I guess that's where the LTS style of overlap schedule comes in, where you lock down a periodic release as the LTS one. 

The problem with such short release cycles for us is that we then have to maintain support for a lot of releases concurrently. Without that support, I'm not sure what the point of a release is – just pick a commit and use it. A release is a commit by comparison is one that will have a series of follow-on bug fixes that won't break your code when you upgrade. For the 0.3 release, this has been really successful: upgrading fairly large, complex code bases from 0.3.0 to 0.3.x has caused no problems that I've seen.

[Michael Francis]

Probably 2 weeks here doesn't make sense, that was more for context,  but keeps people on their toes. The model can be extended to a longer time scale. The real point is that for a feature to be included in the next release it has to be ready much earlier. If the array stuff isn't ready for testing now'ish I'd argue that it can't be part of the next release and other major items should be pulled forward.

There is a difference between a release and a commit - a release has been tested and proven to be stable. A release is not made till this is true. So there is come more to a release than pick a commit. If you overlay that with a LTS branch which has back ports you potentially get the best of both worlds. People who want to move forward track the head release, people who want to skip a few cycles track the LTS release. 

In this model you only perform point releases to the LTS and only selectively backport

Its a very aggressive model... 

I also think there could be some challenges with the way modules are versioned / pulled forwards.

Perhaps this should be on a thread of its own though. 

[David Anthoff]

Yes, the whole 0.3.x cycle was fantastic, regular small updates that never broke anything (at least for me).

 

I think it is worth looking back and seeing why the array stuff is nowhere near ready. My sense is that major work/discussions stopped around March/April, because there was a general agreement that this couldn’t be finished for 0.4. Of course, at that point the general expectation was that 0.4 would be released very soon (not sure whether the idea was a release before JuliaCon, or even earlier). As things stand now, my rough guess is that the whole array work was paused for about half a year?

 

To me that is the real cost of the loose management of the 0.4 cycle. As a user, I couldn’t care less about the long release cycle of 0.4, especially given how solid the 0.3.x stuff was. But having a 6 month time window where important work is paused because everyone expects a release in 4 weeks, but then a constant stream of new stuff is allowed into master (like the whole doc conversion) that pushes things back. The net effect of that is that a 1.0 will happen later than needed, because important features like the array stuff are on hold for such a long time.

 

The root problem seems to be that one group of devs apparently stopped the array work in March/April because they thought the project was close to a release, and another group of devs (e.g. the doc people) operated on a very different schedule assumption.

 

I don’t think anyone is to blame for this, certainly not the devs who did all the fantastic work on the two features I mentioned. But I do think it would help the project enormously if there was a release manager who communicates schedules, sets rules for when stuff can go into master and when it can’t and who especially manages the last couple of weeks of a release in a somewhat unpopular way (“no, this can’t go in” being the main message this person should type a lot). I think only someone from the core group could do that because this is a) a really tough job and b) it needs to be someone who has earned the respect of all the core people.

 

Cheers,

David

 

From: juli...@googlegroups.com [mailto:juli...@googlegroups.com] On Behalf Of Stefan Karpinski
Sent: Monday, September 14, 2015 12:59 PM
To: juli...@googlegroups.com
Subject: Re: [julia-dev] Code Release: Gallium.jl - The julia debugger

 

On Mon, Sep 14, 2015 at 3:51 PM, Michael Francis <mdcfr...@gmail.com> wrote:

[Michael Francis]

David, 

I second your comments about the great management of the bug fixes to 0.3.x

I 100% agree that for a release to work you have to have a build master who gets the go/no go on what ends up in the release. It's a tough role that needs a thick skin. 

[Stefan Karpinski]

On Mon, Sep 14, 2015 at 4:21 PM, Michael Francis <mdcfr...@gmail.com> wrote:

Probably 2 weeks here doesn't make sense, that was more for context,  but keeps people on their toes. The model can be extended to a longer time scale. The real point is that for a feature to be included in the next release it has to be ready much earlier. If the array stuff isn't ready for testing now'ish I'd argue that it can't be part of the next release and other major items should be pulled forward.

The whole point of the 0.5 release is to get all the array changes done at once. Delaying that any further seems like a much worse option.

[David Anthoff]

+1

 

If it was me, I would set the schedule of 0.5 based on the array work. Other major things could go in early in the cycle, but only array work would be allowed to push the 0.5 release schedule.

 

From: juli...@googlegroups.com [mailto:juli...@googlegroups.com] On Behalf Of Stefan Karpinski
Sent: Monday, September 14, 2015 2:18 PM
To: juli...@googlegroups.com
Subject: Re: [julia-dev] Code Release: Gallium.jl - The julia debugger

 

On Mon, Sep 14, 2015 at 4:21 PM, Michael Francis <mdcfr...@gmail.com> wrote:

Probably 2 weeks here doesn't make sense, that was more for context,  but keeps people on their toes. The model can be extended to a longer time scale. The real point is that for a feature to be included in the next release it has to be ready much earlier. If the array stuff isn't ready for testing now'ish I'd argue that it can't be part of the next release and other major items should be pulled forward.

[Michael Francis]

I wasn't implying that you would delay the timing of the array release (although if it isn't ready now then there is an open question regarding how much effort is going to be required to complete it and migrate the packages to be compatible - the array changes seem more far reaching than this round of changes) 

Feb is not that far away and there are other changes piling up, 18 of which are tagged as breaking.  So 0.5 could be some of those with 0.6 being the array changes when they are ready (ideally well before a Feb release date.) 

Again this comes from the context of a different very aggressive build process which may or may not be applicable to Julia. 

[Stefan Karpinski]

This has basically been my role – you can see me saying yes or no to things pretty regularly, aka, going around being a jerk like it's my job. Maybe we need to formalize that role for the next release cycle; I'm happy to continue doing it or someone else can do it.

Array behavior hasn't changed in 0.4, but the implementation has been radically refactored. This refactoring allows different array types to implement a few scalar operations and get all the shared high-level array behaviors for free and with good performance. It's also pretty easy now to change the high-level semantics of all array types at once. You can get an approximation of the work that's been done here by looking at all the non-doc PRs that Matt Bauman has merged:

https://github.com/JuliaLang/julia/pulls?q=is%3Apr+author%3Ambauman+is%3Aclosed

This approach was a strategic: change as many things as we can now without breaking people's code, to make it as easy as possible to make breaking changes in 0.5. Regarding the concern about development time lost, I don't think that's the case – it's not like the people who would/will be making changes to how arrays work were sitting around doing nothing; those same people have been doing lots of other work. In my experience it's kind of a good thing to have a period of silent contemplation before embarking on a major redesign like the arrays. Not actively thinking or working on arrays for a few months before the Arraymageddon is a good thing.

[Stefan Karpinski]

On Mon, Sep 14, 2015 at 5:32 PM, David Anthoff <ant...@berkeley.edu> wrote:

If it was me, I would set the schedule of 0.5 based on the array work. Other major things could go in early in the cycle, but only array work would be allowed to push the 0.5 release schedule.

That is exactly the plan.

[Michael Francis]

It is probably one of the most important roles when you need to get a release out - Personally I would positively identify the person so that people know they are playing that role. This way they get both the credit for doing the un-enviable task and also the trust that they are the final arbiter.

[Tony Kelman]

The plan last time around for 6 months of feature development and 3 months of stabilization didn't work out so well, but in hindsight I think we've learned our lesson to not repeat a large undertaking like the doc conversion late in a release cycle.

Now's the right time to discuss and plan what needs to be done on release-defining array changes for 0.5. Hopefully we can break it up into smaller incremental PR's rather than having one large hard-to-review one like #8745 for package precompilation, which took longer than planned to finish and merge. Coming up with more of a roadmap this time would be good.

I intend to continue doing the same level of backports and point release cadence on release-0.4 that I've been doing (with help) for most of the year on release-0.3. I want to augment it with more thorough testing than we've done before, leveraging PackageEvaluator more heavily ahead of time and assisting with running it regularly on both master and release-0.4.

We've gotten a ways off-topic from the debugger though, sorry Keno!

[Scott Jones]

OK, even on a machine that has never had Xcode 7 betas installed (it is running Xcode 6.4), I get this error, starting totally from scratch, hadn't built Julia on this before.

Machine is running 10.11 El Capitan beta 8.

llvm[6]: Compiling macosx/Host.mm for Release+Asserts build

In file included from /Volumes/Julia/julia/deps/llvm-svn/tools/lldb/source/Host/macosx/Host.mm:61:

In file included from /Volumes/Julia/julia/deps/llvm-svn/tools/lldb/source/Host/macosx/cfcpp/CFCBundle.h:13:

/Volumes/Julia/julia/deps/llvm-svn/tools/lldb/source/Host/macosx/cfcpp/CFCReleaser.h:13:10: fatal error: 

      'CoreFoundation/CoreFoundation.h' file not found

#include <CoreFoundation/CoreFoundation.h>

         ^

1 error generated.

There is a CoreFoundation.h, it is at:

./Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/CoreFoundation.framework/Versions/A/Headers/CoreFoundation.h