xmlvm-developers — Used to discuss development of XMLVM itself. Not for developers using XMLVM.

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

Are we even sure that linking against such a huge library would really be
that much faster? From my experience linking huge binaries can take a long
time as well.

In the end it looks like this:   timeSaved = (timePipelineNow -
timePipelineThen)  - timeLinking

If the times saved is small, the question is whether it makes sense
investing time into it at all. Therefore it would be good to have some
estimates first.

// Sascha

2011/6/10 Arno Puder <ar...@pu...>

> Yes, we've had this discussion before. Basically creating a Unix-like
> library (.a) that speeds things compilation time. However, the problem
> is that (at least) for now it wouldn't work with the C backend. We do
> optimizations that go beyond the simple decision "should this file be
> included or not" (what the linker typically does, and which, btw, is
> also performed by XMLVM at compile-time). We also optimize things like
> vtables, e.g., if a method never gets overridden, it will not end up
> in the vtable. This knowledge, however, only exists if we take the
> application into account. If the application overrides a library
> method, then the cross-compilation of the library also needs to
> change.
>
> I agree that for a regular development cycle it would make sense to
> have something like a library and only do full optimizations for the
> final release. We would need a way to cross-compile without
> optimizations. One big problem I see here are interface methods
> (because of the selector coloring scheme that is used), but I better
> let Markus respond to this since he implemented those optimizations.
>
> Arno
>
>
> On Jun 10, 2011, at 6:26 AM, Panayotis Katsaloulis
> <pan...@pa...> wrote:
>
> >
> > On 10 Ιουν 2011, at 3:11 μ.μ., Sascha Haeberling wrote:
> >
> >> Panayotis,
> >>
> >> sorry, I didn't understand what you mean. What do you mean by "the
> library"? The C backend does compute all dependencies so that the number of
> classes that are compiled and outputted in the end is at a minimum. Only
> required classes will be pulled in. Why would you want to replace this and
> with what?
> >>
> >> // Sascha
> >
> >
> > This is from an old discussion.
> >
> > The idea is to compile the whole JDK and iPhone compatibility library
> (and probably other dependencies) into a C library (i.e. in a form of .a
> file) and compile the project against this library.
> > Thus the Xcode project will compile much much faster and even the
> production of the Xcode project will be faster (and smaller) since no files
> from the JDK and the compatibility library will be required any more.
> >
> > This idea was also in the earlier days of ObjC backend, but due to the
> way ObjC handled dependencies and late binding, the gain was far less.
> > Now with the strong typed C language, things should be much better.
> >
> > For example, if a function is not used at all, the C compiler understands
> that and never embeds it into the output binary - we have optimizations in
> the method-level, instead of the class-level.
> >
> >
> > I don't know how virtual functions are handled and probably Arno could
> help with this.
> >
> >
> > PS: I remember that ProGuard is also able to perform this type of
> optimizations and it is already used for this reason in Android projects.
> Probably we should also do something similar?
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Xmlvm-developers mailing list
> > Xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>

Re: [xmlvm-dev] C backend and library

[Arno P. <ar...@pu...>]

Yes, we've had this discussion before. Basically creating a Unix-like
library (.a) that speeds things compilation time. However, the problem
is that (at least) for now it wouldn't work with the C backend. We do
optimizations that go beyond the simple decision "should this file be
included or not" (what the linker typically does, and which, btw, is
also performed by XMLVM at compile-time). We also optimize things like
vtables, e.g., if a method never gets overridden, it will not end up
in the vtable. This knowledge, however, only exists if we take the
application into account. If the application overrides a library
method, then the cross-compilation of the library also needs to
change.

I agree that for a regular development cycle it would make sense to
have something like a library and only do full optimizations for the
final release. We would need a way to cross-compile without
optimizations. One big problem I see here are interface methods
(because of the selector coloring scheme that is used), but I better
let Markus respond to this since he implemented those optimizations.

Arno


On Jun 10, 2011, at 6:26 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:

>
> On 10 Ιουν 2011, at 3:11 μ.μ., Sascha Haeberling wrote:
>
>> Panayotis,
>>
>> sorry, I didn't understand what you mean. What do you mean by "the library"? The C backend does compute all dependencies so that the number of classes that are compiled and outputted in the end is at a minimum. Only required classes will be pulled in. Why would you want to replace this and with what?
>>
>> // Sascha
>
>
> This is from an old discussion.
>
> The idea is to compile the whole JDK and iPhone compatibility library (and probably other dependencies) into a C library (i.e. in a form of .a file) and compile the project against this library.
> Thus the Xcode project will compile much much faster and even the production of the Xcode project will be faster (and smaller) since no files from the JDK and the compatibility library will be required any more.
>
> This idea was also in the earlier days of ObjC backend, but due to the way ObjC handled dependencies and late binding, the gain was far less.
> Now with the strong typed C language, things should be much better.
>
> For example, if a function is not used at all, the C compiler understands that and never embeds it into the output binary - we have optimizations in the method-level, instead of the class-level.
>
>
> I don't know how virtual functions are handled and probably Arno could help with this.
>
>
> PS: I remember that ProGuard is also able to perform this type of optimizations and it is already used for this reason in Android projects. Probably we should also do something similar?
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

