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

Re: [xmlvm-users] Interface vs abstract classes

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

Do you mean:

public interface FirstOption {
 public void someMethod();
}

public abstract class SecondOption implements FirstOption {
}

Because that would be a good idea. I support it.

On Sun, Sep 12, 2010 at 6:33 AM, Arno Puder <ar...@pu...> wrote:

>
> right now we map Objective-C protocols to Java interfaces, except if
> there are optional methods in the protocol. In that case we map it to an
> abstract class.
>
> Using Java interfaces and being able to make use of multiple inheritance
> leads to better designs, IMHO. Of course you can mimic it with abstract
> classes only but the resulting design is not as 'natural'. As far as I
> can tell, the majority of the Cocoa protocols do not have optional
> methods, so making abstract base classes the default seems like a
> drastic decision.
>
> As a compromise, since you have mentioned a 'support' package that
> houses non-standard API, it would be possible to do both: Java
> interfaces and abstract base classes. This way the developer could
> choose which to use. There would be some redundancy, but if would offer
> developers a choice.
>
> Thoughts, anyone?
>
> Arno
>
>
> On 9/11/10 1:51 PM, Panayotis Katsaloulis wrote:
> > On 11 Σεπ 2010, at 5:44 μ.μ., Leo Izen wrote:
> >
> >> Java doesn't support multiple inheritance the way C++ does. This means
> that If you want your class to extend multiple types, you have to use
> interfaces.
> >
> > I know, I am not talking about general Java programming, but the specific
> implementation of ObjC library under Java.
> >
> ------------------------------------------------------------------------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

[xmlvm-users] XMLVM TODOs

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

Guys,

some of you have offered help and I want to discuss potential projects 
that are up for grabs. Of course it depends on your skills and 
interests. From Android to iPhone, from Java to Objective-C, there is 
plenty to do.

1. Documentation: Let me start with the least favorite, but still very 
important job of documentation. If someone out there enjoys writing 
technical documentation, XMLVM would get a major boost by offering 
better documentation. Right now we have an HTML version in 
xmlvm/doc/homepage/manual that is the best we have right now. We have 
begun to convert this to DocBook in xmlvm/doc/manual/docbook. Anyone 
interested in continuing the conversion to DocBook and/or adding new 
documentation? A little HOWTO and a tutorial would be nice.

2. Java/Cocoa: directory xmlvm/src/xmlvm2objc/compat-lib/java contains 
the Java sources of the Cocoa classes. The implementation of those 
classes are also our own iPhone emulator. There are plenty of missing 
API as well as API that was never implemented. Possible projects would 
be to add missing Cocoa API and/or implement API that has not yet been 
implemented. Another project might be to extend the emulator to run in 
iPad mode. Our Java emulator is written entirely in Java and makes use 
of Java2D. If that interests you, let me know.

3. C wrappers: as I mentioned several times on the mailing list, we are 
swiftly moving towards the new C backend. One piece of work where we can 
use your help is to implement the C wrappers. If you look at directory 
xmlvm/src/xmlvm2c/compat-lib/iphone you see the generated wrappers 
(those wrappers where actually automatically generated from the Java 
Cocoa API mentioned above). If you look in org_xmlvm_iphone_UIImage.m 
you get an idea of the kind of implementation that needs to be done. 
That is kind of a high-priority job since we need those wrappers in 
order to move to the new backend. This job requires good knowledge of 
Objective-C and Cocoa.

4. Android to iPhone: if you check directory xmlvm/src/android2iphone 
you will see Java classes that mimic the Android API, but are 
implemented using our Java version of Cocoa. This is the basis of the 
"Android app running on an iPhone". If you check this directory, you 
will quickly find out that there are many, many Android classes missing. 
This job is tricky because there is not always an obvious mapping from 
Android API to Cocoa API (just think of Android's layout manager that 
has nothing corresponding on the iPhone). Other API are easier. E.g., 
one little project could be to map the location API. This TODO requires 
good knowledge of both Android and iPhone. You can work mostly in Java 
but also need to extend the Cocoa API as needed (this is what I wrote in 
(1)).

Well, guys, here you have it. XMLVM is Open Source and you are free to 
use it in your products. But we can only make fast progress if the 
community helps making XMLVM better. If you are interested in one of 
these jobs, please send a note to me or over the mailing list so we can 
better coordinate your efforts.

Arno

Re: [xmlvm-users] Interface vs abstract classes

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

right now we map Objective-C protocols to Java interfaces, except if 
there are optional methods in the protocol. In that case we map it to an 
abstract class.

Using Java interfaces and being able to make use of multiple inheritance 
leads to better designs, IMHO. Of course you can mimic it with abstract 
classes only but the resulting design is not as 'natural'. As far as I 
can tell, the majority of the Cocoa protocols do not have optional 
methods, so making abstract base classes the default seems like a 
drastic decision.

As a compromise, since you have mentioned a 'support' package that 
houses non-standard API, it would be possible to do both: Java 
interfaces and abstract base classes. This way the developer could 
choose which to use. There would be some redundancy, but if would offer 
developers a choice.

Thoughts, anyone?

Arno


On 9/11/10 1:51 PM, Panayotis Katsaloulis wrote:
> On 11 Σεπ 2010, at 5:44 μ.μ., Leo Izen wrote:
>
>> Java doesn't support multiple inheritance the way C++ does. This means that If you want your class to extend multiple types, you have to use interfaces.
>
> I know, I am not talking about general Java programming, but the specific implementation of ObjC library under Java.
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Recommended method of developing

[Linus B. <li...@br...>]

Thanks for your replies!

Initially, im planning on working on something that does not use widgets
extensively, but takes care of it's own view/drawing - so the kind of
software thats easily portable.

What concerns me most is the automated build on mac, if anyone has any hints
for me about this id appreciate them :-)
I have little experience with xcode and mac development in general, but i
guess it should be scriptable like on any other platform.

/Linus

On Sat, Sep 11, 2010 at 10:01 AM, Arno Puder <ar...@pu...> wrote:

>
> I think it depends on the type of the application. Ideally, the
> preferred way of using XMLVM is to write an Android application and
> cross-compile it to the iPhone. The problem is that this does not work
> well for certain kinds of applications (i.e., applications that make
> heavy use of widgets). On the other hand, games are easier to
> cross-compile because they usually don't make use of native widgets.
>
> As Sascha pointed out, XMLVM is under heavy development. You are bound
> to run into an API that is not yet supported by XMLVM. In that case
> report on this mailing list and lets see if we can find a volunteer to
> work on this.  :-)
>
> Arno
>
>
> On 9/10/10 12:21 PM, Linus Brimstedt wrote:
> > Hello!
> >
> > I've been lurking on this list for a while and have made some minor
> > experiments with XMLVM.
> >
> > I would like to do some more serous tests but wonder, what is the
> > recommended or intended method of developing with XMLVM if you want to
> > target iPhone and Android?
> >
> > I would like to just use the Android SDK and tools and develop
> > "normally" and by automation convert and compile the project on each
> > commit to the repository.
> >
> > Is this how you all do it, or how do you do?
> >
> > best regards
> > /Linus
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing
> > http://p.sf.net/sfu/novell-sfdev2dev
> >
> >
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Interface vs abstract classes

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

On 11 Σεπ 2010, at 5:44 μ.μ., Leo Izen wrote:

> Java doesn't support multiple inheritance the way C++ does. This means that If you want your class to extend multiple types, you have to use interfaces. 

I know, I am not talking about general Java programming, but the specific implementation of ObjC library under Java.

Re: [xmlvm-users] Interface vs abstract classes

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

Java doesn't support multiple inheritance the way C++ does. This means that
If you want your class to extend multiple types, you have to use interfaces.


On Sat, Sep 11, 2010 at 8:17 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> For quite some time there is no decision whether it is preferable to
> use abstract classes or interfaces.
> With this email I'd propose to use only abstract classes instead of
> interfaces and I hope I will convince you :)
>
> First of all I know the disadvantages. By using interfaces we can not
> reuse the same objects and thus we usually create inner classes (so we
> create one class more).
> A second problem has to do with concept: in ObjC there is a use of
> protocols and not interfaces.
>
> The problem is, although it looks like we make economy by reusing the
> same object, in reality under the current xmlvm implementation, this
> is not the case. In order to properly support java interfaces, a
> "secret" glue object is used in every case (in which object we have
> absolutely no control upon).
>
> When using abstract classes there is 1-1 correspondence. Even if we
> use inner classes (which is a common and well known technique), we
> have absolute control on this object. In any case, worst case
> scenario, we have to define/use one (an only one) object of this
> abstract class.
>
> Back to the interface implementation, the minimum number of objects is
> one: the glue object. Though, in the case of an inner object (or any
> time we don't reuse a given object) , the number of objects rises to
> two!
>
> In all cases, interface implementation is more demanding than abstract
> classes, and more complex. For this reason I propose to use everywhere
> in XMLVM compatibility library abstract classes instead of interfaces
> - even for trivial cases.
>
> --
> Panayotis
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Java shrinkers

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

First of all, sorry for the late answer.
Last time I thought that it couldn't be done - if it really can then
this is a nice surprise!
Do you remember the actual parameter used for this issue?
I believe if we find a solution with ProGuard, this will help a *lot*
the XMLVM progress and the whole acceptance of XMLVM, even with the
relaxed new iOS SDK agreement.

On 9/1/10, Jeff Palmer <jcp...@ro...> wrote:
> 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
>
>
>
>


-- 
Panayotis Katsaloulis

[xmlvm-users] Interface vs abstract classes

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

For quite some time there is no decision whether it is preferable to
use abstract classes or interfaces.
With this email I'd propose to use only abstract classes instead of
interfaces and I hope I will convince you :)

First of all I know the disadvantages. By using interfaces we can not
reuse the same objects and thus we usually create inner classes (so we
create one class more).
A second problem has to do with concept: in ObjC there is a use of
protocols and not interfaces.

The problem is, although it looks like we make economy by reusing the
same object, in reality under the current xmlvm implementation, this
is not the case. In order to properly support java interfaces, a
"secret" glue object is used in every case (in which object we have
absolutely no control upon).

When using abstract classes there is 1-1 correspondence. Even if we
use inner classes (which is a common and well known technique), we
have absolute control on this object. In any case, worst case
scenario, we have to define/use one (an only one) object of this
abstract class.

Back to the interface implementation, the minimum number of objects is
one: the glue object. Though, in the case of an inner object (or any
time we don't reuse a given object) , the number of objects rises to
two!

In all cases, interface implementation is more demanding than abstract
classes, and more complex. For this reason I propose to use everywhere
in XMLVM compatibility library abstract classes instead of interfaces
- even for trivial cases.

--
Panayotis

Re: [xmlvm-users] NsTimerDelegate

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

I'm sure there are plenty of "dark corners" in XMLVM where we are (not 
yet) consistent.  :-)  But I'm sure that will be cleaned up eventually.

A support package for non-standard classes/interfaces is a good idea!

Arno


On 9/11/10 4:08 AM, Panayotis Katsaloulis wrote:
>
> 11 Σεπ 2010, 1:59 μ.μ., ο/η Arno Puder<ar...@pu...>  έγραψε:
>
>>
>> well, I was referring to the fact that sometimes we map Objective-C
>> protocols to Java class and sometimes to Java interfaces. Of course we
>> do this consistently, but its a design decision. Likewise its a design
>> decision to map Objective-C @selector to a strongly-typed interface in
>> those cases where it is possible.
>>
>> Arno
>
> Well, probably I am missing something, but I think that this is not always the case. There are some locations, like the one I mentioned before, that don't follow the strongly typed nature of Java.
> In any case, if you really believe that a strongly typed declaration is preferred, I'd at least suggest to create a new package for all these situations, something like org.xmlvm.iphone.support (or anything similar) and keep all non-standard objects there, while having heavy documentation on these classes (although still I believe is not the best solution)
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] NsTimerDelegate

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

11 Σεπ 2010, 1:59 μ.μ., ο/η Arno Puder <ar...@pu...> έγραψε:

> 
> well, I was referring to the fact that sometimes we map Objective-C 
> protocols to Java class and sometimes to Java interfaces. Of course we 
> do this consistently, but its a design decision. Likewise its a design 
> decision to map Objective-C @selector to a strongly-typed interface in 
> those cases where it is possible.
> 
> Arno

Well, probably I am missing something, but I think that this is not always the case. There are some locations, like the one I mentioned before, that don't follow the strongly typed nature of Java. 
In any case, if you really believe that a strongly typed declaration is preferred, I'd at least suggest to create a new package for all these situations, something like org.xmlvm.iphone.support (or anything similar) and keep all non-standard objects there, while having heavy documentation on these classes (although still I believe is not the best solution)

Re: [xmlvm-users] NsTimerDelegate

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

well, I was referring to the fact that sometimes we map Objective-C 
protocols to Java class and sometimes to Java interfaces. Of course we 
do this consistently, but its a design decision. Likewise its a design 
decision to map Objective-C @selector to a strongly-typed interface in 
those cases where it is possible.

Arno


On 9/11/10 3:20 AM, Panayotis Katsaloulis wrote:
> Well, you are the boss, but I I don't see the problem on using reflection.
> And in some situations, we can't avoid it at all (like the important selector "performSelectorOnMainThread")
>
> Now, about the other problem of optional selectors, I believe I gave a nice solution with org.xmlvm.iphone.internal.OptionalSelectorException.
> Of course, the emulator should follow some guidelines, but in any case I believe it is an elegant solution
>
> In both cases, the API was completely compatible with Java and ObjC at the same time :)
>
>
>
>
> --
> Panayotis
>
> 11 Σεπ 2010, 12:42 μ.μ., ο/η Arno Puder<ar...@pu...>  έγραψε:
>
>>
>> just to explain that change: NSTimer in Objective-C allows to trigger
>> arbitrary methods. This is easy in Objective-C since this language is
>> dynamically typed. So far we mimicked this in Java by using reflection.
>> However, Java is a strongly typed language and doing it this way is not
>> in the spirit of the language. That is why we introduced NSTimerDelegate.
>>
>> Note that at some point we need to make design decisions where we cannot
>> easily map Objective-C to Java (another example are optional methods in
>> Objective-C protocols. Here we also deviate from the "official Apple
>> documentation"). Its a design decision but I believe its a good one.
>>
>> Arno
>>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] NsTimerDelegate

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

Well, you are the boss, but I I don't see the problem on using reflection. 
And in some situations, we can't avoid it at all (like the important selector "performSelectorOnMainThread")

Now, about the other problem of optional selectors, I believe I gave a nice solution with org.xmlvm.iphone.internal.OptionalSelectorException. 
Of course, the emulator should follow some guidelines, but in any case I believe it is an elegant solution

In both cases, the API was completely compatible with Java and ObjC at the same time :)




--
Panayotis

11 Σεπ 2010, 12:42 μ.μ., ο/η Arno Puder <ar...@pu...> έγραψε:

> 
> just to explain that change: NSTimer in Objective-C allows to trigger 
> arbitrary methods. This is easy in Objective-C since this language is 
> dynamically typed. So far we mimicked this in Java by using reflection. 
> However, Java is a strongly typed language and doing it this way is not 
> in the spirit of the language. That is why we introduced NSTimerDelegate.
> 
> Note that at some point we need to make design decisions where we cannot 
> easily map Objective-C to Java (another example are optional methods in 
> Objective-C protocols. Here we also deviate from the "official Apple 
> documentation"). Its a design decision but I believe its a good one.
> 
> Arno
> 

Re: [xmlvm-users] NsTimerDelegate

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

just to explain that change: NSTimer in Objective-C allows to trigger 
arbitrary methods. This is easy in Objective-C since this language is 
dynamically typed. So far we mimicked this in Java by using reflection. 
However, Java is a strongly typed language and doing it this way is not 
in the spirit of the language. That is why we introduced NSTimerDelegate.

Note that at some point we need to make design decisions where we cannot 
easily map Objective-C to Java (another example are optional methods in 
Objective-C protocols. Here we also deviate from the "official Apple 
documentation"). Its a design decision but I believe its a good one.

Arno


On 9/11/10 2:35 AM, Panayotis Katsaloulis wrote:
> Hello all!
>
> I'd like to ask you about the introduction of the NSTimerDelegate object.
> I believe this idea was not so good. This is something that does not belong to the iOS sdk, and I strongly believer we should be as strict as possible with this, and violate it *only* there is NO other way of doing it.
> We don't have specific documentation for xmlvm, so please at least b compatible with the documentation being written by others ;) ( namely Apple)
>
>
> --
> Panayotis
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] NsTimerDelegate

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

Hello all!

I'd like to ask you about the introduction of the NSTimerDelegate object. 
I believe this idea was not so good. This is something that does not belong to the iOS sdk, and I strongly believer we should be as strict as possible with this, and violate it *only* there is NO other way of doing it. 
We don't have specific documentation for xmlvm, so please at least b compatible with the documentation being written by others ;) ( namely Apple)


--
Panayotis

Re: [xmlvm-users] Android -> iPhone (general)

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

you are absolutely right that XMLVM does not have enough documentation. 
Documentation for users as well as documentation for developers. XMLVM 
is Open Source and can only thrive with a community. We can certainly 
use any help we can get. If you are interested to donate your time and 
skills, please contact me directly and I'm sure we can find something 
for you to do.  :-)

Arno


On 9/10/10 7:25 AM, tony obrien wrote:
> Hi,
>
> I know the XMLVM team is busily working on many aspects of XMLVM and (as you probably know from previous emails) I am endeavoring to use XMLVM to (re) compile my Android Source into XCode.
>
> I have bumped into a few "not ready yet" aspects of this cross-compile (the PENDING INTENT as an example.)
>
> My question is...
>
> Is there a plan in place to get these items covered byXMLVM? I mean, do I submit them as I find them, or do you guys already "know" that there are classes not covered by XMLVM and have a big long list of them already and will get to them as time allows?
>
> I really love this idea of XMLVM (versus, say, having to rewrite everything in a new "meta-language" which THEN gets compiled down into the various h/w targets...) and I wish that I could help in some manner other than sounding like, uhm, well, a complainer.  I am NOT complaining. I know these things will take time. Perhaps there is a (public) web page that indicates what the development plan is at any given point in time?
>
> If you review my website, you'll see that I have a 30 year background in programming in a variety of languages and platforms ... perhaps you *can* find a way to let me help in some way in this endeavor?
>
> regards,
> tob
>
> Tony O'Brien
> Sourcecode, LLC
> 856.596.6644
> www.sourcecode-llc.com
> www.sourcecode-llc.com/tss
> www.sourcecode-llc.com/tssdonor
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Recommended method of developing

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

I think it depends on the type of the application. Ideally, the 
preferred way of using XMLVM is to write an Android application and 
cross-compile it to the iPhone. The problem is that this does not work 
well for certain kinds of applications (i.e., applications that make 
heavy use of widgets). On the other hand, games are easier to 
cross-compile because they usually don't make use of native widgets.

As Sascha pointed out, XMLVM is under heavy development. You are bound 
to run into an API that is not yet supported by XMLVM. In that case 
report on this mailing list and lets see if we can find a volunteer to 
work on this.  :-)

Arno


On 9/10/10 12:21 PM, Linus Brimstedt wrote:
> Hello!
>
> I've been lurking on this list for a while and have made some minor
> experiments with XMLVM.
>
> I would like to do some more serous tests but wonder, what is the
> recommended or intended method of developing with XMLVM if you want to
> target iPhone and Android?
>
> I would like to just use the Android SDK and tools and develop
> "normally" and by automation convert and compile the project on each
> commit to the repository.
>
> Is this how you all do it, or how do you do?
>
> best regards
> /Linus
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] does recent Apple store announcement negate XMLVM?

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

As you said, there is nothing said about C-derivates only at all. Quite the
contrary: It mentioned Adobe resuming development their tools to convert
Flash Apps to the iPhone.

I think you are mistaken.

// Sascha

On Sat, Sep 11, 2010 at 2:33 AM, Erol Fox <er...@li...> wrote:

>
> http://www.engadget.com/2010/09/09/apple-backpedaling-on-some-ios-development-restrictions-will-al/
>
>
>
> ah, now I can’t find the specific article which said only C, C++, Objective
> C would be allowed, and Engadget wondered how they could actually tell.
>
>
>
> Part of the overall announcement yesterday from Apple about the store
> acceptance policy.
>
>
>
> *From:* sa...@gm... [mailto:sa...@gm...] *On Behalf Of *Sascha
> Haeberling
> *Sent:* Friday, September 10, 2010 4:38 PM
> *To:* Erol Fox
> *Cc:* xml...@li...
> *Subject:* Re: [xmlvm-users] does recent Apple store announcement negate
> XMLVM?
>
>
>
> Which announcement are you talking about? I haven't heard about a
> limitation to C derivates and especially my understanding is that the notion
> of "original language" has disappeared. In this light, XMLVM should be
> perfectly fine.
>
>
>
> // Sascha
>
> On Fri, Sep 10, 2010 at 11:22 PM, Erol Fox <er...@li...> wrote:
>
> Apple just made it really clear that only C derivatives can be used. What's
> this mean for this project?
>
> Cheers!
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>

Re: [xmlvm-users] Recommended method of developing

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

If you want to target iPhone only, then there are two ways you could use
XMLVM:

First of all we have build (and are continuing to extend) a Cocoa Java API.
With this you can write your iPhone Application on top of the Cocoa API, but
all within Java.

Second of all, we are building an Android API on top of this Cocoa Java API.
With this you can develop an Android application that can also be
cross-compiled to the iPhone.

Both APIs are still under heavy development.

// Sascha

On Fri, Sep 10, 2010 at 9:21 PM, Linus Brimstedt <li...@br...> wrote:

> Hello!
>
> I've been lurking on this list for a while and have made some minor
> experiments with XMLVM.
>
> I would like to do some more serous tests but wonder, what is the
> recommended or intended method of developing with XMLVM if you want to
> target iPhone and Android?
>
> I would like to just use the Android SDK and tools and develop "normally"
> and by automation convert and compile the project on each commit to the
> repository.
>
> Is this how you all do it, or how do you do?
>
> best regards
> /Linus
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] does recent Apple store announcement negate XMLVM?

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

Which announcement are you talking about? I haven't heard about a limitation
to C derivates and especially my understanding is that the notion of
"original language" has disappeared. In this light, XMLVM should be
perfectly fine.

// Sascha

On Fri, Sep 10, 2010 at 11:22 PM, Erol Fox <er...@li...> wrote:

> Apple just made it really clear that only C derivatives can be used. What's
> this mean for this project?
>
> Cheers!
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

[xmlvm-users] does recent Apple store announcement negate XMLVM?

[Erol F. <er...@li...>]

Apple just made it really clear that only C derivatives can be used. What's
this mean for this project?

Cheers!

[xmlvm-users] Recommended method of developing

[Linus B. <li...@br...>]

Hello!

I've been lurking on this list for a while and have made some minor
experiments with XMLVM.

I would like to do some more serous tests but wonder, what is the
recommended or intended method of developing with XMLVM if you want to
target iPhone and Android?

I would like to just use the Android SDK and tools and develop "normally"
and by automation convert and compile the project on each commit to the
repository.

Is this how you all do it, or how do you do?

best regards
/Linus

[xmlvm-users] Android -> iPhone (general)

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

Hi,

I know the XMLVM team is busily working on many aspects of XMLVM and (as you probably know from previous emails) I am endeavoring to use XMLVM to (re) compile my Android Source into XCode.

I have bumped into a few "not ready yet" aspects of this cross-compile (the PENDING INTENT as an example.)

My question is...

Is there a plan in place to get these items covered byXMLVM? I mean, do I submit them as I find them, or do you guys already "know" that there are classes not covered by XMLVM and have a big long list of them already and will get to them as time allows?

I really love this idea of XMLVM (versus, say, having to rewrite everything in a new "meta-language" which THEN gets compiled down into the various h/w targets...) and I wish that I could help in some manner other than sounding like, uhm, well, a complainer.  I am NOT complaining. I know these things will take time. Perhaps there is a (public) web page that indicates what the development plan is at any given point in time?

If you review my website, you'll see that I have a 30 year background in programming in a variety of languages and platforms ... perhaps you *can* find a way to let me help in some way in this endeavor? 

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] FW: (no subject)

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

we had a little bug yesterday that we fixed. Please make sure you do a 
"svn update" to get the latest version of XMLVM. All XMLVM demos should 
work just fine. Also make sure you have the latest version of Xcode.

Arno


