Bill Allombert on Mon, 18 Dec 2017 17:39:09 +0100


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Working on iOS port


On Sun, Dec 17, 2017 at 08:15:46PM -0500, ProtonMail wrote:
> Hi all,
> 
> I’m Sharif!  I’m new to the mailing list and pari-dev scene but I’ve
> used Pari/GP before in my undergraduate research.  I’ve been working
> for the past two weeks to port Pari/GP to iOS (iPhone, iPod, and
> iPad).  What I’ve found is that it's really hard compiling Pari/GP for
> iOS, especially since I don’t have that much experience working with
> large C projects nor Xcode build tools.

Hi Sharif!

Thanks for reporting about this!

There is quite old link about this topic:
<http://sagemath.blogspot.fr/2010/06/pari-on-ipad-component-of-sage.html>

> I’ve built apps before and
> have written a good amount of C, but nothing like this.  So I decided
> to go the Emscripten route.  I built pari using the Emscripten build
> commands found at
> https://pari.math.u-bordeaux.fr/archives/pari-dev-1610/msg00015.html
> and ran it on iOS using JavaScriptCore, iOS’s built-in JavaScript
> engine.  It works surprisingly well.

Indeed! Do you know whether JavaScriptCore support WebAssembly ?

How does your app compares to
<https://pari.math.u-bordeaux.fr/gp.html> ?

> JavaScriptCore allows data to
> flow into and out of the JS virtual machine, which allows me to “hide”
> the JavaScript stuff behind a native UI and native functions (like
> file system operations).  I’ve essentially bridged a text area to
> Emscripten’s stdout/stderr functions and a text input to gp_embedded.
> Here are the features directly related to Pari/GP that I’ve developed
> so far:

How do you deal with the asynchronous nature of javascript ?

> P.S. I built Pari/GP with a slightly modified build command than the
> one in the original post linked above:
> 
> make -C Oemscripten-javascript "CC_FLAVOR= -s ALLOW_MEMORY_GROWTH=1 -s PRECISE_I64_MATH=1 -s EXPORTED_FUNCTIONS=[\'_main\',\'_gp_embedded\',\'_gp_embedded_init\'] --memory-init-file 0”

I found that -s ALLOW_MEMORY_GROWTH=1 was slowing done GP too much, so now
I use -s TOTAL_MEMORY=1073741824 which limits the memory to 1GB.
WebAssembly seems not to have this problem.

How do you handle the optional packages ? (galdata, elldata, etc.)

Cheers,
Bill.