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

Re: [Pharo-project] Renaming "Announcement" into "Event"?

by Lukas Renggli

Actually this is even part of ANSI. Any Smalltalk that does not support this out of the box is not ANSI compatible :-) Lukas On 7 October 2011 20:42, Lukas Renggli <renggli(a)gmail.com> wrote: > Actually both -- Announcement and Exception -- implement #, to create > such a collection: > > Â Â anAnnouncer > Â Â Â on: MouseMovedAnnouncement , MouseClickedAnnouncement > Â Â Â do: [ :ann | ... ] > > Â Â [ ... ] > Â Â Â on: ZeroDivideException , IndexOutOfBoundsException , > IllegalStateException > Â Â Â do: [ :err | ... ] > > Lukas > > On 7 October 2011 20:30, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: >> >> >> On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> On 7 October 2011 13:53, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> >>> wrote: >>> > Or remove the absurd coupling between subclassing and grouping >>> > exceptions/events (or whatever name you prefer to use :-) ) that leads >>> > to >>> > absurd/depth/big exception/events hierarchies :-) >>> >>> >>> By proposing that, i expect that you have an alternative in mind. How >>> else you could >>> provide a grouping for exceptions/events in that case? >> >> yeah yeah... of course :-) ... you could create any group you want with any >> collection and not only groups created by a "hierarchy". >> So, you could create an ExceptionToCollectionAdapter that responds to >> #handles: answering true if the exception is included in the group you >> defined. For example: >> ExceptionToCollectionAdapter class>>for: aCollectionOfExceptions >> ^self new initializeFor: aCollectionOfExceptions >> ExceptionToCollectionAdapter>>initializeFor: aCollectionOfExcpetions >> exceptions := aCollectionOfExceptions >> ExceptionToCollectionAdapter>>handles: anException >> ^excpetions includes: anException >> Therefor now you can: >> [ ... bla bla ] >> Â on: (ExceptionToCollectionAdapter for: (Set with: exc1 with: exc2 with: >> etc)) >> Â do: [ bla bla ] >> I used a similar technique to be able to easily identify different >> exceptions that are instances of the same class. >> For example, I created a model to easily run preconditions and if a >> precondition does not hold the exception AssertionFailed is signaled. So, to >> handle a particular assertion failure I use the name of the assertion in the >> #on:do:. For example. >> Number>>/ aDivisor >> Â Â "I removed the precondtions objects to make it easier for the example" >> Â Â aDivisor = 0 ifTrue: [ AssertionFailed signalNamed: #divisorCanNotBeZero >> ]. >> Â Â bla bla >> and now, to handle that assertion failure: >> [ 1/0 ] >> Â on: #divisorCanNotBeZero asExceptionToHandle >> Â do: [ .... ] >> Anyway, the magic again is the dinamic and open nature of smalltalk... in >> this case any object that anwers #handles: can be a parameter in the on: of >> the on:do:... >> It is very interesiting to show this example to Java, C# programmers, etc. >> Â because it breaks the myth about exceptions and shows that exceptions is >> just another model and that in a good language you should be able to change >> it if you wanted :-)... so, GO SMALLTALK!!! :-) >> >> >>> >>> Basically, what we need is a fast way to check if given object belongs >>> to some specific group (in case if we want to react on all >>> exception/events >>> in given group). >>> So? >>> >>> >>> > >>> > On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli(a)gmail.com> >>> > wrote: >>> >> >>> >> On 6 October 2011 17:40, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >> > On 6 October 2011 17:24, Lukas Renggli <renggli(a)gmail.com> wrote: >>> >> >>>> why wasting an energy on something, which not gives any benefits? >>> >> >>> >>> >> >>> There is a benefit when you teach Pharo and write a book. >>> >> >> >>> >> >> Then you should make the Exception hierarchy a subclass of Event too >>> >> >> and rename all exceptions, because they are all (exceptional) events >>> >> >> too. >>> >> >> >>> >> >>>> i completely agree that proper naming is important. but the >>> >> >>>> framework >>> >> >>>> was originally designed not by us, >>> >> >>>> and i think its not quite correct to rename it without asking the >>> >> >>>> author. >>> >> >>> >>> >> >>> This is what this email is about :-) >>> >> >> >>> >> >> Puns aside: Why not just remove the Announcement class altogether? >>> >> >> It >>> >> >> used to be empty in the original implementation and serves no real >>> >> >> purpose other than grouping its subclasses. Any object can >>> >> >> potentially >>> >> >> represent an event. >>> >> >> >>> >> > err.. an Announcement playing own role as a root class for all >>> >> > announcements. >>> >> > In same way as Exception is a root of all exceptions, so if you want >>> >> > to handle all exceptions you putting Exception class. >>> >> > If you remove the notion of root, then you will need to introduce >>> >> > something else in order to satisfy 'i wanna handle all >>> >> > exceptions/events , >>> >> > no matter what they are'. >>> >> >>> >> Object would be your choice for all events then. >>> >> >>> >> Lukas >>> >> >>> >> -- >>> >> Lukas Renggli >>> >> www.lukas-renggli.ch >>> >> >>> > >>> > >>> > >>> > -- >>> > HernÃ¡n Wilkinson >>> > Agile Software Development, Teaching & Coaching >>> > Mobile: +54 - 911 - 4470 - 7207 >>> > email: hernan.wilkinson(a)10Pines.com >>> > site:Â http://www.10Pines.com >>> > Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> HernÃ¡n Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 911 - 4470 - 7207 >> email: hernan.wilkinson(a)10Pines.com >> site:Â http://www.10Pines.com >> Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 7, 2011

