Using version control locally with the GST source tree

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/Run.st
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 Load.st -a Browser Blox Compiler

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

   http://www.gnu.org/software/smalltalk/gst-manual/gst_17.html#SEC23

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 Load.st -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:
   http://www.paulgraham.com/progbot.html
"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"
   http://svnbook.red-bean.com/en/1.1/ch07s05.html
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


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Good idea:  I've borrowed it for myself.

Regards,

----- Original Message ----
From: Paul D. Fernhout <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 5, 2006 5:25:31 PM
Subject: [Help-smalltalk] Using version control locally with the GST source tree

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/Run.st
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 Load.st -a Browser Blox Compiler

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

   http://www.gnu.org/software/smalltalk/gst-manual/gst_17.html#SEC23

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 Load.st -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:
   http://www.paulgraham.com/progbot.html
"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"
   http://svnbook.red-bean.com/en/1.1/ch07s05.html
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


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk





 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

CONTENTS DELETED

Krishna-

Thanks for the suggestion; I just tried darcs (under Debian) with
something smaller than GST for a first test (A Little Smalltalk, the Java
version) and it works pretty nice.
   $ cd SmallWorld
   $ darcs init
   $ darcs add -r *"
   $ darcs record -am "Initial Import."
Kind of like SVN without the need for a central server.

Made a few changes and did more "darcs record" commands. Then to make a
test safe copy (until reboot :-) I made a /tmp/test1 directory, did a
"darcs init" in it, then did a
"darcs push /tmp/test1" from the original directory.
And made some more changes and did another "darcs push" and it only sent
the new changes. Nice!

I can see how using ssh transparently would be great for minimizing
configuring a server process or your firewall to allow more ports, so you
could have a common copy on a file server somewhere). And if one uses the
SVN model of directories of tagged versions, you might still be able to
use SVN branch conventions -- though I suspect darcs copies of files
across versions (patches) are not that lightweight (unlike SVN)?
I certainly did wrestle a lot with SVN and my system to get it installed.

I haven't tried the eclipsedarcs plugin yet though, or merging, or trying
to look at all the versions of a single file, etc. In general I am curious
how easy it is to use some sort of GUI (like an Eclipse plugin?) to
"browse" a repository of Darcs changes?

Still, whether it does those things well or not, I can see darcs is (in
theory) the single easiest way I've seen so far to take something like the
entire GST build tree and be able to roll it back to a known state and
also see what an operation like a "make" changes. And then (in theory) to
manage having many copies of GST, one per application, while still
tracking a central GST maintained by a community. Something like darcs
used commonly with something like GST could then (in theory) spawn quite a
community developing Smalltalk-based applications involving building up
the base while building down the application to meet in the middle (as
Paul Graham suggests in the previously linked article). Smalltalk invites
that sort of work, and tools like darcs (or SVN) make that process more
manageable. And using a text-file based approach, like GST is based
around, certainly makes this more feasible; not that there aren't other
image-based tool to do this in Smalltalk, but here it seems like you are
getting something well supported for free, as long as its model seems good
enough. I'd be more convinced this would work well if there was some
integrated was in GST to automatically write out an image as a source code
file (or files) for rebuilding the image, like I did with the PatqaPata
project for Python/Jython. But I guess you can do it manually with class
exports?

One gotcha was that darcs did not want to import certain files which it
found uninteresting by default (like *.class files, and the I would assume
GST *.a and *.o files?), but I assume there is a way around that? Normally
I probably would not care much or want to archive these (so the default is
helpful), but in this case I was specifically exploring what GST did to
itself when make was run. I'm still wrestling with how the ANTLR plugin
for Eclipse marking the output as "derived" and then the SVN plugin does
not want to check those files in -- where the output (generated parsers)
is something I really want to store. :-)

And also, when I added a file it ignored in in when I did a "darcs
whatsnew". I had to rereun "darcs add * -r" explicitely to get it to
notice the changes. But now I know. :-) So probably still several little
thigns to learn.

Thanks again for the mention of darcs. Definitely something potentially
useful for every GST developer and with a fairly small learning curve and
a very easy install.

--Paul Fernhout

Krishna wrote:
> On 12/8/06, Brad Watson <[hidden email]> wrote:
>
>> Good idea:  I've borrowed it for myself.
>>
>
> Yes. I've been doing this with other pieces of software. But instead
> of SVN I use darcs.
>
> Cheers,


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paul D. Fernhout schrieb:
>
> One gotcha was that darcs did not want to import certain files which it
> found uninteresting by default (like *.class files, and the I would
> assume GST *.a and *.o files?), but I assume there is a way around that?

Take a look in _darcs/prefs/boring

You can also keep your default options in _darcs/prefs/defaults,
which is very handy for stuff like

record --look-for-adds
whatsnew --summary

s.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk