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

Re: [xmlvm-users] Java to C and the other way around

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

On 06 Σεπ 2010, at 4:33 μ.μ., Leo Izen wrote:

> I know, given the new C back-end, conversion from Java to C will be easy. (run javac, then xmlvm.jar). Would it be possible to go the other way around? I looked at C2J converter, and that didn't work very well for me, and I am not paying money for code conversion. Would it be possible to do that?



Although the "not paying money to do my work" is a philosophy I don't agree with, anyways here is a solution to your problem:

http://nestedvm.ibex.org/

[xmlvm-users] Java to C and the other way around

[Leo I. <leo...@gm...>]

I know, given the new C back-end, conversion from Java to C will be easy.
(run javac, then xmlvm.jar). Would it be possible to go the other way
around? I looked at C2J converter, and that didn't work very well for me,
and I am not paying money for code conversion. Would it be possible to do
that?

[xmlvm-users] xmlvm toolchain question

[Andrew d. <de...@ao...>]

  I'm interested in converting Android apps to C and make use of other 
toolkit(s) for the
final target but not to the iPhone platform, and am trying to understand 
the process involved.

I believe I would need to reimplement or at least modify the code in 
Android2iphone/
to handle the needed classes supported in an Android application.  In 
looking at this
code, it appears often based on the code in the Android SDK 1.6.  Is the 
idea to start
with the needed classes as found there and modify them as needed?  (And, 
how does this
code base incorporate new changes from the Android SDK, ie - in the new 
Froyo update,
bug fixes...)

Once the code is converted to C, I would need an additional interface 
library to link to the
target toolkit much as is found in xmlvm2objc/compat-lib/objc/.

Is this the general approach?  Is there documentation that more clearly 
defines how XMLVM
can be targeted at other configurations than the iPhone and how it will 
be working once
the objc support is replaced by the C support?

Re: [xmlvm-users] Java shrinkers

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

I have used Proguard, and it definitely can delete things below Class level,
so I am not sure what you mean about method-level optimizations.

If you add the '-printusage filename' to your config or Ant build.xml you
can see everything removed.  A class name by itself means the whole class
was delete.  If it is followed by a colon, only the stuff below was removed
along with line numbers, e.g.

myNamespace.com.stuff.morestuff.CurrentPlatform:
    public static final byte SERVER_PLATFORM
    public static final byte DESKTOP_PLATFORM
    public static final byte PHONE_PLATFORM
    32:32:public static boolean isServer()
    34:34:public static boolean isPhone()
    39:39:public static boolean isValidPlatform(byte)
    40:40:public static boolean isValidClientPlatform(byte)

It also does much optimization in the methods themselves.  Probably the one
that should be of most interest to you is method in-lining. Sounds like you
only want to do this when the space penalty is very low.  This can be
adjusted using system properties, only documented within Proguard's source
code.

The package to look at is proguard.optimize.peephole .  The Class is
MethodInliner.  You will see that there are 2 properties consulted for the
maximum resulting code length to decide if it should be done.  One for J2SE
& the other for J2ME.  Specifying a lower value for the J2SE version might
help.  Looking through the source of this entire directory for other system
properties may also be good.

I know of another way to get the size down, but think they are going to be
sort of "empty calories".  Here it is just in case:
use option '-repackageclasses ${single-package}'.  Use something like
'<property name="single-package" value="_"/>

Hope this helps


On 8/31/10 5:07 PM, "Panayotis Katsaloulis" <pan...@pa...> wrote:

> 
On 31 Αυγ 2010, at 8:44 μ.μ., Sascha Haeberling wrote:

> I am actually
> working on such an optimized call graph dependency optimizer, which should
> shrink down the whole compilation size.
> 
> In addition we will remove the
> need to compile classes that don't need to be compiled. E.g. all the JDK
> classes need to be compiled once and we can provide it to our users. These two
> measures should speed up compilation time a lot.
> 
> // Sascha

The problem
> has to do more with size, not time.
It is really easy to produce static
> libraries, and thus reduce compilation time to minimum.
The way it is done
> right now, though, is again object-level optimization - similar to what
> ProGuard does (and it does it extremely well - it is even able to deal with
> simple reflection cases).

The problem is with method-level optimizations.
> That is why I propose to investigate such methods. 

In which level is the
> optimization you are working
> on?
--------------------------------------------------------------------------
> ----
This SF.net Dev2Dev email is sponsored by:

