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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30533 Home: https://github.com/pharo-project/pharo-core

Oct. 31, 2013

[pharo-project/pharo-core] e70397: 30533

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: e70397c31a642d5caeda5d9182cd4915022950c2 https://github.com/pharo-project/pharo-core/commit/e70397c31a642d5caeda5d91… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-31 (Thu, 31 Oct 2013) Changed paths: A Collections-Abstract.package/HashedCollection.class/instance/private/noCheckAdd_.st M Kernel.package/ContextPart.class/instance/controlling/restart.st M Kernel.package/ContextPart.class/instance/controlling/resume_.st M Kernel.package/ContextPart.class/instance/controlling/resume_through_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script188.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30533.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30533 3455 HashedCollection missed abstract method noCheckAdd: https://pharo.fogbugz.com/f/cases/3455 12035 Slot and Protocol should be compact https://pharo.fogbugz.com/f/cases/12035 12034 Accessor to temporaries of context in case of unwinding not explicit https://pharo.fogbugz.com/f/cases/12034 http://files.pharo.org/image/30/30533.zip

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by kilon alios

Wow so much work to add an instance variable ? In python is as simple as MyClass.newVariable = 30 I always assumed Pharo was very similar. On Thu, Oct 31, 2013 at 10:55 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > Basically here we discuss how to introduce in Pharo stateful class > extension and stateful traits. I like these features a lot because it means > I would be able to reuse the same class differently depending on the > context and the surrounding classes. But if we overuse that we will > definitely go into chaos. Martin tried in Mist and he concluded that he > should have class composition instead of stateful traits / class extension. > > For now the common way to add extra instance variable is: you add an extra > instance variable named 'properties' in the main class which needs to be > committed on the other package, then in the class extension you initialize > this varable lazily to a dictionary, and to use extra instance variable, > you store/read them in the properties dictionary by overriding the > getter/setter method. You can look at the refactoring browser AST which is > implemented like that. This way is nice because it is easily optimizable by > slots (even if we have not done it yet) and you only add 1 instance > variable to the main class whereas you can add an infinite number of > instance variables. > > Best, > > > 2013/10/31 Tudor Girba <tudor(a)tudorgirba.com> > >> I completely disagree with this point of view :). >> >> We should assume an open world, not a close one. From this point of view, >> any part of the system should be extensible by anyone. In most other >> languages I know, it is not even possible to extend easily a class with new >> functionality. In Pharo we can, and we know it is a powerful mechanism. It >> is not the responsibility of the base class to know what extensions are out >> there and protect against them. Just like with subclassing, It is in the >> responsibility of the extender. >> >> We should be able to do the same with state as well. Without this >> mechanism, we are forced to put in place clunky dictionary-based mechanism >> to support state extension. Essentially, any white-box framework does that. >> For example, Morphic does that, FAMIX and Roassal do that, too (and yes, >> this is not a bad thing). >> >> We need this mechanism in the environment, and if I understand Slots >> correctly, now we have first class support for it. This also means that >> overrides will be easier to deal with, too. Of course, overrides can induce >> headaches from time to time, but we should treat these headaches with >> proper tools, not by forbidding the world to extend. >> >> And if we are at it, we should also be able to extend a class with >> Traits, too. >> >> Cheers, >> Doru >> >> >> >> >> On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >> >>> >>> On 2013-10-30, at 22:36, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > I don't think there's something to fix. >>> > You cannot 'extend' classes belonging to other package in any other way >>> > than adding extension methods. >>> > Allowing extension of ivars or any other vars by foreign package >>> > is road to nowhere. >>> > >>> > I would not like if shape of my kernel classes depends on what >>> packages i load >>> > or in what order i loaded them. >>> > To me it is clear that if one needs to add/remove/modify instance >>> variables >>> > of some class, those changes should belong to the package containing >>> that class, >>> > not some random package. >>> >>> Exactly, it would cause the same problem as we have with overrides in >>> monticello >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

Oct. 31, 2013

another talk online: Pharo: Objects At Your Fingertips

by Marcus Denker

The idea of this talk is to give an intro for someone who know OO but not Pharo (or Smalltalk). (this means for someone who does it has noting new) Pharo: Objects At Your Fingertips A talk given at Universitat PolitÃ¨cnica de Catalunya on Oct 30, 2013. SlideShare: http://www.slideshare.net/MarcusDenker/pharo-objects-at-your-fingertips PDF: http://marcusdenker.de/talks/13BarcelonaTalk/PharoObjectsAtYourFingertips.p… Video: http://media.fib.upc.edu/fibtv/streamingmedia/view/2/821

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by ClÃ©ment Bera