On 9/10/10 7:09 AM, Biardzki, Michal wrote:
> Yes I try to compile with --target=iphone --iphone-app=Something but
> when I try to run project in XCode there lots of errors with classes
> i.e: Main.h in code is normal Main.h and _Main.h, file name is _Main.h.
> When I try to run the iRemote project just like it is there are about
> 300 errors and lots of them are like example above.
> Michal
>
> -----Original Message-----
> From: Arno Puder [mailto:ar...@pu...]
> Sent: Friday, September 10, 2010 3:54 PM
> To: xml...@li...
> Subject: Re: [xmlvm-users] (no subject)
>
>
> first of all, you need a Mac and the iPhone SDK to compile the demos.
> The Makefiles are there for historic reasons (XMLVM began long before
> Apple released the iPhone SDK). You need to use Xcode to write an iPhone
>
> application nowadays. Luckily, XMLVM generates a ready-to-compile Xcode
> project for you.
>
> Try the following:
>
> svn co https://xmlvm.svn.sourceforge.net/svnroot/xmlvm/trunk/xmlvm
> cd xmlvm
> ant
> open dist/demo/android/xokoban/iphone/Xokoban.xcodeproj/
>
> Arno
>
>
> On 9/10/10 6:42 AM, Biardzki, Michal wrote:
>> Hi,
>>
>> I try to convert demo include to xmlvm. I compile xmlvm and demos
>>
>> in Netbeans, everything work fine. But when I convert class files from
>>
>> demo to iphone app and copy everything to Mac machine I try to run
>>
>> Makefile and there is an syntax error in this line
>>
>> ifeq (a, a$(IPHONE_SDK_HOME)).
>>
>> I never work with make so I don't rely know
>>
>> what to do with this? I attach Makefile. ASAP.
>>
>> Regards,
>>
>> M. Biardzki
>>
>>
>>
>>
> ------------------------------------------------------------------------
> ------
>> Automate Storage Tiering Simply
>> Optimize IT performance and efficiency through flexible, powerful,
>> automated storage tiering capabilities. View this brief to learn how
>> you can reduce costs and improve performance.
>> http://p.sf.net/sfu/dell-sfdev2dev
>>
>>
>>
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
> ------------------------------------------------------------------------
> ------
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
> ------------------------------------------------------------------------------
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] FW: (no subject)

[Biardzki, M. <mbi...@mi...>]

Yes I try to compile with --target=iphone --iphone-app=Something but 
when I try to run project in XCode there lots of errors with classes
i.e: Main.h in code is normal Main.h and _Main.h, file name is _Main.h.
When I try to run the iRemote project just like it is there are about 
300 errors and lots of them are like example above.
Michal

-----Original Message-----
From: Arno Puder [mailto:ar...@pu...] 
Sent: Friday, September 10, 2010 3:54 PM
To: xml...@li...
Subject: Re: [xmlvm-users] (no subject)


first of all, you need a Mac and the iPhone SDK to compile the demos. 
The Makefiles are there for historic reasons (XMLVM began long before 
Apple released the iPhone SDK). You need to use Xcode to write an iPhone

application nowadays. Luckily, XMLVM generates a ready-to-compile Xcode 
project for you.

Try the following:

svn co https://xmlvm.svn.sourceforge.net/svnroot/xmlvm/trunk/xmlvm
cd xmlvm
ant
open dist/demo/android/xokoban/iphone/Xokoban.xcodeproj/

Arno


On 9/10/10 6:42 AM, Biardzki, Michal wrote:
> Hi,
>
> I try to convert demo include to xmlvm. I compile xmlvm and demos
>
> in Netbeans, everything work fine. But when I convert class files from
>
> demo to iphone app and copy everything to Mac machine I try to run
>
> Makefile and there is an syntax error in this line
>
> ifeq (a, a$(IPHONE_SDK_HOME)).
>
> I never work with make so I don't rely know
>
> what to do with this? I attach Makefile. ASAP.
>
> Regards,
>
> M. Biardzki
>
>
>
>
------------------------------------------------------------------------
------
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

------------------------------------------------------------------------
------
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful, 
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance. 
http://p.sf.net/sfu/dell-sfdev2dev
_______________________________________________
xmlvm-users mailing list
xml...@li...
https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] (no subject)

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

first of all, you need a Mac and the iPhone SDK to compile the demos. 
The Makefiles are there for historic reasons (XMLVM began long before 
Apple released the iPhone SDK). You need to use Xcode to write an iPhone 
application nowadays. Luckily, XMLVM generates a ready-to-compile Xcode 
project for you.

Try the following:

svn co https://xmlvm.svn.sourceforge.net/svnroot/xmlvm/trunk/xmlvm
cd xmlvm
ant
open dist/demo/android/xokoban/iphone/Xokoban.xcodeproj/

Arno


On 9/10/10 6:42 AM, Biardzki, Michal wrote:
> Hi,
>
> I try to convert demo include to xmlvm. I compile xmlvm and demos
>
> in Netbeans, everything work fine. But when I convert class files from
>
> demo to iphone app and copy everything to Mac machine I try to run
>
> Makefile and there is an syntax error in this line
>
> ifeq (a, a$(IPHONE_SDK_HOME)).
>
> I never work with make so I don’t rely know
>
> what to do with this? I attach Makefile. ASAP.
>
> Regards,
>
> M. Biardzki
>
>
>
> ------------------------------------------------------------------------------
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users