[SF]VM building project third report

Ian Piumarta ian.piumarta at inria.fr
Mon Jun 10 07:06:16 UTC 2002


On Sun, 9 Jun 2002, Tim Rowledge wrote:
> As the duly nominated muggins for the VM project my view is that the      
> green light is on.  If, as appears, you have put together a suitable 
> chunk of stuff (note the sophisticated use of professional terminology 

It's the very same chunk of stuff I've been writing for the last seven
years.  The only difference today is that the build process is
VMM-compatible and the C code contains various fixes inspired by the
patches that were applied to the SF code (and vast chunks of new stuff
that were never on SF).

The question is not whether it is "suitable" for the "VM project" (by
which I assume you mean VMMaker) since it quite clearly functions
perfectly well in that context.  And since the totality of the Unix code
is rooted at (and contained entirely within) my platforms/unix tree it
doesn't affect anything in your platforms/RiscOS tree (nor anything in the
platforms/Cross tree on which your RiscOS code might depend) nor any of
the other platdep trees.

The question is rather whether those people who were hacking on my old
Unix code at SF actually want their code replaced (and this would be a
wholesale replacement) with my new code.  This is my one, unique concern
(and has absolutely nothing to do with what any "VM project" might think
of it).

And just so you know: the new build process hasn't been properly tested on
BSD, Linux/sparc, Linux/alpha, Digital OSF/1, Irix, SunOS 4, HP/UX, etc.
In the meantime I cannot make any recommendations whatsoever about the
code (except that you probably shouldn't use it, under any circumstances,
and maybe not even let the thought of prodding it with a ten-foot barge
pole begin to speculate about the merest possibility of crossing your
mind).

> PS It was _I_ that wrote the original ugly hack unix version of 
> FileCopyPlugin and I used 'system()' because it was trivial and adequate 
> to my needs.

I wrote a whole new one that uses unbuffered read/write on multiples of
the filesystem's (which usually means the disk's physical) block size
(and/or mmap, depending on what the platform is capable of).  And yes,
like the comment in the old code used to say, it does preserve
permissions.

> Assuming you've decided to make unix use the non-copy 
> variety of VMMaker you don't even need it, so get rid of it and feel 
> cleaner.

And no, my build process doesn't copy anything (doing so would be utterly
pointless).  The src and platforms/Cross trees are used in-situ without
duplicating any of their contents elsewhere.

> PPS I think I noticed that AsynchFilePlugin is effectively null in the 
> latest code, so I'd suggest completely removing it.

I prefer to leave the stubs (as with DropPlugin) as a reminder to anybody
who might one day consider it worth implementing (and also as a concrete
[and prototypically verified] record of the functions they'd have to
implement).  Anyone who doesn't want the stubs in their VM has only to
disable the plugin in VMM.

> PPPS Greek goddesses?

The monastery on Patmos was about my closest encounter with divinity.

A+

Ian









More information about the Squeak-dev mailing list