xmlvm-users — For current and interested XMLVM users, for public discussions and anouncements.

Re: [xmlvm-users] How to include library (.a file) in Xcode project

[Markus H. <ma...@ti...>]

I have support for adding custom frameworks to the project in my xmlvm fork:

https://github.com/tisoft/xmlvm/commits/master

Currently it is in this commit https://github.com/tisoft/xmlvm/commit/0e61d09fafce12874d5e28009df44740ae55ea70 but that will change when I rebase my changes.
You should be able to put your .a file into a framework directory structure and specify that as a framework dependency to xmlvm.

I don't have the time currently to bring this patch through the official review system, will do so in january or february. If you want to try it out, just check out the master from above and build that.

I am using this to include the QuincyKit and TestFlight Frameworks in my Kinderlieder App, so it is appstore approved. :)

Sample command line parameter for xmlvm:
--lib=SystemConfiguration.framework,/Users/markus/Documents/workspace/Kinderlieder/iphone/frameworks/TestFlight.framework~,/Users/markus/Documents/workspace/Kinderlieder/iphone/frameworks/CrashReporter.framework~

Regards,
Markus

Am 13.12.2012 um 20:33 schrieb Arno Puder <ar...@pu...>:

> 
> XMLVM does not support this. --lib needs to reference a jar file that 
> will also be cross-compiled. There is no option to include a native 
> library. Patches are welcome.  :)
> 
> Arno
> 
> 
> On 12/13/12 10:42 AM, Steve Hannah wrote:
>> Hi everyone,
>> 
>> I'm having some trouble getting xmlvm to automatically add native ios
>> libraries to the generated Xcode project.  I have a library in a file
>> mylib.a, that I would like to have linked to the Xcode project that is
>> generated by XMLVM.
>> 
>> I have tried:
>> 
>> 1. Placing the mylib.a into the resources directory before running the
>> ANT build step.
>> 2. Specifying --lib=/path/to/mylib.a in as a flag in the call to xmlvm
>> 3. Specifying --resource=/path/to/mylib.a as a flag in the call to xmlvm
>> 
>> In all cases, the library is not linked in the resulting Xcode project
>> (that is produced with the build step).  I have to add it manually
>> after the fact.
>> 
>> Any pointers much appreciated.
>> 
>> Steve
>> 
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] How to include library (.a file) in Xcode project

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

XMLVM does not support this. --lib needs to reference a jar file that 
will also be cross-compiled. There is no option to include a native 
library. Patches are welcome.  :)

Arno


On 12/13/12 10:42 AM, Steve Hannah wrote:
> Hi everyone,
>
> I'm having some trouble getting xmlvm to automatically add native ios
> libraries to the generated Xcode project.  I have a library in a file
> mylib.a, that I would like to have linked to the Xcode project that is
> generated by XMLVM.
>
> I have tried:
>
> 1. Placing the mylib.a into the resources directory before running the
> ANT build step.
> 2. Specifying --lib=/path/to/mylib.a in as a flag in the call to xmlvm
> 3. Specifying --resource=/path/to/mylib.a as a flag in the call to xmlvm
>
> In all cases, the library is not linked in the resulting Xcode project
> (that is produced with the build step).  I have to add it manually
> after the fact.
>
> Any pointers much appreciated.
>
> Steve
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

[xmlvm-users] How to include library (.a file) in Xcode project

[Steve H. <st...@we...>]

Hi everyone,

I'm having some trouble getting xmlvm to automatically add native ios
libraries to the generated Xcode project.  I have a library in a file
mylib.a, that I would like to have linked to the Xcode project that is
generated by XMLVM.

I have tried:

1. Placing the mylib.a into the resources directory before running the
ANT build step.
2. Specifying --lib=/path/to/mylib.a in as a flag in the call to xmlvm
3. Specifying --resource=/path/to/mylib.a as a flag in the call to xmlvm

In all cases, the library is not linked in the resulting Xcode project
(that is produced with the build step).  I have to add it manually
after the fact.

Any pointers much appreciated.

Steve

Re: [xmlvm-users] One small XMLVM benchmark

[Steve H. <st...@we...>]

Shai confirmed that they do not use Proguard for their builds.

http://www.codenameone.com/discussion-forum.html?place=msg%2Fcodenameone-discussions%2FrFAJLbMDcPI%2FIBIPo_Fx8ywJ

If I find time and curiosity, perhaps I'll do some experimentation to see
how proguard affects the performance.  Shai's point that LLVM already does
quite good job of optimization leads me to think that there probably isn't
a whole lot to be gained.  But hey, I was wrong in my first assumption that
Avian would be significantly faster than XMLVM.  So what do I know?

-Steve

On Fri, Dec 7, 2012 at 10:09 AM, Steve Hannah <st...@we...> wrote:

