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

Re: [Pharo-project] Mailinglit Archive not working

by Marcus Denker

On Oct 10, 2011, at 10:56 AM, Torsten Bergmann wrote: > Looks like it is down: > http://lists.gforge.inria.fr/pipermail/pharo-project/ gforge.inria.fr was down as a whole, its working again now. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 10, 2011

Re: [Pharo-project] Mailinglit Archive not working

by Frank Shearar

On 10 October 2011 09:23, Torsten Bergmann <astares(a)gmx.de> wrote: > Looks like it is down: > http://lists.gforge.inria.fr/pipermail/pharo-project/ It's working from London. frank

Oct. 10, 2011

[Pharo-project] Mailinglit Archive not working

by Torsten Bergmann

Looks like it is down: http://lists.gforge.inria.fr/pipermail/pharo-project/ -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Oct. 10, 2011

[Pharo-project] Fwd: completion appears in the wrong place

by Tudor Girba

Any ideas? :) Doru Begin forwarded message: > From: Tudor Girba <tudor(a)tudorgirba.com> > Subject: completion appears in the wrong place > Date: 2 October 2011 18:16:41 CEST > To: Pharo Development <pharo-project(a)lists.gforge.inria.fr> > > Hi, > > I would like to get my model for a PluggableTextMorph work with ECompletion/OCompletion. > > To this end, I basically looked around for examples, and found OBTextPanel and its subclasses. So, I basically copied the following methods in my model (GLMSmalltalkCodeModel in the Glamour repo) and things seemed work fine: > > completionController > | controller | > controller := self triggerEvent: #getCompletionController. > controller ifNil: [controller := self initializeCompletionController]. > ^controller > > initializeCompletionController > | controller | > controller := self createCompletionController. > self > when: #getCompletionController > evaluate: (MessageSend > receiver: controller > selector: #yourself). > ^ controller > > createCompletionController > ^(ECPreferences useECompletionInsteadOfOCompletion > ifFalse: [ OController ] > ifTrue: [ ECController ]) model: self > > > Now, the problem is that when the textmorph in which I am rendering this is in a GLMFinder using an implementation similar to the one of OB, and somehow the completion looks to be rendered in absolute coordinates, rather than relative to the window (see the attached screenshots). > > Any hints regarding what goes wrong? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > > -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Oct. 10, 2011

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

by Hernan Wilkinson

Hi Eliot! On Sat, Oct 8, 2011 at 3:00 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > You're reviving the entire discussion over ANSI exceptions, the Digitalk > one based on classes and the instance-based on from ParcPlace. > Not exactly... I was only suggesting that is not good to couple class hierarchy with exception handling... > The conclusion is that the class-based system is better on balance. > I agree with that... I have used the VA exception based on ExceptionalEvent and Signal and as you say, I prefer to have classes to model exceptions Classes are cheap, their names are really useful when well-chosen and being > able to add behaviour to specific exceptions is a huge win. > Yes, agree > As has been pointed out, creating exception sets with #, means classes of > exception can be conveniently combined. So at least for me it is better to > let sleeping dogs lie and continue to enjoy class-based exceptions (and > class0-based announcements). > I agree, again, I was trying to say that selecting a exception handler should not be only close to a class and its subclasses, and I showed in a previous example how that is supported currently in Pharo, which I think it is great. Well, I hope I made myself clear :-) Bye! Hernan. > But I think the bottom line is that the declarative nature of classes is > extremely useful in making a system comprehensible and navigable by the > programmer. Look at how prototype-based languages end up inventing things > close to classes for precisely these reasons. > > Anyway, I found this useful in two cases and it helps me to explain what >> exceptions are really and how to avoid those big/depth exceptions >> hierarchies very common in "inexperienced" programmers... and when I found I >> could do something like this it blowed my head :-) >> >> >>> On 7 October 2011 23:54, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> >>> wrote: >>> > yes yes, but using #, still has the coupling with the class >>> hierarchy... I >>> > mean, if you write: >>> > [] on: Exc1, Exc2 do: [...] >>> > It will handle Exc1 and it subclasses and Exc2 and its subclasses... I >>> can >>> > not handle just Exc1 and Exc2 >>> > What I tried to say is that handling a class and its subclasses is an >>> > special case of handling a collection of classes and if we can handle >>> any >>> > group of classes, then handling a hierarchy is just trivial, a >>> particular >>> > case of handling a group, then handling the hierarchy creates >>> > an unnecessary coupling, maybe handy but not necessary, and showing >>> > programmers that is not a RULE for the exception handling mechanism to >>> > always handle a hierarchy just "break their head"... (I don't remember >>> the >>> > phrase for that in English :-) ) >>> > >>> > On Fri, Oct 7, 2011 at 3:42 PM, 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 >>> >> >>> > >>> > >>> > >>> > -- >>> > 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 >>> >>> >> >> >> -- >> *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 >> >> > > > -- > best, > Eliot > > -- *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. 10, 2011

