- Pharo-dev - lists.pharo.org

[Pharo-project] ANN: Periscope - Universal Navigation Sidebar for Nautilus

by Pavel Krivanek

Hi all, I want to introduce a tool that, as I hope, may improve your Smalltalk browsing experience. It is named Periscope and it is an universal navigation sidebar for Nautilus that is common for all Nautilus windows. It is snapped to the display edge as the topmost window. Periscope uses a system of plugins written using Spec you may easily improve and adapt it for your needs. Currently it contains only three plugins created mainly for the demonstration. It is: - Tools starters plugin - Bookmarks plugin - Behavior references plugin that show class or trait references of the currently browsed class Of course I can imagine a wide side of next plugins like Spotlight plugin, instance variables plugin, method versions plugin, senders etc. Really cool would be plugins that would show additional information while writing code. Please feel free to improve Periscope. I hope Ben will come with a lot of new ideas and improvements. To test Periscope take some recent 2.0 image and evaluate: Gofer new smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; package: 'Periscope'; load. Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} ...then open Nautilus or open Periscope from the tools menu. Chees, -- Pavel

Aug. 19, 2012

[Pharo-project] a thought for Finder

by Ben Coman

Just a thought on my personal usage of Finder (in Pharo 1.4). I find the majority of my use of the <Choose Packages> button in Finder is continually filtering on the same subset of packages. This subset may be different for different contexts that I am working in, but within each context it is fairly consistent. For instance, if I'm looking at the internals of Alexandre Bergel's Roassal package, then I am always choosing all of those packages. Further, I never seem to find myself using the <All packages> button. I seem to always just open a new Finder since I usually haven't finished with the "Roassal" one and this is quicker than later again filtering on "Roassal." My proposal is that the two buttons <Choose Packages> and <All Packages> be replaced by a pull down list for which the first two items would be the same as the buttons it replaces, plus my saved "context package filters". cheers -ben

Aug. 19, 2012

Re: [Pharo-project] 'self halt' safety net

by Ben Coman

Sean P. DeNigris wrote: > Igor Stasenko wrote > >> in pharo you can use >> Halt now. >> which is imo the right way to do it.. >> >> but i so get used to type 'self halt' .. its hard to get rid of bad >> habits. :) >> >> > > One little carrot to use "Halt now." is that it opens the debugger on the > method with the halt in it instead of on Object>>halt, where you go to be > punished for using "self halt" ;) I just found that out because after > fighting to remove "self halt", I didn't get rid of my bad habit either, ha > ha > > - S > > Except that in Pharo 1.4 the 'Halt now' line is not highlighted upon entering the debugger. Probably not required to be fixed for 1.4 but perhaps could be checked for 2.0. cheers -ben

Aug. 19, 2012

Re: [Pharo-project] numLiterals > 0 is that possible?

by StÃ©phane Ducasse

Mariano don't you like all these ifNil around in caseâ¦ and sometimes this funny logic because one object is missing. ;) So the if is not brokenâ¦ is a tragedy: you know the story where at the end everybody die = no future. We should for example, replace all the MC string concat by an object like in Squeak. Now to answer your question I think that the answer is not about if this is broken or not but what scenario does it support. So do we have cases where we want to get the class of a method that is not bound to a class? When methodClass is accessed? Stef > Replacing something is not the same as removing, I agree. But if the hacks or workaround were for a particular very good reason and some point in time, with certain image and libraries, why to keep it NOW in Pharo? Say ReferenceStream had some hacks around the system. Now we have removed it. Why should we keep the hacks in Pharo itself? No problem if someone wants to install ReferenceStream again in Pharo. But if you do so, bring with you all the hacks/workarounds to make it work. We will not keep the garbage in the main image. > Take this very example of #methodClass. Why would be need to keep the "self literals > 0" ? (if the reasons are what Eliot said). If then Newspeak wants to be built on top of Pharo, great, bring the changes (like this one) with you. > > Finally, I am not afraid/shame of rollbacking. I prefer to clean something and then discover that it was actually needed than do nothing. In fact, I would be able to document why it was needed ;) > > > > frank > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 18, 2012

Re: [Pharo-project] numLiterals > 0 is that possible?

by Mariano Martinez Peck

On Sat, Aug 18, 2012 at 1:02 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 18 August 2012 11:57, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > On Sat, Aug 18, 2012 at 12:33 PM, Camillo Bruni <camillobruni(a)gmail.com> > > wrote: > >> > >> > >> On 2012-08-17, at 22:50, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> > >> > On Fri, Aug 17, 2012 at 1:42 PM, Mariano Martinez Peck < > >> > marianopeck(a)gmail.com> wrote: > >> > > >> >> Hi guys. Right now we have > >> >> > >> >> methodClass > >> >> "answer the class that I am installed in" > >> >> ^self numLiterals > 0 > >> >> ifTrue: [ (self literalAt: self numLiterals) value ] > >> >> ifFalse: [ nil ] > >> >> > >> >> But of course my image has no method with 0 literals: > >> >> > >> >> (CompiledMethod allInstances select: [:each | each numLiterals = 0 ]) > >> >> size > >> >> -> 0 > >> >> > >> >> So...can this really happen? or I can just remove the if ? > >> >> > >> > > >> > Yes it could happen. For example, i the Newspeak implementation above > >> > Squeak these is a collection of inst-var accessors that are shared > >> > through > >> > all Newspeak classes in the system. > >> > >> so it will never happen in Pharo right? > >> > >> > These have a nil methodClass. If one > >> > wanted to save space they could have no methodClass instead of nil in > >> > the > >> > methodClass slot. (Note that the above works for these since nil > value > >> > = > >> > value). So IMO its a harmless piece of defensice programming. > IIABDFI > >> > (If > >> > it ain't broke don't fix it). > >> > >> again, this is not pharo mentality... > >> > > > > Yes, that was my point. Our system is full of "xx > yyy ifZZ:" , > > "isEmptyOrNil ifZZ:", "ifNil: " blah blah blah. I am sure lost of them > were > > workaround introduced to solve a problem in some point in time in the > last > > 20 years. And not only at a point in time, but also together with an > > specific image version, set of libraries, vm, etc. I am also sure lots of > > them may not be necessary anymore after so many cleanings and library > > replacement. Hence, my question. > > > > Finally, if Pharo would have followed the IIABDFI (If it ain't broke > don't > > fix it) then we would still have ReferenceStream, ImageSegment, > HTTPSocket, > > Preferences, FileDirectory, SystemChangeNotifier, and many others around > > (of course, someone could consider them as broken). > > Replacing something is not the same as removing things you think will > never happen. Oftentimes, yes, those crazy bits of nonsense were added > a decade ago _for very good reason_, even if the committe failed his > good citizenry test by documenting it. You can get yourself into very > nasty trouble by randomly fixing things that aren't broken. Especially > if you're not quite sure what the crazy nonsense is for. > Replacing something is not the same as removing, I agree. But if the hacks or workaround were for a particular very good reason and some point in time, with certain image and libraries, why to keep it NOW in Pharo? Say ReferenceStream had some hacks around the system. Now we have removed it. Why should we keep the hacks in Pharo itself? No problem if someone wants to install ReferenceStream again in Pharo. But if you do so, bring with you all the hacks/workarounds to make it work. We will not keep the garbage in the main image. Take this very example of #methodClass. Why would be need to keep the "self literals > 0" ? (if the reasons are what Eliot said). If then Newspeak wants to be built on top of Pharo, great, bring the changes (like this one) with you. Finally, I am not afraid/shame of rollbacking. I prefer to clean something and then discover that it was actually needed than do nothing. In fact, I would be able to document why it was needed ;) > > frank > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 18, 2012

Re: [Pharo-project] numLiterals > 0 is that possible?

by Frank Shearar

On 18 August 2012 11:57, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sat, Aug 18, 2012 at 12:33 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: >> >> >> On 2012-08-17, at 22:50, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> > On Fri, Aug 17, 2012 at 1:42 PM, Mariano Martinez Peck < >> > marianopeck(a)gmail.com> wrote: >> > >> >> Hi guys. Right now we have >> >> >> >> methodClass >> >> "answer the class that I am installed in" >> >> ^self numLiterals > 0 >> >> ifTrue: [ (self literalAt: self numLiterals) value ] >> >> ifFalse: [ nil ] >> >> >> >> But of course my image has no method with 0 literals: >> >> >> >> (CompiledMethod allInstances select: [:each | each numLiterals = 0 ]) >> >> size >> >> -> 0 >> >> >> >> So...can this really happen? or I can just remove the if ? >> >> >> > >> > Yes it could happen. For example, i the Newspeak implementation above >> > Squeak these is a collection of inst-var accessors that are shared >> > through >> > all Newspeak classes in the system. >> >> so it will never happen in Pharo right? >> >> > These have a nil methodClass. If one >> > wanted to save space they could have no methodClass instead of nil in >> > the >> > methodClass slot. (Note that the above works for these since nil value >> > = >> > value). So IMO its a harmless piece of defensice programming. IIABDFI >> > (If >> > it ain't broke don't fix it). >> >> again, this is not pharo mentality... >> > > Yes, that was my point. Our system is full of "xx > yyy ifZZ:" , > "isEmptyOrNil ifZZ:", "ifNil: " blah blah blah. I am sure lost of them were > workaround introduced to solve a problem in some point in time in the last > 20 years. And not only at a point in time, but also together with an > specific image version, set of libraries, vm, etc. I am also sure lots of > them may not be necessary anymore after so many cleanings and library > replacement. Hence, my question. > > Finally, if Pharo would have followed the IIABDFI (If it ain't broke don't > fix it) then we would still have ReferenceStream, ImageSegment, HTTPSocket, > Preferences, FileDirectory, SystemChangeNotifier, and many others around > (of course, someone could consider them as broken). Replacing something is not the same as removing things you think will never happen. Oftentimes, yes, those crazy bits of nonsense were added a decade ago _for very good reason_, even if the committe failed his good citizenry test by documenting it. You can get yourself into very nasty trouble by randomly fixing things that aren't broken. Especially if you're not quite sure what the crazy nonsense is for. frank > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 18, 2012

Re: [Pharo-project] numLiterals > 0 is that possible?

by Mariano Martinez Peck

On Sat, Aug 18, 2012 at 12:33 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-08-17, at 22:50, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Aug 17, 2012 at 1:42 PM, Mariano Martinez Peck < > > marianopeck(a)gmail.com> wrote: > > > >> Hi guys. Right now we have > >> > >> methodClass > >> "answer the class that I am installed in" > >> ^self numLiterals > 0 > >> ifTrue: [ (self literalAt: self numLiterals) value ] > >> ifFalse: [ nil ] > >> > >> But of course my image has no method with 0 literals: > >> > >> (CompiledMethod allInstances select: [:each | each numLiterals = 0 ]) > size > >> -> 0 > >> > >> So...can this really happen? or I can just remove the if ? > >> > > > > Yes it could happen. For example, i the Newspeak implementation above > > Squeak these is a collection of inst-var accessors that are shared > through > > all Newspeak classes in the system. > > so it will never happen in Pharo right? > > > These have a nil methodClass. If one > > wanted to save space they could have no methodClass instead of nil in the > > methodClass slot. (Note that the above works for these since nil value = > > value). So IMO its a harmless piece of defensice programming. IIABDFI > (If > > it ain't broke don't fix it). > > again, this is not pharo mentality... > > Yes, that was my point. Our system is full of "xx > yyy ifZZ:" , "isEmptyOrNil ifZZ:", "ifNil: " blah blah blah. I am sure lost of them were workaround introduced to solve a problem in some point in time in the last 20 years. And not only at a point in time, but also together with an specific image version, set of libraries, vm, etc. I am also sure lots of them may not be necessary anymore after so many cleanings and library replacement. Hence, my question. Finally, if Pharo would have followed the IIABDFI (If it ain't broke don't fix it) then we would still have ReferenceStream, ImageSegment, HTTPSocket, Preferences, FileDirectory, SystemChangeNotifier, and many others around (of course, someone could consider them as broken). -- Mariano http://marianopeck.wordpress.com

Aug. 18, 2012

Re: [Pharo-project] numLiterals > 0 is that possible?

by Camillo Bruni

On 2012-08-17, at 22:50, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > On Fri, Aug 17, 2012 at 1:42 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi guys. Right now we have >> >> methodClass >> "answer the class that I am installed in" >> ^self numLiterals > 0 >> ifTrue: [ (self literalAt: self numLiterals) value ] >> ifFalse: [ nil ] >> >> But of course my image has no method with 0 literals: >> >> (CompiledMethod allInstances select: [:each | each numLiterals = 0 ]) size >> -> 0 >> >> So...can this really happen? or I can just remove the if ? >> > > Yes it could happen. For example, i the Newspeak implementation above > Squeak these is a collection of inst-var accessors that are shared through > all Newspeak classes in the system. so it will never happen in Pharo right? > These have a nil methodClass. If one > wanted to save space they could have no methodClass instead of nil in the > methodClass slot. (Note that the above works for these since nil value = > value). So IMO its a harmless piece of defensice programming. IIABDFI (If > it ain't broke don't fix it). again, this is not pharo mentality...

Aug. 18, 2012

Re: [Pharo-project] numLiterals > 0 is that possible?

by Eliot Miranda

On Fri, Aug 17, 2012 at 1:42 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. Right now we have > > methodClass > "answer the class that I am installed in" > ^self numLiterals > 0 > ifTrue: [ (self literalAt: self numLiterals) value ] > ifFalse: [ nil ] > > But of course my image has no method with 0 literals: > > (CompiledMethod allInstances select: [:each | each numLiterals = 0 ]) size > -> 0 > > So...can this really happen? or I can just remove the if ? > Yes it could happen. For example, i the Newspeak implementation above Squeak these is a collection of inst-var accessors that are shared through all Newspeak classes in the system. These have a nil methodClass. If one wanted to save space they could have no methodClass instead of nil in the methodClass slot. (Note that the above works for these since nil value = value). So IMO its a harmless piece of defensice programming. IIABDFI (If it ain't broke don't fix it). > > thanks > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Aug. 17, 2012

[Pharo-project] numLiterals > 0 is that possible?

by Mariano Martinez Peck

Hi guys. Right now we have methodClass "answer the class that I am installed in" ^self numLiterals > 0 ifTrue: [ (self literalAt: self numLiterals) value ] ifFalse: [ nil ] But of course my image has no method with 0 literals: (CompiledMethod allInstances select: [:each | each numLiterals = 0 ]) size -> 0 So...can this really happen? or I can just remove the if ? thanks -- Mariano http://marianopeck.wordpress.com

Aug. 17, 2012