September 2013 - Pharo-dev - lists.pharo.org

[update 3.0] #30368

by Marcus Denker

30368 ----- 11530 AbstractNautilusUI >> categorizeAllUncategorizedMethods broken https://pharo.fogbugz.com/f/cases/11530 11497 pharo CI.image --list shows empty entry for default command line handler https://pharo.fogbugz.com/f/cases/11497 11528 Harden FileDirectoryWrapper https://pharo.fogbugz.com/f/cases/11528 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-MarcusDenker.531.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.86.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.…

Sept. 5, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion

Sept. 5, 2013

[update 3.0] #30367

by Marcus Denker

30367 ----- 11502 Override Class >> #setName: https://pharo.fogbugz.com/f/cases/11502 10548 All system processes should have proper names https://pharo.fogbugz.com/f/cases/10548 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1234.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.9… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1592.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Weak-MarcusDenker…

Sept. 5, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by GÃ¶ran Krampe

On 09/05/2013 05:01 AM, David T. Lewis wrote: > On Wed, Sep 04, 2013 at 08:38:04AM +0200, Marcus Denker wrote: >> >> Why do you need to support Squeak 3.8? This is how many years old? >> >> I really do not understand this idea to be compatible to all old versions ever. >> > > I do not think that there is any right or wrong answer to this, it is > perhaps a matter of personal perspective. For me, much of my professional > experience is related to supporting manufacturing operations for a large > commercial company. In this environment, the ability to engineer solutions > to new problems without disrupting existing operations is critical. To > me, a failure related to software changes is not just a red mark on a > unit test, it is a significant emotional event if I cause a manufacturing > plant to stop production (thankfully this has rarely happened in my career > so far, knock wood). > > So maybe this makes me "conservative", but from my point of view the ability > to deliver future versions of software that work without breaking older > versions is a matter of good engineering discipline, and I stand by that > as a matter of principle. This is a very good principle :). As an example, at 3DICC we are currently on Squeak4.1, but I think it wasn't that long ago that it was 3.8 based. Of course, all things come to an end. But with larger systems the life cycles are often unbelievably long. regards, GÃ¶ran

Sept. 5, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by David T. Lewis

On Wed, Sep 04, 2013 at 08:38:04AM +0200, Marcus Denker wrote: > > Why do you need to support Squeak 3.8? This is how many years old? > > I really do not understand this idea to be compatible to all old versions ever. > I do not think that there is any right or wrong answer to this, it is perhaps a matter of personal perspective. For me, much of my professional experience is related to supporting manufacturing operations for a large commercial company. In this environment, the ability to engineer solutions to new problems without disrupting existing operations is critical. To me, a failure related to software changes is not just a red mark on a unit test, it is a significant emotional event if I cause a manufacturing plant to stop production (thankfully this has rarely happened in my career so far, knock wood). So maybe this makes me "conservative", but from my point of view the ability to deliver future versions of software that work without breaking older versions is a matter of good engineering discipline, and I stand by that as a matter of principle. Dave

Sept. 5, 2013

Re: [Pharo-dev] OSProcess for Pharo3.0

by David T. Lewis

On Wed, Sep 04, 2013 at 02:17:29PM +0200, Marcus Denker wrote: > > On Sep 4, 2013, at 2:13 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > On Tue, Sep 03, 2013 at 10:51:33PM -0400, David T. Lewis wrote: > >> On Tue, Sep 03, 2013 at 01:48:46PM +0200, Goubier Thierry wrote: > >>> > >>> Le 03/09/2013 13:36, David T. Lewis a ?crit : > >>>> > >>>> Can you post the method here first? I'd like to check it on some Squeak > >>>> images > >>>> before it goes into the repository. > >>> > >>> Here it is (at least an example): > >>> > >>> in OSProcess class > >>> > >>> isPharo3AndLater > >>> "Test if we are on Pharo 3.0" > >>> > >>> ^ (Smalltalk classNamed: 'SystemVersion') > >>> ifNil: [ false ] > >>> ifNotNil: [ :v | v current type = 'Pharo' and: [ v current > >>> major >= 3 ] ] > >> > >> The idea is right, but the details can be a PITA ;-) > >> > >> - In Squeak trunk, class SystemVersion exists. But it does not understand #type, so this fails at runtime. > >> > >> - There are no implementors of #major in Squeak (but this can be rewritten using #perform:). > >> > >> - In Squeak 3.8, #ifNil:ifNotNil: requires a block with no arguments. > >> > >> I did not check the other Pharo versions. > >> > >> Something like this might work: > >> > >> isPharo3AndLater > >> Smalltalk > >> at: #SystemVersion > >> ifPresent: [:cls | ((cls canUnderstand: #type) and: [ cls canUnderstand: #major ]) > >> ifTrue: [^ cls current type = 'Pharo' and: [ cls current major >= 3 ]]]. > >> ^false > >> > > > > > > I am also checking the platform subtype implementation (OSProcess platformSubtype). > > > > In Pharo: > > > > Smalltalk os subtype ==> 'i686' > > > > This reflects the processor type, not the os subtype (it should be 'x86_64' on my PC). > > > > Is this intentional? > > > I don't think so. > > Marcus > Thanks Goubier and Marcus, I made the updates to OSProcess and CommandShell to handle system version and subtype in Pharo 3.0. I did not yet update ConfigurationOfOSProcess or ConfigurationOfCommandShell, but the latest versions for Squeak/Pharo are in OSProcess-dtl.83 and CommandShell-dtl.73 in the SqueakSource repositories. Dave

