[Openmcl-devel] ClozureCL on iPhone
Bill St. Clair
wws at clozure.com
Mon Oct 31 08:44:13 PDT 2011
I wrote this while Andrew was writing his response, so I've repeated
some of what he said.
Gary will likely explain the details better, but my understanding is
that the kernel of the problem is that an iOS app memory page cannot be
both writable and executable. Hence, CCL's compiler can never work on an
unjailbroken iOS device. It could write code, but could never execute
it. Hence, compiled code would have to be cross-compiled in CCL on your
Mac, then signed and loaded into the iOS device. Further live
development would need to generate only evaluated functions.
This is certainly doable, but requires the technology to link
cross-compiled fasl files into static iOS libraries, runtime code to
link those to the heap, and a full evaluator. CCL's current EVAL
implementation handles a few simple cases, and then hands off to the
compiler anything complicated.
You'd probably do development via a Swank server in the running iOS
image, and slime-eval-xxx would make code changes live. Occasionally,
you'd recompile the whole thing to make the working code faster, then
continue with evaluated additions/modifications. A listener on the iOS
device would be possible, but no fun to use on anything but an iPad with
an external keyboard.
-Bill
On 10/31/11 11:36, Andrew Shalit wrote:
> As far as I understand (which may be entirely wrong):
>
> * Gambit Scheme compiles to C, and the C is then compiled by Xcode and loaded onto the iPhone the way compiled C is normally loaded onto the iPhone. There is an interpreter running on the iPhone, but the interactive development capabilities of Gambit Scheme are quite limited.
>
> * iScheme is an interpreter.
>
> * Codify lets you write Lua apps on your iPad but those apps can never leave your personal iPad. What I read implied that you can't even get the sources off your iPad very easily.
>
> There are a few ways that I could see CCL running iOS
>
> 1. We could take the Gambit Scheme approach and compile to C. You give up most interactive development.
>
> 2. We could write a full Common Lisp interpreter. I don't know whether anyone has ever actually done that. It's pretty easy to call 'compile' and modern Common Lisp has lots of special forms. But it could certainly be done.
>
> 3. We could write a cross-compiler which runs on the Mac, and sends iOS code across the Xcode wire to the device. This would be a big project.
>
> 4. We could write a CCL development environment that runs on jailbroken iOS devices and supports delivery on non-jailbroken devices. This is legal, but it's not reliable and Apple would likely frown on it.
>
> I believe that any of these are possible, but none of them are things that we want to do on our own time. We'd be happy to talk to anyone who wanted to fund this work. We'd also like to be able to use CCL to write iOS apps.
>
> Andrew
>
> On Oct 31, 2011, at 10:55 AM, Jianshi Huang wrote:
>
>> On Mon, Oct 31, 2011 at 11:12 PM, Andrew Shalit <alms at clozure.com> wrote:
>>> Gary may chime with additional details, but the short story is that the code-signing requirements of iOS make it pretty much impossible to get CCL running on standard-issue devices. It's possible to get unsigned code to run on jailbroken devices, of course, but engaging in that sort of cat-and-mouse with Apple doesn't seem like a productive use of our time.
>>>
>>> This is unfortunate, because we do iOS development and we'd love to do it with Lisp, but at this point we can't.
>>>
>>
>> I see.
>>
>> But it's still nice to know there's a potential version there. Given
>> the facts that there're two schemes (Gambit REPL and iScheme) and the
>> recent lua based Codify programming environment already approved in
>> the app store, possibly under the category of education software, it
>> might be possible to have one for CCL.
>>
>> Cheers,
>> Jianshi
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
More information about the Openmcl-devel
mailing list