v0.4 deprecations: AbstractString, Union{}

[sebastiang]

Eliminates warnings when running under julia v0.4. Implemented by lifting minimal required code from Compat.jl to do the job. Only one piece of code looks potentially dangerous when actually dealing with arbitrary strings (AbstractString), where a [1:end-3] subset is taken, but this is correct because you know the final three bytes of the string are .jl as you've just tested them.

[sebastiang]

So this PR resulted in some failures on CI testing -- crashes on freeing bad pointers -- but I don't see a particular pattern to the failures. It's certainly conceivable that the change of string types is resulting in pointer problems. Do you experience these problems periodically with the infrastructure?

[waTeim]

In this case it appears that in at least 1 case and possibly 2, the errors are erroneous, and it's Travis as fault (npm download of the package failed). As far as Julia 0.4 and node 0.10 goes, it's because of the way the build system is set up (again), which tests against "released" Julia which used to be 0.3, but now it's 0.4 and because there apparently remains a problem (due to libuv) between node 0.10 and Julia 0.4 -- especially on OS/X. that's failing.

I've restarted this builds to see.

[waTeim]

Ok so here's what I think is going on.

• Unfortunately node 0.10 and Julia 0.4 are currently not compatible. The reason is that some libuv stuff is exposed directly during the initialization of libjulia, which is using node's libuv, not Julia's. This can ultimately be fixed, but not right now. This really is unfortunate, but now that node 0.10 is 2 major versions behind the LTS node, I'm proposing that we try to migrate away from node 0.10.
• Julia nightly's are a moving target, I see that 0.5 on OS/X is different than the dev 0.5 on Linux, by a lot actually, and now there's some new change to Julia that has broken compatibility.

Yes time for an update. So this is what propose to do. I will update the checks so that node 10 is no longer checked against "releases". I will add a new one against Julia 0.3. If there is a future change that breaks backward compatibility there I can make a branch of node-julia that maintains compatibility with Julia 0.3, but expect over the course of the next year that no one will be interested in Julia 0.3 either. Meanwhile I will add what is necessary to un-break Julia 0.5 while trying to maintain backwards compatibility with earlier versions of Julia 0.5 to keep the linux variant also work -- this historically has been possible but at time difficult.

[sebastiang]

That seems reasonable. I kept up with the v0.4 train as it ran because I was learning the language and just starting out. But at the moment I have no desire to keep up with the v0.5 nightlies! As far as node goes, I agree. It's a shame because AWS Lambda is on node v0.10, but since I'm not actually doing anything there yet, I can't get too excited about spending a bunch of time on it. We're using v0.12 ATM

[waTeim]

Yea I can't believe AWS here, they are clearly behind, and they've been given a year's+ heads up. Perhaps OpenShift is just plain better because of that.

[waTeim]

It appears that the check is failing for a more subtle reason, it appears to be a combo of Mavericks, version 6.0 of Xcode, and node 4.x. This does not happen on Yosemite with xcode 7.0, but unfortunately Mavericks old enough now, that it's hard to debug the problem when the error is so opaque. Between mav and yosemite and the xcode that supports them, the included c++lib changed significantly, this is likely contributory. For now I'm disabling checking node 4.x with travis and leaving node 0.12 as a proxy. Not ideal.

[waTeim]

This pull request seems fine though, much thanks!

[sebastiang]

:+1: