Kristoffer Carlsson
Kristoffer Carlsson
> Base64 is an indirect dep of REPL, so it's already loaded? Okay, that makes sense, I looked in ` Base.loaded_modules` and it wasn't there so I assumed it wasn't...
> There @kshyatt nailed down the problem to https://github.com/JuliaLang/julia/commit/71fa11f0427fc66f2328cddbba865852fa47e0f1. Same thing happens when I revert that commit.
Yes, I think they are unrelated.
Same happens with OhMyREPL on nightly: ``` ┌ Debug: Loading object cache file /Users/kristoffercarlsson/.julia/juliaup/julia-nightly/share/julia/compiled/v1.12/StyledStrings/UcVoM_44pG1.dylib for StyledStrings [f489334b-da3d-4c2e-b8f0-e476e12c162b] └ @ Base loading.jl:1227 ┌ Debug: Rejecting cache file /Users/kristoffercarlsson/.julia/compiled/v1.12/OhMyREPL/08e1i_J2Ppx.ji because required dependency...
The assumptions for how the loading system now works with the new "upgradable stdlib" stuff is only known by one person now I think so I assign this to that...
AFAIU, the issue is that we have two REPL modules loaded and `Base.active_repl` will be a different type of REPL than what is type asserted at https://github.com/JuliaLang/julia/blob/125bac4b9022ad9ff9c355e4810f94512739bac6/stdlib/REPL/src/REPL.jl#L764. Basically, there is...
Pkg is not in the sysimage so I don't know why that PR would have an effect on this.
I think this is the require_stdlib thing that the `]` key is bound to which won't load the extension of the currently active Pkg project.
> An improved experience might be something like: So always take the first? How about: ``` julia> "foo"[4] ERROR: BoundsError: attempt to access 3-codeunit String at index [4] Stacktrace: [1]...
> I think so? The error message itself is pretty clear, the stack trace seems dispensable? But how would you know where in your code the problem originated from?