Julia v1.4.0 has been released

Announcements
#6

We already do exactly that. We test all registered Julia packages (registered in the General registry) prior to making a Julia release. We also do this every day on the latest Julia master. See:

  1. ANN: Nanosoldier package evaluation -- with badges!
  2. https://github.com/JuliaCI/NanosoldierReports
  3. https://github.com/JuliaCI/Nanosoldier.jl
  4. https://github.com/JuliaComputing/NewPkgEval.jl
7 Likes
#7

The problem you were experiencing was due to some issue with your local environment, as evidenced by the fact that it was fixed by rm -rf ~/.julia.

In general, when people experience an issue with packages, my first advice is always to rm -rf ~/.julia. I know that it seems extreme, but it really does fix the vast majority of problems.

6 Likes
#8

Note that this could lead to work lost in packages checked out for development. May not be an issue for new users though.

I think that the manual should contain advice about this, cf

6 Likes
#9

That’s a good point. I suppose my advice should actually be:

  1. Commit all changes in any packages that you have checked out for development
  2. Push all changes to a remote (GitHub, GitLab, etc.)
  3. rm -rf ~/.julia

And of course, if you don’t have any packages checked out for development, then you simply do:

  1. rm -rf ~/.julia
1 Like
#10

It seems overly drastic to start by removing lots of files and REPL history and what not. My advice if you suspect problem with your depot would be to create an empty directory somewhere and point JULIA_DEPOT_PATH to it. If that works you can start to think about removing stuff in ~/.julia. If it doesn’t the problem is likely elsewhere and no amount of destruction in your normal depot will help you.

2 Likes
#11

Rather than removing ~/.julia, I would suggest looking at the [compat] section of Project.toml of the two MJL versions


If I interpret correctly, if you had installed Distributions v0.23 a few days ago, then you would not fulfill Distributions = "^0.21,^0.22", and the installer would fall back to MLJ v0.2.3.

MLJ v0.2.4 would not install since it depends on MLJBase = "0.2.3", which maybe was hold back by CSV = "0.5" in https://github.com/alan-turing-institute/MLJBase.jl/blob/v0.2.3/Project.toml

2 Likes
#12

This might be a case for the developers applying monotonic bounds in RetroCap. Going from 0.10 back to 0.2 is quite a difference, it would probably be more helpful to receive a Pkg incompatibility error.

3 Likes
#13

Sorry to report a glitch on Linux 64 bits with (old) AMD processor (Turion II M640)

Invalid instruction at 0x7ff8b4a3f1d0: 0x66, 0x0f, 0x3a, 0x0f, 0xc0, 0x08, 0x0f, 0x83, 0xae, 0x04, 0x00, 0x00, 0x48, 0xc1, 0xe0

signal (4): Illegal instruction
in expression starting at none:0
_ZN4llvm13LexicalScopes23assignInstructionRangesERNS_15SmallVectorImplISt4pairIPKNS_12MachineInstrES5_EEERNS_8DenseMapIS
...
jl_module_run_initializer at /buildworker/worker/package_linux64/build/src/toplevel.c:74
_julia_init at /buildworker/worker/package_linux64/build/src/init.c:788
unknown function (ip: 0x401527)
__libc_start_main at /lib64/libc.so.6 (unknown line)
unknown function (ip: 0x4015d4)
Allocations: 2502 (Pool: 2493; Big: 9); GC: 0
Illegal instruction (core dumped)

More info on https://github.com/JuliaLang/julia/issues/35215, where alea54 was the first to report issue on AMD Phenom

#14

Just want to confirm, what LLVM binaries were being used when building those released Julia binaries? It looks like there’re compatibility issues on Windows and Linux:

Edit:

I noticed the Julia version on Travis CI is still Julia-1.4rc2, this might cause the above issue. (fixed now)

#15

What can I do to fix issues while keeping most of the useful stuff, like my repl history?

  • For example, should I just back up my repl_history.jl file, and copy it back over after rm -rf ~/.julia?
  • What else should I try to keep? Any suggestions?
  • How do I automatically reinstall all packages after deleting them?
2 Likes
#16

To build on what people here are saying:
I installed Julia 1.4.0, then rm -rf ~/.julia.
Next installed MLJ.jl, followed by Distributions.jl.
Here is the message I got:

(@v1.4) pkg> add Distributions
  Resolving package versions...
   Updating `~/.julia/environments/v1.4/Project.toml`
  [31c24e10] + Distributions v0.22.6
   Updating `~/.julia/environments/v1.4/Manifest.toml`
 [no changes]

Next when I check status:

(@v1.4) pkg> status
Status `~/.julia/environments/v1.4/Project.toml`
  [31c24e10] Distributions v0.22.6
  [add582a8] MLJ v0.10.1

It would be great if

  1. Julia warns me when it adds a package which is not the latest or some kind of Pkg incompatability error as @tim.holy mentions:
`Note you have installed Distributions v0.22.6, not the latest 
Distributions v0.23.0 because it conflicts with MLJ v0.10.1.`
  1. Let Pkg.status() display two columns, the package I have & the latest version:
Package         Installed version	Latest version
Distributions   v0.22.6	                v0.23.0
MLJ             v0.10.1	                v0.10.1

I’d submit a PR to (https://github.com/JuliaLang/Pkg.jl), but not sure where to begin, or if others even want this.

5 Likes
Pkg.add updates other packages too?
#17

Yes, I usually keep ~/.julia/logs/repl_history.jl and the folder~/.julia/config, which I have some initialization file such as startup.jl before wiping out ~/.julia. In fact, it’s safer to copy ~/.julia to something like ~/.julia.bak before wiping out ~/.julia.
As for reinstalling the packages, you might want to copy e.g., ~/.julia.bak/environments/v1.3 folder to ~/.julia/environments/v1.4 if you have a large number of packages. But usually, when the new version of Julia is released, I install various packages from scratch and try to install/add only really important packages for my projects. That way, I can cleanup and remove some unnecessary packages that I happened to try previously.

3 Likes
#18

@tim.holy I am not familiar with RetroCap and am confused about its use. Is the idea that a developer applies it to a local version of General.jl (somehow restricting its application to the repos owned by the developer) and then makes a PR to General?

ERROR: Unsatisfiable requirements detected for package TreeViews [a2a6695c]
#19

Exactly. The PR will be manually reviewed, and shouldn’t be merged if it touches repos that the submitter doesn’t have significant developer stake in.

3 Likes
#20

Instead of rm -rf ~/.jullia it’s better to recommend mv ~/.julia ~/.julia.bak, which is safer. I’m just pointing this out because I don’t want people to accidentally delete their work.

18 Likes
Is there a simple Julia upgrade command?
#21

After upgrade to v1.4 from v1.3, I have this warning message: Warning: Pkg.installed() is deprecated. What should I use instead under Pkg v1.4?

1 Like
#23

Pkg.dependencies().

1 Like
#24

This is a great suggestion. I’m usually of the rm -rf ~/.julia type but now I’m much wiser after reading your comment. While I don’t mind re-installing packages again, I do miss my repl_history when I start from scratch.

2 Likes
#25

Not to come off as rude or anything but I think macOS is broken, at least for Catalina. I am opening a full thread on it, but I’m leaving this comment here as future reference.

#26

For the record it works just fine for me on Catalina.

5 Likes
Issue with Upgrading to 1.4 on MacOS Catalina