VMMaker updating: Mantis 6828 and the future of copying files

 
OK, two issues here, one shortterm, one longer term.

a) in mantis 6828 Dave Lewis proposes some changes to fix some  
64bitness issues. They look good to me and he added tests. However I'm  
not responsible for unix vms and I'm not about to commit those  
changes.  Somebody else will have to handle that and close the mantis  
report etc.

b) I'm reasonably sure that all the platforms we are interested in now  
support file links of some sort. File copying (and the vile  
FileCopyPlugin may it be cursed to the bottom of the pits of Vista)  
was only ever used because we had no linking available. Eliot will  
cheerfully (I'm sure) rabbit on for hours about how we used to handle  
things in the brouhaha source tree, where sets of files for particular  
platforms were assembled by links from the assorted subsystems, thus  
making it easy to make. Or even nmake.
It would be really nice to agree a path towards a brighter future  
where VMMaker doesn't have to copy files and worry about damned  
permissions/attributes/flavours/whatever. Thoughts please?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DCBP: Detonate Chair on Bad Password

 

On May 27, 2008, at 11:33 AM, tim Rowledge wrote:


Er, so where do you copy files? At least in the OS-X build and I  
believe the unix build we just point gcc etc to the platform SVN tree,  
and to the generated src tree, or am I missing something?

Noting that Apple only offered up a file copy api in 10.4 when they  
offered up ACL meta-data on files/directories and made primitive  
generic unix file copying quite impossible...

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

 
On 27.05.2008, at 20:33, tim Rowledge wrote:

> OK, two issues here, one shortterm, one longer term.
>
> a) in mantis 6828 Dave Lewis proposes some changes to fix some  
> 64bitness issues. They look good to me and he added tests. However  
> I'm not responsible for unix vms and I'm not about to commit those  
> changes.  Somebody else will have to handle that and close the  
> mantis report etc.

Ian added Dave's VMMaker patches already, so I assume he'd merge these  
things, too. OTOH if we were to drop the FileCopyPlugin, we would not  
need to update it, right?


Bury it I'd say. Who was using it anyway?

Btw, I think it would be nice to revive

        http://www.squeaksource.com/VMMaker.html

Also, some idea about how to handle plugins development-wise would be  
nice. The unix VM now ships several non-default plugins (DBus,  
GStreamer, Rome, maybe more) that one has to download from different  
repositories. Maybe the source for those should be added to the  
VMMaker repo? Or added to SVN? Maybe even a whole VMMaker image?

- Bert -

 
At 9:54 PM +0200 5/27/08, Bert Freudenberg apparently wrote:
I agree, it would be nice to have one place where the source for all the plugins lives. Failing that, at least a index there that shows where they all can be found.

And if working on all this VMMaker stuff, how about making the naming of the plugins consistent?

I have found at least:

internal plugin B3DEnginePlugin generated as Squeak3D
internal plugin BalloonEnginePlugin generated as B2DPlugin
internal plugin BitBltSimulation generated as BitBltPlugin
internal plugin DSAPlugin generated as DSAPrims
internal plugin DeflatePlugin generated as ZipPlugin
internal plugin FFIPlugin generated as SqueakFFIPrims
internal plugin KlattSynthesizerPlugin generated as Klatt
internal plugin LargeIntegersPlugin generated as LargeIntegers

Very confusing.

Ken G. Brown

 
Ken G. Brown wrote:
But necessary to keep existing code running.

Cheers,
   - Andreas

 

On 27-May-08, at 12:54 PM, Bert Freudenberg wrote:

Correct but I don't see us getting all the work to add links etc done  
any time soon and so the old plugin needs to work.

It's been a while since I thought about this stuff. IIRC the copying  
was originally intended to allow the assembly of a customised  
directory so that the automake stuff could then create the right VM  
based on the list of plugins etc that were in the directory. It might  
have been possible to write out a config file for automake as an  
alternative but then you'd have to do something similar for nmake  
(what was in use for windows at the time) and CodeWorrier (what was in  
use for Macs) and so on. Things are quite a lot different these days  
and maybe we should try to take advantage of any improvements over the  
last 10 years.

Part of the complication was that people wanted to be able to make  
custom combinations of internal and external plugins. I doubt that has  
been used all that much. Personally I think that all plugins should be  
external and that the platform should have a sensible way of coping  
with that.

>
> Btw, I think it would be nice to revive
>
> http://www.squeaksource.com/VMMaker.html

Yes, it would.

> Also, some idea about how to handle plugins development-wise would  
> be nice. The unix VM now ships several non-default plugins (DBus,  
> GStreamer, Rome, maybe more) that one has to download from different  
> repositories. Maybe the source for those should be added to the  
> VMMaker repo? Or added to SVN? Maybe even a whole VMMaker image?


I don't know how we should handle plugins that need code from other  
projects. Suggestions welcome.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh, as the Vice Squad took his GIFS ..

 
At 1:27 PM -0700 5/27/08, Andreas Raab apparently wrote:
I'm talking about moving forward with continuous incremental improvement when there is a chance to easily do so.
Those that need to stay in the past can easily do so and avoid using the new stuff, otherwise do the simple change to use the new.

I feel that if you always make compromises in the direction of backward compatibility, the quality of the way forward is also compromised.

Kinda like entering a race and intentionally trying for only second place.

Ken G. Brown

 
Ken G. Brown wrote:
> I'm talking about moving forward with continuous incremental improvement when there is a chance to easily do so.

The emphasis being on "easily". It's not. It requires all the images
that want to use the VMs to update their code base to use the
corresponding names.

> Kinda like entering a race and intentionally trying for only second place.

More like avoiding the race completely since there is absolutely nothing
to be won in it.

Cheers,
   - Andreas

 
At 2:47 PM -0700 5/27/08, Andreas Raab apparently wrote:
Well, then say that the newly generated VM's from the new improved VMMaker work with new improved images. And if you want the older images to work, make a couple of minor changes. All in the name of incremental improvement thereby reducing confusion for the way forward.

Ken G. Brown