[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Using version control locally with the GST source tree

From: Paul D. Fernhout
Subject: [Help-smalltalk] Using version control locally with the GST source tree
Date: Tue, 05 Dec 2006 20:25:31 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1

I justed want to mention in detail this neat idea related to using GST under local version control.

I had put the latest version of GST into a local Subversion (SVN) repository, which I am accessing under Eclipse using the Subclipse plugin. I did this mainly because I intended to make some local changes to experiment with it, however, I am already finding this to be very useful for other reasons, which I would like to share. What I have to say would probably apply to almost any version control system.

After doing a configure and make from the baseline 2.3 GST release, I could use SVN to easily tell me what had changed or added from the make (a lot!). It was interesting to be able to easily study in detail what the GST system (in the sense of being a big tree of files as an extended application) had done to itself after the make command. Then I could check in the results there to establish a new baseline. So I did that.

Unexpectedly, this new baseline checkin came in handy a few minutes later.

Next, I did a
  gst -qK blox/
which gave me a funny result (an error message, but don't worry, Paolo, as you will see, it was an issue on my end).

Then I did a

 gst -qK -a Browser Blox Compiler

from the manual (which is supposed to write out an image file):

And SVN told me nothing had changed. So, SVN here was indirectly telling me something went wrong. Nice! Obviously, I could have looked at file dates and such, but I would have had to be sure what the files name was supposed to be and where it was supposed to be written in any of lots of subdirectories.

It took a while before I looked more carefully at the results of that command and saw a permission error writing to a file, and then I saw the process was referencing files in "/usr/local/share/smalltalk", and then I realized already had an older GST installed as a Debian package. The plain gst command should not have worked at all, of course. Only "./gst" should have worked. Silly me to not notice.

So I uninstalled the package with apt-get, and when testing this to get the error I should have got the first time, I found surprisingly that gst was *still* in "/usr/local/bin/gst". Not sure why, so I removed it manually. Then I got the appropriate error of gst not found. I've tried gst on and off for years, so might have been some configuration issue left over from way back.

So now I run
  ./gst -qK -a Browser Blox Compiler
from the top level directory, and then SVN now tells me the image file there has changed (and only that has changed). Yeah!

Now I can continue to explore GST (including perhaps major surgery related to a possible Java port), and I now know I can easily revert back to known states of the entire system -- even all the way back to not having done a make.

I wanted to mention this idea for a couple of reasons.

One is because it shows the power of version control even when you are just messing around with a complex system which is not your own code. You can see what the system is doing to itself -- and how it is changing in response to your commands. Finding out what changed is easy when the system is small, but once it is large, this gets hard. And when you make more than one change, this is harder still, as you are compounding changes. And this also shows, in this case, the advantage of GST being a series of files -- so you can easily use these tools like SVN on it to see how it changes over time. (Obviously, other Smalltalk have other tools for looking at changes to them, like changelogs or tools like ENVY which have their own strengths or weaknesses). I'd definitely recommend trying this if you have a local SVN repository around and you want to explore some new complex package (GST or otherwise). In one way, I am actually using SVN to give me a sort of coherent "image" like I am used to from other Smalltalks. Only in some ways this repository is more powerful -- sort of like closer to what ENVY allowed me to do in terms of looking at changes to the system in various packages, and allowing various hierarchical branches which can be saved as configurations, later loaded as entire sets of changes, or looked at side by side for differences.

Obviously if you think of yourself as a "developer" of a variant of GST, then putting all of GST under version control makes sense. But, the novel part here is the value of putting GST under version control for yourself when you only think of yourself just as a "user" or "average programmer" making an application with it. Of course, Smalltalk has always blurred that line. :-)

And perhaps this all may sound tame, since obviously it makes sense for any developer to put their *own* application under version control somehow, and once GST is working locally as expected, who cares about how GST binary files and configuration files change?

But, here is the other reasons: with Smalltalk, the spirit of the language (especially under a free license with source code) really encourages all sorts of minor changes here and there as needed. And as much as I disagree with the notion of random changes in various parts of the system from a maintainability standpoint (and so I avoid making them), I have started to wonder if a person like Dan Ingalls (in terms of Squeak's evolution) is right in their desire to change various core bits of the image as they make their applications (obviously someone like Dan is also going to have a sense of ownership of the Smalltalk image few others may never have in any case. :-) Still, I think it might make the most sense if one then confined oneself to having just one major application per customized image (or GST file tree); that might ultimately be easier to maintain rather than having lots of applications per common image which an entire community was messing with, which has been a big set of headaches for the Squeak community leading to "bit rot" as applications that used to work stop working. Now that disk space is so cheap, and the memory for a good VM is not that large (and some later VMs even share memory better across VM instances), then with good version control tools, why not have an entire customized Smalltalk system embedded along with each major application (web browser, simulation, email client, graphics tool, and so on)? I know, issues come up with the base system you would like to fix everywhere at once -- but in general, I would expect that the kind of changes most people would make to their base classes (adding test methods, or convenience methods, and such) would rarely collide with the kind of changes needed for portability or performance improvements, and so would be easy to merge.

I think the merging headaches related to GST upgrades might be less than those of trying to get a large and diverse community to agree on a standard set of base classes over time. At the very least, you'd know any working application would still be working wherever it used to until you tried to merge in new code specifically into that application's image or file tree. You could always be free to use newer GST versions with newer projects or just upgrade any of your projects that were easy to upgrade. And then testing could perhaps be managed more modularly too (on a "per major application upgrade" basis versus a "per major image change" basis, which often seems to lead to surprising failures among previously working applications). Also, free of the fear of changes causing failures in existing major applications built on that platform, mainline Smalltalk platform developers then might feel free to innovate more and make more radical changes with the core system (should that make sense). Of course to make all that work smoothly, one needs to have Smalltalk applications that can easily talk to each other through sockets, files, shared memory, serialized objects, or other means (and supporting other standards) than sharing references to live objects in a common VM memory pool. Yes, this is another set of standards and compatibility to worry about, but those communication standards seem to change more slowly and in more controlled ways than Smalltalk images, and using them is a common part of the Unix-derived experience. :-)

This approach is kind of like a variant on Paul Graham's idea of "bottom-up" Lisp programming. He writes:
"Experienced Lisp programmers divide up their programs differently. As well as top-down design, they follow a principle which could be called bottom-up design-- changing the language to suit the problem. In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. As you're writing a program you may think "I wish Lisp had such-and-such an operator." So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. Language and program evolve together. Like the border between two warring states, the boundary between language and program is drawn and redrawn, until eventually it comes to rest along the mountains and rivers, the natural frontiers of your problem. In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient."

So, a private copy of GST in SVN makes this meet-in-the-middle combination of top-down combined with bottom-up programming more feasible to think about and maintain in Smalltalk. SVN helps you see how you changed something from a baseline, and can also help you reintegrate "vendor branches"
like new versions of GST back into a customized line of development.
So, it makes more feasible the idea of developing one application per customized version of GST (especially if you add in a notion like a variant for Java and the JVM that might make it possible to build one "jar" file that could run on all supported platforms, and hopefully be forward compatible with improved JVM versions and libraries. :-).

Anyway, to sum up, I think I just bumbled into a "powerful idea" somehow, of using version control on a new complex application like GST 2.3 just to monitor what it does. :-) Probably obvious to people here, but new and surprising to me. And there is something even more powerful -- "meet-in-the-middle" programming :-) -- that GST's unusual file-based architecture (for a Smalltalk) makes even more possible using conventional version control tools (SVN or whatever, I have not tried GNU Arch yet but I assume it can do the same thing?), and thus could open up a new style of programming for the free Smalltalk community, or, rather, perhaps make an old style of Smalltalk programming more feasible on a networked community basis. Now the GST community may already have other ideas for doing this, so if there is some other common way of doing this with GST, I'd love to hear it.

--Paul Fernhout

reply via email to

[Prev in Thread] Current Thread [Next in Thread]