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

Re: [xmlvm-users] Help needed: problems getting started with android-on-iphone

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

I just tried SayHello and it works fine on my system. Which version of 
Xcode are you using?

Arno


On 3/26/10 5:50 AM, Zor...@gm... wrote:
> Arno,
>
> thanks a lot! Now, that helped a little bit already: knowing that opening the project in Xcode directly, without doing the steps mentioned in the documentation is good!
>
> Sadly, the result I get is identical to what I got when running "make" yesterday: the application starts (within the iPhone simulator), but closes immediately before displaying anything. I assume this is the behavior of a crashing application...?
>
> Now, in your talk you mention that whenever something goes wrong with a cross-compiled application after successfull cross-compilation, it must be a bug in xmlvm, not generating the correct code. But could it be that a simple app SayHello cannot be correctly ported?
>
> I did not want to go into tracing the resulting Xcode program and as I am not familiar with ObjC (yet) that does not sound like a good option.
>
> I checked out the trunk of xmlvm's svn repository - is that correct? Or is that a not-so-stable version?
>
> Thanks so far!!! Helped a little bit already! :-)
> Regards,
> Olaf
>
>
>
>>
>> Olaf,
>>
>> there is sadly not much documentation and the little bit we do have is
>> outdated. It seems that you managed to check out XMLVM and to compile
>> it. If there is no error when invoking 'ant', you will have compiled
>> XMLVM as well as all the demos. If you would like to see how to
>> cross-compile SayHello, I would suggest you take a look at build.xml.
>>
>> XMLVM generates a ready-to-use Xcode project file. All the steps
>> mentioned in the documentation are not needed anymore. After you run
>> ant, simply do 'open
>> dist/demo/android/sayhello/iphone/SayHello.xcodeproj'. That's it!
>>
>> Arno

Re: [xmlvm-users] Help needed: problems getting started with android-on-iphone

[<Zor...@gm...>]

Sorry for writing again, but here's the stack trace of the iPhone simulator when running SayHello:

[Session started at 2010-03-26 13:45:07 +0100.]
2010-03-26 13:45:17.508 SayHello[2522:207] *** -[NSNull getFileSystemRepresentation:maxLength:]: unrecognized selector sent to instance 0x1f9a5a0
2010-03-26 13:45:17.509 SayHello[2522:207] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSNull getFileSystemRepresentation:maxLength:]: unrecognized selector sent to instance 0x1f9a5a0'
2010-03-26 13:45:17.516 SayHello[2522:207] Stack: (
    32539739,
    2449900809,
    32921659,
    32491126,
    32343746,
    2360353,
    2360262,
    2435603,
    2643944,
    63419,
    395505,
    393244,
    394289,
    394457
)


> Olaf,
> 
> there is sadly not much documentation and the little bit we do have is 
> outdated. It seems that you managed to check out XMLVM and to compile 
> it. If there is no error when invoking 'ant', you will have compiled 
> XMLVM as well as all the demos. If you would like to see how to 
> cross-compile SayHello, I would suggest you take a look at build.xml.
> 
> XMLVM generates a ready-to-use Xcode project file. All the steps 
> mentioned in the documentation are not needed anymore. After you run 
> ant, simply do 'open 
> dist/demo/android/sayhello/iphone/SayHello.xcodeproj'. That's it!
> 
> Arno

Re: [xmlvm-users] Help needed: problems getting started with android-on-iphone

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

On 26 Μαρ 2010, at 2:50 ΜΜ, Zor...@gm... wrote:

> Arno,
>
> thanks a lot! Now, that helped a little bit already: knowing that  
> opening the project in Xcode directly, without doing the steps  
> mentioned in the documentation is good!
>
> Sadly, the result I get is identical to what I got when running  
> "make" yesterday: the application starts (within the iPhone  
> simulator), but closes immediately before displaying anything. I  
> assume this is the behavior of a crashing application...?
>
> Now, in your talk you mention that whenever something goes wrong  
> with a cross-compiled application after successfull cross- 
> compilation, it must be a bug in xmlvm, not generating the correct  
> code. But could it be that a simple app SayHello cannot be correctly  
> ported?
>
> I did not want to go into tracing the resulting Xcode program and as  
> I am not familiar with ObjC (yet) that does not sound like a good  
> option.
>
> I checked out the trunk of xmlvm's svn repository - is that correct?  
> Or is that a not-so-stable version?
>
> Thanks so far!!! Helped a little bit already! :-)
> Regards,
> Olaf


Which OS are you using?
Which version of Java?

Re: [xmlvm-users] Help needed: problems getting started with android-on-iphone

[<Zor...@gm...>]

Arno,

thanks a lot! Now, that helped a little bit already: knowing that opening the project in Xcode directly, without doing the steps mentioned in the documentation is good!

Sadly, the result I get is identical to what I got when running "make" yesterday: the application starts (within the iPhone simulator), but closes immediately before displaying anything. I assume this is the behavior of a crashing application...?

Now, in your talk you mention that whenever something goes wrong with a cross-compiled application after successfull cross-compilation, it must be a bug in xmlvm, not generating the correct code. But could it be that a simple app SayHello cannot be correctly ported?

I did not want to go into tracing the resulting Xcode program and as I am not familiar with ObjC (yet) that does not sound like a good option.

I checked out the trunk of xmlvm's svn repository - is that correct? Or is that a not-so-stable version?

Thanks so far!!! Helped a little bit already! :-)
Regards,
Olaf



> 
> Olaf,
> 
> there is sadly not much documentation and the little bit we do have is 
> outdated. It seems that you managed to check out XMLVM and to compile 
> it. If there is no error when invoking 'ant', you will have compiled 
> XMLVM as well as all the demos. If you would like to see how to 
> cross-compile SayHello, I would suggest you take a look at build.xml.
> 
> XMLVM generates a ready-to-use Xcode project file. All the steps 
> mentioned in the documentation are not needed anymore. After you run 
> ant, simply do 'open 
> dist/demo/android/sayhello/iphone/SayHello.xcodeproj'. That's it!
> 
> Arno

Re: [xmlvm-users] Help needed: problems getting started with android-on-iphone

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

Olaf,

there is sadly not much documentation and the little bit we do have is 
outdated. It seems that you managed to check out XMLVM and to compile 
it. If there is no error when invoking 'ant', you will have compiled 
XMLVM as well as all the demos. If you would like to see how to 
cross-compile SayHello, I would suggest you take a look at build.xml.

XMLVM generates a ready-to-use Xcode project file. All the steps 
mentioned in the documentation are not needed anymore. After you run 
ant, simply do 'open 
dist/demo/android/sayhello/iphone/SayHello.xcodeproj'. That's it!

Arno


On 3/25/10 10:22 AM, Zor...@gm... wrote:
> Hello there!
> I am an Android Developer who was just about to dig into Objective-C and iPhone development because the need arose to also target iPhones as well as Android phones.
> Because of that I was extremely excited when I found Xmlvm just a few days ago!
>
> But, unfortunately, even though I tried to stick exactly to what the short documentation says about the demo projects, I got stuck pretty quickly.
> Maybe I am not alone with this and maybe there's only a tiny little thing I missed that screws everthing up right now.
>
> Here's what I wanted to do: Take one of my Android Apps and simply port it right away. Okay, nice attempt - I got stuck with about a hundred error messages in the Xcode envirnment.
>
> So, I stepped back one step: try to get SayHello working out of the box...
>
> As there's no description of what is needed to try out the demos I'll give you my environment specs quickly: Macbook Pro with Xcode 3.2.1 and Eclipse 3.5 running the latest Android SDK r05. The rest is out of the box.
> Xmlvm compiled fine using the ant script.
>
> Now, my first question: I understood that using Xmlvm for Android apps, it will take the Dalvik Code - but the command line interface for xmlvm only gets the SayHello's project folder (that's what I understood I'd have to do)
>
> So I call:
>
> xmlvm --in=../workspace/xmlvm/demo/android/sayhello/ --target=android-on-iphone --app-name="SayHello"
>
> With this command I get a lot of Warnings of the type: WARNING: Unable to create InputProcesses for input: [...] both for helper files like *.svn AND my *.java source files. Where should xmlvm get the Dalvik machine code from? Isn't that only within the apk file? I got no clue...
>
> Now: my first attempt was to get it working in the iPhone Simulator as that should be done by calling make and using the generated makefile. The simulator starts and there's the SayHello app - but it crashes right away. When I start it, it closes immediately.
>
> Second attempt: get into Xcode (which I really don't know yet...). I created a project, deleted main and xib File plus app delegates and the entry in the pList file.
> Next question arose when trying to add files to the project: I don't have a MakeVars file (but I should not include it - where is it?) An Info.pList file is missing, too...
> Okay, added all the files and pressed Build&Run...
>
> This gives me 39 linker errors which I add at the end of this post.
>
>
> Now - what could be wrong here? Maybe I am not the only one who has a problem getting the first program to run?
> Maybe it is possible to add a little bit more to the documentation so that these first steps don't get so hard to do?
>
> That would be great; as the whole idea behind xmlvm is just great and perfect! I would really LOVE not to end up learning the "latin language" or moving to the Vatikan... :-)
>
> Thanks a lot out there!!
> Cheers,
> Olaf
>
>
> Here are my linker errors:
> Undefined symbols:
>    "_glTranslatef", referenced from:
>        +[org_xmlvm_iphone_gl_GL glTranslatef___float_float_float:::] in org_xmlvm_iphone_gl_GL.o
>    "_glDisableClientState", referenced from:
>        +[org_xmlvm_iphone_gl_GL glDisableClientState___int:] in org_xmlvm_iphone_gl_GL.o
>    ".objc_class_name_EAGLContext", referenced from:
>        literal-pointer@__OBJC@__cls_refs@EAGLContext in org_xmlvm_iphone_gl_EAGLContext.o
>        literal-pointer@__OBJC@__cls_refs@EAGLContext in org_xmlvm_iphone_gl_GLView.o
>    "_glBindRenderbufferOES", referenced from:
>        +[org_xmlvm_iphone_gl_GL glBindRenderbufferOES___int_int::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>        -[org_xmlvm_iphone_gl_GLView drawView__] in org_xmlvm_iphone_gl_GLView.o
>    "_glLineWidth", referenced from:
>        +[org_xmlvm_iphone_gl_GL glLineWidth___float:] in org_xmlvm_iphone_gl_GL.o
>    "_glClearColor", referenced from:
>        +[org_xmlvm_iphone_gl_GL glClearColor___float_float_float_float::::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>    "_glFrustumf", referenced from:
>        +[org_xmlvm_iphone_gl_GL glFrustumf___float_float_float_float_float_float::::::] in org_xmlvm_iphone_gl_GL.o
>    "_glClear", referenced from:
>        +[org_xmlvm_iphone_gl_GL glClear___int:] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView drawView__] in org_xmlvm_iphone_gl_GLView.o
>    "_glTexParameteri", referenced from:
>        +[org_xmlvm_iphone_gl_GL glTexParameteri___int_int_int:::] in org_xmlvm_iphone_gl_GL.o
>    "_glOrthof", referenced from:
>        +[org_xmlvm_iphone_gl_GL glOrthof___float_float_float_float_float_float::::::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>    "_glEnable", referenced from:
>        +[org_xmlvm_iphone_gl_GL glEnable___int:] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>    "_glScalef", referenced from:
>        +[org_xmlvm_iphone_gl_GL glScalef___float_float_float:::] in org_xmlvm_iphone_gl_GL.o
>    "_glDrawArrays", referenced from:
>        +[org_xmlvm_iphone_gl_GL glDrawArrays___int_int_int:::] in org_xmlvm_iphone_gl_GL.o
>    "_glGenFramebuffersOES", referenced from:
>        +[org_xmlvm_iphone_gl_GL glGenFramebuffersOES___int:] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>    ".objc_class_name_AVAudioPlayer", referenced from:
>        literal-pointer@__OBJC@__cls_refs@AVAudioPlayer in android_media_MediaPlayer.o
>        literal-pointer@__OBJC@__cls_refs@AVAudioPlayer in org_xmlvm_iphone_AVAudioPlayer.o
>    "_glVertexPointer", referenced from:
>        +[org_xmlvm_iphone_gl_GL glVertexPointer___int_int_int_java_nio_FloatBuffer::::] in org_xmlvm_iphone_gl_GL.o
>    "_glBindTexture", referenced from:
>        +[org_xmlvm_iphone_gl_GL glBindTexture___int_int::] in org_xmlvm_iphone_gl_GL.o
>    "_glLoadIdentity", referenced from:
>        +[org_xmlvm_iphone_gl_GL glLoadIdentity__] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>    "_kEAGLDrawablePropertyColorFormat", referenced from:
>        _kEAGLDrawablePropertyColorFormat$non_lazy_ptr in org_xmlvm_iphone_gl_CAEAGLLayer.o
>        _kEAGLDrawablePropertyColorFormat$non_lazy_ptr in org_xmlvm_iphone_gl_GLView.o
>    "_kEAGLDrawablePropertyRetainedBacking", referenced from:
>        _kEAGLDrawablePropertyRetainedBacking$non_lazy_ptr in org_xmlvm_iphone_gl_CAEAGLLayer.o
>        _kEAGLDrawablePropertyRetainedBacking$non_lazy_ptr in org_xmlvm_iphone_gl_GLView.o
>    "_glGenTextures", referenced from:
>        +[org_xmlvm_iphone_gl_GL glGenTextures___int_java_nio_IntBuffer::] in org_xmlvm_iphone_gl_GL.o
>    "_glDisable", referenced from:
>        +[org_xmlvm_iphone_gl_GL glDisable___int:] in org_xmlvm_iphone_gl_GL.o
>    "_glBlendFunc", referenced from:
>        +[org_xmlvm_iphone_gl_GL glBlendFunc___int_int::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>    "_glViewport", referenced from:
>        +[org_xmlvm_iphone_gl_GL glViewport___int_int_int_int::::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>    ".objc_class_name_CAEAGLLayer", referenced from:
>        literal-pointer@__OBJC@__cls_refs@CAEAGLLayer in org_xmlvm_iphone_gl_GLView.o
>    "_glColor4f", referenced from:
>        +[org_xmlvm_iphone_gl_GL glColor4f___float_float_float_float::::] in org_xmlvm_iphone_gl_GL.o
>    "_glGenRenderbuffersOES", referenced from:
>        +[org_xmlvm_iphone_gl_GL glGenRenderbuffersOES___int:] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>    "_glBindFramebufferOES", referenced from:
>        +[org_xmlvm_iphone_gl_GL glBindFramebufferOES___int_int::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>        -[org_xmlvm_iphone_gl_GLView drawView__] in org_xmlvm_iphone_gl_GLView.o
>    "_glDeleteRenderbuffersOES", referenced from:
>        +[org_xmlvm_iphone_gl_GL glDeleteRenderbuffersOES___int_int::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView destroyFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>        -[org_xmlvm_iphone_gl_GLView destroyFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>    "_glDeleteFramebuffersOES", referenced from:
>        +[org_xmlvm_iphone_gl_GL glDeleteFramebuffersOES___int_int::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView destroyFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>    "_glTexCoordPointer", referenced from:
>        +[org_xmlvm_iphone_gl_GL glTexCoordPointer___int_int_int_java_nio_FloatBuffer::::] in org_xmlvm_iphone_gl_GL.o
>    "_glEnableClientState", referenced from:
>        +[org_xmlvm_iphone_gl_GL glEnableClientState___int:] in org_xmlvm_iphone_gl_GL.o
>    "_glMatrixMode", referenced from:
>        +[org_xmlvm_iphone_gl_GL glMatrixMode___int:] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>        -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
>    "_glFramebufferRenderbufferOES", referenced from:
>        +[org_xmlvm_iphone_gl_GL glFramebufferRenderbufferOES___int_int_int_int::::] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>    "_glTexImage2D", referenced from:
>        +[org_xmlvm_iphone_gl_GL glTexImage2D___int_int_int_int_int_int_int_int_java_nio_ByteBuffer:::::::::] in org_xmlvm_iphone_gl_GL.o
>    "_glRotatef", referenced from:
>        +[org_xmlvm_iphone_gl_GL glRotatef___float_float_float_float::::] in org_xmlvm_iphone_gl_GL.o
>    "_glCheckFramebufferStatusOES", referenced from:
>        +[org_xmlvm_iphone_gl_GL glCheckFramebufferStatusOES___int:] in org_xmlvm_iphone_gl_GL.o
>        -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>        -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>        -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
>    "_glColorPointer", referenced from:
>        +[org_xmlvm_iphone_gl_GL glColorPointer___int_int_int_java_nio_FloatBuffer::::] in org_xmlvm_iphone_gl_GL.o
>    "_kEAGLColorFormatRGBA8", referenced from:
>        _kEAGLColorFormatRGBA8$non_lazy_ptr in org_xmlvm_iphone_gl_CAEAGLLayer.o
>        _kEAGLColorFormatRGBA8$non_lazy_ptr in org_xmlvm_iphone_gl_GLView.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

I just committed Joshua's fix.

Arno


On 3/25/10 10:49 PM, Joshua Melcon wrote:
> Ok, I understand now.  Yes that is a bug -- and an interesting one.
> Basically, its doing:
>
>
> R1 = object;  // R1 has one retain
> Temp = R1; /
> R1 = object.subobject
> Release Temp (causing an implicit release of the object now in R1)
> retain R1 (so we don't lose it).
>
> Basically, the fix is to just emit the retain instruction before the
> rtmp release.  In the future, we will notice that the back to back
> retain/release is not necessacry.
>
> http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it to
> the trunk after the review completes.
>
> Panayotis: Thanks for finding the bug! I appreciate the feedback, as
> well as your clear description of the issue and how to reproduce it.
> Please let me know if you find anything else.
>
> all :)
> -- Joshua Melcon
>
>
>
> On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
> <pan...@pa...>  wrote:
>> Yes these applications work.
>>
>> If you just try to convert the java source code I gave to you though, you
>> will see the error :)
>> Just try ;)
>> To be fair, I've also checked a lot of code, from my own appplications and
>> test cases and this was the only problem found :)
>>
>> Still, it is a bug ;)
>>
>>
>>
>> --
>> Panayotis
>> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...>  έγραψε:
>>
>> If the last retain is failing it indicates that there is an issue related to
>> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
>>
>> I have run Xokoban, Afireworks, and another CCed program and not encountered
>> any problems.  It is possible that you have found a case which we do not
>> handle correctly that doesn't show up in those programs.  Later tonight I
>> can attempt to reproduce this error using one of our demo apps --
>>
>> Could you confirm that the Xokoban and Afireworks demo apps are working for
>> you?
>>
>> Thanks,
>>
>>
>> -- Joshua Melcon
>>
>>
>> 2010/3/25 Panayotis Katsaloulis<pan...@pa...>
>>>
>>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>>>
>>>>     _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 comes
>>>> back ref count += 1 because its a get function
>>>>     _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we
>>>> need to free our +1 afterwords
>>>>     _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_
>>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>>>>     [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from
>>>> the first line
>>>>     [_r2.o retain]; // retaining the value from _r2, presumably because
>>>> we will be returning soon (can't tell without the rest of the code).
>>>>
>>>> But, based on this code sequence, everything looks correct?  How does
>>>> _r2.o retain break things?
>>>
>>>
>>> It says that it tries to retain am already fee'd object.
>>>
>>> Try it for yourself and see ;)
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> xmlvm-users mailing list
>>> xml...@li...
>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Help needed: problems getting started with android-on-iphone

[<Zor...@gm...>]

Hello again community!

Isn't there somebody who could tell me how to get started? It reads like the people discussing here are actually using xmlvm - and I would like to do this,too.
But why can't I get the simple SayHello demo cross compiled and running?
Where's the missing clue?
I did everything as described in the short documentation; but xmlvm throws lots of WARNINGS ("InputProcesses couldn't be created") and the result simply crashes on the iPhone simulator. Xcode shows me a bunch of linker errors with the SayHello demo and with one of my Android programs it even shows hundreds of compiler errors (header files missing).

Can somebody please give me a short step-by-step description what has to be done to get SayHello cross-compile? Am I using the wrong versions of Xcode (3.2.1) or Java (1.6) or where could be the problem???

Thanks a lot!!!!!!!
Regards,
Olaf

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

Ok, I understand now.  Yes that is a bug -- and an interesting one.
Basically, its doing:


R1 = object;  // R1 has one retain
Temp = R1; /
R1 = object.subobject
Release Temp (causing an implicit release of the object now in R1)
retain R1 (so we don't lose it).

Basically, the fix is to just emit the retain instruction before the
rtmp release.  In the future, we will notice that the back to back
retain/release is not necessacry.

http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it to
the trunk after the review completes.

Panayotis: Thanks for finding the bug! I appreciate the feedback, as
well as your clear description of the issue and how to reproduce it.
Please let me know if you find anything else.

all :)
-- Joshua Melcon



On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
<pan...@pa...> wrote:
> Yes these applications work.
>
> If you just try to convert the java source code I gave to you though, you
> will see the error :)
> Just try ;)
> To be fair, I've also checked a lot of code, from my own appplications and
> test cases and this was the only problem found :)
>
> Still, it is a bug ;)
>
>
>
> --
> Panayotis
> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon <xm...@me...> έγραψε:
>
> If the last retain is failing it indicates that there is an issue related to
> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
>
> I have run Xokoban, Afireworks, and another CCed program and not encountered
> any problems.  It is possible that you have found a case which we do not
> handle correctly that doesn't show up in those programs.  Later tonight I
> can attempt to reproduce this error using one of our demo apps --
>
> Could you confirm that the Xokoban and Afireworks demo apps are working for
> you?
>
> Thanks,
>
>
> -- Joshua Melcon
>
>
> 2010/3/25 Panayotis Katsaloulis <pan...@pa...>
>>
>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>>
>> >    _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 comes
>> > back ref count += 1 because its a get function
>> >    _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we
>> > need to free our +1 afterwords
>> >    _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_
>> > CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>> >    [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from
>> > the first line
>> >    [_r2.o retain]; // retaining the value from _r2, presumably because
>> > we will be returning soon (can't tell without the rest of the code).
>> >
>> > But, based on this code sequence, everything looks correct?  How does
>> > _r2.o retain break things?
>>
>>
>> It says that it tries to retain am already fee'd object.
>>
>> Try it for yourself and see ;)
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

If the last retain is failing it indicates that there is an issue related to
the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.

I have run Xokoban, Afireworks, and another CCed program and not encountered
any problems.  It is possible that you have found a case which we do not
handle correctly that doesn't show up in those programs.  Later tonight I
can attempt to reproduce this error using one of our demo apps --

Could you confirm that the Xokoban and Afireworks demo apps are working for
you?

Thanks,


-- Joshua Melcon


2010/3/25 Panayotis Katsaloulis <pan...@pa...>

>
> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>
> >    _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 comes
> back ref count += 1 because its a get function
> >    _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we
> need to free our +1 afterwords
> >    _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_
> > CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
> >    [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from the
> first line
> >    [_r2.o retain]; // retaining the value from _r2, presumably because we
> will be returning soon (can't tell without the rest of the code).
> >
> > But, based on this code sequence, everything looks correct?  How does
> _r2.o retain break things?
>
>
> It says that it tries to retain am already fee'd object.
>
> Try it for yourself and see ;)
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:

>    _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 comes back ref count += 1 because its a get function
>    _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we need to free our +1 afterwords
>    _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_ 
> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>    [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from the first line
>    [_r2.o retain]; // retaining the value from _r2, presumably because we will be returning soon (can't tell without the rest of the code).
> 
> But, based on this code sequence, everything looks correct?  How does _r2.o retain break things? 


It says that it tries to retain am already fee'd object.

Try it for yourself and see ;)

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

> Last time I was digging through the OBJ-C documentation about
> AutoReleasePools I recall seeing something that indicated that the runtime
> generally creates one before it invokes a thread.  That said, I do have the
> following code in java_lang_Thread.m for a reason:
>
> - (void) threadCallback: (id) arg
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> [runnable run__];
>  [self release];
> [pool release];
> }
> Because apparently, at least in certain cases, you are responsible for
> creating the pool...
>
> The above pattern, plus the assumption that the runtime creates pools
> as necessary should prevent any problems.
>
> Let me know if you have any issues...
>
>
> -- Joshua Melcon
>
>
> 2010/3/25 Panayotis Katsaloulis <pan...@pa...>
>
>
>> On 25 Μαρ 2010, at 1:36 μ.μ., Arno Puder wrote:
>>
>> >
>> > Guys,
>> >
>> > I have just committed a patch submitted by Joshua Melcon. His patch
>> > removes the dependency on NSAutoreleasePool during code generation.
>>
>> I have a question here:
>> What if a selector is called from a separated thread?
>> AFAIK, when a new thread is fired, there is no autorelease pool for that.
>>
>> In the new code, I can see inside java_lang_Thread.m that in selector
>> threadCallback, there is a new autorelease pool.
>> I haven't deeply had a look at the code, but I am wondering if this will
>> cover this problem.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>
>

Re: [xmlvm-users] Palm Pre / WebOS

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

Well, the reason I started with Pre in the first place, is because XMLVM
already has quite a mature JavaScript Output library. This is due of the
history of the project, which has its origins in cross-compiling
AWT/SWT/Swing Apps to the Web. So to push this output in shape to fit it on
the Pre, is quite straightforward. Only (and most important) piece missing
is of course the compat lib.

Another reason we started working on it, is because we thought the Pre might
really catch on, because it looked promising and WebOS is really nice. But
reality has proven us wrong.

// Sascha

2010/3/25 Panayotis Katsaloulis <pan...@pa...>

>
> On 25 Μαρ 2010, at 7:37 μ.μ., Sascha Haeberling wrote:
>
> > Hi XMLVM community!
> >
> > As you may or may not be aware, XMLVM provides infant WebOS support. It's
> not usable at all yet, which is why I was working on that part recently.
> However, watching the mobile space and seeing the recent news about Palm and
> the Pre and Pixi adoption, I am a little bit in doubt, if this effort is
> worth it. Our current view is: No, it's not worth to invest time and effort
> into the WebOS platform right now and we should instead focus all our forces
> on the iPhone.
> >
> > But I would like to see what our community has to say. My guess is that
> 99% of you are subscribed to this mailing list because you are interested in
> the iPhone side. Is there anybody on this list who is looking forward to
> android to pre conversion or feels very strongly about getting it? Or do you
> agree that WebOS is probably not having a bright future?
> >
> > Thanks for your opinions!
> > // Sascha
>
>
> I was thinking about it, too.
> Even in the first place, I am not sure if palm pre worths the effort.
> Although I am basically interested in iPhone, I am also interested in any
> kind of multi-platform environments.
> I believe it would be more important to do some core developing on improve
> xmlvm, than to target on one (rare?) platform.
> Even if this sounds as a contradiction (since right now I am only targeting
> iPhone), it is though my belief.
> :)
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Palm Pre / WebOS

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

On 25 Μαρ 2010, at 7:37 μ.μ., Sascha Haeberling wrote:

> Hi XMLVM community!
> 
> As you may or may not be aware, XMLVM provides infant WebOS support. It's not usable at all yet, which is why I was working on that part recently. However, watching the mobile space and seeing the recent news about Palm and the Pre and Pixi adoption, I am a little bit in doubt, if this effort is worth it. Our current view is: No, it's not worth to invest time and effort into the WebOS platform right now and we should instead focus all our forces on the iPhone.
> 
> But I would like to see what our community has to say. My guess is that 99% of you are subscribed to this mailing list because you are interested in the iPhone side. Is there anybody on this list who is looking forward to android to pre conversion or feels very strongly about getting it? Or do you agree that WebOS is probably not having a bright future?
> 
> Thanks for your opinions!
> // Sascha


I was thinking about it, too.
Even in the first place, I am not sure if palm pre worths the effort.
Although I am basically interested in iPhone, I am also interested in any kind of multi-platform environments.
I believe it would be more important to do some core developing on improve xmlvm, than to target on one (rare?) platform.
Even if this sounds as a contradiction (since right now I am only targeting iPhone), it is though my belief.
:)

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

On 25 Μαρ 2010, at 7:18 μ.μ., Joshua Melcon wrote:

> Yes it is necssacry, though in some cases it may be possible to avoid it. 
> 
> Basically, if you don't null them out after release, other code paths *may* try to release them again (which would be bad).  In some cases, the nulling out isn't necessary -- this is one of the optimizations I intend to add in the future.  
> 
> Additionally,  consider that setting a register to [NsNull null] is in general going to be a great deal more efficient than adding an object to an auto release pool.  So even with unnecessary nulling, we are still faster than autorelease.  We will be even faster in the future when I trim out some of this extra stuff..

Of course!
 I really respect this effort.

Still, I think I found a bug :(
------------------------------------

Here is a small example, I was able to make.

Consider adding this code to applicationDidFinishLaunching (in java)
        UIView view = new UIView();
        float z = view.getFrame().size.width;


This produces (among others) the following code
    _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__];
    _rtmp.o =  _r2.o;
    _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_CGSize;
    [_rtmp.o release]; _rtmp.o = [NSNull null];
    [_r2.o retain];

This retain message breaks the code.
Actually I believe it is something with the _rtmp.o variable, which was released and just later on retained (since _rtmp.o =  _r2.o )

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

Yes it is necssacry, though in some cases it may be possible to avoid it.

Basically, if you don't null them out after release, other code paths *may*
try to release them again (which would be bad).  In some cases, the nulling
out isn't necessary -- this is one of the optimizations I intend to add in
the future.

Additionally,  consider that setting a register to [NsNull null] is in
general going to be a great deal more efficient than adding an object to an
auto release pool.  So even with unnecessary nulling, we are still faster
than autorelease.  We will be even faster in the future when I trim out some
of this extra stuff..

-- Joshua Melcon


2010/3/25 Panayotis Katsaloulis <pan...@pa...>

> I have another question:
>
> At the produced code, I can see something like:
>
>    [_r0.o release]; _r0.o = [NSNull null];
>    [_r1.o release]; _r1.o = [NSNull null];
>    [_r2.o release]; _r2.o = [NSNull null];
> …
>
> for all variables.
> Is this necessary?
> Of course it is not something that will harm, but maybe even these few cpu
> cycles might be important :)
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

[xmlvm-users] Palm Pre / WebOS

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

Hi XMLVM community!

As you may or may not be aware, XMLVM provides infant WebOS support. It's
not usable at all yet, which is why I was working on that part recently.
However, watching the mobile space and seeing the recent news about Palm and
the Pre and Pixi adoption, I am a little bit in doubt, if this effort is
worth it. Our current view is: No, it's not worth to invest time and effort
into the WebOS platform right now and we should instead focus all our forces
on the iPhone.

But I would like to see what our community has to say. My guess is that 99%
of you are subscribed to this mailing list because you are interested in the
iPhone side. Is there anybody on this list who is looking forward to android
to pre conversion or feels very strongly about getting it? Or do you agree
that WebOS is probably not having a bright future?

Thanks for your opinions!
// Sascha

[xmlvm-users] Help needed: problems getting started with android-on-iphone

[<Zor...@gm...>]

Hello there!
I am an Android Developer who was just about to dig into Objective-C and iPhone development because the need arose to also target iPhones as well as Android phones.
Because of that I was extremely excited when I found Xmlvm just a few days ago!

But, unfortunately, even though I tried to stick exactly to what the short documentation says about the demo projects, I got stuck pretty quickly.
Maybe I am not alone with this and maybe there's only a tiny little thing I missed that screws everthing up right now.

Here's what I wanted to do: Take one of my Android Apps and simply port it right away. Okay, nice attempt - I got stuck with about a hundred error messages in the Xcode envirnment.

So, I stepped back one step: try to get SayHello working out of the box...

As there's no description of what is needed to try out the demos I'll give you my environment specs quickly: Macbook Pro with Xcode 3.2.1 and Eclipse 3.5 running the latest Android SDK r05. The rest is out of the box.
Xmlvm compiled fine using the ant script.

Now, my first question: I understood that using Xmlvm for Android apps, it will take the Dalvik Code - but the command line interface for xmlvm only gets the SayHello's project folder (that's what I understood I'd have to do)

So I call:

xmlvm --in=../workspace/xmlvm/demo/android/sayhello/ --target=android-on-iphone --app-name="SayHello"

With this command I get a lot of Warnings of the type: WARNING: Unable to create InputProcesses for input: [...] both for helper files like *.svn AND my *.java source files. Where should xmlvm get the Dalvik machine code from? Isn't that only within the apk file? I got no clue...

Now: my first attempt was to get it working in the iPhone Simulator as that should be done by calling make and using the generated makefile. The simulator starts and there's the SayHello app - but it crashes right away. When I start it, it closes immediately.

Second attempt: get into Xcode (which I really don't know yet...). I created a project, deleted main and xib File plus app delegates and the entry in the pList file.
Next question arose when trying to add files to the project: I don't have a MakeVars file (but I should not include it - where is it?) An Info.pList file is missing, too...
Okay, added all the files and pressed Build&Run...

This gives me 39 linker errors which I add at the end of this post.


Now - what could be wrong here? Maybe I am not the only one who has a problem getting the first program to run?
Maybe it is possible to add a little bit more to the documentation so that these first steps don't get so hard to do?

That would be great; as the whole idea behind xmlvm is just great and perfect! I would really LOVE not to end up learning the "latin language" or moving to the Vatikan... :-)

Thanks a lot out there!!
Cheers,
Olaf


Here are my linker errors:
Undefined symbols:
  "_glTranslatef", referenced from:
      +[org_xmlvm_iphone_gl_GL glTranslatef___float_float_float:::] in org_xmlvm_iphone_gl_GL.o
  "_glDisableClientState", referenced from:
      +[org_xmlvm_iphone_gl_GL glDisableClientState___int:] in org_xmlvm_iphone_gl_GL.o
  ".objc_class_name_EAGLContext", referenced from:
      literal-pointer@__OBJC@__cls_refs@EAGLContext in org_xmlvm_iphone_gl_EAGLContext.o
      literal-pointer@__OBJC@__cls_refs@EAGLContext in org_xmlvm_iphone_gl_GLView.o
  "_glBindRenderbufferOES", referenced from:
      +[org_xmlvm_iphone_gl_GL glBindRenderbufferOES___int_int::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
      -[org_xmlvm_iphone_gl_GLView drawView__] in org_xmlvm_iphone_gl_GLView.o
  "_glLineWidth", referenced from:
      +[org_xmlvm_iphone_gl_GL glLineWidth___float:] in org_xmlvm_iphone_gl_GL.o
  "_glClearColor", referenced from:
      +[org_xmlvm_iphone_gl_GL glClearColor___float_float_float_float::::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
  "_glFrustumf", referenced from:
      +[org_xmlvm_iphone_gl_GL glFrustumf___float_float_float_float_float_float::::::] in org_xmlvm_iphone_gl_GL.o
  "_glClear", referenced from:
      +[org_xmlvm_iphone_gl_GL glClear___int:] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView drawView__] in org_xmlvm_iphone_gl_GLView.o
  "_glTexParameteri", referenced from:
      +[org_xmlvm_iphone_gl_GL glTexParameteri___int_int_int:::] in org_xmlvm_iphone_gl_GL.o
  "_glOrthof", referenced from:
      +[org_xmlvm_iphone_gl_GL glOrthof___float_float_float_float_float_float::::::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
  "_glEnable", referenced from:
      +[org_xmlvm_iphone_gl_GL glEnable___int:] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
  "_glScalef", referenced from:
      +[org_xmlvm_iphone_gl_GL glScalef___float_float_float:::] in org_xmlvm_iphone_gl_GL.o
  "_glDrawArrays", referenced from:
      +[org_xmlvm_iphone_gl_GL glDrawArrays___int_int_int:::] in org_xmlvm_iphone_gl_GL.o
  "_glGenFramebuffersOES", referenced from:
      +[org_xmlvm_iphone_gl_GL glGenFramebuffersOES___int:] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
  ".objc_class_name_AVAudioPlayer", referenced from:
      literal-pointer@__OBJC@__cls_refs@AVAudioPlayer in android_media_MediaPlayer.o
      literal-pointer@__OBJC@__cls_refs@AVAudioPlayer in org_xmlvm_iphone_AVAudioPlayer.o
  "_glVertexPointer", referenced from:
      +[org_xmlvm_iphone_gl_GL glVertexPointer___int_int_int_java_nio_FloatBuffer::::] in org_xmlvm_iphone_gl_GL.o
  "_glBindTexture", referenced from:
      +[org_xmlvm_iphone_gl_GL glBindTexture___int_int::] in org_xmlvm_iphone_gl_GL.o
  "_glLoadIdentity", referenced from:
      +[org_xmlvm_iphone_gl_GL glLoadIdentity__] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
  "_kEAGLDrawablePropertyColorFormat", referenced from:
      _kEAGLDrawablePropertyColorFormat$non_lazy_ptr in org_xmlvm_iphone_gl_CAEAGLLayer.o
      _kEAGLDrawablePropertyColorFormat$non_lazy_ptr in org_xmlvm_iphone_gl_GLView.o
  "_kEAGLDrawablePropertyRetainedBacking", referenced from:
      _kEAGLDrawablePropertyRetainedBacking$non_lazy_ptr in org_xmlvm_iphone_gl_CAEAGLLayer.o
      _kEAGLDrawablePropertyRetainedBacking$non_lazy_ptr in org_xmlvm_iphone_gl_GLView.o
  "_glGenTextures", referenced from:
      +[org_xmlvm_iphone_gl_GL glGenTextures___int_java_nio_IntBuffer::] in org_xmlvm_iphone_gl_GL.o
  "_glDisable", referenced from:
      +[org_xmlvm_iphone_gl_GL glDisable___int:] in org_xmlvm_iphone_gl_GL.o
  "_glBlendFunc", referenced from:
      +[org_xmlvm_iphone_gl_GL glBlendFunc___int_int::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
  "_glViewport", referenced from:
      +[org_xmlvm_iphone_gl_GL glViewport___int_int_int_int::::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
  ".objc_class_name_CAEAGLLayer", referenced from:
      literal-pointer@__OBJC@__cls_refs@CAEAGLLayer in org_xmlvm_iphone_gl_GLView.o
  "_glColor4f", referenced from:
      +[org_xmlvm_iphone_gl_GL glColor4f___float_float_float_float::::] in org_xmlvm_iphone_gl_GL.o
  "_glGenRenderbuffersOES", referenced from:
      +[org_xmlvm_iphone_gl_GL glGenRenderbuffersOES___int:] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
  "_glBindFramebufferOES", referenced from:
      +[org_xmlvm_iphone_gl_GL glBindFramebufferOES___int_int::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
      -[org_xmlvm_iphone_gl_GLView drawView__] in org_xmlvm_iphone_gl_GLView.o
  "_glDeleteRenderbuffersOES", referenced from:
      +[org_xmlvm_iphone_gl_GL glDeleteRenderbuffersOES___int_int::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView destroyFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
      -[org_xmlvm_iphone_gl_GLView destroyFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
  "_glDeleteFramebuffersOES", referenced from:
      +[org_xmlvm_iphone_gl_GL glDeleteFramebuffersOES___int_int::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView destroyFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
  "_glTexCoordPointer", referenced from:
      +[org_xmlvm_iphone_gl_GL glTexCoordPointer___int_int_int_java_nio_FloatBuffer::::] in org_xmlvm_iphone_gl_GL.o
  "_glEnableClientState", referenced from:
      +[org_xmlvm_iphone_gl_GL glEnableClientState___int:] in org_xmlvm_iphone_gl_GL.o
  "_glMatrixMode", referenced from:
      +[org_xmlvm_iphone_gl_GL glMatrixMode___int:] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
      -[org_xmlvm_iphone_gl_GLView setupView__] in org_xmlvm_iphone_gl_GLView.o
  "_glFramebufferRenderbufferOES", referenced from:
      +[org_xmlvm_iphone_gl_GL glFramebufferRenderbufferOES___int_int_int_int::::] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
  "_glTexImage2D", referenced from:
      +[org_xmlvm_iphone_gl_GL glTexImage2D___int_int_int_int_int_int_int_int_java_nio_ByteBuffer:::::::::] in org_xmlvm_iphone_gl_GL.o
  "_glRotatef", referenced from:
      +[org_xmlvm_iphone_gl_GL glRotatef___float_float_float_float::::] in org_xmlvm_iphone_gl_GL.o
  "_glCheckFramebufferStatusOES", referenced from:
      +[org_xmlvm_iphone_gl_GL glCheckFramebufferStatusOES___int:] in org_xmlvm_iphone_gl_GL.o
      -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
      -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
      -[org_xmlvm_iphone_gl_GLView createFramebuffer__] in org_xmlvm_iphone_gl_GLView.o
  "_glColorPointer", referenced from:
      +[org_xmlvm_iphone_gl_GL glColorPointer___int_int_int_java_nio_FloatBuffer::::] in org_xmlvm_iphone_gl_GL.o
  "_kEAGLColorFormatRGBA8", referenced from:
      _kEAGLColorFormatRGBA8$non_lazy_ptr in org_xmlvm_iphone_gl_CAEAGLLayer.o
      _kEAGLColorFormatRGBA8$non_lazy_ptr in org_xmlvm_iphone_gl_GLView.o
ld: symbol(s) not found
collect2: ld returned 1 exit status




 

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

I have another question:

At the produced code, I can see something like:

    [_r0.o release]; _r0.o = [NSNull null];
    [_r1.o release]; _r1.o = [NSNull null];
    [_r2.o release]; _r2.o = [NSNull null];
…

for all variables.
Is this necessary?
Of course it is not something that will harm, but maybe even these few cpu cycles might be important :)

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

On xml...@li...25 Μαρ 2010, at 6:27 μ.μ., Joshua Melcon wrote:

> Last time I was digging through the OBJ-C documentation about AutoReleasePools I recall seeing something that indicated that the runtime generally creates one before it invokes a thread.  That said, I do have the following code in java_lang_Thread.m for a reason:
> 
> - (void) threadCallback: (id) arg
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> 	[runnable run__];
> 	[self release];
> 	[pool release];
> }
> Because apparently, at least in certain cases, you are responsible for creating the pool...
> 
> The above pattern, plus the assumption that the runtime creates pools as necessary should prevent any problems.
> 
> Let me know if you have any issues… 


Not really, have a look here:

http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html

If you are making Cocoa calls outside of the Application Kit’s main thread—for example if you create a Foundation-only application or if you detach a thread—you need to create your own autorelease pool.


That's why I am asking that.
But in any case, I have seen this code and it seems that it should work. I did some preliminary tests and I didn't experience any problems.
I just want to make sure that you are aware of this situation.

Re: [xmlvm-users] No dependence on NSAutoreleasePool

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

On 25 Μαρ 2010, at 1:36 μ.μ., Arno Puder wrote:

> 
> Guys,
> 
> I have just committed a patch submitted by Joshua Melcon. His patch 
> removes the dependency on NSAutoreleasePool during code generation. 

I have a question here:
What if a selector is called from a separated thread?
AFAIK, when a new thread is fired, there is no autorelease pool for that.

In the new code, I can see inside java_lang_Thread.m that in selector threadCallback, there is a new autorelease pool.
I haven't deeply had a look at the code, but I am wondering if this will cover this problem.

Re: [xmlvm-users] weak references

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

On 25 Μαρ 2010, at 3:44 μ.μ., Arno Puder wrote:

> 
> gimme, gimme!  :-)
> 
> These are two different things: support for weak references and allowing 
> additional state information for categories. Both would be extremely useful!
> 
> Arno

Yes, they are really two different things, with "memory management" being the only common area.
I believe I have successfully addressed both of them.
I will check the new autorelease-less mechanism and if everything will be fine, I will re-submit a new patch with all my changes, to the HEAD xmlvm code.

Re: [xmlvm-users] Monster patches and GPL linking exception

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

I very much agree.

So far, we (the core team) weren't very open about what we are working on
either I take it as a task on my todo list to create a page on our home
page, where we can track what people are working on. This roadmap should be
extremly useful for everyone involved

// Sascha

On Thu, Mar 25, 2010 at 2:28 PM, Arno Puder <ar...@pu...> wrote:

>
>
> I wholeheartedly agree with this. If you plan to work on a non-trivial
> enhancement for XMLVM, you should announce that on the mailing list
> before you begin to avoid redundant work.
>
> Arno
>
>
> On 3/20/10 2:32 AM, Gergely Kis wrote:
> > Hi,
> >
> > I think the solution for this is to communicate more on the mailing
> > list, to lay down the technical directions of the project. Right now
> > everyone is developing privately, then throws patches "over the wall".
> > If we discussed the approaches on the mailing list, then each of us
> > would make less duplicated efforts.
> >
> > Of course, when you are under time pressure, to get an application
> > working, you have to go ahead on your private branch. In this case you
> > take the risk that your changes are never going to be merged.
> >
> > Best Regards,
> > Gergely
> >
> > 2010/3/18 Panayotis Katsaloulis <pan...@pa...
> > <mailto:pan...@pa...>>
> >
> >
> >     On 18 Μαρ 2010, at 6:15 ΜΜ, Dr. Alexander K. Seewald wrote:
> >
> >     ...
> >
> >      > Currently it works like that: Wolfgang, Arno or Sascha ask me
> about
> >      > a specific functionality (currently it's audio recording), and I
> >
> >     ....
> >     right, that's the key point:
> >     they "asked" you :)
> >
> >
> >     I know that it really is difficult to handle, but (as I said in
> >     previous posts), it is expected for a new project to have patches
> like
> >     these.
> >
> >     Of course if such patch is not desirable, I could take it back and
> >     send, for example, only UIViewContoller, then tomorrow another
> object,
> >     and so forth :)
> >     But I believe the total effort then will be much much larger than
> now,
> >     since this whole patch has a common logic which at the end of the day
> >     will make evaluating it easier than to send one file at a time.
> >     Maybe it might seem too difficult, but it would be easier than to
> >     "divide and conquer" :)
> >
> >
> >
> ------------------------------------------------------------------------------
> >     Download Intel&#174; Parallel Studio Eval
> >     Try the new software tools for yourself. Speed compiling, find bugs
> >     proactively, and fine-tune applications for parallel performance.
> >     See why Intel Parallel Studio got high marks during beta.
> >     http://p.sf.net/sfu/intel-sw-dev
> >     _______________________________________________
> >     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
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> >
> >
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Clarifications on the Linking Exception

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

Same here.

On Thu, Mar 25, 2010 at 2:34 PM, Wolfgang Korn <wol...@xm...> wrote:

>  Yes - I agree with Arno's statement concerning GPL interpretation and
> monster patches. As can be seen - I read the complete mail ;-)
>
> -- Wolfgang
>
>
>
> Arno Puder wrote:
>
> sorry for the slow response.
>
>
>
> On 3/20/10 2:20 AM, Gergely Kis wrote:
>
>
>  No, Hungary is in Central Europe, and also an EU member state.
>
>
>  sooorry...
>
>
>
>  The problem is, that currently the XMLVM Core Team who own the project,
> are 3 independent persons, who are possibly not even located in the same
> country. This makes it pretty hard to enter into a business relationship
> with you, like to buy a linking exception. Who is signing the contracts?
> All 3 of you? Who is going to create the invoice? Where do we transfer
> the money?
> Also, the contributors should receive written proof that they received a
> linking exception.
>
>
>  these are all fair questions to which we have no specific answers at
> this point. Right now 'payment' for which you receive the linking
> exception is only for code contribution. There is no way to pay $$$ at
> this point. We will address this issue so that your customer can
> purchase a linking exception. But we need some time to implement a
> procedure for this. Right now XMLVM is still a young project and it is
> more important for us to find consensus with you guys (the developers).
> And your currency is code.
>
>
>
>  - How much does it cost for a company? Is it even possible to buy it for
> money?
> - Who do we need to contact? All 3 Core Team members at the same time?
>
> I am trying to be practical here: We would recommend to buy XMLVM
> licenses for our customers, but right now, we can't do that, because
> there is no one to buy it from.
>
>
>  We will work on these issues and consult with you guys as usual. Again,
> it is important to us to have a fair way of balancing open source and
> legitimate business interests. I hope that in the meantime, you as
> developers are OK with the 'code contribution in exchange for linking
> exception' idea.
>
>
>
>  This is an excerpt from the Contributor License Agreement:
>
>     Grant of Copyright License. Subject to the terms and conditions of
>     this Agreement, You hereby grant to XMLVM and to recipients of
>     software distributed by XMLVM a perpetual, worldwide, non-exclusive,
>     no-charge, royalty-free, irrevocable copyright license to reproduce,
>     prepare derivative works of, publicly display, publicly perform,
>     sublicense, and distribute Your Contributions and such derivative works.
>
>
> In my interpretation this means that you can do whatever you want with
> the contributed code, which includes re-licensing and selling it. If
> this were not true, then you would not be able to provide linking
> exceptions for the code that contributors wrote.
>
>
>  Yes. You retain the copyright, but by signing the CLA you give us the
> right to do the things you have mentioned.
>
>
>
>  Just to clarify: This means that if no part of the compatibility library
> (and of course the Android library) of XMLVM is used in a project, then
> the resulting software is not subject to the GPL, and it can be
> redistributed under any license without a linking exception.
>
> Is this the correct interpretation?
>
>
>  Yes. If you only used XMLVM's compiler, the generated code would not be
> covered by the GPL. Note however, that the generated code without the
> library (e.g., xmlvm.m) will not do much. Once you link xmlvm.m, the GPL
> does apply to your application.
>
>
>
>  Any contribution that we (or anybody else) make will have 2 parts:
> - original work: something that was created independently of the
> existing parts of XMLVM, e.g. a new class or method in a class.
> - derived work: something that was created based on existing code in
> XMLVM, e.g. when a method is changed to fix a bug, or the xsl is
> changed...etc.
>
>
>  It is my interpretation of the GPL that these two cases would both be
> considered derived work. How you break up your contribution is up to
> you. There is obviously much value in sending bug fixes (your second
> case). If those bug fixes are 'significant' we will of course also grant
> a linking exception for that. In general we prefer smaller patches. But
> from my perspective you don't need to break it up into new code vs. bug
> fixes. Sometimes you cannot do one without the other.
>
>
>
>
>  [...]
> Do you agree with this approach?
> I am already working on splitting up the patch that is sitting in the
> review system to make it easier to review.
>
> May I ask for the consent from each member of the Core Team about the
> GPL interpretation and the "patch submission policy"?
>
>
>  You certainly my consent. If Wolfgang and Sascha kept on reading until
> here, they can hopefully also give their consent.  :)
>
>
>
>  I would very much like to be done with this legal stuff, and get back to
> coding and improving XMLVM. :)
>
>
>  I would like that very much!
>
> Arno
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] weak references

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

>>> Java is supposed to have weak references, isn't it?
>>> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html
>>> So if you expose them to Java as the spec describes, it should just
>>> be a good thing and make even more Java code work with XMLVM.
>>>
>>> --tml
>
>
> It seems that this was much easier than what I originally thought.
> In parallel I have created a mechanism to store variables of category objects (or any other object anyway), since by definition in a category you won't be able to store other variables.
> This is useful to clean up a bit with retained delegates that nobody releases them (and yes, I believe this code has less memory leaks than ever!)
>
> Probably I should take down my old patch and release a new patch, with this improved memory management issues.
>
> What others (i.e. the xmlvm team) think?

gimme, gimme!  :-)

These are two different things: support for weak references and allowing 
additional state information for categories. Both would be extremely useful!

Arno

Re: [xmlvm-users] Clarifications on the Linking Exception

[Wolfgang K. <wol...@xm...>]

Yes - I agree with Arno's statement concerning GPL interpretation and
monster patches. As can be seen - I read the complete mail ;-)

-- Wolfgang


Arno Puder wrote:
> sorry for the slow response.
>
>
>
> On 3/20/10 2:20 AM, Gergely Kis wrote:
>   
>> No, Hungary is in Central Europe, and also an EU member state.
>>     
>
> sooorry...
>
>   
>> The problem is, that currently the XMLVM Core Team who own the project,
>> are 3 independent persons, who are possibly not even located in the same
>> country. This makes it pretty hard to enter into a business relationship
>> with you, like to buy a linking exception. Who is signing the contracts?
>> All 3 of you? Who is going to create the invoice? Where do we transfer
>> the money?
>> Also, the contributors should receive written proof that they received a
>> linking exception.
>>     
>
> these are all fair questions to which we have no specific answers at 
> this point. Right now 'payment' for which you receive the linking 
> exception is only for code contribution. There is no way to pay $$$ at 
> this point. We will address this issue so that your customer can 
> purchase a linking exception. But we need some time to implement a 
> procedure for this. Right now XMLVM is still a young project and it is 
> more important for us to find consensus with you guys (the developers). 
> And your currency is code.
>
>   
>> - How much does it cost for a company? Is it even possible to buy it for
>> money?
>> - Who do we need to contact? All 3 Core Team members at the same time?
>>
>> I am trying to be practical here: We would recommend to buy XMLVM
>> licenses for our customers, but right now, we can't do that, because
>> there is no one to buy it from.
>>     
>
> We will work on these issues and consult with you guys as usual. Again, 
> it is important to us to have a fair way of balancing open source and 
> legitimate business interests. I hope that in the meantime, you as 
> developers are OK with the 'code contribution in exchange for linking 
> exception' idea.
>
>   
>> This is an excerpt from the Contributor License Agreement:
>>
>>     Grant of Copyright License. Subject to the terms and conditions of
>>     this Agreement, You hereby grant to XMLVM and to recipients of
>>     software distributed by XMLVM a perpetual, worldwide, non-exclusive,
>>     no-charge, royalty-free, irrevocable copyright license to reproduce,
>>     prepare derivative works of, publicly display, publicly perform,
>>     sublicense, and distribute Your Contributions and such derivative works.
>>
>>
>> In my interpretation this means that you can do whatever you want with
>> the contributed code, which includes re-licensing and selling it. If
>> this were not true, then you would not be able to provide linking
>> exceptions for the code that contributors wrote.
>>     
>
> Yes. You retain the copyright, but by signing the CLA you give us the 
> right to do the things you have mentioned.
>
>   
>> Just to clarify: This means that if no part of the compatibility library
>> (and of course the Android library) of XMLVM is used in a project, then
>> the resulting software is not subject to the GPL, and it can be
>> redistributed under any license without a linking exception.
>>
>> Is this the correct interpretation?
>>     
>
> Yes. If you only used XMLVM's compiler, the generated code would not be 
> covered by the GPL. Note however, that the generated code without the 
> library (e.g., xmlvm.m) will not do much. Once you link xmlvm.m, the GPL 
> does apply to your application.
>
>   
>> Any contribution that we (or anybody else) make will have 2 parts:
>> - original work: something that was created independently of the
>> existing parts of XMLVM, e.g. a new class or method in a class.
>> - derived work: something that was created based on existing code in
>> XMLVM, e.g. when a method is changed to fix a bug, or the xsl is
>> changed...etc.
>>     
>
> It is my interpretation of the GPL that these two cases would both be 
> considered derived work. How you break up your contribution is up to 
> you. There is obviously much value in sending bug fixes (your second 
> case). If those bug fixes are 'significant' we will of course also grant 
> a linking exception for that. In general we prefer smaller patches. But 
> from my perspective you don't need to break it up into new code vs. bug 
> fixes. Sometimes you cannot do one without the other.
>
>
>   
>> [...]
>> Do you agree with this approach?
>> I am already working on splitting up the patch that is sitting in the
>> review system to make it easier to review.
>>
>> May I ask for the consent from each member of the Core Team about the
>> GPL interpretation and the "patch submission policy"?
>>     
>
> You certainly my consent. If Wolfgang and Sascha kept on reading until 
> here, they can hopefully also give their consent.  :)
>
>   
>> I would very much like to be done with this legal stuff, and get back to
>> coding and improving XMLVM. :)
>>     
>
> I would like that very much!
>
> Arno
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>