- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Improving a Process termination procedure

by Igor Stasenko

FYI ---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: 2009/5/1 Subject: Re: Improving a Process termination procedure To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Another improvement would be to marry the process termination with exception handling, and nicely signal ProcessTerminatedException. This offers many practical benefits, since then we could write: [ ... ] on: ProcessTerminatedException do: [:ex | Â "oh man we're been terminated" ]. But i'm not expert in exception handling. Can someone give me a sample, how to signal such exception in potential #terminateFromContext: method? 2009/5/1 Igor Stasenko <siguctua(a)gmail.com>: > There are a potential of having incorrect behavior , when terminating > a preempted or waiting process: > > with introduction of ProcessLocalVariable, it is essential that > context unwinding procedure should be performed only > for currently active process. > > Here the proposal how to ensure this: > > if terminating process is not active process we should do the following: > > suspendedContext := proc suspendedContext. > currentProces := Processor activeProcess. > proc suspendedContext: Â [ Â Processor activeProcess > terminateFromContext: suspendedContext. Processor switchToProcess: > currentProcess ] asContext. > Processor switchToProcess: proc. > > here #switchToProcess: is explicit switch (bypassing scheduling logic). > > If we don't care about immediate termination of process and getting > back to process who initiated termination as soon as possible, then > simply do: > process terminateSoon. > > which can be implemented as: > > Process>>terminateSoon > | termContext | > termContext := suspendedContext. > suspendedContext := [ Â self terminateFromContext: termContext. self > suspend ] asContext. > Processor yield. > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig.

May 1, 2009

Re: [Pharo-project] Closure update from eliot

by Igor Stasenko

cool stuff :) 2009/5/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > Begin forwarded message: > > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 1:34:25 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli > <renggli(a)iam.unibe.ch> > Subject: Re: latest Pharo image? > Hi Stef, Hi All, > Â Â Â got it; thanks. Â First thing I want to suggest is the following: > Smalltalk compactClassesArray > {CompiledMethod . MethodProperties . Array . PseudoContext . > LargePositiveInteger . Float . MethodDictionary . Association . Point . > Rectangle . ByteString . AnObsoleteTranslatedMethod . BlockContext . > MethodContext . nil . Bitmap . nil . nil . nil . nil . nil . nil . nil . nil > . nil . nil . nil . nil . nil . nil . nil} > The StackVM and CogVM have updated this for speed. Â So make it look like > Â #(CompiledMethod MethodProperties Array LargeNegativeInteger > LargePositiveInteger Float MethodDictionary Association Point Rectangle > ByteString BlockClosure BlockContext MethodContext nil Bitmap nil nil nil > nil nil nil nil nil nil nil nil nil nil nil nil) > i.e. replaceÂ PseudoContext > withÂ LargeNegativeInteger,Â AnObsoleteTranslatedMethod withÂ BlockClosure. > Â This will poise Pharo for use of the StackVM when it is released. > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> You can find it at >> >> Â Â Â Â http://gforge.inria.fr/frs/?group_id=1299 >> Â Â Â Â then you should take the pharo and not pharo-dev >> Â Â Â Â then you should do update (in system -> software update) >> >> Stef >> >> On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: >> >>> This reminds me to ask you for a location from which to download the >>> latest Pharo image ith closures so I can check the compiler changes I've >>> made against the image and send you them. Â This will be easier and less >>> error-prone than my e.g. extracting the packages we use here and you having >>> to work out the changes. >>> >>> >>> mmm latest pharo image >>> >>> Â [1 == 0] forkAt: 999. >>> >>> oops.. >>> >> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 1, 2009

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

by Nicolas Cellier

I can repeat my problem on linux, don't know if at all the same as Max users. It happens while doing: Installer wiresong project: 'ob'; install: 'OB-Refactory'. Once the load is finished: FileStream allSubInstances size -> 454 ls -l /proc/9091/fd | grep changes | wc -l -> 570 A little mismatch here... Note that it reached 1018 during load, for a total of 1024 opened fd, the upper limit... ls -l /proc/9091/fd | grep -v total | wc -l -> 1024 I can remove in image file stream: Smalltalk collectGarbage. FileStream allSubInstances size -> 4 But the file descriptors are not closed: ls -l /proc/9091/fd | grep changes | wc -l -> 570 Argh! After a garbage collect, I can proceed loading: Installer lukas project: 'omnibrowser'; install: 'OB-Regex'; install: 'OB-Tools' But dragging these 570 opened change log is not very sane... Gonna inquire if I can install a strace on my box. Nicolas 2009/5/1 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Well yes, and the magic check would be > > FileStream allSubInstances size inspect > > same place as the socket. > > Nothing of course finalization is involved in getting rid of zombie > file handles too. > > And Dave is right you should only have one file handle open (read/ > write) for *.changes > > > On 30-Apr-09, at 4:30 PM, David T. Lewis wrote: > >> Well that's a bug for sure. Somebody is opening new file streams on >> the changes file, probably by accident. And not closing the one they >> opened last time. >> >> The bug in changes file handling could easily appear to be a socket >> problem, because the per-process limit on open descriptors would be >> shared between files and sockets (and pipes and ...). So find out >> why the changes file is being accidentally reopened, and the "socket >> problem" will probably go away. >> >> Dave > > -- > = > = > = > ======================================================================== > 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 >

