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

[Gary Byers]

On Fri, 10 Sep 2010, peter wrote:

> At 4:05 PM -0600 10/9/9, Gary Byers wrote:
> [...]
>
>>  (At the very least, any native development environment
>> would violate those guidelines - generating and loading code
>
> [...]
>
> Could we not just see the iOS on Touch devices as just deliver platforms for 
> apps that we write elsewhere?


Cross-compiling native lisp code is generally very different from
cross-compiling [Obj]C.  Lisp object (FASL) files tend to have
side-effects when loaded (that's the whole point ...).  Sometimes,
those side-effects are trivial (some piece of code or data is
associated with a global name (via DEFUN or DEFVAR), and that's not
tremendously different from what a .o file (produced by a C compiler)
contains.  (Part of the process of bootstrapping CCL involves building
a minimal heap image out of a set of FASL files, and the process by
which that happens isn't too different from the process by which a
linker makes an executable file out of a set of .o files.  There are
some fairly strict constraints on the code in the FASLs used to build
that image, and non-trivial side-effects in that code occur when the
image is loaded, not when it's built.  The process of building that
initial image can occur on a machine of a different architecture than
that which the image is intended to run on.)

Once you start talk talking about building more complex lisp systems
(and just about anything is more complex than that bootstrapping image),
the build process starts to involve more load-time side effects (the
order in which files are loaded and those side-effects occur starts
to matter) and it's very hard for me to believe that this can be done
non-natively.  I believe that you can compile an iOS FASL file on a Mac -
I spent a lot of the last few months doing similar things - but I think
that we're a long way from being able to meaningfully load that file
(or fully emulate the effects of loading that file) on anything but
the target architecture.

It's a little early to say how one would do development on an iDevice.
There are some resources that're clearly pretty limited (battery life,
screen real estate in most cases, keyboards in most cases, native text
editors, other things) on the device and others (including CPU power,
RAM, disk[-like] storage) that're more abundant than they were in what
most of us had on our desktops not too many years ago.  I imagine that
a desktop/ laptop machine (and something like SLIME/SWANK, Terje's
MCLIDE, some future component of the CCL IDE, something we aren't
thinking of yet) would be involved in the development process, but I
think that it's also likely that the development process will also
involve loading and compiling and executing and testing and compiling
and loading and debugging code on the device.  I actually think that's
desirable, but (for reasons stated above) I also think that it's unavoidable.




>
> The "Clozure CL64" API app weighs in at 47MB, Alex's XMLisp at 135MB. While 
> the dx86cl64 executable is 1/2MB.  So couldn't my small iOS app weigh in at 
> 1MB?

I don't think that I understand the question.  Disk footprint probably
matters some (as do some of the things that contribute to it), but I think
that it's possible to care both too much and too little about this.  Disk
footprint likely has something to do with memory utilization, but not all
memory's created equal.

~] gb at antinomial> cd /usr/local/src/ccl-dev/
[src/ccl-dev] gb at antinomial> size dx86cl64
__TEXT	__DATA	__OBJC	others	dec	hex
163840	8192	0	466944	638976	9c000

That's trying to say that that version of the CCL kernel contains about 164K
of code ("text", to unix), another 8K of initialized data, and ~470K bytes
of (mostly) debugging information.  It's trivial to strip that out; it's
useful to leave it in (even in the released product) because it makes it
easier to productively debug crashes remotely.  In that case, the benefit
of leaving the extra debugging info in the kernel seems to pretty clearly
outweigh the costs (disk storage and however long it takes to transfer that
extra ~470K around the net.)  Unless you're debugging the kernel with GDB,
that ~470K costs nothing: it's not ordinairly mapped into memory at runtime.

There are some similar issues with respect to the heap image: that
image contains several MB of ObjC metainformation that's needed at
compile time but isn't (or at least shouldn't be) needed at runtime,
several MB of source code location information, a few MB or more of
doc strings, a few MB of local variable info for backtrace ... very
little of this stuff is ever going to be resident in memory, though we
should probably offer options to strip it out of heap images to make
those images smaller (and, in some cases, to eliminate the cost of
generating that information.)

If at some point in the future you have a standalone CCL iOS application,
it is very likely that:

   - it'll be larger than a functionally equivalent ObjC app, largely because
     one of the principal libraries that it uses - CL itself - is statically
     linked into the application.

   - users and potential users will probably care more about functionality
     than about disk footprint in all but extreme cases.  ("Functionality"
     includes things like memory utilization and there's a correlation between
     disk footprint and memory utilization, but it's looser and more subtle
     than one might think.)

   - some of the Apple applications on my iPad contain TIFF files that seem
     to be over 1MB in size.  It fairly clearly isn't 10 (or 20) years
     ago anymore.



>
> I was hoping to develop with Clozure on steroids on a Mac with Cinema display 
> with copious resources, then deliver on any Mac, in particular on iPhone and 
> iPad in shrink-wrapped form.
> I.e. not develop on Touch platforms - I thought that was the philosophy, 
> consumer devices for consuming rather than creating content.
>
> Apple stress the need for apps to start and stop fast. I was surprised when 
> Willem Rein Oudshoorn wrote
>
> "1. Start Clozure CL64.app  [ 1.5-r13651  (DarwinX8664)! ]
> 2. Wait till it is started up"
>
> I find CCL fabulously fast to boot, even with Hemlock bloat on-board, and 
> take CCL as on a trajectory to be able to deliver Mac apps that qualify as 
> first class Cocoa citizens (i.e. just what Apple will love).

Most modern OSes use unused RAM as a disk cache; if an executable file is
in the disk cache (usually because it's been run before and nothing's LRUed
it out of that cache) it'll generally start up pretty quickly and if it's
not there (and especially if other things need to be paged out to make room
for it) it'll take noticably longer.  There isn't too much that I can think
of that an application can do to control this (besides "stay out of the way".)

>
> How delusional is any of this?

I only understood bits and pieces of it, to be honest.

> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>