Handle undo for xeus-cpp/xeus-cpp-lite

[anutosh491]

Clang-repl provides an undo option which I guess should help us get past redefinition issues .
https://llvm.org/devmtg/2022-11/slides/Lightning6-RecoveringFromErrorsInClang-ReplAndCodeUndo.pdf

For example

anutosh491@Anutoshs-MacBook-Air bin % ./clang-repl
clang-repl> extern "C" int printf(const char*, ...);
clang-repl> int x = 50;
clang-repl> %undo
clang-repl> const char* x = "Hello World";
clang-repl> auto r = printf("%s\n", x);
Hello World

Without the undo you would get

clang-repl> int y = 50;
clang-repl> const char* y = "Hello World";
In file included from <<< inputs >>>:1:
input_line_6:1:13: error: redefinition of 'y' with a different type: 'const char *' vs 'int'
    1 | const char* y = "Hello World";
      |             ^
input_line_5:1:5: note: previous definition is here
    1 | int y = 50;
      |     ^
error: Parsing failed.

When the same is attempted through xeus-cpp, it is being considered as a magic but probably should be looked at from a simple execute_request point of view .

[anutosh491]

So yeah two tasks here

• fix undo for xeus-cpp
• fix undo for xeus-cpp-lite. Probably this might be more involved all calls for implementing this I'g guess. ([Clang-repl] Implementation for removeModule for wasm use case llvm/llvm-project#131558)

But yeah for starters, we just need to make sure these are not being considered as magics.

[davy39]

Hi,

I was wondering if there are any plans to allow redefinitions of variables and functions.

This feature would be ideal for using xeus-cpp as a coding sandbox. Currently, we need to restart the kernel every time we correct or update a function, which makes the iterative development process quite impossible.

I've see that a similar issue has been discussed for xeus-cling (jupyter-xeus/xeus-cling#91), what about xeus-cpp and its wasm build ?

[anutosh491]

Hi @davy39 ,

1. we have a PR doing this for xeus-cpp 's native kernel [wip] Added undo operation for xeus-cpp #293 (probably needs to be looked into as to what remains)

2. And we won't be having undo untill emscripten fixes the buggy dlclose implementation they have
   [BUG] Dlclose behaves differently as compared to native counterpart emscripten-core/emscripten#23939 .The maintainers there say that they get few use cases for dlclose and few bugs are reported so they don't have enough motivation for fixing it :\

[davy39]

Thanks for the detailed explanation. That's unfortunate, as the inability to redefine functions is a significant blocker for using xeus-cpp in an interactive sandbox environment.

While I'm not an expert on the kernel's internals, I was wondering if a different approach could work around the dlclose issue. Would it be feasible to implement an option where the kernel resets its state before executing a cell?

We'll lose the ability to split code between multiple cells, but maybe could achieve the goal of redefinition without needing to unload a specific previous code.