[test additional commit] Adding OpenMP Kernels + explicitly load libomp.so

[Vipul-Cariappa]

No description provided.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 83.33333% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.94%. Comparing base (c357fd6) to head (42415e6).

Files with missing lines	Patch %	Lines
src/xinterpreter.cpp	83.33%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #432      +/-   ##
==========================================
- Coverage   81.94%   81.94%   -0.01%     
==========================================
  Files          21       21              
  Lines         853      864      +11     
  Branches       87       91       +4     
==========================================
+ Hits          699      708       +9     
- Misses        154      156       +2     

Files with missing lines	Coverage Δ
src/xinterpreter.cpp	90.00% <83.33%> (-0.57%)	⬇️

Files with missing lines	Coverage Δ
src/xinterpreter.cpp	90.00% <83.33%> (-0.57%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[anutosh491]

Hey @Vipul-Cariappa , thanks a lot for this !

I'll take out some time soon to go through this.

Initial thoughts

1. I tried the wasm use case back in November or so. And though we can build libomp.so using emscripten, it's just how Jupyterlite and xeus is framed using pthreads this might not work. Pretty sure I wrote about my analysis in more detail on discord

2. Something which looks concerning & I personally feel should be handled better is the amount of kernels. We already have 6 native kernels (3 C, 3 C++) and 6 wasm kernels (3 C, 3 C++)

Now for any specific use case like this if we have 6 more kernels coming in, that would be an insane amount of kernels to maintain. We already expect cuda, out-of-process, debugger enabled kernels to land ... and any other python-interop, clad etc kernels in future.

I think for a specific functionality use case, we should just present our best kernel forward. One with the latest C++ version.

I'm guessing @JohanMabille & @SylvainCorlay would also agree to the same ?!

[mcbarton]

@anutosh491 This PR is not one that is supposed to be merged in. It is just to test an additional commit on top of my existing PR #389 which had been open for a while now.

[Vipul-Cariappa]

@mcbarton why are the OSX tests failing? Doesn't it pass on your local machine?

[anutosh491]

those were just some thoughts ;)

[mcbarton]

@mcbarton why are the OSX tests failing? Doesn't it pass on your local machine?

No the test doesn't pass locally for me on osx.