October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to find methods sent but not implemented?

by StÃ©phane Ducasse

unsentMessages or something like that is available. Stef On Oct 25, 2008, at 12:49 PM, Oscar Nierstrasz wrote: > > BTW, it would be cool to check this in the Pharo image. > > What would be the Smalltalk expression to pop open a browser on all > methods that send messages that are not implemented? (Or simply to > return a list of those messages?) > > - on > > On Oct 25, 2008, at 12:35, Adrian Lienhard wrote: > >> Probably, "literals do:" instead of "literalsDo:" will work. >> (Normally, methods to be removed should first be deprecated, which >> apparently was not done in this case.) >> >> Adrian >> >> On Oct 25, 2008, at 12:22 , Oscar Nierstrasz wrote: >> >>> >>> Hi, >>> >>> I was trying out the refactoring engine, and tried to run the code >>> critic. >>> >>> I got a message not understood in >>> SmalllintContext>>addLiteralsFor: which sends literalsDo: to its >>> argument aCompiledMethod. >>> >>> This appears to be the only method in the Pharo-dev image that >>> sends this msg. >>> >>> Any ida what the fix should be? >>> >>> - on >>> >>> >>> _______________________________________________ >>> 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 >

Oct. 25, 2008

[Pharo-project] How to find methods sent but not implemented?

by Oscar Nierstrasz

BTW, it would be cool to check this in the Pharo image. What would be the Smalltalk expression to pop open a browser on all methods that send messages that are not implemented? (Or simply to return a list of those messages?) - on On Oct 25, 2008, at 12:35, Adrian Lienhard wrote: > Probably, "literals do:" instead of "literalsDo:" will work. > (Normally, methods to be removed should first be deprecated, which > apparently was not done in this case.) > > Adrian > > On Oct 25, 2008, at 12:22 , Oscar Nierstrasz wrote: > >> >> Hi, >> >> I was trying out the refactoring engine, and tried to run the code >> critic. >> >> I got a message not understood in SmalllintContext>>addLiteralsFor: >> which sends literalsDo: to its argument aCompiledMethod. >> >> This appears to be the only method in the Pharo-dev image that >> sends this msg. >> >> Any ida what the fix should be? >> >> - on >> >> >> _______________________________________________ >> 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

Oct. 25, 2008

Re: [Pharo-project] SmallLint broken -- no literalsDo: in CompiledMethod ?

by Oscar Nierstrasz

Right, thanks. In an older Squeak image I find: CompiledMethod>>literalsDo: aOneArgumentBlock ^self literals do:aOneArgumentBlock. - on On Oct 25, 2008, at 12:35, Adrian Lienhard wrote: > Probably, "literals do:" instead of "literalsDo:" will work. > (Normally, methods to be removed should first be deprecated, which > apparently was not done in this case.) > > Adrian > > On Oct 25, 2008, at 12:22 , Oscar Nierstrasz wrote: > >> >> Hi, >> >> I was trying out the refactoring engine, and tried to run the code >> critic. >> >> I got a message not understood in SmalllintContext>>addLiteralsFor: >> which sends literalsDo: to its argument aCompiledMethod. >> >> This appears to be the only method in the Pharo-dev image that >> sends this msg. >> >> Any ida what the fix should be? >> >> - on >> >> >> _______________________________________________ >> 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

Oct. 25, 2008

Re: [Pharo-project] SmallLint broken -- no literalsDo: in CompiledMethod ?

by Adrian Lienhard

Probably, "literals do:" instead of "literalsDo:" will work. (Normally, methods to be removed should first be deprecated, which apparently was not done in this case.) Adrian On Oct 25, 2008, at 12:22 , Oscar Nierstrasz wrote: > > Hi, > > I was trying out the refactoring engine, and tried to run the code > critic. > > I got a message not understood in SmalllintContext>>addLiteralsFor: > which sends literalsDo: to its argument aCompiledMethod. > > This appears to be the only method in the Pharo-dev image that sends > this msg. > > Any ida what the fix should be? > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2008

[Pharo-project] SmallLint broken -- no literalsDo: in CompiledMethod ?

by Oscar Nierstrasz

Hi, I was trying out the refactoring engine, and tried to run the code critic. I got a message not understood in SmalllintContext>>addLiteralsFor: which sends literalsDo: to its argument aCompiledMethod. This appears to be the only method in the Pharo-dev image that sends this msg. Any ida what the fix should be? - on

Oct. 25, 2008

[Pharo-project] Fwd: [Etoys] Fully Relicensed version of mainstream Squeak

by StÃ©phane Ducasse

