[Openmcl-devel] Apple OKs other dev tools for iOS

Gary Byers gb at clozure.com
Thu Sep 9 18:51:56 PDT 2010

On Thu, 9 Sep 2010, Brent Fulgham wrote:

> Dear Gary,
> On Thu, Sep 9, 2010 at 3:05 PM, Gary Byers <gb at clozure.com> wrote:
>> I haven't worked on this for a few weeks, but here's an actual, unretouched
>> result of copying and pasting between two Emacs buffers.  (Honest!)  Please
>> forget that you ever saw it:

Apparently, complete with a cut-and-paste mishap that lost a newline somewhere ...

>> magical:~/ccl-dev mobile$ ./darmcl Welcome to Clozure Common Lisp Version
>> 1.6-dev-r14170MS-trunk  (DarwinARM32)!
>> ? (machine-type)
>> "iPad1,1"
>> ?
> Share!  Share share share!
> -Brent

I think that all of the sources are in the trunk svn tree; you can cross-compile
the kernel on a Mac by doing 'make' from the lisp-kernel/darwinarm directory,
and (assuming that you have whatever version of XCode/iPhone SDK I have ...)
that should produce a kernel binary.  If you transfer that binary to an iDevice
and digitally sign it - and can do those steps in that order - and can then run
it, it should start up and complain that it can't find a heap image.

AFAIK, all of the sources needed to produce a heap image (and a set of interfaces
for the C-library stuff for iOS 3.2) are also in svn.  A heap image isn't in SVN;
the short version of the reason for that is even on a device which has relaxed
code-signing restrictions iOS implements some unusual memory-protection policies
and some things in CCL expect to be able to do some things that those policies
don't allow.  I worked around that issue in a not-too-satisfactory way; when I
get time to work on this again, I'll try to use a better workaround and will
likely check in binaries when that happens.

In the big picture, there are still a lot of open issues and there's still a
lot of work to be done, so it was probably premature of me to have included
that low-rent screenshot in my earlier message (and it probably isn't a bad
idea to forget that I did so ...).  The working model of what we can/can't
expect to do with "CCL on iOS" has changed a bit over the last month or so,
changed some more with today's announcement, and may change in the future;
at this point, it's hard to say much more than "some necessary technology
exists in an almost-usable form"; we'd obviously like to be able to say more
than that, and will when we can.

More information about the Openmcl-devel mailing list