Best practices for developing in julia/base/*.jl

[Tom Short]

What's the best way to experiment or develop code inside of julia/base/*.jl?

After every change, I've been doing `make` followed by restarting
Julia. That's quite a long edit/compile/debug cycle, though.

[Viral Shah]

That is what I do. There used to be a time when you could reload modified files, but that stopped working since we got modules.

-viral

[Jasper]

Only just noticed `evalfile`, it does seem to actually load the file
like `load` used to.

About workflow: With Common Lisp, using SLIME, i had another way of
working than the repl or running make intermittently; i'd just write in
the file i was working and evaluate bits of the file i wanted to look
at. Hopefully at some point Julia will be able to do that too.

[Toivo Henningsson]

I think that depends entirely on how intertwined the new functionality is with what is already in Base. Of course, first develop it outside of Base as far as you can, if that is possible. Also, I think that you should be able to monkey-patch Base by Base.eval(mycode). That's probably not 100% reliable, but it might very well be worth the shortened development cycle. Of course, there's still no substitute for rebuilding julia to make sure that it works in the end.

[Michael Fox]

I was wondering if there's any updates on this story? Is edit; make clean all; test; still the preferred way to hack up base?

[Ivar Nesje]

It is enough to type "make", "make clean" is only needed if "make" fails.

[David van Leeuwen]

Hello

Is this still the workflow for experimenting with base/*.jl?   Is it possible that just a single file from base gets reloaded/recompiled in make?

Rebuilding the base after every change makes this a very long turn-around time. (of the order of minutes on my machine)

---david 

[Mike Innes]

Juno will let you eval into the base module directly if you open up a file in Base. 0.4 support is still in the early stages though.

[Pontus Stenetorp]

On 12 December 2014 at 09:01, David van Leeuwen

My set-up is usually to either start from scratch in a new file
outside of base for smaller changes, then write tests in the same
file. If it relies more heavily on existing code I copy the existing
file out of base and delete whatever I don't need. Once I am
done I integrate the code/tests back into base and do a final check
before filing a PR. I am not overly in love with this approach, but
it works and alleviates most of the overly long turn-around time.

Side-note, I could have sworn that I asked this very same question a
few months ago, maybe it was over on the IRC channel.

Pontus