waba-spec Mailing List for Waba Virtual Machine (Page 2)
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: Sean L. <se...@cs...> - 2001-11-28 02:37:31
|
Isao Quoth: > The reason for my initial proposal was that I had to match the=20= > fonts with > proper character sets. This is a requirement for code-page based > Win32 environment (WinCE, NT, 2000, XP are Unicode based). How does _Java_ handle this for Win32 then? It seems to me that rather than this being a Font issue, this is an=20 implementation issue better handled at the native level when a user=20 requests a drawText() (or as I'm proposing rewriting it, a drawString()=20= or drawChars() :-). Your native implementation of drawText() basically=20= gets handed a string of unicode characters, and a font to draw them in. =20= If the font is a "Japanese" font according to your operating system,=20 then you take the unicode characters requested and map them into the=20 appropriate hi-bit escape value ASCII gunk necessary to render them=20 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=20= is going on. If he wants an Hangul (Korean) character like =E3=8C=B3, = he writes=20 drawText("\u3333"). Similarly, if he wants a Han (CJK) character like = =E5=95=95=20 then he writes drawText("\u5555"). If the system is presently not=20 drawing with a Hangul font or Han font or whatever, then it either draws=20= a stub character (on the Mac, it's a square box), or it switches=20 temporarily to some Hangul or Han font that's appropriate, draws the=20 character however necessary, and then switches back. [BTW, I'd be very interested in knowing who was capable of viewing the=20= characters I wrote above in their email! MacOS X is a wonderful=20 system.] >> Instead of defining script in terms of "locale" (which I think is not = a >> good idea for fonts), instead define it in terms of script name. >> Unicode has some standard script names, see >> http://www.unicode.org/unicode/reports/tr24/charts/ . Stuff like=20 >> Latin, >> Armenian, Han, Hiragana, etc. If you like you can be more=20 >> sophisticated >> and allow the names to be separated by spaces, and it returns any = fonts >> which provide all three scripts, as in "Han Hiragana Hangul". If nil=20= >> is >> passed in, or the string is empty, then ALL fonts are returned. >> > >>> > Mmm, sounds like we'd have to embed many look-up tables = somewhere. > I'm not sure about this and it doesn't make me feel comfortable, > as it makes blow up Waba's code size for not-so important = feature. > I'd still like to keep this issue to a coder's discretion. Well, if you can't query the OS to get this information, you might have=20= to do it with tables or not at all. The way I was envisioning it, if=20 the system can provide this stuff, it does. If it doesn't, the array=20 that comes back is empty. It would be an optional nicety, but it's not=20= a deal-breaker for me, just an idea. >> Further, the Font.forUse()... etc. methods should assume that the=20 >> user's >> pre-defined script for his system (Japanese, Latin, etc.) biases the >> font choice for the given use. Though I'd strongly suggest that any >> such fonts should *also* be able to display Latin. > > Only up to ASCII code 127. For instance, in Japanese OS, > ASCII code up above 128 are used as flags for double byte = encoding. > So, I can't mix Japanese characters with alphabets with accent = marks > (as it is the case for code-page based OS). Well all right, but the developer isn't writing in ASCII. He's writing=20= in Unicode. So if you get a Unicode character your current font is=20 capable of rendering, you render it. If you get a character you don't=20= know how to render, you either give a filler character, or you figure=20 out how to switch to a different font to render that character and then=20= switch back. Both are fine. But I feel we should avoid any=20 platform-specific features in the core spec. Sean |
From: Isao Y. <IYamashita@Vetronix.com> - 2001-11-27 17:52:22
|
> By code-page, I assume that you're saying that something is displaying > (say) the Cyrillic range of the Unicode glyph-space. But why not just > switch the font automagically when it has to display a given character > Foo outside its range? Is this a Palm problem I'm missing somewhere? > >>> First, let me say I like the word "automagically". I think this would be a good idea. By detecting Unicode range, I can automagically change character sets. The reason for my initial proposal was that I had to match the fonts with proper character sets. This is a requirement for code-page based Win32 environment (WinCE, NT, 2000, XP are Unicode based). > On the other hand, if you have fonts which only work in certain areas, > why not specify this in the name string? As in: new Font("Cyrillic", > Font.BOLD + Font.ITALIC, 18); > > Clue me in, I'm probably not seeing it. > >>> Well, there are multiple fonts available for a given character set. Like there are two default Japanese fonts, "mincho" and "gothic". So this option is not really usable. > Now, there *is* an issue if you want to display Chinese (say) and don't > know which font is capable of doing this. You'd like an equivalent of > Font.forUse(...). One approach is: > > Change my proposed > > public static native String[] getNames(); > > to > > public static native String[] getNames(String script); > > Or instead of deleting it, you could redefine getNames() to be { return > getNames(nil); } That way you can look up all the available fonts for a > given script; of course you'd need to be able to provide such a thing > programmatically (on the Newton we'd have to just hack it and create a > little list of various-language fonts we know about). Programmers > should be informed that if the returned array is empty, they should tell > the user they can't figure out what font to use for a given script, and > perhaps ask the user to pick from a list. > > Instead of defining script in terms of "locale" (which I think is not a > good idea for fonts), instead define it in terms of script name. > Unicode has some standard script names, see > http://www.unicode.org/unicode/reports/tr24/charts/ . Stuff like Latin, > Armenian, Han, Hiragana, etc. If you like you can be more sophisticated > and allow the names to be separated by spaces, and it returns any fonts > which provide all three scripts, as in "Han Hiragana Hangul". If nil is > passed in, or the string is empty, then ALL fonts are returned. > >>> Mmm, sounds like we 'd have to embed many look-up tables somewhere. I'm not sure about this and it doesn't make me feel comfortable, as it makes blow up Waba's code size for not-so important feature. I'd still like to keep this issue to a coder's discretion. > Further, the Font.forUse()... etc. methods should assume that the user's > pre-defined script for his system (Japanese, Latin, etc.) biases the > font choice for the given use. Though I'd strongly suggest that any > such fonts should *also* be able to display Latin. > >>> Only up to ASCII code 127. For instance, in Japanese OS, ASCII code up above 128 are used as flags for double byte encoding. So, I can't mix Japanese characters with alphabets with accent marks (as it is the case for code-page based OS). > The nice feature of this is that there are Unicode scripts which aren't > locale-based: like "Sm", which is math symbols, or "No", which is > special kinds of number symbols. > >>> Ah, sounds good. > _______________________________________________ > Waba-spec mailing list > Wab...@li... > https://lists.sourceforge.net/lists/listinfo/waba-spec |
From: Guilherme C. H. <gu...@us...> - 2001-11-27 14:10:17
|
Hi, 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. 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. I expect that when i finish implement the huge memory model, all timings will fall down about 10%. All tests runs the same program (examples/bench) and in my Palm Professional handheld. regards guich |
From: Guilherme C. H. <gu...@us...> - 2001-11-27 10:58:19
|
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 = new waba.sys.CharacterConverter(); /** Creates a string from the given byte array. The bytes are converted to char using the CharacterConverter associated in the charConverter member. */ public String(byte []value, int offset, int count) { chars = charConverter.bytes2chars(value,offset,count); } /** return this String as bytes.The chars are converted to byte using the CharacterConverter associated in the charConverter member. @since SuperWaba2.0beta4 */ public byte []getBytes() { return charConverter.chars2bytes(chars,0,chars.length); } And this is the CharacterConverter class: /** 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. * Note that the java.lang.String mentioned above is located at org/superwaba/palm/classes/java.lang.String. */ public class CharacterConverter { public static char[] bytes2chars(byte bytes[], int offset, int length) { char []value = new char[length]; int i = 0; while (length-- > 0) { byte b = bytes[offset++]; value[i++] = (char)(b >= 0 ? b : (256 + b)); } return value; } public static byte[] chars2bytes(char chars[], int offset, int length) { byte []bytes = new byte[length]; int end = offset+length-1; int i = 0; byte b; for (; offset <= end; offset++) { char c = chars[offset]; if (c <= '\377') b = (byte)c; else { if ('\uD800' <= c && c <= '\uDBFF') { if (offset == end) // we must skip one byte, but no more bytes avail? break; offset++; } b = (byte)'?'; } bytes[i++] = b; } if (i != length) { byte []temp = new byte[i]; Vm.copyArray(bytes,0,temp,0,i); bytes = temp; } return bytes; } } So, if someone need a special conversion, just implement it and set the public static member of String class. regards guich |
From: Sean L. <se...@cs...> - 2001-11-27 03:06:34
|
Isao wrote: > I'd like to add couple of things on top of "Font", "Image", and > "Graphics" > classes. > > Font class: > Since some of OS don't support Unicode natively, > I'd like to add a code-page attribute to this class as an alternative. > For this, I need "String locale;" > "public Font(String name, String locale, int style, int size);", > "public String getLocale();" > "public void setLocale(String locale);" > to be added to this class. > > What I have right now is that an user passes "jp", "ru", etc. to > "locale", > and VM chooses the closest match of code page to the specified locale. I'm trying to understand what you're proposing here. A Font, as far as Java is concerned, is a family + size + formatting. Some fonts support certain character glyphs, some don't. By code-page, I assume that you're saying that something is displaying (say) the Cyrillic range of the Unicode glyph-space. But why not just switch the font automagically when it has to display a given character Foo outside its range? Is this a Palm problem I'm missing somewhere? On the other hand, if you have fonts which only work in certain areas, why not specify this in the name string? As in: new Font("Cyrillic", Font.BOLD + Font.ITALIC, 18); Clue me in, I'm probably not seeing it. Now, there *is* an issue if you want to display Chinese (say) and don't know which font is capable of doing this. You'd like an equivalent of Font.forUse(...). One approach is: Change my proposed public static native String[] getNames(); to public static native String[] getNames(String script); Or instead of deleting it, you could redefine getNames() to be { return getNames(nil); } That way you can look up all the available fonts for a given script; of course you'd need to be able to provide such a thing programmatically (on the Newton we'd have to just hack it and create a little list of various-language fonts we know about). Programmers should be informed that if the returned array is empty, they should tell the user they can't figure out what font to use for a given script, and perhaps ask the user to pick from a list. Instead of defining script in terms of "locale" (which I think is not a good idea for fonts), instead define it in terms of script name. Unicode has some standard script names, see http://www.unicode.org/unicode/reports/tr24/charts/ . Stuff like Latin, Armenian, Han, Hiragana, etc. If you like you can be more sophisticated and allow the names to be separated by spaces, and it returns any fonts which provide all three scripts, as in "Han Hiragana Hangul". If nil is passed in, or the string is empty, then ALL fonts are returned. Further, the Font.forUse()... etc. methods should assume that the user's pre-defined script for his system (Japanese, Latin, etc.) biases the font choice for the given use. Though I'd strongly suggest that any such fonts should *also* be able to display Latin. The nice feature of this is that there are Unicode scripts which aren't locale-based: like "Sm", which is math symbols, or "No", which is special kinds of number symbols. As to your examples, "jp" would be covered probably by any font which can do "Han Hiragana" or "Han Katakana". "ru" would be covered by any font which can do "Cyrillic". Sean |
From: Isao Y. <IYamashita@Vetronix.com> - 2001-11-26 18:45:23
|
FIRST PRIORITY: IMPROVED GRAPHICS API I posted replacement classes for Font, FontMetrics, Control, Graphics, and Image which basically do two things: - Add Java-compliant method names (presently we have to keep the old Waba method names, adding to class heap size I'm afraid) - Extend the Graphics object to provide for significantly more graphics primitives, still being compatible with the AWT Graphics object. - Fix Font nastiness By looking at your source files which you have posted back in last August, they look pretty good and resonable. I'd like to add couple of things on top of "Font", "Image", and "Graphics" classes. Font class: Since some of OS don't support Unicode natively, I'd like to add a code-page attribute to this class as an alternative. For this, I need "String locale;" "public Font(String name, String locale, int style, int size);", "public String getLocale();" "public void setLocale(String locale);" to be added to this class. What I have right now is that an user passes "jp", "ru", etc. to "locale", and VM chooses the closest match of code page to the specified locale. Isao |
From: Sean L. <se...@cs...> - 2001-11-26 00:22:30
|
The list has been pretty quiet lately, and that concerns me. Let me=20 attempt to restart certain discussions: FIRST PRIORITY: IMPROVED GRAPHICS API I posted replacement classes for Font, FontMetrics, Control, Graphics,=20= and Image which basically do two things: - Add Java-compliant method names (presently we have to keep the=20= old Waba method names, adding to class heap size I'm afraid) - Extend the Graphics object to provide for significantly more = graphics primitives, still being compatible with the AWT Graphics = object. Guilherme should like the collection I provided I think. - Fix Font nastiness I've not heard whether or not we're at the point where we should discuss=20= this, but given the quietness of the list I propose we do so. THE REGISTRY At the end of this message, I have some recommendations for changes to=20= the Registry documentation at=20 http://waba.sourceforge.net/javadoc/waba/io/Registry.html Assuming these are implemented, I then move that the Registry be = adopted. SUPERWABA OPTIMIZATIONS A while back Guilherme posted that he had made certain optimizations to=20= the Waba core VM which boosted speed 30%. Guich, could you tell us the=20= specifics of those optimizations? Which ones are trivially=20 implementable, and can you provide the code diffs and explanations to=20 implement them, especially on weird environments like the Newton? "JAVALIKE" CLASSES A while back I posted a collection of classes which implement chunks of=20= the core functionality that the KVM gives. I won't claim they're CLDC=20= compliant, though they should make porting much simpler. I move that=20 (modulo bug-fixes; the classes are totally untested) we replace=20 waba.ui.Vector with my Vector class, and add the Stack, Hashtable, Math,=20= Random, Enumeration, Boolean, Byte, Character, Float, Integer, and Short=20= classes, which can be added trivially. We should modify the Vm and=20 Convert classes accordingly. Secondly we should consider adding the=20 String, StringBuffer, and Object classes, though we may want to give=20 more consideration to the String and StringBuffer classes for memory=20 consideration issues. Lastly, we should implement the Class, System,=20 and Object classes as described in the collection if/when we can get=20 Class objects working. The Throwable, *Exception, and Error classes must wait until and if we=20= ever get around to implementing exception handling in the Waba VM. the=20= Double and Long classes may be added if your system supports it, but are=20= not required. ------ Registry documentation changes. The modifications I made are between=20 ***STARS***. ----------------------- writeBytes public int writeBytes(byte[]=A0buf, int=A0start, int=A0count) ***Deletes any bytes stored in the Registry at the current position and=20= beyond, then writes the provided bytes into the Registry starting at the=20= current position. Updates the current position to just beyond the=20 newly-written bytes.*** Overrides: writeBytes in class Stream Parameters: buf - buffer from which the data should be taken start - position in the buffer to start taking data count - number of bytes to write Returns: the number of bytes actually written, -1 indicating an error ----------------------- skipBytes public int skipBytes(int=A0count) Skip bytes. ***The bytes to skip may be negative.*** Parameters: count - the number of bytes to skip; ***if count will skip to less than=20= the first byte position (position 0), then the new position is set to=20 0. If count will skip to beyond the data currently in the Registry,=20 then the position is set to just beyond the final byte in the=20 currently-written data.*** ***[DELETE: the result of skipping past=20 data that has been previously written is implementation-dependent]*** Returns: the new position in the Registry, or -1 if an error occurred |
From: Noel J. B. <no...@de...> - 2001-11-10 03:58:06
|
CE Wire (www.cewire.com) is running a survey: "Do you want to develop in Java on your WinCE device, or just in Visual C++?" The results really do surprise me, given the normal assumptions about the people programming for the platform: "Mainly Java: 43% Mainly VC++: 34% Both: 23%" --- Noel |
From: Christian G. <chr...@sm...> - 2001-10-25 16:33:34
|
Hello, On Wed, Oct 17, 2001 at 03:59:58PM -0400, Sean Luke wrote: > Here are my initial thoughts on the final Registry description. Thank you for the feedback! > 1. There is no reason why you shouldn't be able to skip negative bytes. > If you back up to position X, and then start writing, the Registry > should assume that everything after X is automatically deleted. I modified 'skipBytes' accordingly. I am assuming that no platform will have a problem with this (reel tapes are not that common on PDA's :-) ). > 2. What happens if you delete the registry while it's open? Can you > continue to write? Would that recreate the registry (I assume not)? Or > do you have to call getRegistry() again? Reading/writing after having deleted the Registry is undefined; one should re-obtain it. I modified the documentation accordingly. > 3. There should be a function indicating the maximum feasible number of > bytes that the registry can hold. I added a 'spaceAvailable()' method, which would return the amount of registry space available at that moment. Is that what you had in mind? > 4. I presume that the registry does not take locking into consideration: > if you have multiple instances of your application open, I presume the > result is undefined? Which is fine, just as long as we state this. Another good point. The result would indeed be undefined, and I modified the documentation accordingly. Let me know what you think. Thanks, -Christian |
From: Guilherme C. H. <gu...@us...> - 2001-10-19 10:12:49
|
Hi Scott, > I think you are misunderstanding the concept here. Currently platforms > other than PalmOS don't have catalogs, but they emulate them. Why can't > SW emulate the Registry or Database class using underlying Catalogs? > (just like SW emulates catalogs on WinCE and Java) But i did agree with the Registry class. You can see an e-mail i sent about the registry topic. It only have one work: agreed. About the Database class, i need more time to see if its feasible. I'll do that next week. > Why does a SW program need access to real Palm Catalogs? > If a SW program needs to access real PalmOS catalogs (like the MemoDB or > AdressDB) then the program will only work on the Palm. Shouldn't the > SW(waba) api reflect this platform dependancy? Don't windows have Notepad and address books? we could use a common denominator. > Is your concern backwards compatiblity? Sure. I'll not break backwards compatibility (even with PalmOS 2.0). > Sorry if I'm being too confronting, but I want to try to understand why > you disagree. You're more correct than me. bye guich |
From: Scott C. <sc...@co...> - 2001-10-19 04:39:33
|
>>- move the Catalog class to the Palm platform specific branch. This mean >> it's available for the Palm implementation, but not necessary for >> others. >><< >> >> Disagree. Catalog must be implemented in all platforms. >> Otherwise, Palm programs will able to run other platforms >> without being modified. > > But that's why they're *Palm* programs! If you want to run on other > > platforms without being modified, use the Registry class and/or a > > Database class replacement of some sort. > > Sean (and all), this is really out of discussion. There is *no* other > options for storage in PalmOS. If the spec decides that it should be moved, > SW will not implement that decision. Guich, I think you are misunderstanding the concept here. Currently platforms other than PalmOS don't have catalogs, but they emulate them. Why can't SW emulate the Registry or Database class using underlying Catalogs? (just like SW emulates catalogs on WinCE and Java) Why does a SW program need access to real Palm Catalogs? If a SW program needs to access real PalmOS catalogs (like the MemoDB or AdressDB) then the program will only work on the Palm. Shouldn't the SW(waba) api reflect this platform dependancy? Is your concern backwards compatiblity? Sorry if I'm being too confronting, but I want to try to understand why you disagree. scott |
From: Rony G. F. <Ron...@wu...> - 2001-10-18 11:02:04
|
Guilherme Hazan wrote: > >> > - move the Catalog class to the Palm platform specific branch. This mean > it's available for the Palm implementation, but not necessary for > others. > << > > Disagree. Catalog must be implemented in all platforms. Otherwise, no > Palm programs will able to run other platforms without being modified. *Strong* support. It should be possible to retrofit the Palm catalog (together with attributes) on to any filesystem of any other operating system. (It is for all practical means *impossible* to get the file notion performant onto the Palm devices using Palm catalogs.) (Super)Waba should be about programs to be written once and to be run on any *present* PDA-platform. Going the device-dependent route should be a *last* *resort* for extremely important functionality. The largest market share of PDAs by all means, like it or not, is the Palm segment; so that should be the premiere platform to be considered (but keeping an eye on the devlopment of other platforms, of course). Just my 2c. ---rony |
From: Guilherme C. H. <gu...@us...> - 2001-10-17 21:31:28
|
> Serialization is a LARGE addition to the VM, both in terms of VM support > underneath, and in terms of supporting Java classes. That's why, for > example, that the CLDC doesn't support it. I think we should think very > hard whether or not the advantages of the feature (which I use heavily > in "real" Java programs) outweigh its significant disadvantages in terms > of majorly bloating the system. I already did a function that does serialization in SW (but it didnt worked :-) ). It receives an object and stores all primitive/String types. We could use something like that. > But that's why they're *Palm* programs! If you want to run on other > platforms without being modified, use the Registry class and/or a > Database class replacement of some sort. Sean (and all), this is really out of discussion. There is *no* other options for storage in PalmOS. If the spec decides that it should be moved, SW will not implement that decision. > Record attributes are a Palm thing, ar they not? What kind of > general-purpose "attributes" are you thinking of? I can still be > convinced. /** Read Only database */ public static final int DB_ATTR_READ_ONLY = 0x0002; /** Set if Application Info block is dirty. Optionally supported by an App's conduit */ public static final int DB_ATTR_APPINFODIRTY = 0x0004; /** Set if database should be backed up to PC if no app-specific synchronization conduit has been supplied. */ public static final int DB_ATTR_BACKUP = 0x0008; /** This tells the backup conduit that it's OK for it to install a newer version of this database with a different name if the current database is open. This mechanism is used to update the Graffiti Shortcuts database, for example. */ public static final int DB_ATTR_OK_TO_INSTALL_NEWER = 0x0010; /** Device requires a reset after this database is installed. */ public static final int DB_ATTR_RESET_AFTER_INSTALL = 0x0020; /** This database should not be copied to */ public static final int DB_ATTR_COPY_PREVENTION = 0x0040; /** This database is used for file stream implementation. This attribute may not be used. */ public static final int DB_ATTR_STREAM = 0x0080; /** Record atribute: Deleted */ public static final byte REC_ATTR_DELETE = (byte)0x80; /** Record atribute: Dirty (has been modified since last sync) */ public static final byte REC_ATTR_DIRTY = (byte)0x40; /** Record atribute: Private */ public static final byte REC_ATTR_SECRET = (byte)0x10; regards guich |
From: Sean L. <se...@cs...> - 2001-10-17 20:00:02
|
Here are my initial thoughts on the final Registry description. 1. There is no reason why you shouldn't be able to skip negative bytes. If you back up to position X, and then start writing, the Registry should assume that everything after X is automatically deleted. 2. What happens if you delete the registry while it's open? Can you continue to write? Would that recreate the registry (I assume not)? Or do you have to call getRegistry() again? 3. There should be a function indicating the maximum feasible number of bytes that the registry can hold. 4. I presume that the registry does not take locking into consideration: if you have multiple instances of your application open, I presume the result is undefined? Which is fine, just as long as we state this. Now as to some other stuff. Olivier had written: > - take the Ewe's Datastore package and insert it in the extension API. By my read, Datastore requires a *lot* of underlying modification; further I think it is inappropriate for environments which do not file storage. Am I misreading the description? If Datastore can sit on top of existing stream protocols with little or no underlying VM changes, then I think we might consider it. But if it requires VM modification, we should talk about it some more: I don't like the idea of changing the VM semantics to support a nonstandard package. That's a recipe for spaghetti code. So I want to discuss this further first. > - postpone the java.util.Map (and the associated class) to the next > release of the specifications. In truth, I don't think we should implement Map at all. The CLDC doesn't. It's too heavyweight for our purposes. > - postpone the serialization also to a future release of the API. Serialization is a LARGE addition to the VM, both in terms of VM support underneath, and in terms of supporting Java classes. That's why, for example, that the CLDC doesn't support it. I think we should think very hard whether or not the advantages of the feature (which I use heavily in "real" Java programs) outweigh its significant disadvantages in terms of majorly bloating the system. > - move the Catalog class to the Palm platform specific branch. This mean > it's available for the Palm implementation, but not necessary for > others. > << > > Disagree. Catalog must be implemented in all platforms. Otherwise, no > Palm programs will able to run other platforms without being modified. But that's why they're *Palm* programs! If you want to run on other platforms without being modified, use the Registry class and/or a Database class replacement of some sort. > - take http://waba.sourceforge.net/javadoc/waba/io/CatalogSeanLuke.html > for the base of the discussion when the topic "Catalog class" will > come. > << > > Does this make sense in other platforms too? > > /** Retrieves the attributes of the current record. Use the > REC_ATTR_xxx > masks to set/retrieve its states. @returns 0 if db dont exists @since > 2.0 */ > public byte getRecordAttributes() > { > return NativeMethods.nm.catalogGetRecordAttributes(this); > } Record attributes are a Palm thing, ar they not? What kind of general-purpose "attributes" are you thinking of? I can still be convinced. > To limit the discussions, I suggest to agree with complete package, and > not to split them. I suggest to take all but the Throwable. This mean, > WRAPPER, UTILITY, SYSTEM and MODIFIED. I know Sean say the last one to > take is SYSTEM, but I think if we take them later, the classes allready > in Waba continue to diverge, and it will be more difficult in the future > to change them. Yeah, that's doable, though I might need some help on implementing the Class class. The throwable classes may be easily removed, but only by commenting out all the "throw" statements in the other classes; otherwise they will get compiled in with the other class files when you make your app. That's fine to do this, though we should keep "thrown" versions of the classes around that are compatible for the future situations when we do (?) get exception handling. BTW, I don't recall if the Vector class has backward-compatible functions for the old waba.util.Vector class or not, it's easily enough added in. Sean |
From: Olivier B. <Oli...@sm...> - 2001-10-17 16:08:10
|
Hello, > Zeroth off, the classes we're referring to can be found at=20 > http://www.cs.gmu.edu/~sean/newton/waba/dev/wababase.zip You can access the documentation (javadoc) of these classes at : http://waba.sourceforge.net/javadoc_wababase/ Here is the full list : > THROWABLE CLASSES > ----------------- > ArithmeticException > ArrayIndexOutOfBoundsException > ArrayStoreException > ClassCastException > ClassNotFoundException > Error > Exception > IllegalAccessException > IllegalArgumentException > IndexOutOfBoundsException > InstantiationException > NegativeArraySizeException > NullPointerException > NumberFormatException > RuntimeException > StringIndexOutOfBoundsException > EmptyStackException > NoSuchElementException > Throwable > WRAPPER CLASSES > --------------- > Boolean > Byte > Character > Double > Float > Integer > Long > Short > UTILITY CLASSES > --------------- > Math > Enumeration > Hashtable > Random > Stack > Vector > SYSTEM CLASSES > -------------- > Class > Object > String > StringBuffer > System > MODIFIED WABA CLASSES > --------------------- > waba.sys.Convert > waba.sys.Vm To limit the discussions, I suggest to agree with complete package, and not to split them. I suggest to take all but the Throwable. This mean, WRAPPER, UTILITY, SYSTEM and MODIFIED. I know Sean say the last one to take is SYSTEM, but I think if we take them later, the classes allready in Waba continue to diverge, and it will be more difficult in the future to change them. > > Are we trying to reinvent the wheel? Aren't there other tools tha= t > > implements the full set of Java in the devices? Why are we going in t= he=20 > > same > > direction? >=20 > Olivier probably didn't understand: these classes are already finished,= =20 > they just need to be debugged. I have correctly understand. I have accepted all these classes because they are mostly finished. Good day. Olivier --=20 Olivier Bornet SMARTDATA SA Oli...@sm... Centre du Parc http://www.smartdata.ch av. des Pr=E9s-Beudin 20 Phone +41-27-723'55'03 1920 Martigny Fax +41-27-723'55'19 Phone +41-27-723'55'18 |
From: Guilherme H. <gu...@us...> - 2001-10-17 15:27:35
|
Hi, >> - move the Catalog class to the Palm platform specific branch. This mean it's available for the Palm implementation, but not necessary for others. << Disagree. Catalog must be implemented in all platforms. Otherwise, no Palm programs will able to run other platforms without being modified. >> - take http://waba.sourceforge.net/javadoc/waba/io/CatalogSeanLuke.html for the base of the discussion when the topic "Catalog class" will come. << Does this make sense in other platforms too? /** Retrieves the attributes of the current record. Use the REC_ATTR_xxx masks to set/retrieve its states. @returns 0 if db dont exists @since 2.0 */ public byte getRecordAttributes() { return NativeMethods.nm.catalogGetRecordAttributes(this); } /** Sets the attributes of the current record. Use the REC_ATTR_xxx masks to set/retrieve its states. @since 2.0 */ public void setRecordAttributes(byte attr) { NativeMethods.nm.catalogSetRecordAttributes(this, attr); } /** Retrieves this catalog's attributes. Use the DB_ATTR_xxx masks to retrieve its states. @returns 0 if no current record @since 2.0 */ public int getAttributes() { return NativeMethods.nm.catalogGetAttributes(this); } /** Sets this catalog's attributes, defined by the DB_ATTR_xxx constants. The original attributes must be getted prior applying this value. If not, you can loose your database and your app will crash. @since 2.0 */ public void setAttributes(int i) { NativeMethods.nm.catalogSetAttributes(this, i); } ///////// guich: note this is a feature request, so it may be added. /** Returns the currect record position or -1 if there is no current record. @since SuperWaba2.0beta3 */ public int getRecordPos() { return NativeMethods.nm.catalogGetRecordPos(this); } regards |
From: Olivier B. <Oli...@sm...> - 2001-10-17 15:11:51
|
Hello, as the opinion of every one is not clear for me, thanks to answer _brievly_ (agree/disagree) to all this questions : - move the Catalog class to the Palm platform specific branch. This mean it's available for the Palm implementation, but not necessary for others. - take http://waba.sourceforge.net/javadoc/waba/io/CatalogSeanLuke.html for the base of the discussion when the topic "Catalog class" will come. - implement the (simple) Registry class as suggested by Sean in the Core Classes. - take the Ewe's Datastore package and insert it in the extension API. - postpone the java.util.Map (and the associated class) to the next release of the specifications. - postpone the serialization also to a future release of the API. After that, I will take every point causing problems into discution. Good day. Olivier --=20 Olivier Bornet SMARTDATA SA Oli...@sm... Centre du Parc http://www.smartdata.ch av. des Pr=E9s-Beudin 20 Phone +41-27-723'55'03 1920 Martigny Fax +41-27-723'55'19 Phone +41-27-723'55'18 |
From: Olivier B. <Oli...@sm...> - 2001-10-17 15:05:08
|
Hello all, the proposed waba.io.Registry class is available for discution on the javadoc server : http://waba.sourceforge.net/javadoc/ or directly : http://waba.sourceforge.net/javadoc/waba/io/Registry.html We have implemented it on waba@sourceforge in the Linux port, both using a file system or a flash memory. If you are OK with the definition, I will include it in the specifications. Good day. Olivier --=20 Olivier Bornet SMARTDATA SA Oli...@sm... Centre du Parc http://www.smartdata.ch av. des Pr=E9s-Beudin 20 Phone +41-27-723'55'03 1920 Martigny Fax +41-27-723'55'19 Phone +41-27-723'55'18 |
From: Sean L. <se...@cs...> - 2001-10-12 19:32:12
|
On Fri, 12 Oct 2001 wab...@li... wrote: > In this weekend i'll release SuperWaba 2.0beta4. One of its big > changes is in the license. > > I asked Rick to let me change the license to LGPL and he answered this: > > "I don't disagree with anyone trying to make some money off Waba. > There have been a few companies who have taken a shot at it and as > long as they do a good job, I support their efforts. As long as there > isn't something that keeps a basic waba being free, I'm ok with it. " So from this I assume he agreed to let you change it to LGPL, is this correct? > So, SuperWaba must run now separetely from the WabaSpec. Why? > Here are 2 questions: > > 1. can a gpl product use a Lgpl piece of code? Yes. But if the LGPL code is part of the GPL product, it must be distributed under GPL. > 2. can a Lgpl product use a gpl piece of code? It depends; if it's just linked, then the answer is yes. If it's distributed as part of the source distribution, and is tightly coupled, then the whole thing must be GPL I believe. > If both answers are true, please disregard the last phrase in the last > paragraph. Which one: the statement about not being able to be compatible with the Waba Spec? > ps: i don't remember who changed the license to bsd, but, if you dont want > to have your code hijacked, better change it to other thing. Rick permitted the Newton group do use his code under the BSD license. BSD code can be distributed under GPL without any problem. Guilherme, you are absolutely welcome use any and all Waba for Newton source in SuperWaba if it's distributed LGPL or GPL (or BSD). Sean |
From: Guilherme C. H. <gu...@us...> - 2001-10-12 13:50:12
|
Hi my friends, In this weekend i'll release SuperWaba 2.0beta4. One of its big changes is in the license. I asked Rick to let me change the license to LGPL and he answered this: "I don't disagree with anyone trying to make some money off Waba. There have been a few companies who have taken a shot at it and as long as they do a good job, I support their efforts. As long as there isn't something that keeps a basic waba being free, I'm ok with it. " So, SuperWaba must run now separetely from the WabaSpec. That dont means that it wont follow the WabaSpec, but we must be careful about using each others code. Also, i'm a little confused if a lgpl isnt so much "free" as he wants. Here are 2 questions: 1. can a gpl product use a Lgpl piece of code? 2. can a Lgpl product use a gpl piece of code? If both answers are true, please disregard the last phrase in the las paragraph. Starting at January, i'll create SuperWaba.com, and i'll try to live from it, specially by giving courses and support. I'll also port SW to all platforms, including phone ones. The idea is to spread its use to all over the world. And, i'm very emotioned with all the good words and aproval i received from people regarding this idea. Michael: can i use in SW your code for Introspection? thanks guich ps: i don't remember who changed the license to bsd, but, if you dont want to have your code hijacked, better change it to other thing. |
From: Noel J. B. <no...@de...> - 2001-10-11 16:27:56
|
Rony, Why become more compatible with PJava? Because if Waba does not, eventually it will be marginalized, and cease to offer significant value. And Waba DOES have things to offer into the PJava environment. As I stated, and as you reiterated, "Waba allows almost anyone to master programming GUI-apps for PDAs within a couple of weeks. Its user interfaces are more geared towards PDAs." The core classes should have the same interface as those in PJava. I do not see any point to migrating over the UI from PJava. PJava compatible exception and thread handling classes need to be added to Waba. This isn't new. Many of us have been making these points for months. I am simply point out that Java is starting to be a standard component on more PDAs. PDAs will continue to get faster and more capable. The massive migration from PalmOS to PocketPC indicates that a miminalist strategy is failing to meet the increasing needs of more and more users. Eventually it is almost certain that PJava will fit on all PDAs. If we focus on what makes Waba good on PDAs, we are in a position to offer that knowledge and experience to the larger PDA Java community. For example, classes from Waba or Ewe would offer PJava users a more appropriate UI framework. --- Noel |
From: Rony G. F. <Ron...@wu...> - 2001-10-11 08:58:45
|
"Noel J. Bergman" wrote: > I've been very busy lately, but I agree with the general statement that Waba > should strive for (greater) compliance with Personal Java. The announcement > that every new 3800 series iPAQ will come loaded with Java > (http://www.sun.com/smi/Press/sunflash/2001-10/sunflash.20011004.2.html) > lends more weight behind the standard. > > In the case of Waba, I think that we have a lot to offer, especially with > classes that are much smarter about the PDA environment, e.g., stylus-based > UI and other PDA classes, such as Michael's support for PDA<->desktop > interactions. > > But greater source compatibility with PersonalJava is important. What for? (Or better phrased: to what extent and why?) --- In the case of SuperWaba 2.0b4 it seems that Guich rewrote parts such that the (Super)Waba applications are able to run unaltered under a plain vanilla JVM with the JFC available. So this is good and opens up the field for (Super)Waba programs to new environments per se. No need to turn (Super)Waba into a true subset of Java. If someone really wants/needs it then s/he would be better of using PJ and the likes. --- Now, making some core (lang) classes in Waba/Java more compatible to Java's then this is another discussion (and yes, personally, I would prefer that as well, *but* only as long as the interfaces remain simple and (Super)Waba programs remain functional without re-compiling). One big advantage of (Super)Waba over Java is its concise set of classes, making it much simpler than trying to master a huge mountain of massive of classes as is the case with "classic" Java with its (important) sets of classes for different purposes. Also, many classes offered by others compared to Java's are lightweighted in the sense, that they do not implement a functionality comparable of an "egg-laying-wool-milk-sow" (as is often the case with Sun's Java) but implement the core of the most-needed ("core") functionality. (Super)Waba allows almost anyone to master programming GUI-apps for PDAs within a couple of weeks. Its user interfaces are more geared towards PDAs. And it runs on non-overpowered-PDAs (like WindowsCE machines with 200+ MHz). Hence its potential remains intact for merging with wireless phones etc. at least in the next couple of years to come. --- So, no, I would not think it desirable that (Super)Waba becomes a true subset of Java, although all of the used core classes (mostly the lang stuff) should have as much of the same interfaces as the true Java in order to make switching over to (Super)Waba as easy as possible. Just my two cents ... ---rony |
From: Noel J. B. <no...@de...> - 2001-10-10 15:08:18
|
I've been very busy lately, but I agree with the general statement that Waba should strive for (greater) compliance with Personal Java. The announcement that every new 3800 series iPAQ will come loaded with Java (http://www.sun.com/smi/Press/sunflash/2001-10/sunflash.20011004.2.html) lends more weight behind the standard. In the case of Waba, I think that we have a lot to offer, especially with classes that are much smarter about the PDA environment, e.g., stylus-based UI and other PDA classes, such as Michael's support for PDA<->desktop interactions. But greater source compatibility with PersonalJava is important. --- Noel |
From: Sean L. <se...@cs...> - 2001-10-09 19:33:23
|
Guilherme wrote: > > My opinion on this is: Waba is too different from the Java standard. > > It's making porting difficult. SuperWaba is pushing us even further in > > this direction. I think that if we're trying to establish a good > > standard set of classes, we should bite the bullet and implement a good > > set of basic classes rather than try to modify the noncompatible ones we > > presently have. We only have to do this once. > > In fact SW did not started that nightmare, i'm just continuing in the > same path, exactly to make SW fully back compatible with Waba. ...well, I wouldn't exactly call it a nightmare! But there are many function calls in Waba and SuperWaba which are named differently than the equivalents in Java. This makes porting from Java unenjoyable. Rick did this, as I understand, to avoid the iron thumb of Sun, and that's perfectly reasonable. But Sun has been relatively tolerant of systems which don't claim to be "Java" lately, except anything coming out of Microsoft. :-) I think that, whenever it doesn't add significant burden to the VM, we should strive to use classes and method names that make porting as simple as possible. But I'm not going hog-wild here. I don't think that we should implement MIDP etc.! My goal here is to provide some similar functionality in some core classes where we can, but be different where we have to (like interfaces etc.) > "Hi, I've been doing a skunkworks project on the feasibility of Java > development on PDA platforms. So far in terms of getting a straight > forward app up an running, SuperWaba wins in every way I care about. > > As far as I can tell, all the big commercial players are doing > heavyweight "compliant" implementations of full JVMs on PDAs and/or > MIDP with proprietary GUIs for PDA's. I'm interested in knowing if > SuperWaba is on a different trajectory and if so, where it's headed? > > 1. Given infinite resources and a fair wind, what [might/will/should] > SuperWaba be in a years time? > > 2. Is the intention to ultimately provide a complete cleanroom > implementation of all concievable Java classes or to specifically > avoid this in order to remain small and fast?" My response to this person is as follows: There is a tradeoff between compatibility with the Java codebase; and good, fast portable design for PDAs. Right now Waba has swung way out towards good, fast portable design, ignoring compatibility. SuperWaba has swung out a little further still. There were good justifications for this at the time, but hindsight is 20/20. In working with the Waba Core, I'm trying to swing back *a*little*, to retain the design advantages of Waba while providing a little more compatibility to make us not totally cut off from the Java world. Sean |
From: Guilherme H. <gu...@us...> - 2001-10-08 21:07:07
|
> > > My opinion regarding this is: keep waba small as possible. > > Implementing > > too much classes wont make it powerful. People like Waba bc it is small > > and > > powerful. > > My opinion on this is: Waba is too different from the Java standard. > It's making porting difficult. SuperWaba is pushing us even further in > this direction. I think that if we're trying to establish a good > standard set of classes, we should bite the bullet and implement a good > set of basic classes rather than try to modify the noncompatible ones we > presently have. We only have to do this once. In fact SW did not started that nightmare, i'm just continuing in the same path, exactly to make SW fully back compatible with Waba. > > That being said, I've worked hard to make these classes as > backward-compatible as possible. In fact, they should be implementable > without *any* modifications to existing applications. Im sure you did a good job. The basic point of Waba and SuperWaba is a user question: "Hi, I've been doing a skunkworks project on the feasibility of Java development on PDA platforms. So far in terms of getting a straight forward app up an running, SuperWaba wins in every way I care about. As far as I can tell, all the big commercial players are doing heavyweight "compliant" implementations of full JVMs on PDAs and/or MIDP with proprietary GUIs for PDA's. I'm interested in knowing if SuperWaba is on a different trajectory and if so, where it's headed? So, my questions: 1. Given infinite resources and a fair wind, what [might/will/should] SuperWaba be in a years time? 2. Is the intention to ultimately provide a complete cleanroom implementation of all concievable Java classes or to specifically avoid this in order to remain small and fast? Any enlightenment or opinion welcome. -- Paul Sidnell Electric Pocket http://electricpocket.com " Make your own conclusions... guich |