Re: [Pharo-project] Renaming "Announcement" into "Event"?

by Lukas Renggli

Actually both -- Announcement and Exception -- implement #, to create such a collection: anAnnouncer on: MouseMovedAnnouncement , MouseClickedAnnouncement do: [ :ann | ... ] [ ... ] on: ZeroDivideException , IndexOutOfBoundsException , IllegalStateException do: [ :err | ... ] Lukas On 7 October 2011 20:30, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: > > > On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 7 October 2011 13:53, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> >> wrote: >> > Or remove the absurd coupling between subclassing and grouping >> > exceptions/events (or whatever name you prefer to use :-) ) that leads >> > to >> > absurd/depth/big exception/events hierarchies :-) >> >> >> By proposing that, i expect that you have an alternative in mind. How >> else you could >> provide a grouping for exceptions/events in that case? > > yeah yeah... of course :-) ... you could create any group you want with any > collection and not only groups created by a "hierarchy". > So, you could create an ExceptionToCollectionAdapter that responds to > #handles: answering true if the exception is included in the group you > defined. For example: > ExceptionToCollectionAdapter class>>for: aCollectionOfExceptions > ^self new initializeFor: aCollectionOfExceptions > ExceptionToCollectionAdapter>>initializeFor: aCollectionOfExcpetions > exceptions := aCollectionOfExceptions > ExceptionToCollectionAdapter>>handles: anException > ^excpetions includes: anException > Therefor now you can: > [ ... bla bla ] > Â on: (ExceptionToCollectionAdapter for: (Set with: exc1 with: exc2 with: > etc)) > Â do: [ bla bla ] > I used a similar technique to be able to easily identify different > exceptions that are instances of the same class. > For example, I created a model to easily run preconditions and if a > precondition does not hold the exception AssertionFailed is signaled. So, to > handle a particular assertion failure I use the name of the assertion in the > #on:do:. For example. > Number>>/ aDivisor > Â Â "I removed the precondtions objects to make it easier for the example" > Â Â aDivisor = 0 ifTrue: [ AssertionFailed signalNamed: #divisorCanNotBeZero > ]. > Â Â bla bla > and now, to handle that assertion failure: > [ 1/0 ] > Â on: #divisorCanNotBeZero asExceptionToHandle > Â do: [ .... ] > Anyway, the magic again is the dinamic and open nature of smalltalk... in > this case any object that anwers #handles: can be a parameter in the on: of > the on:do:... > It is very interesiting to show this example to Java, C# programmers, etc. > Â because it breaks the myth about exceptions and shows that exceptions is > just another model and that in a good language you should be able to change > it if you wanted :-)... so, GO SMALLTALK!!! :-) > > >> >> Basically, what we need is a fast way to check if given object belongs >> to some specific group (in case if we want to react on all >> exception/events >> in given group). >> So? >> >> >> > >> > On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli(a)gmail.com> >> > wrote: >> >> >> >> On 6 October 2011 17:40, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > On 6 October 2011 17:24, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> >>>> why wasting an energy on something, which not gives any benefits? >> >> >>> >> >> >>> There is a benefit when you teach Pharo and write a book. >> >> >> >> >> >> Then you should make the Exception hierarchy a subclass of Event too >> >> >> and rename all exceptions, because they are all (exceptional) events >> >> >> too. >> >> >> >> >> >>>> i completely agree that proper naming is important. but the >> >> >>>> framework >> >> >>>> was originally designed not by us, >> >> >>>> and i think its not quite correct to rename it without asking the >> >> >>>> author. >> >> >>> >> >> >>> This is what this email is about :-) >> >> >> >> >> >> Puns aside: Why not just remove the Announcement class altogether? >> >> >> It >> >> >> used to be empty in the original implementation and serves no real >> >> >> purpose other than grouping its subclasses. Any object can >> >> >> potentially >> >> >> represent an event. >> >> >> >> >> > err.. an Announcement playing own role as a root class for all >> >> > announcements. >> >> > In same way as Exception is a root of all exceptions, so if you want >> >> > to handle all exceptions you putting Exception class. >> >> > If you remove the notion of root, then you will need to introduce >> >> > something else in order to satisfy 'i wanna handle all >> >> > exceptions/events , >> >> > no matter what they are'. >> >> >> >> Object would be your choice for all events then. >> >> >> >> Lukas >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> > >> > >> > >> > -- >> > HernÃ¡n Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: hernan.wilkinson(a)10Pines.com >> > site:Â http://www.10Pines.com >> > Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site:Â http://www.10Pines.com > Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina > -- Lukas Renggli www.lukas-renggli.ch

