All together now ;-)

Hi Guys -

You probably noticed that I was busy working on the latest Croquet VMs -
the whole set of issues and changes that I am dealing with right now are
for Croquet 1.0. It seems like things are settling down now (at least I
have no obvious things on my TODO list any longer) and a consolidated
version of VMMaker which includes all the issues discussed here is
available at the repository at:

   http://hedgehog.software.umn.edu:8888/Homebase.html

Tim - This (or perhaps the version two weeks from now ;-) is probably a
good version for you to merge back into the main line when you find the
time for it. There aren't many changes, just what I was dealing with in
general (FloatMathPlugin, Tests, CroquetPlugin, SocketPlugin) so
integration should be straightforward.

Cheers,
   - Andreas

On 26-Mar-06, at 10:05 PM, Andreas Raab wrote:
>
>   http://hedgehog.software.umn.edu:8888/Homebase.html
>
> Tim - This (or perhaps the version two weeks from now ;-) is  
> probably a good version for you to merge back into the main line  
> when you find the time for it. There aren't many changes, just what  
> I was dealing with in general (FloatMathPlugin, Tests,  
> CroquetPlugin, SocketPlugin) so integration should be straightforward.

Notes from looking at the diffs -
AsynchFilePlugin
What about #primitiveAsyncFileWriteStart:fPosition:fromBuffer:at:  
count: Seems to need a fix from 'int' to 'sqInt' but you missed it.  
Or was that deliberate for some inscrutable reason?

B3DAcceleratorPlugin
Are you wanting that added to VMMaker? IIRC it has heretofore been  
kept in the Balloon3D package.

CroquetPlugin
Do you want that in the VMM package too?
- any dependencies in image to worry about? Things in shared pools  
come to mind.

FilePlugin
many removals of oopForPointer: ? Seems wrong to me. oopForPointer is  
pretty important according to Ian's writeup on 64 bit changes. Though  
it (the macro at least) probably does need fixing for cases were  
sqMemoryBase is non-0.

FloatMathPlugin
- I couldn't see code beyond the class decl in your .49 package. Do  
you want it in VMM?
And what about the tests? Not for VMMaker inclusion in my view.

Mpeg3Plugin
Use of file name checking call bothers me. John, why is there a  
rather pointless indirection of sqFilenameFromStringOpen through  
ioFilenamefromStringofLengthresolveAliases ? Is the resolve alisases  
nonsense even needed now you've changed to OSX support only and using  
unix style filenames?



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SDR: Shift Disk Right

Hi Tim -

> AsynchFilePlugin
> What about #primitiveAsyncFileWriteStart:fPosition:fromBuffer:at: count:
> Seems to need a fix from 'int' to 'sqInt' but you missed it. Or was that
> deliberate for some inscrutable reason?

Something's wrong here... since I didn't touch that at all. It should be
the same version that is on SqueakMap. Ditto for FilePlugin and
oopForPointer: - I haven't touched FilePlugin at all.

> B3DAcceleratorPlugin
> Are you wanting that added to VMMaker? IIRC it has heretofore been kept
> in the Balloon3D package.

Yes. Balloon3D is dead (has been for a couple of years now).

> CroquetPlugin
> Do you want that in the VMM package too?
> - any dependencies in image to worry about? Things in shared pools come
> to mind.

Currently, there are no dependencies. Whether it should be kept in
VMMaker ... good question. I think it might make things easier for
everyone involved (any contrary opinions?).

> FloatMathPlugin
> - I couldn't see code beyond the class decl in your .49 package. Do you
> want it in VMM?
> And what about the tests? Not for VMMaker inclusion in my view.

Yes, this should definitely go into VMMaker. I also think we should have
those "FloatMathPluginTests" in VMMaker because they make sure that the
primitives in the plugin function properly (and are therefore mostly
needed for the person building the VM). I have essentially the same
tests duplicated in the CroquetVMTests to ensure that (for example) the
implementation of Float>>exp adheres to the requirement, but that seems
independent from the VM builder's side.

> Mpeg3Plugin
> Use of file name checking call bothers me. John, why is there a rather
> pointless indirection of sqFilenameFromStringOpen through
> ioFilenamefromStringofLengthresolveAliases ? Is the resolve alisases
> nonsense even needed now you've changed to OSX support only and using
> unix style filenames?

I'll leave this one for John.

Cheers,
   - Andreas

Andreas,

How does your new FloatMathPlugin work with the existing floating
point? Is it meant to replace all other floating point calculations?
I can see how that would be advantageous for some applications but for
others the speed of hardware floating point may be more important.

OK, for now, the library you're using may be as fast as the
interpreter but adding some basic floating point support to Exupery
would be fairly easy.

Bryce

P.S. Andreas, I sent this directly to you by mistake. I meant
to send to the list.

Bryce Kampjes wrote:
> P.S. Andreas, I sent this directly to you by mistake. I meant
> to send to the list.

Well, then here's my reply to the list:

 > How does your new FloatMathPlugin work with the existing floating
 > point? Is it meant to replace all other floating point calculations?

If you mean basic operations like add, subtract, divide, multiply by
"all other calculations", then no. FloatMathPlugin includes only the
following functions: acos, acosh, asin, asinh, atan, atan2, atanh, cos,
cosh, exp, fmod, modf, hypot, log10, log, sin, sinh, sqrt, tan, tanh, ldexp.

 > I can see how that would be advantageous for some applications but for
 > others the speed of hardware floating point may be more important.

With the exception of sqrt I have found the functions in fdlibm to be
exceedingly fast (to the point of performing on par or better with the C
library functions when compiled in a static C program, e.g., not
counting any additional overhead for allocation etc). And sqrt is
(fortunately) fairly well-defined so that (on Intel at least) we can use
the hardware fsqrt instead of the fdlibm version. I'm hoping that this
will be true in general (but we'll find out soon).

 > OK, for now, the library you're using may be as fast as the
 > interpreter but adding some basic floating point support to Exupery
 > would be fairly easy.

Basic floating point support would not speed up any of the above
functions. Neither do the above functions do basic floating point
support. These issues are fairly unrelated.

Cheers,
   - Andreas

On 28-Mar-06, at 11:17 AM, tim Rowledge wrote:

> Mpeg3Plugin
> Use of file name checking call bothers me. John, why is there a  
> rather pointless indirection of sqFilenameFromStringOpen through  
> ioFilenamefromStringofLengthresolveAliases ? Is the resolve  
> alisases nonsense even needed now you've changed to OSX support  
> only and using unix style filenames?

The resolve aliases nonsense is still needed because you still can  
make hfs+ alias files in os-x, so then the question is at any point
are you opening the alias or opening the file the alias points to?

I'll fix the pointless pointless indirection of  
sqFilenameFromStringOpen through  
ioFilenamefromStringofLengthresolveAliases

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: SDR: Shift Disk Right
>
>

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===