Basically here we discuss how to introduce in Pharo stateful class extension and stateful traits. I like these features a lot because it means I would be able to reuse the same class differently depending on the context and the surrounding classes. But if we overuse that we will definitely go into chaos. Martin tried in Mist and he concluded that he should have class composition instead of stateful traits / class extension. For now the common way to add extra instance variable is: you add an extra instance variable named 'properties' in the main class which needs to be committed on the other package, then in the class extension you initialize this varable lazily to a dictionary, and to use extra instance variable, you store/read them in the properties dictionary by overriding the getter/setter method. You can look at the refactoring browser AST which is implemented like that. This way is nice because it is easily optimizable by slots (even if we have not done it yet) and you only add 1 instance variable to the main class whereas you can add an infinite number of instance variables. Best, 2013/10/31 Tudor Girba <tudor(a)tudorgirba.com> > I completely disagree with this point of view :). > > We should assume an open world, not a close one. From this point of view, > any part of the system should be extensible by anyone. In most other > languages I know, it is not even possible to extend easily a class with new > functionality. In Pharo we can, and we know it is a powerful mechanism. It > is not the responsibility of the base class to know what extensions are out > there and protect against them. Just like with subclassing, It is in the > responsibility of the extender. > > We should be able to do the same with state as well. Without this > mechanism, we are forced to put in place clunky dictionary-based mechanism > to support state extension. Essentially, any white-box framework does that. > For example, Morphic does that, FAMIX and Roassal do that, too (and yes, > this is not a bad thing). > > We need this mechanism in the environment, and if I understand Slots > correctly, now we have first class support for it. This also means that > overrides will be easier to deal with, too. Of course, overrides can induce > headaches from time to time, but we should treat these headaches with > proper tools, not by forbidding the world to extend. > > And if we are at it, we should also be able to extend a class with Traits, > too. > > Cheers, > Doru > > > > > On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> >> On 2013-10-30, at 22:36, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > I don't think there's something to fix. >> > You cannot 'extend' classes belonging to other package in any other way >> > than adding extension methods. >> > Allowing extension of ivars or any other vars by foreign package >> > is road to nowhere. >> > >> > I would not like if shape of my kernel classes depends on what packages >> i load >> > or in what order i loaded them. >> > To me it is clear that if one needs to add/remove/modify instance >> variables >> > of some class, those changes should belong to the package containing >> that class, >> > not some random package. >> >> Exactly, it would cause the same problem as we have with overrides in >> monticello >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 31, 2013

Re: [Pharo-dev] How to create lines with Athens

by kilon alios

yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens and reload the image, I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ? On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > ah, yes , there's also examples in > Athens-Examples package. > > > On 31 October 2013 01:30, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> On 30 October 2013 23:02, kilon alios <kilon.alios(a)gmail.com> wrote: >> >>> well I just asked if there is any kind of Documentation about Athens . >>> Or should I just read the code and ask questions ? >>> >>> >> the main source of documentation right now is class comments >> and tutorial. >> I've spent quite of a time commenting the central classes of athens, >> hope that's helpful. >> Of course this does not replacement for a well written docu, and that >> needs to be done. >> >> >>> >>> On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> i hope you satisfied with my answer. >>>> you welcome to ask more, if you not :) >>>> >>>> >>>> On 30 October 2013 22:32, dimitris chloupis <thekilon(a)yahoo.co.uk>wrote: >>>> >>>>> >>>>> http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 31, 2013

Re: [Pharo-dev] Formatting dates

by phil＠highoctane.be