Ah now I see, thanks for the explanation. I am curious to what Arno has to
say about this, as I am not in this matter too deeply. However, I know that
we are doing several optimizations on the files in the C-backend when we
know that a certain set of classes doesn't exist.

One functionality we have right now is introducing special error methods
that stop the execution of the program, if a "red class" is hit. This makes
sense for classes we are not sure actually work at all for example.

Also I wonder if the linking process would then not take a lot of time and
if the time speed-up would then be really that much.

Just thinking out loud ... I let Arno comment on it, who knows much better
to evaluate the situation.

// Sascha

2011/6/10 Panayotis Katsaloulis <pan...@pa...>

>
> On 10 Ιουν 2011, at 3:11 μ.μ., Sascha Haeberling wrote:
>
> > Panayotis,
> >
> > sorry, I didn't understand what you mean. What do you mean by "the
> library"? The C backend does compute all dependencies so that the number of
> classes that are compiled and outputted in the end is at a minimum. Only
> required classes will be pulled in. Why would you want to replace this and
> with what?
> >
> > // Sascha
>
>
> This is from an old discussion.
>
> The idea is to compile the whole JDK and iPhone compatibility library (and
> probably other dependencies) into a C library (i.e. in a form of .a file)
> and compile the project against this library.
> Thus the Xcode project will compile much much faster and even the
> production of the Xcode project will be faster (and smaller) since no files
> from the JDK and the compatibility library will be required any more.
>
> This idea was also in the earlier days of ObjC backend, but due to the way
> ObjC handled dependencies and late binding, the gain was far less.
> Now with the strong typed C language, things should be much better.
>
> For example, if a function is not used at all, the C compiler understands
> that and never embeds it into the output binary - we have optimizations in
> the method-level, instead of the class-level.
>
>
> I don't know how virtual functions are handled and probably Arno could help
> with this.
>
>
> PS: I remember that ProGuard is also able to perform this type of
> optimizations and it is already used for this reason in Android projects.
> Probably we should also do something similar?
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>

Re: [xmlvm-dev] C backend and library

[Panayotis K. <pan...@pa...>]

On 10 Ιουν 2011, at 3:11 μ.μ., Sascha Haeberling wrote:

> Panayotis,
> 
> sorry, I didn't understand what you mean. What do you mean by "the library"? The C backend does compute all dependencies so that the number of classes that are compiled and outputted in the end is at a minimum. Only required classes will be pulled in. Why would you want to replace this and with what?
> 
> // Sascha


This is from an old discussion.

The idea is to compile the whole JDK and iPhone compatibility library (and probably other dependencies) into a C library (i.e. in a form of .a file) and compile the project against this library.
Thus the Xcode project will compile much much faster and even the production of the Xcode project will be faster (and smaller) since no files from the JDK and the compatibility library will be required any more.

This idea was also in the earlier days of ObjC backend, but due to the way ObjC handled dependencies and late binding, the gain was far less.
Now with the strong typed C language, things should be much better.

For example, if a function is not used at all, the C compiler understands that and never embeds it into the output binary - we have optimizations in the method-level, instead of the class-level.


I don't know how virtual functions are handled and probably Arno could help with this.


PS: I remember that ProGuard is also able to perform this type of optimizations and it is already used for this reason in Android projects. Probably we should also do something similar? 

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

Panayotis,

sorry, I didn't understand what you mean. What do you mean by "the library"?
The C backend does compute all dependencies so that the number of classes
that are compiled and outputted in the end is at a minimum. Only required
classes will be pulled in. Why would you want to replace this and with what?

// Sascha

On Fri, Jun 10, 2011 at 11:00 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> Hello!
>
> I remember this discussion in the past, but I would like to bring it up
> again.
> >From my understanding, the C backend right now computates on the fly the
> required classes and adds only those to the Xcode project.
> Since now in C the handling of library should be more optimized, I think
> that it would be very interesting to use the library (which will also reduce
> compile time to minimum) and will make this class optimization obsolete.
>
> What do you think?
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>

[xmlvm-dev] C backend and library

[Panayotis K. <pan...@pa...>]

Hello!

I remember this discussion in the past, but I would like to bring it up again.
From my understanding, the C backend right now computates on the fly the required classes and adds only those to the Xcode project.
Since now in C the handling of library should be more optimized, I think that it would be very interesting to use the library (which will also reduce compile time to minimum) and will make this class optimization obsolete.

What do you think?

Re: [xmlvm-dev] ARC

[Panayotis K. <pan...@pa...>]

On Jun 8, 2011, at 9:03 PM, Arno Puder wrote:

> I don't know yet what ARC is but just to note that we are in
> compliance with Apples guidelines. If ARC should make reference
> counting more efficient, then that is nice for the Objective-C
> backend, however, it is irrelevant for the C backend since we use a
> garbage collector.
> 
> Arno


From my understanding, it automates the procedure of retain and release/autorelease
Practically you don't need to (or probably you should not) use retain/release any more.
The compiler takes care of that and automatically adds this code for you.
Indeed a GC is a more elegant solution of course.

Re: [xmlvm-dev] ARC

[Paul P. <bay...@gm...>]

Panayotis,

As I understand it, once the C backend supports everything the Obj-C backend
does, the Obj-C backend will not be updated anymore.  That may mean a branch
is tagged & it's removed from trunk or it just remains in trunk unchanged,
but either way it's living stagnant.  So I'm not going to stop you, but I'm
curious why you would want to invest that time in the Obj-C backend.

