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

[Pharo-project] [ANN] 10294, 10295, 10296

by StÃ©phane Ducasse

Hi here are some updates: 10294 - not working sensor fixes :( but like that they are in 10295 - http://code.google.com/p/pharo/issues/detail?id=789 (PseudoContext initialize) - http://code.google.com/p/pharo/issues/detail?id=788 (compact classes - http://code.google.com/p/pharo/issues/detail?id=783 Issue 783: Better ContextPart>>errorReportOn: 10296 - http://code.google.com/p/pharo/issues/detail?id=790: bookmorph cleaning - http://code.google.com/p/pharo/issues/detail?id=756 font rendering speed up - http://code.google.com/p/pharo/issues/detail?id=786 (remoteString closing) stef

May 2, 2009

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

by Alexandre Bergel

-- before ScriptLoader loadOBAlpha -- Socket allSubInstances size 0 HTTPSocket allSubInstances size 0 FileStream allSubInstances size 4 -- after ScriptLoader loadOBAlpha, the debugger is still up -- Socket allSubInstances size 2 HTTPSocket allSubInstances size 2 FileStream allSubInstances size 56 Alexandre On 2 May 2009, at 09:14, John M McIntosh wrote: > That would be > >> FileStream allSubInstances size inspect > > not > > FileStream allInstances size > > > On 2-May-09, at 12:13 AM, Alexandre Bergel wrote: > >> Strange, I have figures different from Nicolas: >> >> -- before ScriptLoader loadOBAlpha -- >> Socket allInstances size 0 >> HTTPSocket allInstances size 0 >> FileStream allInstances size 0 >> >> -- after ScriptLoader loadOBAlpha, the debugger is still up -- >> Socket allInstances size 0 >> HTTPSocket allInstances size 2 >> FileStream allInstances size 0 >> >> Alexandre >> >> >> On 1 May 2009, at 04:04, John M McIntosh wrote: >> >>> Well yes, and the magic check would be >>> >>> FileStream allSubInstances size inspect > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 2, 2009

[Pharo-project] I will integrate and push some fixes before noon

by StÃ©phane Ducasse

- not working sensor fixes - http://code.google.com/p/pharo/issues/detail?id=789 (PseudoContext initialize) -http://code.google.com/p/pharo/issues/detail?id=788 (MC pool sorting) - http://code.google.com/p/pharo/issues/detail?id=788 (compact classes - http://code.google.com/p/pharo/issues/detail?id=783 Issue 783: Better ContextPart>>errorReportOn: - http://code.google.com/p/pharo/issues/detail?id=774 network rollover - http://code.google.com/p/pharo/issues/detail?id=784 TestCollections - http://code.google.com/p/pharo/issues/detail?id=769 Fix for (StringTest new testUnescapePercentsWithTextEncoding) - http://code.google.com/p/pharo/issues/detail?id=758 Little font rendering speedup Stef

May 2, 2009

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

by John M McIntosh

That would be > FileStream allSubInstances size inspect not FileStream allInstances size On 2-May-09, at 12:13 AM, Alexandre Bergel wrote: > Strange, I have figures different from Nicolas: > > -- before ScriptLoader loadOBAlpha -- > Socket allInstances size 0 > HTTPSocket allInstances size 0 > FileStream allInstances size 0 > > -- after ScriptLoader loadOBAlpha, the debugger is still up -- > Socket allInstances size 0 > HTTPSocket allInstances size 2 > FileStream allInstances size 0 > > Alexandre > > > On 1 May 2009, at 04:04, John M McIntosh wrote: > >> Well yes, and the magic check would be >> >> FileStream allSubInstances size inspect -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

May 2, 2009

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

by Alexandre Bergel

Strange, I have figures different from Nicolas: -- before ScriptLoader loadOBAlpha -- Socket allInstances size 0 HTTPSocket allInstances size 0 FileStream allInstances size 0 -- after ScriptLoader loadOBAlpha, the debugger is still up -- Socket allInstances size 0 HTTPSocket allInstances size 2 FileStream allInstances size 0 Alexandre On 1 May 2009, at 04:04, John M McIntosh wrote: > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 2, 2009

Re: [Pharo-project] Fwd: Closure update from eliot

by StÃ©phane Ducasse

now as http://code.google.com/p/pharo/issues/detail?id=789 On May 1, 2009, at 9:31 PM, StÃ©phane Ducasse wrote: > > > Begin forwarded message: > >> From: John M McIntosh <johnmci(a)smalltalkconsulting.com> >> Date: May 1, 2009 7:41:58 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 >> >> Ok to answer the question, when we need to find the class of an >> object, we invoke either fetchClassOf: or fetchClassOfNonInt: >> now if the class is compact as per the oops header bits we use more >> bits in the oops header to pull the class oops from the compact array >> using the compact class index value. Otherwise the oops of the class >> is in the header, which requires more storage for the oops header >> >> When we make the class as compact then it's stuff into the compact >> array and allInstances of the old class converted. >> >> >> Lastly, well I'm wondering about the impact on image segments. >> >> The comment in becomeCompact: says... >> >> "Here are the restrictions on compact classes in order for export >> segments to work: A compact class index may not be reused. If a >> class was compact in a release of Squeak, no other class may use >> that index. The class might not be compact later, and there should >> be nil in its place in the array." >> >> But I wonder if >> remapCompactClasses:refStrm: >> >> ensures accidents don't happen, however let's see if Eliot has cross- >> checked this issue, no doubt the the comment is dated... >> >> >> Also >> PseudoContext(class)>>initialize >> seems rather obsolete then? >> >> >> On 1-May-09, at 3:10 AM, StÃ©phane Ducasse wrote: >> >>> I have a stupid question about this one. >>> Does it mean that we should fix that at the level of the vm since >>> compactClassesArray is a primitive >>> and recreateSpecialObjectsArray used it. >>> >>> stef >>> >>> Begin forwarded message: >>> >>>> From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Date: May 1, 2009 11:55:45 AM CEDT >>>> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >>>> Subject: [Pharo-project] Closure update from eliot >>>> Reply-To: Pharo-project(a)lists.gforge.inria.fr >>>> >>>> >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> 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

Re: [Pharo-project] Fwd: latest Pharo image?

by StÃ©phane Ducasse

now as http://code.google.com/p/pharo/issues/detail?id=788 On May 1, 2009, at 11:54 AM, StÃ©phane Ducasse wrote: > > > 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.. >> >> >> > <SortPoolsInMonticello.st.st> > > _______________________________________________ > 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] Fwd: Closure update from eliot

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=787 On May 1, 2009, at 9:31 PM, StÃ©phane Ducasse wrote: > > > 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 >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> > > _______________________________________________ > 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: Closure update from eliot

by StÃ©phane Ducasse

Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: May 1, 2009 7:43:44 PM CEDT > To: Eliot Miranda <eliot.miranda(a)gmail.com> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Closure update from eliot > Reply-To: johnmci(a)smalltalkconsulting.com > > Boo hiss, well that would work, but '12' is a magic number in this > case the iteration over the collection was to *avoid* one-off > useages of a magic number > Well humpft. > > Of course one off usages of a magic number is allowed... Since it's > less typing.. > > > On 1-May-09, at 10:31 AM, Eliot Miranda wrote: > >> 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 > > -- > = > = > = > = > = > ====================================================================== > 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 7:41:58 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 > > Ok to answer the question, when we need to find the class of an > object, we invoke either fetchClassOf: or fetchClassOfNonInt: > now if the class is compact as per the oops header bits we use more > bits in the oops header to pull the class oops from the compact array > using the compact class index value. Otherwise the oops of the class > is in the header, which requires more storage for the oops header > > When we make the class as compact then it's stuff into the compact > array and allInstances of the old class converted. > > > Lastly, well I'm wondering about the impact on image segments. > > The comment in becomeCompact: says... > > "Here are the restrictions on compact classes in order for export > segments to work: A compact class index may not be reused. If a > class was compact in a release of Squeak, no other class may use > that index. The class might not be compact later, and there should > be nil in its place in the array." > > But I wonder if > remapCompactClasses:refStrm: > > ensures accidents don't happen, however let's see if Eliot has cross- > checked this issue, no doubt the the comment is dated... > > > Also > PseudoContext(class)>>initialize > seems rather obsolete then? > > > On 1-May-09, at 3:10 AM, StÃ©phane Ducasse wrote: > >> I have a stupid question about this one. >> Does it mean that we should fix that at the level of the vm since >> compactClassesArray is a primitive >> and recreateSpecialObjectsArray used it. >> >> stef >> >> Begin forwarded message: >> >>> From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> Date: May 1, 2009 11:55:45 AM CEDT >>> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> >>> Subject: [Pharo-project] Closure update from eliot >>> Reply-To: Pharo-project(a)lists.gforge.inria.fr >>> >>> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > >

May 1, 2009