> Thanks for the tips.  Avian used pro guard but had optimizations disabled
> because I was getting errors otherwise,
>
> I don't know if the xmlvm build used proguard because I used their build
> server for that one. I will check with Shai to see if they're using
> proguard and what the settings are.
>
> Steve
>
>
> On Friday, December 7, 2012, Jeff Palmer wrote:
>
>> Hi,
>>
>> Might it not help pre-running byte code through Proguard with the number
>> of optimization passes set to say 5?  Some of these static accesses might
>> not even survive the process.  The nice thing might be that xmlvm does not
>> have to change.  Also you can check the the performance impact with or
>> without.
>>
>> On the blog, it said proguard was used for the Avian Port.  This was for
>> size, but was the xmlvm version also pre-run through Proguard?
>>
>> Here is some output, pass 1, from a desktop application.  Am noticing
>> that staticized methods is part of process, which might not be helpful
>> here.  Do not know if it can be turned off.  When Proguard is run against
>> an Android app, some optimizations are disabled, but not that one.
>>
>> [proguard] Ignoring unused library classes...
>> [proguard]   Original number of library classes: 19088
>> [proguard]   Final number of library classes:    1048
>> [proguard] Printing kept classes, fields, and methods...
>>       ** Removed **
>> [proguard] Shrinking...
>> [proguard] Removing unused program classes and class elements...
>> [proguard]   Original number of program classes: 1219
>> [proguard]   Final number of program classes:    910
>> [proguard] Inlining subroutines...
>> [proguard] Optimizing...
>> [proguard]   Number of finalized classes:                 462
>> [proguard]   Number of vertically merged classes:         8
>> [proguard]   Number of horizontally merged classes:       27
>> [proguard]   Number of removed write-only fields:         221
>> [proguard]   Number of privatized fields:                 1467
>> [proguard]   Number of inlined constant fields:           58
>> [proguard]   Number of privatized methods:                773
>> [proguard]   Number of staticized methods:                199
>> [proguard]   Number of finalized methods:                 6007
>> [proguard]   Number of removed method parameters:         281
>> [proguard]   Number of inlined constant parameters:       233
>> [proguard]   Number of inlined constant return values:    50
>> [proguard]   Number of inlined short method calls:        2348
>> [proguard]   Number of inlined unique method calls:       1573
>> [proguard]   Number of inlined tail recursion calls:      22
>> [proguard]   Number of merged code blocks:                138
>> [proguard]   Number of variable peephole optimizations:   8986
>> [proguard]   Number of arithmetic peephole optimizations: 258
>> [proguard]   Number of cast peephole optimizations:       251
>> [proguard]   Number of field peephole optimizations:      49
>> [proguard]   Number of branch peephole optimizations:     3766
>> [proguard]   Number of string peephole optimizations:     1148
>> [proguard]   Number of simplified instructions:           943
>> [proguard]   Number of removed instructions:              6557
>> [proguard]   Number of removed local variables:           1196
>> [proguard]   Number of removed exception blocks:          470
>> [proguard]   Number of optimized local variable frames:   3028
>> [proguard] Shrinking...
>> [proguard] Removing unused program classes and class elements...
>> [proguard]   Original number of program classes: 910
>> [proguard]   Final number of program classes:    869
>>
>>
>> Jeff Palmer
>> WhatIf Squared LLC
>>
>> On Dec 6, 2012, at 8:53 PM, xml...@li...wrote:
>>
>> *From: *Arno Puder <ar...@pu...>
>> *Subject: **Re: [xmlvm-users] One small XMLVM benchmark*
>> *Date: *December 6, 2012 8:55:46 PM EST
>> *To: *Steve Hannah <st...@we...>
>> *Cc: *"xml...@li..." <
>> xml...@li...>
>>
>>
>>
>> well, allow me some remarks. As you already alluded to, performance
>> testing is a tricky business. XMLVM cross-compiles to C code and by its
>> very nature it cannot do hot-patching at runtime. This means that every
>> static access to a class needs to check if that class was already
>> initialized. If your application is mainly using static fields and methods
>> (as did your original test case), XMLVM can't do many optimizations.
>>
>> XMLVM is far from being perfect, but it is doing a decent job. Mileage
>> may vary depending on the details of an app. It is always a good idea to
>> try different tools and pick the one that works best for you.
>>
>> Arno
>>
>>
>>
>
> --
> Steve Hannah
> Web Lite Solutions Corp.
>
>


-- 
Steve Hannah
Web Lite Solutions Corp.

Re: [xmlvm-users] One small XMLVM benchmark

[Jeff P. <jcp...@ro...>]

Hi,

Might it not help pre-running byte code through Proguard with the number of optimization passes set to say 5?  Some of these static accesses might not even survive the process.  The nice thing might be that xmlvm does not have to change.  Also you can check the the performance impact with or without.

On the blog, it said proguard was used for the Avian Port.  This was for size, but was the xmlvm version also pre-run through Proguard?

Here is some output, pass 1, from a desktop application.  Am noticing that staticized methods is part of process, which might not be helpful here.  Do not know if it can be turned off.  When Proguard is run against an Android app, some optimizations are disabled, but not that one. 

[proguard] Ignoring unused library classes...
[proguard]   Original number of library classes: 19088
[proguard]   Final number of library classes:    1048
[proguard] Printing kept classes, fields, and methods...
      ** Removed **
[proguard] Shrinking...
[proguard] Removing unused program classes and class elements...
[proguard]   Original number of program classes: 1219
[proguard]   Final number of program classes:    910
[proguard] Inlining subroutines...
[proguard] Optimizing...
[proguard]   Number of finalized classes:                 462
[proguard]   Number of vertically merged classes:         8
[proguard]   Number of horizontally merged classes:       27
[proguard]   Number of removed write-only fields:         221
[proguard]   Number of privatized fields:                 1467
[proguard]   Number of inlined constant fields:           58
[proguard]   Number of privatized methods:                773
[proguard]   Number of staticized methods:                199
[proguard]   Number of finalized methods:                 6007
[proguard]   Number of removed method parameters:         281
[proguard]   Number of inlined constant parameters:       233
[proguard]   Number of inlined constant return values:    50
[proguard]   Number of inlined short method calls:        2348
[proguard]   Number of inlined unique method calls:       1573
[proguard]   Number of inlined tail recursion calls:      22
[proguard]   Number of merged code blocks:                138
[proguard]   Number of variable peephole optimizations:   8986
[proguard]   Number of arithmetic peephole optimizations: 258
[proguard]   Number of cast peephole optimizations:       251
[proguard]   Number of field peephole optimizations:      49
[proguard]   Number of branch peephole optimizations:     3766
[proguard]   Number of string peephole optimizations:     1148
[proguard]   Number of simplified instructions:           943
[proguard]   Number of removed instructions:              6557
[proguard]   Number of removed local variables:           1196
[proguard]   Number of removed exception blocks:          470
[proguard]   Number of optimized local variable frames:   3028
[proguard] Shrinking...
[proguard] Removing unused program classes and class elements...
[proguard]   Original number of program classes: 910
[proguard]   Final number of program classes:    869


Jeff Palmer
WhatIf Squared LLC

On Dec 6, 2012, at 8:53 PM, xml...@li... wrote:

> From: Arno Puder <ar...@pu...>
> Subject: Re: [xmlvm-users] One small XMLVM benchmark
> Date: December 6, 2012 8:55:46 PM EST
> To: Steve Hannah <st...@we...>
> Cc: "xml...@li..." <xml...@li...>
> 
> 
> 
> well, allow me some remarks. As you already alluded to, performance testing is a tricky business. XMLVM cross-compiles to C code and by its very nature it cannot do hot-patching at runtime. This means that every static access to a class needs to check if that class was already initialized. If your application is mainly using static fields and methods (as did your original test case), XMLVM can't do many optimizations.
> 
> XMLVM is far from being perfect, but it is doing a decent job. Mileage may vary depending on the details of an app. It is always a good idea to try different tools and pick the one that works best for you.
> 
> Arno

Re: [xmlvm-users] One small XMLVM benchmark

[Steve H. <st...@we...>]

Thanks for the tips.  Avian used pro guard but had optimizations disabled
because I was getting errors otherwise,

I don't know if the xmlvm build used proguard because I used their build
server for that one. I will check with Shai to see if they're using
proguard and what the settings are.

Steve

On Friday, December 7, 2012, Jeff Palmer wrote:

> Hi,
>
> Might it not help pre-running byte code through Proguard with the number
> of optimization passes set to say 5?  Some of these static accesses might
> not even survive the process.  The nice thing might be that xmlvm does not
> have to change.  Also you can check the the performance impact with or
> without.
>
> On the blog, it said proguard was used for the Avian Port.  This was for
> size, but was the xmlvm version also pre-run through Proguard?
>
> Here is some output, pass 1, from a desktop application.  Am noticing
> that staticized methods is part of process, which might not be helpful
> here.  Do not know if it can be turned off.  When Proguard is run against
> an Android app, some optimizations are disabled, but not that one.
>
> [proguard] Ignoring unused library classes...
> [proguard]   Original number of library classes: 19088
> [proguard]   Final number of library classes:    1048
> [proguard] Printing kept classes, fields, and methods...
>       ** Removed **
> [proguard] Shrinking...
> [proguard] Removing unused program classes and class elements...
> [proguard]   Original number of program classes: 1219
> [proguard]   Final number of program classes:    910
> [proguard] Inlining subroutines...
> [proguard] Optimizing...
> [proguard]   Number of finalized classes:                 462
> [proguard]   Number of vertically merged classes:         8
> [proguard]   Number of horizontally merged classes:       27
> [proguard]   Number of removed write-only fields:         221
> [proguard]   Number of privatized fields:                 1467
> [proguard]   Number of inlined constant fields:           58
> [proguard]   Number of privatized methods:                773
> [proguard]   Number of staticized methods:                199
> [proguard]   Number of finalized methods:                 6007
> [proguard]   Number of removed method parameters:         281
> [proguard]   Number of inlined constant parameters:       233
> [proguard]   Number of inlined constant return values:    50
> [proguard]   Number of inlined short method calls:        2348
> [proguard]   Number of inlined unique method calls:       1573
> [proguard]   Number of inlined tail recursion calls:      22
> [proguard]   Number of merged code blocks:                138
> [proguard]   Number of variable peephole optimizations:   8986
> [proguard]   Number of arithmetic peephole optimizations: 258
> [proguard]   Number of cast peephole optimizations:       251
> [proguard]   Number of field peephole optimizations:      49
> [proguard]   Number of branch peephole optimizations:     3766
> [proguard]   Number of string peephole optimizations:     1148
> [proguard]   Number of simplified instructions:           943
> [proguard]   Number of removed instructions:              6557
> [proguard]   Number of removed local variables:           1196
> [proguard]   Number of removed exception blocks:          470
> [proguard]   Number of optimized local variable frames:   3028
> [proguard] Shrinking...
> [proguard] Removing unused program classes and class elements...
> [proguard]   Original number of program classes: 910
> [proguard]   Final number of program classes:    869
>
>
> Jeff Palmer
> WhatIf Squared LLC
>
> On Dec 6, 2012, at 8:53 PM, xml...@li...<javascript:_e({}, 'cvml', 'xml...@li...');>wrote:
>
> *From: *Arno Puder <ar...@pu... <javascript:_e({}, 'cvml',
> 'ar...@pu...');>>
> *Subject: **Re: [xmlvm-users] One small XMLVM benchmark*
> *Date: *December 6, 2012 8:55:46 PM EST
> *To: *Steve Hannah <st...@we... <javascript:_e({}, 'cvml',
> 'st...@we...');>>
> *Cc: *"xml...@li... <javascript:_e({}, 'cvml',
> 'xml...@li...');>" <xml...@li...<javascript:_e({}, 'cvml', 'xml...@li...');>
> >
>
>
>
> well, allow me some remarks. As you already alluded to, performance
> testing is a tricky business. XMLVM cross-compiles to C code and by its
> very nature it cannot do hot-patching at runtime. This means that every
> static access to a class needs to check if that class was already
> initialized. If your application is mainly using static fields and methods
> (as did your original test case), XMLVM can't do many optimizations.
>
> XMLVM is far from being perfect, but it is doing a decent job. Mileage may
> vary depending on the details of an app. It is always a good idea to try
> different tools and pick the one that works best for you.
>
> Arno
>
>
>

-- 
Steve Hannah
Web Lite Solutions Corp.

Re: [xmlvm-users] One small XMLVM benchmark

[Steve H. <st...@we...>]

Ah... you clearly had some insight into how it works :)  Dramatically
different results when using object methods instead of static methods.

I have updated my blog post to incorporate these changes:

http://sjhannah.com/blog/?p=226

The results were (with the same n=30, move from pole 1 to pole 3):

XMLVM: 40.2 seconds
Avian: 77.4 seconds

In this case, XMLVM is getting very close to the performance of the native
C function calls.

Just for fun I also created an Objective-C version using message passing
rather than C functions and, not surprisingly, it was dramatically slower
at around 154 seconds.


Obviously we can't read too much into these narrow benchmarks, but it is
good to know how close to native performance XMLVM can get.


-Steve



On Thu, Dec 6, 2012 at 3:45 PM, Steve Hannah <st...@we...> wrote:

> Will do.  I'll post the result when I have it.
>
> Steve
>
>
> On Thursday, December 6, 2012, Arno Puder wrote:
>
>>
>> just out of curiosity, could you please change your test and make method
>> "move()" and variable "counter" of your class "TowersOfHanoi" not
>> static? I'd be interested in the numbers when you make that change.
>>
>> Thanks,
>> Arno
>>
>>
>> On 12/6/12 2:59 PM, Steve Hannah wrote:
>> > Just a small update.  As it turns out, my first benchmark was flawed
>> > because it allowed GCC/LLVM to optimize it more than was fair.  After
>> > revising the algorithm to force GCC/LLVM to play by the rules I found
>> > that Avian edged out XMLVM by about 15% in speed.  They were both slower
>> > than the native C implementation by a factor of about 2.
>> >
>> > This doesn't change, at all, my overall impression that XMLVM is quite
>> > fast and that the potential is very far reaching.
>> >
>> > I wrote about the revised benchmarks on my blog at
>> > http://sjhannah.com/blog/?p=226
>> >
>> > Keep up the great work!
>> >
>> > -Steve
>> >
>> > On Thu, Dec 6, 2012 at 10:20 AM, Paul Poley <bay...@gm...
>> > <mailto:bay...@gm...>> wrote:
>> >
>> >     Interesting news.  Nice write up!
>> >
>> >     Paul
>> >
>> >     On Mon, Dec 3, 2012 at 12:15 PM, Steve Hannah <st...@we...
>> >     <mailto:st...@we...>> wrote:
>> >
>> >         I just wanted to drop a line into this list to thank you guys
>> >         for your work.  I have been playing around with CodenameOne
>> >         recently to try to build a port that runs on Avian (an AOT java
>> >         compiler) because I had a hunch that it would be faster than the
>> >         code produced by XMLVM (which is their default solution for
>> iOS).
>> >
>> >         I was wrong.  Running a simple test on the Towers of Hanoi
>> >         problem on an app that was built separately using XMLVM and
>> >         Avian I found that the XMLVM build was actually slightly faster
>> >         than the Avian AOT compiled binary.
>> >
>> >         I wrote about my experiment in my blog at
>> >         http://sjhannah.com/blog/?p=225
>> >
>> >         Anyways.  Incredible work.  The potential of this project is
>> >         quite far-reaching.
>> >
>> >         -Steve
>> >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> >         Keep yourself connected to Go Parallel:
>> >         BUILD Helping you discover the best ways to construct your
>> >         parallel projects.
>> >         http://goparallel.sourceforge.net
>> >         _______________________________________________
>> >         xmlvm-users mailing list
>> >         xml...@li...
>> >         <mailto:xml...@li...>
>> >         https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Steve Hannah
>> > Web Lite Solutions Corp.
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> > Remotely access PCs and mobile devices and provide instant support
>> > Improve your efficiency, and focus on delivering more value-add services
>> > Discover what IT Professionals Know. Rescue delivers
>> > http://p.sf.net/sfu/logmein_12329d2d
>> >
>> >
>> >
>> > _______________________________________________
>> > xmlvm-users mailing list
>> > xml...@li...
>> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>
>
> --
> Steve Hannah
> Web Lite Solutions Corp.
>
>


