[Openmcl-devel] ClozureCL on iPhone

Bill St. Clair wws at clozure.com
Wed Nov 2 11:17:50 PDT 2011


That, of course, works, but so does regular Slime-connected development,
on a jail-broken development device. The simulator that ships with XCode
simulates the iPhone code compiled for x86. It does NOT emulate on
iPhone's ARM processor.

-Bill

On 11/02/11 13:57, Paul Krueger wrote:
> Bill,
> 
> 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.
> 
> Paul
> 
> Sent from my iPad
> 
> On Nov 2, 2011, at 11:22 AM, "Bill St. Clair" <wws at clozure.com>
> wrote:
> 
>> Paul,
>> 
>> 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.
>> 
>> -Bill
>> 
>> 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
>> manual.
>>>>> - 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
>> 
>> _______________________________________________ Openmcl-devel
>> mailing list Openmcl-devel at clozure.com 
>> http://clozure.com/mailman/listinfo/openmcl-devel




More information about the Openmcl-devel mailing list