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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
On May 27, 2008, at 11:33 AM, tim Rowledge wrote:
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?
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 johnmci@smalltalkconsulting.com 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?
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?
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:
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?
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?
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 -
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:
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.
But necessary to keep existing code running.
Cheers, - Andreas
At 1:27 PM -0700 5/27/08, Andreas Raab apparently wrote:
Ken G. Brown wrote:
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.
But necessary to keep existing code running.
Cheers,
- Andreas
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:
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
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
On 27-May-08, at 12:54 PM, Bert Freudenberg wrote:
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?
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.
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?
Bury it I'd say. Who was using it anyway?
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
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; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as the Vice Squad took his GIFS ..
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
John M McIntosh -
Ken G. Brown -
tim Rowledge