waba-spec Mailing List for Waba Virtual Machine
Status: Abandoned
Brought to you by:
bornet
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(20) |
Nov
(16) |
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2003 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ben A. <ben...@st...> - 2007-06-25 11:09:34
|
Hello there I would greatly appreciate a small amount of your time to assist with my doctoral research at The University of Newcastle. The research concerns open source licensing and we're seeking developers working on Java projects. The research is supervised, ethics-approved, anonymous and results will be freely available. Participation will also provide a custom licensing report for your project. To learn more, please visit: http://licensing-research.newcastle.edu.au Thanks for reading this email, and I hope you'll consider participating. Best regards Ben Alex (My apologies for being off-topic; this list will not be emailed again) |
From: CAROL B. <EXU...@ma...> - 2004-04-24 09:44:05
|
OFFICE OF THE EXECUTIVE DIRECTOR United Nations Children's Fund Three United Nations Plaza New York, New york,10017 23 APRIL 2004 HEAD/DIRECTOR WABA PO Box 1200, 10850 - Penang, Malaysia Dear Sir/Madam, Re: List of WABA member Organisations. I would like to ask for a list of all the member organisations and there full contact addresses including Postal/Physical address, Telephone, Fax and Email plus websites. This is to help us in the evaluation of Funding for some of them in the particular category of specialisation and need. I will be grateful for you cooperation and timely reply. With regards Best wishes, Carol Bellamy EXECUTIVE DIRECTOR <P><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">Get the FREE email that has everyone talking at <a href="http://www.mail2world.com" target="new">http://www.mail2world.com</a></font><br><br> </font> </font> |
From: <pos...@vg...> - 2003-08-21 22:38:35
|
See the attached file for details |
From: Olivier B. <Oli...@sm...> - 2003-04-13 10:08:07
|
Hello Mag, (sorry for the long delay before answering) > I read README.uClinux file, it mentioned that the cleanup() function is n= ecessary. > Where i could place the _cleanup function ? should i palce it in some > c files or create a separate c file to store this function ? Two solutions:=20 - add in all your applications. Just add a : void _cleanup(void) {} in one of your sources. See: http://www.uclinux.org/pub/uClinux/archive/4941.html - patch the libc.a to have the _cleanup() function. I'm not sure this is always needed with last release of uC-libc. Anyway, this seem to be obsolete, and you must try to use m68k-elf-gcc instead. See: http://www.uclinux.org/pub/uClinux/archive/4939.html (sorry, I don't have any kind of experience with m68k-elf-gcc at this time.) Hope this help. Olivier --=20 Olivier Bornet http://www.smartdata.ch/ Oli...@sm... SMARTDATA SA Phone: +41-27-723'55'03 Rue du Coll=E8ge 5A GPG key ID: C53D9218 CH-1920 Martigny |
From: SAI C. M. <010...@st...> - 2003-03-25 06:50:21
|
Hi, i am Mag. I am a student student studying in Hong Kong. I finished the part of patch for PIC32 code, when i compile a Waba, there are errors about that cannot find cleanup() function. Please help ... I read README.uClinux file, it mentioned that the cleanup() function is necessary. Where i could place the _cleanup function ? should i palce it in some c files or create a separate c file to store this function ? Thanks !!! |
From: Olivier B. <Oli...@sm...> - 2003-02-09 09:58:29
|
Hello Mag, > I want to know how can i port Waba into uClinux !! > Do i need to change the format of Waba ?? Look at the README.uClinux file. Look at it, and ask again the list if you experience problems. Good day. Olivier --=20 Olivier Bornet http://www.smartdata.ch/ Oli...@sm... SMARTDATA SA Phone: +41-27-723'55'03 Rue du Coll=E8ge 5A GPG key ID: C53D9218 CH-1920 Martigny |
From: <mag...@ya...> - 2003-02-08 17:21:40
|
I am Mag. I want to know how can i port Waba into uClinux !! Do i need to change the format of Waba ?? Thanks !!! _________________________________________________________ 趣怪留言信箱 新年潮流方向 http://voicemail.yahoo.com.hk |
From: Noel J. B. <no...@de...> - 2002-03-12 17:41:10
|
There is a security risk reported on zlib: http://www.gzip.org/zlib/advisory-2002-03-11.txt Just FYI, in case there is a vulnerability with your VM. Many VMs use zlib internally. --- Noel |
From: Sean L. <se...@cs...> - 2001-12-04 16:46:18
|
I'm thinking of also suggesting one additional method to the Vm class: /** Tells the Waba system to be compatible with at most the semantics of the given Waba version */ public static void setCompatibility(int wabaVersion); The idea would be that by setting this method to 10000, certain methods behave differently -- for example, the Font() constructor creates CORRECT font sizes rather than the broken font sizes. And drawRect() would create CORRECT rectangles rather than the broken ones. A simpler version of this method might be: /** Tells Waba to assume the Core Waba specification, else old Waba 1.0 */ public static void setCoreWaba(boolean set); I'm a little weirded out by needing to "set" this value. But I can't think of any way around it and still retaining compatibility with drawRect() while moving forward with a corrected version. Any ideas? To keep apps from having to set this switch themselves, we might define a class like MainWindow2 or WabaWindow or something which is defined as follows: public class MainWindow2 extends MainWindow { public MainWindow2() { super(); waba.sys.Vm.setCoreWaba(true); } } So core waba users would create applications with MainWindow2 or WabaWindow or whatever, rather than MainWindow, and magically certain methods would behave differently. Hopefully, if we did this right, we'd only have to make the modifications once. Sean |
From: Sean L. <se...@cs...> - 2001-12-04 16:01:44
|
Guilherme, I defined getMaxColors as follows in Vm.java: /** Returns the number of colors supported by the device. * Colors are defined as follows: * 0 means 2^32 colors. * 1 indicates a lookup table of colors or other custom coloring, * which will be defined later * -1 is reserved for future use. * 2 means black and white. * Other values <= 16 mean that the device only supports gray scale * with that number of grays. * Negative values N also mean that the device only supports gray scale * with AbsoluteValue(N) number of grays * All other values indicate colors, and the value is the number of colors * actually supported. The number of colors *may* include alpha, * which you can ignore if you like. * If the number is a power of three, then alpha is not included. * * Some common values include: * * <ul> <li> 0 8bit/R, 8bit/B, 8bit/G, 8bit/A <li> 1 (lookup tables) <li> 2 Black and White <li> 16 16 grays <li> -256 256 grays <li> 4096 4bit/R, 4bit/B, 4bit/G <li> 32768 5bit/R, 5bit/B, 5bit/G, [maybe 1bit/A] <li> 65536 4bit/R, 4bit/B, 4bit/G, 4bit/A <li> 16777216 8bit/R, 8bit/B, 8bit/G <li> 1073741824 10bit/R, 10bit/B, 10bit/G, [maybe 2bit/A] </ul> * This odd definition is given in order to be backward-compatible * with SuperWaba. */ public native static int getMaxColors(); However, I would PREFER to define a VM function like this: /** Returns the display capabilities of the device. If the value * is positive, then it indicates the bits per pixel for each of * red, green, and blue. If the value is negative, then its absolute * value indicates the number of gray values (bits per pixel) for a * grayscale display. If the value is zero, then the display system * is custom, likely a lookup table, and must be dealt with specially. * Special handling has not been addressed as of yet. Alpha is not * indicated. Some possible values include: * * <ul> <li> 0 (custom, likely lookup tables) <li> -1 Black and White <li> -16 16 grays <li> -256 256 grays <li> 4 4bit/R, 4bit/B, 4bit/G [maybe 4bit/A] <li> 5 5bit/R, 5bit/B, 5bit/G [maybe 1bit/A] <li> 8 8bit/R, 8bit/B, 8bit/G [maybe 8bit/A] "32-bit Color" <li> 10 10bit/R, 10bit/B, 10bit/G [maybe 2bit/A] </ul> */ public native static int colorDisplay(); What would be the consequences for SuperWaba if we defined the spec display in this form? Sean |
From: Guilherme C. H. <gu...@us...> - 2001-12-03 21:24:38
|
I'm changing today the Vm class. Here are the changes: ! removed some methods from class Vm and putted as constants in class Settings. Below is the convertion table: . Vm.oldStyle==true -> Settings.uiStyle == Settings.PalmOS . Vm.oldStyle==false -> Settings.uiStyle == Settings.WinCE . Vm.getScreenSize -> Settings.screenWidth,Settings.screenHeight . Vm.isColor -> Settings.isColor . Vm.getMaxColors -> Settings.maxColors . Vm.getUserName -> Settings.userName . Vm.getPlatform -> Settings.platform Sean, thanks for your complains. guich |
From: Sean L. <se...@cs...> - 2001-12-03 19:52:39
|
After looking at Waba's and SuperWaba's Vm implementations, and knowing that implementation of the Class class will take longer than expected, allow me to make the following recommendation for a new Vm class: |
From: Sean L. <se...@cs...> - 2001-12-02 23:13:08
|
BTW, you can see the Waba error showing up in Guilherme's draw/fillRect pictures (thanks Guilherme). The dark black line should go all the away around the gray rect. That's what it does in the AWT anyway. But instead, in Waba there's a white line on the left and bottom. Sean |
From: Sean L. <se...@cs...> - 2001-12-02 23:05:14
|
Guilherme, if you could provide pictures for GraphicsTestApp.java (just run it as "java GraphicsTestApp"), I'd appreciate it. Plus, you'll be able to see what the differences are between Java's correct output and the SuperWaba output. Sean On Sunday, December 2, 2001, at 06:54 PM, Guilherme C. Hazan wrote: > Hi, > > The tests run almost well. Here are the gifs. gta is graphic test > in > appletviewer; gtp is gt in palm. The test 6 in palm gave me a pose > warning > of writing in data manager structures. The Polygon routine is different > between palm and appletviewer, so thats why the differences. Please let > me > know if any of the tests went as expected. The drawArc and fillPie (= > fillarc) algorithms were invented by a catedratic mathematic called > Guilherme Hazan. Eheheh... kidding. I had to create it bc i couldnt > find any > one available. If anyone knows a free availabe one, please let me know. > > regards > > guich > |
From: Guilherme C. H. <gu...@us...> - 2001-12-02 22:54:49
|
Hi, The tests run almost well. Here are the gifs. gta is graphic test in appletviewer; gtp is gt in palm. The test 6 in palm gave me a pose warning of writing in data manager structures. The Polygon routine is different between palm and appletviewer, so thats why the differences. Please let me know if any of the tests went as expected. The drawArc and fillPie (= fillarc) algorithms were invented by a catedratic mathematic called Guilherme Hazan. Eheheh... kidding. I had to create it bc i couldnt find any one available. If anyone knows a free availabe one, please let me know. regards guich |
From: Sean L. <se...@cs...> - 2001-12-02 22:25:26
|
I've checked to see what various JVMs do with regard to metrics for rects, ovals, arcs, lines, and roundRects. The spec is a little obtuse, but here's what it appears to say: 0. Clips and filled objects go from (x,y) to (x+width-1,y+width-1) INCLUSIVE 1. Filled objects go from (x,y) to (x+width,y+width) INCLUSIVE While practically every JVM is a little buggy with regard to the extents of roundrects, ovals, and arcs (!!), EVERY SINGLE JVM is consistent with regard to rects. Unfortunately, Waba is not. Waba presently implements its drawRect() as going from (x,y) to (x+width,y+width) inclusive. I don't know if this was a bug or an intentional decision, but it's not a good thing, that's for dang sure. Unfortunately, most Waba apps assume the incorrect measurements, while all portable Java apps assume the correct measurements, which means we may be royally screwed here. I have created some Java code for people to test with. The code draws a "bounds area", and then draws various objects such that they're supposed to fit just within the bounds area so that they just touch (but don't overwrite) the bounds area lines. The objects are first drawn and then filled. The filled version is supposed to fit just inside the drawn version and not overwrite it. Waba for the Newton also appears to not handle clips right -- it's off by 1 on the top and left. I don't know if this is a Newton bug or if it's a Waba bug (I only have Newtons); could someone run the code on a Palm/WinCE box and let me know? Here's a version that you can compile and run on your JVM and see what it does. I'd be interested in knowing about how Microsoft JVMs draw the ovals, arcs, and roundrects, because all I have here are Solaris, MacOS 9, and MacOS X 10.1. Send me some screenshots! |
From: Sean L. <se...@cs...> - 2001-12-02 19:11:27
|
I've identified a bug in Waba's Graphics.drawRect, and maybe also SuperWaba's implementation of other graphics primitives. Presently, Waba draws rectangles with one less pixel in width and one less pixel in height than java.awt.Graphics does. This is a nasty bug because drawRect is used *everywhere* in the Waba system, and fixing this bug may cause quite a number of apps to draw one-off. What should we do here? This is going to crop up again and again if we don't decide on a strategy here: what about drawRoundRect? drawOval? drawArc? All of these are correctly implemented by assuming a rectangle 1 larger and 1 higher than actually requested. For example, the corrected code is: public void drawRect(int x, int y, int width, int height) { int x2 = x + width; // got rid of a -1 int y2 = y + height; // got rid of a -1 drawLine(x, y, x2 - 1, y); drawLine(x2, y, x2, y2 - 1); drawLine(x2, y2, x + 1, y2); drawLine(x, y2, x, y + 1); } In Java, the here are the actual boundaries. <=X means the X coordinate of the leftmost pixel. >=X means the X coordinate of the rightmost pixel. Etc. Object <=X <=Y >=X >=Y drawLine(x,y,x2,y2) x y x2 y2 drawRect(x,y,width,height) x y x+width y+height OOPS! Waba draws >=X as x+width-1, and >=Y as y+height-1 fillRect(x,y,width,height) x y x+width-1 y+height-1 Other ones fyi: drawRoundRect(x,y,width, height,awidth,aheight) x y x+width y+height fillRoundRect(x,y,width, height,awidth,aheight) x y x+width y+height drawOval(x,y,width,height) x y x+width y+height fillOval(x,y,width,height) x+1 y+1 x+width-2 y+height-2 OOPS! This is *different* from drawRoundRect -- thus if you're using drawRoundRect to do drawOval (in SuperWaba say), you're probably off by one. drawArc and fillArc perform similarly to drawOval/fillOval, though there are some oddities with drawing the leftmost ray in Java (it doesn't get filled, very weird). |
From: Isao Y. <IYamashita@Vetronix.com> - 2001-11-29 19:58:55
|
I think Windows can handle the intertwined events like that. And I don't think the proposal below would break much of stuff. - extend the definition of "penDragged" to assume that if the user doesn't drag the pen within some N milliseconds of the previous event handling, that another penDragged will get called with the same coordinates -- will this break any apps you are aware of? *** Can I add one extra stuff regading the hardware buttons? I've implemented this for Palm long time ago by somebody's request, but I haven't posted it anywhere yet. Right now, I'm just defining extra const values in IKeys.java, but I've started to think to implement some kind of plug-in mechanism would be more appropriate, since so many variety of button configurations out there. For example, antenna hardware-button on PalmVII. Voice record button on iPaq. We need to come up with some clean and clever idea. Has this issue been discussed before? Isao |
From: Guilherme C. H. <gu...@us...> - 2001-11-29 19:46:25
|
> On the Newton this isn't possible, because drag events are actually > handled by polling the system for drags until you get a response. Uff! In the palm either. If the user presses in the grafitti area, the hole system is locked until he releases it. Thats why games are handled by the hard keys: pg up, pg down, etc. regards guich |
From: Sean L. <se...@cs...> - 2001-11-29 19:36:10
|
On the Palm or WinCE, is it possible to have key events or timer events occur between pen up and pen down events? As in: ... DOWN DRAG DRAG DRAG KEY KEY DRAG TIMER DRAG DRAG UP ... On the Newton this isn't possible, because drag events are actually handled by polling the system for drags until you get a response. The reason I ask this is that if the user just holds down the pen on Waba for the Newton, without moving it, the whole system goes into a wait loop until he moves or lets up; having games freeze isn't very fun. So I was thinking of proposing either: - extend the definition of "penDragged" to assume that if the user doesn't drag the pen within some N milliseconds of the previous event handling, that another penDragged will get called with the same coordinates -- will this break any apps you are aware of? - add a "penStillDown" event that's called every N milliseconds the pen is down. I prefer the former; it's cleaner. Sean |
From: Guilherme C. H. <gu...@us...> - 2001-11-28 12:42:04
|
Hi Folks, Here are the results of running WabaMark (Sieve - 75 iterations/Whetstone - 20/Linpack - 15) 1. In Waba 1.0: 220930/155420/72860 2. In SuperWaba 2.0 beta4 release 8: 136250/80400/52140 regards guich |
From: Guilherme C. H. <gu...@us...> - 2001-11-28 11:09:35
|
I'm very happy that finally someone liked my work in this list. Thats why i am disapointed with it: if i needed to implement all changes proposed here, i just had to throw SuperWaba to trash and restart all over again. I think that provide some other codepages is good, and is what i was wondering when i created that methodology. As you suggested, i'll remove the static method from String and place it at convert. regards guich |
From: Sean L. <se...@cs...> - 2001-11-28 03:24:34
|
[Last message tonight, I PROMISE!] Guich quoth: > I'll post a list of my changes on the VM so that you can know what i > done. The problem is that the list is huge (more than 70 changes) and i > cannot precise very well what had changed. Also, currently i'm out of > time > to do that. So, please give me one more week. Guich, the ones I'm particularly interested in are those which can be implemented specifically in the core VM and aren't hard to do -- most bang for the buck, you know! :-) > If you take a look at my current release and compare the > executeMethod > part, you may see many of them. > > The Waba 1.0 timmings are 143010/33340/8860/25940/126460/53250 > (graphics+native method/ loop/ field/ method/ array/ string) > The current release has: 76100/24180/4980/14870/94330/29360. Please compile and run WabaMark and let us know the results on the SuperWaba VM. (http://www.cs.gmu.edu/~sean/newton/waba/dev/WabaMark.java), especially compared to the standard Waba VM on the same handheld. Thanks! Sean |
From: Sean L. <se...@cs...> - 2001-11-28 03:20:21
|
Guilherme quoth: > Maybe you could adopt what i made in SuperWaba. > My String class has this: > /** The bytes are converted to char and vice-versa using the > CharacterConverter associated in this charConverter member. */ > public static waba.sys.CharacterConverter charConverter; > public String(byte[] value, int offset, int count); > public byte[] getBytes(); I like the general idea of supporting the getBytes() function and String(byte[],int,int) constructor. Especially since we'd need to read and write to streams. And you picked exactly the right ones to support (rather than the other myriad of byte-conversion methods). AND I like the idea of a swap-in coder. But I'm a little queasy about adding a data member to a Java-compliant a class as java.lang.String! This really pushes us away from the Java standard rapidly. So where do you stash a swap-in converter if not String? Maybe the best place would be as a static member of the waba.sys.Convert class. A few other quibbles to otherwise a nice idea: > /** This class is used to correctly handle international character > convertions. > * The default character scheme converter is the 8859-1. If you want > to use > a different one, > * you must extend this class, implementing the bytes2chars and > chars2bytes > methods, and then > * assign the public member of java.lang.String charConverter to use > your > class instead of this default one. In a PDA, ISO-8859-1 really *shouldn't* be the default. The default really should be some form which preserves Unicode values, like UTF-8. Unfortunately, Sun's suggested "default" (if your operating system doesn't have anything better) is indeed ISO-8859-1. I think that was a big mistake on their part, but oh well. If we're going the drop-in coding route, we oughta provide, at the very least, free encoders in the core spec which do ASCII, (more critical than others) UTF-8, plus maybe UTF-16BE, UTF-16LE, and UTF-16. That's all the encodings one's expected to see typically anyway, and those can all be done easily without a lookup table. Kaffe's probably got GNU versions of the encodings if you want to grab 'em. > public class CharacterConverter Converter isn't the right word. This should be an encoder, something like CharacterEncoder, or some such. No big deal though. BTW, there's a standard non-public Java class called java.lang.StringCoding, which has almost identical functions as yours, they're called: static byte[] encode(char[] ca, int off, int len); static char[] decode(byte[] ba, int off, int len); ...maybe those would be better names, just a suggestion. Also, I'm not sure if you should override CharacterEncoder, er, CharacterConverter, or if we should have an interface to extend instead, where the default class extending the CharacterEncoder interface is ISO88591Encoder. Dunno about that. Perhaps it wouldn't buy us anything in terms of memory consumption. Sean |
From: Isao Y. <IYamashita@Vetronix.com> - 2001-11-28 03:03:07
|
> How does _Java_ handle this for Win32 then? > > It seems to me that rather than this being a Font issue, this is an > implementation issue better handled at the native level when a user > requests a drawText() (or as I'm proposing rewriting it, a drawString() > or drawChars() :-). Your native implementation of drawText() basically > gets handed a string of unicode characters, and a font to draw them in. > If the font is a "Japanese" font according to your operating system, > then you take the unicode characters requested and map them into the > appropriate hi-bit escape value ASCII gunk necessary to render them > correctly. If the font is a "Cyrillic" font, you do the same thing. > > It seems to me that the software developer shouldn't even know that this > is going on. If he wants an Hangul (Korean) character like ?, he writes > drawText("\u3333"). Similarly, if he wants a Han (CJK) character like ? > then he writes drawText("\u5555"). If the system is presently not > drawing with a Hangul font or Han font or whatever, then it either draws > a stub character (on the Mac, it's a square box), or it switches > temporarily to some Hangul or Han font that's appropriate, draws the > character however necessary, and then switches back. > > [BTW, I'd be very interested in knowing who was capable of viewing the > characters I wrote above in their email! MacOS X is a wonderful > system.] > Well all right, but the developer isn't writing in ASCII. He's writing in Unicode. So if you get a Unicode character your current font is capable of rendering, you render it. If you get a character you don't know how to render, you either give a filler character, or you figure out how to switch to a different font to render that character and then switch back. Both are fine. But I feel we should avoid any platform-specific features in the core spec. *** With my system at the office, they're just blank rectangles. I guess I have to install fonts in the system in order to display them. Anyhow, I see the difference in our view here. I'm not arguing or anything, but the way I was seeing the implementation is that, you can type in characters in both ways, either "\u5555" or "?(the rectangle)", so that a coder can just type in the characters as they are displyed on his/her editor. In my case, I just typed in Kanjis with no problem, but I had to specify the values for Cyrillic characters. If we can just force them to type in the values, then it makes my life much easier. If this will be the case, we have to use one of those Unicode capable text editors. Surprisingly, it seems Java compiler takes both formats and encodes in UCS format (With JDK 1.2.2. Maybe detecting from the default OS code-page, I guess). So, I thought I ought to handle both ways too somehow. Any more thoughts? Isao |