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

[Pharo-project] text selection feature

by Michael Roberts

Hi, there is a recent (I don't know how old) feature where text areas now highlight the selected text in all parts of the same text pane. Does this feature have a name and a setting to control it? thanks, Mike

Feb. 14, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Eliot Miranda

On Fri, Feb 11, 2011 at 1:43 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Hi guys > > let us do another pass at cleaning and realigning the system. > Could we agree to deprecate caseOf: and caseOf:otherwise:? > it will simply the compiler, decompiler and also we do not need that at > all. > > | z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. #b caseOf: z > > => > "| z | z := {[#a]->[1+1]. ['b' asSymbol]->[2+2]. [#c]->[3+3]}. > z detect: [:each | each key value = #b] " > > there is one user which I fixing right now. > please don't. It is used in many places in Cog and would be extremely uncomfortable to live without. > > Stef > >

Feb. 14, 2011

Re: [Pharo-project] Working with weak announcements...

by Igor Stasenko

On 14 February 2011 21:52, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > I'm working with weak announcements, trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) > I try to explain: > > This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. > Well, the real question is... how can I produce a "Weak BlockClosure reference" who can die if receiver dies? > I tried some hacks (really ugly hacks, btw), but fail completely. > Any idea? > Don't even try doing it until we will have ephemerons support at VM side :) I explained this few days ago to Stephane, and also i mentioned about this maybe half of year ago when i took a look at announcements. With ephemerons you can have: - reference a block strongly only if subscriber , which held weakly is alive. Once subscribed dies, you start referencing block weakly. In terms on GC it means, that during mark phase, you are visiting a references which reachable through block closure only if your subscriber are already marked as 'live'. So, this means that you can do weak subscriptions like following: self weakOn: Foo do: [:announcement | self bar ]. A 'self' is a subscriber. But if you create a subscription from a pair of: <subscriber> and <block> without using ephemerons you should make sure that reference to subscriber are not reachable through given block. Otherwise, a weak reference become strong one, because you referencing a block strongly and therefore subscriber too, since block referencing subscriber through one of its vars. So, without ephemerons you have to invent some workarounds by rewriting above code with something like: self weakOn: Foo do: [:announcement :myself | myself bar ]. in the above, a block no longer referencing receiver (a subsriber), and instead it will be passed as extra argument to the block. ( except that still, you will have a problem, if closure keeps a reference to home context, which in own turn referencing subscriber through context's receiver.. so without emphemerons you should be really careful) And of course, i think that the usefulness of Announcements is quite limited without proper weak subscription support, because weak subscriptions makes things a lot more easier: you don't have to explicitly unsubscribe some object, once you no longer using it , which as to me means that about 99% of all subscriptions in system will be weak ones , simply to prevent potential problems with hanging references, and because you don't have to worry about unsubscribing. And of course, without weak-block subscriptions, the ease of use of subscription mechanism is a bit limited. So, instead of writing simple and cool: self weakOn: Foo do: [:announcement | self bar ]. you must do more elaborate (and IMO less elegant) self weakOn: Foo send: #handleFooAnnouncement: . and then in #handleFooAnnouncement: you making 'self bar' P.S. the #weakOn: ... is not part of Announcements protocol , it is just an example of 'meta-message' to reveal an intent to create a weak subscription to some announcer by using receiver as a subscriber. > best, > Esteban > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2011

Re: [Pharo-project] A new GUI visual designer

by Schwab,Wilhelm K

In Dolphin, one can cope with that fairly easily - most of the time. The trick is to change the affected class' serializing version number, which causes the loader to seek help reading old serialized data, which arrives as an array. Streams work well for adapting the old array into an array that is correct for the current version. I have not used SIXX long enough to encounter this in a significant way. SIXX appears to depend on messages/apsects, where Dolphin's serializer deals directly in instance variables. My guess is that SIXX will be tolerant of changes that would clobber Dolphin's serializer, but that Dolphin provides tools to handle it. SIXX has something too; I have not needed it yet. One thing about SmartReferenceStream: the conversion methods go in the serializer itself; they belong in the affected class, or in its proxy if one is used. SmartReferenceStream also assumes that user==developer :( Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Monday, February 14, 2011 3:41 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] A new GUI visual designer What is happening if the class of your application UI gets a new variables or if a superclass changes its structure? May be in objective-C you have to resave your nib? Stef DynaBook.

Feb. 14, 2011

Re: [Pharo-project] writing to the transcript stream

by Adrien BARREAU

It inherits from Object, but seems to use a Stream. But it does not support things such as nextPutAll:, ... > From: stephane.ducasse(a)inria.fr > Date: Mon, 14 Feb 2011 21:48:21 +0100 > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] writing to the transcript stream > > probably. > When I did threadsafetranscript I was thinking that transcript is a tool but may be this is a stream. > > On Feb 13, 2011, at 3:59 PM, Hilaire Fernandes wrote: > > > I try the following > > > > Text fromUser storeOn: Transcript > > > > It failed, as ThreadTranscript is not a Stream, but according to PBE, > > Transcript is a Stream. > > > > Should I fill a bug ticket or is it a misuse? > > > > > > Hilaire > > > > -- > > Education 0.2 -- http://blog.ofset.org/hilaire > > > > > >

