Re: [Chicken-users] IPhone

[Nicholas \"Indy\" Ray]

I think these are all minor problems, if you write in a consless
style, you should be able to prevent most allocation, and as long as
you trigger GC's early you shouldn't have to worry about the memory
issue too much. eval is rarely used, and I think chicken already
supports a compile option to remove such. and as long as you're linked
libs aren't too large (chicken already supports static linking, and
the standard libs are pretty small). In all I think it'd be easier to
tweak chicken to suit you're needs then create you're own scheme -> C
compiler.

Indy

On Thu, Apr 9, 2009 at 10:46 PM, lowly coder
<address@hidden> wrote:
> I really appreciate this analysis.
>
> The points on
> (*) why GC can be bad
> (*) eval not allowed
> (*) why static linking can be problematic
> have been very insightful. (And led me to believe that I should either code
> in Objective C, or write my own scheme -> Objective C compiler).
>
> Thanks!
>
>
> On Thu, Apr 9, 2009 at 7:46 PM, Nicholas "Indy" Ray <address@hidden>
> wrote:
>>
>> On Thu, Apr 9, 2009 at 7:15 PM, lowly coder
>> <address@hidden> wrote:
>> > Wait ... the Apple Developer Agreement has strict requirements against
>> > GC?
>> > Where? I've never had a dev agreement say what technical things you can
>> > and
>> > can't do. Are they going to ban linked lists, maps, and my hand rolled
>> > memory allocator too?
>>
>> It's an embedded platform that they have strict control over, they can
>> disallow anything they want, and GC doesn't fit well within the
>> allocation profile of the phone, GC apps will likely cause the kernel
>> to kill it often, which is a crash to the user, too many apps do that
>> and users have bad perception of the phone as a whole.
>>
>> I don't know if the agreement is public but you can try this link:
>>
>> http://developer.apple.com/iphone/download.action?path=/iphone/iphone_sdk_for_iphone_os_2.2.1__9m2621a__final/iphone_sdk_agt_ea0495.pdf
>>
>> Looking through that I can't find anything that explicitly disallows
>> GC, but you should still watch out for you're allocations:
>>
>> http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/DevelopingSoftware/DevelopingSoftware.html#//apple_ref/doc/uid/TP40006556-CH5-SW12
>>
>> But going through the agreement another point to be brought up at
>> section 3.3.2 which disallows the use of the interpreter, so you will
>> probably want to disable eval, but that shouldn't be too difficult.
>>
>> > I tried building a basic Chicken 4 app on Mac OS X ... looks like the
>> > objc
>> > egg is not ported over yet. Anyone know what's holding it up?
>>
>> afaik, zbigniew mantains this, I figure he just hasn't gotten around
>> to porting it yet.
>>
>> > I was going to just have a gigantic statically linked app. Why not? The
>> > iPod
>> > Touch has HDs in the Gigs. It's not like people who want to be
>> > entertained
>> > will care. At worst, they may have to erase a trashy music video. :-)
>>
>> I agree that a statically linked app probably won't be a problem. But
>> keep in mind the size problem isn't in relation the HD space, but
>> rather in active memory, without any swap space on the IPhone you're
>> entire app and all statically linked libs will have to be in memory,
>> giving GC less room to work within.
>>
>>
>> Indy
>
>