hoc-devel — Developer discussion about HOC

Re: [hoc-devel] withAutoreleasePool in finalizers

[Gustav M. <grd...@gm...>]

> I have verified that finalisers are run in lightweight ("unbound") threads,
> so I am now pretty convinced that my theory is right.

Excellent.

> I like your patch. Do you want commit access?

Sure, that would be most convenient for the future.

!g

Re: [hoc-devel] withAutoreleasePool in finalizers

[Wolfgang T. <wol...@gm...>]

On Sep 8, 2008, at 11:48 AM, Gustav Munkby wrote:

> Actually, that does not seem to be a major problem, since we can
> just reuse the functions already declared in MemoryManagement.h.
> See the attached patch for a first go at this.

Good. I had forgotten about them.

I have verified that finalisers are run in lightweight ("unbound")  
threads, so I am now pretty convinced that my theory is right.
I like your patch. Do you want commit access?

Cheers,

Wolfgang

Re: [hoc-devel] withAutoreleasePool in finalizers

[Gustav M. <grd...@gm...>]

>> Is this the right way to fix this problem?
>
> I think it's *almost* the right way.
> More importantly, in this case, I think that the autorelease pools
> have to be created and destroyed in HOC_cbits/MemoryManagement.m
> rather than on the Haskell side.
> I still have to double-check this, but I seem to remember that GHC
> finalisers are run as lightweight threads by GHC, which means that we
> get no guarantee on which of the GHC runtime system's worker OS
> threads gets to execute each timeslice of the finaliser; it is
> therefore theoretically possible that the pool gets installed in one
> OS thread, but the actual dealloc executes in another, and the pool
> dealloc in yet another OS thread (which might have a *different* pool
> in place, causing lots of confusion). Not likely, but I am kind of
> afraid of it.

If this is the case, it would explain the behavior that I'm seeing, but
with my limited understanding of how the GHC internals work, there
could be a lot of other plausible explanations as well. =)

>> I tried wrapping the finalizers in
>> withAutoreleasePool which removed the
>> messages, but resulted in Yi crashing after
>> some time when an autoreleasepool is
>> deallocated twice. I can reproduce the
>> error, but not predictably.
>
> I think your attempt of wrapping the entire finaliser might have
> caused the time window for this problem to be longer, and therefore
> just made the crashes more likely than if you just wrap the actual
> dealloc. So we'll probably have to do it the hard way (we can't use
> *real* objective C if we want to be able to use GHCi, so we have to
> send all the messages "by hand" from C).

Actually, that does not seem to be a major problem, since we can
just reuse the functions already declared in MemoryManagement.h.
See the attached patch for a first go at this.

!g

Re: [hoc-devel] withAutoreleasePool in finalizers

[Wolfgang T. <wol...@gm...>]

First of all, it's great to see this list really coming to life :-).

On Aug 25, 2008, at 5:29 PM, Gustav Munkby wrote:

> I do not understand why this works, but
> this _is_ in the "Arcane Magic" section
> of HOC, so I guess I should not be too
> surprised. =)
>

I think the original problem is that there was not necessarily an  
autorelease pool available for use by an object's dealloc method, so  
wrapping the calls to dealloc and release should be the right thing to  
do.

> Is this the right way to fix this problem?

I think it's *almost* the right way.
More importantly, in this case, I think that the autorelease pools  
have to be created and destroyed in HOC_cbits/MemoryManagement.m  
rather than on the Haskell side.
I still have to double-check this, but I seem to remember that GHC  
finalisers are run as lightweight threads by GHC, which means that we  
get no guarantee on which of the GHC runtime system's worker OS  
threads gets to execute each timeslice of the finaliser; it is  
therefore theoretically possible that the pool gets installed in one  
OS thread, but the actual dealloc executes in another, and the pool  
dealloc in yet another OS thread (which might have a *different* pool  
in place, causing lots of confusion). Not likely, but I am kind of  
afraid of it.

> I tried wrapping the finalizers in
> withAutoreleasePool which removed the
> messages, but resulted in Yi crashing after
> some time when an autoreleasepool is
> deallocated twice. I can reproduce the
> error, but not predictably.

I think your attempt of wrapping the entire finaliser might have  
caused the time window for this problem to be longer, and therefore  
just made the crashes more likely than if you just wrap the actual  
dealloc. So we'll probably have to do it the hard way (we can't use  
*real* objective C if we want to be able to use GHCi, so we have to  
send all the messages "by hand" from C).

Cheers,

Wolfgang

Re: [hoc-devel] Is this list dead?

[Daniel R. <da...@ph...>]

On Aug 27, 2008, at 2:02 PM, André Pang wrote:

>  I have a small hatred of the latter.

you too huh?

-- 
Daniel

Re: [hoc-devel] Is this list dead?

[André P. <oz...@al...>]

On 18/08/2008, at 4:45 AM, Daniel Rogers wrote:

> - I'm unfamiliar with the cabal build system so I haven't touched  
> that stuff at all.  Are there plans to maintain two build systems  
> indefinitely?

The last time I checked HOC's Cabal build system, it seemed to work  
OK.  I'd probably prefer to go with the Haskell cultural standard  
(i.e. Cabal) and ditch autogoats altogether; I have a small hatred of  
the latter.  As long as the Cabal build system works, I have no  
problem at all with autofoo being ripped out.


-- 
% Andre Pang : trust.in.love.to.save  <http://www.algorithm.com.au/>

Re: [hoc-devel] withAutoreleasePool in finalizers

[Daniel R. <da...@ph...>]

On Aug 26, 2008, at 5:36 AM, Gustav Munkby wrote:

> The issue is that the finalizers are being executed in their own  
> thread,
> and Cocoa needs autorelease pools to be established in each thread.
> The finalizers are not executed after the application finishes, but  
> rather
> during Haskell garbage collection.

Ah.  I hadn't realized there was a separate system thread for garbage  
collection (I thought it was only a lightweight thread).  That's what  
I get for being new to HOC...

> That is a completely different can-of-worms, which would indeed  
> solve this
> issue. However, having both Haskell and Objective-C run their own  
> garbage
> collectors would supposedly require even more "Arcane Magic".

Indeed.  Though from what I've been able to gather, it should be  
possible.  I went ahead and applied your patch.  Even if there was a  
way to install an autorelease pool in the garbage collector thread,  
it's probably not what I want, since the garbage collector thread  
never exits.

-- 
Daniel

Re: [hoc-devel] withAutoreleasePool in finalizers

[Gustav M. <grd...@gm...>]

On Mon, Aug 25, 2008 at 6:22 PM, Daniel Rogers <da...@ph...> wrote:
>
> On Aug 25, 2008, at 8:29 AM, Gustav Munkby wrote:
>
>> I'm implementing a HOC/Cocoa frontend for
>> the Yi editor, and so far it works really well.
>>
>> I was puzzled about messages concerning
>> autoreleasing without a pool in place. After
>> some digging I have concluded that the
>> problem was that there was no autorelease
>> pool in place while finalizers were executed.
>
> Hmm, there should always be an autorelease pool in place.  If you're not
> using one of apples built in event loops, you should allocate/deallocate an
> autorelease pool in your main method.  That being said, not having finalizer
> autoreleased objects actually release until the program exits is probably
> unacceptable.

For the main application there is one main autorelease pool available during
the scope of the whole program, and then the run-loop creates a new pool
every iteration (according to the documentation).

> hmm, are these finalizers being run after the main method exits?  If so,
> it's actually safe to ignore those warnings.

The issue is that the finalizers are being executed in their own thread,
and Cocoa needs autorelease pools to be established in each thread.
The finalizers are not executed after the application finishes, but rather
during Haskell garbage collection.

>> I tried wrapping the finalizers in
>> withAutoreleasePool which removed the
>> messages, but resulted in Yi crashing after
>> some time when an autoreleasepool is
>> deallocated twice. I can reproduce the
>> error, but not predictably.
>
> I'd really like to understand this error.   It would go a long way toward
> understanding if this is the "right way."  As far as I can tell, that should
> work.

Yes, that seems reasonable. However, I cannot say that I exactly
understand the interaction between Haskell and Objective-C in
terms of memory management.

>> I then tried wrapping only the actual calls
>> to release/dealloc in the finalizer, and with
>> quite some testing I have not been able
>> to reproduce the above failure.
>
> While I don't understand why wrapping the finalizers didn't work, and that
> bugs me, this is more or less how you are supposed to use autorelease pools.
>
>> I do not understand why this works, but
>> this _is_ in the "Arcane Magic" section
>> of HOC, so I guess I should not be too
>> surprised. =)
>
> Autorelease pools work by telling the runtime "I no longer need this object,
> but I'm pretty sure someone else is going to want it, so I'll just put a
> message in the pool, and go ahead an deallocate the object when the pool is
> released."  It's essentially a delayed release.  It's good practice to
> sprinkle your code with new autorelease pools whenever you're allocating
> then deallocating a large number of objects so that stuff is actually
> released and the memory is freed when you exit that section.  Otherwise you
> have to rely on the top level autorelease which is probably allocated in (or
> close too) your main method.