-- 
Steve Hannah
Web Lite Solutions Corp.

Re: [xmlvm-users] One small XMLVM benchmark

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

well, allow me some remarks. As you already alluded to, performance 
testing is a tricky business. XMLVM cross-compiles to C code and by its 
very nature it cannot do hot-patching at runtime. This means that every 
static access to a class needs to check if that class was already 
initialized. If your application is mainly using static fields and 
methods (as did your original test case), XMLVM can't do many optimizations.

XMLVM is far from being perfect, but it is doing a decent job. Mileage 
may vary depending on the details of an app. It is always a good idea to 
try different tools and pick the one that works best for you.

Arno


On 12/06/2012 05:47 PM, Steve Hannah wrote:
> Ah... you clearly had some insight into how it works :)  Dramatically
> different results when using object methods instead of static methods.
>
> I have updated my blog post to incorporate these changes:
>
> http://sjhannah.com/blog/?p=226
>
> The results were (with the same n=30, move from pole 1 to pole 3):
>
> XMLVM: 40.2 seconds
> Avian: 77.4 seconds
>
> In this case, XMLVM is getting very close to the performance of the
> native C function calls.
>
> Just for fun I also created an Objective-C version using message passing
> rather than C functions and, not surprisingly, it was dramatically
> slower at around 154 seconds.
>
>
> Obviously we can't read too much into these narrow benchmarks, but it is
> good to know how close to native performance XMLVM can get.
>
>
> -Steve
>
>
>
> On Thu, Dec 6, 2012 at 3:45 PM, Steve Hannah <st...@we...
> <mailto:st...@we...>> wrote:
>
>     Will do.  I'll post the result when I have it.
>
>     Steve
>
>
>     On Thursday, December 6, 2012, Arno Puder wrote:
>
>
>         just out of curiosity, could you please change your test and
>         make method
>         "move()" and variable "counter" of your class "TowersOfHanoi" not
>         static? I'd be interested in the numbers when you make that change.
>
>         Thanks,
>         Arno
>
>
>         On 12/6/12 2:59 PM, Steve Hannah wrote:
>          > Just a small update.  As it turns out, my first benchmark was
>         flawed
>          > because it allowed GCC/LLVM to optimize it more than was
>         fair.  After
>          > revising the algorithm to force GCC/LLVM to play by the rules
>         I found
>          > that Avian edged out XMLVM by about 15% in speed.  They were
>         both slower
>          > than the native C implementation by a factor of about 2.
>          >
>          > This doesn't change, at all, my overall impression that XMLVM
>         is quite
>          > fast and that the potential is very far reaching.
>          >
>          > I wrote about the revised benchmarks on my blog at
>          > http://sjhannah.com/blog/?p=226
>          >
>          > Keep up the great work!
>          >
>          > -Steve
>          >
>          > On Thu, Dec 6, 2012 at 10:20 AM, Paul Poley <bay...@gm...
>          > <mailto:bay...@gm...>> wrote:
>          >
>          >     Interesting news.  Nice write up!
>          >
>          >     Paul
>          >
>          >     On Mon, Dec 3, 2012 at 12:15 PM, Steve Hannah
>         <st...@we...
>          >     <mailto:st...@we...>> wrote:
>          >
>          >         I just wanted to drop a line into this list to thank
>         you guys
>          >         for your work.  I have been playing around with
>         CodenameOne
>          >         recently to try to build a port that runs on Avian
>         (an AOT java
>          >         compiler) because I had a hunch that it would be
>         faster than the
>          >         code produced by XMLVM (which is their default
>         solution for iOS).
>          >
>          >         I was wrong.  Running a simple test on the Towers of
>         Hanoi
>          >         problem on an app that was built separately using
>         XMLVM and
>          >         Avian I found that the XMLVM build was actually
>         slightly faster
>          >         than the Avian AOT compiled binary.
>          >
>          >         I wrote about my experiment in my blog at
>          > http://sjhannah.com/blog/?p=225
>          >
>          >         Anyways.  Incredible work.  The potential of this
>         project is
>          >         quite far-reaching.
>          >
>          >         -Steve
>          >
>          >
>          >
>          >
>          >
>         ------------------------------------------------------------------------------
>          >         Keep yourself connected to Go Parallel:
>          >         BUILD Helping you discover the best ways to construct
>         your
>          >         parallel projects.
>          > http://goparallel.sourceforge.net
>          >         _______________________________________________
>          >         xmlvm-users mailing list
>          > xml...@li...
>          >         <mailto:xml...@li...>
>          > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>          >
>          >
>          >
>          >
>          >
>          > --
>          > Steve Hannah
>          > Web Lite Solutions Corp.
>          >
>          >
>          >
>          >
>         ------------------------------------------------------------------------------
>          > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free
>         Trial
>          > Remotely access PCs and mobile devices and provide instant
>         support
>          > Improve your efficiency, and focus on delivering more
>         value-add services
>          > Discover what IT Professionals Know. Rescue delivers
>          > http://p.sf.net/sfu/logmein_12329d2d
>          >
>          >
>          >
>          > _______________________________________________
>          > xmlvm-users mailing list
>          > xml...@li...
>          > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>          >
>
>         ------------------------------------------------------------------------------
>         LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>         Remotely access PCs and mobile devices and provide instant support
>         Improve your efficiency, and focus on delivering more value-add
>         services
>         Discover what IT Professionals Know. Rescue delivers
>         http://p.sf.net/sfu/logmein_12329d2d
>         _______________________________________________
>         xmlvm-users mailing list
>         xml...@li...
>         https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>     --
>     Steve Hannah
>     Web Lite Solutions Corp.
>
>
>
>
> --
> Steve Hannah
> Web Lite Solutions Corp.
>

Re: [xmlvm-users] One small XMLVM benchmark

[Steve H. <st...@we...>]

Will do.  I'll post the result when I have it.

Steve

On Thursday, December 6, 2012, Arno Puder wrote:

>
> just out of curiosity, could you please change your test and make method
> "move()" and variable "counter" of your class "TowersOfHanoi" not
> static? I'd be interested in the numbers when you make that change.
>
> Thanks,
> Arno
>
>
> On 12/6/12 2:59 PM, Steve Hannah wrote:
> > Just a small update.  As it turns out, my first benchmark was flawed
> > because it allowed GCC/LLVM to optimize it more than was fair.  After
> > revising the algorithm to force GCC/LLVM to play by the rules I found
> > that Avian edged out XMLVM by about 15% in speed.  They were both slower
> > than the native C implementation by a factor of about 2.
> >
> > This doesn't change, at all, my overall impression that XMLVM is quite
> > fast and that the potential is very far reaching.
> >
> > I wrote about the revised benchmarks on my blog at
> > http://sjhannah.com/blog/?p=226
> >
> > Keep up the great work!
> >
> > -Steve
> >
> > On Thu, Dec 6, 2012 at 10:20 AM, Paul Poley <bay...@gm...<javascript:;>
> > <mailto:bay...@gm... <javascript:;>>> wrote:
> >
> >     Interesting news.  Nice write up!
> >
> >     Paul
> >
> >     On Mon, Dec 3, 2012 at 12:15 PM, Steve Hannah <st...@we...<javascript:;>
> >     <mailto:st...@we... <javascript:;>>> wrote:
> >
> >         I just wanted to drop a line into this list to thank you guys
> >         for your work.  I have been playing around with CodenameOne
> >         recently to try to build a port that runs on Avian (an AOT java
> >         compiler) because I had a hunch that it would be faster than the
> >         code produced by XMLVM (which is their default solution for iOS).
> >
> >         I was wrong.  Running a simple test on the Towers of Hanoi
> >         problem on an app that was built separately using XMLVM and
> >         Avian I found that the XMLVM build was actually slightly faster
> >         than the Avian AOT compiled binary.
> >
> >         I wrote about my experiment in my blog at
> >         http://sjhannah.com/blog/?p=225
> >
> >         Anyways.  Incredible work.  The potential of this project is
> >         quite far-reaching.
> >
> >         -Steve
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >         Keep yourself connected to Go Parallel:
> >         BUILD Helping you discover the best ways to construct your
> >         parallel projects.
> >         http://goparallel.sourceforge.net
> >         _______________________________________________
> >         xmlvm-users mailing list
> >         xml...@li... <javascript:;>
> >         <mailto:xml...@li... <javascript:;>>
> >         https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >
> >
> >
> >
> >
> > --
> > Steve Hannah
> > Web Lite Solutions Corp.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> >
> >
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li... <javascript:;>
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xmlvm-users mailing list
> xml...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>


-- 
Steve Hannah
Web Lite Solutions Corp.

Re: [xmlvm-users] One small XMLVM benchmark

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

just out of curiosity, could you please change your test and make method 
"move()" and variable "counter" of your class "TowersOfHanoi" not 
static? I'd be interested in the numbers when you make that change.

Thanks,
Arno


On 12/6/12 2:59 PM, Steve Hannah wrote:
> Just a small update.  As it turns out, my first benchmark was flawed
> because it allowed GCC/LLVM to optimize it more than was fair.  After
> revising the algorithm to force GCC/LLVM to play by the rules I found
> that Avian edged out XMLVM by about 15% in speed.  They were both slower
> than the native C implementation by a factor of about 2.
>
> This doesn't change, at all, my overall impression that XMLVM is quite
> fast and that the potential is very far reaching.
>
> I wrote about the revised benchmarks on my blog at
> http://sjhannah.com/blog/?p=226
>
> Keep up the great work!
>
> -Steve
>
> On Thu, Dec 6, 2012 at 10:20 AM, Paul Poley <bay...@gm...
> <mailto:bay...@gm...>> wrote:
>
>     Interesting news.  Nice write up!
>
>     Paul
>
>     On Mon, Dec 3, 2012 at 12:15 PM, Steve Hannah <st...@we...
>     <mailto:st...@we...>> wrote:
>
>         I just wanted to drop a line into this list to thank you guys
>         for your work.  I have been playing around with CodenameOne
>         recently to try to build a port that runs on Avian (an AOT java
>         compiler) because I had a hunch that it would be faster than the
>         code produced by XMLVM (which is their default solution for iOS).
>
>         I was wrong.  Running a simple test on the Towers of Hanoi
>         problem on an app that was built separately using XMLVM and
>         Avian I found that the XMLVM build was actually slightly faster
>         than the Avian AOT compiled binary.
>
>         I wrote about my experiment in my blog at
>         http://sjhannah.com/blog/?p=225
>
>         Anyways.  Incredible work.  The potential of this project is
>         quite far-reaching.
>
>         -Steve
>
>
>
>
>         ------------------------------------------------------------------------------
>         Keep yourself connected to Go Parallel:
>         BUILD Helping you discover the best ways to construct your
>         parallel projects.
>         http://goparallel.sourceforge.net
>         _______________________________________________
>         xmlvm-users mailing list
>         xml...@li...
>         <mailto:xml...@li...>
>         https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
>
> --
> Steve Hannah
> Web Lite Solutions Corp.
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] One small XMLVM benchmark

[Steve H. <st...@we...>]

On Thursday, December 6, 2012, Steve Hannah wrote:

> Optimizations were on for both.  The problem is that the original test
> didn't modify anything outside the function so the optimization could
> potentially be reduced down to NOOP with gcc.
>
> I needed to change the test case so that it modified something outside
> itself so the code actually had to be run.
>
> Avian doesn't have all the optimizations that gcc has so it wasn't able to
> "cheat" at all in the first test.  It ran the benchmark faithfully.
>
> That said, the xmlvm version didn't cheat much either, compared to the
> native c version.
>
> Steve
>
> On Thursday, December 6, 2012, Panayotis Katsaloulis wrote:
>
>> What if you turn on optimizations for both test cases?
>>
>> If one supports full optimizations (and is much more faster) than the
>> other - although it might sound unfair - the final result is that one is
>> faster and the other is not.
>> At the end of the day, nobody cares about all the transformations the
>> code has to pass - the only important thing is the final execution speed.
>>
>>
>> On Fri, Dec 7, 2012 at 12:59 AM, Steve Hannah <st...@we...> wrote:
>>
>>> Just a small update.  As it turns out, my first benchmark was flawed
>>> because it allowed GCC/LLVM to optimize it more than was fair.  After
>>> revising the algorithm to force GCC/LLVM to play by the rules I found that
>>> Avian edged out XMLVM by about 15% in speed.  They were both slower than
>>> the native C implementation by a factor of about 2.
>>>
>>> This doesn't change, at all, my overall impression that XMLVM is quite
>>> fast and that the potential is very far reaching.
>>>
>>> I wrote about the revised benchmarks on my blog at
>>> http://sjhannah.com/blog/?p=226
>>>
>>> Keep up the great work!
>>>
>>> -Steve
>>>
>>> On Thu, Dec 6, 2012 at 10:20 AM, Paul Poley <bay...@gm...>wrote:
>>>
>>>> Interesting news.  Nice write up!
>>>>
>>>> Paul
>>>>
>>>> On Mon, Dec 3, 2012 at 12:15 PM, Steve Hannah <st...@we...> wrote:
>>>>
>>>>> I just wanted to drop a line into this list to thank you guys for your
>>>>> work.  I have been playing around with CodenameOne recently to try to build
>>>>> a port that runs on Avian (an AOT java compiler) because I had a hunch that
>>>>> it would be faster than the code produced by XMLVM (which is their default
>>>>> solution for iOS).
>>>>>
>>>>> I was wrong.  Running a simple test on the Towers of Hanoi problem on
>>>>> an app that was built separately using XMLVM and Avian I found that the
>>>>> XMLVM build was actually slightly faster than the Avian AOT compiled binary.
>>>>>
>>>>> I wrote about my experiment in my blog at
>>>>> http://sjhannah.com/blog/?p=225
>>>>>
>>>>> Anyways.  Incredible work.  The potential of this project is quite
>>>>> far-reaching.
>>>>>
>>>>> -Steve
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Keep yourself connected to Go Parallel:
>>>>> BUILD Helping you discover the best ways to construct your parallel
>>>>> projects.
>>>>> http://goparallel.sourceforge.net
>>>>> _______________________________________________
>>>>> xmlvm-users mailing list
>>>>> xml...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Steve Hannah
>>> Web Lite Solutions Corp.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>> Remotely access PCs and mobile devices and provide instant support
>>> Improve your efficiency, and focus on delivering more value-add services
>>> Discover what IT Professionals Know. Rescue delivers
>>> http://p.sf.net/sfu/logmein_12329d2d
>>> _______________________________________________
>>> xmlvm-users mailing list
>>> xml...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>>
>>>
>>
>>
>> --
>> Panayotis Katsaloulis
>>
>>
>
> --
> Steve Hannah
> Web Lite Solutions Corp.
>
>

