Magma benchmarks with different MaDictionaries comparison

[Florian Minjat]

Chris Muller wrote:
> Hi Florian, thanks for trying the latest version.  I just posted a new
> version, 1.0r40gamma4 which, along with the suggestions below, should
> address (hopefully all) of your issues.
> 
>> - I wanted to run it under linux but it doesn't want to, looking for a
>> 'squeak.exe' intead of 'squeak'.
> 
> I changed that to "SmalltalkImage current getSystemAttribute: 0".
> Does that work for you on your Linux?

I'll try later and keep you informed.

>> - I got a problem with firefox taking one of the listening port of the
>> squeak image.
> 
> How did you figure that out?  The Magma test cases listen on 1314,
> 1315, 1316 and 51969.  Why would Firefox be listening or connecting to
> one of those ports?  In either case, you can set MaNetworkTestCase
> class>>'NextPort' to whatever value you need for your system.

No idea why, just saw it with a tcp viewer. It could be caused by a 
flash application. Closing Firefox solved the problem.

> It sounds like you are running a special version of SUnit.  At this
> time, Magma supports only the versions of Squeak that are listed on
> the Magma home page.

I was running the last squeak-dev image with updates 
(sq3.9-7067dev07.08.1).

>> - I got a complain about the MagmaPerson and MagmaContact because it
>> didn't found the right files.
> 
> They're available on the documentation page:
> 
>     http://wiki.squeak.org/squeak/2661
> 
> Did you put them in your image directory?

I did put them. But the test wanted them with a different filename 
(MagmaContact.1.st and MagmaPerson.1.st) and kept asking them until I 
found it too annoying and renamed them :).

>> - After that the tests worked ok until i noticed the cpu down after
>> some time and saw an Error primitiveFailed on
>> StandardFileStream>>primSetPosition:to: on the _magmaTestServer image.
>> Magma was trying to use an old MagmaSession from the benchmarks and
>> couldn't open the repository. There should be some cleaning of the
>> image before the test. Something like that : MagmaSession
>> disconnectAndCloseAllConnectedSessions.
>> MagmaRepositoryController initialize. MagmaServerConsole allInstances
>> do: [:i|i shutdown]. Smalltalk garbageCollect.
>> (btw I managed to gc all the MagmaSession with this but I don't know
>> if it's the proper way).
> 
> Hmm, that might be too presumptious for Magma to go closing down your
> open db's...  For now, please just clean up your own databases if you
> don't want them open.

And is there a better or easier way to clean all that stuff ?

>> - I got an error EmptyStream during SecureHashAlgorithm>>hashStream:
>> with MultiByteFileStream: 'c:\temp\Magma\objects.5.idx' as argument on
>> the _magmaTestServer. The _testConductor image shows 'remote
>> performing  captureFileChecksumsWithCopy: with arguments #(false) in
>> server'. The file size is 0 octet so I don't know what the hash is
>> suppose to answer on this one.
>> I modified the
>> MagmaTestCase>>fileChecksums method to put 0 in the answer if the file
>> is empty (file atEnd).
> 
> Please expect the tests to run from start to finish without any
> problems.  If they don't, there's  a problem and what you are doing is
> simply trying to hide a problem with the test that shouldn't have
> occurred in the first place.  When you have as many problems as you
> had getting this far, it's very likely this was caused by a previous
> problem.  You should focus on getting a clean run before trying to
> "fix" potential non-problems.

I never proceed a failed test. Each problem I mentionned was the only 
one of a test run. The problem with the empty files was a real problem 
and occured each time.

>> Then an assertion failed when comparing the
>> hashes of the files before and after a rollback and the only
>> difference was that the empty file was missing. So I change that
>> method again so if the file is empty, it's not listed in the dict.
> 
> Not a good change because it shouldn't happen.  If it does we need to
> investigate why, not simply hide it.
> 
>> - Finally I got an assertion failed during 'remote performing
>> verifyAddedStrings with arguments #() in client1'. The assert was on
>> _magmaTestClient1 in MagmaTestCase>>verifyAddedStrings where
>> 'afterImagesProgress size' equals 0. No idea what to do next.
> 
> It sounds like your earlier failures led to later failures.  The test
> cases should run from start to finish without interruption.

The only thing that could have led to this problem was the empty file 
whose fix was to simply ignore it. The test run was launched from the 
start without errors.

I will try your new version today to see if I got any other errors.

Thanks for our answer !

Florian

>  - Chris
> 
> 
>> Florian Minjat wrote:
>>> Here are my benchs :
>>> Magma Benchmark (r40Gamma3 + Ma special collections-cmm.83) (Local) :
>>> http://paste.lisp.org/display/47159
>>> Magma Benchmark (r40Gamma3 + Ma special collections-sig.89) (Local) :
>>> http://paste.lisp.org/display/47158
>>> I added the two text result to the mail.
>>> I will try to run the full magma test on my computer.
>>>
>>> Florian
>>
>>
>> _______________________________________________
>> Magma mailing list
>> Magma at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>>
>