Paul


On Wed, Jun 8, 2011 at 1:03 PM, Arno Puder <ar...@pu...> wrote:

> I don't know yet what ARC is but just to note that we are in
> compliance with Apples guidelines. If ARC should make reference
> counting more efficient, then that is nice for the Objective-C
> backend, however, it is irrelevant for the C backend since we use a
> garbage collector.
>
> Arno
>
> On Jun 8, 2011, at 10:23 AM, Panayotis Katsaloulis
> <pan...@pa...> wrote:
>
> >
> > On Jun 8, 2011, at 6:51 PM, Arno Puder wrote:
> >
> >> I cannot read this document because I have to agree to new terms and
> >> condition of the iOS developer program and I don't want to just
> >> blindly click on "I agree". Does anyone happen to know what these new
> >> terms are?
> >>
> >> Coming back to the reference counting problem. This is already solved
> >> with the C backend since we have a fully fledged garbage collector.
> >> Except in some isolated parts of the wrapper library, there are no
> >> more retain/releases in the generated code.
> >>
> >> Arno
> >
> >
> > Even though, I believe that since this is recommended by Apple, I would
> suggest to follow their guidelines.
> >
> > Moreover, although I already know that the ObjC backend is not actively
> developed in favor of the C backend, I believe it worths it to support the
> ARC and I could start working with it.
> >
> ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Xmlvm-developers mailing list
> > Xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>

Re: [xmlvm-dev] ARC

[Arno P. <ar...@pu...>]

I don't know yet what ARC is but just to note that we are in
compliance with Apples guidelines. If ARC should make reference
counting more efficient, then that is nice for the Objective-C
backend, however, it is irrelevant for the C backend since we use a
garbage collector.

Arno

On Jun 8, 2011, at 10:23 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:

>
> On Jun 8, 2011, at 6:51 PM, Arno Puder wrote:
>
>> I cannot read this document because I have to agree to new terms and
>> condition of the iOS developer program and I don't want to just
>> blindly click on "I agree". Does anyone happen to know what these new
>> terms are?
>>
>> Coming back to the reference counting problem. This is already solved
>> with the C backend since we have a fully fledged garbage collector.
>> Except in some isolated parts of the wrapper library, there are no
>> more retain/releases in the generated code.
>>
>> Arno
>
>
> Even though, I believe that since this is recommended by Apple, I would suggest to follow their guidelines.
>
> Moreover, although I already know that the ObjC backend is not actively developed in favor of the C backend, I believe it worths it to support the ARC and I could start working with it.
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers

Re: [xmlvm-dev] ARC

[Panayotis K. <pan...@pa...>]

On Jun 8, 2011, at 6:51 PM, Arno Puder wrote:

> I cannot read this document because I have to agree to new terms and
> condition of the iOS developer program and I don't want to just
> blindly click on "I agree". Does anyone happen to know what these new
> terms are?
> 
> Coming back to the reference counting problem. This is already solved
> with the C backend since we have a fully fledged garbage collector.
> Except in some isolated parts of the wrapper library, there are no
> more retain/releases in the generated code.
> 
> Arno


Even though, I believe that since this is recommended by Apple, I would suggest to follow their guidelines.

Moreover, although I already know that the ObjC backend is not actively developed in favor of the C backend, I believe it worths it to support the ARC and I could start working with it.

Re: [xmlvm-dev] ARC

[Arno P. <ar...@pu...>]

I cannot read this document because I have to agree to new terms and
condition of the iOS developer program and I don't want to just
blindly click on "I agree". Does anyone happen to know what these new
terms are?

Coming back to the reference counting problem. This is already solved
with the C backend since we have a fully fledged garbage collector.
Except in some isolated parts of the wrapper library, there are no
more retain/releases in the generated code.

Arno

On Jun 8, 2011, at 6:49 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:

> Hello all!
>
> When digging the iOS 5 documentation, I found this:
>
> https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniPhoneOS/Articles/iOS5.html#//apple_ref/doc/uid/TP30915195-SW4
>
> I believe this is very interesting and XMLVM should consider implementing it :)
> It seems that more or less it does what we already do.
> If we can indeed get rid of the many retain/release methods and let the compiler decide about it, it would be a great benefit for this project.
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers

[xmlvm-dev] ARC

[Panayotis K. <pan...@pa...>]

Hello all!

When digging the iOS 5 documentation, I found this:

https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniPhoneOS/Articles/iOS5.html#//apple_ref/doc/uid/TP30915195-SW4

I believe this is very interesting and XMLVM should consider implementing it :)
It seems that more or less it does what we already do.
If we can indeed get rid of the many retain/release methods and let the compiler decide about it, it would be a great benefit for this project.

[xmlvm-dev] NSSelector finished

[Panayotis K. <pan...@pa...>]

The new NSSelector API is migrated to the Android backend too.
I've tested it and there seems to be no problem.
I didn't remove the deprecated methods of NSObject yet, just in case something is missing or is not properly working (although I doubt).

Re: [xmlvm-dev] Re-integrated skeleton branch

[Sascha H. <sa...@gm...>]