-- 
Steve Hannah
Web Lite Solutions Corp.

Re: [xmlvm-users] One small XMLVM benchmark

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

What if you turn on optimizations for both test cases?

If one supports full optimizations (and is much more faster) than the other
- although it might sound unfair - the final result is that one is faster
and the other is not.
At the end of the day, nobody cares about all the transformations the code
has to pass - the only important thing is the final execution speed.


On Fri, Dec 7, 2012 at 12:59 AM, Steve Hannah <st...@we...> wrote:

> Just a small update.  As it turns out, my first benchmark was flawed
> because it allowed GCC/LLVM to optimize it more than was fair.  After
> revising the algorithm to force GCC/LLVM to play by the rules I found that
> Avian edged out XMLVM by about 15% in speed.  They were both slower than
> the native C implementation by a factor of about 2.
>
> This doesn't change, at all, my overall impression that XMLVM is quite
> fast and that the potential is very far reaching.
>
> I wrote about the revised benchmarks on my blog at
> http://sjhannah.com/blog/?p=226
>
> Keep up the great work!
>
> -Steve
>
> On Thu, Dec 6, 2012 at 10:20 AM, Paul Poley <bay...@gm...> wrote:
>
>> Interesting news.  Nice write up!
>>
>> Paul
>>
>> On Mon, Dec 3, 2012 at 12:15 PM, Steve Hannah <st...@we...> wrote:
>>
>>> I just wanted to drop a line into this list to thank you guys for your
>>> work.  I have been playing around with CodenameOne recently to try to build
>>> a port that runs on Avian (an AOT java compiler) because I had a hunch that
>>> it would be faster than the code produced by XMLVM (which is their default
>>> solution for iOS).
>>>
>>> I was wrong.  Running a simple test on the Towers of Hanoi problem on an
>>> app that was built separately using XMLVM and Avian I found that the XMLVM
>>> build was actually slightly faster than the Avian AOT compiled binary.
>>>
>>> I wrote about my experiment in my blog at
>>> http://sjhannah.com/blog/?p=225
>>>
>>> Anyways.  Incredible work.  The potential of this project is quite
>>> far-reaching.
>>>
>>> -Steve
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Keep yourself connected to Go Parallel:
>>> BUILD Helping you discover the best ways to construct your parallel
>>> projects.
>>> http://goparallel.sourceforge.net
>>> _______________________________________________
>>> xmlvm-users mailing list
>>> xml...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>>
>>>
>>
>
>
> --
> Steve Hannah
> Web Lite Solutions Corp.
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>


-- 
Panayotis Katsaloulis

Re: [xmlvm-users] One small XMLVM benchmark

[Steve H. <st...@we...>]

Just a small update.  As it turns out, my first benchmark was flawed
because it allowed GCC/LLVM to optimize it more than was fair.  After
revising the algorithm to force GCC/LLVM to play by the rules I found that
Avian edged out XMLVM by about 15% in speed.  They were both slower than
the native C implementation by a factor of about 2.

This doesn't change, at all, my overall impression that XMLVM is quite fast
and that the potential is very far reaching.

I wrote about the revised benchmarks on my blog at
http://sjhannah.com/blog/?p=226

Keep up the great work!

-Steve

On Thu, Dec 6, 2012 at 10:20 AM, Paul Poley <bay...@gm...> wrote:

> Interesting news.  Nice write up!
>
> Paul
>
> On Mon, Dec 3, 2012 at 12:15 PM, Steve Hannah <st...@we...> wrote:
>
>> I just wanted to drop a line into this list to thank you guys for your
>> work.  I have been playing around with CodenameOne recently to try to build
>> a port that runs on Avian (an AOT java compiler) because I had a hunch that
>> it would be faster than the code produced by XMLVM (which is their default
>> solution for iOS).
>>
>> I was wrong.  Running a simple test on the Towers of Hanoi problem on an
>> app that was built separately using XMLVM and Avian I found that the XMLVM
>> build was actually slightly faster than the Avian AOT compiled binary.
>>
>> I wrote about my experiment in my blog at http://sjhannah.com/blog/?p=225
>>
>> Anyways.  Incredible work.  The potential of this project is quite
>> far-reaching.
>>
>> -Steve
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel:
>> BUILD Helping you discover the best ways to construct your parallel
>> projects.
>> http://goparallel.sourceforge.net
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>>
>


-- 
Steve Hannah
Web Lite Solutions Corp.

[xmlvm-users] One small XMLVM benchmark

[Steve H. <st...@we...>]

I just wanted to drop a line into this list to thank you guys for your
work.  I have been playing around with CodenameOne recently to try to build
a port that runs on Avian (an AOT java compiler) because I had a hunch that
it would be faster than the code produced by XMLVM (which is their default
solution for iOS).

I was wrong.  Running a simple test on the Towers of Hanoi problem on an
app that was built separately using XMLVM and Avian I found that the XMLVM
build was actually slightly faster than the Avian AOT compiled binary.

I wrote about my experiment in my blog at http://sjhannah.com/blog/?p=225

Anyways.  Incredible work.  The potential of this project is quite
far-reaching.

-Steve

