On 14 déc. 04, at 01:16, Markus Gaelli wrote:

> Hi Tom,
>
> thanks for the offer! The more, the merrier... :-)
> (You already helped me by forcing me to write down the next concrete 
> steps, but I won't let you go so easily...)
>
> Hannes is right, so my plan right now is, to make it run first and not 
> to focus too much on the most elegant solution...
>
> Tomorrow I will check if I can have a linux server here at SCG (or 
> alternatively try OSProcess on Solaris),
> as OSProcess does not seem to be ready on Mac yet. As David was 
> assuming, the important parts for this task are not working yet on 
> OS-X, at least not in Ians VM, which is the only one I tried. (The 
> stubs in the mac subclasses in OSProcess are still empty, so I went 
> for Ians VM....)
>
> If all that is failing I even would give Scheme another shot - 16 
> years I wrote my last program in Scheme, but it was fun also, and I am 
> sure Alexandre of Stef are happy  to throw some round brackets here 
> and there, if I had problems with the script from Daniel.
>
> If we have it running again, I really want to make the results 
> available via some Seaside app and at least at that moment we can have 
> good fun, to add all kinds of features,  among them some decent 
> coverage info. So there will be enough to do.
>
> Any good names for that Squeak Test Server thingie? Maybe in the 
> spirit of  BrowseUnit, we should call it ServeUnit?

cool name.


>
> Happy for any feedback,
>
> Markus
>
> On Dec 14, 2004, at 0:06, Thomas Koenig wrote:
>
>> Markus,
>> Is there some way I could help you with this effort?  I've some
>> experience with writing sunit tests.
>> If we are going to change rapidly (which we must) and reliably (which 
>> we
>> must) then we need ideas like the one you are proposing.  I don't want
>> to choose between a radically improved infrastructure and a 
>> trustworthy
>> face to the world.
>> Tom
>>
>>> -----Original Message-----
>>> From: squeak-dev-bounces at lists.squeakfoundation.org
>>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>>> Behalf Of Markus Gaelli
>>> Sent: Monday, December 13, 2004 5:28 AM
>>> To: The general-purpose Squeak developers list
>>> Cc: Daniel Vainsencher
>>> Subject: Re: [Q] A new attempt to create a Squeak Test Server
>>> +Image Fingerprints
>>>
>>>
>>> Hannes,
>>>
>>> thanks for your motivating words.
>>>
>>>> For the beginning even a relatively modest thing would be
>>> tremendously
>>>> helpful.
>>>>
>>>>
>>>> ---------------------------------------------------------------
>>>> The use case:
>>>>
>>>> a) take a base image (3.8g for example)
>>>> b) follow a loading list (e.g. the packages for full)
>>>> c) load a package and create an entry in a log text file
>>>> d) do this until all packages are successfully loaded.
>>>> e) send an email with the following notes to this list
>>>>    (weekly)
>>>>    the version of the base image, the packages loaded.
>>>>
>>> I think you identified a very important use case.
>>> I assume that you mean the newest versions of this packages
>>> available,
>>> no?
>>> So this would make sense on a moving target, meaning to try
>>> to load the
>>> newest versions into the _actual_ image version, right?
>>>>    -----------------------------------------------------
>>>> Result:
>>>> The sucess of the test is indicated by a email
>>>>
>>>> Error:
>>>> The process of loading may stuck. A crude and easy way to
>>> detect this
>>>> is just a time out superwised by the calling shell script.
>>>>
>>>> The log file gives the last known package which loaded.
>>>> An error report describing this is sent to the list as well.
>>>> ---------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> As a package loading list we could start with 'Full'
>>>> and later add variants of it.
>>>>
>>>>
>>>> Later one (when SM has dependencies) your test robot could go to
>>>> SqueakMap and load all the packages listed there as
>>> compatible with a
>>>> certain version. Developers could even check a box that they are
>>>> informed automatically if their package does not load.
>>>>
>>>> But for the moment we should limit ourselves to hand crafted package
>>>> loading list.
>>>>
>>>> If you manage to set up this Test Server again that would be a
>>>> tremendous contribution for the community. Notably one that
>>> safes each
>>>> one on the list a lot of trouble ....
>>> Big thanks goes to Daniel Vainsencher, who installed it, and
>>> made work
>>> the first time! But somehow university got both of us distracted
>>> again...
>>>>
>>>>
>>>>
>>>> I do not see the fingerprint thing to be an issue. Just take the
>>>> images from the download directory. They are tagged with the change
>>>> set version number. For the beginning that is fine.
>>> I did not explain it very well, I guess. The idea is to
>>> harvest all the
>>> unary methods (at least the ones on the class sides) and use them as
>>> "smoke tests".
>>> Some of them might never run, but if some ran in an earlier
>>> version and
>>> now not anymore, that might mean sth.
>>>
>>> In order to get them I was thinking to use this fingerprint approach,
>>> as you want to make sure, that no side-effects of some earlier tests
>>> occur.
>>> For academic reasons I would be quite interested in this
>>> approach: has
>>> this been done before, is it useful, is it feasible?
>>>>
>>>> Thank you again for this initivative.
>>>>
>>> Thanks again for clarifying this useful use case and cheering
>>> words :-)
>>>
>>> Markus
>>>
>>>
>>
>>
>
>