This is a good description of autorelease pools. The one thing left out that is
relevant for this discussion is that there is a stack of autorelease pools per
thread, and outside the main thread you are not only encouraged, but even
required to set up an autorelease pool.

>> Is this the right way to fix this problem?
>
> Arguably, the right way is to side step the issue entirely and use garbage
> collected interfaces.  Otherwise yes, (other than not understanding why
> wrapping the entire finalizer didn't work).

That is a completely different can-of-worms, which would indeed solve this
issue. However, having both Haskell and Objective-C run their own garbage
collectors would supposedly require even more "Arcane Magic".

> Also, I don't believe dealloc is supposed to require an autorelease pool.
>  Though someone could always override dealloc and call autorelease and
> objective-c expects there to always be an autorelease pool available.

I'm quite sure that the normal release message is also not using any pools.
>From the looks of the messages produced by Yi, an NSView autoreleases
its child views upon receiving a dealloc message.

!g

Re: [hoc-devel] withAutoreleasePool in finalizers

[Daniel R. <da...@ph...>]

On Aug 25, 2008, at 8:29 AM, Gustav Munkby wrote:

> I'm implementing a HOC/Cocoa frontend for
> the Yi editor, and so far it works really well.
>
> I was puzzled about messages concerning
> autoreleasing without a pool in place. After
> some digging I have concluded that the
> problem was that there was no autorelease
> pool in place while finalizers were executed.

Hmm, there should always be an autorelease pool in place.  If you're  
not using one of apples built in event loops, you should allocate/ 
deallocate an autorelease pool in your main method.  That being said,  
not having finalizer autoreleased objects actually release until the  
program exits is probably unacceptable.

hmm, are these finalizers being run after the main method exits?  If  
so, it's actually safe to ignore those warnings.

> I tried wrapping the finalizers in
> withAutoreleasePool which removed the
> messages, but resulted in Yi crashing after
> some time when an autoreleasepool is
> deallocated twice. I can reproduce the
> error, but not predictably.

I'd really like to understand this error.   It would go a long way  
toward understanding if this is the "right way."  As far as I can  
tell, that should work.


> I then tried wrapping only the actual calls
> to release/dealloc in the finalizer, and with
> quite some testing I have not been able
> to reproduce the above failure.

While I don't understand why wrapping the finalizers didn't work, and  
that bugs me, this is more or less how you are supposed to use  
autorelease pools.

> I do not understand why this works, but
> this _is_ in the "Arcane Magic" section
> of HOC, so I guess I should not be too
> surprised. =)

Autorelease pools work by telling the runtime "I no longer need this  
object, but I'm pretty sure someone else is going to want it, so I'll  
just put a message in the pool, and go ahead an deallocate the object  
when the pool is released."  It's essentially a delayed release.  It's  
good practice to sprinkle your code with new autorelease pools  
whenever you're allocating then deallocating a large number of objects  
so that stuff is actually released and the memory is freed when you  
exit that section.  Otherwise you have to rely on the top level  
autorelease which is probably allocated in (or close too) your main  
method.

> Is this the right way to fix this problem?

Arguably, the right way is to side step the issue entirely and use  
garbage collected interfaces.  Otherwise yes, (other than not  
understanding why wrapping the entire finalizer didn't work).

Also, I don't believe dealloc is supposed to require an autorelease  
pool.  Though someone could always override dealloc and call  
autorelease and objective-c expects there to always be an autorelease  
pool available.

-- 
Daniel

[hoc-devel] withAutoreleasePool in finalizers

[Gustav M. <grd...@gm...>]

I'm implementing a HOC/Cocoa frontend for
the Yi editor, and so far it works really well.

I was puzzled about messages concerning
autoreleasing without a pool in place. After
some digging I have concluded that the
problem was that there was no autorelease
pool in place while finalizers were executed.

I tried wrapping the finalizers in
withAutoreleasePool which removed the
messages, but resulted in Yi crashing after
some time when an autoreleasepool is
deallocated twice. I can reproduce the
error, but not predictably.

I then tried wrapping only the actual calls
to release/dealloc in the finalizer, and with
quite some testing I have not been able
to reproduce the above failure.

I do not understand why this works, but
this _is_ in the "Arcane Magic" section
of HOC, so I guess I should not be too
surprised. =)

