February 2015 - Pharo-dev - lists.pharo.org

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