- Pharo-dev - lists.pharo.org

How to browse a given keymap category

by stepharo

Hi I wanted to fix https://pharo.fogbugz.com/default.asp?14845 Selecting a class and pressing command B+M raises an error so either we should check that the selected method is not nil (I do not like that much) or the key binding should not work on classes (preferred solution). buildBrowseShortcutsOn: aBuilder <keymap> (aBuilder shortcut: #browseSenders) category: #NautilusGlobalShortcuts default: $b command , $n command do: [:target | target browseSendersOfMessages ] description: 'Browse senders of the selected method'. (aBuilder shortcut: #browseClassRefs) category: #NautilusGlobalShortcuts default: $b command, $n command shift do: [ :target | target browseClassRefs ] description: 'Browse class references'. (aBuilder shortcut: #browseImplementors) category: #NautilusGlobalShortcuts default: $b command , $m command do: [:target | target browseMessages ] ^^^^^^^^^^^^^^^^^^^^^^^^^ description: 'Browse implementors of the selected method'. a "bad solution to my eye" is browseMessages self selectedMethod iifNil: [^ self]. <<<<< self browseMessagesFrom: self selectedMethod selector Now my question is then how can I find the different categories of bindings such as #NautilusGlobalShortCuts I tried to inspect a builder from the debugger but I got lost and should run to catch a train. Stef

Feb. 1, 2015

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

by Thierry Goubier

2015-02-01 11:02 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Thanks Thierry. But I don't have an answer for you. You might notice in > Pharo4MetaRepo it took me three goes to bump ConfigurationOfOSProcess from > 4.5.12 to 4.5.13 - my first such modification of a Configuration. (btw, I > tried using Versioneer but there was some error and I presumed (perhaps > wrongly) that its existing Configuration format might not be compatible > with Versioneer, so did it manually) > No problem. So far, what I have is that trying to load 4.5.13 of OSProcess loads 4.6.9 of CommandShell as a dependency and 4.6.9 loads back 4.5.12 of OSProcess... I'll have to try updating ConfigurationOfCommandShell as well. Thierry > > cheers -ben > > > On Sun, Feb 1, 2015 at 5:14 PM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> Oh, one more question: >> >> is there a need to bump the command shell version (currently 4.6.9) as >> well to get it to point to OSProcess 4.5.13? It's now pointing to 4.5.12. >> >> Thierry >> >> 2015-02-01 10:12 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> Hi Dave, Ben, >>> >>> I updated a bit the configuration of OSProcess and propagated it in the >>> three meta repositories (squeaksource, MetaRepoForPharo30, >>> MetaRepoForPharo40), but I also integrated a fix which is in the >>> squeaksource repository (by dkh) which restricts OSProcess to 4.5.8 on >>> Pharo2.x ? >>> >>> Thierry >>> >>> 2015-01-25 16:03 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: >>> >>>> On Sun, Jan 25, 2015 at 01:41:01PM +0800, Ben Coman wrote: >>>> > On Mon, Jan 12, 2015 at 6:10 AM, Thierry Goubier < >>>> thierry.goubier(a)gmail.com> wrote: >>>> > > >>>> > > 2015-01-11 20:42 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: >>>> > >> >>>> > >> I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the >>>> OSProcess >>>> > >> repository. An update to ConfigurationOfOSProcess will be needed to >>>> > >> get the latest version. >>>> > >>>> > Sorry for the delay getting back to this. I updated the >>>> Configuration and >>>> > tested it loads okay on latest Pharo. You can copy... >>>> > >>>> > ConfigurationOfOSProcess-BenComan.36 >>>> >>>> Done. >>>> >>>> Thanks Ben! >>>> >>>> Dave >>>> >>>> >>>> >>> >> >

Feb. 1, 2015

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

by Ben Coman

Thanks Thierry. But I don't have an answer for you. You might notice in Pharo4MetaRepo it took me three goes to bump ConfigurationOfOSProcess from 4.5.12 to 4.5.13 - my first such modification of a Configuration. (btw, I tried using Versioneer but there was some error and I presumed (perhaps wrongly) that its existing Configuration format might not be compatible with Versioneer, so did it manually) cheers -ben On Sun, Feb 1, 2015 at 5:14 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Oh, one more question: > > is there a need to bump the command shell version (currently 4.6.9) as > well to get it to point to OSProcess 4.5.13? It's now pointing to 4.5.12. > > Thierry > > 2015-02-01 10:12 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Hi Dave, Ben, >> >> I updated a bit the configuration of OSProcess and propagated it in the >> three meta repositories (squeaksource, MetaRepoForPharo30, >> MetaRepoForPharo40), but I also integrated a fix which is in the >> squeaksource repository (by dkh) which restricts OSProcess to 4.5.8 on >> Pharo2.x ? >> >> Thierry >> >> 2015-01-25 16:03 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: >> >>> On Sun, Jan 25, 2015 at 01:41:01PM +0800, Ben Coman wrote: >>> > On Mon, Jan 12, 2015 at 6:10 AM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> > > >>> > > 2015-01-11 20:42 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: >>> > >> >>> > >> I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess >>> > >> repository. An update to ConfigurationOfOSProcess will be needed to >>> > >> get the latest version. >>> > >>> > Sorry for the delay getting back to this. I updated the Configuration >>> and >>> > tested it loads okay on latest Pharo. You can copy... >>> > >>> > ConfigurationOfOSProcess-BenComan.36 >>> >>> Done. >>> >>> Thanks Ben! >>> >>> Dave >>> >>> >>> >> >

Feb. 1, 2015

Proposal for LiteralArray class

by Ben Coman

Looking into Image locking problems [1] caused by a recursive array such as this... literalArray := #( 1 2 3 ). literalArray at: 3 put: literalArray. I find that "literalArray printString" locks the image due to Array>>printOn: use of the recursive #shouldBePrintedAsLiteral method. Now its implementation is identical to #isLiteral and indeed "literalArray isLiteral" also locks the Image. So comparing implementors of #isLiteral... Object>>isLiteral ^false Boolean>>isLiteral ^true Character>>isLiteral ^true Integer>>isLiteral ^true String>>isLiteral ^true UndefinedObject>>isLiteral ^true ByteArray>>isLiteral ^self class == ByteArray Float>>isLiteral ^self isFinite "^(self - self) = 0.0" ScaledDecimal>>isLiteral ^denominator = 1 or: [(10 raisedTo: scale)\\denominator = 0] Array>>isLiteral ^self class == Array and: [self allSatisfy: [:each | each isLiteral]] ...I find most are very basic (might even say deterministic), with the recursion of Array>>isLiteral seeming an annomaly. Also, the big IF condition in Array>>printOn: smells like a design decision being made at runtime (Valloud AMCOS p12). Array>>printOn: aStream self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: aStream. ^ self]. self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: aStream. ^ self]. super printOn: aStream Flipping between two printString formats seems like selecting between two class types. Indeed, if we had a LiteralArray class, there would be no need for its printOn: to recursively search to determine its form, thus allowing #printStringLimitedTo: to do its thing to protect against infinite recursion. Also, instead of a recursive Array>>isLiteral we'd have something like LiteralArray>>isLiteral ^true Array>>isLiteral ^false which seems to align much better with the pattern of the other #isLiteral implementors. I notice there is both RBArrayNode and RBLiteralArrayNode. So what are the wider concerns that might apply? (In particular, I'm not sure how the #isSelfEvaluating (which is also recursive) fits into the big picture) cheers -ben [1] https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg25156.html

Feb. 1, 2015

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

by Thierry Goubier

Oh, one more question: is there a need to bump the command shell version (currently 4.6.9) as well to get it to point to OSProcess 4.5.13? It's now pointing to 4.5.12. Thierry 2015-02-01 10:12 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Dave, Ben, > > I updated a bit the configuration of OSProcess and propagated it in the > three meta repositories (squeaksource, MetaRepoForPharo30, > MetaRepoForPharo40), but I also integrated a fix which is in the > squeaksource repository (by dkh) which restricts OSProcess to 4.5.8 on > Pharo2.x ? > > Thierry > > 2015-01-25 16:03 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > >> On Sun, Jan 25, 2015 at 01:41:01PM +0800, Ben Coman wrote: >> > On Mon, Jan 12, 2015 at 6:10 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> > > >> > > 2015-01-11 20:42 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: >> > >> >> > >> I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess >> > >> repository. An update to ConfigurationOfOSProcess will be needed to >> > >> get the latest version. >> > >> > Sorry for the delay getting back to this. I updated the Configuration >> and >> > tested it loads okay on latest Pharo. You can copy... >> > >> > ConfigurationOfOSProcess-BenComan.36 >> >> Done. >> >> Thanks Ben! >> >> Dave >> >> >> >

Feb. 1, 2015

Re: [Pharo-dev] [squeak-dev] OSProcess stdErr issue on Windows

by Thierry Goubier

Hi Dave, Ben, I updated a bit the configuration of OSProcess and propagated it in the three meta repositories (squeaksource, MetaRepoForPharo30, MetaRepoForPharo40), but I also integrated a fix which is in the squeaksource repository (by dkh) which restricts OSProcess to 4.5.8 on Pharo2.x ? Thierry 2015-01-25 16:03 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > On Sun, Jan 25, 2015 at 01:41:01PM +0800, Ben Coman wrote: > > On Mon, Jan 12, 2015 at 6:10 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > > > 2015-01-11 20:42 GMT+01:00 David T. Lewis <lewis(a)mail.msen.com>: > > >> > > >> I copied ConfigurationOfOSProcess-ThierryGoubier.33 to the OSProcess > > >> repository. An update to ConfigurationOfOSProcess will be needed to > > >> get the latest version. > > > > Sorry for the delay getting back to this. I updated the Configuration > and > > tested it loads okay on latest Pharo. You can copy... > > > > ConfigurationOfOSProcess-BenComan.36 > > Done. > > Thanks Ben! > > Dave > > >

Feb. 1, 2015

Re: [Pharo-dev] Anonymous classes should be browseable

by Thierry Goubier

Hi Hernan, Stef, 2015-02-01 9:14 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Hi Stef > > 2015-01-31 6:13 GMT-03:00 stepharo <stepharo(a)free.fr>: > > Now may be the anonymous classes you create should return a dummy package. >> >> > I think that would be a good solution. > > > Current RPackageOrganizer has a pseudo package which is _UnpackagedPackage. Why not use this one? Thierry

Feb. 1, 2015

Re: [Pharo-dev] Tools for automatic recognition of Design Patterns

by HernÃ¡n Morales Durand

Hi Nevena, I don't know of such tool for Smalltalk. But if you feel inspired to build something you could check : "DPB: A Benchmark for Design Pattern Detection Tools" which is a good review. Cheers, HernÃ¡n 2015-01-30 13:07 GMT-03:00 Nevena Milojkovic <nevena(a)iam.unibe.ch>: > Hi, > > Can anyone suggest me tool for automatic design patterns detection in > Smalltalk? > > Cheers, > Nevena Milojkovic > > > ââââââââ > Nevena Milojkovic > Research assistant > Software Composition Group > Institute of Computer Science and Applied Mathematics > University of Bern > > email: nevena(a)iam.unibe.ch > office phone: +41 (0)31 511 7639 > webpage: http://scg.unibe.ch/staff/Milojkovic > > > > > > >

Feb. 1, 2015

Re: [Pharo-dev] Anonymous classes should be browseable

by HernÃ¡n Morales Durand

Hi Stef 2015-01-31 6:13 GMT-03:00 stepharo <stepharo(a)free.fr>: > Hernan > > I would really love that you think twice before pressing the button sent > mail. Else I will finish to put > you on my kill list and I will be sad but so far I see from you often > frustration. Could you try to be positive? > You will see as a state of mind this is so much more pleasant. > > I will reply to this by private e-mail. > There are many aspects of Nautilus that I do not like but there are even > more aspect about the old browser > and OB that I hate! And as you know doing is difficult. > You know I wrote several OB browsers so I know OB had problems. OB was not *that* bad. The old browser was. But I just spent too much energy on OB. > So what is the point. How many anonymous classes did I created over the > last five year: none. > We have different POV and use cases. > What do we do with class side? packages? > > Why do you expect that a tools supporting the Smalltalk metaclass model > should suport Anonymous classes? > Because tools should be flexible enough to support other similar artifacts (like anonymous classes) at least without too much modification. How we can evolve if tools are not adaptable? > BTW I'm the guy in Squeak that fixed long long long time ago Behavior new > new (So I know a bit on anonymous classes). > When I used anonymous classes > I did it to support instance based programming. So should I expect my hack > to work with normal browser? > > When I think about halting SystemWindow>>delete automatically I miss the instance-based behavior. I do not consider it a hack. Now Glamour could be a solution? It would support building tools for all the other experiments (MethodWrappers, Ghosts, Multi-Methods, Wide Classes, etc)? Now may be the anonymous classes you create should return a dummy package. > > I think that would be a good solution. > Stef > > Le 26/1/15 07:44, HernÃ¡n Morales Durand a Ã©crit : > > I want to discuss case 14789 (https://pharo.fogbugz.com/f/ >> cases/14789/Nautilus-assumes-a-class-always-understand-package) because >> a class should be browseable even without a definition. Anonymous classes >> are still classes. >> >> If Nautilus project cannot deal with the whole Smalltalk power then it is >> poorly designed and I wonder what's the advantage over the old >> OmniBrowser... >> >> HernÃ¡n >> >> > >

Feb. 1, 2015

changing Spec tab after opening throws MNU

by Peter UhnÃ¡k

Changing Tab name after the UI has been build fails, since it tries to set the label to MorphicTabAdapter instead of Tab. I could fix it by changing in TabModel>>initialize label whenChangedDo: [ :new | self widget ifNotNil: [ :w | w label: new ] ]. to label whenChangedDo: [ :new | self widget ifNotNil: [ :w | w widget label: new ] ]. but setting it this way feels weird (not mentioning Demeter). Maybe the MorphicTabAdapter should delegate it? Apart from label this also applies to icon and most likely to all other stuff (morph, retrievingBlock, ...) Peter

Jan. 31, 2015