Show off your parallel
> programming skills.
Enter the Intel(R) Threading Challenge
> 2010.
http://p.sf.net/sfu/intel-thread-sfd
___________________________________
> ____________
xmlvm-users mailing
> list
xml...@li...
https://lists.sourceforge.net/lists/lis
> tinfo/xmlvm-users

Re: [xmlvm-users] Android -> iPhone

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

sorry, but none of the Android classes you mentioned are supported by 
XMLVM. You can see all the classes that we support in 
xmlvm/src/android2iphone. If an Android class is missing in that 
directory, we don't support it. Of course that doesn't mean that support 
can be added. Patches are always welcome!  :-)

Arno


On 8/31/10 8:47 AM, tony obrien wrote:
> Hello ..
>
> XCode is telling me it cannot find a number of header files .. some examples include:
>
> android_app_PendingIntent.h
> android_telephony_SmsManager.h
> android_telephony_gsm_SmsMessage.h
>
> I scoured the XMLVM output of my android project and TRUNK folders but to no avail.
>
> If these actions in Android are not yet supported for conversion to iPhone and I missed that in the docs, then I apologize... I would appreciate a hint as to where this sort of stuff is in the XMLVM documentation.
>
>
> regards,
> tob
>
> Tony O'Brien
> Sourcecode, LLC
> 856.596.6644
> www.sourcecode-llc.com
> www.sourcecode-llc.com/tss
> www.sourcecode-llc.com/tssdonor
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Java shrinkers

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

As I explained, I am working on two things: Optimizing the amount of code
being pulled in as well as having things pre-compiled.

The first will reduce the size of the binary. The dependency analysis I
implemented a while a go is a very naive approach that pulls in all classes
and all their references, thus pulling in almost the complete JDK. It was
good for getting us started with the C backend. What I am currently working
on does the analysis on a Class::method level, which should reduce code size
significantly.

Stay tuned for updates around this this week, I will let you know when I
have something to try out.

// Sascha

On Tue, Aug 31, 2010 at 11:07 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On 31 Αυγ 2010, at 8:44 μ.μ., Sascha Haeberling wrote:
>
> > I am actually working on such an optimized call graph dependency
> optimizer, which should shrink down the whole compilation size.
> >
> > In addition we will remove the need to compile classes that don't need to
> be compiled. E.g. all the JDK classes need to be compiled once and we can
> provide it to our users. These two measures should speed up compilation time
> a lot.
> >
> > // Sascha
>
> The problem has to do more with size, not time.
> It is really easy to produce static libraries, and thus reduce compilation
> time to minimum.
> The way it is done right now, though, is again object-level optimization -
> similar to what ProGuard does (and it does it extremely well - it is even
> able to deal with simple reflection cases).
>
> The problem is with method-level optimizations. That is why I propose to
> investigate such methods.
>
> In which level is the optimization you are working on?
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Java shrinkers

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

On 31 Αυγ 2010, at 8:44 μ.μ., Sascha Haeberling wrote:

> I am actually working on such an optimized call graph dependency optimizer, which should shrink down the whole compilation size.
> 
> In addition we will remove the need to compile classes that don't need to be compiled. E.g. all the JDK classes need to be compiled once and we can provide it to our users. These two measures should speed up compilation time a lot.
> 
> // Sascha

The problem has to do more with size, not time.
It is really easy to produce static libraries, and thus reduce compilation time to minimum.
The way it is done right now, though, is again object-level optimization - similar to what ProGuard does (and it does it extremely well - it is even able to deal with simple reflection cases).

The problem is with method-level optimizations. That is why I propose to investigate such methods. 

In which level is the optimization you are working on?

Re: [xmlvm-users] Java shrinkers

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

I am actually working on such an optimized call graph dependency optimizer,
which should shrink down the whole compilation size.

In addition we will remove the need to compile classes that don't need to be
compiled. E.g. all the JDK classes need to be compiled once and we can
provide it to our users. These two measures should speed up compilation time
a lot.

// Sascha

On Aug 31, 2010 7:08 PM, "Panayotis Katsaloulis" <pan...@pa...>
wrote:
>
> On 31 Αυγ 2010, at 7:18 μ.μ., Sascha Haeberling wrote:
>
>> Panayotis,
>>
>> just to understand your proposal: Are you talking about trying to reduce
the amount of code we need to translate based on a call graph analysis? Thus
throwing out methods that are never called in an application and classes
that are never referenced?
>>
>> // Sascha
>
> Yes, exactly.
> There are already some projects, which do that. Having only class-based
dependency is rather expensive, so unfortunately projects like ProGuard is
of minimum help.
>
> I don't know why yGuard which does method-based analysis didn't work, but
1) we can investigate it, 2) bug report it 3) try another library :)
> I suspect it had to do with some Scala optimizations; probably with pure
Java code we won't have this problem. Still I believe that a more generic
solution (i.e. one that also supports other JVM-based languages, like Scala)
should be considered.
>
------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] C++ target support dropped

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