Is this the right way to fix this problem?

See attached patch for changes.

!g

[hoc-devel] TH debugging

[Daniel R. <da...@ph...>]

Greetings,

I thought I could write a cleaner version of expandSynonyms.  Then I  
discovered writing and verifying TH is hard!  So I wrote some code for  
debugging and testing TH functions.

There is a module now called HOC.THDebug that contains some useful  
printing methods.  In Tests there is also now a target thtests that  
compiles two files for testing expandSynonyms.  Because it is TH, the  
test actually runs from within the compiler.  To run the test, you  
compile the program.  thtests actually ensures that the compile is run  
every time.  If the compile succeeds, the test passed!  It needs work  
to be a real test harness, but I think it's something to build on.

Beyond that, runIO and the code in THDebug are tremendously useful for  
outputting intermediate results (during compile) of your TH code.

-- 
Daniel

Re: [hoc-devel] Is this list dead?

[Daniel R. <da...@ph...>]

On Aug 17, 2008, at 7:54 PM, André Pang wrote:

> It's certainly not dead


In that case,

I've figured out the build problem with using the system libffi.  I'll  
commit a patch for that as soon as possible.

I've also figured out all the build problems dynamic libraries.  It  
turns out that mac os x is one of the few platforms that building PIC  
code and -dynamic works at all.  Unfortunately, none of the cabal  
libraries (or the ghc libraries) are built as shared libraries.  This  
means that your dynamic version of HOC needs to staticly link in all  
it's dependencies.  If your main app also links those dependencies,  
this creates two copies of that dependency in memory.  It's possible  
to build GHC and cabal stuff with all dynamic libraries (which will  
solve this problem) but the link command isn't generated by GHC and so  
must be determined by hand (or generated from the data in ghc-pkg),  
and more importantly, isn't supported by the cabal  or GHC build  
system very well.

I don't see any good reason to build HOC as a dynamic library, since  
without jumping through very small, very high loops, it's entirely  
possible it will increase your memory usage, thus negating the  
benefits of a shared library.

The best answer is that dynamic library support is very close to ready  
in GHC 6.10 (and is targeted for 6.10.1 currently).  GHC 6.10 is  
supposed to be out in a few weeks, so we should revisit dynamic  
libraries then.

There are a few other issues.
- HOC installs itself in an odd place with current versions of GHC.
- I'm unfamiliar with the cabal build system so I haven't touched that  
stuff at all.  Are there plans to maintain two build systems  
indefinitely?
- Mac OS 10.5 introduced xml descriptions useful for generating  
language bindings for all of their core frameworks.  It's entirely  
possible this could simplify the code generation.
- Mac OS 10.5 introduced garbage collection into Objective-C.  This  
might simplify the referencing managing code.
- Mac OS 10.5 also deprecated a whole bunch of objective c runtime calls
- make happily continues on errors, even with -k.  This should  
probably be fixed.

Now that I have a google code account, I'll try to add these issues in  
the issue tracker.

Right now I'm trying to understand the code that is there and adding  
comments as I figure it out.

-- 
Daniel

Re: [hoc-devel] documentation

[André P. <oz...@al...>]

On 11/08/2008, at 3:45 PM, Daniel Rogers wrote:

> Can someone explain what the constructors Allocated, Covariant,
> CovariantInstance, Inited, and Released mean?  I'm managed to figure
> out most of it, though I don't understand what the "Covariant" ones
> mean.  Specifically, I'm trying to understand "doctorCovariant" in
> DeclareSelector.hs.

See Wikipedia for the definitions of covariant and contravariant;  
they're to do with return types and parameter types to functions:

   http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29

I'm not entirely sure what they mean in the context of HOC, though...  
I'm guessing they have something to do with constructing the phantom  
types properly so that functions can properly accept covariant types.   
Wolfgang will know for sure, though.


-- 
% Andre Pang : trust.in.love.to.save  <http://www.algorithm.com.au/>

Re: [hoc-devel] Is this list dead?

[André P. <oz...@al...>]

On 17/08/2008, at 2:21 AM, Daniel Rogers wrote:

> Is this list dead?  I've not gotten any responses to my previous
> emails.  Is hoc dead?