Re: [xmlvm-users] Using CoreGraphics

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

the C backend has two different versions of the iOS classes:

1. classes in package org.xmlvm.iphone.*: these classes are used by 
default when using the C backend. The Java classes in that package and 
their matching C wrapper implementations were written by hand.

2. classes in package org.xmlvm.ios.*: these classes can be used with 
the C backend. In this case you need to invoke XMLVM with 
--xmlvm-new-ios-api. The big difference of the org.xmlvm.ios.* package 
is that its classes and matching C wrapper implementations were 
generated by a tool and not written by hand. Check out 
xmlvm/trunk/crossmobile. This project can parse the original Objective-C 
header files contained in the iOS SDK and generate the Java classes as 
well as the C wrappers.

Arno


On 11/18/12 7:28 AM, Kurayami Tenshi wrote:
> Hi there
>
> What's the difference between org.xmlvm.ios.UIImage and
> org.xmlvm.iphone.UIImage? If I use the ios version, XCode won't be able
> to compile the project.
>
> The main thing I want to do is this: Load an image using CoreGraphics.
> While using the UIImage from iphone package works, CoreGraphics gives me
> the same types of errors too:
>
> XCode says:
> org_xmlvm_iosNSURLResponse.m
> LLVM GCC 4.2 error:
> struct <anonymous> ......... etc etc
>
> Why is this so?
> I'm compiling the project in C rather than Objective C. Is that a
> possible reason?
>
> How do I fix this?
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

[xmlvm-users] Using CoreGraphics

[Kurayami T. <kur...@gm...>]

Hi there

What's the difference between org.xmlvm.ios.UIImage and
org.xmlvm.iphone.UIImage? If I use the ios version, XCode won't be able to
compile the project.

The main thing I want to do is this: Load an image using CoreGraphics.
While using the UIImage from iphone package works, CoreGraphics gives me
the same types of errors too:

XCode says:
org_xmlvm_iosNSURLResponse.m
LLVM GCC 4.2 error:
struct <anonymous> ......... etc etc

Why is this so?
I'm compiling the project in C rather than Objective C. Is that a possible
reason?

How do I fix this?

Re: [xmlvm-users] Error building demos

[Markus N. <mar...@gm...>]

Hi,

Android cross-compilation is still supported but we deprecated the
Objective-C backend. We cross-compile to C instead now.
Someone must have forgotten to change this in all demos. I commited a fix
for it and you should now be able to run "ant demos"
again after you update.

Cheers,
Markus


On Tue, Nov 13, 2012 at 11:19 AM, Kristján Bjarni Guðmundsson <
kri...@gm...> wrote:

>
> I downloaded fresh from source and followed the documentation, but I get
> this error when doing "ant demos":
>
> -xproject-create:
>      [echo] Creating Xcode project with the Objective C backend.
>      [java] Error: The ObjC-based Android to iPhone conversion is no
> longer supported.
>
> So are you scrapping Android conversions totally? What was the last
> version that supported Android?
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

[xmlvm-users] Error building demos

[Kristján B. G. <kri...@gm...>]

I downloaded fresh from source and followed the documentation, but I get
this error when doing "ant demos":

-xproject-create:
     [echo] Creating Xcode project with the Objective C backend.
     [java] Error: The ObjC-based Android to iPhone conversion is no longer
supported.

So are you scrapping Android conversions totally? What was the last version
that supported Android?

Re: [xmlvm-users] Missing AbstractPreferences & Checksum with --target=csharp

[Oren <or...@gm...>]

hi Jun,
not sure if this solves your issues, but you could try
"/define:CONSOLE" - adding this option to your c# compiler could
remove some redundant dependencies for simple things like hello world in java.
//oren

On Sun, Oct 14, 2012 at 1:05 PM, Jun Lee <jun...@gm...> wrote:
> Hello,
> Does anyone know how to solve the missing references to
> java.util.prefs.AbstractPreferences and java.util.zip.Checksum when cross
> compiling with the csharp target?
> Even when I cross compile a simple Java Hello.class to C#, I still get these
> errors from the csharp compiler (Mono).
> I tried to add the AbstractPreferences*.class and Checksum.class to the
> cross compiled set, but that gives a lot of errors for uninplemented
> interface/abstract methods.
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Missing AbstractPreferences & Checksum with --target=csharp

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

these classes are not on the red list and are contained in harmony.jar, 
so the dependency analysis should pull them in. Not sure what the 
problem is.

Arno


On 10/14/12 1:05 PM, Jun Lee wrote:
> Hello,
> Does anyone know how to solve the missing references to
> java.util.prefs.AbstractPreferences and java.util.zip.Checksum when
> cross compiling with the csharp target?
> Even when I cross compile a simple Java Hello.class to C#, I still get
> these errors from the csharp compiler (Mono).
> I tried to add the AbstractPreferences*.class and Checksum.class to the
> cross compiled set, but that gives a lot of errors for uninplemented
> interface/abstract methods.
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

[xmlvm-users] Missing AbstractPreferences & Checksum with --target=csharp

[Jun L. <jun...@gm...>]

Hello,
Does anyone know how to solve the missing references to
java.util.prefs.AbstractPreferences and java.util.zip.Checksum when cross
compiling with the csharp target?
Even when I cross compile a simple Java Hello.class to C#, I still get
these errors from the csharp compiler (Mono).
I tried to add the AbstractPreferences*.class and Checksum.class to the
cross compiled set, but that gives a lot of errors for uninplemented
interface/abstract methods.

[xmlvm-users] Incremental Conversions and Best Practices

[<ju...@ed...>]

(sorry for posting again....it seems my original post ended up in  
another thread (maybe I Replied instead of Posted last time...))

I am seeking some advice on how best to prepare our Android -> iOS  
conversion(s).
We want to minimize effort and risk.

I would like to create a **known good conversion** of each of the  
binary artifacts in our real-world situation.
Here is a good description of our binaries:

DESCRIPTION                     NOTES                                   
       	ARTIFACT
===========			=====                                        	========
External Library :                                                      
     	xstream-1.3.1-POS.jar
OurOwnCustomClasses_1 :         code that uses xstream ->			Custom_1.jar
OurOwnCustomClasses_2 :         other code ->                           
        	Custom_2.jar
OurOwnAPKLib :			Custom_1.jar + Custom_2.jar + xstream           Custom.apklib
OurOwnAPK :                     Custom.apklib + Android + AndroidDeriv  
       	Custom.apk

After trying a few times with the big-bang approach to "convert  
'Custom.apk' to 'Custom.iOS'", I realized that to make this actually  
work, i need to deal with each binary separately.
In the big bang approach I got errors like:
<quote>
-xproject-create:
    [delete] Deleting directory /POC-1/build/.xcode
      [echo] Creating Xcode project with the C backend.
      [java] [09/17/12 10:29:09.620]    ERROR: Couldn't create node  
for com.thoughtworks.xstream.XStream
      [java] [09/17/12 10:29:09.622]    ERROR: Couldn't create node  