On Mon, May 23, 2011 at 4:38 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> So to sum up, please correct me if I didn't understand something:
>
> 1) For all inner classes in the compatibility library, we make sure that
> none of them is anonymous
>

If you don't want them to be cross-compiled or skeleton-ized (which you
probably never want), yes. And make sure to add the XMLVMIgnore annotation
to them. Unfortunately there doesn't seem to be a way to append annotations
to anonymous classes.


>
> 2) the option "--gen-wrapper" is no longer there
>

Exact.


>
> 3) the option "gen-c-wrappers" is there, and more clever, but no interface
> change
>

There never was such an option. There is an ant target of that name and an
XMLVM target of that name. Absolutely no interface change. You never ran
--gen-wrapper on non-skeleton classes anyway. In the past, "gen-wrapper" was
enabled for all classes in the processing pipeline. Now it is just enabled
for those classes with XmlvmSkeletonOnly. The name "--gen-wrapper" was
misleading anyway, because it didn't do what you might have thought. It
didn't generate wrapper but generated skeletons.

// Sascha


>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>

Re: [xmlvm-dev] Re-integrated skeleton branch

[Panayotis K. <pan...@pa...>]

So to sum up, please correct me if I didn't understand something:

1) For all inner classes in the compatibility library, we make sure that none of them is anonymous

2) the option "--gen-wrapper" is no longer there

3) the option "gen-c-wrappers" is there, and more clever, but no interface change

[xmlvm-dev] Re-integrated skeleton branch

[Sascha H. <sa...@gm...>]

Hi guys,

I just re-integrated a branch that I've been working on for quite a few
weeks now. The basic feature I wanted to introduce was merging the
compat-lib wrapper on the fly. While doing this, I came across a few things
that were not so nice and needed to be fixed and cleaned-up.

One major achievement from this work is that the --gen-wrapper flag is gone.
It was used in the past to tell the stylesheet to produce a skeleton from
all classes. However, for this purpose we always had the XMLVMSkleleton
annotation for classes that should be turned into skeletons. So I made sure
that all classes that should have this annotation, have it.

In addition, the gen-c-wrappers ant target had some implicit logic in there
that ignored inner classes and classes in sub-packes of org.xmlvm.iphone.
This is very implicit and error-prone. I made sure that these classes now
have an XMLVMIgnore annotation. This also meant turning some anonymous
classes into proper inner classes, so that the annotation could be applied.

And this in one thing I ask the ones of you who work with this to be careful
about (I know Panayotis e.g. made some changes in these classes recently):
>From now on, do not use anonymous classes, if these classes should not be a
part of the cross-compiled compat-lib. In this case, make it an inner class
and attach the XMLVMIgnore annotation to it. The implicit logic always
through all all innter and anonymous classes for you. You now have to take
care of it yourself by marking it as such.
This clean-up removes quite a bit of messy code and logic we had, and it
should all be a bit clearer now.

As I said, the main motivation of this change was the on-the-fly merging of
the hand-written wrapper code. This is needed by the constant pool and is
nice in general. It saves you in some cases from regenerating these classes
all the time when changes have been made in the stylesheet or in the classes
themselves. The original skeleton class will be run through the pipeline
anyway and in the end, the hand-written code for the methods will now be
merged into them.

I hope all of this makes sense. If you discover issues with this change, let
me know on this thread.

// Sascha

Re: [xmlvm-dev] C backend issues

[Arno P. <ar...@pu...>]

just some clarifications on the red list: the red list contains those 
classes of Apache Harmony that we will never use under iOS (e.g., AWT or 
Swing). We are still fine tuning the red list and there are classes on 
that list that might be desirable to have. In those cases simply remove 
the classes to be included from xmlvm/lib/redlist.txt.

Whenever you remove a class from the red list, you should run "ant 
gen-c-native-skeletons". If the class you removed from the red list 
happens to have a native method, a new file will be created in 
xmlvm/src/xmlvm2c/lib/native. Those native methods need to be 
implemented manually using Posix API.

Hope this makes things a little clearer.

Arno