Closest match is with the Printf package (http://www.squeaksource.com/Printf ) example: now := DateAndTime now. filename := '%s-%04d%02d%02d_%02d%02d.ston' printf: { self name. now year. now month. now dayOfMonth. now hour. now minutes.}. I am coming from C, so, yes, I like printf. (Can't help thinking about PRINT USING "#####.##" of old :-) http://www.colorcomputerarchive.com/coco/Documents/Manuals/Hardware/Getting… p187 - 1983) Phil On Wed, Oct 30, 2013 at 11:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > > On 30 Oct 2013, at 22:46, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Why not a more discriminating example, like '19991231â? > > From the class comment: > > â¦ > You instanciate me by specifying the textual format by example, based on a > #reference timetamp. > > Each component of the example representation is numbered from largest to > smallest unit, 1=year, 2=month, 3=dayInMonth, 4=hour (16 in 24 hour > format), 5=minute and 6=second, as in the ISO representation: > 2001-02-03T16:05:06Z which is a Saterday. Example format strings can be > found in my class accessing protocol or in the unit tests. > â¦ > > But of course, internally there is less magic: it are just specific > keys/tokens that are recognised ;-) The example is kind of compiled though > to make it more efficient should you reuse the format. > > > 2013/10/30 Sven Van Caekenberghe <sven(a)stfx.eu> > > Hi Blake, > > > > On 30 Oct 2013, at 21:55, blake <dsblakewatson(a)gmail.com> wrote: > > > > > Heya, guys-- > > > > > > Converting a Ruby program to Pharo, and one of the things this program > does is write a file out by date. The format is "yyyymmdd" (which is my > preferred naming convention). In Ruby I have: > > > > > > "%04d" % d.year + "%02d" % d.month + "%02d" % d.day > > > > > > In Smalltalk, the closest I can seem to get to this is: > > > > > > d year asString, (d monthIndex asString padLeftTo: 2 with: $0), (d > dayOfMonth asString padLeftTo: 2 with: $0) > > > > > > ...which seems sort verbose. Anyone have any more elegant solutions? > > > > Using the âby exampleâ formatter/parser that is part of the ZTimestamp > package (can be loaded using the Configuration Browser), you could say: > > > > (ZTimestampFormat fromString: '20010203') format: Date today. > > > > Although it is called ZTimestampFormat, it can actually work with Date, > Time, DateAndTime as well. > > > > Sven > > > > >

Oct. 31, 2013

Re: [Pharo-dev] Losing instance variable addition

by Tudor Girba

I completely disagree with this point of view :). We should assume an open world, not a close one. From this point of view, any part of the system should be extensible by anyone. In most other languages I know, it is not even possible to extend easily a class with new functionality. In Pharo we can, and we know it is a powerful mechanism. It is not the responsibility of the base class to know what extensions are out there and protect against them. Just like with subclassing, It is in the responsibility of the extender. We should be able to do the same with state as well. Without this mechanism, we are forced to put in place clunky dictionary-based mechanism to support state extension. Essentially, any white-box framework does that. For example, Morphic does that, FAMIX and Roassal do that, too (and yes, this is not a bad thing). We need this mechanism in the environment, and if I understand Slots correctly, now we have first class support for it. This also means that overrides will be easier to deal with, too. Of course, overrides can induce headaches from time to time, but we should treat these headaches with proper tools, not by forbidding the world to extend. And if we are at it, we should also be able to extend a class with Traits, too. Cheers, Doru On Wed, Oct 30, 2013 at 10:54 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2013-10-30, at 22:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > I don't think there's something to fix. > > You cannot 'extend' classes belonging to other package in any other way > > than adding extension methods. > > Allowing extension of ivars or any other vars by foreign package > > is road to nowhere. > > > > I would not like if shape of my kernel classes depends on what packages > i load > > or in what order i loaded them. > > To me it is clear that if one needs to add/remove/modify instance > variables > > of some class, those changes should belong to the package containing > that class, > > not some random package. > > Exactly, it would cause the same problem as we have with overrides in > monticello > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 31, 2013

Re: [Pharo-dev] Formatting dates

by David T. Lewis

On Wed, Oct 30, 2013 at 03:03:53PM -0700, blake wrote: > Chris, > > On Wed, Oct 30, 2013 at 2:02 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > > Date today yyyymmdd. "prints '2013-10-30'" > > > > > I don't want the separator. > Date today yyyymmdd copyWithoutAll: '-'

Oct. 31, 2013

Re: [Pharo-dev] How to create lines with Athens

by Igor Stasenko

ah, yes , there's also examples in Athens-Examples package. On 31 October 2013 01:30, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 30 October 2013 23:02, kilon alios <kilon.alios(a)gmail.com> wrote: > >> well I just asked if there is any kind of Documentation about Athens . Or >> should I just read the code and ask questions ? >> >> > the main source of documentation right now is class comments > and tutorial. > I've spent quite of a time commenting the central classes of athens, > hope that's helpful. > Of course this does not replacement for a well written docu, and that > needs to be done. > > >> >> On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> i hope you satisfied with my answer. >>> you welcome to ask more, if you not :) >>> >>> >>> On 30 October 2013 22:32, dimitris chloupis <thekilon(a)yahoo.co.uk>wrote: >>> >>>> >>>> http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Oct. 31, 2013