Sept. 5, 2013

Re: [Pharo-dev] [About Documentation] Teach, Don't Tell / Steve Losh

by Sven Van Caekenberghe

On 04 Sep 2013, at 21:54, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I have the impression that the Deep into Pharo book is going in that direction. Rest assured that all the work that you and others are doing with regards to the different books is absolutely in the right direction ! Two/three years ago, the Pharo by Example and Seaside book were really important to me, heck they still are, especially the real paper versions. These did indeed 'teach'. So thank you and please continue. I know it is hard work, but is does make a real difference, I am sure to many people. >> Pretty well written piece about real documentation: >> >> http://stevelosh.com/blog/2013/09/teach-dont-tell/ >> >> Sven >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> > >

Sept. 4, 2013

Re: [Pharo-dev] [About Documentation] Teach, Don't Tell / Steve Losh

by StÃ©phane Ducasse

I have the impression that the Deep into Pharo book is going in that direction. > Pretty well written piece about real documentation: > > http://stevelosh.com/blog/2013/09/teach-dont-tell/ > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > >

Sept. 4, 2013

Re: [Pharo-dev] specialSelectors

by Eliot Miranda

On Wed, Sep 4, 2013 at 3:35 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > i think you can feel the difference while running interpreter. > With JIT it makes little sense to have special selectors imo. > There are two advantages. Space; special selectors encode a message send in 1 byte, instead of 1 byte for the send bytecode + 4 bytes for the literal selector. Optimization; the JIT (as does the interpreter) inlines +,-,*,/ etc for SmallInteger and then does even more inlining for >,<,>=,<=,== when they're followed by a jump. As far as space goes, now that the system is 32-bit, and especially if it is 64-bit there is an opportunity to add 256 special selectors and use a two-byte special selector bytecode, 2 < 1 + 4. VisualWorks does this. There are problems though; over time the most statically frequent selectors can change as the library changes (e.g. blockCopy: is no longer used). > > On 4 September 2013 12:31, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Agree, >> My point was to ensure there was no speedup, so it's only a space >> optimization (1 slot saved from literals, times 5000 senders or so per >> selector plus maybe a byte for the send bytecode ?). >> However the arithmetic ops, comparisons, bit ops, at: at:put:, == and >> class special selectors still have some specific speed up, especially in >> COG, so we cannot get rid of specialSelectors alltogether... >> >> >> 2013/9/4 Marcus Denker <marcus.denker(a)inria.fr> >> >>> >>> On Sep 4, 2013, at 12:08 AM, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> > I note that #class was removed from specialSelectors (nilled entry) so >>> as to not use the VM hack which fetches the class without sending a message. >>> > Pharo prefers the regular message send. >>> > But next to that entry, there is #blockCopy: which was formerly used >>> for blue book BlockContext. >>> > BlockContext was removed from Pharo... >>> > So that makes two available slots for optimizing most used (sent) >>> messages... >>> > We might choose some candidates and test on some macro benchmark if >>> ever that really makes a difference. >>> >>> I am not sure if optimizations on that level make senseâ¦ >>> >>> Marcus >>> >> >> > > > -- > Best regards, > Igor Stasenko. > -- best, Eliot

Sept. 4, 2013

Monticello Zinc Socket timeout

by Camillo Bruni

We have this strange bug again that we get timeouts on the Squeaksource, I thought the Sven fixed it, but it still persists in the latest image. I reopened https://pharo.fogbugz.com/default.asp?6923

Sept. 4, 2013