compiler-research / xeus-cpp Goto Github PK

The XCppTests in jupyter_kernel_test fail to run on Windows.

Hello,
I'm trying to compile and install this kernel to built it with Jupyterlite.
Finally, I think the build is good, but there is an error when I try to integrate it inside Jupyterlite :

$ jupyter lite build --XeusAddon.prefix=/home/davy/miniforge3/envs/xeus-cpp
....
/home/davy/miniforge3/envs/xeus-cpp/lib/python3.12/site-packages/jupyterlite_xeus/add_on.py:56: UserWarning: kernel binaries not found for xcpp
  warnings.warn(f"kernel binaries not found for {path.name}")

Any idea on why this is not detecting xcpp bin which have been build and install ?

Any chance we can get it out of the box soon ?

We pass the install prefix as a compile time definition for the tag files, making relocation less easy (via the XCPP_TAGFILES_DIR compile time definition).

We should rather use xtl::prefix_path at runtime to prevent the need for binary relocation.

This issue also applies to xeus-cling.

Xeus-cling comprises a (fragile) implementation of auto-completion at https://github.com/jupyter-xeus/xeus-cling/blob/0.15.0/src/xinterpreter.cpp#L204-L238.

A more robust version should be implemented for xeus-cpp.

The pure C++ tests do work though, and integration tests seem to work fine on other platforms.

If you looking at the ci workflow at the moment it has the error on the job which does the coverage
Error: Codecov token not found. Please provide Codecov token with -t flag.

The report is generated but is unable to upload due to a missing token. This is not something I am able to fix. Can one of @alexander-penev @JohanMabille @vgvassilev @anutosh491 add the token where it is needed in the settings, and adjust the workflow accordingly to fix?

See https://docs.codecov.com/docs/adding-the-codecov-token for details about the token.

See https://github.com/compiler-research/xeus-cpp/actions/runs/9021481520/job/24788910894#step:13:33 for an example workflow showing the error.

When using the contextual help panel in e.g. JupyterLab, an inspect request is sent at every key stroke to populate the contextual help with the docstring of the latest item in the expression being typed.

This should presumably use the same approach as the implementation of the help magic ? in xeus-cling, although the retrieval of the type would be done differently.

Currently few tests from test_xcpp_kernel.py fail while running tests through the windows CI (hence the test are not enabled for the same).

Mentioning them here too

C:\Users\runneradmin\micromamba-root\envs\xeus-cpp\Lib\site-packages\jupyter_client\channels.py:233: Empty
=========================== short test summary info ===========================
FAILED test_xcpp_kernel.py::XCppTests::test_display_data - _queue.Empty
FAILED test_xcpp_kernel.py::XCppTests::test_execute_stderr - _queue.Empty
FAILED test_xcpp_kernel.py::XCppTests::test_execute_stdout - _queue.Empty
FAILED test_xcpp_kernel.py::XCppTests::test_kernel_info - _queue.Empty
============= 4 failed, 8 skipped, 20 rerun in 367.71s (0:06:07) ==============

The clangdev conda-forge recipe is a multi-output recipe, which creates the following packages:

clangdev
libclang-cpp13(13 is the soversion) and libclang-cpp (only symlinks)
libclang and libclang13 (13 is the soversion) and libclang (only symlinks)
clang-16 (16 is the current major version) and clang (symlinks)
clangxx
clang-format-16 (16 is the current major version) and clang-format (only symlinks)
clang-tools
python-clang

It seems that clangdev depends on clangxx etc, which are the onces having run exports, so we should probablly depend on clangxx instead of clangdev.

I think now, for a start we have some implementation for all request methods.
We also have tests for some of them and we can finish the others I guess

• execute_request
• inspect_request
• complete_request
• is_complete_request
• kernel_info_request
• shutdown_request

The various install docs seem to have contradictory instructions. In hopes of providing a fix, I tried installing things on my Mac (apple silicon)

I tried just installing directly

mamba create -n xeus-cpp
mamba activate xeus-cpp
mamba install -c conda-forge xeus-cpp

results in

The following package could not be installed
└─ xeus-cpp   does not exist (perhaps a typo or a missing channel).

so I tried from source (which is suggested as being required)

However I end up with a conflict between cxx-compiler and clangdev

ends with

└─ cxx-compiler   is uninstallable because there are no viable options

(followed by a bunch of version details).

Since it is mentioned as important, I have python 3.11.6.

Any other install recipes to try?

Xeus-cpp should be able to attach clang-repl and other plugins such as clad or cppyy. We should investigate and implement plugin-system which is friendly to package managers.

@SylvainCorlay, you had a concrete proposal for directory structure that we wanted to adopt. Could you spell it out here?

cc: @alexander-penev, @grimmmyshini

We should implement the printing of the last value. The corresponding code is currently commented here, because unlike cling, clang-repl's process_code does not return the counterpart of a cling Value, which should be the case.

xeus-cling supports quick inline help through the ? magics, similarly to IPython, rendering the help in the pager (in the classic notebook) or in an output cell.

The way this is done is by finding the corresponding the type and looking it up in the "tags file" that binds the type to a URL. A tags file for the standard library is included in xeus-cling, pointing to the corresponding URLs on cppreference.

We should add some developers' documentation on how to start development in the project locally. I believe a lot of the folks with clang-repl background will have trouble set up the infrastructure locally allowing them to add improvements.

We can invert the CI matrix to include only the different options and the steps can become the same. For reference see how's done in the vgvassilev/clad project.

Take what's done here: https://github.com/compiler-research/CppInterOp/tree/main/.github/workflows

The current requirement of xeus in CMakeLists.txt is 3.0.5. This should be upgraded ot the lates 3 version.

In Contributing.md file, under the general-guidelines section Project Jupyter Contributor Documentation is pointing to this link that shows 404 Not Found

• xeus-cpp version: 0.4.0
• Operating System: MacOS/arm64

Description

When we try to test code (via pytest) that throw exception, this test fail.
After that all other (no-skiped) tests also fails.

We expect this test not to fail, and even a little bit to interfere with the work of the following tests.

What I Did

class XCppTests(jupyter_kernel_test.KernelTests):
    # Exception throwing
    code_generate_error = 'throw std::runtime_error("Unknown exception");'

$ pytest .
====== test session starts =====
...
collected 12 items
test_xcpp_kernel.py ss.ssFFsssFF

We use xtl only for xtl::prefix_path. Let's drop this compile-time dependency.

The is_complete request is implemented in xeus-cling at https://github.com/jupyter-xeus/xeus-cling/blob/0.15.0/src/xinterpreter.cpp#L258-L282.

This is required for meaningful usage of xeus-cpp in a Jupyter console.

For this purpose, we would need a counterpart to cling's input validator.

What are the dependency or command lines to be written in linux to solve above issue.
I did all the steps as given in the README.md with the help of which I could locally run C++ in jupyter file but I am unable to run python code using %%python.

@SylvainCorlay @vgvassilev @JohanMabille pls help me with this issue

As denoted in this comment we should have a testing framework (at the xeus-cpp level or at the overall xeus-stack level) that would accept a kernel ( Maybe different xeus kernels and their different possible versions) and a demo notebook and return some jsons for confirming the expected outputs.

This would ensure consistency for the kernels over the long run.

Do we want to keep the xcpp kernel spec now that we have many xcppXX kernels? I find it redundant since it is always the same as one of the versioned language kernel.

Perhaps copy what's done here.