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@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@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@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@gmail.com | > | To: "Janko Mivšek" janko.mivsek@eranova.si | > | Cc: "VWNC" vwnc@cs.uiuc.edu, "Squeak" | > | squeak-dev@lists.squeakfoundation.org, | > | Pharo-project@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@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. | > | | > | | > | |