- Pharo-dev - lists.pharo.org

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

by Cameron Sanders

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

April 30, 2009

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

by John M McIntosh

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 = = = ========================================================================

April 30, 2009

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

by John M McIntosh

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 = = = ========================================================================

April 30, 2009

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

by Cameron Sanders

Don't worry, I "get it" from the logical view. I just wondered if it was related to 'Socket status must Unconnected before opening a new connection'. -cam On Apr 29, 2009, at 10:27 PM, Cameron Sanders wrote: > Maybe I'm just sleep deprived... but, the method isUnconnected looks > odd. Perhaps it is correct, and there is a good reason for the > implementation, but "socketHandle == nil ifTrue: [^false ]" seems > counter-intuitive. If socketHandle is not defined, then, it seems, we > probably not connected... and hence should answer true. > > My apologies if I am not thinking clearly... or if it is simply more > complex handle management. > > Socket >> > isUnconnected > "Return true if this socket's state is Unconnected." > > socketHandle == nil ifTrue: [^ false]. > ^ (self primSocketConnectionStatus: socketHandle) == Unconnected > > -Cam > > 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' >> > > Per > > _______________________________________________ > 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 Cameron Sanders

Maybe I'm just sleep deprived... but, the method isUnconnected looks odd. Perhaps it is correct, and there is a good reason for the implementation, but "socketHandle == nil ifTrue: [^false ]" seems counter-intuitive. If socketHandle is not defined, then, it seems, we probably not connected... and hence should answer true. My apologies if I am not thinking clearly... or if it is simply more complex handle management. Socket >> isUnconnected "Return true if this socket's state is Unconnected." socketHandle == nil ifTrue: [^ false]. ^ (self primSocketConnectionStatus: socketHandle) == Unconnected -Cam 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' > Per

April 30, 2009

Re: [Pharo-project] run all tests from superClass

by Miguel Enrique CobÃ¡ MartÃnez

Hernan Wilkinson wrote: > I don't think it is a good idea to have hierarchies with test cases... > depending on how you are doing it, it could couple the test hierarchy > with the model hierarchy and I don't think that is a good idea... > It also introduces some complexity, for example the number of tests are > not only the test methods but for each concrete test class, the test > methods on it plus the test methods of the abstract superclasses... hmmm > I don't know, it is not natural at least for me too user inheritance > with tests... +1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged. Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of. Cheers, Miguel CobÃ¡ > > On Wed, Apr 29, 2009 at 4:46 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > HI guys > > I was coding this afternoon with Cyrille who is working a lot to > improve the test coverage of collections. > And we found a bit strange that when a testcase inherits from another > one the tests of the superclass are not run. > I checked a bit SUnit code and superclass testmethods are only run is > the superclass is abstract or if there are not testmethods. > Imagine > BagTest > IdentityBagTest > > > We could redefine buildSuite on BagTest to invoke allSelectors > but this means in essence that we could do it on a lot of potential > testcase classes that may be subclasses. > > Or we could redefine buildSuite on IdentyBagTest but this means that > the subclasses should specify it. > May be this solution is the best but I wanted to get your thoughts. > > Of course this idea of inheriting test case make sense when superclass > setup can be reused in subclasses one. > So the default behavior of buildSuite always invoking all testmethods > may not be so good but then > via subclassing from BagTest if this is not to reuse it. > > Stef > > > On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: > > > A change have been saved in 'PharoInBox' for class TestCase in > > package SUnit > > so that suite are now built from allSelectors. > > This makes sense when you have testcase classes which inherits from > > each other and have parametrized (hook-based) setup. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@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

April 30, 2009

Re: [Pharo-project] run all tests from superClass

by Mariano Martinez Peck

On Wed, Apr 29, 2009 at 7:09 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > There is already such a switch that can be overridden in TestCase > class>>#shouldInheritSelectors. > That's true. There was a discussion in squeak-dev. Here: http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/132946/foc… greetings mariano > > Lukas > > On Wed, Apr 29, 2009 at 10:03 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Maybe add a switch > > runSuperTests > > "Tells whether test from superclass should be run. > > By default, this is true. > > If you don't want to run superclass tests, redefine this as false > > in your subclass." > > > > ^true > > > > 2009/4/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> HI guys > >> > >> I was coding this afternoon with Cyrille who is working a lot to > >> improve the test coverage of collections. > >> And we found a bit strange that when a testcase inherits from another > >> one the tests of the superclass are not run. > >> I checked a bit SUnit code and superclass testmethods are only run is > >> the superclass is abstract or if there are not testmethods. > >> Imagine > >> BagTest > >> IdentityBagTest > >> > >> > >> We could redefine buildSuite on BagTest to invoke allSelectors > >> but this means in essence that we could do it on a lot of potential > >> testcase classes that may be subclasses. > >> > >> Or we could redefine buildSuite on IdentyBagTest but this means that > >> the subclasses should specify it. > >> May be this solution is the best but I wanted to get your thoughts. > >> > >> Of course this idea of inheriting test case make sense when superclass > >> setup can be reused in subclasses one. > >> So the default behavior of buildSuite always invoking all testmethods > >> may not be so good but then > >> via subclassing from BagTest if this is not to reuse it. > >> > >> Stef > >> > >> > >> On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: > >> > >>> A change have been saved in 'PharoInBox' for class TestCase in > >>> package SUnit > >>> so that suite are now built from allSelectors. > >>> This makes sense when you have testcase classes which inherits from > >>> each other and have parametrized (hook-based) setup. > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2009