May 1, 2009

[Pharo-project] Sensor fix again does not work

by StÃ©phane Ducasse

if you want to try load the following cs Stef

May 1, 2009

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

by StÃ©phane Ducasse

I agree more or less :) Now with traits we just compose kind of first class protocols and the result is quite natural. stef On May 1, 2009, at 12:37 AM, Hernan Wilkinson wrote: > My mind keep thinking about this and I realized that the problem > with reusing sunit test cases is more a tool related problem. I > mean, nothing stop us from doing something like this: > ------- > TestCase subclass: #EnumerationTest > instanceVariableNames: 'collection' > etc. > > EnumerationTest>>testDo > > collection do: [ :x | self assert: what ever has to be > tested.... ]. > > EnumerationTest>>testSelect > > collection select: [ what ever has to be tested ... ] > > EnumerationTest>>collection: aCollection > > collection := aCollection. > ----- > Then if you want to run it with an array, we can do something like > this: > > EnumerationTest buildSuite > tests do: [ :aTest | aTest collection: #(1 2 3) ]; > run. > > or with a OrderedCollection > > EnumerationTest buildSuite > tests do: [ :aTest | aTest collection: (OrderedCollection with: > 1 ....) ]; > run. > > etc. > The problem with this is that the test runner assumes that test > cases are made up from subclasses of TestCase, a really bad > coupling... so, if we want to keep running test from the test > runner, we can: > 1) Create a test case per collection type and create a test method > per test method in EnumerationTest... > TestCase subclass: #ArrayTest > ArrayTest>> testDo > (EnumerationTest selector: #testDo) collection: #(1 2 3); run. > etc. a really ugly thing > 2) Redefine testSelectors in ArrayTest, OrderedCollectionTest to do > something like this: > testSelectors > ^EnumerationTest testSelectors > buildSuiteFromLocalSelectors > ^(super buildSuiteFromLocalSelectors) > tests do: [ :aTest | aTest collection: ... ] > 3) Or just open the test runner with a suite... something like: > > TestRunner open runSuite; ( EnumerationTest buildSuite > tests do: [ :aTest | aTest collection: #(1 2 3) ]; yourself) > > > Anyway, I think the problem of reusing tests with SUnit is more > related with the tools we use to run the tests and not with the > TestCase hierarchy, although it is not straightforward to reuse > tests with it. > > Bye, > Hernan > > On Thu, Apr 30, 2009 at 9:56 AM, Hernan Wilkinson <hernan.wilkinson(a)gmail.com > > wrote: > > What I read here indicates you prefer maintaining many duplicates of > the test. > And when you realize that one of the test was buggy (not the method > that is tested, but the test itself), you certainly prefer to track > all the copies and probably leave a buggy one here and there... > > nop nop... that was not my intention. If there is "duplicate code", > then it should be reified. > Traits is an option and we did that with Acciaressi and Butarelli > thesis (same problem). > Another option is just normal delegation. > > Bye, > Hernan > > > > Rethorical debates are fine, but it would be more enlightning to > discuss around some chosen examples. > > Nicolas > > 2009/4/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com>: > > 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 > > > > > > _______________________________________________ > > 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

May 1, 2009

[Pharo-project] Closure update from eliot

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 1:34:25 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli <renggli(a)iam.unibe.ch > > > Subject: Re: latest Pharo image? > > Hi Stef, Hi All, > > got it; thanks. First thing I want to suggest is the following: > > Smalltalk compactClassesArray > {CompiledMethod . MethodProperties . Array . PseudoContext . > LargePositiveInteger . Float . MethodDictionary . Association . > Point . Rectangle . ByteString . AnObsoleteTranslatedMethod . > BlockContext . MethodContext . nil . Bitmap . nil . nil . nil . > nil . nil . nil . nil . nil . nil . nil . nil . nil . nil . nil . nil} > > The StackVM and CogVM have updated this for speed. So make it look > like > #(CompiledMethod MethodProperties Array LargeNegativeInteger > LargePositiveInteger Float MethodDictionary Association Point > Rectangle ByteString BlockClosure BlockContext MethodContext nil > Bitmap nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil) > > i.e. replace PseudoContext with LargeNegativeInteger, > AnObsoleteTranslatedMethod with BlockClosure. This will poise Pharo > for use of the StackVM when it is released. > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > You can find it at > > http://gforge.inria.fr/frs/?group_id=1299 > then you should take the pharo and not pharo-dev > then you should do update (in system -> software update) > > Stef > > > On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: > > This reminds me to ask you for a location from which to download the > latest Pharo image ith closures so I can check the compiler changes > I've made against the image and send you them. This will be easier > and less error-prone than my e.g. extracting the packages we use > here and you having to work out the changes. > > > mmm latest pharo image > > [1 == 0] forkAt: 999. > > oops.. > > >

