[Openmcl-devel] ClozureCL on iPhone

Bill St. Clair wws at clozure.com
Wed Nov 2 09:22:26 PDT 2011


Good idea, but you missed the part where you can't run any newly-loaded
compiled code on an iOS device. You can load a fasl file into memory,
but you can't execute any of the newly-loaded code. Writeable memory
pages cannot be executable, unless you jailbreak the device. So in order
to do what you want, we'd need an Arm emulator running on the Mac, to
load the fasls and dump the resulting app. And that emulator wouldn't
have any of the iOS libraries, so it could dump code that calls the
libraries, but never actually call any of them.


On 11/02/11 09:38, Paul Krueger wrote:
> One of the things that I did when I created the app development tools
> in my contrib was to do the final build and dump of the application
> executable from within a separate instance of CCL. So the developer
> essentially directs that the app be created in one CCL instance, a
> separate instance is started up, and a stream is opened between them.
> Commands are passed to that second instance to direct that it load
> whatever is required for the app and then dump itself to a specified
> place (typically within an application package).
> What I had in the back of my mind when I did that is that eventually
> the separate CCL instance might be resident on an IOS platform. If it
> is capable of loading source from and dumping an app executable back
> to a connected Mac, then perhaps you could use this two-part system
> to create an executable IOS app package. There is a whole lot of
> hand-waving going on there I realize (including but not limited to
> remotely executing CCL on a tethered IOS platform and getting a
> stream to work between the two CCLs), but I still think there might
> be merit in something along those lines.
> The general idea is that you could develop and test an app on the mac
> and then deliver it on an IOS platform. Now to really test an IOS app
> on a mac you would want to use the IOS simulator that Apple provides,
> so you'd need to build first for that, run your test, and then build
> for the IOS. So we might need to figure out how to get CCL to run on
> the IOS simulator as well. Lots of details there too I imagine.
> I would be happy to look at adapting my tools to work with the
> secondary CCL running under IOS (and/or the IOS simulator) if such
> were easily available, but I agree there might be quite a bit of work
> to do to make this a reality. I'll guarantee that there are many
> other problems that I have yet to recognize. I use my iPad heavily on
> a daily basis, so I'm not anxious to jailbreak it in a way that
> causes any problems for normal Apple updates or other routine
> operations, but if I can do it in a relatively benign way, I'll give
> it a go.
> Paul
> On Nov 2, 2011, at 7:28 AM, Andrew Shalit wrote:
>> What you're asking for is a cross-compiler and cross-dumper.
>> When CCL is running on a Macintosh with an Intel processor, the
>> compiler produces code for the Macintosh and Intel processor.  You
>> want the compiler to have a special mode where it can create iOS
>> ARM code even though it is running on a Macintosh.
>> Furthermore, the process of creating a Lisp program almost always
>> involves the creation of initial datastructures, which then get
>> dumped out.  These initial datastructures are created by running
>> Lisp code.  So you'd want to be able to run Lisp code on the
>> Macintosh (or whatever) that would somehow create data structures
>> suitable for the iOS ARM.  That's just not the way most Lisps
>> (including CCL) work.
>> This is all technically possible, but it would be a lot of work.
>> On Nov 2, 2011, at 7:59 AM, Lynbech Christian wrote:
>>> I am getting a little confused.
>>> I understand that getting a full-fledged CCL, including compiler
>>> and REPL, up and running on an iDevice is pretty difficult.
>>> But if one looked at the (presumably) simpler problem of just
>>> getting a standlone application transferred to the device, ie one
>>> that was developed and dumped with CCL but without any dynamic
>>> development environment, would we still need heavy handed
>>> extensions of CCL (like compilling to C)?
>>> ------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
>>> ------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference
>>> - petonic at hal.com (Michael A. Petonic)
>> _______________________________________________ Openmcl-devel
>> mailing list Openmcl-devel at clozure.com 
>> http://clozure.com/mailman/listinfo/openmcl-devel
> _______________________________________________ Openmcl-devel mailing
> list Openmcl-devel at clozure.com 
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list