On 5/20/11 1:11 AM, Domenico De Fano wrote:
> Hi,
>
> Thank you Sascha, that couldn't have been more clear!
> Now I'm not sure about the native library. Does it contain those java
> classes that
> need to be implemented in C, right?
> I'm asking because I searched for java.util.TimeZone in the red list but
> I couldn't find it;
> instead, in the native library there is a native_java_util_TimeZone.c
> Does it mean that this class cannot be directly cross-compiled from the
> Harmony version
> and thus that I need to implement the methods in c?
>
> Thank you again for your help!
>
> P.S: Arno, I read the slides as a first step as you suggested me. It
> helped me a lot
> to understand the basics of the C backend, but I had some doubts left on
> the red list topic.
>
> On Thu, May 19, 2011 at 6:53 PM, Arno Puder <ar...@pu...
> <mailto:ar...@pu...>> wrote:
>
>
>     to add to this: there is a little bit of information on the C backend
>     and the redlist in the slides: xmlvm/doc/slides
>
>     Arno
>
>
>     On 5/19/11 9:45 AM, Sascha Haeberling wrote:
>      > Hi Domenico,
>      >
>      > these are all good questions, no worries. I think we haven't done a
>      > terrific job in documenting all of this so far. I hope I will
>     find some
>      > time soon to update out docs on how this works.
>      >
>      > Let me give you some background on what the redlist is: We are
>     loading
>      > resources recursively. For each class C we have a list of
>     dependencies.
>      > These are classes that are used from within that class C.
>     Unfortunately,
>      > if we do this even on a simple HelloWorld application, we would
>     end up
>      > with almost the whole harmony SDK. So what we did it, we created stop
>      > signs for the recursive loading algorithm and said... this class,
>     don't
>      > load it, we probably don't need it. This make sense because there
>     are a
>      > lot of classes that we don't need in a mobile application.
>      > In a first step we red listed a lot of classes and our approach is to
>      > take classes of whenever we need them. Sometimes taking of a
>     class from
>      > the list might require some more work like implementing that class'
>      > native methods, or removing/chaning other methods.
>      >
>      > I am not sure about java.util.TimeZone. It sounds like it could
>     be a bit
>      > of work to make it work fine. But you can try yourself what happens
>      > by modifying the redlist.txt. Just remove java.util.TimeZone from it.
>      > And if other classes are missing, remove those, too. If native
>     methods
>      > needs to be implemented and you hit them, then you need to implement
>      > those or find a different way of simplifying the class.
>      >
>      > I hope that makes sense.
>      >
>      > // Sascha
>      >
>      > On Thu, May 19, 2011 at 5:34 PM, Domenico De Fano
>     <dom...@gm... <mailto:dom...@gm...>
>      > <mailto:dom...@gm... <mailto:dom...@gm...>>> wrote:
>      >
>      >     Hi all,
>      >
>      >     I finally decided to make the big jump to the C backend.
>     After a few
>      >     attempts, I managed to compile my project without errors.
>      >     In order to do this, I had to write a skeleton for the class
>      >     UITableViewController. I must say, I found the C backend is
>      >     painfully unreadable and it took me some
>      >     time to understand how to manipulate it. I hope however it
>     will get
>      >     better with time as I get used to it.
>      >     Now as I try to run the Xcode project, I obtain the following
>     error:
>      >
>      >     XMLVM Error: Unsatisfied red class dependency:
>      >     (java_util_TimeZone___INIT___):(path to the application
>      >     source)/java_util_TimeZone.m:805
>      >
>      >     Does it mean that the class TimeZone needs some other class
>     which is
>      >     in the red list? Or that it misses that constructor?
>      >
>      >     I'm not sure I understood from the slides how to remove
>     classes from
>      >     the red list. Should I retrieve the class TimeZone from the
>      >     Harmony distribution and insert it into the
>     src/xmlvm2c/lib/proxies?
>      >     I also see that there already is a
>     native_java_lang_TimeZone.c class
>      >     in the
>      >     src/xmlvm2c/lib/proxies folder; should I use that one and
>     implement
>      >     the missing method?
>      >
>      >     I'm sorry about all the questions, but I don't find the
>     passage from
>      >     the Objective-C backend really natural.
>      >
>      >     Thank your for your attention
>      >
>      >
>      >     --
>      >     Domenico De Fano
>      >
>      >
>     ------------------------------------------------------------------------------
>      >     What Every C/C++ and Fortran developer Should Know!
>      >     Read this article and learn how Intel has extended the reach
>     of its
>      >     next-generation tools to help Windows* and Linux* C/C++ and
>     Fortran
>      >     developers boost performance applications - including clusters.
>      > http://p.sf.net/sfu/intel-dev2devmay
>      >     _______________________________________________
>      >     Xmlvm-developers mailing list
>      > Xml...@li...
>     <mailto:Xml...@li...>
>      > <mailto:Xml...@li...
>     <mailto:Xml...@li...>>
>      > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>      >
>      >
>      >
>      >
>      >
>     ------------------------------------------------------------------------------
>      > What Every C/C++ and Fortran developer Should Know!
>      > Read this article and learn how Intel has extended the reach of its
>      > next-generation tools to help Windows* and Linux* C/C++ and Fortran
>      > developers boost performance applications - including clusters.
>      > http://p.sf.net/sfu/intel-dev2devmay
>      >
>      >
>      >
>      > _______________________________________________
>      > Xmlvm-developers mailing list
>      > Xml...@li...
>     <mailto:Xml...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
>     ------------------------------------------------------------------------------
>     What Every C/C++ and Fortran developer Should Know!
>     Read this article and learn how Intel has extended the reach of its
>     next-generation tools to help Windows* and Linux* C/C++ and Fortran
>     developers boost performance applications - including clusters.
>     http://p.sf.net/sfu/intel-dev2devmay
>     _______________________________________________
>     Xmlvm-developers mailing list
>     Xml...@li...
>     <mailto:Xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
>

Re: [xmlvm-dev] NSSelector introduction

[Arno P. <ar...@pu...>]

On 5/21/11 4:30 AM, Panayotis Katsaloulis wrote:
>
> On May 13, 2011, at 8:46 PM, Arno Puder wrote:
>
>>
>> I'm OK with this patch. Needless to say you should only commit it when
>> the C side works as well. Please take a look at the current C
>> implementation of performSel... and ask me any questions you have in
>> understanding the inner workings. The one thing that might help you to
>> understand the C code is the dispatcherObject. Its purpose is to be used
>> as a stand-in to perform the actual performSelec... method on the
>> Objective-C side.
>>
>> Arno
>
> I have commit the patch, both backends work.
> What I actually did for the C backend, is more or less to copy the method of the older system.
> I am sure that some optimization could be performed, but I am a bit confused :)
>
> I didn't touch the old methods, I have only marked them as deprecated.
> If you agree, I'd go over the android demos and replace the obsolete code.
> :)

