Hacker News Reader

Comment by plinkplonk | Hacker News Reader

I second the move to a precommit based system. Getting a rock solid build is low hanging fruit for most projects, And getting to that point is usually just straightforward engineering. That said, this is a young project, and probably just needs more developer bandwidth to fix these minor glitches.

View on HN

The problem with Travis failures is not that people aren't running the tests, it's that Julia depends on a lot of complex, finicky software [1], much of which is unusually sensitive to platform-specific differences and even differences between specific CPUs and VMs. This makes keeping builds green across the board pretty challenging. But anyone who has tried to build a fully working numerical stack like the one Julia ships with, can attest that it's non-trivial and changes that work on one machine may break things elsewhere.

[1] https://github.com/JuliaLang/julia#required-build-tools-and-...

In contrast, getting R up and running is very easy. I can easily set up multiple R versions on my machine. If I want to emulate a library environment on another machine, I just need to copy the folder over to that machine.

Are you talking about compiling R from source, including all dependencies and high-performance BLAS, LAPACK, FFT, ARPACK, etc. libraries? If not, you are comparing apples to oranges.

Yes. You can get multiple versions easily on the same machine and run them from that location. It's also easy to point rstudio to that instance. All the libraries install in the same location as well.

R ships with the reference BLAS which is 4x slower than OpenBLAS even on modestly sized problems. If you value portability over performance, I guess that's an ok choice, but we want to make sure that Julia ships with the best open source BLAS available. If that means putting up with the occasional broken builds on Travis, I think it's worth it. OpenBLAS is just one example – R seems to have consistently chosen portability over performance for their libraries. That's a viable choice, but it's not the one we've made.

This isn't quite true. I know of several R packages that I've had to build from source on Linux and I'd be worried about installing on windows (Combinations and Cranvas come to mind).

Generally the packages that aim for higher performance are more difficult to install, which makes sense.

Combinations: http://www.omegahat.org/Combinations/

Cranvas: https://github.com/ggobi/cranvas

edit: and if, god forbid, cran kicks off one of the packages you're using or an upstream package for a package you're using, then you've got to track it down and install it on your own. (tikzDevice is the one I'm thinking of.)

I understand, but having so many dependencies is probably all the more reason why you need very good test coverage and a build/deploy that keeps the trunk clean, so nothing gets released without all three (or however many) platforms all build clean.

Not to armchair quarterback, I know it is a hard thing to get there and you guys are all busy. Just my 2 cents.

(And I think Julia is bloody brilliant, fwiw)

Reply on news.ycombinator.com