Julia: Errors in startup.jl result in not being able to enter REPL

Created on 22 Oct 2020  ·  4Comments  ·  Source: JuliaLang/julia

Currently, exceptions or parse errors in ~/.julia/config/startup.jl result in not being able to enter REPL. Ideally, if there are errors in startup.jl, the same stacktrace would be displayed, followed by the usual Julia startup message and a REPL prompt.

If this is indeed an issue, I would be interested in fixing it.

~ ❯❯❯ echo 'error(0)' > ~/.julia/config/startup.jl
~ ❯❯❯ julia
ERROR: LoadError: 0
Stacktrace:
 [1] error(::Int64) at ./error.jl:42
 [2] top-level scope at /home/julian/.julia/config/startup.jl:1
 [3] include(::Function, ::Module, ::String) at ./Base.jl:380
 [4] include at ./Base.jl:368 [inlined]
 [5] include_ifexists at ./client.jl:213 [inlined]
 [6] load_julia_startup() at ./client.jl:328
 [7] exec_options(::Base.JLOptions) at ./client.jl:267
 [8] _start() at ./client.jl:506
in expression starting at /home/julian/.julia/config/startup.jl:1
~ ❯❯❯
~ ❯❯❯ echo 'throw(DomainError(0))' > ~/.julia/config/startup.jl
~ ❯❯❯ julia
ERROR: LoadError: DomainError with 0:

Stacktrace:
 [1] top-level scope at /home/julian/.julia/config/startup.jl:1
 [2] include(::Function, ::Module, ::String) at ./Base.jl:380
 [3] include at ./Base.jl:368 [inlined]
 [4] include_ifexists at ./client.jl:213 [inlined]
 [5] load_julia_startup() at ./client.jl:328
 [6] exec_options(::Base.JLOptions) at ./client.jl:267
 [7] _start() at ./client.jl:506
in expression starting at /home/julian/.julia/config/startup.jl:1
~ ❯❯❯ 
~ ❯❯❯ echo 'x y' > ~/.julia/config/startup.jl
~ ❯❯❯ julia
ERROR: LoadError: syntax: extra token "y" after end of expression
Stacktrace:
 [1] top-level scope at /home/julian/.julia/config/startup.jl:1
 [2] include(::Function, ::Module, ::String) at ./Base.jl:380
 [3] include at ./Base.jl:368 [inlined]
 [4] include_ifexists at ./client.jl:213 [inlined]
 [5] load_julia_startup() at ./client.jl:328
 [6] exec_options(::Base.JLOptions) at ./client.jl:267
 [7] _start() at ./client.jl:506
in expression starting at /home/julian/.julia/config/startup.jl:1
~ ❯❯❯
~ ❯❯❯ echo '' > ~/.julia/config/startup.jl
~ ❯❯❯ julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.1 (2020-08-25)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> 

versioninfo() output:

julia> versioninfo()
Julia Version 1.5.1
Commit 697e782ab8 (2020-08-25 20:08 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-9.0.1 (ORCJIT, haswell)

Most helpful comment

I suppose one option is to hard-error in non-interactive mode and soft-error in interactive mode.

All 4 comments

Personally, I feel like erroring is better. What if you had something important in there and now you are running Julia without it?

Do you know about the --startup-file=no option?

Personally, I feel like erroring is better. What if you had something important in there and now you are running Julia without it?

The errors would still be visible, just above the first line in REPL.

When errors appear in the startup file, do we want to force the programmer to either fix them immediately before accessing the REPL or to keep passing --startup-file=no until the issue is resolved? I believe that having access to an interactive Julia session (without having to remember an appropriate option name) would be useful when fixing bugs in the startup file.

Both Python and Ruby behave in the proposed way, without blocking access to REPL:

$ echo 'x y z' > start.py
$ PYTHONSTARTUP=`realpath ./start.py` python3
Python 3.7.5 (default, Apr 19 2020, 20:18:17) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
  File "/home/julian/start.py", line 1
    x y z
      ^
SyntaxError: invalid syntax
>>>
$ echo 'x y z' > ~/.irbrc
$ irb
load error: /home/julian/.irbrc
NameError: undefined local variable or method `z' for main:Object
        /home/julian/.irbrc:1:in `<top (required)>'
        /usr/lib/ruby/2.5.0/irb/init.rb:228:in `load'
        /usr/lib/ruby/2.5.0/irb/init.rb:228:in `run_config'
        /usr/lib/ruby/2.5.0/irb/init.rb:20:in `setup'
irb(main):001:0>

I suppose one option is to hard-error in non-interactive mode and soft-error in interactive mode.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

manor picture manor  ·  3Comments

TotalVerb picture TotalVerb  ·  3Comments

iamed2 picture iamed2  ·  3Comments

felixrehren picture felixrehren  ·  3Comments

omus picture omus  ·  3Comments