Crossing your fingers would be advisable when you attempt this, but in
theory the C backend should be able to deal with this.

Arno

On Aug 31, 2010, at 10:04 AM, Damian <dam...@gm...> wrote:

Great, so I will be able to cross compile the scala libs and everything will
work?

2010/8/31 Arno Puder <ar...@pu...>

> Yes, the idea is to cross-compile everything in the java.* namespace.
>
> Arno
>
>
> On Aug 31, 2010, at 8:09 AM, Panayotis Katsaloulis
> <pan...@pa...> wrote:
>
> >
> > On 31 Αυγ 2010, at 2:28 π.μ., Damian wrote:
> >
> >> Well, to be able to use scala I had to cross compile some of the scala
> libraries. This libraries are writen upon java libraries, and the problem
> I'm facing is that scala uses many functions that are nor implemented in the
> objective-c xmlvm implementation of the java libraries. So I have to write
> the missing functions, but since I will have to do it again with the new
> backend then I decided to wait.
> >> I wonder if the java libraries for the c backend will also be handwriten
> or it will be cross compiled?
> >
> > From my knowledge, the idea is to be automatically cross compiled!
> >
> ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Java shrinkers

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

On 31 Αυγ 2010, at 7:18 μ.μ., Sascha Haeberling wrote:

> Panayotis,
> 
> just to understand your proposal: Are you talking about trying to reduce the amount of code we need to translate based on a call graph analysis? Thus throwing out methods that are never called in an application and classes that are never referenced?
> 
> // Sascha

Yes, exactly.
There are already some projects, which do that. Having only class-based dependency is rather expensive, so unfortunately projects like ProGuard is of minimum help.

I don't know why yGuard which does method-based analysis didn't work, but 1) we can investigate it, 2) bug report it 3) try another library :)
I suspect it had to do with some Scala optimizations; probably with pure Java code we won't have this problem. Still I believe that a more generic solution (i.e. one that also supports other JVM-based languages, like Scala) should be considered. 

Re: [xmlvm-users] C++ target support dropped

[Damian <dam...@gm...>]

Great, so I will be able to cross compile the scala libs and everything will
work?

2010/8/31 Arno Puder <ar...@pu...>

> Yes, the idea is to cross-compile everything in the java.* namespace.
>
> Arno
>
>
> On Aug 31, 2010, at 8:09 AM, Panayotis Katsaloulis
> <pan...@pa...> wrote:
>
> >
> > On 31 Αυγ 2010, at 2:28 π.μ., Damian wrote:
> >
> >> Well, to be able to use scala I had to cross compile some of the scala
> libraries. This libraries are writen upon java libraries, and the problem
> I'm facing is that scala uses many functions that are nor implemented in the
> objective-c xmlvm implementation of the java libraries. So I have to write
> the missing functions, but since I will have to do it again with the new
> backend then I decided to wait.
> >> I wonder if the java libraries for the c backend will also be handwriten
> or it will be cross compiled?
> >
> > From my knowledge, the idea is to be automatically cross compiled!
> >
> ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> >
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] C++ target support dropped

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

Yes, the idea is to cross-compile everything in the java.* namespace.

Arno


On Aug 31, 2010, at 8:09 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:

>
> On 31 Αυγ 2010, at 2:28 π.μ., Damian wrote:
>
>> Well, to be able to use scala I had to cross compile some of the scala libraries. This libraries are writen upon java libraries, and the problem I'm facing is that scala uses many functions that are nor implemented in the objective-c xmlvm implementation of the java libraries. So I have to write the missing functions, but since I will have to do it again with the new backend then I decided to wait.
>> I wonder if the java libraries for the c backend will also be handwriten or it will be cross compiled?
>
> From my knowledge, the idea is to be automatically cross compiled!
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Java shrinkers

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

Panayotis,

just to understand your proposal: Are you talking about trying to reduce the
amount of code we need to translate based on a call graph analysis? Thus
throwing out methods that are never called in an application and classes
that are never referenced?

// Sascha