Re: [Pharo-project] Destruction of object in Pharo/Smalltalk - When I clean resources?

by StÃ©phane Ducasse

pay attention because the finalization of objects changed since then. What you can do is to check if you have pending announcements or others. Because may be you do not have them :) Normally there is no need to unregister objects. And with ephemerons it will be fixed even more nicely. Stef On Oct 9, 2011, at 11:23 PM, nullPointer wrote: > http://wiki.squeak.org/squeak/664 > > -- > View this message in context: http://forum.world.st/Destruction-of-object-in-Pharo-Smalltalk-When-I-clean… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 9, 2011

Re: [Pharo-project] Destruction of object in Pharo/Smalltalk - When I clean resources?

by nullPointer

http://wiki.squeak.org/squeak/664 -- View this message in context: http://forum.world.st/Destruction-of-object-in-Pharo-Smalltalk-When-I-clean… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 9, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Schwab,Wilhelm K

That's a good idea. Then every version of Fuel would pass an ever growing set of tests designed to ensure that the "backup" format works as intended. Hopefully, the format will eventually stabilize. I might be alone in this, but I see serializers as a very simple object oriented database, aka a "free" file format. Yes, one could do much the same thing with an OODMS, but there were reasons to avoid that path, especially at the time we got started. One needs to cope with schema changes (instance variable layout) in the application classes, but that can be done (Object Arts strikes again). *IF* Fuel is to serve a market that archives data, the format needs to be readable well into the future. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Michael Roberts [mike(a)mjr104.co.uk] Sent: Sunday, October 09, 2011 10:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] When will Fuel file format stabilize? I wonder if it would be possible for you to come up with a separate format, whose purpose was only ever for this purpose. It would not need to be efficient in any respect, just something you could write out to file (say) during the process. It would be a shame to rely on the whole graph needing to be in memory. Maybe something very crude and text based? It could even be considered a debugging format, if it was somewhat human readable. If so, you could easily send this over a socket from an old version of a running system to a newer one, without relying on either serialising format. It could be quite handy. cheers, Mike On Sun, Oct 9, 2011 at 10:27 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Oct 9, 2011 at 12:03 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Mariano >> >> >> > No, that's impossible, and if posible, it is not worth it. Migrating >> > from an old format to a new one is extremelly complicated and innecessary. >> > The easiest way to solve this is to take the correct version of Fuel, >> > materialize the graph from the stream, load new version of Fuel, and >> > seriaize it again. That the easiest, more secure, and more practical >> > approach I can see. >> >> It would be interesting to see if you can get two different versions in >> memory :) > > heheh that would be nice :) > >> >> (a need for a module system) > > yep, so far it is not possible. > >> >> so that you can load with one and save with the other. >> >> Stef >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 9, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Michael Roberts

