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