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

Re: [xmlvm-users] Demos Translated to JavaScript

[D S. <dav...@ya...>]

I seem to be having no end of trouble generating the app.  It seems that if the file name has a space in it, java.io.File(String) ignores the space and everything after it.  So it's telling the path assigned to the environment variable "XMLVM_QOOXDOO_PATH" doesn't exist.  The Java API documentation is oddly silent on the issue.  So after a number of futile attempts to encode/escape the space characters, I commented out the parts in org.xmlvm.proc.out.QooxdooOutputProcess.peformSanityChecks() that check if the qooxdoo directory and the app-creating script exist, rebuilt the jar file, and tried again.  XMLVM is now telling me that the output directory (build/js) isn't a valid qx project because the file build/js/temp_cache/temp_qx_app/generate.py doesn't exist.

On a related question, before I started playing around with XMLVM, I noticed that XML11 generates the JS without the need for python.  What is XML11 using to generate the app?

Thanks,

D




________________________________
From: Sascha Haeberling <sa...@xm...>
To: D Sledge <dav...@ya...>
Cc: xml...@li...
Sent: Fri, May 28, 2010 9:05:14 AM
Subject: Re: [xmlvm-users] Demos Translated to JavaScript

The way you translated the app will only give you the JS code of that single file, and not a whole app that works. In order to get an app that is usable and that contains all the required dependencies, you need to use the --target=qooxdoo flag. I am actually not sure if the AbsoluteCalculator works, I haven't tried it in a while. But I will keep this in mind and try to check it on the weekend.

// Sascha



On Fri, May 28, 2010 at 4:47 PM, D Sledge <dav...@ya...> wrote:

>
>I used the command:
>
>    java -jar "dist/xmlvm.jar" --in=build/demo/java-desktop/org/xmlvm/demo/AbsoluteCalculator.class --out=build/js --target=js
>
>It generated a single js file (org_xmlvm_demo_AbsoluteCalculator.js), but I don't see a way to specify in which HTML element to display it.  I also see it has some dependencies that where not generated with in the file, such as the objects java_lang_Object and qx.  The latter I realize is part of the qooxdoo framework, but I find that a bit perplexing since the command flag "--target=qooxdoo" specifies a qooxdoo js app.
>
>Thanks,
>
>D
>
>
>
>>
>
________________________________
From: Sascha Haeberling <sa...@xm...>
>To: D Sledge <dav...@ya...>
>Cc: xml...@li...
>Sent: Fri, May 28, 2010 4:00:26 AM
>Subject: Re: [xmlvm-users] Demos Translated to JavaScript
>
>
>>Hi D,
>
>
>how did you cross-compile the demo exactly? I ask, because there a different ways of doing it.
>
>
>Thanks
>// Sascha
>
>
>
>On Wed, May 26, 2010 at 11:52 PM, D Sledge <dav...@ya...> wrote:
>
>>>
>>So once I cross-complile one of the demos to JavaScript (specifically the Java-base AbsoluteCalculator demo), how do I see the generated script in action?
>>
>>Thanks,
>>
>>D
>>
>>
>>------------------------------------------------------------------------------
>>
>>
>>_______________________________________________
>>>>xmlvm-users mailing list
>>xml...@li...
>>https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>>
>
>
>------------------------------------------------------------------------------
>
>
>_______________________________________________
>>xmlvm-users mailing list
>xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>



      

Re: [xmlvm-users] Demos Translated to JavaScript

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

The way you translated the app will only give you the JS code of that single
file, and not a whole app that works. In order to get an app that is usable
and that contains all the required dependencies, you need to use the
--target=qooxdoo flag. I am actually not sure if the AbsoluteCalculator
works, I haven't tried it in a while. But I will keep this in mind and try
to check it on the weekend.

// Sascha


On Fri, May 28, 2010 at 4:47 PM, D Sledge <dav...@ya...> wrote:

> I used the command:
>
>     java -jar "dist/xmlvm.jar"
> --in=build/demo/java-desktop/org/xmlvm/demo/AbsoluteCalculator.class
> --out=build/js --target=js
>
> It generated a single js file (org_xmlvm_demo_AbsoluteCalculator.js), but I
> don't see a way to specify in which HTML element to display it.  I also see
> it has some dependencies that where not generated with in the file, such as
> the objects java_lang_Object and qx.  The latter I realize is part of the
> qooxdoo framework, but I find that a bit perplexing since the command flag
> "--target=qooxdoo" specifies a qooxdoo js app.
>
> Thanks,
>
> D
>
> ------------------------------
> *From:* Sascha Haeberling <sa...@xm...>
> *To:* D Sledge <dav...@ya...>
> *Cc:* xml...@li...
> *Sent:* Fri, May 28, 2010 4:00:26 AM
> *Subject:* Re: [xmlvm-users] Demos Translated to JavaScript
>
> Hi D,
>
> how did you cross-compile the demo exactly? I ask, because there a
> different ways of doing it.
>
> Thanks
> // Sascha
>
> On Wed, May 26, 2010 at 11:52 PM, D Sledge <dav...@ya...> wrote:
>
>> So once I cross-complile one of the demos to JavaScript (specifically the
>> Java-base AbsoluteCalculator demo), how do I see the generated script in
>> action?
>>
>> Thanks,
>>
>> D
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] Demos Translated to JavaScript

[D S. <dav...@ya...>]

I used the command:

    java -jar "dist/xmlvm.jar" --in=build/demo/java-desktop/org/xmlvm/demo/AbsoluteCalculator.class --out=build/js --target=js

It generated a single js file (org_xmlvm_demo_AbsoluteCalculator.js), but I don't see a way to specify in which HTML element to display it.  I also see it has some dependencies that where not generated with in the file, such as the objects java_lang_Object and qx.  The latter I realize is part of the qooxdoo framework, but I find that a bit perplexing since the command flag "--target=qooxdoo" specifies a qooxdoo js app.

Thanks,

D




________________________________
From: Sascha Haeberling <sa...@xm...>
To: D Sledge <dav...@ya...>
Cc: xml...@li...
Sent: Fri, May 28, 2010 4:00:26 AM
Subject: Re: [xmlvm-users] Demos Translated to JavaScript

Hi D,

how did you cross-compile the demo exactly? I ask, because there a different ways of doing it.

Thanks
// Sascha



On Wed, May 26, 2010 at 11:52 PM, D Sledge <dav...@ya...> wrote:

So once I cross-complile one of the demos to JavaScript (specifically the Java-base AbsoluteCalculator demo), how do I see the generated script in action?
>
>Thanks,
>
>D
>
>
>------------------------------------------------------------------------------
>
>
>_______________________________________________
>>xmlvm-users mailing list
>xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>



      

Re: [xmlvm-users] Demos Translated to JavaScript

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

Hi D,

how did you cross-compile the demo exactly? I ask, because there a different
ways of doing it.

Thanks
// Sascha

On Wed, May 26, 2010 at 11:52 PM, D Sledge <dav...@ya...> wrote:

