Item — HN Reader

Has anyone who has used this know if like any other Lisp, one can do live editing while the app is running on the actual mobile device?

For example: i have the app running and it fails, I go to emacs, fix the culprit code, compile and load, go back to app, it starts working again without having to re-run the app. If yes, that will be awesome. I hate the edit, compile, test cycle really.

7 comments

Embeddable Common-Lisp has now official Android support. It is also known to build for iPhone. It allows connecting via swank to the running application:

https://common-lisp.net/project/ecl

https://gitlab.common-lisp.net/ecl/ecl-android

Disclaimer: I'm the maintainer.

Edit: add main project website, clarify iPhone support status.

This is awesome. Is there an ecl-ios repo? I could not find it on gitlab.common-lisp.net. Sorry if it is there, as I only had a quick glance on the repo.

I don't own any ios device and support for it isn't merged in the repository yet. There are a few git repositories (a bit dated though), regarding building ECL with iPhone[1], and there is a project by Kris Kohlhepp[2] – I've wrote to him recently with the question about patches. If anyone has iOS and will submit a proper PR with some notes about building I'll gladly accept it :-)

[1] https://github.com/search?utf8=%E2%9C%93&q=ecl+iphone&type=R...

[2] https://chriskohlhepp.wordpress.com/embeddable-common-lisp-o...

BTW, ECL has also (untested, but integrated) ports for NaCL and pNaCL, which should run cross-platform.

I did not use them, but look at mocl[1] and Lispworks[2] for Mobile.

[1] https://wukix.com/mocl

[2] http://www.lispworks.com/products/lw4mr.html

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!!!

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.

There is work on-going to get ClojureSCript working with React Native. The tooling is a pain-point right now, but it's at least at proof-of-concept stage.

http://cljsrn.org/ is generally up-to-date with the state of the art in CLJS+RN.

You can add a TCP based REPL to any LambdaNative app by inclusion of a single module. This allows you to connect through emacs and run/alter code on the live system, potentially directly on the mobile device (although it would make more sense to do this sort of iterative development on a build for the localhost). The setup is described here:

https://github.com/part-cw/lambdanative/wiki/Using-Emacs

Check out our LNhealth repository (from the LambdaNative team). https://github.com/part-cw/LNhealth

The LNhealth app is similar to your desired workflow. It runs scripts written in Scheme that define the pages in the app. When developing for Android I can just push a change to the script (using the Android Debug Bridge - adb) and do not need to recompile the app itself. It makes for a much faster development cycle.

ClojureScript has a great story for hot reload with React Native via Leiningen + Figwheel[1] or Boot[2].

[1]: https://github.com/decker405/figwheel-react-native [2]: https://github.com/mjmeintjes/boot-react-native

No idea but coding against unit tests, rather than testing every change on a running app, should help avoid that frustration.

While I do not deny the value of automated tests, the ability to do incremental, live updates when rapidly prototyping is indispensable.

Unit tests doesn't help when exploring the behavior of the app. Working in a live environment is wonderful for debugging.