It's certainly not dead, but it's not particularly active at the  
moment (as you can see).  I've received all your previous messages and  
will be looking to integrate them into the main trunk when I've got  
time: I've got a full-time job these days and have a number of other  
projects that I hack on, so HOC hasn't got much love & care at all in  
the past year.  Sorry, that's the best I can do at the moment.

Daniel, if you've got a Google Code account, drop me a private email  
with your account name and I'll add you to the committer list so you  
can send back patches without needing to go through the bureaucracy :).


-- 
% Andre Pang : trust.in.love.to.save  <http://www.algorithm.com.au/>

[hoc-devel] Is this list dead?

[Daniel R. <da...@ph...>]

Hi!

Is this list dead?  I've not gotten any responses to my previous  
emails.  Is hoc dead?

-- 
Daniel

[hoc-devel] documentation

[Daniel R. <da...@ph...>]

Greetings again,

I'm going through the sources, trying to understand how they work, and  
commenting what I find.  (I'd love to be able to checkin the comments  
when I'm done).

Can someone explain what the constructors Allocated, Covariant,  
CovariantInstance, Inited, and Released mean?  I'm managed to figure  
out most of it, though I don't understand what the "Covariant" ones  
mean.  Specifically, I'm trying to understand "doctorCovariant" in  
DeclareSelector.hs.

Actually, an overview of how the memory management works in the  
bindings would be great.

-- 
Daniel

[hoc-devel] Patch to add InterfaceGenerator2 to build

[Daniel R. <da...@ph...>]

Greetings,

Here is another patch, this one adds support for building  
InterfaceGenerator2.  I noticed that there is a cabal file.  I'll see  
about making my patches work for the cabal file too.  Is there a plan  
in place to maintain two parallel build systems indefinitely?


-- 
Daniel

[hoc-devel] configure options patch

[Daniel R. <da...@ph...>]

Greetings,

Here is a patch to add the three configure options:

--with-ffi-sources
--with-ffi
--with-dynamic-haskell

--with-ffi-sources lets you specify the location of your libffi source  
directory.

--with-ffi lets you specify the prefix into which libffi is installed.

--with-dynamic-haskell lets you specify the HocBuildDylibs flag I saw  
in a few places in the make file.

Right now building with the system libffi is broken for reasons I  
don't quite understand.  Partially, it's because the static objects do  
not play nice with a dynamically linked libffi.  The defaults will  
find libffi-src and failing that, look for a system libffi.   
Unfortunately, building with HocBuildDylibs /also/ doesn't work.  I'm  
not sure why either.  I just saw that someone putting the flag there  
in the makefile, so I exposed it to ./configure

Having --with-ffi-sources is quite useful, and hopefully, having the  
two build options available in the configure script will encourage me  
(or someone else) to fix them.

-- 
Daniel

Re: [hoc-devel] HOC on mac os 10.5

[Daniel R. <da...@ph...>]

I am not!  Thank you.  The old page has higher google status, ironicly.

--  
Daniel


On Aug 10, 2008, at 9:07 AM, Judah Jacobson wrote:

> On Sat, Aug 9, 2008 at 10:06 PM, Daniel Rogers <da...@ph... 
> > wrote:
>> Greetings,
>>
>> I'm trying to build HOC on Mac OS 10.5 (i386).  There are a lot of
>> things that don't work, and a lot of things that are unnecessary.
>> Here is a list.
>>
>
> Daniel, have you tried building from the newer repo at:
> http://code.google.com/p/hoc/
>
> I was able to build on 10.5.4 using that.
>
>> 4. However, parsing the header files is mute, since apple 10.5
>> included BridgeSupport.  So there is no need to include a parser for
>> header files, since it is sufficient to parse the xml file for the
>> framework.   And apple has included a .bridgesupport file for every
>> framework they have, and a tool for generating your own.
>>
>
> There's been some discussion of this in the past, FYI:
> http://www.haskell.org/pipermail/haskell-cafe/2007-November/ 
> 034205.html
> http://www.haskell.org/pipermail/haskell-cafe/2007-November/ 
> 034223.html
>
> Best,
> -Judah
>

Re: [hoc-devel] HOC on mac os 10.5

[Judah J. <jud...@gm...>]

On Sat, Aug 9, 2008 at 10:06 PM, Daniel Rogers <da...@ph...> wrote:
> Greetings,
>
> I'm trying to build HOC on Mac OS 10.5 (i386).  There are a lot of
> things that don't work, and a lot of things that are unnecessary.
> Here is a list.
>

Daniel, have you tried building from the newer repo at:
http://code.google.com/p/hoc/

I was able to build on 10.5.4 using that.

> 4. However, parsing the header files is mute, since apple 10.5
> included BridgeSupport.  So there is no need to include a parser for
> header files, since it is sufficient to parse the xml file for the
> framework.   And apple has included a .bridgesupport file for every
> framework they have, and a tool for generating your own.
>

There's been some discussion of this in the past, FYI:
http://www.haskell.org/pipermail/haskell-cafe/2007-November/034205.html
http://www.haskell.org/pipermail/haskell-cafe/2007-November/034223.html

Best,
-Judah

[hoc-devel] Generated code

[Daniel R. <da...@ph...>]

Hello again,

since I am unable to get the generated output for HOC, would someone  
be so kind as to send me a fully-built, read to be installed version  
of HOC (or at least the generated .hs files contained within?)

-- 
Daniel

[hoc-devel] HOC on mac os 10.5

[Daniel R. <da...@ph...>]

Greetings,

I'm trying to build HOC on Mac OS 10.5 (i386).  There are a lot of  
things that don't work, and a lot of things that are unnecessary.   
Here is a list.

1. libffi is included with the default install of mac os x (and it's  
newer).

2. The bundled libffi doesn't build on 10.5.

3. Obj-C 2.0 apparently sufficiently changed the header files that  
they no longer parse correctly.

4. However, parsing the header files is mute, since apple 10.5  
included BridgeSupport.  So there is no need to include a parser for  
header files, since it is sufficient to parse the xml file for the  
framework.   And apple has included a .bridgesupport file for every  
framework they have, and a tool for generating your own.

5. 10.5 has optional garbage collection, which would simplify things a  
great deal.

6. 10.5 deprecated a whole slew of the objective-c runtime methods.   
This is related to GC.

Anyways, it interests me to do so, so I'm attempting resolve some of  
these issues.

-- 
Daniel

Re: [hoc-devel] iPhone/Cocoa Touch support?

[Samuel B. <na...@gm...>]

On Thu, Jul 17, 2008 at 10:43 AM, Andrew Robbins <and...@ya...> wrote:

> (2) The ARM compilation is more of an issue, but is not something the HOC project really has control over. Also, I'm using macosx-10.4 which doesn't have an ARM cross compiler (I believe this is only available for macosx-10.5) so I can't help much on that front.

Yeah, GHC isn't really prepared to cross-compile anything, never mind
cross-compiling code that uses TH (which would basically require the
very same GHC executable to support cross-compilation, native
compilation, and GHCi in order to be able to run the TH code).

You would basically have to run an ARM version of GHC (is there one
yet?) under something like qemu.

Re: [hoc-devel] iPhone/Cocoa Touch support?

[Andrew R. <and...@ya...>]

There are 2 aspects of this that need consideration, not just the ARM aspect. 

(1) Currently the tool 'ifgen' that converts Objective-C frameworks into Haskell modules, is only designed to convert Foundation.framework and AppKit.framework. I have done some initial work to abstract this tool to allow it to work on other frameworks, and I will submit my patch soon. What would be nice is if we could use CoreSurface.framework (which is the API to the multi-touch-screen).

(2) The ARM compilation is more of an issue, but is not something the HOC project really has control over. Also, I'm using macosx-10.4 which doesn't have an ARM cross compiler (I believe this is only available for macosx-10.5) so I can't help much on that front.

Andrew


--- On Wed, 7/16/08, ne...@n-... <ne...@n-...> wrote:

> From: ne...@n-... <ne...@n-...>
> Subject: [hoc-devel] iPhone/Cocoa Touch support?
> To: hoc...@li...
> Date: Wednesday, July 16, 2008, 3:18 AM
> Will there be support for the iPhone/Cocoa Touch in the
> future?
> There are cross-compilers for the ARM-architecture.
> 
> Regards,
> Nikolas M.
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> hoc-devel mailing list
> hoc...@li...
> https://lists.sourceforge.net/lists/listinfo/hoc-devel


      

[hoc-devel] iPhone/Cocoa Touch support?

[<ne...@n-...>]

Will there be support for the iPhone/Cocoa Touch in the future?
There are cross-compilers for the ARM-architecture.

Regards,
Nikolas M.