> So once I cross-complile one of the demos to JavaScript (specifically the
> Java-base AbsoluteCalculator demo), how do I see the generated script in
> action?
>
> Thanks,
>
> D
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] will XMLVM comply with appstore for OS4?

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

you hit the hammer on the nail. This is not about iPhone applications 
with an Android-ish look-and-feel. However this is about locking in 
developers into the iPhone ecosystem and making it as difficult as 
possible to target other smartphones.

Arno


On 5/26/10 2:23 PM, Joris Verschoor wrote:
> While that's what most developers understand (esp. game developers),
> it's not what the license agreement states.
>
>
> On Wed, May 26, 2010 at 14:02, Kühn Wolfgang<wo....@en...>  wrote:
>> Hi,
>>
>>
>>
>> the note by Gergely is the most accurate synthesis concerning cross-language
>> tools and the changed
>>
>> iPhone Developer Program License Agreement.
>>
>>
>>
>> Apple has an interest to create a market for quality software which does
>> support and
>>
>> makes use of their innovative hardware.
>>
>>
>>
>> It is not in their interest to make an iDevice look like any other Android
>> or Flash gadget.
>>
>>
>>
>> So why not provide the community with tools to create iPhone specific
>> software based on the
>>
>> Java stack. And doing so by focusing on the strength of the Java (or Scala
>> or any other JVM)
>>
>> language and its tool chain, and not by emulating a particular Java
>> framework.
>>
>>
>>
>> My belief is that Apple will be less reluctant to object to this strategy
>> the less their hardware
>>
>> is exposed to most-cross-compatible applications.
>>
>>
>>
>> Greetings, Wolfgang
>>
>> ________________________________
>> Von: Gergely Kis [mailto:ger...@ma...]
>> Gesendet: Mittwoch, 26. Mai 2010 12:02
>> An: xml...@li...
>> Betreff: Re: [xmlvm-users] will XMLVM comply with appstore for OS4?
>>
>> Hi Alex,
>>
>> I am not sure it is possible to take the Android code and just recompile it
>> for the iPhone. Technically, it might be feasible with implementing as much
>> of the Android API as possible, so that "80%" of applications compile fine.
>>
>> However, the main issue is the difference in the platforms: both at the
>> framework and at the UI level.
>>
>> At framework level (just 2 examples):
>> - Android has the very powerful Intent system, iPhone has no such thing. It
>> can be emulated for intra-app intents, but for complex apps, which are
>> designed to have separate service processes ... etc. it won't work.
>> - File management concepts are different: in iPhone there is a very specific
>> structure your app has to follow in terms of file placement. On Android you
>> are much more on your own: you can use data directory, sdcard ... etc.
>>
>> At the UI level:
>> - The iPhone Human Interface Guidelines are not compatible with the Android
>> "Guidelines / Best Practices". For example: navigation bars at the top of
>> the screen, no exit function on the iPhone ... etc.
>>
>> If an application is not HIG compliant the chances are good that Apple will
>> reject it during the review process. It would also open up an "attack
>> surface" against XMLVM, because it would seem that XMLVM apps are not
>> "native" apps.
>>
>> In my opinion it would be a far better strategy to concentrate on making
>> XMLVM a porting tool, by acknowledging the fact, that
>> - you will probably have to redo the UI for each platform
>> - you will need to adapt the backend to the platforms limitations (e.g. no
>> bluetooth comms in iphone, or no in app purchase api in android)
>> - you should try to organize the software so that the majority of the code
>> still sits in the business layer, which can be moved between platforms
>> without touching it by hand.
>>
>> So in my opinion the focus should be:
>> - Provide a complete Java Iphone API, so really all iPhone features can be
>> accessed from Java
>> - Provide better tooling: This basically means incremental compilation, IDE
>> integration, JUnit support and debugger support (I think I came up a better
>> solution than Arno's proposal, I just have to write it up).
>>
>> Of course these are just my thoughts, one of the great things about
>> open-source is that everyone can work on parts they see as important, and we
>> can all put together what we have and create something great.
>>
>> What do you think?
>>
>> Best Regards,
>> Gergely
>>
>> 2010/5/26 Dr. Alexander K. Seewald<al...@se...>
>>>
>>> Sorry for the late reply, but my app is also still in the App Store
>>> and sells reasonably well...
>>> http://itunes.apple.com/de/app/id365473377
>>>
>>> Kudos to the development team to switch the license to LGPL! In fact
>>> this suggests one safe way to prevent Apple from delisting
>>> XMLVM-ported apps: porting as many apps as possible to the platform!
>>> Once there are at least a few popular apps among them, Apple will
>>> find it hard to prevent people from using XMLVM to port their apps.
>>> With the half a dozen that are currently in there, it would still be
>>> easy for Apple to "pull the plug".
>>>
>>> I hereby suggest a Google Summer-of-Code project where Android
>>> developers can contribute their app code and get iPhone versions
>>> back. These could be made available as free apps via the development
>>> team's account (since a lot of people might not want to install
>>> XCode/MacOS and get an iPhone for testing) or given back to the
>>> developers to list on their own (this could now also be done for
>>> paid apps). Instead of porting one app at a time, we'd create tools
>>> to port a lot of apps at once and address remaining issues with XMLVM
>>> by highest frequency first. The goal would be to plug in the Android code
>>> and get out the iPhone code without any changes in the application. Surely
>>> Google should be interested in that, perhaps we can get a contribute
>>> your code link on the main Android development page? ;-)
>>>
>>> I can help with scripting and automating the porting of so many apps,
>>> also with compiling (I've got an VMWare image w/ MacOS/XCode for
>>> Intel - debugging does not work on AMD, everything else does). Some
>>> local people here in Austria have also expressed interest. I don't
>>> have a clue what needs to be done to set up a Summer-of-Code
>>> project, or how best to get developers to contribute their Android
>>> code for porting. I am afraid we are too late for this year, but
>>> perhaps next year would be a ok.
>>>
>>> Best,
>>>   Alex
>>> --
>>> Dr. Alexander K. Seewald
>>>
>>> Seewald Solutions
>>> www.seewald.at
>>> Tel. +43(664)1106886
>>> Fax. +43(1)2533033/2764
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> xmlvm-users mailing list
>>> xml...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>>
>>
>> --
>> Kis Gergely
>> MattaKis Consulting
>> Email: ger...@ma...
>> Web: http://www.mattakis.com
>> Phone: +36 70 408 1723
>> Fax: +36 27 998 622
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] Demos Translated to JavaScript

[D S. <dav...@ya...>]

So once I cross-complile one of the demos to JavaScript (specifically the Java-base AbsoluteCalculator demo), how do I see the generated script in action?

Thanks,

D



      

Re: [xmlvm-users] will XMLVM comply with appstore for OS4?

[Joris V. <jbv...@gm...>]

While that's what most developers understand (esp. game developers),
it's not what the license agreement states.


