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

Re: [xmlvm-users] XMLVM changes to synchronization

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

On 28 Ιουλ 2010, at 8:44 μ.μ., Arno Puder wrote:

> 
> I just committed your patch. Nice job, Paul!
> 
> Arno
> 

Now that I see the patch again, I have this comment on this part of the code:
//- (void)dealloc {
//
//// TODO is it okay to have this method since this IS currently a category of NSObject? I.e. I want to make sure the real dealloc is called & I can't call super dealloc on NSObject
//
//	objc_setAssociatedObject(self, &memberKey, nil, OBJC_ASSOCIATION_ASSIGN);
//	[super dealloc];
//}

AFAIK the associated object is automatically released when the main object is deallocated. So I think this code is not required at all, I think.

Re: [xmlvm-users] Writer, OutputStreamWriter, BufferedWriter, PrintWriter. Also escape String literals (issue18003)

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

Tolle sourceforge ad.  Irgendwie passend ;)

On Jul 28, 2010 8:11 PM, "Arno Puder" <ar...@pu...> wrote:
>
> I just committed that patch as well (after some minor editing). Thanks
> again, Paul!
>
> Arno
>
>
> -------- Original Message --------
> Subject: Re: Writer, OutputStreamWriter, BufferedWriter, PrintWriter.
> Also escape String literals (issue18003)
> Date: Tue, 27 Jul 2010 23:51:00 +0000
> From: bay...@gm...
> Reply-To: bay...@gm..., re...@xm...,
> tli...@gm..., al...@se..., re...@xm...
> To: re...@xm..., tli...@gm..., al...@se...
> CC: re...@xm...
>
> Updated patch to latest changes in repository
>
> http://xmlvm-reviews.appspot.com/18003/show
>
>
------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] XMLVM changes to synchronization

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

I just committed your patch. Nice job, Paul!

Arno


On 7/25/10 1:50 PM, Paul Poley wrote:
> I have just submitted my patch for synchronization, wait(), wait(long),
> notify() & notifyAll().
> I think this will be a great addition to XMLVM.
>
> I now know what you were referring to, Arno, about how "the simulator
> version leaks memory".  The root cause of failed associative references
> due to importing java_lang_Class.h & java_lang_String.h was xmlvm.h.
>   Since the Simulator did not support associated references until
> recently, a change was previously made to get around that.  That blocked
> associated references in the simulator for SDK4.  Fortunately, that is
> not needed anymore, and you'll see I've commented that out in my patch
> (69001).
>
> To help testing, I've attached a demo project.  There's a couple of
> scenarios in there.  I've tested a lot more than is immediately shown in
> the demo.  By default, the demo has 2 threads that are notified via
> notifyAll() from another thread.
>
> Also, it will probably help testing if you uncomment out the NSLog
> statements in java_lang_Object.m.
> Also, after generating the obj-c code, I like to go into my Logger &
> change the single println to NSLog instead so it includes a timestamp.
>
> Thanks!
> Paul Poley
>
>
> 2010/7/20 Paul Poley <bay...@gm... <mailto:bay...@gm...>>
>
>     Yep, thanks!  I was also able to get associative references working
>     with the SDK simulator 4.0.
>
>     I ran into an anomaly where they do NOT work in java_lang_Object.m.
>       After a while, I was able to determine that it works once the
>     imports for java_lang_Class.h & java_lang_String.h are removed.
>       Unfortunately, the former import cannot be removed.
>
>     One solution is to just make a new category of java_lang_Object in a
>     separate file & use the associative references, etc. there.
>       However, I'd rather get down to the root cause to see why this is
>     happening.  I'll dig in further later this week.
>
>     Thanks!
>     Paul Poley
>
>     On Sun, Jul 18, 2010 at 5:47 PM, Panayotis Katsaloulis
>     <pan...@pa... <mailto:pan...@pa...>> wrote:
>
>
>         On 17 Ιουλ 2010, at 5:36 μ.μ., Panayotis Katsaloulis wrote:
>
>          > 17 Ιουλ 2010, 11:49 π.μ., ο/η Arno Puder <ar...@pu...
>         <mailto:ar...@pu...>> έγραψε:
>          >
>          >>
>          >> I also wanted to say something about the associations.
>         Panayotis has
>          >> reported that they don't work in the simulator but do work
>         on the actual
>          >> device. Apparently you've implemented your own solution as a
>          >> consequence. I would strongly advise against this. For one,
>         it only
>          >> matters if it works correctly on the device. I've heard many
>         times that
>          >> you cannot get around testing on the real device because of
>         many subtle
>          >> differences between the simulator and the device. So, we
>         should optimize
>          >> for the device; not the simulator. If the simulator version
>         leaks
>          >> memory, so be it. I'm sure Apple will fix that in the next
>         version of
>          >> the SDK.
>          >
>          > Just a quick note:
>          > The problem with associations in the simulator was in the
>         previous version of the SDK. It is possible that with the
>         release of 4.0 this is not the case any more. Right now I am
>         practically away from my computer but I will have a look at it
>         next week.
>
>
>         A quick test with the SDK simulator 4.0, showed that object
>         associations seem to work fine in the simulator now :)
>         (or at least, they seem to work and no work around is necessary ).
>         I think the workaround code  is not necessary any more.
>         ------------------------------------------------------------------------------
>         This SF.net email is sponsored by Sprint
>         What will you do first with EVO, the first 4G phone?
>         Visit sprint.com/first <http://sprint.com/first> --
>         http://p.sf.net/sfu/sprint-com-first
>         _______________________________________________
>         xmlvm-users mailing list
>         xml...@li...
>         <mailto:xml...@li...>
>         https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] Writer, OutputStreamWriter, BufferedWriter, PrintWriter. Also escape String literals (issue18003)

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

I just committed that patch as well (after some minor editing). Thanks 
again, Paul!

Arno


