C stack usage problem with Jupyter/IHaskell on mac
JulianZhang opened this issue · comments
I install HaskellR as flowing guide
http://tweag.github.io/HaskellR/docs/build-and-install.html
But if I run any R command such as [r|1+1|], the will be an error as "C stack usage xxx is too close to the limit".
I think the error is same as blow, But I didn't know how to fix it on Ihaskell case
Could you tell us more about your platform? OS X? Linux? Windows?
Hi, my platform is OS X.
Hi mboes, I think the problem is the same with http://tweag.github.io/HaskellR/docs/faq.html
But I didn't know how to pass the -fno-ghci-sandbox to notebook
This may well be an upstream feature request for the IHaskell project: be able to pass arbitrary GHC options to the Jupyter haskell kernel. I don't know if that's possible. If it is then would love to have an augmented FAQ entry regarding this. :)
Does typing :set -fno-ghci-sandbox in the first cell in a notebook work? I'm not sure that it would, since it's possible that this option only works if it's set before launching GHCi, rather than within a session.
Yes, it works, thank you. And I will raise a question on IHASKELL, to find a way to change the system setting.
Hi mboes, maybe you can add it to FAQ, if want fix it by default, just add ":set -fno-ghci-sandbox" to ~/ihaskell/rc.hs (create it if didn't exist)
I am getting this error when building a library on macOS which depends on inline-r, failing at the module that mostly using R. Is there an equivalent to -fno-ghci-sandbox without ghci?
The closest equivalent is to run event loop and R evaluations in the main thread (Thread1). You can achieve that by making something like:
forever $ join $ atomically $ readTQueue input
And all other threads will send computations to that input Queue.
It looks rather pessimistic from the performance view point, so other possibilities are to run forkOn 0 and pass a flag that binds HECs to the OS threads.
If you have a minimal example can you share that one, I have a system where I can test and fix the issue now.
I should mention that it's when compiling a program, not running.
Oh.. that's pretty bad. I'll think what can we do around that.
Oh.. that's pretty bad. I'll think what can we do around that.
Anything we could possibly do? I'm stumped.
What could be causing this issue when building (with Nix) on macOS only? Does haskell-r do anything with ghci post processing the library and during the building step of each individual hs file?
Exact location:
Preprocessing library for differential-0.1.2.1..
Building library for differential-0.1.2.1..
[1 of 5] Compiling Types ( src/Types.hs, dist/build/Types.o )
[2 of 5] Compiling Plot ( src/Plot.hs, dist/build/Plot.o )
Error: C stack usage 17587453424728 is too close to the limit
Error: C stack usage 17587453424776 is too close to the limit
Error: C stack usage 17587453424312 is too close to the limit
Fatal error: unable to initialize the JIT
We perform hacks to run in single treaded mode even during compilation, but it seems that on MacOS we need to be running in the main thread. And I'm actually not sure how to achieve that in a proper way.
Fortunately I have an environment where I can test that case if I have a nice reproducer.
If it is only used for parsing/lexing, perhaps it would be simpler to run R as a separate process during compilation.
I was thinking about running our code in separate process, but using R directly may actually work.