Chris,

Agreed ... the only required link to SCM is during the code loading ... 

As I have suspected, this operation is being done by individual development groups (because they consider it a requirement), but as a community we don't provide out-of-the-box support and we should ...

Dale

----- Original Message -----
| From: "Chris Muller" <asqueaker at gmail.com>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Sent: Sunday, January 29, 2012 1:14:06 PM
| Subject: Re: [squeak-dev] Smalltalk for small projects only?
| 
| I agree with Dale that being able to automate building of images is
| essential for large projects -- because it provides a necessary
| starting point of coordination among the large group that, itself, is
| capable of advancing forward (thus advancing the entire group with
| it).
| 
| Whether this function should be part of the SCM toolset -- I'm not
| sure..
| 
| We've gotten by for at least the last 4 years using a very simple
| procedure for building our images.  We use SVN to keep version
| history
| of three .st scripts:
| 
|   vanilla.st
|   app.st
|   deluxe.st
| 
| What we do is use a make script to launch the stock Squeak 4.3 image
| with vanilla.st script as input.  It's just an Installer script that
| loads latest versions of our base frameworks we need:  Seaside,
| Magma,
| etc. and saves as vanilla.image.
| 
| Next, the make script launches the just-saved vanilla.image with
| app.st as input.  That script loads our proprietary application code
| and saves as app.image.
| 
| app.image is then launched with deluxe.st as input.  This one adds
| developer tools, etc.
| 
| The only time we need to update any of the .st scripts is when we
| make
| a new package -- a rare occurrence anymore.
| 
| So, with SVN and make, we have "one button" ability to produce 3
| tiers
| of images.
| 
| An all-Smalltalk tool to do the same -- one that did not require make
| and SVN, would be nice.
| 
|   - Chris
| 
| 
| On Sat, Jan 28, 2012 at 7:30 PM, Dale Henrichs <dhenrich at vmware.com>
| wrote:
| > Martin,
| >
| > Very good points ... So here's a little riff on:
| >
| >  "Always start from a fresh one and load the code back in"
| >
| > Just imagine if the standard Smalltalk development experience
| > started with a micro-image (a compiler and not much else) and then
| > went through the following steps:
| >
| >  1. decide which base image (thing choosing between Squeak 4.3
| >     and Pharo 1.3) to use for development
| >  2. run image build script starting with the micro-image that
| >     produces a deployment image and a development image
| >  3. fire up development image and write code using all of the
| >     nifty in-image development tools
| >  4. committing your work involves saving your code and updating
| >     the build script
| >  5. either continue development at step 3 or go back to step 2.
| >     If the project is successful, there may be demand to actually
| >     run on multiple platforms (Squeak 4.3 and Pharo 1.3 or Squeak
| >     4.3 and Squeak 4.4), but then it should be as easy to build two
| >     sets of images as it is to build 1
| >
| > If this were the standard development process for Smalltalk, I
| > think that the SCM tools would be much better overall (the more
| > engineers experiencing pain, the more chance that someone will
| > decide to fix problems) and I think (as you imply) that Smalltalk
| > would be easier for newbies to pick up on their own, since there
| > is a familiar process and the illusion that programs are being
| > created ... and oh yeah that 200 developer team would have the
| > opportunity to fail miserably while using Smalltalk ...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: mkobetic at gmail.com
| > | To: "Janko Mivšek" <janko.mivsek at eranova.si>
| > | Cc: "VWNC" <vwnc at cs.uiuc.edu>, "Squeak"
| > | <squeak-dev at lists.squeakfoundation.org>,
| > | Pharo-project at lists.gforge.inria.fr
| > | Sent: Saturday, January 28, 2012 4:38:27 PM
| > | Subject: Re: [squeak-dev] Smalltalk for small projects only?
| > |
| > | "Janko Mivšek"<janko.mivsek at eranova.si> wrote:
| > | > Ralph Johnson in his InfoQ interview made an interesting
| > | > observation:
| > | >
| > | > 2:55 minute: "Smalltalk made an fundamental error ... image ...
| > | > you
| > | > can
| > | > build something with 4-5 people what 50 people can build in
| > | > Java,
| > | > but if
| > | > you take 200 people in Java ... it is really designed for small
| > | > systems
| > | > ...  "
| > | >
| > | > Are we because of the image really destined for relatively
| > | > small
| > | > projects and small systems (of Java 50 people project size)?
| > |
| > | The "image" argument is one of the easiest to pick when you want
| > | to
| > | justify your xenophobic reaction to an unfamiliar environment
| > | you're
| > | about to enter ("... but they are green and have antennas...",
| > | never
| > | mind that the antennas may actually be useful for something). But
| > | there's nothing fundamental about Smalltalk that requires an
| > | image,
| > | c.f. there are a few Smalltalks that don't make you use one (e.g.
| > | Smalltalk/X). It's just frozen state, many IDEs and editors allow
| > | you to freeze their state (e.g. Eclipse workspace), it would be a
| > | royal pain having to reopen the files you were working on
| > | manually
| > | every time, wouldn't it.
| > |
| > | I think the problem is that most newbies, when being introduced
| > | to
| > | Smalltalk, are immediately confronted with "the image" as if it
| > | was
| > | something fundamental, like they couldn't get any further until
| > | they
| > | grok it. But there's nothing preventing you from never saving the
| > | image. Just commit your source code (and it could just as easily
| > | be
| > | a common file based VC in the back there) and quit the image.
| > | Always
| > | start from a fresh one and load the code back in. In this mode
| > | there's (superficially*) no difference between Smalltalk and any
| > | other IDE, you write your code, you run it, debug it, commit it,
| > | etc. You can completely forget the image if you want, it's just
| > | that
| > | most seasoned smalltalkers (the ones doing the introduction) have
| > | learned to take advantage of the image and using it in all kinds
| > | of
| > | creative ways, so they want to pass the knowledge along and
| > | manage
| > | to freak the newbies out in the process.
| > |
| > | (*) the real difference between Smalltalk and other IDEs, that
| > | may or
| > | may not be an issue in any particular case, is that the IDE runs
| > | in
| > | the same memory space using the same code base as the
| > | application,
| > | so your development can crash the IDE, while other IDEs prefer to
| > | crash on their own :-).
| > |
| > | But I disagree that the image is some sort of technical obstacle
| > | to
| > | scalability, I think it's completely orthogonal. The only place
| > | where it's hard to ignore the image with the image based
| > | Smallltalks
| > | is deployment. At this stage the image is the "compiled object
| > | code", in the same sense that a shared library is "compiled
| > | object
| > | code". You can (and some do) deploy as a clean base image, load
| > | the
| > | application code on start and launch the application. That's no
| > | different from a java or python app, their base image is just
| > | burned
| > | into the VM. But it's so much easier to make that snapshot when
| > | all
| > | of this is finally loaded in memory and ready to run. It loads
| > | faster, there are no scattered files to hunt down in the dark
| > | corners of the filesystem, makes perfect sense in many (most?)
| > | cases. If people are freaked out that they don't need to mess
| > | with
| > | CLASS_PATH, or PYTHONPATH or what have you, well, it would be
| > | quite
| > | easy to "fix that", wouldn't it.
| > |
| > | You could say that every piece of software "has an image". When
| > | it is
| > | loaded it initializes its runtime structures, lays them out in
| > | memory and starts running. Nothing fundamentally different from
| > | the
| > | base image case, the "image" is just burned into the executable.
| > | If
| > | the VM was simply embedded in every saved smalltalk image and the
| > | resulting file was turned into an executable, you can't really
| > | tell
| > | the difference. The image just wouldn't be portable anymore.
| > |
| > | So I could agree that the image can be an obstacle to adoption if
| > | you
| > | rub it in people's face, but it can just as easily be mostly
| > | ignored. It's not significant unless you make it so in your
| > | development process.
| > |
| > |
| >
| 
|