June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Jenkins down?

by Sean P. DeNigris

StÃ©phane Ducasse wrote > > yes probably a problem with Java having too many handle open. > This is strange since last week christophe removed the aida job that was > causing us trouble. > The previous errors were 502 (bad gateway) errors, while this one is a 503 (service not available) error HTH, Sean -- View this message in context: http://forum.world.st/Jenkins-down-tp4635262p4635319.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 18, 2012

[Pharo-project] Wrong gofer command in ss3 gemstone

by Guillaume Larcheveque

In the section "Getting the code" for a project, the displayed command should be: "Gofer new squeaksource3: 'MyProject'; package: 'MyPackage'; load" It should be useful to correct that to avoid searching the correct syntax. Thanks in advance, -- *Guillaume Larcheveque*

June 18, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by Guillermo Polito

On Mon, Jun 18, 2012 at 12:46 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > But it looks like we're still not there: > > methods := Object methodDict values. > SystemNavigation default browseMessageList: methods name: 'Object methods' > > This is working in my latest 2.0 image :^)

June 18, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by StÃ©phane Ducasse

On Jun 18, 2012, at 12:46 AM, Igor Stasenko wrote: > On 17 June 2012 23:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Guys, we should hack this together. >>> When is next sprint? :) >> >> Next friday? >> > > Yeah,.. > because i still found things which i fail to understand in SystemNavigation: > some while ago we kind of decided that best would be to match the protocol(s) of > CompiledMethod and RGMethodDefinition, so you can use either one or > another or mix of them > as a model for browsers/lists etc including SystemNavigation. > > But it looks like we're still not there: > > methods := Object methodDict values. > SystemNavigation default browseMessageList: methods name: 'Object methods' > > fails miserably.. > but if i convert it to #methodReference, it works: > > methods := (Object methodDict values). > methods := methods collect: #methodReference. > SystemNavigation default browseMessageList: methods name: 'Object methods' > > and i feel like i was fooled: we replaced one wrapper - > MethodDefinition (or what was that?) > with another with just different name. But we still cannot use > CompiledMethod as a model for lists > etc.. > so can someone enlighten me, what is then changed, except a name(s)? This is just that the code to fill up the list is just using the wrong initialization (it should not wrap ring objects) There is no need for Ring objects there. Ring objects are only needed for remote package browsing, method versions, change recorder. Now we should just sit with ben and look at the filling up of the tools. > I am still clueless, why system tools cannot speak directly with > object(s) under the question, if necessary? See above. > > > -- > Best regards, > Igor Stasenko. >

June 18, 2012

Re: [Pharo-project] FileSystem and file extensions

by Milan Mimica

On 18 June 2012 01:50, Camillo Bruni <camillobruni(a)gmail.com> wrote: > indeed this is a bit tricky... but what can you explicitely say :/ > > foo.tar > foo.tar.gz > foo.1.tar > foo.1.tar.gz > Nice example. File extension is always after the last dot. -- Milan Mimica http://sparklet.sf.net

June 18, 2012

[Pharo-project] Select multiple items in ObjectExplorer

by HernÃ¡n Morales Durand

Hi guys, Have you seen out there a specialized ObjectExplorer where you may select several items? Cheers, HernÃ¡n

June 18, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by Eliot Miranda

On Sun, Jun 17, 2012 at 6:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 June 2012 01:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 17 June 2012 23:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> >> Guys, we should hack this together. > >> >> When is next sprint? :) > >> > > >> > Next friday? > >> > > >> > >> Yeah,.. > >> because i still found things which i fail to understand in > >> SystemNavigation: > >> some while ago we kind of decided that best would be to match the > >> protocol(s) of > >> CompiledMethod and RGMethodDefinition, so you can use either one or > >> another or mix of them > >> as a model for browsers/lists etc including SystemNavigation. > >> > >> But it looks like we're still not there: > >> > >> methods := Object methodDict values. > >> SystemNavigation default browseMessageList: methods name: 'Object > methods' > >> > >> fails miserably.. > >> but if i convert it to #methodReference, it works: > >> > >> methods := (Object methodDict values). > >> methods := methods collect: #methodReference. > >> SystemNavigation default browseMessageList: methods name: 'Object > methods' > >> > >> and i feel like i was fooled: we replaced one wrapper - > >> MethodDefinition (or what was that?) > >> with another with just different name. But we still cannot use > >> CompiledMethod as a model for lists > >> etc.. > >> so can someone enlighten me, what is then changed, except a name(s)? > > > > > > I did it a long time ago in VisualWorks 3.0 (IIRC). See below. > > > >> > >> I am still clueless, why system tools cannot speak directly with > >> object(s) under the question, if necessary? > > > > > > The wrapper is a pointer. If one redefines a method when recompiling > then > > the pointer refers to the current version of the method but a direct > > reference to the method answers the old version. The direct reference > > prevents the old version being garbage collected but the pointer does > not. > > For these reasons we use methodReference and not direct references. So > the > > use of pointers is necessary to make the tools work as expected. When > > methods are selected in the method list browser tools, the tools show > > current versions, not versions as of when they were opened. This is the > > same as the system browser, which holds onto class names and selectors, > not > > on class objects and method objects. > > > > By the way, in the olden days the method list browsers worked with > strings > > that looked like 'Foo selector' and 'Foo class selector:' which were > > pointers, but painful to parse to indirect to CompiledMethods. I added > > MethodReference in VisualWorks to replace these large and inflexible > strings > > with explicit pointer objects. Looks like Squeak followed suit. > > > > I know it. > But the point is, that those tools are subscribed to system changes, > and so, if listed method get changed or removed, the tool can update > it's list accordingly, > without a need to hold indirect pointer. > IIABDFI, KISS > > > > > As evidence of painful parsing here's code form the Smalltalk-80 > > MethodListBrowser: > > > > MethodListBrowser methodsFor: 'method list' > > methodName: selection > > | aStream aSymbol | > > methodName _ selection. > > selection == nil ifTrue: [selector _ nil. ^ self textMode: > > #unclassified]. > > aStream _ ReadStream on: selection. > > className _ (aStream upTo: $ ) asSymbol. > > aSymbol _ (aStream upTo: $ ) asSymbol. > > (meta _ (aSymbol == #class) & aStream atEnd not) ifTrue: > > [aSymbol _ (aStream upTo: $ ) asSymbol]. > > protocol _ self selectedClass organization categoryOfElement: > aSymbol. > > self selector: aSymbol > > > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

