Issue at REPL with 1.11---am I doing something silly here?

General Usage
1

Hi all—

I see that 1.11 is out and I’m super excited to use it and play with the new Memory type and stuff. I am sure this is just me doing something silly, but I am getting a lot of errors in the REPL before doing anything and I’m wondering if somebody has any suggestions about what I can do to fix it.

I installed 1.11 with juliaup add 1.11, and juliaup default 1.11 says it isn’t installed (strange), but I could juliaup default release and that worked fine and gives me a 1.11 REPL and stuff.

But I’m having a funny issue: if I open a REPL with no flags, I can press ] and get the Pkg prompt just fine:

cg:~> julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.11.0 (2024-10-07)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

(@v1.11) pkg> 

(@v1.11) pkg> # pressed enter, no error

But if I open it with julia -O3 and press ], this happens:

cg:~> julia -O3
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.11.0 (2024-10-07)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

(@v1.11) pkg> Unhandled Task ERROR: ArgumentError: Package REPLExt [e5eb5ef1-03cf-53a7-ae1d-5a66b08e832b] is required but does not seem to be installed:
 - Run `Pkg.instantiate()` to install all recorded dependencies.

Stacktrace:
  [1] _require(pkg::Base.PkgId, env::Nothing)
    @ Base ./loading.jl:2423
  [2] __require_prelocked(uuidkey::Base.PkgId, env::Nothing)
    @ Base ./loading.jl:2300
  [3] #invoke_in_world#3
    @ ./essentials.jl:1088 [inlined]
  [4] invoke_in_world
    @ ./essentials.jl:1085 [inlined]
  [5] _require_prelocked
    @ ./loading.jl:2287 [inlined]
  [6] _require_prelocked
    @ ./loading.jl:2286 [inlined]
  [7] macro expansion
    @ ./loading.jl:2587 [inlined]
  [8] macro expansion
    @ ./lock.jl:273 [inlined]
  [9] require_stdlib(package_uuidkey::Base.PkgId, ext::String)
    @ Base ./loading.jl:2542
 [10] macro expansion
    @ ~/.julia/juliaup/julia-1.11.0+0.x64.linux.gnu/share/julia/stdlib/v1.11/REPL/src/Pkg_beforeload.jl:8 [inlined]
 [11] macro expansion
    @ ./lock.jl:273 [inlined]
 [12] load_pkg()
    @ REPL ~/.julia/juliaup/julia-1.11.0+0.x64.linux.gnu/share/julia/stdlib/v1.11/REPL/src/Pkg_beforeload.jl:7
 [13] (::REPL.var"#119#137"{REPL.LineEdit.MIState, REPL.LineEditREPL, REPL.LineEdit.Prompt})()
    @ REPL ~/.julia/juliaup/julia-1.11.0+0.x64.linux.gnu/share/julia/stdlib/v1.11/REPL/src/REPL.jl:1233

I can’t ]add REPLExt, which I would have hoped would solve the problem.

Am I doing something dumb here? In case it is helpful, my machine information is

julia> versioninfo()
Julia Version 1.11.0
Commit 501a4f25c2b (2024-10-07 11:40 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 12 × 12th Gen Intel(R) Core(TM) i7-1260P
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, alderlake)
Threads: 1 default, 0 interactive, 1 GC (on 12 virtual cores)
Environment:
  LD_LIBRARY_PATH = :/opt/knitro-13.2.0-Linux-64/lib:/opt/knitro-13.2.0-Linux-64/lib:/opt/knitro-13.2.0-Linux-64/lib

For what it is worth, I can also reproduce this behavior on the following system:

julia> versioninfo()
Julia Version 1.11.0
Commit 501a4f25c2b (2024-10-07 11:40 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 128 × AMD EPYC 9554P 64-Core Processor
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver4)
Threads: 1 default, 0 interactive, 1 GC (on 128 virtual cores)
Environment:
  LD_LIBRARY_PATH = :/u/g/e/geoga/private/knitro-13.2.0-Linux-64/lib

Also, unrelated, but is there a way for me to turn off the visual autocomplete? It is a super cool feature and I commend whoever developed it, but personally I find it unappealing because of the (small) input lag it produces. I don’t see anything about it in julia --help or from googling things like julia 1.11 disable autocomplete.
EDIT: found the note about toggling this in the blog post. Sorry!

1 Like
2

I’m not sure about the rest, but to disable autocomplete, it’s in the blog post here: Julia 1.11 Highlights

you can put this in your startup.jl

atreplinit() do repl
    if VERSION >= v"1.11.0-0"
        repl.options.hint_tab_completes = false
    end
end
2 Likes
3

Also experienced errors in the REPL related to OhMyREPL.jl in my startup.jl:

┌ Warning: error while importing OhMyREPL
│   e =
│    InitError: UndefRefError: access to undefined reference
│    during initialization of module REPLExt
└ @ Main ~/.julia/config/startup.jl:5

This error is thrown by the usual:

atreplinit() do repl
  try
    @eval using OhMyREPL
  catch e
    @warn "error while importing OhMyREPL" e
  end
end
1 Like
4

Try "UndefRefError: access to undefined reference" in 1.11 beta · Issue #345 · KristofferC/OhMyREPL.jl · GitHub

3 Likes
5

I have got the same problem too. In the beginning I thought it may be something to do with OhMyREPL.jl. But after removing it from the startup.jl, the problem persists.

1 Like
6

Also for me—I commented out everything in my startup.jl and don’t use OhMyREPL.

2 Likes
7

I can reproduce the bug with -O3 and the package manager. Did you create a bug report?

2 Likes
8

No, I assumed that somebody would appear on the thread and tell me that I just missed something in the docs or announcement or something. But I’ll file an issue now.

2 Likes
9

I mean, who is using option -O3 ? Not many people. But it should work.

10

Thanks Chris!

For those looking for the issue, it’s here: v1.11 REPL error if starting julia with `-O3` · Issue #56054 · JuliaLang/julia · GitHub

1 Like
11

Wait, off-topic, but are most people not using -O3? Should I not be using it? I just assumed that I’d eat longer compile times and get slightly faster code for it, which is a trade I’m very happy to make and I would have guessed many people here are also happy to make.

12

Well, it depends on the problem you are trying to solve. But usually -O3 creates more problems than it brings of advantage, at least for my simulation tasks. But you might be solving different problems.

13

What do you mean? I think, but not sure, that -O3 enables some unsafe optimizations like @simd globally. At least @simd can, and should be applied be applied locally, and maybe all optimizations that -O3? Or least can be opted into for modules (or used to lower opt.). I think it’s rarely if even better to opt into it globally, but I would like to be proven wrong on it being unsafe, and know exactly what extra optimizations it brings. [There’s also I believe a possibility of more fine-grained global settings through LLVM but I forget how.]

14

I get an error even without the -O3 flag:

add ┌ Error: Error in the keymap
│   exception =
│    IOError: stat("Templates"): too many symbolic links encountered (ELOOP)
│    Stacktrace:

(above output truncated)

1 Like
15

Can you open a new thread for this problem?

16

That’s probably the same issue as Autocomplete fails if `stat` errors, on nightly · Issue #56037 · JuliaLang/julia · GitHub

17

Yes, of course.