Is it possible to move away from V8 in favor of a liter dependency? Say, QuickJSR

[barracuda156]

@jtextor V8 is a very heavy dependency to build and it is broken for some platforms. Could we get rid of it? Possibly, replacing with QuickJSR, like rstan did?

[jtextor]

It's an interesting idea, but V8 is very fast and QuickJS seems to be quite a bit slower ... I don't know if that would be a bottleneck or not? Could be an interesting thing to test.

[barracuda156]

I cannot vouch personally for speed (since V8 is broken for the platform where I test), but given that rstan uses QuickJSR, and rstan is a very sophisticated and speed-wanting software, it should be pretty good.

QuickJSR itself builds quickly, and Stan models work fine. V8 – well, last time I tried to fix it, and went pretty far with that, it took multiple hours before failing on a wrong assembler :) Admittedly, my PowerPC is no TALOSII, but it is a very heavy dependency.

[barracuda156]

@jtextor Maybe you could make a branch with a switch to QuickJSR? That would fix dagitty without compromising it for those preferring V8.

[barracuda156]

@jtextor Any update on this?

[Lulliter]

I am experiencing an issue due to V8 dependency as well

> library(dagitty)
Error: package or namespace load failed for ‘dagitty’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library/V8/libs/V8.so':
  dlopen(/Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library/V8/libs/V8.so, 0x0006): symbol not found in flat namespace '__ZNSt3__122__libcpp_verbose_abortEPKcz'

Apparently the V8 package's shared object file (V8.so) is not linking correctly to the C++ standard library (libc++.1.dylib) on your macOS ARM64 system.

R version 4.4.2 (2024-10-31)
Platform: aarch64-apple-darwin20
Running under: macOS Ventura 13.0

[barracuda156]

@Lulliter While I do endorse moving away from V8 here, you could probably get V8 built from source, and if whatever its default V8 is fails to, then build it against a different version. As I recall, it is supposed to accept a wide range of V8 versions.

Does MacPorts R-V8 build for you by the way?

[Lulliter]

@barracuda156 I am not familiar with MacPorts, but I tried installing V8 from source, reinstalling command tools, etc. In the end, what solved the incompatibility was updating also my Mac OS. So now I can load V8 with

R version 4.4.2 (2024-10-31)
Platform: aarch64-apple-darwin20
Running under: macOS Sequoia 15.1.1

[barracuda156]

Apple messed up Xcode quite badly recently, and several times, so that some versions are incompatible with each other on the same system, could be due to that. Anyway, good that it works now.