June 18, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by Igor Stasenko

On 18 June 2012 01:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sun, Jun 17, 2012 at 3:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 17 June 2012 23:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Guys, we should hack this together. >> >> When is next sprint? :) >> > >> > Next friday? >> > >> >> Yeah,.. >> because i still found things which i fail to understand in >> SystemNavigation: >> some while ago we kind of decided that best would be to match the >> protocol(s) of >> CompiledMethod and RGMethodDefinition, so you can use either one or >> another or mix of them >> as a model for browsers/lists etc including SystemNavigation. >> >> But it looks like we're still not there: >> >> methods := Object methodDict values. >> SystemNavigation default browseMessageList: methods name: 'Object methods' >> >> fails miserably.. >> but if i convert it to #methodReference, it works: >> >> methods := (Object methodDict values). >> methods := methods collect: #methodReference. >> SystemNavigation default browseMessageList: methods name: 'Object methods' >> >> and i feel like i was fooled: we replaced one wrapper - >> MethodDefinition (or what was that?) >> with another with just different name. But we still cannot use >> CompiledMethod as a model for lists >> etc.. >> so can someone enlighten me, what is then changed, except a name(s)? > > > I did it a long time ago in VisualWorks 3.0 (IIRC). Â See below. > >> >> I am still clueless, why system tools cannot speak directly with >> object(s) under the question, if necessary? > > > The wrapper is a pointer. Â If one redefines a method when recompiling then > the pointer refers to the current version of the method but a direct > reference to the method answers the old version. Â The direct reference > prevents the old version being garbage collected but the pointer does not. > Â For these reasons we use methodReference and not direct references. Â So the > use of pointers is necessary to make the tools work as expected. Â When > methods are selected in the method list browser tools, the tools show > current versions, not versions as of when they were opened. Â This is the > same as the system browser, which holds onto class names and selectors, not > on class objects and method objects. > > By the way, in the olden days the method list browsers worked with strings > that looked like 'Foo selector' and 'Foo class selector:' Â which were > pointers, but painful to parse to indirect to CompiledMethods. Â I added > MethodReference in VisualWorks to replace these large and inflexible strings > with explicit pointer objects. Â Looks like Squeak followed suit. > I know it. But the point is, that those tools are subscribed to system changes, and so, if listed method get changed or removed, the tool can update it's list accordingly, without a need to hold indirect pointer. > > As evidence of painful parsing here's code form the Smalltalk-80 > MethodListBrowser: > > MethodListBrowser methodsFor: 'method list' > methodName: selection > Â Â | aStream aSymbol | > Â Â methodName _ selection. > Â Â selection == nil ifTrue: [selector _ nil. ^ self textMode: > #unclassified]. > Â Â aStream _ ReadStream on: selection. > Â Â className _ (aStream upTo: $ ) asSymbol. > Â Â aSymbol _ (aStream upTo: $ ) asSymbol. > Â Â (meta _ (aSymbol == #class) & aStream atEnd not) ifTrue: > Â Â Â Â [aSymbol _ (aStream upTo: $ ) asSymbol]. > Â Â protocol _ self selectedClass organization categoryOfElement: aSymbol. > Â Â self selector: aSymbol > >> >> -- >> Best regards, >> Igor Stasenko. > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

June 18, 2012

Re: [Pharo-project] FileSystem and file extensions

by Igor Stasenko

yep. extension should be the thing after _last_ dot. On 18 June 2012 02:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Eliot Miranda-2 wrote >> >> Â Â #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: >> [:thing| thing extension] => #('' 'tar' 'gz' 'tar' 'gz') >> and >> Â Â #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: >> [:thing| thing extensions] => #(#() #('tar') #('gz' 'tar') #('tar' '1') >> #('gz' 'tar' '1')) >> or >> Â Â #('foo' 'foo.tar' 'foo.tar.gz' 'foo.1.tar' 'foo.1.tar.gz') collect: >> [:thing| thing extensions] => #(#() #('tar') #('tar' 'gz') #('1' 'tar') >> #('1' 'tar' 'gz')) >> > > Sounds good. > > -- > View this message in context: http://forum.world.st/FileSystem-and-file-extensions-tp4635256p4635293.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

June 18, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Igor Stasenko

and besides, concerning buggy, the tests which i implemented for ephemerons are green. It maybe, that tests are not fully cover the specs.. sure it can be possible. So if you have some more complex/tricky tests in mind, feel free to add them. -- Best regards, Igor Stasenko.

June 18, 2012