I wonder if it would be possible for you to come up with a separate format, whose purpose was only ever for this purpose. It would not need to be efficient in any respect, just something you could write out to file (say) during the process. It would be a shame to rely on the whole graph needing to be in memory. Maybe something very crude and text based? It could even be considered a debugging format, if it was somewhat human readable. If so, you could easily send this over a socket from an old version of a running system to a newer one, without relying on either serialising format. It could be quite handy. cheers, Mike On Sun, Oct 9, 2011 at 10:27 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Oct 9, 2011 at 12:03 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Mariano >> >> >> > No, that's impossible, and if posible, it is not worth it. Migrating >> > from an old format to a new one is extremelly complicated and innecessary. >> > The easiest way to solve this is to take the correct version of Fuel, >> > materialize the graph from the stream, load new version of Fuel, and >> > seriaize it again. That the easiest, more secure, and more practical >> > approach I can see. >> >> It would be interesting to see if you can get two different versions in >> memory :) > > heheh that would be nice :) > >> >> (a need for a module system) > > yep, so far it is not possible. > >> >> so that you can load with one and save with the other. >> >> Stef >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 9, 2011

Re: [Pharo-project] Odd deprecation message in UIManager

by StÃ©phane Ducasse

On Oct 9, 2011, at 3:28 PM, Igor Stasenko wrote: > On 9 October 2011 08:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> At some point we should have a UI builder with specs like in vw. >> I should do a little proto to show how it can work and that people understand the value and help but I want to finish rpackage and bootstrap first > > with specs? then it will be same as toolbuilder, no? No VWspec are declarative. Here is an example: composite structure. The UIBuilder takes that as input and produce a widget. windowSpec "Tools.UIPainter new openOnClass: self andSelector: #windowSpec" <resource: #canvas> ^#(#{UI.FullSpec} #window: #(#{UI.WindowSpec} #label: 'Author Coloring Control' #bounds: #(#{Graphics.Rectangle} 535 279 823 658 ) ) #component: #(#{UI.SpecCollection} #collection: #( #(#{UI.CompositeSpecCollection} #collection: #( #(#{UI.SequenceViewSpec} #layout: #(#{Graphics.LayoutFrame} 0 0 0 0 0 1.0 0 1.0 ) #name: #AuthorList #model: #authorList #multipleSelections: true #useModifierKeys: true #selectionType: #checkMark ) ) #compositeSpec: #(#{UI.CompositeSpec} #layout: #(#{Graphics.LayoutFrame} 0 0 25 0 0 1 0 1 ) #name: #Composite1 ) ) #(#{UI.LabelSpec} #layout: #(#{Graphics.LayoutSizedOrigin} 20 0.0 4 0 140 20 ) #name: #Label1 #label: 'Select users to disable them:' ) ) ) ) > my point is that the role of uimanager is to provide protocol(s) for > basic stuff, and dont make it too wide. > As for ui builder , i think it would be nice to have real ui editor > which can serialize UI either into source code, not in source code, in spec. > or since we have fuel, we can serialize it into a bunch of bytes and > then store them either in file or in image. Saving objects will lead to death as soon as we change the objects shape. Stef > >> Stef >> >> >>>> Hi! >>>> >>>> There is this method: >>>> >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> UIManager>>multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight >>>> "Create a multi-line instance of me whose question is queryString with >>>> the given initial answer. Invoke it centered at the given point, and >>>> answer the string the user accepts. Answer nil if the user cancels. An >>>> empty string returned means that the ussr cleared the editing area and >>>> then hit 'accept'. Because multiple lines are invited, we ask that the user >>>> use the ENTER key, or (in morphic anyway) hit the 'accept' button, to >>>> submit; that way, the return key can be typed to move to the next line." >>>> >>>> self deprecated: 'Use multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: ' on: '7 September 2011' in: 'Pharo1.4'. >>>> ^self subclassResponsibility >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> Apparently, the deprecation message says to use this very method. Which method should I use? Shall I open an entry? >>>> >>> i really wonder why such things are there? >>> UI manager has to provide a simple interface, without any >>> sophisticated stuff, like multiline/multibutton etc. >>> Lets stop bloating the interface, it leads nowhere. >>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 9, 2011