April 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Nice widget in Pharo

by Alexandre Bergel

Simon and I just discovered these methods. Amazing UITheme exampleColorControls UITheme exampleBasicControls UITheme exampleGroups UITheme exampleOtherControls UITheme exampleWindowWithToolbars Simon & Alexandre, about to change their mind on Morph -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 30, 2009

Re: [Pharo-project] tests for Collection classes

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=784 On Apr 30, 2009, at 10:33 AM, Cyrille Delaunay wrote: > Hello > > I'm Cyrille Delaunay, I work for the RMOD Inria team. > I'm currently working on tests for the Pharo Collection Library > using traits. > I've modified, added some traits and therefore redifined things in > test classes to attempt to get a best coverage. > (For the moment : Arraytest , BagTest , DictionaryTest , IntervalTest > , OrderedCollectionTest , SetTest , SortedCollectionTest StringTest , > SymbolTest , LinkedListTest ). > All modification have been saved in 'PharoTaskForces'. > With a static coverage tool (also saved in PharoTaskPhorces ) > removing noise > for each class (methods defined too high in hierarchy that are not > appropriated , > private methods , very specific methods that may should not be tested > for collection ), I got those coverage : > > Arraytest : tested at 94.5 % > BagTest : 88.4 % > DictionaryTest: 85 % > IntervalTest : 93 % > OrderedCollectionTest : 93.9% > SetTest : 85.9% > SortedCollectionTest : 92.3 % > StringTest : 91% > LinkedListTest : 90.5 % > > > Here are the more important modifications i've made about traits : > > -> new trait TConvertTest : > testing converting methods (such that 'asArray,' asBag', .. ) > > > -> new trait 'TSortTrait' : > testing sorting methods for 'ArrayedCollection'. > -sort > -sort: > -isSorted > -isSortedBy: > > > -> new trait: 'TCopySequenceable' : > testing copying methods using an order, an index access > (copyAfter: for example) > > > -> new trait 'TOccurrencesTest' : > testing method : > -> OccurencesOf: > > > -> new trait: TIterateSequencedReadableTest' > testing iterating methods using a specific order > ( usable therefore only by sequenceable collection ) > > -> new trait: 'TConcatenaionTest' > Bad initial version (specific to sequenceable collection) > Split into two trait: > -> TSequencedConcatenationTest (initial version) > -> TConcatenationTest (to do) > > - > new trait: 'TReplacementSequencedTest' > testing replacemnt methods : > - replaceAll:with: > - replaceFrom:to:with: > - replaceFrom:to:with:startingAt: > for Sequenced Collection > > -> Modification of all the methods in 'TIndexAccessingTest' > making them independent of elements in collection's Type.( so that it > can be used with all type of sequenceable collection like 'String'). > > -> > -> modification of all the tests in 'TAsStringAndDelimiterTest' > making its independent of the elements' type in collection. > 'TAsStringAndDelimiterTest' added to 'ArrayTest'. > > -> redefinition of 'TAsStringCommaAndDelimiterTest' which were > specific to sequenceable collection (and didn't work for 'BagTest'). > The initial version has been kept in a new trait: > 'TAsStringCommaAndDelimiterSequenceableTest'. > > > -> with new trait: 'TBeginsEndsWith' testing methods: > - beginsWith: > - endsWith: > > -> Remodularisation of the initial trait 'TIndexAccessing' (which > became to big) > Split into three traits: > - methods like 'indexOf' added to the New trait 'IndexAccess' . > - methods concerning 'SubCollectionAccess' added to a new trait: > 'TSubCollectionAccess'. > - methods concerning elements access added to a new trait : > 'TSequencedElementAccessTest' > > -> new trait: 'TPrintTest' > testing 'stream printing' methods > > Modification of TPrintTest wich was specific to sequenceable > collections. Initial version has been kept in a new trait : > TPrintSequencedTest > > > > -> Modification of TConvertTest wich tested some methods > (asSet, asIdentitySet) for duplicate contents what can't work for > Interval or Collection without equel elements. > Creation of a new trait : 'TConvertAsSetForMultiplinessTest'. > > > -> Remodularisation of TCopySequenceableTest wich were too big. > Creation of a new trait : > > -> TCopySequenceableSameContents > testing copying methods that only change the order of elements > and don't remove or add any elements to the copy. > > -> TCopyPartOfSequenceable > testing copying methods that only copy a part of a collection > (copyAfter: copyUpTo: ) > > -> TCopySequenceableWithOrWithoutSpecificElements > testing copying methods ( from the initial trait > TCopySequenceable ) that copy the collection with more or less > specified elements . > > -> 'TCopySequenceableWithReplacement' > testing copying methods ( from the initial version of > TSequenceableTest ) that copy and replace subcollections in the > receiver. > > -> Refinition of all tests in TIndexAccess so that they required a > simple collection without equal element and test the 'Standard' > comportement that come with. Therefore, it can be used by collections > that don't allowed duplicate elements. > The aspect of 'multiple occurrences' was puted into a new trait: > TIndexAccessForMultipliness > ( this aspect is important for 'lastIndexOf:' or 'identityIndexOf:' > for exemple ) > > > -> modification of all methods in TAddTest. > those methods used always directly 'self collection' to test if an > element had been added . > For example : self assert: self collection size = oldsize + 1 > > That didn't work if required methods returned a new object at each > time > and not an instance variable of the classTest. > TAddTest use now its own copies of required collection to be > independant of the way the method is given by the ClassTest. > > -> new trait: > - TRmoveByIndexTest > testing methods for removing by index access > (used at least by OrderedCollection and SortedCollection) > > -> new trait: > - TCopyPartOfSequenceableForMultipliness > testing the specific comportement with duplicate for methods in > TCopyPartOfSequenceable. > TCopyPartOfSequenceable can now be used by collection that don't > allowed duplicate elements. > > -> new traits : > - TCopySequenceableWithReplacementForSorted > testing specific comportement of methods like 'copyReplaceAll:with:' > for sorted collection. > > -> redefinition of trait : 'TIterateTest' (in a new trait > 'TIterateNew'). > This trait required a specific collection of integer and many tests > depended on the fact that elements were SmallInteger. > As this trait test iterating methods for all collections ( it is used > by 'CollectionRootTest' ), it should work for every kind of > collection and therfore every kind of elements in ( it should, for > example, work for 'LinkedList' that use 'Link' elements ) > The new trait work now for 'LinkedListTest'. > > -> Modification of all tests in 'TIterateSequencedReadableTest' > ( in the same way and for the same reasons than 'TItereateTest' ) > > -> Modification of test: > testAsCommaStringMore > in trait 'TAsStringCommaAndDelimiterSequenceableTest' > so that it works also with elements for wich 'asString' return a > String including ' '. > (for example: Link new asSTring returns: 'a Link') > > > -> TConvertTest split into two Traits. > All methods converting into a sorted collection are now tested in a > new trait: TConvertAsSortedTest so that collections that can't > include 'sortable' elements (LinkedList for example ) can use > TConvertTest. > TConvertAsSorted is specific to collection that can include sortable > elements. > > > -> Modification of TConvertTest wich tested some methods > (asSet, asIdentitySet) for duplicate contents what can't work for > Interval or Collection without equel elements. > Creation of a new trait : 'TConvertAsSetForMultiplinessTest'. > > > -> Remodularisation of TCopySequenceableTest wich were too big. > Creation of a new trait : > > -> TCopySequenceableSameContents > testing copying methods that only change the order of elements > and don't remove or add any elements to the copy. > > -> TCopyPartOfSequenceable > testing copying methods that only copy a part of a collection > (copyAfter: copyUpTo: ) > > -> TCopySequenceableWithOrWithoutSpecificElements > testing copying methods ( from the initial trait > TCopySequenceable ) that copy the collection with more or less > specified elements . > > -> 'TCopySequenceableWithReplacement' > testing copying methods ( from the initial version of > TSequenceableTest ) that copy and replace subcollections in the > receiver. > > -> Refinition of all tests in TIndexAccess so that they required a > simple collection without equal element and test the 'Standard' > comportement that come with. Therefore, it can be used by collections > that don't allowed duplicate elements. > The aspect of 'multiple occurrences' was puted into a new trait: > TIndexAccessForMultipliness > ( this aspect is important for 'lastIndexOf:' or 'identityIndexOf:' > for exemple ) > > > -> modification of all methods in TAddTest. > those methods used always directly 'self collection' to test if an > element had been added . > For example : self assert: self collection size = oldsize + 1 > > That didn't work if required methods returned a new object at each > time > and not an instance variable of the classTest. > TAddTest use now its own copies of required collection to be > independant of the way the method is given by the ClassTest. > > -> new trait: > - TRmoveByIndexTest > testing methods for removing by index access > (used at least by OrderedCollection and SortedCollection) > > -> new trait: > - TCopyPartOfSequenceableForMultipliness > testing the specific comportement with duplicate for methods in > TCopyPartOfSequenceable. > TCopyPartOfSequenceable can now be used by collection that don't > allowed duplicate elements. > > -> new traits : > - TCopySequenceableWithReplacementForSorted > testing specific comportement of methods like 'copyReplaceAll:with:' > for sorted collection. > > -> redefinition of trait : 'TIterateTest' (in a new trait > 'TIterateNew'). > This trait required a specific collection of integer and many tests > depended on the fact that elements were SmallInteger. > As this trait test iterating methods for all collections ( it is used > by 'CollectionRootTest' ), it should work for every kind of > collection and therfore every kind of elements in ( it should, for > example, work for 'LinkedList' that use 'Link' elements ) > The new trait work now for 'LinkedListTest'. > > -> Modification of all tests in 'TIterateSequencedReadableTest' > ( in the same way and for the same reasons than 'TItereateTest' ) > > -> Modification of test: > testAsCommaStringMore > in trait 'TAsStringCommaAndDelimiterSequenceableTest' > so that it works also with elements for wich 'asString' return a > String including ' '. > (for example: Link new asSTring returns: 'a Link') > > > -> TConvertTest split into two Traits. > All methods converting into a sorted collection are now tested in a > new trait: TConvertAsSortedTest so that collections that can't > include 'sortable' elements (LinkedList for example ) can use > TConvertTest. > TConvertAsSorted is specific to collection that can include sortable > elements. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 30, 2009

Re: [Pharo-project] Enhanced ContextPartOn printReportOn: from John McIntosh

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=783 Stef On Apr 30, 2009, at 10:05 AM, StÃ©phane Ducasse wrote: >> >> I've attached a ContextPart>>errorReportOn: we use to print more >> information, the current one dates from the last decade of the last >> century and really >> provides too little data on the instance variables and stack size. >> For example if we could see all of files: we chould see if the >> pier.changes file is there. >>>>> >>>>> >> >> >> ContextPart>>errorReportOn: strm >> "Write a detailed error report on the stack (above me) on a >> stream. For both the error file, and emailing a bug report. >> Suppress any errors while getting printStrings. Limit the length." >> >> | cnt aContext startPos | >> strm print: Date today; space; print: Time now; cr. >> strm cr. >> strm nextPutAll: 'VM: '; >> nextPutAll: SmalltalkImage current platformName asString; >> nextPutAll: ' - '; >> nextPutAll: SmalltalkImage current platformSubtype asString; >> nextPutAll: ' - '; >> nextPutAll: SmalltalkImage current osVersion asString; >> nextPutAll: ' - '; >> nextPutAll: SmalltalkImage current vmVersion asString; >> cr. >> strm nextPutAll: 'Image: '; >> nextPutAll: SystemVersion current version asString; >> nextPutAll: ' ['; >> nextPutAll: SmalltalkImage current lastUpdateString asString; >> nextPutAll: ']'; >> cr. >> strm cr. >> SecurityManager default printStateOn: strm. >> >> "Note: The following is an open-coded version of >> ContextPart>>stackOfSize: since this method may be called during a >> low space condition and we might run out of space for allocating the >> full stack." >> cnt := 0. startPos := strm position. >> aContext := self. >> [aContext notNil and: [(cnt := cnt + 1) < 40]] whileTrue: >> [aContext printDetails: strm. "variable values" >> strm cr. >> aContext := aContext sender]. >> >> strm cr; nextPutAll: '--- The full stack ---'; cr. >> aContext := self. >> cnt := 0. >> [aContext == nil] whileFalse: >> [cnt := cnt + 1. >> cnt = 40 ifTrue: [strm nextPutAll: ' - - - - - - - - - - - - - - - >> - - - - - - - - - - - - - - - - - -'; cr]. >> strm print: aContext; cr. "just class>>selector" >> >> strm position > (startPos+150000) ifTrue: [strm nextPutAll: >> '...etc...'. >> ^ self]. "exit early" >> cnt > 200 ifTrue: [strm nextPutAll: '-- and more not shown --'. ^ >> self]. >> aContext := aContext sender]. >> >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 30, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by StÃ©phane Ducasse

I would like to know why does the system rely on finalisation to release socket Apparently david mentioned that this is the source of huge problems. So what would be the alternative? Stef On Apr 30, 2009, at 12:00 PM, Michael Rueger wrote: > Alexandre Bergel wrote: >> Thanks Johan for such a deep insight. >> You're probably very close to the truth. I modified the priority of >> the finalization process to 61. The socket problem just vanished. > > Great news! > > And a big thanks to John for the in depth analysis! > > So, should we just change the priority by default? What could be > possible side effects? > > Michael > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 30, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Alexandre Bergel

I checked again, and apparently setting the priority of the finalization process to 61 does _not_ solve the socket problem. Maybe I did a wrong manipulation previously. Grrr... Alexandre On 30 Apr 2009, at 05:40, John M McIntosh wrote: > Further to this I"m wondering if there is something else "clever" > going on. > > Should the finalization process run at priority 61? See > WeakArray>>restartFinalizationProcess > Perhaps someone can check that? > > Let me ramble on... > > In the past you had the event polling going on at prioirty 40 in the > 'UI process' > That would grind away... > > You also had the 'event tickler' that ran every 500 ms at priority 60. > > And there in the middle why the key player here, the 'WeakArray > finalization process' at 50 > > In this problem area, if we consider the socket creation fails because > the number of sockets allocated has reached the limit (aka unix limit) > not seen in windows. > then this is because either (a) we are actualy holding onto thousands > of sockets on purpose? > Or we have 1, and thousands of zombies that have been tenured to > OldSpace but not yet GCed, and Unix is unhappy with us. > > Now when the socket create fails that causes well another pointless > attempt at creation (why?) but also a full GC. > The full GC will of course signal to the 'WeakArray finalization > process' for it to gently destroy sockets. > > But let's consider what's NEW here is the 'input events fetching > process' is now running at 2x the speed of the older UI process and > consuming 10-30% of the cpu? > I'm not sure why before it was acceptable to look every 1/50 second, > but now it has to be every 1/100 of a second. > > But it's interesting that it''s running at priority 60, which means > it's sucking CPU away from the weak array finalization process. > > Now as we know the weak array finalization process is rather cpu > intensive, so I wonder if there is just enough CPU taken away from > finalization process > so that it can't do enough work before the retry for the socket > allocation leaps in and fails for a final time? > > Well of course I'm not sure why the finalization process wouldn't > finalize all the zombie sockets in one go when the full gc completes, > but that would require some more testing... > > > On 29-Apr-09, at 8:09 PM, John M McIntosh wrote: > >> Er maybe someone doing the testing can stick a >> Socket allInstances size inspect >> in at the pointer where the exception is signaled. I think it would >> be enlightening what the value is. >> >> On 29-Apr-09, at 7:52 PM, Cameron Sanders wrote: >> >>> Socket status must Unconnected before opening a new >>> connection >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 30, 2009

Re: [Pharo-project] [FIX] Issue 782: OB is ambiguous when asking to Accept or Discard changes in the code panel

by StÃ©phane Ducasse

> > > > BTW, any hint about how to introduce return line in pop up title? :) 'hjkhkjh / lkjlkjkj ' withCrs

April 30, 2009

Re: [Pharo-project] tests for Collection classes

by StÃ©phane Ducasse

I will integrate it soon Stef On Apr 30, 2009, at 11:39 AM, Damien Cassou wrote: > On Thu, Apr 30, 2009 at 10:33 AM, Cyrille Delaunay > <cyrille.delaunay(a)etudiant.univ-lille1.fr> wrote: >> Hello >> >> I'm Cyrille Delaunay, I work for the RMOD Inria team. >> I'm currently working on tests for the Pharo Collection Library >> using traits. >> I've modified, added some traits and therefore redifined things in >> test classes to attempt to get a best coverage. >> (For the moment : Arraytest , BagTest , DictionaryTest , IntervalTest >> , OrderedCollectionTest , SetTest , SortedCollectionTest StringTest , >> SymbolTest , LinkedListTest ). >> All modification have been saved in 'PharoTaskForces'. >> With a static coverage tool (also saved in PharoTaskPhorces ) >> removing noise >> for each class (methods defined too high in hierarchy that are not >> appropriated , >> private methods , very specific methods that may should not be >> tested >> for collection ), I got those coverage : > > Hi Cyrille, > > thank you very much. This is very nice work. Hope to see that in > Pharo soon. > > Thank you > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 30, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Michael Rueger

Alexandre Bergel wrote: > Hi Cam, > > The problem is likely to be the one pointed out by John yes and no. The problem with the ftp is probably a porting problem to the new socket code. Will take a look Michael

April 30, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Alexandre Bergel

Hi Cam, The problem is likely to be the one pointed out by John Alexandre On 30 Apr 2009, at 05:58, Cameron Sanders wrote: > Alexandre, you did mention having #port: sent to a ByteArray. It looks > like the last line of > FTPClient>>openPassiveDataConnection should be: > self openDataSocket: remoteHostAddress asSocketAddress port: dataPort > > instead of (current code): > self openDataSocket: remoteHostAddress port: dataPort > > With that change, the system drills on down and has a primitive > failure in #port (on a Mac). > > I will add "Socket allInstances size inspect" just above the #port: > method in Socket>>connectTo:port:. > > ... and the answer is SmallInteger: 7. > Anything else I should inspect in here? > > -Cam > PS: I am coming at this from the Monticello/FTP side, because my code > is on an ftp server. > > > On Apr 29, 2009, at 5:00 PM, Alexandre Bergel wrote: > >> Does not work for me. The problem is probably different. I still >> get a >> 'Socket status must Unconnected before opening a new connection' >> >> Alexandre >> >> >> On 29 Apr 2009, at 21:39, Nicolas Cellier wrote: >> >>> Could you test if this fix works: >>> >>> PharoInbox/SLICE-M7343-Socket-Rollover-bug-nice.2 >>> >>> 2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> OK guys, I think you loaded my rollover stuff... >>>> Mea maxima culpa: >>>> >>>> #waitForDataUntil: and #waitForDataFor: DID NOT DO THE SAME THING! >>>> >>>> the former signals ConnectionClosed, while the later silently >>>> answer false... >>>> >>>> The reason it works on windws is probably I did not load my change >>>> (I >>>> used a different image...). >>>> >>>> Strangely, I used Monticello on squeaksource without encountering >>>> this bug... >>>> >>>> Nicolas >>>> >>>> 2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> Also note that it fails at the end of the progress bar. >>>>> And inspecting response tempVar in HTTPSocket>>getRestOfBuffer: >>>>> leads to: >>>>> >>>>> collection copyFrom: readLimit-100 to: readLimit -> >>>>> 'Standard.39-cwp.1.mcz</a> 18-Aug-2006 >>>>> 19:38 >>>>> 50K >>>>> <hr></pre> >>>>> </body></html> >>>>> ' >>>>> >>>>> I don't want to learn anything about http protocol, but it sounds >>>>> like >>>>> the whole stream was correctly retrieved. >>>>> That means something has changed in the order things are >>>>> processed. >>>>> We should test if it is a matter of VM or in image change. >>>>> >>>>> Nicolas >>>>> >>>>> 2009/4/29 Michael Rueger <m.rueger(a)acm.org>: >>>>>> Nicolas Cellier wrote: >>>>>>> I confirm it works on windows and fails on linux (exupery VM) >>>>>> >>>>>> as it also fails on Mac it seems it could be the Unix socket >>>>>> code? >>>>>> >>>>>> Michael >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>> project >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 30, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Michael Rueger

Alexandre Bergel wrote: > Thanks Johan for such a deep insight. > You're probably very close to the truth. I modified the priority of > the finalization process to 61. The socket problem just vanished. Great news! And a big thanks to John for the in depth analysis! So, should we just change the priority by default? What could be possible side effects? Michael

April 30, 2009