yes, your implementation is pretty inefficient.  :)  Please change the 
Android Compat Lib and all other locations to make use of NSSelector. 
Then remove the deprecated method. Once you have done that, I will 
revise your implementation. I need to change the implementation in 
DispatcherObject that will break the deprecated method, so I will wait 
until you are done with your changes.

Arno

Re: [xmlvm-dev] NSSelector introduction

[Panayotis K. <pan...@pa...>]

On May 13, 2011, at 8:46 PM, Arno Puder wrote:

> 
> I'm OK with this patch. Needless to say you should only commit it when
> the C side works as well. Please take a look at the current C
> implementation of performSel... and ask me any questions you have in
> understanding the inner workings. The one thing that might help you to
> understand the C code is the dispatcherObject. Its purpose is to be used
> as a stand-in to perform the actual performSelec... method on the
> Objective-C side.
> 
> Arno

I have commit the patch, both backends work.
What I actually did for the C backend, is more or less to copy the method of the older system. 
I am sure that some optimization could be performed, but I am a bit confused :)

I didn't touch the old methods, I have only marked them as deprecated.
If you agree, I'd go over the android demos and replace the obsolete code.
:)

Re: [xmlvm-dev] C backend issues

[Arno P. <ar...@pu...>]

to add to this: there is a little bit of information on the C backend 
and the redlist in the slides: xmlvm/doc/slides

Arno


On 5/19/11 9:45 AM, Sascha Haeberling wrote:
> Hi Domenico,
>
> these are all good questions, no worries. I think we haven't done a
> terrific job in documenting all of this so far. I hope I will find some
> time soon to update out docs on how this works.
>
> Let me give you some background on what the redlist is: We are loading
> resources recursively. For each class C we have a list of dependencies.
> These are classes that are used from within that class C. Unfortunately,
> if we do this even on a simple HelloWorld application, we would end up
> with almost the whole harmony SDK. So what we did it, we created stop
> signs for the recursive loading algorithm and said... this class, don't
> load it, we probably don't need it. This make sense because there are a
> lot of classes that we don't need in a mobile application.
> In a first step we red listed a lot of classes and our approach is to
> take classes of whenever we need them. Sometimes taking of a class from
> the list might require some more work like implementing that class'
> native methods, or removing/chaning other methods.
>
> I am not sure about java.util.TimeZone. It sounds like it could be a bit
> of work to make it work fine. But you can try yourself what happens
> by modifying the redlist.txt. Just remove java.util.TimeZone from it.
> And if other classes are missing, remove those, too. If native methods
> needs to be implemented and you hit them, then you need to implement
> those or find a different way of simplifying the class.
>
> I hope that makes sense.
>
> // Sascha
>
> On Thu, May 19, 2011 at 5:34 PM, Domenico De Fano <dom...@gm...
> <mailto:dom...@gm...>> wrote:
>
>     Hi all,
>
>     I finally decided to make the big jump to the C backend. After a few
>     attempts, I managed to compile my project without errors.
>     In order to do this, I had to write a skeleton for the class
>     UITableViewController. I must say, I found the C backend is
>     painfully unreadable and it took me some
>     time to understand how to manipulate it. I hope however it will get
>     better with time as I get used to it.
>     Now as I try to run the Xcode project, I obtain the following error:
>
>     XMLVM Error: Unsatisfied red class dependency:
>     (java_util_TimeZone___INIT___):(path to the application
>     source)/java_util_TimeZone.m:805
>
>     Does it mean that the class TimeZone needs some other class which is
>     in the red list? Or that it misses that constructor?
>
>     I'm not sure I understood from the slides how to remove classes from
>     the red list. Should I retrieve the class TimeZone from the
>     Harmony distribution and insert it into the src/xmlvm2c/lib/proxies?
>     I also see that there already is a native_java_lang_TimeZone.c class
>     in the
>     src/xmlvm2c/lib/proxies folder; should I use that one and implement
>     the missing method?
>
>     I'm sorry about all the questions, but I don't find the passage from
>     the Objective-C backend really natural.
>
>     Thank your for your attention
>
>
>     --
>     Domenico De Fano
>
>     ------------------------------------------------------------------------------
>     What Every C/C++ and Fortran developer Should Know!
>     Read this article and learn how Intel has extended the reach of its
>     next-generation tools to help Windows* and Linux* C/C++ and Fortran
>     developers boost performance applications - including clusters.
>     http://p.sf.net/sfu/intel-dev2devmay
>     _______________________________________________
>     Xmlvm-developers mailing list
>     Xml...@li...
>     <mailto:Xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
>
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers

Re: [xmlvm-dev] C backend issues

[Sascha H. <sa...@gm...>]

Hi Domenico,

these are all good questions, no worries. I think we haven't done a terrific
job in documenting all of this so far. I hope I will find some time soon to
update out docs on how this works.