On Wed, May 26, 2010 at 14:02, Kühn Wolfgang <wo....@en...> wrote:
> Hi,
>
>
>
> the note by Gergely is the most accurate synthesis concerning cross-language
> tools and the changed
>
> iPhone Developer Program License Agreement.
>
>
>
> Apple has an interest to create a market for quality software which does
> support and
>
> makes use of their innovative hardware.
>
>
>
> It is not in their interest to make an iDevice look like any other Android
> or Flash gadget.
>
>
>
> So why not provide the community with tools to create iPhone specific
> software based on the
>
> Java stack. And doing so by focusing on the strength of the Java (or Scala
> or any other JVM)
>
> language and its tool chain, and not by emulating a particular Java
> framework.
>
>
>
> My belief is that Apple will be less reluctant to object to this strategy
> the less their hardware
>
> is exposed to most-cross-compatible applications.
>
>
>
> Greetings, Wolfgang
>
> ________________________________
> Von: Gergely Kis [mailto:ger...@ma...]
> Gesendet: Mittwoch, 26. Mai 2010 12:02
> An: xml...@li...
> Betreff: Re: [xmlvm-users] will XMLVM comply with appstore for OS4?
>
> Hi Alex,
>
> I am not sure it is possible to take the Android code and just recompile it
> for the iPhone. Technically, it might be feasible with implementing as much
> of the Android API as possible, so that "80%" of applications compile fine.
>
> However, the main issue is the difference in the platforms: both at the
> framework and at the UI level.
>
> At framework level (just 2 examples):
> - Android has the very powerful Intent system, iPhone has no such thing. It
> can be emulated for intra-app intents, but for complex apps, which are
> designed to have separate service processes ... etc. it won't work.
> - File management concepts are different: in iPhone there is a very specific
> structure your app has to follow in terms of file placement. On Android you
> are much more on your own: you can use data directory, sdcard ... etc.
>
> At the UI level:
> - The iPhone Human Interface Guidelines are not compatible with the Android
> "Guidelines / Best Practices". For example: navigation bars at the top of
> the screen, no exit function on the iPhone ... etc.
>
> If an application is not HIG compliant the chances are good that Apple will
> reject it during the review process. It would also open up an "attack
> surface" against XMLVM, because it would seem that XMLVM apps are not
> "native" apps.
>
> In my opinion it would be a far better strategy to concentrate on making
> XMLVM a porting tool, by acknowledging the fact, that
> - you will probably have to redo the UI for each platform
> - you will need to adapt the backend to the platforms limitations (e.g. no
> bluetooth comms in iphone, or no in app purchase api in android)
> - you should try to organize the software so that the majority of the code
> still sits in the business layer, which can be moved between platforms
> without touching it by hand.
>
> So in my opinion the focus should be:
> - Provide a complete Java Iphone API, so really all iPhone features can be
> accessed from Java
> - Provide better tooling: This basically means incremental compilation, IDE
> integration, JUnit support and debugger support (I think I came up a better
> solution than Arno's proposal, I just have to write it up).
>
> Of course these are just my thoughts, one of the great things about
> open-source is that everyone can work on parts they see as important, and we
> can all put together what we have and create something great.
>
> What do you think?
>
> Best Regards,
> Gergely
>
> 2010/5/26 Dr. Alexander K. Seewald <al...@se...>
>>
>> Sorry for the late reply, but my app is also still in the App Store
>> and sells reasonably well...
>> http://itunes.apple.com/de/app/id365473377
>>
>> Kudos to the development team to switch the license to LGPL! In fact
>> this suggests one safe way to prevent Apple from delisting
>> XMLVM-ported apps: porting as many apps as possible to the platform!
>> Once there are at least a few popular apps among them, Apple will
>> find it hard to prevent people from using XMLVM to port their apps.
>> With the half a dozen that are currently in there, it would still be
>> easy for Apple to "pull the plug".
>>
>> I hereby suggest a Google Summer-of-Code project where Android
>> developers can contribute their app code and get iPhone versions
>> back. These could be made available as free apps via the development
>> team's account (since a lot of people might not want to install
>> XCode/MacOS and get an iPhone for testing) or given back to the
>> developers to list on their own (this could now also be done for
>> paid apps). Instead of porting one app at a time, we'd create tools
>> to port a lot of apps at once and address remaining issues with XMLVM
>> by highest frequency first. The goal would be to plug in the Android code
>> and get out the iPhone code without any changes in the application. Surely
>> Google should be interested in that, perhaps we can get a contribute
>> your code link on the main Android development page? ;-)
>>
>> I can help with scripting and automating the porting of so many apps,
>> also with compiling (I've got an VMWare image w/ MacOS/XCode for
>> Intel - debugging does not work on AMD, everything else does). Some
>> local people here in Austria have also expressed interest. I don't
>> have a clue what needs to be done to set up a Summer-of-Code
>> project, or how best to get developers to contribute their Android
>> code for porting. I am afraid we are too late for this year, but
>> perhaps next year would be a ok.
>>
>> Best,
>>  Alex
>> --
>> Dr. Alexander K. Seewald
>>
>> Seewald Solutions
>> www.seewald.at
>> Tel. +43(664)1106886
>> Fax. +43(1)2533033/2764
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
> --
> Kis Gergely
> MattaKis Consulting
> Email: ger...@ma...
> Web: http://www.mattakis.com
> Phone: +36 70 408 1723
> Fax: +36 27 998 622
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] will XMLVM comply with appstore for OS4?

[Kühn W. <wo....@en...>]

Hi,

the note by Gergely is the most accurate synthesis concerning cross-language tools and the changed
iPhone Developer Program License Agreement.

Apple has an interest to create a market for quality software which does support and
makes use of their innovative hardware.

It is not in their interest to make an iDevice look like any other Android or Flash gadget.

So why not provide the community with tools to create iPhone specific software based on the
Java stack. And doing so by focusing on the strength of the Java (or Scala or any other JVM)
language and its tool chain, and not by emulating a particular Java framework.

My belief is that Apple will be less reluctant to object to this strategy the less their hardware
is exposed to most-cross-compatible applications.

Greetings, Wolfgang

________________________________
Von: Gergely Kis [mailto:ger...@ma...]
Gesendet: Mittwoch, 26. Mai 2010 12:02
An: xml...@li...
Betreff: Re: [xmlvm-users] will XMLVM comply with appstore for OS4?

Hi Alex,

I am not sure it is possible to take the Android code and just recompile it for the iPhone. Technically, it might be feasible with implementing as much of the Android API as possible, so that "80%" of applications compile fine.

However, the main issue is the difference in the platforms: both at the framework and at the UI level.

At framework level (just 2 examples):
- Android has the very powerful Intent system, iPhone has no such thing. It can be emulated for intra-app intents, but for complex apps, which are designed to have separate service processes ... etc. it won't work.
- File management concepts are different: in iPhone there is a very specific structure your app has to follow in terms of file placement. On Android you are much more on your own: you can use data directory, sdcard ... etc.