Feb. 14, 2011

[Pharo-project] Pharo 1.2 virtual sprint

by laurent laffont

Could we organize a Pharo 1.2 virtual sprint over IRC to resolve, kill, eleminate, eradicate, destroy remaining issues ? and learn together too. I can do this next week from monday to wednesday evening (France time zone). Laurent

Feb. 14, 2011

Re: [Pharo-project] Working with weak announcements...

by StÃ©phane Ducasse

good question :) On FHi, > I'm working with weak announcements, good we need that. Igor was telling me that the right anwser are ephemerons (but for that: gc change is required). Now it would be good to have first a solution at image level > trying to make it work, and I have a problem in #on:do: protocol (or #when:do:) > I try to explain: > > This method receives a block, not an object/selector, so I can't create a WeakMessageSend which is the appropriate message to handle in other cases. > Well, the real question is... how can I produce a "Weak BlockClosure reference" who can die if receiver dies? > I tried some hacks (really ugly hacks, btw), but fail completely. > Any idea? > > best, > Esteban

Feb. 14, 2011

Re: [Pharo-project] sprint in lille on march 12?

by StÃ©phane Ducasse

On Feb 14, 2011, at 9:52 PM, Tudor Girba wrote: > Hi, > > There was some mentioning of a Pharo Sprint after the Smalltalk School on March 12. Is there one, yes > or do we do some programming during the school days? yes that too I hope. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > >

Feb. 14, 2011

Re: [Pharo-project] shout and Pharo 1.2 or 1.3

by StÃ©phane Ducasse

Marcus you should learn how not to burn your energy. I think that this is important and I take pharo exactly has an exercise. I burned myself writing project proposals and budget so :) Kind of zen exercise because the problem with shout is not complex. Just that email communications are more difficult to communicate and to follow. Stef > >> I have been reading the related discussion in the bug tracker. It is not >> clear to me if finally shout will eventually work with 1.2. >> I am going to prepare a DrGeo public release where I want shout, I am >> wondering if I should just use early 1.3 Pharo to do (where shout works >> nicely). Are there any reason or pitfall I should be aware of before >> doing so? > > > If there is something so important so people would use 1.3 > instead of 1.2, then why do we not fix it? > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage > > We should really try to get 1.2 ready. this is getting really boring, and I really have > no energy left anymore for it. > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Feb. 14, 2011

Re: [Pharo-project] shout and Pharo 1.2 or 1.3

by StÃ©phane Ducasse

> I have been reading the related discussion in the bug tracker. It is not > clear to me if finally shout will eventually work with 1.2. It is now. We spent one hour together with ben and it was not difficult. Just needed time of people knowing both sides of the problems and we also fixed 1.3 Easy no? > I am going to prepare a DrGeo public release where I want shout, I am > wondering if I should just use early 1.3 Pharo to do (where shout works > nicely). Are there any reason or pitfall I should be aware of before > doing so? > > Thanks > > hilaire > > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

Feb. 14, 2011