Working on iOS port

[ProtonMail <mshm@protonmail.com>]

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.  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.  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:

- Write pari commands in a text input and run them.
- Have output and errors be appended to a text box.
- Periodically save output to a file as a backup.
- Allow the user to choose a custom stack size for gp_embedded_init.
- Experimental file system support.  You can do something like write(“my_file.txt”, “hello”) and that file will be created in the app’s file system.  I was working on implementing write first, but now that I have that working, read shouldn’t be much different.  The way it works now is I intercept a write and notify the app of the newly modified file so that it can copy it out of Emscripten’s in-memory file system to the app’s persistent file system.  Read would work similarly, but in reverse, supplying a file to the Emscripten file system when pari attempts to read it.
- I haven’t worked on input() yet, but since Emscripten handles input with a call to window.prompt, I could easily overwrite window.prompt with my own function to prompt the user for input.  It should not be too difficult to do.  I’ve thought about it and looked at it but haven’t done it yet ;)

However, there are some features that just flat-out do not work, like breakpoint and interrupting calculations with Ctrl-C.  I haven’t tested more than this, but I’m pretty sure some other low-level stuff also won’t work (like install, system, etc).

This email is already getting bogged down in details.  Really what I want is feedback from other pari devs.  Is this a good direction to go in with an iOS port?  Should I provide a demo to show how the app works and what it does?  I want to provide screenshots, but I’m unsure of how to post one through the mailing list.  Imgur?  I could also provide the code.  I plan on open sourcing it, and if the pari community is interested, hopefully passing ownership to the Pari project (don’t worry, I’d still be maintaining it though!)  The only issue is that I haven’t committed it to a git repo yet since the app was going through really rapid and drastic changes.  Now that I have something working, I could put it in a git repo somewhere (Github?) and post the link here.  It’s incredibly messy though, so I’ll clean it up a little before posting it.

Cheers!
Muhammad-Sharif Moustafa

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”

Basically I turned off the memory-init-file flag because the memory file wasn’t working well in JavaScriptCore.  Turning off the flag results in just one JavaScript file, gp-sta.js.