At the UI level:
- The iPhone Human Interface Guidelines are not compatible with the Android "Guidelines / Best Practices". For example: navigation bars at the top of the screen, no exit function on the iPhone ... etc.

If an application is not HIG compliant the chances are good that Apple will reject it during the review process. It would also open up an "attack surface" against XMLVM, because it would seem that XMLVM apps are not "native" apps.

In my opinion it would be a far better strategy to concentrate on making XMLVM a porting tool, by acknowledging the fact, that
- you will probably have to redo the UI for each platform
- you will need to adapt the backend to the platforms limitations (e.g. no bluetooth comms in iphone, or no in app purchase api in android)
- you should try to organize the software so that the majority of the code still sits in the business layer, which can be moved between platforms without touching it by hand.

So in my opinion the focus should be:
- Provide a complete Java Iphone API, so really all iPhone features can be accessed from Java
- Provide better tooling: This basically means incremental compilation, IDE integration, JUnit support and debugger support (I think I came up a better solution than Arno's proposal, I just have to write it up).

Of course these are just my thoughts, one of the great things about open-source is that everyone can work on parts they see as important, and we can all put together what we have and create something great.

What do you think?

Best Regards,
Gergely

2010/5/26 Dr. Alexander K. Seewald <al...@se...<mailto:al...@se...>>
Sorry for the late reply, but my app is also still in the App Store
and sells reasonably well...
http://itunes.apple.com/de/app/id365473377

Kudos to the development team to switch the license to LGPL! In fact
this suggests one safe way to prevent Apple from delisting
XMLVM-ported apps: porting as many apps as possible to the platform!
Once there are at least a few popular apps among them, Apple will
find it hard to prevent people from using XMLVM to port their apps.
With the half a dozen that are currently in there, it would still be
easy for Apple to "pull the plug".

I hereby suggest a Google Summer-of-Code project where Android
developers can contribute their app code and get iPhone versions
back. These could be made available as free apps via the development
team's account (since a lot of people might not want to install
XCode/MacOS and get an iPhone for testing) or given back to the
developers to list on their own (this could now also be done for
paid apps). Instead of porting one app at a time, we'd create tools
to port a lot of apps at once and address remaining issues with XMLVM
by highest frequency first. The goal would be to plug in the Android code
and get out the iPhone code without any changes in the application. Surely
Google should be interested in that, perhaps we can get a contribute
your code link on the main Android development page? ;-)

I can help with scripting and automating the porting of so many apps,
also with compiling (I've got an VMWare image w/ MacOS/XCode for
Intel - debugging does not work on AMD, everything else does). Some
local people here in Austria have also expressed interest. I don't
have a clue what needs to be done to set up a Summer-of-Code
project, or how best to get developers to contribute their Android
code for porting. I am afraid we are too late for this year, but
perhaps next year would be a ok.

Best,
 Alex
--
Dr. Alexander K. Seewald

Seewald Solutions
www.seewald.at<http://www.seewald.at>
Tel. +43(664)1106886
Fax. +43(1)2533033/2764

------------------------------------------------------------------------------

_______________________________________________
xmlvm-users mailing list
xml...@li...<mailto:xml...@li...>
https://lists.sourceforge.net/lists/listinfo/xmlvm-users



--
Kis Gergely
MattaKis Consulting
Email: ger...@ma...<mailto:ger...@ma...>
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

Re: [xmlvm-users] will XMLVM comply with appstore for OS4?

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

On 26 Μαϊ 2010, at 1:02 ΜΜ, Gergely Kis wrote:
>
> - Provide better tooling: This basically means incremental  
> compilation,


This is done already (at least for the obj-c part)  :)

Re: [xmlvm-users] will XMLVM comply with appstore for OS4?

[Gergely K. <ger...@ma...>]

Hi Alex,

I am not sure it is possible to take the Android code and just recompile it
for the iPhone. Technically, it might be feasible with implementing as much
of the Android API as possible, so that "80%" of applications compile fine.

However, the main issue is the difference in the platforms: both at the
framework and at the UI level.

At framework level (just 2 examples):
- Android has the very powerful Intent system, iPhone has no such thing. It
can be emulated for intra-app intents, but for complex apps, which are
designed to have separate service processes ... etc. it won't work.
- File management concepts are different: in iPhone there is a very specific
structure your app has to follow in terms of file placement. On Android you
are much more on your own: you can use data directory, sdcard ... etc.

At the UI level:
- The iPhone Human Interface Guidelines are not compatible with the Android
"Guidelines / Best Practices". For example: navigation bars at the top of
the screen, no exit function on the iPhone ... etc.

If an application is not HIG compliant the chances are good that Apple will
reject it during the review process. It would also open up an "attack
surface" against XMLVM, because it would seem that XMLVM apps are not
"native" apps.

In my opinion it would be a far better strategy to concentrate on making
XMLVM a porting tool, by acknowledging the fact, that
- you will probably have to redo the UI for each platform
- you will need to adapt the backend to the platforms limitations (e.g. no
bluetooth comms in iphone, or no in app purchase api in android)
- you should try to organize the software so that the majority of the code
still sits in the business layer, which can be moved between platforms
without touching it by hand.

So in my opinion the focus should be:
- Provide a complete Java Iphone API, so really all iPhone features can be
accessed from Java
- Provide better tooling: This basically means incremental compilation, IDE
integration, JUnit support and debugger support (I think I came up a better
solution than Arno's proposal, I just have to write it up).

Of course these are just my thoughts, one of the great things about
open-source is that everyone can work on parts they see as important, and we
can all put together what we have and create something great.

What do you think?

Best Regards,
Gergely

2010/5/26 Dr. Alexander K. Seewald <al...@se...>

> Sorry for the late reply, but my app is also still in the App Store
> and sells reasonably well...
> http://itunes.apple.com/de/app/id365473377
>
> Kudos to the development team to switch the license to LGPL! In fact
> this suggests one safe way to prevent Apple from delisting
> XMLVM-ported apps: porting as many apps as possible to the platform!
> Once there are at least a few popular apps among them, Apple will
> find it hard to prevent people from using XMLVM to port their apps.
> With the half a dozen that are currently in there, it would still be
> easy for Apple to "pull the plug".
>
> I hereby suggest a Google Summer-of-Code project where Android
> developers can contribute their app code and get iPhone versions
> back. These could be made available as free apps via the development
> team's account (since a lot of people might not want to install
> XCode/MacOS and get an iPhone for testing) or given back to the
> developers to list on their own (this could now also be done for
> paid apps). Instead of porting one app at a time, we'd create tools
> to port a lot of apps at once and address remaining issues with XMLVM
> by highest frequency first. The goal would be to plug in the Android code
> and get out the iPhone code without any changes in the application. Surely
> Google should be interested in that, perhaps we can get a contribute
> your code link on the main Android development page? ;-)
>
> I can help with scripting and automating the porting of so many apps,
> also with compiling (I've got an VMWare image w/ MacOS/XCode for
> Intel - debugging does not work on AMD, everything else does). Some
> local people here in Austria have also expressed interest. I don't
> have a clue what needs to be done to set up a Summer-of-Code
> project, or how best to get developers to contribute their Android
> code for porting. I am afraid we are too late for this year, but
> perhaps next year would be a ok.
>
> Best,
>  Alex
> --
> Dr. Alexander K. Seewald
>
> Seewald Solutions
> www.seewald.at
> Tel. +43(664)1106886
> Fax. +43(1)2533033/2764
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>



