Tim --

I think your "intriguing possibility" is a better way to go overall. I think tiny runtime resources are great, but I don't see why one shouldn't always be able to invoke any or all of the full power of the system when wanted or needed. (Having said this a few times over the years, it's still quite interesting how much hold the old "program time" vs. "runtime" distinction has today, even with strong examples of their union, as with LISP and Smalltalk.)

Cheers,

Alan

------

At 12:18 PM -0700 6/30/00, Tim Rowledge wrote:

In message 8525690E.0067B178.00@intlnamsmtp20.us.pw.com you wrote:

...

Thanks for your reply. However, I believe that my point #2 and #3 still refer to different aspects of tailoring the Squeak environment.

Believe me John, I understand the problems all too well having suffered the need for many years!

...

The requirement here is to strip out all classes and methods that are not specifically called by the program (same functionality as C++ compilers). This process includes stripping out the all of the development tools. The stripping process may remove only parts of modular plugins or categories as well as entire subsystems. The goal is to create a "runtime" image for the user.

Although stripping can be done quite thoroughly if you use a whittling down process (like we used to use in VW when I was still at PPS; you remove unused stuff, loop back and remove stuff left orphan by that removal, repeat until bored) and care, it's a hard path. Since we don't (thank goodness) have types, you don't get to check them. Lex shewed a pretty impressive inferencer at last years OOPSLA that would help a great deal in trying to do a whittle, but you'll still be left with uncertainties.

Building up from a base and modules _could_ (if done sufficuently well) mean not having to worry about this. To produce your deployment 'image' you simply leave out all the stuff you think is not needed. The smaller and more focussed each module is, the more certain you will be about whether you need it or not.

Another intriuging possibility that would be great in some cases and useless in others would be to have an on-demand repository of all the class & method (come to that, any object might be useful) so that a running image could load just what it needed, when needed. We have finally got a basic run at this into the VM codebase. Demand loading would probably be great for net connected machines and suchlike, but I can also see possibilities for small machines where we would have the repository in ROM and thereby keep the RAM demand down to what is really needed.

-- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Why Dogs Hate WIn95:-17) Too difficult to "mark" every website they visit.

Tim Rowledge wrote:

In message 8525690E.0067B178.00@intlnamsmtp20.us.pw.com you wrote:

...

Thanks for your reply. However, I believe that my point #2 and #3 still refer to different aspects of tailoring the Squeak environment.

Believe me John, I understand the problems all too well having suffered the need for many years!

The primary reason I object to Stripping as opposed to Construction is that you give up all testing you may have done- no matter how much you trust the stripper, the result is NOT the code you tested, and if you are going to wait until after stripping to test then you are giving up lots of component level testing that could have been done. If you are not going to test at all, then stripping is fine. But if you want to be able to establish some level of certainty about the fitness of your system, you have to test, and you have to test the system that you are going to deploy, not the one that you have prior to "packaging" that has all the development tools in it.

So, it's not that I think you shouldn't be stripping things out- indeed, that would be a part of the modularization effort in many cases. What is important is that the resulting stripped component is NOT the component that might have been tested before stripping, and must be re-tested in order to re-establish its fitness for use. Again, if you have no interest in testing your software prior to distribution it's not much of an issue. ( for the record, the stuff I've made available is definitely User Beware- but I've never claimed otherwise. But at some point wouldn't it be nice to have an IMAP client that I could certify to you as having met whatever standards are applicable, and to what extent, as opposed to "I have an IMAP client. It works in my image. Good Luck" ).

Also, I believe you will discover that compilers in other languages such as C++ do not actually remove code in the way you might be thinking- a library linked into your code is linked in its entirety, not just bits of it. This is done for exactly the reasons I point out above. ( Admittedly, I'm going out on a limb with this statement as I haven't used anything other than Smalltalk for about 6 years, but I'm pretty certain this is true ).

I don't see this as a competition between the "Program-Time" and "Run-Time" mindsets, though. I see it more as an issue of whether a delivered system is supposed to be granting the full power of a programming environment to what most developers would consider end-users. There's nothing wrong with doing that in contexts where it makes good sound sense for the end-users to have that kind of power, however much of it you wish to make available. But there are cases where a system should not have that kind of power, and in those cases it would be nice to have the means to control very explicitly, without guesswork, and to a very fine degree, exactly which bits of power the end-users get. Either you have that, or you are telling potential developers that they should not use Squeak because it is more important to the Squeak community that everyone who gets anything built using Squeak have as much power as the organization which built the delivered app, so much so that we are giving that organization's customers the power to open up the application and change it to suit their own personal whims. Again, in some contexts there's nothing wrong with that at all, and even highly desireable. But not in all of them. We can support both.

That being said, let it be clear that the thing which lured me into the Smalltalk world was precisely the notion that the users would be the gods of their own software world. Not a bad vision, and one that I happen to agree with in many ways. Especially when I get e-mail viruses from reading the mail using certain "closed" products. And I can't tell you how many times I've tried to initiate a walkback on some non-Smalltalk commercial application to find out what on Earth it was doing that was taking so long, so that I could go in and fix the damned thing.

But on the other hand, that power is undermined when the user cannot tell what state their world is actually in without having to expend unpredictable and quite possibly enormous amounts of personal effort to make that assessment. The existing tools within most Smalltalks just don't cut it once we get beyond a few hundred classes in a few dozen categories. By the time you reach a few thousand classes, the situation is not good at all. More is needed in order to have the same level of control as one might have had back when the image only had 100 classes. That will be a challenging goal, but one that will have to be hit head-on if we are to truly have all of these distributed repositories lying around the globe ( does anybody remember my mentioning this years ago? I thought not).

- les