On Tue, Aug 31, 2010 at 5:54 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> After the talk about Scala under iPhone, and since the Scala library is too
> big (~8MB), I thought to have a look at java shrinkers.
>
> Since most people were talking about ProGuard & Android projects, I give it
> a shot.
> If this is successful enough, this will be a gain not only for Scala or
> whatever, but also for OpenJDK and similar approaches that depend on other
> JAR files :)
>
> I have to say that I was quite successful with ProGuard. It works even for
> strangely crafted classes, like the Scala's ones.
> The only problem with ProGuard is that it performs a quick class-based
> optimization only. For a simple hello-world application (with some
> Scala-based features), it required ~350kb of classes from the Scala
> framework (from a total of ~6MB library). Not bad, but not good enough.
>
> I also had a look at yGuard, which is a free (but not completely open
> source) project, which performs method- and variable- based optimizations.
> Unfortunately I wasn't lucky, at least with Scala projects, it crashed with
> a message:
> "yShrink encountered an unknown problem!"
>
> In ProGuard site there is a list of other shrinkers. Of course we heading
> only for open source, or at least free implementations.
> Here is the list:
> http://proguard.sourceforge.net/alternatives.html
> Since ProGuard does a good job with class-based shrinking, we are actually
> looking for method-based shrinking.
> Even if this is too slow, we could have ProGuard make a pre-selection of
> classes and then let the second library do the mathod-based selection.
>
> What do you think? I believe that this task is really necessary and will
> help a lot with  every project, especially with the new upcoming C backend,
> but it needs testers ;)
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] C++ target support dropped

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

On 31 Αυγ 2010, at 2:28 π.μ., Damian wrote:

> Well, to be able to use scala I had to cross compile some of the scala libraries. This libraries are writen upon java libraries, and the problem I'm facing is that scala uses many functions that are nor implemented in the objective-c xmlvm implementation of the java libraries. So I have to write the missing functions, but since I will have to do it again with the new backend then I decided to wait.
> I wonder if the java libraries for the c backend will also be handwriten or it will be cross compiled?

From my knowledge, the idea is to be automatically cross compiled!

[xmlvm-users] Java shrinkers

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

After the talk about Scala under iPhone, and since the Scala library is too big (~8MB), I thought to have a look at java shrinkers.

Since most people were talking about ProGuard & Android projects, I give it a shot.
If this is successful enough, this will be a gain not only for Scala or whatever, but also for OpenJDK and similar approaches that depend on other JAR files :)

I have to say that I was quite successful with ProGuard. It works even for strangely crafted classes, like the Scala's ones.
The only problem with ProGuard is that it performs a quick class-based optimization only. For a simple hello-world application (with some Scala-based features), it required ~350kb of classes from the Scala framework (from a total of ~6MB library). Not bad, but not good enough.

I also had a look at yGuard, which is a free (but not completely open source) project, which performs method- and variable- based optimizations. Unfortunately I wasn't lucky, at least with Scala projects, it crashed with a message:
"yShrink encountered an unknown problem!"

In ProGuard site there is a list of other shrinkers. Of course we heading only for open source, or at least free implementations.
Here is the list:
http://proguard.sourceforge.net/alternatives.html
Since ProGuard does a good job with class-based shrinking, we are actually looking for method-based shrinking.
Even if this is too slow, we could have ProGuard make a pre-selection of classes and then let the second library do the mathod-based selection.

What do you think? I believe that this task is really necessary and will help a lot with  every project, especially with the new upcoming C backend, but it needs testers ;) 

[xmlvm-users] Android -> iPhone

[tony o. <to...@so...>]

Hello ..

XCode is telling me it cannot find a number of header files .. some examples include:

android_app_PendingIntent.h
android_telephony_SmsManager.h
android_telephony_gsm_SmsMessage.h

I scoured the XMLVM output of my android project and TRUNK folders but to no avail.

If these actions in Android are not yet supported for conversion to iPhone and I missed that in the docs, then I apologize... I would appreciate a hint as to where this sort of stuff is in the XMLVM documentation.


regards,
tob

Tony O'Brien
Sourcecode, LLC
856.596.6644
www.sourcecode-llc.com
www.sourcecode-llc.com/tss
www.sourcecode-llc.com/tssdonor

Re: [xmlvm-users] C++ target support dropped

[Damian <dam...@gm...>]

