[Openmcl-devel] ClozureCL on iPhone

Wed Nov 2 12:12:01 PDT 2011

Yes, I'm aware that the simulator uses x86 code. I was thinking about running an x86 version of CCL there that could load, compile, and execute code as well as loading an iOS version of the Cocoa libraries. (Any problems creating those?) But if it enforces the restriction against executing out of writeable memory then that can't all work. If it DID work, then potentially you could construct and test an app there and only resort to using a real jail-broken iOS device for the final load, test, executable dump stage.

I hadn't considered doing slime-connected development directly on an iOS device, but that sounds like a good way to get started. For cocoa apps you'd still want to use Interface Builder on a mac and be able to build bundles and whatnot there, but there might be a way to put the development workflow together in an almost tolerable way. I'd want to think about that more. The goal, of course, is still to develop final apps that could be run on non-jail-broken devices.

So, is it actually possible today to run CCL on a jail-broken device and connect via slime on a mac? Anyone want to walk me through that process or point me to instructions somewhere? I'll go research jailbreaking my iPad to make sure I'm happy with that.

Paul

Sent from my iPad

On Nov 2, 2011, at 1:17 PM, "Bill St. Clair" <wws at clozure.com> wrote:

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