May 1, 2009

[Pharo-project] Closure update from eliot

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 3:23:48 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli <renggli(a)iam.unibe.ch > > > Subject: Re: latest Pharo image? > > One thing I recommend you do is to rip out the old closure compiler > stuff. e.g. CompiledMethod>>embeddedBlockMethods. > What I'm doing now is a merge that pulls in the important bug fixes. > > Things I'll try and do (or work with you) later are > > - ripping out MethodProperties and using the penultimate literal to > hold either the selector or an AdditionalMethodState, which is a > pragma-friendly replacement for MethodProperties. Doing this saves > a lot of space. > > - adding a primitive error code so you can write > fooPrimitive > <primitive: 'myprim' module: 'mymodule' error: errorCode> > errorCode == #'bad receiver' ifTrue: ... > > - remove all the old closure compiler stuff. > > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > You can find it at > > http://gforge.inria.fr/frs/?group_id=1299 > then you should take the pharo and not pharo-dev > then you should do update (in system -> software update) > > Stef > > > On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: > > This reminds me to ask you for a location from which to download the > latest Pharo image ith closures so I can check the compiler changes > I've made against the image and send you them. This will be easier > and less error-prone than my e.g. extracting the packages we use > here and you having to work out the changes. > > > mmm latest pharo image > > [1 == 0] forkAt: 999. > > oops.. > > >

May 1, 2009

[Pharo-project] Fwd: latest Pharo image?

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 1:50:55 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli <renggli(a)iam.unibe.ch > > > Subject: Re: latest Pharo image? > > the attached sorts class variables and shared pools in Monticello > class defs and results in fewer conflicts being reported. > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > You can find it at > > http://gforge.inria.fr/frs/?group_id=1299 > then you should take the pharo and not pharo-dev > then you should do update (in system -> software update) > > Stef > > > On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: > > This reminds me to ask you for a location from which to download the > latest Pharo image ith closures so I can check the compiler changes > I've made against the image and send you them. This will be easier > and less error-prone than my e.g. extracting the packages we use > here and you having to work out the changes. > > > mmm latest pharo image > > [1 == 0] forkAt: 999. > > oops.. > > >

May 1, 2009

[Pharo-project] Fwd: latest Pharo image?

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 1:34:25 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli <renggli(a)iam.unibe.ch > > > Subject: Re: latest Pharo image? > > Hi Stef, Hi All, > > got it; thanks. First thing I want to suggest is the following: > > Smalltalk compactClassesArray > {CompiledMethod . MethodProperties . Array . PseudoContext . > LargePositiveInteger . Float . MethodDictionary . Association . > Point . Rectangle . ByteString . AnObsoleteTranslatedMethod . > BlockContext . MethodContext . nil . Bitmap . nil . nil . nil . > nil . nil . nil . nil . nil . nil . nil . nil . nil . nil . nil . nil} > > The StackVM and CogVM have updated this for speed. So make it look > like > #(CompiledMethod MethodProperties Array LargeNegativeInteger > LargePositiveInteger Float MethodDictionary Association Point > Rectangle ByteString BlockClosure BlockContext MethodContext nil > Bitmap nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil) > > i.e. replace PseudoContext with LargeNegativeInteger, > AnObsoleteTranslatedMethod with BlockClosure. This will poise Pharo > for use of the StackVM when it is released. > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > You can find it at > > http://gforge.inria.fr/frs/?group_id=1299 > then you should take the pharo and not pharo-dev > then you should do update (in system -> software update) > > Stef > > > On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: > > This reminds me to ask you for a location from which to download the > latest Pharo image ith closures so I can check the compiler changes > I've made against the image and send you them. This will be easier > and less error-prone than my e.g. extracting the packages we use > here and you having to work out the changes. > > > mmm latest pharo image > > [1 == 0] forkAt: 999. > > oops.. > > >

May 1, 2009

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

by Nicolas Cellier

Hmm... I suspect my linux /proc has been foolished for some reason and it was in fact some sockets... I tried again, during loading, the socket opened and close and were recognized as such in /proc, but after a certain point, listing /proc/$pid/fd was reporting change log open and close... though the loading did continue normally. I will try the whole procedure again, but all this is really slow (I had some other traffic going on my limited bandwith). Nicolas 2009/5/1 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Well yes, and the magic check would be > > FileStream allSubInstances size inspect > > same place as the socket. > > Nothing of course finalization is involved in getting rid of zombie > file handles too. > > And Dave is right you should only have one file handle open (read/ > write) for *.changes > > > On 30-Apr-09, at 4:30 PM, David T. Lewis wrote: > >> Well that's a bug for sure. Somebody is opening new file streams on >> the changes file, probably by accident. And not closing the one they >> opened last time. >> >> The bug in changes file handling could easily appear to be a socket >> problem, because the per-process limit on open descriptors would be >> shared between files and sockets (and pipes and ...). So find out >> why the changes file is being accidentally reopened, and the "socket >> problem" will probably go away. >> >> Dave > > -- > = > = > = > ======================================================================== > 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 >

May 1, 2009