Item — HN Reader

I have tried both, but then do not offer the live interactivity that is possible when running off a desktop Lisp implementation. I guess this is so because we are not running a lisp image on the mobile device.

I just now prototype any mobile app using LW CAPI and then port it to the actual platform!!!

2 comments

Not actually true. I have a simple puzzle game running in iOS with mocl. Lisp does the Model+Controller part and the View is in ObjectiveC. Once the game is running I can change states like level-up/down, etc. and the changes are reflected in real-time. I cannot change functions like in a true CL environment on the desktop, but I can definetly change global things to see if e.g. my flow works...

Yes, you are right. I was not explicit in that I meant while mocl does offer a run time repl, it is not the same as a true CL desktop environment.

Thanks for pointing my mistake.

LispWorks' iOS mobile runtime can be used for interactive development. I use SLIME to develop with it myself.

Vow, I did not know that. I had tested with beta ios runtimes, then it was not possible.

So now you connect the iOS device, change code in slime, recompile and you can see live updates on the device. Is that what you mean by using slime to develop mobile apps using LW mobile?

During the beta days, one would generate a static lib, that would then get copied to Xcode project. I would assume all this is taken care of now automatically with incremental development possible.

Can you point to any documentation for Lispworks mobile with these details? Sorry I could not find any on their website.

You still deliver the mobile runtime as a static library, but the compiled library contains the entire LispWorks runtime minus the native code compiler (which is a constraint of the lack of executable memory on iOS). The runtime contains a byte-compiler however, so the runtime is still available intact in fairly complete form. You just need to make sure that CLOS and everything you care about for interactive development is kept during delivery (see the Delivery guide for details). How you deal with the lack of compile-file is up to you, (you can easily just treat it as a no-op, or a loader) but I personally installed my own function which remotely invokes the cross compiler to compile new ARM64 FASL and then save the results in a local directory on the iOS device. It will treat the code like any interpreted code, but it works great for development.