Colin,
I agree that code management is one of the problems that is trying to be addressed by the modules effort(s).
So again, I don't think I understand your concern. Are you saying that you prefer the SM/DVS route to 3.3 modules?
Well, I guess that is more or less what I'm saying.
How do you define "modular" and "monolithic?"
I save an image, and when I restart a Squeak VM, it comes back with *everything* exactly the way I left it. I call that "monolithic".
Your point that keeping multiple Squeak images around is a "Good Thing" is significant (IMO). Squeak is a "virtual machine" and running multiple virtual machines on one "real" machine with different images in each is a perfectly reasonable thing to do.
I start up a Sqeak VM and it goes hunting all over my disk (and possibly the network) looking for bits and pieces that it thinks it's supposed to have to build an image before I can do anything useful. That would be one kind of "modular", and I wouldn't like it.
-Dean
-----Original Message----- From: Colin Putney [mailto:cputney@whistler.com] Sent: Thursday, October 31, 2002 4:09 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: An uncomfortable question
On Wednesday, October 30, 2002, at 05:33 PM, Swan, Dean wrote:
Colin,
Consider the case where there are dependencies between the modules and more than one version of each module. The current effort of implementing modules is attempting to deal with these issues, and it is a non-trivial problem. It is also possible that because of certain interdependencies between different versions of different modules that some modules may become mutually incompatible. This situation is witnessed with MS Windows .DLL libraries quite often.
One common effect is that some applications have to be installed on a Windows machine in a particular order in order for them to all function properly on the same machine. There can arise instances where because of different sets of .DLL versions required, a set of applications may not all function correctly on one machine.
Well sure, incompatibilities between different parts of the system is always a danger. Certain parts of the system expect particular behaviour from other parts of the system. If you make changes you run the risk of violating those expectations. This is true whether those parts are modules, classes, functions or DLLs.
The nice thing about Squeak is that you can have multiple images lying around. So if you need different versions of a module in different situations, you do that without having to say, swap out your hard drive when switching between applications.
Now, this is not to say that dependency tracking, versioning and so on is a non-issue. It is a problem that we're going to have to address. But the ability to build images for specific purposes is a mitigating factor. So when we do have incompatibilities between modules - and it will happen - instead of "hell" we're faced with a mere problem.
And regarding SqueakMap and DVS, realize that these are based on the monolithic image model. They are more or less fancy user interfaces to manage filing in the various change sets (I know I'm oversimplifying a bit, but the point is still valid).
Hmm. It sounds like we have different definitions of "monolithic." When I speak of modularizing the image I mean grouping the code into clusters of classes and methods that a) provide a distinct and coherent piece of functionality, and b) interact with other clusters through well defined interfaces. Once that's accomplished (and yes, it's a non-trivial task) many of the clusters can be removed from the base image and maintained separately.
I place that scenario opposite the "monolithic" system used by Squeak 3.2. Everything is really intertwined and you can't easily remove any functionality from the image. Adding functionality is easier, but still quite a hassle because of the some what artificial distinction between "blessed" code that's maintained by SqC and other stuff, which is floating around in ChangeSets.
So again, I don't think I understand your concern. Are you saying that you prefer the SM/DVS route to 3.3 modules? How do you define "modular" and "monolithic?"
As to SqueakMap and DVS, sure. They really are just tools to make it easier to move code in and out of images. But that's the point! The whole problem here is that it's difficult to manage code.
Of course, monolithic systems have the issue of shared namespaces which can make it difficult to make different packages play nice together in the same image, so like I said, the problem is > non-trivial.
While it would certainly be possible to produce an MPEG player image, with only the items necessary to play MPEGs, and a MIDI image with only the items needed for MIDI processing, and so on, factoring out the common components can be difficult. This is especially true when some "applications" use different versions of a particular component and rely on some characteristic behavior. A hardware example of this is the 4046 phase locked loop IC. It is a fairly standard part, BUT the Motorola Version and the Philips versions are incompatible in that the external timing components require different values to get the same frequency out of the two parts. The same kind of thing can happen in software.
No, it's not trivial, but it can be solved, and it's not even all that difficult.
For one thing, the package model used by DVS makes the problem easier by virtue of its inflexibility. A given package can contain classes and methods. When a package is loaded, it can create classes and it can add methods to existing classes. It cannot modify methods belonging to another package, and it can't delete methods. So it avoids all kinds of problems that can arise when modules can modify each other.
A second factor that makes the problem tractable is that Squeak images offer developers much more control over the execution environment than, say, a desktop operating system. For development, you can build an image that has exactly the configuration you need - all the right packages, of the right versions, loaded in the correct order. For deployment, you just distribute that image. There's no need to have users load your package into whatever randomly configured system they happen to be running. That's the situation that creates DLL hell and it just doesn't apply to Squeak.
And finally, if you do run into a compatibility problem, just fix it! The source code is there, there's a community of people willing to help, and with SqueakMap and DVS, you've got the tools to easily distribute your fix to the rest of the community and to easily benefit from their efforts. As Daniel mentioned, we've got a social advantage over the commercial world.
Cheers,
Colin
Swan, Dean wrote:
Colin,
I agree that code management is one of the problems that is trying to be addressed by the modules effort(s).
So again, I don't think I understand your concern. Are you saying that you prefer the SM/DVS route to 3.3 modules?
Well, I guess that is more or less what I'm saying.
How do you define "modular" and "monolithic?"
I save an image, and when I restart a Squeak VM, it comes back with *everything* exactly the way I left it. I call that "monolithic".
Your point that keeping multiple Squeak images around is a "Good Thing" is significant (IMO). Squeak is a "virtual machine" and running multiple virtual machines on one "real" machine with different images in each is a perfectly reasonable thing to do.
I start up a Sqeak VM and it goes hunting all over my disk (and possibly the network) looking for bits and pieces that it thinks it's supposed to have to build an image before I can do anything useful. That would be one kind of "modular", and I wouldn't like it.
I don't think that's what's being said though. Colin (and others) is saying that you need to be able to easily add and remove pieces from your image. We're not talking about running the pieces from outside the image, having to go looking for them on the Net or whatever. The desire is to have a way to easily control what is in your image so when you save, everything is not only the way you left it, but the way you *want* it.
Julian
squeak-dev@lists.squeakfoundation.org