Well, to be able to use scala I had to cross compile some of the scala
libraries. This libraries are writen upon java libraries, and the problem
I'm facing is that scala uses many functions that are nor implemented in the
objective-c xmlvm implementation of the java libraries. So I have to write
the missing functions, but since I will have to do it again with the new
backend then I decided to wait.
I wonder if the java libraries for the c backend will also be handwriten or
it will be cross compiled?

2010/8/30 Panayotis Katsaloulis <pan...@pa...>

>
> On 31 Αυγ 2010, at 1:40 π.μ., Damian wrote:
>
> > Yes, but I only could compile a very simple project. I'm having several
> problems so I will wait until the C backend is ready to continue with it.
>
> I did also some basic tests on how to use Scala with xmlvm, and I was
> successful up to now, but with very limited code.
> What kind of problems did you have?
>
> I suspect that these problems have nothing to do with the Obj-C backend, so
> either this might not be able to be addressed by XMLVM or, in any case,
> there is a need to keep it in mind.
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] C++ target support dropped

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

On 31 Αυγ 2010, at 1:40 π.μ., Damian wrote:

> Yes, but I only could compile a very simple project. I'm having several problems so I will wait until the C backend is ready to continue with it.

I did also some basic tests on how to use Scala with xmlvm, and I was successful up to now, but with very limited code. 
What kind of problems did you have?

I suspect that these problems have nothing to do with the Obj-C backend, so either this might not be able to be addressed by XMLVM or, in any case, there is a need to keep it in mind.

Re: [xmlvm-users] C++ target support dropped

[Damian <dam...@gm...>]

Yes, but I only could compile a very simple project. I'm having several
problems so I will wait until the C backend is ready to continue with it.

On Mon, Aug 30, 2010 at 4:40 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On 27 Αυγ 2010, at 1:42 π.μ., Damian wrote:
>
> > I was wondering the same...
> > Since I'm using xmlvm for making a 100% opengl app and I'm coding in
> Scala I had to change some of the java library and crosscompile some scala
> libs to make it work, so I will have to do that again when changing to the C
> backend. Should I change to C backend now or is it too early?
> >
> > Damian
>
>
> How did you use Scala with XMLVM ?
> Did you use ProGuard?
> Can you give us an example?
>
>

Re: [xmlvm-users] C++ target support dropped

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

On 27 Αυγ 2010, at 1:42 π.μ., Damian wrote:

> I was wondering the same... 
> Since I'm using xmlvm for making a 100% opengl app and I'm coding in Scala I had to change some of the java library and crosscompile some scala libs to make it work, so I will have to do that again when changing to the C backend. Should I change to C backend now or is it too early?
> 
> Damian


How did you use Scala with XMLVM ?
Did you use ProGuard?
Can you give us an example?

Re: [xmlvm-users] Overall Plan??

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

thanks for offering help. We still need to do some internal cleanup 
before we can outsource some of the TODOs. I'll keep you posted.

Arno


On 8/29/2010 12:24 AM, Lennie De Villiers wrote:
> Hi need help with the C backend?
>
>> On 27 Aug 2010 6:48 PM, "Arno Puder" <ar...@pu...
>> <mailto:ar...@pu...>> wrote:
>>
>>
>> at this point the top-priority is to get the C backend up and running
>> and making everything work again for the iPhone. That will put XMLVM in
>> a good position to support other platforms, but that also depends on the
>> community and what kind of support we get from others. Remember, XMLVM
>> is Open Source and depends on people donating their time and effort.
>>
>> Arno
>>
>>
>>
>> On 8/27/10 9:43 AM, C. Johnson wrote:
>> > Any other OS targets be considered other than IOS 4 for ip...
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions...
>>

Re: [xmlvm-users] Overall Plan??

[Lennie De V. <len...@gm...>]

Hi need help with the C backend?

On 27 Aug 2010 6:48 PM, "Arno Puder" <ar...@pu...> wrote:


at this point the top-priority is to get the C backend up and running
and making everything work again for the iPhone. That will put XMLVM in
a good position to support other platforms, but that also depends on the
community and what kind of support we get from others. Remember, XMLVM
is Open Source and depends on people donating their time and effort.

Arno



On 8/27/10 9:43 AM, C. Johnson wrote:
> Any other OS targets be considered other than IOS 4 for ip...

------------------------------------------------------------------------------
Sell apps to millions...

Re: [xmlvm-users] Android to iPhone

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

in theory, yes. But there is most likely a bug that prevents it from 
working with this indirection. I guess no one stumbled over it so far 
since it is not a common way of using XMLVM.

Arno


