Animated progress. Beautiful!
21 Likes
It isn’t just fancy, it’s also faster as precompilation is now parallel:
31 Likes
Yeah. Combine that with the parallel precompilation and much better loading times, and it is a really great release. (also the other color work for things like @code_native etc are so nice). Really 1.6 feels like the first julia version where we finally added all the nice to have things that don’t fundamentally change anything, but just make the whole language more of a joy to use.
22 Likes
Indeed, I noticed. Nice!!!
1 Like
Pre-compilation occurs during instalation, right? (Instead of in the first using) If so, that makes much more sense and improves a lot the first impression.
3 Likes
It can be a little bit annoying as if you add n packages independently, you can end up with O(n^2) precompile, but it’s a pretty good balance. The best time for precompile might actually be when exiting dev mode, but that would probably be annoying to implement.
2 Likes
It isn’t instead: precompilation now happens automatically after most Pkg operations, but if for example you modify a deved package, at the next restart it’ll be precompiled again at using time. It’s just that now it’s less likely that a package isn’t precompiled when you using it
5 Likes
@PetrKryslUCSD Are you using 1.6 for your day-to-day work? If so, any problems?
I’ve been using v1.6 for day-to-day work for a month or so. I’m primarily on Windows, so this issue pushed me to work with a Linux v1.6 binary installed on WSL2, but it seems to be fixed now that this PR’s been merged. Julia’s Linux binaries are typically the most robust, since many of the core devs use it as their primary platform.
Not yet. I had to wait for LoopVectorization to catch up.
Update: it looks like I will have to wait a little bit longer. 1.6 has some difficulties installing/updating the registry on Windows 10. https://github.com/JuliaLang/julia/issues/38691
If you happen to depend on LoopVectorization, 1.6 is still out of reach, since this package hasn’t been updated yet.
1 Like
LoopVectorization 0.9 works on 1.6 (but the Windows registry issue could be another show stopper until it gets fixed).
3 Likes
Downloads are much faster too since we use libcurl and can share and reuse TCP+TLS connections.
8 Likes
You are right. Sorry. It is the damn dependencies: it pulled 8.2.6, which I thought was okay. But apparently the new one is 0.9…
I will then rephrase my previously stated opinion: we need some way of detecting newer package versions.
4 Likes
What do you mean?
So the case here is FinEtools.jl when run in 1.6 needs LoopVectorization 0.9. But in 1.5 it needs 0.8.
And, when tested in 1.6, the test fails, because 0.8 LoopVectorization is requested.
So, it would be helpful if I could run a command say Pkg.newer() that would detect all newer versions of the packages requested in the current environment. I believe that Pkg.update() will not do that, since it is quite happy to report that given the requirements in the project, all packages are okay.
1 Like
It isn’t a matter of “detecting” new versions, Pkg.update updates the registry and is already aware of all new versions. However, Pkg.update respects all compatibility requirements in your environment. If it doesn’t update a package to a newer version, probably it’s because something else is holding it back because of compatibility bounds. What would be useful is a tool to easily investigate why a package is held back.
3 Likes
Are you sure? If the project asks for 0.8, are you certain that if 0.9 is available it will update? I haven’t seen that.
One possible fix would be for up to give warnings for packages that don’t get their newest release installed (or maybe their newest feature release according to semvar)
3 Likes