-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

Re: [xmlvm-users] will XMLVM comply with appstore for OS4?

[Dr. A. K. S. <al...@se...>]

Sorry for the late reply, but my app is also still in the App Store
and sells reasonably well...
http://itunes.apple.com/de/app/id365473377

Kudos to the development team to switch the license to LGPL! In fact
this suggests one safe way to prevent Apple from delisting
XMLVM-ported apps: porting as many apps as possible to the platform!
Once there are at least a few popular apps among them, Apple will
find it hard to prevent people from using XMLVM to port their apps.
With the half a dozen that are currently in there, it would still be
easy for Apple to "pull the plug".

I hereby suggest a Google Summer-of-Code project where Android
developers can contribute their app code and get iPhone versions
back. These could be made available as free apps via the development
team's account (since a lot of people might not want to install
XCode/MacOS and get an iPhone for testing) or given back to the
developers to list on their own (this could now also be done for
paid apps). Instead of porting one app at a time, we'd create tools
to port a lot of apps at once and address remaining issues with XMLVM
by highest frequency first. The goal would be to plug in the Android code
and get out the iPhone code without any changes in the application. Surely
Google should be interested in that, perhaps we can get a contribute
your code link on the main Android development page? ;-)

I can help with scripting and automating the porting of so many apps,
also with compiling (I've got an VMWare image w/ MacOS/XCode for
Intel - debugging does not work on AMD, everything else does). Some
local people here in Austria have also expressed interest. I don't
have a clue what needs to be done to set up a Summer-of-Code
project, or how best to get developers to contribute their Android
code for porting. I am afraid we are too late for this year, but
perhaps next year would be a ok.

Best,
  Alex
-- 
Dr. Alexander K. Seewald

Seewald Solutions
www.seewald.at
Tel. +43(664)1106886
Fax. +43(1)2533033/2764

Re: [xmlvm-users] SecureTextEntry...

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

On 25 Μαϊ 2010, at 10:05 μ.μ., Gergely Kis wrote:

> Hi,
> 
> I think, that we should eventually abandon the Java Simulator (I refuse to call it an emulator, because it is not that good :) ). We first ported our application to work with it, but the fact, that your app works with this Java Simulator tells you almost nothing about whether it will work on the actual device.

I, on the other hand, like the idea of the simulator :)
It really helps to prototype your application in other OS'es, even if only little bits of the UI interface are there. 
Although right now I don't work on it, I believe that this is something that for the time being shouldn't be abandoned :) 

Re: [xmlvm-users] memory bug found

[Gergely K. <ger...@ma...>]

Hi,

Actually it might make sense to add a set of -O compiler flags, so that it
is easier for the users to experiment with it, but the default settings
would generate "safe" code. What do you think?

Best Regards,
Gergely

2010/5/25 Arno Puder <ar...@pu...>

>
> I just commented out the faulty optimization in the repository. I don't
> think it makes sense to add a parameter for something that doesn't work.
>
> Arno
>
>
> On 5/25/10 8:22 AM, Panayotis Katsaloulis wrote:
> >
> > On 24 Μαϊ 2010, at 8:19 μ.μ., Joshua Melcon wrote:
> >
> >> Panayotis,
> >>
> >> This particular issue can occur in a variety of places.  In general
> >> they are very hard to detect unless you get lucky at runtime.  I
> >> strongly recommend commenting out:
> >>>> // new ExcessRetainsOptimization().Process(curRun.allCodePaths,
> curRun.beenTo,
> >>>> //            codeElement);
> >>
> >> in order to prevent any other nasty surprises.
> >>
> >> Regards,
> >>
> >> -- Joshua Melcon
> >>
> >
> >
> > Probably then this should be default for xmlvm?
> > Or what about a (hidden/advanced?)  parameter for xmlvm which will turn
> this on and off?
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>



-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

Re: [xmlvm-users] SecureTextEntry...

[Gergely K. <ger...@ma...>]

Hi,

I think, that we should eventually abandon the Java Simulator (I refuse to
call it an emulator, because it is not that good :) ). We first ported our
application to work with it, but the fact, that your app works with this
Java Simulator tells you almost nothing about whether it will work on the
actual device.

Actually the most porting work that you will have to do is the
implementation of missing standard Java API classes. Mapping missing UIKit
widgets is mostly straightforward.

Of course, if you don't have a Mac, you don't have many options. You will
need to get one anyway, otherwise you can't compile the native code.

One possibility would be to implement a "real" simulator using e.g. the
Cocotron libraries: www.cocotron.org
Of course they mostly concentrated on desktop APIs now, but something has
already started in the UIKit direction:
http://groups.google.com/group/cocotron-dev/browse_thread/thread/d6c51ebbec4ef0ce/f4f12b9ff69bf15b?lnk=gst&q=UIKit#f4f12b9ff69bf15b

Best Regards,
Gergely

PS: Could the list settings be changed to set reply-to to the list?

2010/5/25 Arno Puder <ar...@pu...>