On 8/27/10 11:03 AM, tony obrien wrote:
> I followed your advise and *was* able to create the xcode output I
> expected...
>
> Thanks for the idea -- but *shouldn't* it have worked going through the
> xmlvm output step too?
>
>
> On Aug 26, 2010, at 6:17 PM, xml...@li...
> <mailto:xml...@li...> wrote:
>
>>
>>
>> 1. Re: Android to iPhone problem... (Arno Puder)
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 17 Aug 2010 10:03:32 -0700
>> From: Arno Puder <ar...@pu... <mailto:ar...@pu...>>
>> Subject: Re: [xmlvm-users] Android to iPhone problem...
>> To: xml...@li...
>> <mailto:xml...@li...>
>> Message-ID: <4C6...@pu...
>> <mailto:4C6...@pu...>>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>
>> there is no need to first generate the .xmlvm files and then
>> cross-compile them. You can point --in to your .class files directly and
>> do everything in one step. You can take a look at build.xml for some
>> examples.
>>
>> Arno
>>
>
>> I created the ".xmlvm" output using:
>>
>> java -jar /Users/tonyobrien/Desktop/xmlvm/trunk/xmlvm/dist/xmlvm.jar
>> --in=. --out=xmlvm_output
>>
>> which created the ".xmlvm" files
>
>> I then applied the following command (expecting the results in a new,
>> empty folder named 'iPhone_Output'):
>>
>> java -jar /Users/tonyobrien/Desktop/xmlvm/trunk/xmlvm/dist/xmlvm.jar
>> --in=xmlvm_output --out=iPhone_Output --target=android-on-iphone
>> --iphone-app=myIphoneApp
>>
>> But I was greeted by an error stream:
> http://www.sourcecode-llc.com/xmlvm/Scr2.png
>
> <http://www.sourcecode-llc.com/xmlvm/Scr2.png>
>>
>
> regards,
> tob
>
> Tony O'Brien
> Sourcecode, LLC
> 856.596.6644
> www.sourcecode-llc.com <http://www.sourcecode-llc.com>
> www.sourcecode-llc.com/tss <http://www.sourcecode-llc.com/tss>
> www.sourcecode-llc.com/tssdonor <http://www.sourcecode-llc.com/tssdonor>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Android to iPhone

[tony o. <to...@so...>]

I followed your advise and *was* able to create the xcode output I expected...

Thanks for the idea --  but *shouldn't* it have worked going through the xmlvm output step too?


On Aug 26, 2010, at 6:17 PM, xml...@li... wrote:

> 
> 
>   1. Re: Android to iPhone problem... (Arno Puder)
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 17 Aug 2010 10:03:32 -0700
> From: Arno Puder <ar...@pu...>
> Subject: Re: [xmlvm-users] Android to iPhone problem...
> To: xml...@li...
> Message-ID: <4C6...@pu...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> 
> there is no need to first generate the .xmlvm files and then 
> cross-compile them. You can point --in to your .class files directly and 
> do everything in one step. You can take a look at build.xml for some 
> examples.
> 
> Arno
> 

> I created the ".xmlvm" output using:
> 
> java -jar /Users/tonyobrien/Desktop/xmlvm/trunk/xmlvm/dist/xmlvm.jar
> --in=. --out=xmlvm_output
> 
> which created the ".xmlvm" files 

> I then applied the following command (expecting the results in a new,
> empty folder named 'iPhone_Output'):
> 
> java -jar /Users/tonyobrien/Desktop/xmlvm/trunk/xmlvm/dist/xmlvm.jar
> --in=xmlvm_output --out=iPhone_Output --target=android-on-iphone
> --iphone-app=myIphoneApp
> 
> But I was greeted by an error stream:
http://www.sourcecode-llc.com/xmlvm/Scr2.png


> 

regards,
tob

Tony O'Brien
Sourcecode, LLC
856.596.6644
www.sourcecode-llc.com
www.sourcecode-llc.com/tss
www.sourcecode-llc.com/tssdonor

Re: [xmlvm-users] Overall Plan??

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

at this point the top-priority is to get the C backend up and running 
and making everything work again for the iPhone. That will put XMLVM in 
a good position to support other platforms, but that also depends on the 
community and what kind of support we get from others. Remember, XMLVM 
is Open Source and depends on people donating their time and effort.

Arno


On 8/27/10 9:43 AM, C. Johnson wrote:
> Any other OS targets be considered other than IOS 4 for iphone ??
>
>
>