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

[Pharo-project] Fwd: Closure update from eliot

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 7:31:05 PM CEDT > To: johnmci(a)smalltalkconsulting.com > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Closure update from eliot > > I just used this in an updated Pharo0.1Core-10281cl.image > > PseudoContext becomeUncompact. > LargeNegativeInteger becomeCompact. > Smalltalk compactClassesArray at: 12 put: nil. "Stomp on the > obsolete Translated whatsit" > BlockClosure becomeCompact > > On Fri, May 1, 2009 at 9:29 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com > > wrote: > Also see > http://code.google.com/p/pharo/issues/detail?id=467 > > > Eliot wants > #(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) > > so do > > (Smalltalk compactClassesArray select: [:e | e notNil and: [e > isObsolete]]) > do: [:i | i becomeUncompact]. > PseudoContext becomeUncompact. > Smalltalk garbageCollect. > LargeNegativeInteger becomeCompact. > BlockClosure becomeCompact. > > gives then > > Smalltalk compactClassesArray inspect > > {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} > > Which my squinting eyeballs this morning seem to say it's the same... > > A post check is > > Smalltalk compactClassesArray doWithIndex: > [:c :i | c == nil ifFalse: > [c indexIfCompact = i ifFalse: [self halt]]] > > > > > On 1-May-09, at 3:10 AM, StÃ©phane Ducasse wrote: > > Smalltalk compactClassesArray > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > >

May 1, 2009

[Pharo-project] Fwd: Closure update from eliot

by StÃ©phane Ducasse

Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: May 1, 2009 6:29:33 PM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Eliot Miranda <eliot.miranda(a)gmail.com> > Subject: Re: [Pharo-project] Closure update from eliot > Reply-To: johnmci(a)smalltalkconsulting.com > > Also see > http://code.google.com/p/pharo/issues/detail?id=467 > > > Eliot wants > #(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) > > so do > > (Smalltalk compactClassesArray select: [:e | e notNil and: [e > isObsolete]]) > do: [:i | i becomeUncompact]. > PseudoContext becomeUncompact. > Smalltalk garbageCollect. > LargeNegativeInteger becomeCompact. > BlockClosure becomeCompact. > > gives then > > Smalltalk compactClassesArray inspect > > {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} > > Which my squinting eyeballs this morning seem to say it's the same... > > A post check is > > Smalltalk compactClassesArray doWithIndex: > [:c :i | c == nil ifFalse: > [c indexIfCompact = i ifFalse: [self halt]]] > > > > > On 1-May-09, at 3:10 AM, StÃ©phane Ducasse wrote: > >>>> Smalltalk compactClassesArray > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > >

May 1, 2009

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

by Hernan Wilkinson

On Fri, May 1, 2009 at 7:00 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > I agree more or less :) jeje > > Now with traits we just compose kind of first class protocols and the > result is quite natural. yes, it is true... I just wonder which one is better from the "theorical" point of view, if there is really a better one. Bye, Hernan. > > > 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 > > > _______________________________________________ > 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

Re: [Pharo-project] fixing linux loadOBAlpha problem by strace-ing an image (was Monticello/ftp stopped working for me)

by John M McIntosh

That is the multibyte file stream handing the UTF8 logic, where it writes one byte at a time to the file system. Er slow eh? I'll guess we are reading/writting change files now as UTF8? You can watch the system messages thunder into 100's of millions... for the VM. I'll bet that is why MC loading is so slow now? Because of this for Sophie we build a SophieMultiByteMemoryFileStream which streamed data in or out of a memory based stream with setup or close logic to read or flush the entire in memory stream to/from a target stream (usually a file). Technically what is required is a file stream subclass that does block read/writes so that you can read/write data in 64K chunks versus byte by byte. On 1-May-09, at 10:07 AM, Nicolas Cellier wrote: > Tracing is really slow, especially with these unbuffered writes > write(6, "^", 1) = 1 > write(6, "s", 1) = 1 > write(6, "e", 1) = 1 > write(6, "l", 1) = 1 > write(6, "f", 1) = 1 > I remember Eliot noticed this easy potential speed-up already. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

May 1, 2009

Re: [Pharo-project] fixing linux loadOBAlpha problem by strace-ing an image (was Monticello/ftp stopped working for me)

by Nicolas Cellier