Oct. 7, 2011

Re: [Pharo-project] Too many semaphores, image blocked

by Janko MivÅ¡ek

Hi Henrik, S, Henrik Sperre Johansen piÅ¡e: > On 05.10.2011 01:18, Schwab,Wilhelm K wrote: >> The log you posted contains the string "Not enough space for external >> objects, set a larger size at startup!" Maybe a command-line switch >> to the vm will give you more memory and a way to get the image going? > Smalltalk vm maxExternalSemaphoresSilently: aSize would be the line to > include. > If the script passed on a command line is higher in the startuplist than > the InputEventSensor, it would get it working again. Ok, I'm back having time to look at this problem and I made a start.st script below, start the image with it, but get the same blank screen as you can see in attached screenshot. Ctrl or Alt . doesn't help. start.st Smalltalk vm maxExternalSemaphoresSilently: 3000 ./Contents/Linux/squeak ./Contents/Resources/waste.image start.st Any more idea? Otherwise I'll start to recover from changes, but starting this nonresponsive image would of course be faster solution:) Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Oct. 7, 2011

Re: [Pharo-project] Renaming "Announcement" into "Event"?

by Hernan Wilkinson

On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 October 2011 13:53, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> > wrote: > > Or remove the absurd coupling between subclassing and grouping > > exceptions/events (or whatever name you prefer to use :-) ) that leads to > > absurd/depth/big exception/events hierarchies :-) > > > By proposing that, i expect that you have an alternative in mind. How > else you could > provide a grouping for exceptions/events in that case? > yeah yeah... of course :-) ... you could create any group you want with any collection and not only groups created by a "hierarchy". So, you could create an ExceptionToCollectionAdapter that responds to #handles: answering true if the exception is included in the group you defined. For example: ExceptionToCollectionAdapter class>>for: aCollectionOfExceptions ^self new initializeFor: aCollectionOfExceptions ExceptionToCollectionAdapter>>initializeFor: aCollectionOfExcpetions exceptions := aCollectionOfExceptions ExceptionToCollectionAdapter>>handles: anException ^excpetions includes: anException Therefor now you can: [ ... bla bla ] on: (ExceptionToCollectionAdapter for: (Set with: exc1 with: exc2 with: etc)) do: [ bla bla ] I used a similar technique to be able to easily identify different exceptions that are instances of the same class. For example, I created a model to easily run preconditions and if a precondition does not hold the exception AssertionFailed is signaled. So, to handle a particular assertion failure I use the name of the assertion in the #on:do:. For example. Number>>/ aDivisor "I removed the precondtions objects to make it easier for the example" aDivisor = 0 ifTrue: [ AssertionFailed signalNamed: #divisorCanNotBeZero ]. bla bla and now, to handle that assertion failure: [ 1/0 ] on: #divisorCanNotBeZero asExceptionToHandle do: [ .... ] Anyway, the magic again is the dinamic and open nature of smalltalk... in this case any object that anwers #handles: can be a parameter in the on: of the on:do:... It is very interesiting to show this example to Java, C# programmers, etc. because it breaks the myth about exceptions and shows that exceptions is just another model and that in a good language you should be able to change it if you wanted :-)... so, GO SMALLTALK!!! :-) > Basically, what we need is a fast way to check if given object belongs > to some specific group (in case if we want to react on all > exception/events > in given group). > So? > > > > > > On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: > >> > >> On 6 October 2011 17:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > On 6 October 2011 17:24, Lukas Renggli <renggli(a)gmail.com> wrote: > >> >>>> why wasting an energy on something, which not gives any benefits? > >> >>> > >> >>> There is a benefit when you teach Pharo and write a book. > >> >> > >> >> Then you should make the Exception hierarchy a subclass of Event too > >> >> and rename all exceptions, because they are all (exceptional) events > >> >> too. > >> >> > >> >>>> i completely agree that proper naming is important. but the > framework > >> >>>> was originally designed not by us, > >> >>>> and i think its not quite correct to rename it without asking the > >> >>>> author. > >> >>> > >> >>> This is what this email is about :-) > >> >> > >> >> Puns aside: Why not just remove the Announcement class altogether? It > >> >> used to be empty in the original implementation and serves no real > >> >> purpose other than grouping its subclasses. Any object can > potentially > >> >> represent an event. > >> >> > >> > err.. an Announcement playing own role as a root class for all > >> > announcements. > >> > In same way as Exception is a root of all exceptions, so if you want > >> > to handle all exceptions you putting Exception class. > >> > If you remove the notion of root, then you will need to introduce > >> > something else in order to satisfy 'i wanna handle all > >> > exceptions/events , > >> > no matter what they are'. > >> > >> Object would be your choice for all events then. > >> > >> Lukas > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > > > > > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > > > > > > -- > Best regards, > Igor Stasenko. > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by StÃ©phane Ducasse

