[Openmcl-devel] ClozureCL on iPhone
plkrueger at comcast.net
Wed Nov 2 10:57:00 PDT 2011
My assumption was that an iOS-resident CCL (on a jail-broken device) could load source files (not fasl files necessarily) that it could compile and run there and then just dump the resulting core image executable back to the mac where it is incorporated into the iOS app bundle. I understand that this new app can't itself then load and execute any new code when run on a non-jail-broken device. This of course implies that the ARM port of CCL is capable of compiling for an ARM target, but I assumed that was probably necessary just to get it running in the first place. So instead of requiring an ARM emulator on the mac I want to use a jail-broken iOS device running CCL to compile and dump an executable image that incorporates everything the app might need. There is a lot I don't know about what an iOS executable needs to look like, so this still might not be feasible, but at least I hope this clears up my intent.
Thinking more about running on the iOS simulator I realize that you likely couldn't jail-break it, so unless it fails to enforce the executable memory constraint that exists for iOS devices you are entirely correct that my suggestion for running there is not feasible in any easy manner. I guess all debugging would have to be done directly on a real jail-broken device.
Sent from my iPad
On Nov 2, 2011, at 11:22 AM, "Bill St. Clair" <wws at clozure.com> wrote:
> 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.
>> 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
>> _______________________________________________ Openmcl-devel mailing
>> list Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel