Incongruent hash - point largness (a hoax)...and BeOS news...

Serg Koren Serg at VisualNewt.com
Wed Feb 11 17:08:08 UTC 1998


---- On Wed Feb 11 16:33:31 1998, Andreas Raab said ------

>I actually didn't want to get into this discussion but I can't resist any
>longer...
>
>> But a point IS a location. 
>

Ack! what have I started....jeez, I was just kidding! lol :-)  You guys 
need to lighten up a bit (although the arguments for and con a point being 
a location have been interesting.)  I was just playing off the previous 
post's light tone.

A point is a location with no size.  A point is infinitely small 
(whatever that means).  Hence a location is NOT a magnitude. A point is a position 
in space.  One point being larger than another point is meaningless.  However 
you CAN compare points.  The question then comes down to context and always 
in relationship to something else (usually another point or points).

(And to the person who said you can't compare apples and oranges...well 
you can you know...they are both fruit...one is orange...one 
is multicolored...both are edible...one is usually LARGER than 
another....does this mean we have to have Squeak methods for comparing apples and oranges? 
I don't think so ;-)  ).

Sorry for the uproar I've caused ;-)
S

PS - Just a quick update on the status of the BeOS port.  I'm 
still rearchitecting the interpreter code into objects... I'm taking the 
lazy approach in this cut by basically breaking the code out by 
structure....that is parts of the interpreter that deal with the image get dropped into 
the ImageObject...those things that deal with hardware specific stuff I'm 
dropping into the ApplicationObject (which I'll probably factor into 
sub-objects), etc..  I could've done a true design analysis and factored out things in 
the interpreter such as the methods dealing with bitmaps into a BitMap object, 
and the stacks into StackObjects, but I'd like to get a version up and 
running fairly quickly.  Basically, everything that requires a base class (such as 
the interpreter) get dropped into the InterpreterObject, everything else 
gets dropped into the Application, Memory, Image (File), clock/timing code into 
a StopWatch object.  non-Interpreter objects are subclasses of BeOS classes. 
 I've also discovered (no surprise) that the generated code isn't 
very efficient in some spots.   With any luck (and lots of free time since this 
is a spare-time effort) I should have everything converted and ready 
for debugging by this weekend.  I'll keep you posted on successes (and failures).

Cheers,
S


-------------------------------------------------
VisualNewt Software: http://www.VisualNewt.com/
Maker of Newt'sPaper(tm) the Premier Newton(R)
MessagePad(tm) News Reader.

-----------Sent by BeOS--------------------------





More information about the Squeak-dev mailing list