Let me give you some background on what the redlist is: We are loading
resources recursively. For each class C we have a list of dependencies.
These are classes that are used from within that class C. Unfortunately, if
we do this even on a simple HelloWorld application, we would end up with
almost the whole harmony SDK. So what we did it, we created stop signs for
the recursive loading algorithm and said... this class, don't load it, we
probably don't need it. This make sense because there are a lot of classes
that we don't need in a mobile application.
In a first step we red listed a lot of classes and our approach is to take
classes of whenever we need them. Sometimes taking of a class from the list
might require some more work like implementing that class' native methods,
or removing/chaning other methods.

I am not sure about java.util.TimeZone. It sounds like it could be a bit of
work to make it work fine. But you can try yourself what happens
by modifying the redlist.txt. Just remove java.util.TimeZone from it. And if
other classes are missing, remove those, too. If native methods needs to be
implemented and you hit them, then you need to implement those or find a
different way of simplifying the class.

I hope that makes sense.

// Sascha

On Thu, May 19, 2011 at 5:34 PM, Domenico De Fano <dom...@gm...>wrote:

> Hi all,
>
> I finally decided to make the big jump to the C backend. After a few
> attempts, I managed to compile my project without errors.
> In order to do this, I had to write a skeleton for the class
> UITableViewController. I must say, I found the C backend is painfully
> unreadable and it took me some
> time to understand how to manipulate it. I hope however it will get better
> with time as I get used to it.
> Now as I try to run the Xcode project, I obtain the following error:
>
> XMLVM Error: Unsatisfied red class dependency:
> (java_util_TimeZone___INIT___):(path to the application
> source)/java_util_TimeZone.m:805
>
> Does it mean that the class TimeZone needs some other class which is in the
> red list? Or that it misses that constructor?
>
> I'm not sure I understood from the slides how to remove classes from the
> red list. Should I retrieve the class TimeZone from the
> Harmony distribution and insert it into the src/xmlvm2c/lib/proxies?
> I also see that there already is a native_java_lang_TimeZone.c class in the
>
> src/xmlvm2c/lib/proxies folder; should I use that one and implement the
> missing method?
>
> I'm sorry about all the questions, but I don't find the passage from the
> Objective-C backend really natural.
>
> Thank your for your attention
>
>
> --
> Domenico De Fano
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
>

[xmlvm-dev] C backend issues

[Domenico De F. <dom...@gm...>]

Hi all,

I finally decided to make the big jump to the C backend. After a few
attempts, I managed to compile my project without errors.
In order to do this, I had to write a skeleton for the class
UITableViewController. I must say, I found the C backend is painfully
unreadable and it took me some
time to understand how to manipulate it. I hope however it will get better
with time as I get used to it.
Now as I try to run the Xcode project, I obtain the following error:

XMLVM Error: Unsatisfied red class dependency:
(java_util_TimeZone___INIT___):(path to the application
source)/java_util_TimeZone.m:805

Does it mean that the class TimeZone needs some other class which is in the
red list? Or that it misses that constructor?

I'm not sure I understood from the slides how to remove classes from the red
list. Should I retrieve the class TimeZone from the
Harmony distribution and insert it into the src/xmlvm2c/lib/proxies?
I also see that there already is a native_java_lang_TimeZone.c class in the
src/xmlvm2c/lib/proxies folder; should I use that one and implement the
missing method?

I'm sorry about all the questions, but I don't find the passage from the
Objective-C backend really natural.

Thank your for your attention


-- 
Domenico De Fano

Re: [xmlvm-dev] Building for the device with iphonec target

[Arno P. <ar...@pu...>]

the compile error in the GC has been fixed.

Arno


On Fri, May 13, 2011 at 1:03 PM, Markus Heberling <ma...@ti...> wrote:

> Hi,
>
> I can build my project fine fpr the simulator. But building for the actual
> device fails. I'm using the iphonec target.
>
> I get the following error:
> In file included from
> /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/iphone/xmlvm-sock.h:24,
>                  from
> /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/app/native_java_net_InetAddress.m:8:
> /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/iphone/hysock.h:43:27:
> error: sys/socketvar.h: No such file or directory
>
>
> I can just remove the include, and the file is compiled than, but I get
> another error, that I'm not able to fix:
>
> CompileC
> /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Objects-normal/armv6/atomic_ops_stack.o
> ../build/xcode/src/lib/boehmgc/atomic_ops_stack.c normal armv6 c
> com.apple.compilers.gcc.4_2
>     cd /Users/markus/Documents/workspace/Kinderlieder/dist
>     setenv LANG en_US.US-ASCII
>     setenv PATH
> "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
>     /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x c
> -arch armv6 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs
> -fpascal-strings -O0 -Wreturn-type -isysroot
> /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk
> -gdwarf-2 -fvisibility=hidden -mno-thumb -miphoneos-version-min=3.1 -iquote
> /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-generated-files.hmap
> -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-own-target-headers.hmap
> -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-all-target-headers.hmap
> -iquote
> /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-project-headers.hmap
> -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Products/Debug-iphoneos/include
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/armcc
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/gcc
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/hpc
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/ibmc
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/icc
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/msftc
> -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/sunc
> -I../build/xcode/src/lib/boehmgc/include
> -I../build/xcode/src/lib/boehmgc/include/private
> -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/DerivedSources/armv6
> -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/DerivedSources
> -F/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Products/Debug-iphoneos
> -c
> /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/boehmgc/atomic_ops_stack.c
> -o
> /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Objects-normal/armv6/atomic_ops_stack.o
>
> {standard input}:337:even register required -- `strexd lr,r1,[r0]'
> Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2
> failed with exit code 1
>
>
> Any hints, what is wrong here?
>
> Regards,
> Markus
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
>

Re: [xmlvm-dev] Building for the device with iphonec target

[Wolfgang K. <wol...@xm...>]

The network related problem should be fixed now.

-- Wolfgang



On 14.05.11 01:15, Arno Puder wrote:
> We know about the GC related compile error; someone is working on this.
>
> We'll investigate the network problem.
>
> Arno
>
> On May 13, 2011, at 1:04 PM, Markus Heberling <ma...@ti...> wrote:
>
>> Hi,
>>
>> I can build my project fine fpr the simulator. But building for the actual device fails. I'm using the iphonec target.
>>
>> I get the following error:
>> In file included from /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/iphone/xmlvm-sock.h:24,
>>                  from /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/app/native_java_net_InetAddress.m:8:
>> /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/iphone/hysock.h:43:27: error: sys/socketvar.h: No such file or directory
>>
>>
>> I can just remove the include, and the file is compiled than, but I get another error, that I'm not able to fix:
>>
>> CompileC /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Objects-normal/armv6/atomic_ops_stack.o ../build/xcode/src/lib/boehmgc/atomic_ops_stack.c normal armv6 c com.apple.compilers.gcc.4_2
>>     cd /Users/markus/Documents/workspace/Kinderlieder/dist
>>     setenv LANG en_US.US-ASCII
>>     setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
>>     /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x c -arch armv6 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -gdwarf-2 -fvisibility=hidden -mno-thumb -miphoneos-version-min=3.1 -iquote /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-generated-files.hmap -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-own-target-headers.hmap -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-all-target-headers.hmap -iquote /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-project-headers.hmap -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Products/Debug-iphoneos/include -I../build/xcode/src/lib/boehmgc/libatomic_ops/src -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/armcc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/gcc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/hpc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/ibmc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/icc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/msftc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/sunc -I../build/xcode/src/lib/boehmgc/include -I../build/xcode/src/lib/boehmgc/include/private -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/DerivedSources/armv6 -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/DerivedSources -F/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Products/Debug-iphoneos -c /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/boehmgc/atomic_ops_stack.c -o /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Objects-normal/armv6/atomic_ops_stack.o
>>
>> {standard input}:337:even register required -- `strexd lr,r1,[r0]'
>> Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 failed with exit code 1
>>
>>
>> Any hints, what is wrong here?
>>
>> Regards,
>> Markus
>> ------------------------------------------------------------------------------
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Xmlvm-developers mailing list
>> Xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers

Re: [xmlvm-dev] Building for the device with iphonec target

[Arno P. <ar...@pu...>]

We know about the GC related compile error; someone is working on this.

We'll investigate the network problem.

Arno

On May 13, 2011, at 1:04 PM, Markus Heberling <ma...@ti...> wrote:

> Hi,
>
> I can build my project fine fpr the simulator. But building for the actual device fails. I'm using the iphonec target.
>
> I get the following error:
> In file included from /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/iphone/xmlvm-sock.h:24,
>                  from /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/app/native_java_net_InetAddress.m:8:
> /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/iphone/hysock.h:43:27: error: sys/socketvar.h: No such file or directory
>
>
> I can just remove the include, and the file is compiled than, but I get another error, that I'm not able to fix:
>
> CompileC /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Objects-normal/armv6/atomic_ops_stack.o ../build/xcode/src/lib/boehmgc/atomic_ops_stack.c normal armv6 c com.apple.compilers.gcc.4_2
>     cd /Users/markus/Documents/workspace/Kinderlieder/dist
>     setenv LANG en_US.US-ASCII
>     setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
>     /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x c -arch armv6 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -gdwarf-2 -fvisibility=hidden -mno-thumb -miphoneos-version-min=3.1 -iquote /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-generated-files.hmap -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-own-target-headers.hmap -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-all-target-headers.hmap -iquote /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Kinderlieder-project-headers.hmap -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Products/Debug-iphoneos/include -I../build/xcode/src/lib/boehmgc/libatomic_ops/src -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/armcc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/gcc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/hpc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/ibmc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/icc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/msftc -I../build/xcode/src/lib/boehmgc/libatomic_ops/src/atomic_ops/sysdeps/sunc -I../build/xcode/src/lib/boehmgc/include -I../build/xcode/src/lib/boehmgc/include/private -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/DerivedSources/armv6 -I/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/DerivedSources -F/Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Products/Debug-iphoneos -c /Users/markus/Documents/workspace/Kinderlieder/dist/../build/xcode/src/lib/boehmgc/atomic_ops_stack.c -o /Users/markus/Library/Developer/Xcode/DerivedData/Kinderlieder-dqzgewranxvdwnbmzbsuizxevalc/Build/Intermediates/Kinderlieder.build/Debug-iphoneos/Kinderlieder.build/Objects-normal/armv6/atomic_ops_stack.o
>
> {standard input}:337:even register required -- `strexd lr,r1,[r0]'
> Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 failed with exit code 1
>
>
> Any hints, what is wrong here?
>
> Regards,
> Markus
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers