[Waba-spec] Re-starting discussion

[Sean L. <se...@cs...>]

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