-------- Original Message --------
Subject: Re: Writer, OutputStreamWriter, BufferedWriter, PrintWriter. 
Also 	escape String literals (issue18003)
Date: Tue, 27 Jul 2010 23:51:00 +0000
From: bay...@gm...
Reply-To: bay...@gm..., re...@xm..., 
tli...@gm..., 	al...@se..., re...@xm...
To: re...@xm..., tli...@gm..., al...@se...
CC: re...@xm...

Updated patch to latest changes in repository

http://xmlvm-reviews.appspot.com/18003/show

Re: [xmlvm-users] Emulator and debugging

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

On 24 Ιουλ 2010, at 6:34 π.μ., Damian Troncoso wrote:

> Well, I'm finding myself blocked by the emulator capabilities, and I
> think that using it maybe is not the best idea.
> Is there any way to use apple emulator and be able to debug somehow?
> Anyone has taken the approach of not using xmlvm emulator and using
> apple's one or a real device? Could I have better luck this way?
> The problem I find with xmlvm emulator is that most of apple libraries
> are not implemented, and I think doing so is not practical at all.
> Besides that, I don't think it's uncommon to find problems in apple
> emulator that wasn't in xmlvm one, because the code is not the same.
> So finding a way to debug in the actual device would be absolutely
> useful and there would be no need to put so much effort on xmlvm
> emulator and libs. Am I right?
> 
> Any help or idea will be greatly appreciated.
> Damian


try this command:

java -jar xmlvm.jar --out=OUT_DIR --app-name=NAME --skeleton=iphone

and of course replace OUT_DIR and NAME with actual parameters.
Then open the created project in Netbeans under OS X.
Don't forget to change target form Netbeans to Xcode

[xmlvm-users] Emulator and debugging

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

Well, I'm finding myself blocked by the emulator capabilities, and I
think that using it maybe is not the best idea.
Is there any way to use apple emulator and be able to debug somehow?
Anyone has taken the approach of not using xmlvm emulator and using
apple's one or a real device? Could I have better luck this way?
The problem I find with xmlvm emulator is that most of apple libraries
are not implemented, and I think doing so is not practical at all.
Besides that, I don't think it's uncommon to find problems in apple
emulator that wasn't in xmlvm one, because the code is not the same.
So finding a way to debug in the actual device would be absolutely
useful and there would be no need to put so much effort on xmlvm
emulator and libs. Am I right?

Any help or idea will be greatly appreciated.
Damian

Re: [xmlvm-users] XMLVM changes to synchronization

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

Yep, thanks!  I was also able to get associative references working with the
SDK simulator 4.0.

I ran into an anomaly where they do NOT work in java_lang_Object.m.  After a
while, I was able to determine that it works once the imports for
java_lang_Class.h & java_lang_String.h are removed.  Unfortunately, the
former import cannot be removed.

One solution is to just make a new category of java_lang_Object in a
separate file & use the associative references, etc. there.  However, I'd
rather get down to the root cause to see why this is happening.  I'll dig in
further later this week.

Thanks!
Paul Poley

On Sun, Jul 18, 2010 at 5:47 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On 17 Ιουλ 2010, at 5:36 μ.μ., Panayotis Katsaloulis wrote:
>
> > 17 Ιουλ 2010, 11:49 π.μ., ο/η Arno Puder <ar...@pu...> έγραψε:
> >
> >>
> >> I also wanted to say something about the associations. Panayotis has
> >> reported that they don't work in the simulator but do work on the actual
> >> device. Apparently you've implemented your own solution as a
> >> consequence. I would strongly advise against this. For one, it only
> >> matters if it works correctly on the device. I've heard many times that
> >> you cannot get around testing on the real device because of many subtle
> >> differences between the simulator and the device. So, we should optimize
> >> for the device; not the simulator. If the simulator version leaks
> >> memory, so be it. I'm sure Apple will fix that in the next version of
> >> the SDK.
> >
> > Just a quick note:
> > The problem with associations in the simulator was in the previous
> version of the SDK. It is possible that with the release of 4.0 this is not
> the case any more. Right now I am practically away from my computer but I
> will have a look at it next week.
>
>
> A quick test with the SDK simulator 4.0, showed that object associations
> seem to work fine in the simulator now :)
> (or at least, they seem to work and no work around is necessary ).
> I think the workaround code  is not necessary any more.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Two questions about xmlvm-iphone

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

Yes, I've found the problem, in Device.java there's something like this:

    @Override
    public void paint(Graphics g) {
        if (glPanel == null) {
            Graphics2D g2d = (Graphics2D) g;
            AffineTransform savedTransform = g2d.getTransform();
            g2d.transform(deviceTransform);
            super.paint(g);

            AffineTransform displayTransform = new AffineTransform();
            displayTransform.translate(35, 107);
            g2d.transform(displayTransform);
            display.paint(g2d);

            g2d.setTransform(savedTransform);
        } else {
            super.paint(g);
            g.drawImage(chassisImage, 0, 0, null);
            if (!glCreated) {
                glCreated = true;
                try {
                    org.lwjgl.opengl.Display.create(new PixelFormat(8, 8,
0));
                    org.lwjgl.opengl.Display.setParent(glPanel);
                    org.lwjgl.opengl.Display.setVSyncEnabled(true);
                    GLMousePollingThread p = new GLMousePollingThread(this,
glPanel);
                    p.start();
                } catch (LWJGLException e) {
                    throw new RuntimeException(e);
                }
            }
        }
    }

And as my app is OpenGL based, it does not the rotation of the chassis and
the view, I'll see if I can fix it.
I've already fixed some other problems before:
* touches were not working on the simulator when using a GLView.
* There were some java instructions missing in the xml that I had to add to
cross compile some Scala libraries.
Is there any way for me to contribute those fixes?
Thanks.

Damian

On Sun, Jul 18, 2010 at 7:48 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On 18 Ιουλ 2010, at 7:28 μ.μ., Damian wrote:
>
> > 1. Is there any way to put the simulator in landscape? I've tried
> this.setStatusBarOrientation(UIInterfaceOrientation.LandscapeLeft) but it
> only resizes the window and relocates the acelerometer controls, but does
> not rotates the view.
>
> Did you have a look at Hello World Landscape demo?
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Two questions about xmlvm-iphone

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

On 18 Ιουλ 2010, at 7:28 μ.μ., Damian wrote:

> 1. Is there any way to put the simulator in landscape? I've tried this.setStatusBarOrientation(UIInterfaceOrientation.LandscapeLeft) but it only resizes the window and relocates the acelerometer controls, but does not rotates the view.

Did you have a look at Hello World Landscape demo?

Re: [xmlvm-users] XMLVM changes to synchronization

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

On 17 Ιουλ 2010, at 5:36 μ.μ., Panayotis Katsaloulis wrote:

> 17 Ιουλ 2010, 11:49 π.μ., ο/η Arno Puder <ar...@pu...> έγραψε:
> 
>> 
>> I also wanted to say something about the associations. Panayotis has 
>> reported that they don't work in the simulator but do work on the actual 
>> device. Apparently you've implemented your own solution as a 
>> consequence. I would strongly advise against this. For one, it only 
>> matters if it works correctly on the device. I've heard many times that 
>> you cannot get around testing on the real device because of many subtle 
>> differences between the simulator and the device. So, we should optimize 
>> for the device; not the simulator. If the simulator version leaks 
>> memory, so be it. I'm sure Apple will fix that in the next version of 
>> the SDK.
> 
> Just a quick note:
> The problem with associations in the simulator was in the previous version of the SDK. It is possible that with the release of 4.0 this is not the case any more. Right now I am practically away from my computer but I will have a look at it next week.


A quick test with the SDK simulator 4.0, showed that object associations seem to work fine in the simulator now :)
(or at least, they seem to work and no work around is necessary ).
I think the workaround code  is not necessary any more.

Re: [xmlvm-users] Two questions about xmlvm-iphone

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

Answer to your second question: Yes there is. Just head over to this URL:
https://sourceforge.net/mailarchive/forum.php?forum_name=xmlvm-users

<https://sourceforge.net/mailarchive/forum.php?forum_name=xmlvm-users>//
Sascha

On Sun, Jul 18, 2010 at 6:28 PM, Damian <dam...@gm...> wrote:

> *1.* Is there any way to put the simulator in landscape? I've tried *
> this.setStatusBarOrientation(UIInterfaceOrientation.LandscapeLeft)* but it
> only resizes the window and relocates the acelerometer controls, but does
> not rotates the view.
> *2.* Is there any way to search into the xmlvm mail archive so we don't
> have to ask thigs that may already have been asked before?
>
> Thanks!
> Damian.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

[xmlvm-users] Two questions about xmlvm-iphone

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

*1.* Is there any way to put the simulator in landscape? I've tried *
this.setStatusBarOrientation(UIInterfaceOrientation.LandscapeLeft)* but it
only resizes the window and relocates the acelerometer controls, but does
not rotates the view.
*2.* Is there any way to search into the xmlvm mail archive so we don't have
to ask thigs that may already have been asked before?

Thanks!
Damian.

[xmlvm-users] Patch for review

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

Hi,

I have uploaded a patch for review, that contains several fixes to be able to crosscompile the J2ME emulator microemu.org to the iPhone.

http://xmlvm-reviews.appspot.com/68001/show

The patch consists of several smaller patches, that can be found in my github repository. http://github.com/tisoft/xmlvm/compare/trunk...master

Regards,
Markus

Re: [xmlvm-users] XMLVM changes to synchronization

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

Hi Arno,


I believe I have slightly misled you.  My attached project in my earlier
email is a Java proof of concept written with the intent ready to easily
port to Objective-C.  So it's not a patch just yet.  I wanted to first make
sure I wasn't going against the grain of the XMLVM community.


Since it's all Java & not yet a patch, I have not implemented my own version
of associative references.  I agree that would be a poor approach & we
should absolutely optimize for the device & not the simulator.  My comments
were mostly just pondering as to the best solution to that portion.  If
associative references work in the SDK4, then that's wonderful.  I'm going
to try that out this weekend.


Regarding dex:monitor-enter vs jam:monitorenter, there's a comment saying
"we can't map this to @synchronized {} because DEX may generate multiple
monitor-exit for one monitor-enter".  Other than that, it wouldn't seem very
difficult to use the DEX instructions instead of JVM.


I think we're in agreement.


If everything goes smoothly, I will prepare a patch hopefully within the
week.


Hi Gergely,


I took a look at your implementation.  I believe we have come up with
similar solutions.  I used NSLock for synchronization (recursive conditions
handled so that a single release can be called when needed for wait*) &
NSConditionLock for wait* & notify*.  Again assuming associative references
work in SDK4, I will try to get our solutions together.


Thanks!

Paul Poley

On Sat, Jul 17, 2010 at 9:36 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> 17 Ιουλ 2010, 11:49 π.μ., ο/η Arno Puder <ar...@pu...> έγραψε:
>
> >
> > I also wanted to say something about the associations. Panayotis has
> > reported that they don't work in the simulator but do work on the actual
> > device. Apparently you've implemented your own solution as a
> > consequence. I would strongly advise against this. For one, it only
> > matters if it works correctly on the device. I've heard many times that
> > you cannot get around testing on the real device because of many subtle
> > differences between the simulator and the device. So, we should optimize
> > for the device; not the simulator. If the simulator version leaks
> > memory, so be it. I'm sure Apple will fix that in the next version of
> > the SDK.
>
> Just a quick note:
> The problem with associations in the simulator was in the previous version
> of the SDK. It is possible that with the release of 4.0 this is not the case
> any more. Right now I am practically away from my computer but I will have a
> look at it next week.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] XMLVM changes to synchronization

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

17 Ιουλ 2010, 11:49 π.μ., ο/η Arno Puder <ar...@pu...> έγραψε:

> 
> I also wanted to say something about the associations. Panayotis has 
> reported that they don't work in the simulator but do work on the actual 
> device. Apparently you've implemented your own solution as a 
> consequence. I would strongly advise against this. For one, it only 
> matters if it works correctly on the device. I've heard many times that 
> you cannot get around testing on the real device because of many subtle 
> differences between the simulator and the device. So, we should optimize 
> for the device; not the simulator. If the simulator version leaks 
> memory, so be it. I'm sure Apple will fix that in the next version of 
> the SDK.

Just a quick note:
The problem with associations in the simulator was in the previous version of the SDK. It is possible that with the release of 4.0 this is not the case any more. Right now I am practically away from my computer but I will have a look at it next week. 

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

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

Hi,

2010/7/17 Arno Puder <ar...@pu...>

>
> I wanted to comment on your comment.  :-)  There is never the 'optimal'
> solution as you have pointed out. I recently came across this Java code
> that someone tried to cross-compile:
>
> ... = new Stack<String>() { ...override toString() };
>
> This doesn't work with our way of defining a category to NSMutableArray
> because this Cocoa class cannot be subclassed!
>

Actually, in the old patch http://xmlvm-reviews.appspot.com/18002 I had the
beginnings of a solution for this, look at java_util_Vector and
java_util_List and java_util_list_internal_ListProxy.

The trick is to use dynamic proxies and categories: implement the List, Map,
... etc. interfaces as categories, just like we do it now. However, use a
dynamic proxy to define the actual ArrayList, LinkedList ... etc. classes,
which behind the scene use the NSMutable* classes.

We use this solution in our own application, because we are subclassing
Vector.

There is one extra optimization bit that I thought of, but did not implement
yet:

In the proxy init method it could check whether the classname being
instantiated is a standard class. if yes, then it could simply return the
standard NSMutable* object instead of itself. With this optimization, in
most cases the applications would still use the standard NSMutable* classes
without the additional overhead of the NSProxy.

Unfortunately I won't have time to submit this patch in the next few weeks,
so if anyone has the time and would like to jump in, I would be very glad.

Best Regards,
Gergely




>
> Anyways, I wanted to make one more point I didn't mention in my original
> reply. Apart from compiling OpenJDK we are also working on a new code
> generation backend for C/C++. Eventually I would like to deprecate the
> Objective-C backend for two reasons: first of all C/C++ is much more
> portable across different smartphone platforms. Objective-C only works
> on the iPhone, so with a C/C++ backend we can more easily target other
> smartphones in the future. Note that iPhone also supports C/C++.
>
> Second reason: Java is a statically typed language and Objective-C is a
> dynamically typed language. When cross-compiling a statically typed
> language to a dynamically typed language, you cannot do very many
> optimizations. Since we have this information on the Java side, it would
> be possible to map many Java methods to simple C functions whose
> invocation would be much more runtime efficient than a dynamic method
> dispatch in Objective-C.
>
> Well, this is ongoing work and won't happen in quite some time. But I do
> believe it is the right way to go.
>
> Arno
>
>
> On 7/12/10 10:33 AM, Panayotis Katsaloulis wrote:
> >
> > On 11 Ιουλ 2010, at 2:47 μ.μ., Arno Puder wrote:
> >
> >> …
> >> We are currently working on cross-compiling the original JRE classes
> >> from OpenJDK. For one, it would give us instant 100% compatibility and
> >> the issues you have described would also be resolved. Note that this is
> >> ongoing work and will take some time to complete.
> >>
> >> Arno
> >
> >
> > I have a comment on this.
> > I think that even if it is useful and "quick", direct using of java
> objects found in the JDK is not a good idea.
> > JDK is optimized for various versions, situations and platforms, and uses
> many objects from many other packages.
> > Moreover most of the library is written in JAVA itself (and for a good
> reason).
> >
> > At least for the iOS port I believe that this is not an optimum solution.
> Most calls can be directly mapped to obj-c selectors and there is no need to
> implement them just to keep 100% java compatibility. I believe the pathway
> that was followed up to now, to map as much methods as possible and
> implement anew only tiny bits, is the best approach.
> >
> > Panayotis
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> 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] XMLVM changes to synchronization

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

Hi Paul and Everyone,

I am sorry that I have been silent in the last couple weeks, unfortunately I
am very much underwater with other projects, and I had no time to clean up
and resubmit our patches which solve this issue.

We have already discussed approaches for this problem on this list. And also
an implementation can be found in my horribly outdated patch (
http://xmlvm-reviews.appspot.com/18002, look in xmlvm.h and .m and in
java_lang_Object.h and .m)
although it seems that the critical portion, the NSRecursiveCondition is
missing from there, I attached our current version of xmlvm.h and .m, which
includes it.

Unfortunately I won't be able to update the patch in the next few weeks, so
if anyone would like to jump in, I would be very happy.

The version in these patches are using a central, global registry of locks,
to get around the problem that categories cannot contain fields.

However, I think Panayotis found the associative references feature which
allows us to "link" objects at runtime. You should be able to find this
discussion in the list archives.

Using associative references removes the bulk of the complexity of my
solution, and it boils down to this:

1. Each java_lang_Object has a linked NSRecursiveCondition instance. This
instance gets created on demand on the first access of [java_lang_Object
lockImpl];

2. monitorenter and monitorexit instructions generate [java_lang_Object
lockImpl] and [unlockImpl] calls.

3. the wait* and notify* methods in java_lang_Object are simply using the
NSRecursiveCondition instance that is linked with the Object instance.

This solution is completely transparent. The compiler generates the
monitorenter / exit instructions at the right places (with respect to
exception handling ... etc.). We are using this solution with many locks and
threads, wait / notify scenarios in our application and it works fine.

It is possible that an NSRecursiveLock and an NSCondition instance together
could remove the need of our own NSRecursiveCondition implementation, but I
don't have the time now to think it over.

On the simulator one could still use the central registry to store the lock
objects, or provide a simplistic implementation for the associative
references interface.

Again, sorry that I did not have and still don't have the time to properly
submit this change, and please if anyone has the time, feel free to take it
over and (re)submit it.

Best Regards,
Gergely

PS: Attachment got rejected by Sourceforge, here is the important part, the
NSRecursiveCondition (the XMLVMWrapper can be safely ignored, and converted
to the NSValue based solution.):

@interface NSRecursiveCondition : NSCondition
{
    NSMutableDictionary* waitingThreads;
    NSThread *lockingThread;
    int count;
}

- (id) init;
- (void) dealloc;
- (void) lock;
- (void) unlock;
- (void)wait;
- (BOOL)waitUntilDate:(NSDate *)limit;
- (void)signal;
- (void)broadcast;
- (BOOL)isFree;

@end

@implementation NSRecursiveCondition

- (id) init
{
    NSRecursiveCondition* c = [super init];
    if (c != nil) {
        c->waitingThreads = [[NSMutableDictionary alloc] init];
        c->count = 0;
        c->lockingThread = nil;
    }
    return c;
}
- (void) dealloc
{
    [waitingThreads release];
    if (lockingThread != nil) {
        [lockingThread release];
    }
    [super dealloc];
}

- (void) lock
{
    NSThread *currentThread = [NSThread currentThread];
    @synchronized (self) {
        if (currentThread == lockingThread) {
            ++ count;
            return;
        }
    }
    [super lock];
    @synchronized (self) {
        if (lockingThread != nil) {
            @throw [[NSException alloc] initWithObject: @"BUG: lockingThread
not nill after lock()"];
        }
        ++ count;
        lockingThread = currentThread;
    }
}

- (void) unlock
{
    NSThread *currentThread = [NSThread currentThread];
    @synchronized (self) {
        if (currentThread != lockingThread) {
            return;
        }
        if (count > 1) {
            -- count;
            return;
        }
        [super unlock];
        count = 0;
        lockingThread = nil;
    }
}

- (void)wait
{
    NSThread *currentThread = [NSThread currentThread];
    @synchronized (self) {
        if (currentThread != lockingThread) {
            java_lang_IllegalStateException* ex =
[[java_lang_IllegalStateException alloc] init];
            [ex __init_java_lang_IllegalStateException__];
            @throw ex;
        }
        XMLVMKeyWrapper *key = [[XMLVMKeyWrapper alloc] initWithObject:
currentThread];
        [waitingThreads setObject: [NSNumber numberWithInteger: count]
forKey: key];
        [key release];
        count = 0;
        lockingThread = nil;
    }
    [super wait];
    @synchronized (self) {
        NSNumber* n = (NSNumber *) [waitingThreads objectForKey:
currentThread];
        count = [n intValue];
        [waitingThreads removeObjectForKey: currentThread];
        lockingThread = currentThread;
    }
}

- (BOOL)waitUntilDate:(NSDate *)limit
{
    NSThread *currentThread = [NSThread currentThread];
    @synchronized (self) {
        if (currentThread != lockingThread) {
            java_lang_IllegalStateException* ex =
[[java_lang_IllegalStateException alloc] init];
            [ex __init_java_lang_IllegalStateException__];
            @throw ex;
        }
        XMLVMKeyWrapper *key = [[XMLVMKeyWrapper alloc] initWithObject:
currentThread];
        [waitingThreads setObject: [NSNumber numberWithInteger: count]
forKey: key];
        [key release];
        count = 0;
        lockingThread = nil;
    }
    BOOL ret = [super waitUntilDate: limit];
    @synchronized (self) {
        NSNumber* n = (NSNumber *) [waitingThreads objectForKey:
currentThread];
        count = [n intValue];
        [waitingThreads removeObjectForKey: currentThread];
        lockingThread = currentThread;
    }
    return ret;
}

- (void)signal
{
    NSThread *currentThread = [NSThread currentThread];
    @synchronized (self) {
        if (currentThread != lockingThread) {
            java_lang_IllegalStateException* ex =
[[java_lang_IllegalStateException alloc] init];
            [ex __init_java_lang_IllegalStateException__];
            @throw ex;
        }
        [super signal];
    }
}

- (void)broadcast
{
    NSThread *currentThread = [NSThread currentThread];
    @synchronized (self) {
        if (currentThread != lockingThread) {
            java_lang_IllegalStateException* ex =
[[java_lang_IllegalStateException alloc] init];
            [ex __init_java_lang_IllegalStateException__];
            @throw ex;
        }
        [super broadcast];
    }
}

- (BOOL) isFree
{
    @synchronized (self) {
        if (lockingThread == nil && count == 0 && [waitingThreads count] ==
0) {
            return TRUE;
        }
        return FALSE;
    }
}


@end


2010/7/17 Paul Poley <bay...@gm...>

>  This is a pretty critical change, so please bare with me on the length of
> this e-mail.
> I have attached some source code that may be the best explanation. (See
> TestSync.java specifically)
>
> The major points are:
>
>    1. Changing XMLVM's synchronization
>    2. Implementing wait(), wait(long), notify(), notifyAll()
>    3. Considering alternatives to associative references to store member
>    variables in java_lang_Object
>
>
> [...]

-- 
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] Using categories vs. encapsulation in Objective-C compat-lib

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

I wanted to comment on your comment.  :-)  There is never the 'optimal' 
solution as you have pointed out. I recently came across this Java code 
that someone tried to cross-compile:

... = new Stack<String>() { ...override toString() };

This doesn't work with our way of defining a category to NSMutableArray 
because this Cocoa class cannot be subclassed!

Anyways, I wanted to make one more point I didn't mention in my original 
reply. Apart from compiling OpenJDK we are also working on a new code 
generation backend for C/C++. Eventually I would like to deprecate the 
Objective-C backend for two reasons: first of all C/C++ is much more 
portable across different smartphone platforms. Objective-C only works 
on the iPhone, so with a C/C++ backend we can more easily target other 
smartphones in the future. Note that iPhone also supports C/C++.

Second reason: Java is a statically typed language and Objective-C is a 
dynamically typed language. When cross-compiling a statically typed 
language to a dynamically typed language, you cannot do very many 
optimizations. Since we have this information on the Java side, it would 
be possible to map many Java methods to simple C functions whose 
invocation would be much more runtime efficient than a dynamic method 
dispatch in Objective-C.

Well, this is ongoing work and won't happen in quite some time. But I do 
believe it is the right way to go.

Arno


On 7/12/10 10:33 AM, Panayotis Katsaloulis wrote:
>
> On 11 Ιουλ 2010, at 2:47 μ.μ., Arno Puder wrote:
>
>> …
>> We are currently working on cross-compiling the original JRE classes
>> from OpenJDK. For one, it would give us instant 100% compatibility and
>> the issues you have described would also be resolved. Note that this is
>> ongoing work and will take some time to complete.
>>
>> Arno
>
>
> I have a comment on this.
> I think that even if it is useful and "quick", direct using of java objects found in the JDK is not a good idea.
> JDK is optimized for various versions, situations and platforms, and uses many objects from many other packages.
> Moreover most of the library is written in JAVA itself (and for a good reason).
>
> At least for the iOS port I believe that this is not an optimum solution. Most calls can be directly mapped to obj-c selectors and there is no need to implement them just to keep 100% java compatibility. I believe the pathway that was followed up to now, to map as much methods as possible and implement anew only tiny bits, is the best approach.
>
> Panayotis
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] XMLVM changes to synchronization

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

thanks for the patch, Paul. Can you please upload it to the review 
system? I promise a swift turnaround reviewing it. I would like to make 
some general comments without having looked at your patch. In your mail 
you refer to jvm:monitorenter. We want to deprecate the JVM instructions 
and move to the DEX instructions. But as far as I know, the DEX 
synchronization instructions are pretty much identical.

I also wanted to say something about the associations. Panayotis has 
reported that they don't work in the simulator but do work on the actual 
device. Apparently you've implemented your own solution as a 
consequence. I would strongly advise against this. For one, it only 
matters if it works correctly on the device. I've heard many times that 
you cannot get around testing on the real device because of many subtle 
differences between the simulator and the device. So, we should optimize 
for the device; not the simulator. If the simulator version leaks 
memory, so be it. I'm sure Apple will fix that in the next version of 
the SDK.

More importantly, I favor using the tools given to us by the SDK. Apple 
undoubtedly put a lot of effort on implementing these associations 
efficiently and rather than inventing our our mechanism, we should use 
theirs. So, to be honest, I am reluctant to commit your patch in its 
current form.

Arno


On 7/17/10 12:36 AM, Paul Poley wrote:
> This is a pretty critical change, so please bare with me on the length
> of this e-mail.
> I have attached some source code that may be the best explanation. (See
> TestSync.java specifically)
>
> The major points are:
>
>    1. Changing XMLVM's synchronization
>    2. Implementing wait(), wait(long), notify(), notifyAll()
>    3. Considering alternatives to associative references to store member
>       variables in java_lang_Object
>
>
> In order to implement wait() and wait(long) in Objective-C, I must first
> take more control of synchronization.
> This is because these 2 methods release the Object's monitor for another
> thread while waiting.
>
> So while @synchronized has been the perfect solution for
> "jvm:monitorenter" and "jvm:monitorexit" before this point, it is not
> longer sufficient because it is scope based.
> I.e. I need to be able to release the Object's monitor for another
> thread when calling wait() or wait(long) and then retain the monitor
> again when the wait is over.
>
> My solution is to use NSLock, while accounting for exceptions and
> recursive locks.
> Java style, the following requires conversion:
>
> *    synchronized (this) {*
> *        // Do something*
> *    }*
>
> It would be converted to:
>
> *    acquireLockRecursive();*
> *
> *
> *    try {*
> *        // Do something*
> *    } finally {*
> *        releaseLockRecursive();*
> *    }*
>
> First every Object needs:
>
> *    private NSLock myLock; // the lock which to use for the Object in
> place of synchronizing on "this"*
> *    private int recursiveLocks = 0; // the number of recursive locks.
> If only synchronized once, this is 1*
> *    private Thread owningThread; // the thread that owns the Object's
> monitor or null for none*
>
> More in depth is:
>
> *    private void acquireLockRecursive() {*
> *        boolean acquireLock = false;*
> *        synchronized (this) {*
> *            acquireLock = Thread.currentThread() != owningThread;*
> *        }*
> *
> *
> *        if (acquireLock) {*
> *            myLock.lock();*
> *            synchronized (this) {*
> *                owningThread = Thread.currentThread();*
> *            }*
> *        }*
> *        recursiveLocks++;*
> *    }*
> *
> *
> *    private void releaseLockRecursive() {*
> *        recursiveLocks--;*
> *
> *
> *        if (recursiveLocks == 0) {*
> *            synchronized (this) {*
> *                owningThread = null;*
> *            }*
> *            myLock.unlock();*
> *        }*
> *    }*
>
> Unfortunately, associative references do not work in the simulator, so I
> do not believe this to be a viable option for member variables at this
> point.
> I don't think it would be prudent to stop allowing XMLVM to operate in
> the simulator entirely.
> Hopefully we can come up with a universal solution (maybe changing
> java_lang_Object to inherit from NSObject instead of be one, but that
> causes other issues).
>
>
> I have attached the source code prototypes.  For the current
> conversation, see TestSync.java.  In a later conversation, we can
> discuss TestObject2.java.
> I made a crude Java implementation of NSLock & NSConditionLock.  They
> work for this scenario, but are not intended for general use.
> Also, note that they are backed by wait(), wait(long) & notifyAll(),
> which is somewhat ironic since that's what we're trying to implement.
>
>
>
> Once all this is done, I can move on to wait() and wait(long) where they
> can unlock() and lock() around the waiting period.
> Please give me any input, positive or negative!  If you disagree with
> anything or everything, I would be interested in hearing those thoughts
> as well.
>
> Thanks,
> Paul Poley
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

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

Thanks for the info Panayotis.  I'm disappointed to hear associative
references don't work in the simulator.
To me, that means it's not a viable option for XMLVM, since using them would
stop allowing XMLVM to operate in the simulator entirely.

I will be sending out a somewhat lengthy email later with Java source code
included discussing changes around "@synchronized" so that I can implement
wait(), wait(long), notify() & notifyAll().  Unfortunately, it requires a
solution such as associative references that is more universal.  I'll
probably have to find an alternate solution to adding member variables to
java_lang_Object.

Thanks!
Paul Poley

2010/7/12 Panayotis Katsaloulis <pan...@pa...>

>
> On 12 Ιουλ 2010, at 11:10 μ.μ., Paul Poley wrote:
>
> > An associative reference looks to be just what I need.  I'm assuming it
> works with at least the latest version of iOS 3 & not just 4.0 & beyond.
> >
>
> It requires iOS 3.1 and above - and it is not supported at the simulator.
> Of course there you don't really care so much of memory leaks, as with
> iPhone.
>
>
> > I suppose the best solution is to lazily create the reference only when
> first needed, since most objects won't need it.  That will also not create
> any overhead to existing functionality.
> >
>
> Have in mind that this solution actually retains the object - it is not
> just a weak reference.
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] How to compile Java to JavaScript ?

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

In principle your approach is absolutely sane, however the JS backend is
laking some attention lately. I for myself am very keen on making some
progress on that side again at some point soon, but there are some other
items on the agenda for me right now. So for now  I would recommend not to
bother with the JS side. I need to put up a strategy and goals for this
first and prioritize before getting anywhere with it.

I am not the expert on the Obj-C side, so I added the list again to see if
anyof the Obj-C guys has an idea about what's going wrong there.

// Sascha


On Fri, Jul 16, 2010 at 3:47 PM, <ul...@we...> wrote:

>  Hi Sascha,
>
> I appreciate a lot, that you help me.
>
> My favorite language is Java.
> I'm not a Mac expert and borrowed an iMac.
> I would like to get some Java running on the iPad.
> 3 ways to do this failed.
>
> Versions:
> - xmlvm repository Jun 12. 2010
> - Mac OS 10.6.4
> - Xcode 3.2.3
>
> a) JS
>
> JS would run with iPad's Safari.
> JS has the additional advantage,
> that it runs on nearly every browser.
> So I tried this first.
> I don't know how to get xmlvm's JS run,
> see last mail.
>
> b) Native iPhone app
>
> I'm able to use XMLVM for the Obj-C code.
> I can't compile it wit Xcode,
> because there are compiler errors:
>
> 1) MyFireworks/iphone/src/xcode/lib/iphone/java_lang_String.h:25:
> conflicting declaration 'typedef struct NSMutableString java_lang_String'
>
> 2) MyFireworks/iphone/src/xcode/lib/iphone/java_lang_Object.h:24:
> 'struct java_lang_String' has a previous declaration as 'struct
> java_lang_String'
>
> 3)
> MyFireworks/iphone/src/xcode/lib/iphone/org_xmlvm_iphone_UINavigationItem.h:12:
> conflicting declaration 'typedef struct UINavigationItem
> org_xmlvm_iphone_UINavigationItem'
>
> 4)
> MyFireworks/iphone/src/xcode/lib/iphone/org_xmlvm_iphone_UINavigationBar.h:10:
> 'struct org_xmlvm_iphone_UINavigationItem' has a previous declaration as
> 'struct org_xmlvm_iphone_UINavigationItem'
>
> c) make
>
> The xmlvm documentation says,
> I could type make in console in the Obj-C directory.
> This causes the error:
> library not found for -lcrt1.10.5.o
>
> ***
>
> The attached picture shows how I see the mailing list with Win-FF.
> With Win-IE it looks the same.
> Sorry, I don't find a kind of respond feature.
>
> Any ideas ?
>
> Thanks
> Ulrich
>
>
> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
>

Re: [xmlvm-users] How to compile Java to JavaScript ?

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

This is odd. I just checked the code in XMLVM that is throwing this error,
and all it does is checking whether the given path is a directory. However,
in the error message, I don't add any quotes. So I believe that in your
case, the quotes are taken as part of the value. Could you please set the
path like hits:

set XMLVM_QOOXDOO_PATH=D:\Inform\Java\xmlvm\qooxdoo

And let me know whether this worked.

Thanks
// Sascha

On Thu, Jul 15, 2010 at 9:11 PM, <ul...@we...> wrote:

>  Thanks Sascha.
>
> Now the path is absolute, I tried:
> set XMLVM_QOOXDOO_PATH="D:\Inform\Java\xmlvm\qooxdoo"
> set XMLVM_QOOXDOO_PATH="D:\Inform\Java\xmlvm\qooxdoo\tool"
> set XMLVM_QOOXDOO_PATH="D:\Inform\Java\xmlvm\qooxdoo\tool\bin"
>
> Sorry to say, that the error message is the same:
> ERROR: QooxdooOutputProcess: QX directory cannot be found:
> "D:\Inform\Java\xmlvm\qooxdoo"
>
> I'm working with WinXP.
> qooxdoo has no installer, right ?
> It's just a directory tree
> with lots of *.py, *.js and *.json files.
>
> I installed Python.
> Anything else needed ?
>
> Any further ideas ?
> Is there any more documentation ?
>
> Thx
> Ulrich
>
>
> > Try setting the path to Qooxdoo absolute, and not relative.
>
>
> >> On Thu, Jul 15, 2010 at 6:52 PM, <ul...@we...> wrote:
> >>
> >> Dear Developers,
> >>
> >> Everything with eclipse and the repository works fine.
> >> I don't get anything working with JavaScript.
> >>
> >> In "Email Archive xmlvm-users" I found the thread:
> >> "[xmlvm-users] Demos Translated to JavaScript" from 2010-05-28 22:47.
> >> Sascha gave the advice to set a XMLVM_QOOXDOO_PATH.
> >> In my Windows XP console I set:
> >> set XMLVM_QOOXDOO_PATH="qooxdoo"
> >>
> >> My xmlvm command line is:
> >> java -jar dist/xmlvm.jar --in=../HelloWorld/bin/pack/ --out=output
> >> --target=qooxdoo --qx-app=MyApp --qx-main=Main
> >>
> >> The xmlvm error message is:
> >> ERROR: QooxdooOutputProcess: QX directory cannot be found: "qooxdoo"
> >>
> >> Phython is installed.
> >> The qooxdoo folder is in same directory as console and dist/xmlvm.jar.
> >> The result is the same for:
> >> set XMLVM_QOOXDOO_PATH="qooxdoo\tool" or
> >> set XMLVM_QOOXDOO_PATH="qooxdoo\tool\bin"
> >>
> >> Any ideas ?
> >> Is there any more documentation ?
> >>
> >> Thx
> >> Ulrich
>
>
> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] How to compile Java to JavaScript ?

[Leo I. <le...@sc...>]

Its true. In general, when setting environment variables, try to use an absolute 
path, because you might not have any idea where the thing that is reading the 
variable is. In this case you do have an idea, but you don't know if something 
else might read it.




________________________________
From: Sascha Haeberling <sa...@xm...>
To: ul...@we...
Cc: xml...@li...
Sent: Thu, July 15, 2010 11:53:34 AM
Subject: Re: [xmlvm-users] How to compile Java to JavaScript ?

Try setting the path to Qooxdoo absolute, and not relative.


On Thu, Jul 15, 2010 at 6:52 PM, <ul...@we...> wrote:

Dear Developers,
>
>Everything with eclipse and the repository works fine.
>I don't get anything working with JavaScript.
>
>In "Email Archive xmlvm-users" I found the thread:
>"[xmlvm-users] Demos Translated to JavaScript" from 2010-05-28 22:47.
>Sascha gave the advice to set a XMLVM_QOOXDOO_PATH.
>In my Windows XP console I set:
>set XMLVM_QOOXDOO_PATH="qooxdoo"
>
>My xmlvm command line is:
>java -jar dist/xmlvm.jar --in=../HelloWorld/bin/pack/ --out=output 
>--target=qooxdoo --qx-app=MyApp --qx-main=Main
>
>The xmlvm error message is:
>ERROR: QooxdooOutputProcess: QX directory cannot be found: "qooxdoo"
>
>Phython is installed.
>The qooxdoo folder is in same directory as console and dist/xmlvm.jar.
>The result is the same for:
>set XMLVM_QOOXDOO_PATH="qooxdoo\tool" or
>set XMLVM_QOOXDOO_PATH="qooxdoo\tool\bin"
>
>Any ideas ?
>Is there any more documentation ?
>
>Thx
>Ulrich  
>
>
> 
>Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!     
>Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail 
>------------------------------------------------------------------------------
>This SF.net email is sponsored by Sprint
>What will you do first with EVO, the first 4G phone?
>Visit sprint.com/first-- http://p.sf.net/sfu/sprint-com-first
>_______________________________________________
>xmlvm-users mailing list
>xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] How to compile Java to JavaScript ?

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

Try setting the path to Qooxdoo absolute, and not relative.

On Thu, Jul 15, 2010 at 6:52 PM, <ul...@we...> wrote:

>  Dear Developers,
>
> Everything with eclipse and the repository works fine.
> I don't get anything working with JavaScript.
>
> In "Email Archive xmlvm-users" I found the thread:
> "[xmlvm-users] Demos Translated to JavaScript" from 2010-05-28 22:47.
> Sascha gave the advice to set a XMLVM_QOOXDOO_PATH.
> In my Windows XP console I set:
> set XMLVM_QOOXDOO_PATH="qooxdoo"
>
> My xmlvm command line is:
> java -jar dist/xmlvm.jar --in=../HelloWorld/bin/pack/ --out=output
> --target=qooxdoo --qx-app=MyApp --qx-main=Main
>
> The xmlvm error message is:
> ERROR: QooxdooOutputProcess: QX directory cannot be found: "qooxdoo"
>
> Phython is installed.
> The qooxdoo folder is in same directory as console and dist/xmlvm.jar.
> The result is the same for:
> set XMLVM_QOOXDOO_PATH="qooxdoo\tool" or
> set XMLVM_QOOXDOO_PATH="qooxdoo\tool\bin"
>
> Any ideas ?
> Is there any more documentation ?
>
> Thx
> Ulrich
>
>
> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

[xmlvm-users] New things with XMLVM

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

I am happy to announce that just now a patch of mine has been applied to the main XMLVM source tree, which will make XMLVM Android compatibility and emulator a bit better than before :)

Here is a rough change-log of the changes:

1) Improved handling of specific events and support of background images in Android compatibility library
2) Improved Activity pipeline in Android projects
3) CompoundButton under Android properly works
4) Fixed some Android API inconsistencies
5) Support of images, background images and control states in UIButton (and emulator)
6) Property support of background color in UIView and children
7) Improved emulator support of UILabel, UITextField and UITextView. Improved support of UITextField and UITextView
8) Improved support of launching iPhone applications: arguments supported and custom UIApplication classes
9) UIApplicationDelegate used instead of UIApplication being itself a UIApplicationDelegate
10) Template project does not have the "xmlvm" string any more, and comments added to xcode.project file


I'd like also to mention again the problem with (obsolete) iPhone 3 projects.
To define a iPhone 3 project, one have to edit file nbproject/xcode.properties and set xmlvm.project to iphone3
Or, if someone wants to work with the command line version of xmlvm, he should pass the parameter 
-DXcodeProject=iphone3 
to the xmlvm binary.

I hope you will enjoy it!