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.