for com.thoughtworks.xstream.XStream
      [java] [09/17/12 10:29:17.120]    ERROR: Vtable for  
com.thoughtworks.xstream.XStream not found!
      [java] [09/17/12 10:29:17.120]    ERROR: Vtable for  
com.thoughtworks.xstream.XStream not found!
</quote>

Now, I immediately started to think about breaking the work down bc  
XStream is a rather complicated library.

So, I attempted 2 conversions:
[1] xmlvm --in=xstream-1.3.1-POS.jar --target=xmlvm --out=xmlvm-output/xmlvm
[2] xmlvm --in=xstream-1.3.1-POS.jar --target=iphone --out=xmlvm-output/iphone

And, I got no errors in each case ! Nice !! Here is a summary of the  
generated contents:

xmlvm-output/xmlvm :
from 342 class files in the xstream jar we ended up with 343 .xmlvm files

xmlvm-output/iphone/build/xcode/src/app:
from 342 class files in the xstream jar we ended up with 684 files  
(342 .h and 342 .m)

So, the outputs look promising.
Of course, I do not not which artifacts are the ones I should consider  
using :)

So, my thought is to perform incremental xmlvm (and/or iphone) build  
working down the ARTIFACT list above.
This would mean that xmlvm executions would successively have an  
increasingly larger number of 'pre-compiled' inputs.
It also means I know where errors/issues are at the library level.
(We would probably manage the 'successful pre-compiled derivates' with  
Maven - as we do our Java outputs and dependencies.)

So, if you have experience of such an approach (not on the Maven side,  
we are ok with that), could you please advise me on how to structure  
my builds.
I am guessing that care would need to be taken so as to avoid  
duplicates, and as I do not understand the internals of  
dependency/input management in xmlvm, I would need advice specifically  
on this and how to create meaningful successive invocations of xmlvm.

Best Regards
Julian

[xmlvm-users] Best Practice and Incremental Conversions

[<ju...@ed...>]

I am seeking some advice on how best to prepare our Android -> iOS  
conversion(s).
We want to minimize effort and risk.

I would like to create a **known good conversion** of each of the  
binary artifacts in our real-world situation.
Here is a good description of our binaries:

DESCRIPTION			NOTES					ARTIFACT
===========			=====					========
External Library : 							xstream-1.3.1-POS.jar
OurOwnCustomClasses_1 : 	code that uses xstream -> 		Custom_1.jar
OurOwnCustomClasses_2 : 	other code -> 				Custom_2.jar
OurOwnAPKLib :			Custom_1.jar + Custom_2.jar		Custom.apklib
OurOwnAPK :			Custom.apklib + Android + AndroidDeriv	Custom.apk

After trying a few times with the big-bang approach to "convert  
'Custom.apk' to 'Custom.iOS'", I realized that to make this actually  
work, i need to deal with each binary separately.
In the big bang approach I got errors like:
<quote>
-xproject-create:
    [delete] Deleting directory /POC-1/build/.xcode
      [echo] Creating Xcode project with the C backend.
      [java] [09/17/12 10:29:09.620]    ERROR: Couldn't create node  
for com.thoughtworks.xstream.XStream
      [java] [09/17/12 10:29:09.622]    ERROR: Couldn't create node  
for com.thoughtworks.xstream.XStream
      [java] [09/17/12 10:29:17.120]    ERROR: Vtable for  
com.thoughtworks.xstream.XStream not found!
      [java] [09/17/12 10:29:17.120]    ERROR: Vtable for  
com.thoughtworks.xstream.XStream not found!
</quote>

Now, I immediately started to think about breaking the work down bc  
XStream is a rather complicated library.

So, I attempted 2 conversions:
[1] xmlvm --in=xstream-1.3.1-POS.jar --target=xmlvm --out=xmlvm-output/xmlvm
[2] xmlvm --in=xstream-1.3.1-POS.jar --target=iphone --out=xmlvm-output/iphone

And, I got no errors in each case ! Nice !! Here is a summary of the  
generated contents:

xmlvm-output/xmlvm :
from 342 class files in the xstream jar we ended up with 343 .xmlvm files

xmlvm-output/iphone/build/xcode/src/app:
from 342 class files in the xstream jar we ended up with 684 files  
(342 .h and 342 .m)

So, the outputs look promising.
Of course, I do not not which artifacts are the ones I should consider  
using :)

So, my thought is to perform incremental xmlvm (and/or iphone) build  
working down the ARTIFACT list above.
This would mean that xmlvm executions would successively have an  
increasingly larger number of 'pre-compiled' inputs.
It also means I know where errors/issues are at the library level.
(We would probably manage the 'successful pre-compiled derivates' with  
Maven - as we do our Java outputs and dependencies.)

So, if you have experience of such an approach (not on the Maven side,  
we are ok with that), could you please advise me on how to structure  
my builds.
I am guessing that care would need to be taken so as to avoid  
duplicates, and as I do not understand the internals of  
dependency/input management in xmlvm, I would need advice specifically  
on this and how to create meninful successive invocations of xmlvm.

Best Regards
Julian

[xmlvm-users] Problem with Tutorial

[John T. <joh...@ho...>]

Hi All, 

  Thanks Markus and Nikolai for the last reply.

  I followed the tutorial, got it to compile using Eclipse, generated the Xcode files and manage to have a successful Build.

 However, when I run the application I got the following error:

Exception in thread "main" java.lang.Error: Unresolved compilation problem: 

Also I would like to, instead of compiling the Helloworld into an application, compile it into a dylib.

How may I do so?

Many Thanks,

John

Re: [xmlvm-users] java.net.InetAddress

[Markus N. <mar...@gm...>]

Hi,

The specific method you're trying to use isn't implemented in xmlvm yet.
You'd have to implement it in
src/xmlvm2c/lib/native/native_java_net_InetAddress.c by using appropriate
native API.
Another method in this file (getHostByAddrImpl) is already implemented so
it should be fairly straightforward to implement getHostByNameImpl.

Markus

On Fri, Sep 7, 2012 at 8:54 PM, Anson Tai <an...@mo...> wrote:

> Hi,Folks.,
>
>    I am using new ios api
>
>    and when running the app, it shows the message ,
>
>
> *XMLVM Error: Unimplemented native method:
> (java_net_InetAddress_getHostByNameImpl___java_lang_String_boolean):/Users/netmeeting/svn_repository/xmlvm/trunk/xmlvm/demo/iphone/RoomBooking/dist/../build/xcode/src/app/native_java_net_InetAddress.m:82
> *
>
> java code ,
>
> URL url = new URL("http://xxx.xxx.xxxx.xxx/......");   //where it returns
> json
>
>   URLConnection tc = url.openConnection();
>
>   BufferedReader in = new BufferedReader(new InputStreamReader(
>
>                  tc.getInputStream(), "UTF-8"));
>
>
> --
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>