Begin forwarded message: > From: Yoshiki Ohshima <yoshiki(a)vpri.org> > Date: October 23, 2008 7:04:54 PM CEDT > To: stephane ducasse <stephane.ducasse(a)free.fr> > Cc: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: Re: [Etoys] Fully Relicensed version of mainstream Squeak > > At Thu, 23 Oct 2008 15:11:04 +0200, > stephane ducasse wrote: >> >> I could not see the authorship2 code. >> Did you send it? > > No, but I uploaded code to SqueakSource. > > http://www.squeaksource.com/MethodAuthorship/MethodAuthorship-yo.1.mcz > > is the data collection mechansim (I forgot to set the ancestor so the > version number of the mcz package is wrong) and the Seaside code is > > http://www.squeaksource.com/AuthorshipViewer.html > > -- Yoshiki >

Oct. 25, 2008

Re: [Pharo-project] facetious Splitter

by StÃ©phane Ducasse

Yes this is bug I introduced when removing etoy and that gary fixed but I harvested part of the solution. The problem was splitter used x and y of morphs and only them so gary replaced that with left right but I should harvest bottomBoundary from UIEnhancements/ polymorphWidgets.latest Now I got some problems to see what I have to extract exactly. If you get a list that is working I would be happy. gary said "More to the point... the overrides for bottomBoundary etc. are missing in ProportionalSplitterMorph." On Oct 25, 2008, at 12:44 AM, nicolas cellier wrote: > Recipe for a nice scrambling of layouts in Pharo 10102: > > open a FileList; > single click the splitter above text; > you should see an annoying mess in the pane layouts. > > This happens with some other tools (like FileContentsBrowser). > Removing the list of files morph with the halos, I discovered a > hidden splitter under top buttons. > You can see the mess in Pharo when acting on these two splitters. > Note that 3.9 ad 3.10.2 images have the hidden splitter too, but the > splitters behaves better. > So it has to be a Pharo change. > Unfortunately morphs are hard to debug! > It would probably be easier to trace recent Morphic changes. Any clue? > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2008

[Pharo-project] facetious Splitter

by nicolas cellier

Recipe for a nice scrambling of layouts in Pharo 10102: open a FileList; single click the splitter above text; you should see an annoying mess in the pane layouts. This happens with some other tools (like FileContentsBrowser). Removing the list of files morph with the halos, I discovered a hidden splitter under top buttons. You can see the mess in Pharo when acting on these two splitters. Note that 3.9 ad 3.10.2 images have the hidden splitter too, but the splitters behaves better. So it has to be a Pharo change. Unfortunately morphs are hard to debug! It would probably be easier to trace recent Morphic changes. Any clue? Nicolas

Oct. 24, 2008

Re: [Pharo-project] Re: [Pkg] Installer: Installer-Core-AlexandreBergel.244.mcz

by Alexandre Bergel

Hi Matthew, You're right. We were unaware of this. Cheers, Alexandre On 23 Oct 2008, at 18:19, Matthew Fulmer wrote: > Hi alex. I don't understand the purpose of this change. > Installing a mc package already does some pretty sophisticated > pattern matching in the method InstallerMonticello>>mcThing, > allowing you to install the latest version, the latest version > from a particular author, or a specific version. Was there a bug > in that code? Were you unaware of it? I don't understand why > this is needed. > > On Thu, Oct 23, 2008 at 05:53:06PM +0200, squeak-dev-noreply(a)lists.squeakfoundation.org > wrote: >> A new version of Installer-Core was added to project Installer: >> http://www.squeaksource.com/Installer/Installer-Core-AlexandreBergel.244.mcz >> >> ==================== Summary ==================== >> >> Name: Installer-Core-AlexandreBergel.244 >> Author: AlexandreBergel >> Time: 23 October 2008, 5:53:02 pm >> UUID: 2080ff3e-6f59-4f15-91c2-ff07703cbccf >> Ancestors: Installer-Core-kph.243 >> >> added #installLatest: method to Installer >> >> =============== Diff against Installer-Core-kph.243 =============== >> >> Item was added: >> + ----- Method: Installer>>installLatest: (in category >> 'instanciation') ----- >> + installLatest: packageNameCollectionOrDetectBlock >> + | versions | >> + self addPackage: packageNameCollectionOrDetectBlock. >> + versions := (self availablePackages select: [:e | e beginsWith: >> packageNameCollectionOrDetectBlock]) asSortedCollection: [:a :b | >> + [(a findBetweenSubStrs: #($.)) allButLast last >> asInteger > (b findBetweenSubStrs: #($.)) allButLast last asInteger] >> + on: Error do: [:ex | false]]. >> + versions isEmpty ifTrue: [^ self]. >> + self packages removeLast. >> + self addPackage: versions first. >> + >> + ^ self install! >> > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 24, 2008

[Pharo-project] Author identification :)

by StÃ©phane Ducasse

A while ago I hacked with doru an author map. something that would be good to have with mondrian in pharo to check the licensing issues. Here you see the classes and their methods and a color per author. :)

Oct. 24, 2008