Re: [Pharo-project] run all tests from superClass

by Lukas Renggli

There is already such a switch that can be overridden in TestCase class>>#shouldInheritSelectors. Lukas On Wed, Apr 29, 2009 at 10:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Maybe add a switch > runSuperTests > Â Â "Tells whether test from superclass should be run. > Â Â By default, this is true. > Â Â If you don't want to run superclass tests, redefine this as false > in your subclass." > > Â Â ^true > > 2009/4/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> HI guys >> >> I was coding this afternoon with Cyrille who is working a lot to >> improve the test coverage of collections. >> And we found a bit strange that when a testcase inherits from another >> one the tests of the superclass are not run. >> I checked a bit SUnit code and superclass testmethods are only run is >> the superclass is abstract or if there are not testmethods. >> Imagine >> Â Â Â Â BagTest >> Â Â Â Â Â Â Â Â IdentityBagTest >> >> >> We could redefine buildSuite on BagTest to invoke allSelectors >> but this means in essence that we could do it on a lot of potential >> testcase classes that may be subclasses. >> >> Or we could redefine buildSuite on IdentyBagTest but this means that >> the subclasses should specify it. >> May be this solution is the best but I wanted to get your thoughts. >> >> Of course this idea of inheriting test case make sense when superclass >> setup can be reused in subclasses one. >> So the default behavior of buildSuite always invoking all testmethods >> may not be so good but then >> via subclassing from BagTest if this is not to reuse it. >> >> Stef >> >> >> On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: >> >>> A change have been saved in 'PharoInBox' for class TestCase in >>> package SUnit >>> so that suite are now built from allSelectors. >>> This makes sense when you have testcase classes which inherits from >>> each other and have parametrized (hook-based) setup. >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

April 29, 2009

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

by Mariano Martinez Peck

2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > ups... another question then... where is a list of core pharo packages?I > saw there is a pharo-core image and a pharo (or pharo-dev) image. I could > not find the pharo-core image, the one in the download page is the pharo-dev > image. > In pharo webpage where it says "archive and more...". It is a link to this: http://gforge.inria.fr/frs/?group_id=1299 There are all the images. saludos mariano > > Thanks > Hernan. > > > On Wed, Apr 29, 2009 at 2:22 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> However, I see this is related to OB. >> It's not really a package of the core pharo, but rather an external >> one included in Damien development images. >> Such external package has its own maintainer and is not maintained by >> pharo team. >> You should post to the appropriate code repository and mailing list... >> (a good soul in this list will have to tell you which one, because I >> don't know it) >> >> Cheers >> >> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> > ok then, no problem. >> > BTW, I'd like somebody to look at the fix I made because I'm not sure >> that >> > is the right way to doit. I mean, it is rare how the exception is >> related to >> > the dialog box. I think it is done that way because the handler of the >> > notification could not show a dialog... but if that is the idea then I >> think >> > something is missing to relate the cancel option of the notification >> with >> > the cancel button of the dialog. >> > >> > On Wed, Apr 29, 2009 at 12:39 PM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> Not annoying at all. Please do. >> >> >> >> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> >> > Another fix... >> >> > (Do I have to send a mail to the list per fix? the how to contribute >> >> > page >> >> > says so but it can be annoying...) >> >> > Hernan. >> >> > _______________________________________________ >> >> > 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 >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2009

Re: [Pharo-project] run all tests from superClass

by Hernan Wilkinson

I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea...It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests... On Wed, Apr 29, 2009 at 4:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > HI guys > > I was coding this afternoon with Cyrille who is working a lot to > improve the test coverage of collections. > And we found a bit strange that when a testcase inherits from another > one the tests of the superclass are not run. > I checked a bit SUnit code and superclass testmethods are only run is > the superclass is abstract or if there are not testmethods. > Imagine > BagTest > IdentityBagTest > > > We could redefine buildSuite on BagTest to invoke allSelectors > but this means in essence that we could do it on a lot of potential > testcase classes that may be subclasses. > > Or we could redefine buildSuite on IdentyBagTest but this means that > the subclasses should specify it. > May be this solution is the best but I wanted to get your thoughts. > > Of course this idea of inheriting test case make sense when superclass > setup can be reused in subclasses one. > So the default behavior of buildSuite always invoking all testmethods > may not be so good but then > via subclassing from BagTest if this is not to reuse it. > > Stef > > > On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: > > > A change have been saved in 'PharoInBox' for class TestCase in > > package SUnit > > so that suite are now built from allSelectors. > > This makes sense when you have testcase classes which inherits from > > each other and have parametrized (hook-based) setup. > > > > > > _______________________________________________ > > 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 >

April 29, 2009