Menu
▾
▴
xmlvm-developers
|
From: Arno P. <ar...@pu...> - 2011-10-09 23:33:18
|
Guys, as some of you already know, we are working on the automatic generation of the Java iOS API. So far, the generation of the API is a manual process. Needless to say that this process is sometimes inconsistent, error prone and does not scale. Currently XMLVM only supports a fraction of the complete iOS API. Generating the Java iOS API will be a quantum leap for XMLVM. Once we accomplish this, XMLVM will support 100% of the iOS API. There are two steps to this process: (1) generating the Java API and (2) generating the matching C wrappers. Panayotis has just completed the first version of a tool for (1). Those of you who have knowledge of the iOS API - both Java and Objective-C - are welcomed to take a look at the generated API. You can do so with the following instructions: git clone https://code.google.com/p/crossmobile/ cd crossmobile/src/xmbuild ant skeleton Make sure that iOS SDK 4.3 is installed. Under the folder build/skeleton/src you can find the produced Java files. Please take a look at the generated Java files and send comments/questions/suggestions to this mailing list. Once we have settled on the Java API, we will work on part (2): automatically generating the C wrappers. Thanks to Panayotis for writing a parser tool to generate the Java API. Arno |
|
From: Aaron V. <gru...@gm...> - 2011-10-10 01:37:12
|
Wow, that's brilliant work! This is a great direction to be moving in.
I took a quick look and had a few comments:
----------------------------------
UIColor.java:
/**
* - (UIColor *)initWithHue:(CGFloat)hue
saturation:(CGFloat)saturation brightness:(CGFloat)brightness
alpha:(CGFloat)alpha;
* - (UIColor *)initWithRed:(CGFloat)red green:(CGFloat)green
blue:(CGFloat)blue alpha:(CGFloat)alpha;
*/
public UIColor(float arg1, float arg2, float arg3, float arg4,
UIColor.Colorspace colorspace) {}
This looks a bit strange to me... it's a ctor that maps to two objc
methods. So apparently the inner enum colorspace is automatically
generated just for the purpose of distinguishing these constructors?
I think it would make more sense to have the generated colorspace
parameter be the first parameter rather than the last.
----------------------------------
CGFont.java:
/**
* bool CGFontGetGlyphBBoxes(CGFontRef font, const CGGlyph glyphs[],
size_t count, CGRect bboxes[]) ;
*/
public boolean getGlyphBBoxes(short[] glyphs, int count,
Reference<CGRect> bboxes)
The mapping from CGRect[] to Reference<CGRect> at first glance didn't
seem correct, but inspecting Reference.java that it is basically a
stripped down type of List. Could we use array or ArrayLists instead
of making a new container class? If not, could Reference be renamed
to make it clear that it represents an array of values rather than a
single value. Although I see that both "const SomeType arg[]" and
"const SomeType* arg" are translated to "References<SomeType>", since
they are functionally identical in C, but are semantically different.
(There are many instances of this.)
----------------------------------
Constant values are missing, for example
CGContext.java:
/**
* void CGContextSetLineJoin(CGContextRef c, CGLineJoin join) ;
*/
public void setLineJoin(int join)
The CGLineJoin constants (kCGLineJoinMiter, kCGLineJoinRound,
kCGLineJoinBevel) are not defined anywhere. These are defined in
CGContext.h as enum CGLineJoin. I don't know what all the
implications are, but if this could be made into a Java enum instead
of converting it to int, I think that would be great. (There are many
other such enums.)
----------------------------------
CGContext.java:
/**
* void CGContextSelectFont(CGContextRef c, const char *name, CGFloat
size, CGTextEncoding textEncoding) ;
*/
public void selectFont(byte[] name, float size, int textEncoding)
I'd really like to see (const char*) parameters changed to String
instead of byte[], although I wonder if it will be possible to do this
conversion automatically in the C wrappers in a way that will work in
all cases. (There are many instances of this.)
----------------------------------
UIKit.java:
/**
* CGContextRef UIGraphicsGetCurrentContext(void);
*/
public static CGContext UIGraphicsGetCurrentContext()
I was expecting this to be UIGraphics.getCurrentContext(), rather than
UIKit.UIGraphicsGetCurrentContext(). But this was discussed
previously on the list, and the size of the UIKit grouping seems good
(not too large). So for this I would just want to make sure there is
some clear documentation about where to find methods like this.
Cheers,
--Aaron V.
On Sun, Oct 9, 2011 at 4:33 PM, Arno Puder <ar...@pu...> wrote:
>
> Guys,
>
> as some of you already know, we are working on the automatic generation
> of the Java iOS API. So far, the generation of the API is a manual
> process. Needless to say that this process is sometimes inconsistent,
> error prone and does not scale. Currently XMLVM only supports a fraction
> of the complete iOS API.
>
> Generating the Java iOS API will be a quantum leap for XMLVM. Once we
> accomplish this, XMLVM will support 100% of the iOS API. There are two
> steps to this process: (1) generating the Java API and (2) generating
> the matching C wrappers. Panayotis has just completed the first version
> of a tool for (1). Those of you who have knowledge of the iOS API - both
> Java and Objective-C - are welcomed to take a look at the generated API.
> You can do so with the following instructions:
>
> git clone https://code.google.com/p/crossmobile/
> cd crossmobile/src/xmbuild
> ant skeleton
>
> Make sure that iOS SDK 4.3 is installed. Under the folder
> build/skeleton/src you can find the produced Java files. Please take a
> look at the generated Java files and send comments/questions/suggestions
> to this mailing list.
>
> Once we have settled on the Java API, we will work on part (2):
> automatically generating the C wrappers.
>
> Thanks to Panayotis for writing a parser tool to generate the Java API.
>
> Arno
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>
|
|
From: Panayotis K. <pan...@pa...> - 2011-10-10 11:33:04
|
On 10 Οκτ 2011, at 4:37 π.μ., Aaron VonderHaar wrote:
> Wow, that's brilliant work! This is a great direction to be moving in.
>
> I took a quick look and had a few comments:
>
> ----------------------------------
> UIColor.java:
> /**
> * - (UIColor *)initWithHue:(CGFloat)hue
> saturation:(CGFloat)saturation brightness:(CGFloat)brightness
> alpha:(CGFloat)alpha;
> * - (UIColor *)initWithRed:(CGFloat)red green:(CGFloat)green
> blue:(CGFloat)blue alpha:(CGFloat)alpha;
> */
> public UIColor(float arg1, float arg2, float arg3, float arg4,
> UIColor.Colorspace colorspace) {}
>
> This looks a bit strange to me... it's a ctor that maps to two objc
> methods. So apparently the inner enum colorspace is automatically
> generated just for the purpose of distinguishing these constructors?
>
> I think it would make more sense to have the generated colorspace
> parameter be the first parameter rather than the last.
Exactly.
Since we do not have something like "name override" in Java constructors, we need to distinguish them somehow.
As you said, these enums are created semi-automatically, with external help (to provide the actual enum type).
If you can think of a better approach, I am all ears!
Of course, having the enum in the beginning is very easy to do, as long as we all agree to that.
> ----------------------------------
> CGFont.java:
> /**
> * bool CGFontGetGlyphBBoxes(CGFontRef font, const CGGlyph glyphs[],
> size_t count, CGRect bboxes[]) ;
> */
> public boolean getGlyphBBoxes(short[] glyphs, int count,
> Reference<CGRect> bboxes)
>
> The mapping from CGRect[] to Reference<CGRect> at first glance didn't
> seem correct, but inspecting Reference.java that it is basically a
> stripped down type of List. Could we use array or ArrayLists instead
> of making a new container class? If not, could Reference be renamed
> to make it clear that it represents an array of values rather than a
> single value. Although I see that both "const SomeType arg[]" and
> "const SomeType* arg" are translated to "References<SomeType>", since
> they are functionally identical in C, but are semantically different.
> (There are many instances of this.)
Yes, this is a very serious issue.
As you said, in terms of C, there is no way to distinguish [] from *
Not only that, but in many locations the API defines a * for a table, or even a nil terminated list.
I don't even want to go in details about reference for structs,double reference or even typedefs…
The whole is a mess and with automatic tools this was the best I could do.
Now, about the Reference object, it is primary a "reference", not an "array".
It just happens in C that arrays are actually references to the first item in a list.
References are more common to the iOS API than tables, since NSArray is used usually instead (and is properly mapped to a "List").
These references (like NSError **) are used as "call by reference" arguments.
So it's primary work is to provide a "pointer" and not a "table".
What I actually did to automatically solve this issue, was a "trick", to support both references and arrays.
The same object has behavior as a reference (with the get() and set() methods, without index) and as an array (the same methods with an index parameter). If you think that an ArrayList will be more appropriate than a fixed array, this is something that could change.
I was also thinking of another solution - make everything as arrays.
Then the callback variables will be a one-dimension, size-one arrays, but this will look a bit strange at first.
If we want to do something more elegant that this (which I agree), I will be happy to provide an "XML API", in which will specifically define all those methods that need to be fine tuned.
It won't be an easy job though.
> ----------------------------------
> Constant values are missing, for example
> CGContext.java:
> /**
> * void CGContextSetLineJoin(CGContextRef c, CGLineJoin join) ;
> */
> public void setLineJoin(int join)
>
> The CGLineJoin constants (kCGLineJoinMiter, kCGLineJoinRound,
> kCGLineJoinBevel) are not defined anywhere. These are defined in
> CGContext.h as enum CGLineJoin. I don't know what all the
> implications are, but if this could be made into a Java enum instead
> of converting it to int, I think that would be great. (There are many
> other such enums.)
Yes you are right, they are not in the output, since it is still under discussion (not only enums but also external typedefs to constant values).
The first thought (I though I said it myself to this list) was exactly what you said.
Create Java enums that will do exactly that.
The problem is that, many enums can be combined between them and represent different states.
So they need to be left as int.
In the sake of universality, I prefer to keep them as int, which will be much easier for the C backend too.
> ----------------------------------
> CGContext.java:
> /**
> * void CGContextSelectFont(CGContextRef c, const char *name, CGFloat
> size, CGTextEncoding textEncoding) ;
> */
> public void selectFont(byte[] name, float size, int textEncoding)
>
> I'd really like to see (const char*) parameters changed to String
> instead of byte[], although I wonder if it will be possible to do this
> conversion automatically in the C wrappers in a way that will work in
> all cases. (There are many instances of this.)
I understand, and I absolutely disagree :)
The reason is that char* is NOT a String, it is a byte[].
String is a unicode stream of (Java's) char, while char is 2-bytes variable instead of 1-byte C's char.
In English language there is no real difference, but for every other language this is a serious problem (including my mother tongue).
I wanted with the API to make clear that "char* is not a String - if you want to do something like this, do it with your own responsibility".
Having said that, it would be indeed nice to have functions that the developer can call and convert between byte[] and String - oh wait, here they are! :)
http://download.oracle.com/javase/1,5.0/docs/api/java/lang/String.html#String%28byte[]%29
http://download.oracle.com/javase/1,5.0/docs/api/java/lang/String.html#getBytes%28%29
> ----------------------------------
> UIKit.java:
> /**
> * CGContextRef UIGraphicsGetCurrentContext(void);
> */
> public static CGContext UIGraphicsGetCurrentContext()
>
> I was expecting this to be UIGraphics.getCurrentContext(), rather than
> UIKit.UIGraphicsGetCurrentContext(). But this was discussed
> previously on the list, and the size of the UIKit grouping seems good
> (not too large). So for this I would just want to make sure there is
> some clear documentation about where to find methods like this.
Yes, the idea is "if an object exists, put it there, if not, put it in the framework object:.
Thank you for the constructive comments!
|
|
From: Aaron V. <gru...@gm...> - 2011-10-13 08:54:01
|
Do you think it could work simply to use List<SomeType> where SomeType[] is used in C, and Reference<SomeType> where SomeType* is used? Even though C compiles them identically, we can still distinguish the intent in the header files. On Mon, Oct 10, 2011 at 4:32 AM, Panayotis Katsaloulis <pan...@pa...> wrote: >> ---------------------------------- >> CGFont.java: >> /** >> * bool CGFontGetGlyphBBoxes(CGFontRef font, const CGGlyph glyphs[], >> size_t count, CGRect bboxes[]) ; >> */ >> public boolean getGlyphBBoxes(short[] glyphs, int count, >> Reference<CGRect> bboxes) >> >> The mapping from CGRect[] to Reference<CGRect> at first glance didn't >> seem correct, but inspecting Reference.java that it is basically a >> stripped down type of List. Could we use array or ArrayLists instead >> of making a new container class? If not, could Reference be renamed >> to make it clear that it represents an array of values rather than a >> single value. Although I see that both "const SomeType arg[]" and >> "const SomeType* arg" are translated to "References<SomeType>", since >> they are functionally identical in C, but are semantically different. >> (There are many instances of this.) > > > Yes, this is a very serious issue. > As you said, in terms of C, there is no way to distinguish [] from * > Not only that, but in many locations the API defines a * for a table, or even a nil terminated list. > I don't even want to go in details about reference for structs,double reference or even typedefs… > The whole is a mess and with automatic tools this was the best I could do. > > Now, about the Reference object, it is primary a "reference", not an "array". > It just happens in C that arrays are actually references to the first item in a list. > References are more common to the iOS API than tables, since NSArray is used usually instead (and is properly mapped to a "List"). > These references (like NSError **) are used as "call by reference" arguments. > So it's primary work is to provide a "pointer" and not a "table". > > What I actually did to automatically solve this issue, was a "trick", to support both references and arrays. > The same object has behavior as a reference (with the get() and set() methods, without index) and as an array (the same methods with an index parameter). If you think that an ArrayList will be more appropriate than a fixed array, this is something that could change. > > I was also thinking of another solution - make everything as arrays. > Then the callback variables will be a one-dimension, size-one arrays, but this will look a bit strange at first. > > If we want to do something more elegant that this (which I agree), I will be happy to provide an "XML API", in which will specifically define all those methods that need to be fine tuned. > It won't be an easy job though. |
|
From: Panayotis K. <pan...@pa...> - 2011-10-14 08:52:02
|
-- Panayotis 13 Οκτ 2011, 11:53 π.μ., ο/η Aaron VonderHaar <gru...@gm...> έγραψε: > Do you think it could work simply to use List<SomeType> where > SomeType[] is used in C, and Reference<SomeType> where SomeType* is > used? Even though C compiles them identically, we can still > distinguish the intent in the header files. > > On Mon, Oct 10, 2011 at 4:32 AM, Panayotis Katsaloulis > <pan...@pa...> wrote: >>> ---------------------------------- >>> CGFont.java: >>> /** >>> * bool CGFontGetGlyphBBoxes(CGFontRef font, const CGGlyph glyphs[], >>> size_t count, CGRect bboxes[]) ; >>> */ >>> public boolean getGlyphBBoxes(short[] glyphs, int count, >>> Reference<CGRect> bboxes) >>> >>> The mapping from CGRect[] to Reference<CGRect> at first glance didn't >>> seem correct, but inspecting Reference.java that it is basically a >>> stripped down type of List. Could we use array or ArrayLists instead >>> of making a new container class? If not, could Reference be renamed >>> to make it clear that it represents an array of values rather than a >>> single value. Although I see that both "const SomeType arg[]" and >>> "const SomeType* arg" are translated to "References<SomeType>", since >>> they are functionally identical in C, but are semantically different. >>> (There are many instances of this.) >> >> >> Yes, this is a very serious issue. >> As you said, in terms of C, there is no way to distinguish [] from * >> Not only that, but in many locations the API defines a * for a table, or even a nil terminated list. >> I don't even want to go in details about reference for structs,double reference or even typedefs… >> The whole is a mess and with automatic tools this was the best I could do. >> >> Now, about the Reference object, it is primary a "reference", not an "array". >> It just happens in C that arrays are actually references to the first item in a list. >> References are more common to the iOS API than tables, since NSArray is used usually instead (and is properly mapped to a "List"). >> These references (like NSError **) are used as "call by reference" arguments. >> So it's primary work is to provide a "pointer" and not a "table". >> >> What I actually did to automatically solve this issue, was a "trick", to support both references and arrays. >> The same object has behavior as a reference (with the get() and set() methods, without index) and as an array (the same methods with an index parameter). If you think that an ArrayList will be more appropriate than a fixed array, this is something that could change. >> >> I was also thinking of another solution - make everything as arrays. >> Then the callback variables will be a one-dimension, size-one arrays, but this will look a bit strange at first. >> >> If we want to do something more elegant that this (which I agree), I will be happy to provide an "XML API", in which will specifically define all those methods that need to be fine tuned. >> It won't be an easy job though. |
|
From: Aaron V. <gru...@gm...> - 2011-10-13 09:31:45
|
There's the problem though that String.getBytes() returns different
bytes depending on the "the platform's default charset". I'm not
immediately sure what that even refers to in using xmlvm to generate
objc code.
This gets ugly pretty quickly, but at the moment I don't see a real
solution for this. Sticking with byte[] does sound like the best bet
for now.
Just to add a few more details, here's what the Java code would look
like to correctly convert draw some text to a CGContext...
myCGContext.selectFont(myFontName.getBytes(Charset.forName("US-ASCII"),
12, UIKit.CGEncodingMacRoman);
byte[] bytes = myText.getBytes(Charset.forName("MacRoman"));
myCGContext.showText(bytes, bytes.length);
The font name is required to be a "postscript name", although it
doesn't specifically say what the encoding should be (I'm guessing
ASCII here). The text passed to showText needs to be in the encoding
specified by the third argument to selectFont. (The only two choices
are MacRoman or FontSpecific--not particularly helpful.)
The C backend is going to be cross-compiling the Apache Harmony, is
the correct? Hopefully that includes an implementation of the
MacRoman Charset, which is not required to be implemented by every
Java platform.
Maybe in practice it won't be that big of a deal, but I'm sure some
xmlvm user down the road is going to be thrown for a loop by this.
Again, I don't have any other solution to offer, but I think it's
interesting to stay aware of this.
Cheers,
--Aaron V.
On Mon, Oct 10, 2011 at 4:32 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:
>> ----------------------------------
>> CGContext.java:
>> /**
>> * void CGContextSelectFont(CGContextRef c, const char *name, CGFloat
>> size, CGTextEncoding textEncoding) ;
>> */
>> public void selectFont(byte[] name, float size, int textEncoding)
>>
>> I'd really like to see (const char*) parameters changed to String
>> instead of byte[], although I wonder if it will be possible to do this
>> conversion automatically in the C wrappers in a way that will work in
>> all cases. (There are many instances of this.)
>
>
> I understand, and I absolutely disagree :)
> The reason is that char* is NOT a String, it is a byte[].
> String is a unicode stream of (Java's) char, while char is 2-bytes variable instead of 1-byte C's char.
> In English language there is no real difference, but for every other language this is a serious problem (including my mother tongue).
> I wanted with the API to make clear that "char* is not a String - if you want to do something like this, do it with your own responsibility".
>
> Having said that, it would be indeed nice to have functions that the developer can call and convert between byte[] and String - oh wait, here they are! :)
> http://download.oracle.com/javase/1,5.0/docs/api/java/lang/String.html#String%28byte[]%29
> http://download.oracle.com/javase/1,5.0/docs/api/java/lang/String.html#getBytes%28%29
>
|
|
From: Panayotis K. <pan...@pa...> - 2011-10-14 08:54:20
|
13 Οκτ 2011, 12:31 μ.μ., ο/η Aaron VonderHaar <gru...@gm...> έγραψε: > There's the problem though that String.getBytes() returns different > bytes depending on the "the platform's default charset". I'm not > immediately sure what that even refers to in using xmlvm to generate > objc code. Since there is no "default implementation" for Java in iOS, I believe that we can safely assume that the "default charset" is UTF8, and thus solve tons of issues... |
|
From: Panayotis K. <pan...@pa...> - 2011-10-14 08:59:19
|
13 Οκτ 2011, 11:53 π.μ., ο/η Aaron VonderHaar <gru...@gm...> έγραψε: > Do you think it could work simply to use List<SomeType> where > SomeType[] is used in C, and Reference<SomeType> where SomeType* is > used? Even though C compiles them identically, we can still > distinguish the intent in the header files. In most cases, even if the intent is to use tables, the definition is still with * instead. There are only a very few situations where the [] notation is used. So, at the end of the day it is still impossible to guess if it is a reference or a table. I believe that only manual could define what something is (and I'd love to hear your suggestions on how to properly define something like this in the XML file). |
|
From: Aaron V. <gru...@gm...> - 2011-10-19 09:00:44
|
I guess you're referring to src/org/crossmobile/source/guru/advisor.xml ?
Looking at what's already in that file, it seems like you're trying to
(a) avoid specifying anything for which the default choices are
already correct, and (b) keep the definitions general enough to make
it clear what the transformations are without having to understand how
the processor is implemented. So given that, I'd probably lean toward
something like this (and leave Reference<> to be the default):
<parametertypes>
<method signature="CGFontGetGlyphBBoxes::CGFontRefCGGlyph[]size_tCGRect[]">
<!-- or whatever the correctly mangled signature would be -->
<parameter index="1" type="List<CGGlyph>" />
<parameter index="3" type="List<CGRect>" />
</method>
</parametertypes>
However, taking another look through the skeleton, I'm starting to
think that maybe this is not the phase to be trying to Java-ize these
types of references. For instance, taking a look at
CGContext.addRects(Reference<CGRect> rects, int count), clearly in
Java this would be better translated as
CGContext.addRects(List<CGRect> rects) (the count parameter being
redundant). I'm thinking that rather than trying to convert from
Reference to List in the initial phase, it might be better to keep the
naive translation (Reference<>, int), and then later tack on a
written-by-hand convenience method like this:
public void addRects(List<CGRect> rects) {
addRects(Reference.fromList(rects), rects.size());
}
This type of approach of adding in convenience methods could also
perhaps be used to address some of the string conversion (String vs
byte[]) issues discussed previously.
Cheers,
--Aaron V.
On Fri, Oct 14, 2011 at 1:59 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:
> I believe that only manual could define what something is (and I'd love to hear your suggestions on how to properly define something like this in the
> XML file).
> Do you think it could work simply to use List<SomeType> where
> SomeType[] is used in C, and Reference<SomeType> where SomeType* is
> used? Even though C compiles them identically, we can still
> distinguish the intent in the header files.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X