>
> please upload your patch to the review system (info on our homepage).
>
> I forgot to mention one detail regarding the discussion of our Java
> emulator. We support affine transformations and because of that we
> cannot make use of Swing widgets. You would have to implement new Cocoa
> Touch widgets based on Java 2D.
>
> Arno
>
>
> On 5/25/10 4:09 PM, Adrian Buerki wrote:
> > Hi guys
> >
> > Okay, I am going to prepare and submit a patch.
> >
> > I'm mostly working on Linux and use the Java emulator a lot.
> >
> > I'm not very far with my iPhone project yet. If I find missing widgets
> > as I go, I have no problem providing those widgets for the Java
> > emulator. XMLVM is an open source project, so I get something and I am
> > happy to give something back :-)
> >
> > Regards, Adrian
> >
> > 2010/5/23 Arno Puder<ar...@pu...>:
> >>
> >> that is certainly true: unlike Xcode, the Java emulator allows you to
> >> develop on platforms other than Mac OS. Doing 'simplified'
> >> implementations of the UI widgets is also sensible. Well, hopefully
> >> someone has the calling to work on that.  :-)
> >>
> >> Arno
> >>
> >>
> >> On 5/23/10 7:02 PM, George Smith wrote:
> >>>
> >>> One of the important (to me and my partners) features of XMLVM was the
> >>> ability to "mostly" develop an App for the iPhone/iPad on a developer's
> >>> existing systems (be they Mac, Linux, or even Windows).  IMO, this does
> NOT
> >>> mean that every Cocoa/Objective-C widget/class must have a fully
> functioning
> >>> and UI simulating Java Emulator stand-in, but that there should be a
> >>> marginally UI functional API conformant stand-in.  An example might be
> a
> >>> Spin-Picker in Cocoa that renders as an appropriately sized and placed
> >>> colored box, with JTextField or JComboBox in it.
> >>>
> >>> My $0.02, George Smith
> >>>
> >>> -----Original Message-----
> >>> From: Arno Puder [mailto:ar...@pu...]
> >>> Sent: Sunday, May 23, 2010 9:36 AM
> >>> To: xml...@li...
> >>> Subject: Re: [xmlvm-users] SecureTextEntry...
> >>>
> >>>
> >>>
> >>> On 5/23/10 6:11 PM, Adrian Buerki wrote:
> >>>> There is a property secureTextEntry in the class UITextField. Seems
> >>>> like that is the password field support I was looking for. However
> >>>> this does not work in the iPhone Java emulator. I assume the problem
> >>>> is just in the emulator, once cross compiled the text field would
> >>>> behave correctly?
> >>>
> >>> the Objective-C side does what it is supposed to do. This feature is
> not
> >>> implemented in the Java emulator, as you have noticed.
> >>>
> >>> That feature is easy to implement in the Java emulator and your patch
> is
> >>> most certainly welcome. However, the question remains how far to push
> >>> our Java emulator. The problem is that there are many very unique UI
> >>> widgets in the iPhone SDK and it would mean a lot of work to provide a
> >>> Java implementation. All of the new widgets Panayotis has implemented
> >>> are only available on the Objective-C side. If someone feels the urge
> to
> >>> do a Java version, what would certainly be nice.
> >>>
> >>> A few weeks ago I proposed a debugging architecture for XMLVM. The
> >>> benefit of the proposal would be that we can leverage Apple's own
> iPhone
> >>> emulator (or even the actual device) and there would be no need for our
> >>> Java emulator. I still hope to do that one day.
> >>>
> >>> Arno
> >>>
> >>>
> ----------------------------------------------------------------------------
> >>> --
> >>>
> >>> _______________________________________________
> >>> xmlvm-users mailing list
> >>> xml...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >>>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> xmlvm-users mailing list
> >> xml...@li...
> >> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >>
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>



-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

Re: [xmlvm-users] SecureTextEntry...

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

please upload your patch to the review system (info on our homepage).

I forgot to mention one detail regarding the discussion of our Java 
emulator. We support affine transformations and because of that we 
cannot make use of Swing widgets. You would have to implement new Cocoa 
Touch widgets based on Java 2D.

Arno


On 5/25/10 4:09 PM, Adrian Buerki wrote:
> Hi guys
>
> Okay, I am going to prepare and submit a patch.
>
> I'm mostly working on Linux and use the Java emulator a lot.
>
> I'm not very far with my iPhone project yet. If I find missing widgets
> as I go, I have no problem providing those widgets for the Java
> emulator. XMLVM is an open source project, so I get something and I am
> happy to give something back :-)
>
> Regards, Adrian
>
> 2010/5/23 Arno Puder<ar...@pu...>:
>>
>> that is certainly true: unlike Xcode, the Java emulator allows you to
>> develop on platforms other than Mac OS. Doing 'simplified'
>> implementations of the UI widgets is also sensible. Well, hopefully
>> someone has the calling to work on that.  :-)
>>
>> Arno
>>
>>
>> On 5/23/10 7:02 PM, George Smith wrote:
>>>
>>> One of the important (to me and my partners) features of XMLVM was the
>>> ability to "mostly" develop an App for the iPhone/iPad on a developer's
>>> existing systems (be they Mac, Linux, or even Windows).  IMO, this does NOT
>>> mean that every Cocoa/Objective-C widget/class must have a fully functioning
>>> and UI simulating Java Emulator stand-in, but that there should be a
>>> marginally UI functional API conformant stand-in.  An example might be a
>>> Spin-Picker in Cocoa that renders as an appropriately sized and placed
>>> colored box, with JTextField or JComboBox in it.
>>>
>>> My $0.02, George Smith
>>>
>>> -----Original Message-----
>>> From: Arno Puder [mailto:ar...@pu...]
>>> Sent: Sunday, May 23, 2010 9:36 AM
>>> To: xml...@li...
>>> Subject: Re: [xmlvm-users] SecureTextEntry...
>>>
>>>
>>>
>>> On 5/23/10 6:11 PM, Adrian Buerki wrote:
>>>> There is a property secureTextEntry in the class UITextField. Seems
>>>> like that is the password field support I was looking for. However
>>>> this does not work in the iPhone Java emulator. I assume the problem
>>>> is just in the emulator, once cross compiled the text field would
>>>> behave correctly?
>>>
>>> the Objective-C side does what it is supposed to do. This feature is not
>>> implemented in the Java emulator, as you have noticed.
>>>
>>> That feature is easy to implement in the Java emulator and your patch is
>>> most certainly welcome. However, the question remains how far to push
>>> our Java emulator. The problem is that there are many very unique UI
>>> widgets in the iPhone SDK and it would mean a lot of work to provide a
>>> Java implementation. All of the new widgets Panayotis has implemented
>>> are only available on the Objective-C side. If someone feels the urge to
>>> do a Java version, what would certainly be nice.
>>>
>>> A few weeks ago I proposed a debugging architecture for XMLVM. The
>>> benefit of the proposal would be that we can leverage Apple's own iPhone
>>> emulator (or even the actual device) and there would be no need for our
>>> Java emulator. I still hope to do that one day.
>>>
>>> Arno
>>>
>>> ----------------------------------------------------------------------------
>>> --
>>>
>>> _______________________________________________
>>> xmlvm-users mailing list
>>> xml...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] SecureTextEntry...

[Adrian B. <kil...@gm...>]

Hi guys

Okay, I am going to prepare and submit a patch.

I'm mostly working on Linux and use the Java emulator a lot.

I'm not very far with my iPhone project yet. If I find missing widgets
as I go, I have no problem providing those widgets for the Java
emulator. XMLVM is an open source project, so I get something and I am
happy to give something back :-)

Regards, Adrian

2010/5/23 Arno Puder <ar...@pu...>:
>
> that is certainly true: unlike Xcode, the Java emulator allows you to
> develop on platforms other than Mac OS. Doing 'simplified'
> implementations of the UI widgets is also sensible. Well, hopefully
> someone has the calling to work on that.  :-)
>
> Arno
>
>
> On 5/23/10 7:02 PM, George Smith wrote:
>>
>> One of the important (to me and my partners) features of XMLVM was the
>> ability to "mostly" develop an App for the iPhone/iPad on a developer's
>> existing systems (be they Mac, Linux, or even Windows).  IMO, this does NOT
>> mean that every Cocoa/Objective-C widget/class must have a fully functioning
>> and UI simulating Java Emulator stand-in, but that there should be a
>> marginally UI functional API conformant stand-in.  An example might be a
>> Spin-Picker in Cocoa that renders as an appropriately sized and placed
>> colored box, with JTextField or JComboBox in it.
>>
>> My $0.02, George Smith
>>
>> -----Original Message-----
>> From: Arno Puder [mailto:ar...@pu...]
>> Sent: Sunday, May 23, 2010 9:36 AM
>> To: xml...@li...
>> Subject: Re: [xmlvm-users] SecureTextEntry...
>>
>>
>>
>> On 5/23/10 6:11 PM, Adrian Buerki wrote:
>>> There is a property secureTextEntry in the class UITextField. Seems
>>> like that is the password field support I was looking for. However
>>> this does not work in the iPhone Java emulator. I assume the problem
>>> is just in the emulator, once cross compiled the text field would
>>> behave correctly?
>>
>> the Objective-C side does what it is supposed to do. This feature is not
>> implemented in the Java emulator, as you have noticed.
>>
>> That feature is easy to implement in the Java emulator and your patch is
>> most certainly welcome. However, the question remains how far to push
>> our Java emulator. The problem is that there are many very unique UI
>> widgets in the iPhone SDK and it would mean a lot of work to provide a
>> Java implementation. All of the new widgets Panayotis has implemented
>> are only available on the Objective-C side. If someone feels the urge to
>> do a Java version, what would certainly be nice.
>>
>> A few weeks ago I proposed a debugging architecture for XMLVM. The
>> benefit of the proposal would be that we can leverage Apple's own iPhone
>> emulator (or even the actual device) and there would be no need for our
>> Java emulator. I still hope to do that one day.
>>
>> Arno
>>
>> ----------------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] memory bug found

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

I just commented out the faulty optimization in the repository. I don't 
think it makes sense to add a parameter for something that doesn't work.

Arno


On 5/25/10 8:22 AM, Panayotis Katsaloulis wrote:
>
> On 24 Μαϊ 2010, at 8:19 μ.μ., Joshua Melcon wrote:
>
>> Panayotis,
>>
>> This particular issue can occur in a variety of places.  In general
>> they are very hard to detect unless you get lucky at runtime.  I
>> strongly recommend commenting out:
>>>> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo,
>>>> //            codeElement);
>>
>> in order to prevent any other nasty surprises.
>>
>> Regards,
>>
>> -- Joshua Melcon
>>
>
>
> Probably then this should be default for xmlvm?
> Or what about a (hidden/advanced?)  parameter for xmlvm which will turn this on and off?
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] memory bug found

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

On 24 Μαϊ 2010, at 8:19 μ.μ., Joshua Melcon wrote:

> Panayotis,
> 
> This particular issue can occur in a variety of places.  In general
> they are very hard to detect unless you get lucky at runtime.  I
> strongly recommend commenting out:
>>> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo,
>>> //            codeElement);
> 
> in order to prevent any other nasty surprises.
> 
> Regards,
> 
> -- Joshua Melcon
> 


Probably then this should be default for xmlvm?
Or what about a (hidden/advanced?)  parameter for xmlvm which will turn this on and off?

Re: [xmlvm-users] memory bug found

[Joshua M. <xm...@me...>]

Panayotis,

This particular issue can occur in a variety of places.  In general
they are very hard to detect unless you get lucky at runtime.  I
strongly recommend commenting out:
>> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo,
>> //            codeElement);

in order to prevent any other nasty surprises.

Regards,

-- Joshua Melcon



2010/5/24 Panayotis Katsaloulis <pan...@pa...>:
>
> On 24 Μαϊ 2010, at 7:16 μ.μ., Joshua Melcon wrote:
>
>> Hi Panayotis,
>>
>> I am aware of this issue and have been working on a fix for it.
>> Sadly, the fix is non trivial though I am making (slow) progress on
>> it.
>>
>> For now, the best workaround is to comment out
>> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo,
>> //            codeElement);
>>
>> in ReferenceCounting.java.
>>
>> Since this bug is affecting people, I will talk to Arno about checking
>> in that workaround until I can actually implement a correct fix.
>>
>> Sorry you encountered this...
>
> The good thing is someone is working on it (the bad is that I spent 4 hours to understand why my application didn't work with latest version of xmlvm :-o )
>
> As with my previous e-mail, I'll suggest a simple fix for this: every time an object is referenced this way, retain this object and keep track of it, as with other objects. When this is no longer needed, release it.
> Probably of course it gets more complex than this :)
>
> For now, I preferred to do it the "hard" way - just retain this object and release it later on (yes, yes, with my newest shiny patch :P )
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] memory bug found

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

On 24 Μαϊ 2010, at 7:16 μ.μ., Joshua Melcon wrote:

> Hi Panayotis,
> 
> I am aware of this issue and have been working on a fix for it.
> Sadly, the fix is non trivial though I am making (slow) progress on
> it.
> 
> For now, the best workaround is to comment out
> // new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo,
> //		codeElement);
> 
> in ReferenceCounting.java.
> 
> Since this bug is affecting people, I will talk to Arno about checking
> in that workaround until I can actually implement a correct fix.
> 
> Sorry you encountered this…

The good thing is someone is working on it (the bad is that I spent 4 hours to understand why my application didn't work with latest version of xmlvm :-o )

As with my previous e-mail, I'll suggest a simple fix for this: every time an object is referenced this way, retain this object and keep track of it, as with other objects. When this is no longer needed, release it.
Probably of course it gets more complex than this :)

For now, I preferred to do it the "hard" way - just retain this object and release it later on (yes, yes, with my newest shiny patch :P )

Re: [xmlvm-users] memory bug found

[Joshua M. <xm...@me...>]

Hi Panayotis,

I am aware of this issue and have been working on a fix for it.
Sadly, the fix is non trivial though I am making (slow) progress on
it.

For now, the best workaround is to comment out
// new ExcessRetainsOptimization().Process(curRun.allCodePaths, curRun.beenTo,
//		codeElement);

in ReferenceCounting.java.

Since this bug is affecting people, I will talk to Arno about checking
in that workaround until I can actually implement a correct fix.

Sorry you encountered this...

-- Joshua Melcon