See patch for http://code.google.com/p/pharo/issues/detail?id=786 in PharoInbox/SLICE-RemoteString-closeFile-nice.1 2009/5/1 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > After ScriptLoader loadOBAlpha problems, I'm now playing a bit with strace. > very instructive. > > strace build/squeak *.image `pwd`/loadOBAlpha.st > tmp.trace 2>&1 > > Notice a > (SourceFiles at: 2) truncate: SmalltalkImage current lastQuitLogPosition. > This is because repeated ScriptLoader loadOBAlpha are quickly spoiling > the change log. > > Tracing is really slow, especially with these unbuffered writes > write(6, "^", 1) = 1 > write(6, "s", 1) = 1 > write(6, "e", 1) = 1 > write(6, "l", 1) = 1 > write(6, "f", 1) = 1 > I remember Eliot noticed this easy potential speed-up already. > > I noticed a bunch of try...catch style of open file at startup. > grep ENOENT ../pharo0.1-10268dev09.04.1/tmp.trace | wc -l > 4012 > Most are plugin/library search and Freetype related. > But a few search concern icons and wonderland... Some room for more > etoys clean-up here? > > On my linux box, I can now confirm the socket problem encountered by > loadOBAlpha is really a (Too many open files) problem. > Some @!*^# code is trying to open more than 1018 change log files > which is a bit too much. > Some file closing happens from time to time but very sparsely. > This happens while loading > Installer wiresong > project: 'ob'; > install: 'OB-Refactory'. > > Consequently, the following instruction fails. > Installer lukas > project: 'ob'; > install: 'OB-Regex'; > > You can find tmp.trace at http://ncellier.ifrance.com/Squeak/tmp.trace.gz > 26MB gzipped. > > ------------------------------------------------------------------------------------------------------- > Now it's easier to debug the change log opener in image. > But it's not obvious whether we can reproduce in debugger because of > UI, debugger, GC interactions... > So we gonna use the MessageTally/Notification tricks: > > build/squeak *.image `pwd`/TraceOpenFile.st & > > Tally results are copied in OpenFileTally.txt. > Highly suspect is #readOnlyCopy... > RemoteString is guilty for not closing the file and relying on some > finalization actions... > And OBDynamicProtocols is abusing of this stuff... > > So fixing RemoteString by gently closing the file does fix the linux problem... > build/squeak *.image `pwd`/loadOBAlpha.st & > > > Now this is a good workaround, but what change introduced the problem ? > there are two solutions: > - either recent versions of OB are creating the problem > - or recent changes in Polling UI/or Process changed finalization order > > This should be tested in a 3.10.2 image >

May 1, 2009

[Pharo-project] fixing linux loadOBAlpha problem by strace-ing an image (was Monticello/ftp stopped working for me)

by Nicolas Cellier

After ScriptLoader loadOBAlpha problems, I'm now playing a bit with strace. very instructive. strace build/squeak *.image `pwd`/loadOBAlpha.st > tmp.trace 2>&1 Notice a (SourceFiles at: 2) truncate: SmalltalkImage current lastQuitLogPosition. This is because repeated ScriptLoader loadOBAlpha are quickly spoiling the change log. Tracing is really slow, especially with these unbuffered writes write(6, "^", 1) = 1 write(6, "s", 1) = 1 write(6, "e", 1) = 1 write(6, "l", 1) = 1 write(6, "f", 1) = 1 I remember Eliot noticed this easy potential speed-up already. I noticed a bunch of try...catch style of open file at startup. grep ENOENT ../pharo0.1-10268dev09.04.1/tmp.trace | wc -l 4012 Most are plugin/library search and Freetype related. But a few search concern icons and wonderland... Some room for more etoys clean-up here? On my linux box, I can now confirm the socket problem encountered by loadOBAlpha is really a (Too many open files) problem. Some @!*^# code is trying to open more than 1018 change log files which is a bit too much. Some file closing happens from time to time but very sparsely. This happens while loading Installer wiresong project: 'ob'; install: 'OB-Refactory'. Consequently, the following instruction fails. Installer lukas project: 'ob'; install: 'OB-Regex'; You can find tmp.trace at http://ncellier.ifrance.com/Squeak/tmp.trace.gz 26MB gzipped. ------------------------------------------------------------------------------------------------------- Now it's easier to debug the change log opener in image. But it's not obvious whether we can reproduce in debugger because of UI, debugger, GC interactions... So we gonna use the MessageTally/Notification tricks: build/squeak *.image `pwd`/TraceOpenFile.st & Tally results are copied in OpenFileTally.txt. Highly suspect is #readOnlyCopy... RemoteString is guilty for not closing the file and relying on some finalization actions... And OBDynamicProtocols is abusing of this stuff... So fixing RemoteString by gently closing the file does fix the linux problem... build/squeak *.image `pwd`/loadOBAlpha.st & Now this is a good workaround, but what change introduced the problem ? there are two solutions: - either recent versions of OB are creating the problem - or recent changes in Polling UI/or Process changed finalization order This should be tested in a 3.10.2 image

May 1, 2009

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

by Nicolas Cellier

Forget it. I was the only one foolished :) strace showed it was effectively an attempt to open more than 1018 change log... Then in absence of garbage collect every socket attempt just fails... (Too many open files) If we find the guilty change log opener, this will fix the issue at least on my linux box. Otherwise inserting a retryWithGC: here and there is a possible temporary workaround... But those files will have to be closed... 2009/5/1 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 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

[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