Hans-Martin,

 (mostly because I can't be bothered with finding out how to set up
repeating jobs on Windows)

Try running "taskschd" from the command line.
also:
http://technet.microsoft.com/en-us/library/cc721931.aspx

Cheers,
Darius
______________

On Sun, Jan 29, 2012 at 10:18 AM, Hans-Martin Mosner <hmm at heeg.de> wrote:

> Am 29.01.2012 02:46, schrieb James Robertson:
> > We start from visual.im
> >
> > -- load Store tools
> > -- load application code
> > -- save development image
> > -- build runtime image, save it
> > -- compress the runtime (using VW tools)
> > -- run tests, report on results
> > -- copy all final files (dev image, runtimes, and reports) to a share
> drive location
> > -- send email to specified recipient as to build results
> >
> >
> In the VA Smalltalk project that I've been working in for more than 10
> years, we've been doing something similar for
> quite a long time (not from the beginning, but at least 5-6 years).
> There's one builder image (which is created by
> loading just one app into a virgin VAST image) which is started from a
> batch file passing the relevant parameters which
> specify what config maps should be loaded, what if any tests should be run
> and whether a runtime image should be built.
> This image is being used by a number of small batch files for unit tests
> and runtime image construction. It's not
> automated yet (mostly because I can't be bothered with finding out how to
> set up repeating jobs on Windows), but running
> it is just a matter of double-clicking on a batch file, so it's not a big
> deal.
> Of course, with ENVY you get very powerful version control, so this
> project could successfully be built by about 20
> developers, at that time targeting OS/2 and VAST 6.0, and has been pushed
> through several VAST versions, survived a
> target platform change to Windows, has been extended to include
> functionality previously supplied by an additional
> software system which was unavailable for reasons I won't go into here.
> Although this is not a "huge" project it shows that projects with a
> significant number of developers can be developed
> robustly in Smalltalk.
> The image is definitely not a problem for us - during development, it's
> very handy to always have everything available
> in the morning just as you left it when going home, and for deployment
> it's just another way of packaging the
> application. Much easier than, say, Java apps which consist of oodles of
> .jar files and xml configurations and whatever.
>
> I have always been under the impression that the obstacles to using
> Smalltalk in many organization are a combination of
> badmouthing, misinformation, histories of bad licensing policies and
> perceived vendor instabilities. The PPS/Digitalk
> merger, although it is clearly history, did its thing, as well as the
> Instantiations phoenix-from-the-ashes stunt.
>
> What can one do about it? Seriously, I don't have an answer. We're mostly
> technical guys, and those normally don't have
> a say in the decisions about project tools. I'd be interested in seeing
> analyses of large Smalltalk projects and the
> reason they either succeeded or floundered. What were the actual reasons
> for DabbleDB to go under, why couldn't
> Teleplace make enough money to survive, ...? Was it the technology, or was
> it that companies initiated by mostly
> technical people have a hard time surviving when facing economical
> upheaval?
>
> Cheers,
> Hans-Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120129/551e7665/attachment.htm