Simple question: Is there a reason why 1.0 was not yet announced here?
I’m glad 1.0 was released even if the package ecosystem is nowhere near ready. There’s been more than enough transparency about 1.0 plans for experienced Julia users to make an informed decision on when to upgrade. I’m still on 0.6.4 myself and will probably stay there for several more weeks.
But newbies who catch the 1.0 announcements and blog posts don’t have that information. So I simply wish there was a big red box on the download page telling everyone up front that the language itself is ready but the packages will need some time to catch up. And that everyone who needs most packages to work should probably stick to 0.6.4 for now.
I for one can admit that this described me exactly. I didn’t update my packages until I saw the 1.0. Why? Mainly laziness, a touch of fear that the target will keep moving, and mostly dread that it would be too hard. In the end it took literally 10 minutes to bring two packages to zero warnings in 0.7. So easy.
I’ve had to roll back to v0.6 myself. I am unable to get v0.7 or v1.0.0 to work with longstanding packages like Plots.jl.
So I’m guessing that precompile errors such as I see with “using Queryverse” on a new installation of Julia v1.0-rc1 would simply be due to the referenced package not being updated to be compatible? Sounds like it might be a little hit or miss for a while.
Especially considering that new deprecations were added on the eve of 0.7, I feel like the 1.0 release was a bit rushed. (I had already updated most of my packages for 0.7, but in many cases I need to update them again.)
The whole point of having a 0.7 release was to give people time to fix deprecations before they became errors. Releasing 1.0 just a few days after 0.7, so that most users skip the 0.7 release entirely, eviscerates that plan.
Anyway, water under the bridge, I suppose. In a month or so the transition will have smoothed out, but in the meantime there are likely to be a bunch of confused users.
I agree. While I trust the core devs that if they say 1.0 is ready then it is ready, that doesn’t mean it has to immediately be presented as the “default” current version of the language.
I think there is a simple fix for this for which it is not too late: have the Julia download page explain the situation. Tell users that they can download 1.0, and much may work with it, but that 0.7 is a transitional release intended to make it easier to port the 0.6 code, which up until about a couple of weeks ago was the latest release. Then, in a month, hide 0.7 altogether and render it ancient history. At that point at least it can be said that the maintainers of packages which break on 1.0 haven’t done their due diligence to catch up with the current release. A lot of potentially irritated users can be saved a lot of grief simply by changing the order in which the download links appear.
Hah, I didn’t realize it hadn’t been. I think with all the excitement of JuliaCon, getting the binaries up, getting the blog post up and fixing up the new website, everyone just assumed someone else must have done it. Apologies—I’ll write a post.
Can we have a status page on the Julia site that shows a list of critical packages (e.g. ones that receive many stars on GitHub) and if they are ready for 1.0?
Currently we are in a blinded situation that nobody knows what works and it becomes a trial and error exercise. Not great for newbies either.
The 1.0 download page should have a link to this status page. We could just say that the language runtime is ready but many packages in the ecosystem still need time to upgrade.
It seems IJulia does not work. I tried
“]”, that brought up
pkg > add IJulia
… but it did not add IJulia as I did not see a Julia-1.0.0 in the Jupyter notebook.
I have used a Macbook pro High Sierra 10.13.4
Same issue I had. Try
build IJulia. It worked for me after that. I am not sure why though.
My perspective below is as a user eagerly waiting for 1.0 since about a year when I wrote a large-ish code base in Julia 0.6 (I resisted trying out 0.7 since my code was working perfectly in 0.6). I finally updated my code to 0.7/1.0 over the past couple of days.
I did feel a bit of unease directly porting my current 0.6 code to 1.0 mainly because the deprecation warning are not thrown in 1.0. But once I realized this and tried things on 0.7, it hardly took any time to fix things blindly following the instructions in the deprecation warnings. For those who have kept themselves in the loop over the transition from 0.6 - 0.7 - 1.0 (i.e., package developers) this might have been a known fact, but for me it was overwhelming at first (scary when even
srand() throws an error ).
For newbies discovering the language from the new webpage, they will probably see a shiny, powerful, familiar language that needs a good introduction book. For hopeful past users like me, there needs to be a single line somewhere prominent that if 1.0 breaks all functions you used before, try things out on 0.7 first
End of it all, I think 1.0 needed the marketing it got (and a bit more) and is truly an awesome release.
build IJuia did work on REPL, so I now have Julia as an inferior process on my Jupyter and that’s fine.
But I cannot add a new package from Jupyter; I will have to go back to REPL and refresh. This is not a problem with Julia 0.7.
I suppose that’s the new hurdle. In Jupyter, how do I use Julia 1.0.0 to add packages, etc.
I gave up after a while.
You use e.g.
returns the following error:
UndefVarError: Pkg not defined Stacktrace:  top-level scope at none:0
using Pkg? Or do
Thanks @PetrKryslUCSD, but none of them work unfortunately in the Jupyter notebook running Julia 1.0-rc1
]add Gadfly would return
syntax: unexpected "]"
using Pkg pkg"add Gadfly"
:-), excellent @ValdarT !
using Pkg pkg"add Gadfly" Pkg.add("Gadfly")
Gadfly fails to precompile with Julia 1.0.0
Try to use the 0.7 kernel. If Gadfly failed to compile due to a deprecation, this will fix it.