Apparently I identified a bug I have a sharedPool SharedPool subclass: #CZPool instanceVariableNames: '' classVariableNames: 'Author BookTitle Chapter Editor Institution Journal Note Number Pages Publisher RequiredFields School Series Title Volume Year uthor' poolDictionaries: '' category: 'Citezen-Model' and on the class side of a pool user class Object subclass: #Flop instanceVariableNames: 'key value' classVariableNames: '' poolDictionaries: 'CZPool' category: 'Citezen-Model' If I have Flop class>> foo ^ Author it will return the SharedPool value. Now if I define the method in a subclass Flop class>> foo ^ Author return the Author global class Now I understand I got a problem.

Oct. 7, 2011

Re: [Pharo-project] Renaming "Announcement" into "Event"?

by Igor Stasenko

On 7 October 2011 13:53, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: > Or remove the absurd coupling between subclassing and grouping > exceptions/events (or whatever name you prefer to use :-) ) that leads to > absurd/depth/big exception/events hierarchies :-) By proposing that, i expect that you have an alternative in mind. How else you could provide a grouping for exceptions/events in that case? Basically, what we need is a fast way to check if given object belongs to some specific group (in case if we want to react on all exception/events in given group). So? > > On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> On 6 October 2011 17:40, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > On 6 October 2011 17:24, Lukas Renggli <renggli(a)gmail.com> wrote: >> >>>> why wasting an energy on something, which not gives any benefits? >> >>> >> >>> There is a benefit when you teach Pharo and write a book. >> >> >> >> Then you should make the Exception hierarchy a subclass of Event too >> >> and rename all exceptions, because they are all (exceptional) events >> >> too. >> >> >> >>>> i completely agree that proper naming is important. but the framework >> >>>> was originally designed not by us, >> >>>> and i think its not quite correct to rename it without asking the >> >>>> author. >> >>> >> >>> This is what this email is about :-) >> >> >> >> Puns aside: Why not just remove the Announcement class altogether? It >> >> used to be empty in the original implementation and serves no real >> >> purpose other than grouping its subclasses. Any object can potentially >> >> represent an event. >> >> >> > err.. an Announcement playing own role as a root class for all >> > announcements. >> > In same way as Exception is a root of all exceptions, so if you want >> > to handle all exceptions you putting Exception class. >> > If you remove the notion of root, then you will need to introduce >> > something else in order to satisfy 'i wanna handle all >> > exceptions/events , >> > no matter what they are'. >> >> Object would be your choice for all events then. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site:Â http://www.10Pines.com > Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina > -- Best regards, Igor Stasenko.

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by StÃ©phane Ducasse

Hi levente > Frank tried to point out that shadowing a global with a class variable actually works. When I try Object subclass: #Plop instanceVariableNames: '' classVariableNames: 'OrderedCollection Editor' poolDictionaries: '' category: 'Citezen-Stef-Scripts' I get a duplicate warning for Editor. Same with OrderedCollection. When I proceed it indeed works (which is good) Now my scenario was that I was using the browser to define classVariable interactively and I could not for Editor. So at least this is a good news. Stef

Oct. 7, 2011

[Pharo-project] about Zen new version in Pharo1.4

by StÃ©phane Ducasse

Hi sven I think that it would be good to update Zen in Pharo1.4 with your latest version. Do you think that it make sense? Stef

Oct. 7, 2011

Re: [Pharo-project] About the scope of classVariables

by StÃ©phane Ducasse

Oct. 7, 2011

Re: [Pharo-project] Renaming "Announcement" into "Event"?

by Hernan Wilkinson

Or remove the absurd coupling between subclassing and grouping exceptions/events (or whatever name you prefer to use :-) ) that leads to absurd/depth/big exception/events hierarchies :-) On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > On 6 October 2011 17:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 6 October 2011 17:24, Lukas Renggli <renggli(a)gmail.com> wrote: > >>>> why wasting an energy on something, which not gives any benefits? > >>> > >>> There is a benefit when you teach Pharo and write a book. > >> > >> Then you should make the Exception hierarchy a subclass of Event too > >> and rename all exceptions, because they are all (exceptional) events > >> too. > >> > >>>> i completely agree that proper naming is important. but the framework > >>>> was originally designed not by us, > >>>> and i think its not quite correct to rename it without asking the > author. > >>> > >>> This is what this email is about :-) > >> > >> Puns aside: Why not just remove the Announcement class altogether? It > >> used to be empty in the original implementation and serves no real > >> purpose other than grouping its subclasses. Any object can potentially > >> represent an event. > >> > > err.. an Announcement playing own role as a root class for all > announcements. > > In same way as Exception is a root of all exceptions, so if you want > > to handle all exceptions you putting Exception class. > > If you remove the notion of root, then you will need to introduce > > something else in order to satisfy 'i wanna handle all > > exceptions/events , > > no matter what they are'. > > Object would be your choice for all events then. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Oct. 7, 2011