search

JuliaLang / IJulia.jl

Julia kernel for Jupyter
MIT License
2.79k stars 411 forks source link

Set Base.active_repl when running via jupyter console #644

Open non-Jedi opened 6 years ago

non-Jedi commented 6 years ago

It would be really nice if IJulia implemented a subtype of Base.AbstractREPL so that the jupyter REPL experience could give a similar level of functionality to the vanilla julia repl (Don't know what else would be necessary for this other than setting Base.active_repl...). This is desirable because if you get jupyter working somewhere, you get most all of its kernels working there for free. I'm interested in this as an alternative to overcome some of the deficiencies of the ESS inferior julia or the emacs julia-repl package.

Don't have the knowledge to do this myself now, but if someone has an idea of how it would be done and can point me in the right direction, I'll take a stab when I get a chance.

EDIT:

Off the top of my head, the two major issues I currently have with running ijulia with jupyter console are:

  1. Vanilla julia REPL opens plots in the browser for both Gadfly and Plots. With IJulia, the only way I've been able to get plotting working is by saving the plots and then viewing them. (edit2: this might just be me not configuring jupyter right.)
  2. ASTInterpreter2 calls into Base.active_repl for much of its functionality.

I'm sure there are other problems I've had, but I think those are the two big ones.

MasonProtter commented 5 years ago

I just ran into this myself and would also like Base.active_repl to exist. Have you given any more thought to this?

stevengj commented 5 years ago

I think you have a misunderstanding of how Jupyter/IJulia works.

IJulia has no idea of whether it is connected to a Jupyter notebook, to JupyterLab, to qtconsole, or to the Jupyter console. It could be talking to all of them simultaneously. IJulia just gets requests for code to evaluate, and sends back the results. It has no control over the user interface that is presented. If there is a plot, it sends both the image (e.g. image/png) and text/plain form of the results, but has no control over which (if any) the front-end displays.

I'm not sure it is possible to define any REPL-like API.

stevengj commented 5 years ago

If active_repl just has an API to evaluate a block of code, we can provide that, but that's about all.

stevengj commented 5 years ago

I only see one place where ASTInterpreter2 uses active_repl, and it is to search the history for the definitions of code whose filename starts with REPL[ (which wouldn't apply to IJulia) … am I missing something?

MasonProtter commented 5 years ago

If active_repl just has an API to evaluate a block of code, we can provide that, but that's about all.

Yeah, that would be ideal. Currently, the help, shell and pkg interaction modes are hard coded into IJulia's execution model, I think it'd be nice if there was a way that IJulia could just spin up a REPL instance and just pass code to that repl to evaluate it. That way, we could make is so that repl mode keys like ?, ;, ] and whatever custom keys are defined by packages like ReplMaker.jl can just be sent to the REPL so that it deals with any special parsing of the code.

I find Julia's REPL code very frustrating to try to understand and I've searched searched the source code and asked online multiple times for how to pass a chunk of code / text to be evaluated by the repl and come up empty handed. If I ever do manage to understand the REPL better, I'll look into whether this could be a realistic approach for IJulia's execution model, though I wouldn't hold my breath for that.

As a more realistic alternative, maybe we can find a way for packages / users to add modifier keys to the current list and define separate parsing modes analogous to REPL modes but not actually using the REPL's overcomplicated machinery.

rfourquet commented 4 years ago

I had a similar need to enable a REPL mode in IJulia, and chose the hacky solution of hardcoding the mode in the "execute_request.jl" file, like is done for ";" (shell) and "]" (pkg) modes. If @MasonProtter 'idea above to "spin up a REPL instance and just pass code to that repl to evaluate it" is too impractical, it could be nice to allow user to pass to IJulia a "code transformation" function: this means having to duplicate the logic of a REPL mode for IJulia, but at least it's more flexible than having to locally fork IJulia (and hardcode your mode there).

Acmion commented 3 years ago

I'm also having issues with Base.active_repl.

It is unfortunate that certain code works in Julia when executed via the command line and that the same code does not work when executing from IJulia.

My specific use case is to change the active module of the REPL and thus execute code in other modules than Main.

EDIT: Changing the module, which was my primary use case, can be accomplished with: IJulia.set_current_module(MODULE).

xgdgsc commented 1 year ago

I' m thinking of using RemoteREPL.jl to connect to a runing vscode julia REPL process, to show Interact.jl WebIO plots inside jupyterlab. Does just setting Base.active_repl help with this use case?

MasonProtter commented 1 year ago

@xgdgsc an alternative to getting Base.active_repl set in IJulia, would be to get this PR merged in RemoteREPL.jl: https://github.com/c42f/RemoteREPL.jl/pull/42

I've been using this locally on my machine and it works well for me.