On Mon, May 24, 2010 at 6:28 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:
> I think I found a serious memory bug with current implementation of xmlvm.
>
> Here is the minimum java code to reproduce this bug:
>
> package xmlvm;
> import org.xmlvm.iphone.UIApplication;
> import org.xmlvm.iphone.UIView;
>
> public class Main extends UIApplication {
>    public void applicationDidFinishLaunching(UIApplication app) {
>        testView view = new testView();
>    }
>    public static void main(String[] args) {
>        UIApplication.main(args, Main.class);
>    }
>    public class testView extends UIView {
>        public testView() {
>            System.out.println(getFrame().size);
>        }
>    }
> }
>
>
> the initialization code of testView produces this code:
>
> - (void) __init_xmlvm_Main_testView___xmlvm_Main :(xmlvm_Main*)n1
> {
>    XMLVMElem _rtmp;
>    XMLVMElem _r0;
>    XMLVMElem _r1;
>    XMLVMElem _r2;
>    XMLVMElem _r3;
>    _r2.o = self;
>    _r3.o = n1;
>    _r0.o = JAVA_NULL;
>    _r1.o = JAVA_NULL;
>    [_r3.o retain];
>    [((xmlvm_Main_testView*) _r2.o)->this_0_xmlvm_Main release];
>    ((xmlvm_Main_testView*) _r2.o)->this_0_xmlvm_Main = _r3.o;
>    [((org_xmlvm_iphone_UIView*) _r2.o) __init_org_xmlvm_iphone_UIView__];
>    _r0.o = [java_lang_System _GET_out];
>    _r1.o = [((xmlvm_Main_testView*) _r2.o) getFrame__];
>    _rtmp.o =  _r1.o;
>    _r1.o = ((org_xmlvm_iphone_CGRect*) _r1.o)->size_org_xmlvm_iphone_CGSize;
>    [_rtmp.o release];
>    _rtmp.o = JAVA_NULL;
>    [((java_io_PrintStream*) _r0.o) println___java_lang_Object:_r1.o];
>    return;
> }
>
>
>
> Now, let me copy & paste the code and add some comments, to describe it:
> // perform getFrame()
>    _r1.o = [((xmlvm_Main_testView*) _r2.o) getFrame__];
>
> // keep result of getFrame() into temporary variable _rtmp
>    _rtmp.o =  _r1.o;
>
> // frame's size is received from the structure
>    _r1.o = ((org_xmlvm_iphone_CGRect*) _r1.o)->size_org_xmlvm_iphone_CGSize;
>
> // **release frame ** - here is the bug
>    [_rtmp.o release];
>    _rtmp.o = JAVA_NULL;
>
> // Use CGSize data, although the structure that was encapsulating it (the frame) is already freed!
>    [((java_io_PrintStream*) _r0.o) println___java_lang_Object:_r1.o];
>
>
>
> It seems that objects whose member items are used later on, should also be tracked and released ONLY after the inside items are not used any more!
> Or, even better, every time a reference with the -> operator is made, also retain this object and properly release it afterwards.
>
> What others do say?
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

[xmlvm-users] memory bug found

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

I think I found a serious memory bug with current implementation of xmlvm.

Here is the minimum java code to reproduce this bug:

package xmlvm;
import org.xmlvm.iphone.UIApplication;
import org.xmlvm.iphone.UIView;

public class Main extends UIApplication {
    public void applicationDidFinishLaunching(UIApplication app) {
        testView view = new testView();
    }
    public static void main(String[] args) {
        UIApplication.main(args, Main.class);
    }
    public class testView extends UIView {
        public testView() {
            System.out.println(getFrame().size);
        }
    }
}


the initialization code of testView produces this code:

- (void) __init_xmlvm_Main_testView___xmlvm_Main :(xmlvm_Main*)n1
{
    XMLVMElem _rtmp;
    XMLVMElem _r0;
    XMLVMElem _r1;
    XMLVMElem _r2;
    XMLVMElem _r3;
    _r2.o = self;
    _r3.o = n1;
    _r0.o = JAVA_NULL;
    _r1.o = JAVA_NULL;
    [_r3.o retain];
    [((xmlvm_Main_testView*) _r2.o)->this_0_xmlvm_Main release];
    ((xmlvm_Main_testView*) _r2.o)->this_0_xmlvm_Main = _r3.o;
    [((org_xmlvm_iphone_UIView*) _r2.o) __init_org_xmlvm_iphone_UIView__];
    _r0.o = [java_lang_System _GET_out];
    _r1.o = [((xmlvm_Main_testView*) _r2.o) getFrame__];
    _rtmp.o =  _r1.o;
    _r1.o = ((org_xmlvm_iphone_CGRect*) _r1.o)->size_org_xmlvm_iphone_CGSize;
    [_rtmp.o release];
    _rtmp.o = JAVA_NULL;
    [((java_io_PrintStream*) _r0.o) println___java_lang_Object:_r1.o];
    return;
}



Now, let me copy & paste the code and add some comments, to describe it:
// perform getFrame()
    _r1.o = [((xmlvm_Main_testView*) _r2.o) getFrame__];

// keep result of getFrame() into temporary variable _rtmp
    _rtmp.o =  _r1.o;

// frame's size is received from the structure
    _r1.o = ((org_xmlvm_iphone_CGRect*) _r1.o)->size_org_xmlvm_iphone_CGSize;

// **release frame ** - here is the bug
    [_rtmp.o release];
    _rtmp.o = JAVA_NULL;

// Use CGSize data, although the structure that was encapsulating it (the frame) is already freed! 
    [((java_io_PrintStream*) _r0.o) println___java_lang_Object:_r1.o];



It seems that objects whose member items are used later on, should also be tracked and released ONLY after the inside items are not used any more!
Or, even better, every time a reference with the -> operator is made, also retain this object and properly release it afterwards.

What others do say?

Re: [xmlvm-users] Apple agreements

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

> As a developer, the point of this discussion is to determine whether  
> XMLVM
> is a dead end for anyone wanting to create an AppStore app. FUD is a  
> real
> concern with Apple right now as they want to kill off any dev tool  
> other
> than Xcode.

Just to remind...
XMLVM does use XCode for developing.
The problem is that the code is not originally written in objc
:)

Probably next time Apple will request us to originally think in  
English before writing code, and not in our native language ;)

Re: [xmlvm-users] Apple agreements

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

Apple is in *complete* control and they will only accept applications 
they deem acceptable. Look at this story:
http://www.niemanlab.org/2010/04/mark-fiore-can-win-a-pulitzer-prize-but-he-cant-get-his-iphone-cartoon-app-past-apples-satire-police/

Even if you use Apple's Xcode tool, there is absolutely no guarantee 
that Apple will accept your application. If you are concerned about not 
losing your investment, the answer is simple: don't develop for the iPhone!

Arno


On 5/23/10 10:31 PM, Erol Fox wrote:
> As a developer, the point of this discussion is to determine whether XMLVM
> is a dead end for anyone wanting to create an AppStore app. FUD is a real
> concern with Apple right now as they want to kill off any dev tool other
> than Xcode. I can think of no other company that is deliberately trying to
> kill any other tool than their own, rather than simply make a superior tool
> through engineering competition.
>
> So the question is, is XMLVM going to be a dead end? Will we invest time
> simply to find after months of waiting that the app is killed in the store
> and must be written all over again? This is my question. Politics isn't
> important.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Apple agreements

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

As a developer, the point of this discussion is to determine whether XMLVM
is a dead end for anyone wanting to create an AppStore app. FUD is a real
concern with Apple right now as they want to kill off any dev tool other
than Xcode. I can think of no other company that is deliberately trying to
kill any other tool than their own, rather than simply make a superior tool
through engineering competition.

So the question is, is XMLVM going to be a dead end? Will we invest time
simply to find after months of waiting that the app is killed in the store
and must be written all over again? This is my question. Politics isn't
important.