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

Re: [Pharo-project] Announcement real problems - please read and comment.

by Igor Stasenko

On 4 April 2011 16:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 4, 2011, at 1:16 29PM, Igor Stasenko wrote: > >> On 4 April 2011 12:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>>>>> Henrik what is your answer to problem 1 >>>>>>> >>>>>>> Problem 1 >>>>>>> Â Â - the second announcement was never sent, because the first one broke the second was blocked. >>>>>>> Â Â >> Â we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass >>>>>>> >>>>>>> Because we can get the system down just because one guy can register a bug. >>>>>> http://forum.world.st/Another-finalization-concern-error-handling-td2989615… >>>>>> >>>>>> It's basically the same. >>>>> ?? >>>> Same basic problem, same solutions apply. >>>> I'd rather not repeat the exact same discussion. >>>> Just exchange "finalization" with "announcement delivery" when reading the thread >>> >>> Igor what was exactly the summary? >>> >> >> Summary, in short, is following: >> >> we want to iterate over some arbitrary collection and perform an >> action per each element, like: >> >> collection do: [:each | each doSomeAction ] >> >> but the problem here is that if one action triggers an error, then >> your loop are interrupted and no other actions performed >> for the remaining elements of collection. >> >> So, we need such behavior , that guarantees that: >> a) all elements , except errorneous get processed >> b) if an error is unhandled by action , then show a debugger window >> >> in terms of implementation this means that we should run each action >> in separate forked process (and Eliot described a clever scheme how to >> avoid most overhead of forking). >> >> So then, even if some action will trigger an error, it won't interrupt >> the loop and error could be handled in debugger > > Or instead of forking each action, simply: > (changed to make OC copy) > deliver: anAnnouncement > Â Â Â Â | cls copy | > Â Â Â Â cls := anAnnouncement class. > > Â Â Â Â "using a copy, so subscribers can unsubscribe from announcer " > Â Â Â Â "Use OrderedCollection , so unwind protection is easier" > Â Â Â Â self protected: [ copy := subscriptions as: OrderedCollection ]. > Â Â Â Â self deliver: anAnnouncement to: copy > > (private category) > deliver: anAnnouncement to: subs > > Â Â Â Â subs do: > Â Â Â Â Â Â Â Â [:each | > Â Â Â Â Â Â Â Â [each deliver: anAnnouncement] > Â Â Â Â Â Â Â Â Â Â Â Â ifCurtailed: [self deliver: anAnnouncement to: (subs after: each)]] > then probably you can do it in right place - in subscription>>deliver: put ifCurtailed: handler. > > This has the added benefits of: > - No thread creation overhead (Not sure if how it's written avoids creating a block for argument to each ifCurtailed call though) > - Reproducibility. > Â Â Â Â Especially in the case Stephane gave, if you forking in separate threads, his code would appear to work when stepping in debugger. > Â Â Â Â There'd be mucho frustration and grumbling over announcements failing one second, but working the next. :) > > Downside is ofc that rest of subscribers won't be notified until you proceed/exit the debugger, but compared to reproducibility, that's a small price to pay imho. > Its really depends on use case, what is preferable behavior. For instance if you stall in debugger when delivering UI events, then no new events could be handled and you dead, so in cases like this you cannot afford to stop handler from processing events and wait for user intervention. Also, i think it would be nice to disable a subscription, so it won't receive any new announcements if it stopped under debugger, because if you don't do that, and new announcements are flowing at some constant rate, then you will have a tons of debugger windows popping out and no way to stop that :) > Cheers, > Henry > > -- Best regards, Igor Stasenko AKA sig.

April 4, 2011

Re: [Pharo-project] Last pending things for Pharo 1.2

by Mariano Martinez Peck

On Sat, Mar 12, 2011 at 8:19 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > So....here is the list of things I guess are pending: > > 1) "Release" all configurations included in Pharo (this is, > ConfigurationOfPharo and all it dependencies). I mean, we should NOT use or > depend on #development versions. > so...can someone check this is done? GUillermo and me did it once...but it seems a lot of stuff was updated once again > 2) Update the one click image to use latest cog images and "pharo prepared > vms". There are some issues regarding this... > Marcus, which is the status of this one ? > 3) Write down all the things/summary done in Pharo 1.2 > consider as done in nobody else comes with something better, > 5) Update SystemVersion current -->> Pharo1.2rc2 of 27 January 2011 update > 12340 > SystemVersion current ->> Pharo1.2.1 of 2 April 2011 update 12345 so..it is ok, isn't it ? can we forget this item ? > 6) Condense sources? condense changes? #cleanUpForRelease > > Marcus, is that necessary ? DEVImageCreator >> cleanUps ScriptLoader new cleanUpForRelease. "In Pharo 1.1 condenseChanges is VERY slow because of the new method trailers. So condensingChanges each time even when it is not needed is not a good idea anymore. So in case a condenseChanges is needed it should be done explicitly. Smalltalk condenseChanges." Smalltalk garbageCollect. I did that and I put that comment. Now that they are faster and that we have Hudson, should I put back the Smalltalk condenseChanges ? is there anything else needed? do we need a condenseSources ? -- Mariano http://marianopeck.wordpress.com

April 4, 2011

Re: [Pharo-project] [Pharo-users] Do we want this for Pharo 1.2 and futures?

by Mariano Martinez Peck

Discussion finished. Marcus, can we add in the PharoDev images a installScript.st with the code that was executed to generate the image? yes, the ConfigurationOfPharo load.... On Sun, Mar 13, 2011 at 6:52 PM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > installScript definitely yes. > > changelog is useful if it is accurate and maintained else better avoid > it. Packages I never found a reason for it to be in the zip. not very > useful for newbies because they don't now what a package is based only > in the name and for a experimented user, they can find the packages > directly in the image. > > So, I think that they won't be missing. > > Cheers > > El sÃ¡b, 12-03-2011 a las 20:13 +0100, Mariano Martinez Peck escribiÃ³: > > In Pharo 1.0 and 1.1 I used to include certain files in addition to > > the .image and .changes. These files were: changelog.txt, > > installScript.st and packages.txt > > So...what do you think? are they (still) useful ? if true, then we > > should add it to hudson. If not, we just ignore it. > > > > Thanks > > > > Mariano > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > -- Mariano http://marianopeck.wordpress.com

April 4, 2011

Re: [Pharo-project] Do you want to add the background picture to the image like we did with Pharo 1.1 ?

by Mariano Martinez Peck

Ok. Discussion finished. No background for Pharo 1.2. One less task to do On Tue, Mar 15, 2011 at 3:23 PM, Richard Durr <richard.durr(a)googlemail.com>wrote: > > I vote against using a picture as a background > > +1 > I like a gradient as background and preferences to specify an url / a file > of an image. :D > > > On Tue, Mar 15, 2011 at 12:14 AM, GermÃ¡n Arduino <garduino(a)gmail.com>wrote: > >> 2011/3/13 Tudor Girba <tudor.girba(a)gmail.com>: >> > I vote against using a picture as a background. >> > >> > Doru >> > >> > >> >> +1 >> >> GermÃ¡n. >> >> > -- Mariano http://marianopeck.wordpress.com

April 4, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Mariano Martinez Peck

I started to try to release 1.2. Not only I did the list of changes but also: 1) I asked if people still wanted the background: http://forum.world.st/Do-you-want-to-add-the-background-picture-to-the-imag… results: negative. So, no backgrund. White as it is now. 2) I asked what people wanted that used to be in 1.1: http://forum.world.st/Do-we-want-this-for-Pharo-1-2-and-futures-td3350721.h… guess how many replies? TWO. results: I would only nclude the installScript. I guess that Hudson could do that very easy, doesn't it ? marcus ? 3) I wrote down the pending lists: http://forum.world.st/Last-pending-things-for-Pharo-1-2-tp3350731p3350731.h… Sorry, I cannot do more. Cheers Mariano On Mon, Apr 4, 2011 at 4:33 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > > On Mon, Apr 4, 2011 at 4:31 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > >> >> On 04 Apr 2011, at 16:19, Marcus Denker wrote: >> >> > On Apr 4, 2011, at 4:09 PM, Sven Van Caekenberghe wrote: >> > >> >> >> >> On 04 Apr 2011, at 15:40, StÃ©phane Ducasse wrote: >> >> >> >>> Please help because we have not the steam for the splash organization. >> >> >> >> So we poor users have to do all the work ?? >> >> >> >> Seriously, what is the easiest/fastest way to get to a rough list of >> the changes between 1.1.1 and 1.2.1 ? >> >> >> >> From that list we could try to make a readable list for release notes >> and then we could try to make a list of bullet points / highlights. >> >> >> > >> > Mariano started a list: >> > >> > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo >> > >> > All things done should have a tracker entry: >> > >> > http://code.google.com/p/pharo/issues/list?can=1&q=milestone=1.2 >> > >> http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D1.2-DevImage >> >> OK, I will start reading through these lists and compare with what was >> written about the previous releases and see if I can come up with something >> by tomorrow. >> > > I will translate for the French announcement. > > Laurent. > > > > >> >> Sven >> >> >> > -- Mariano http://marianopeck.wordpress.com

April 4, 2011

Re: [Pharo-project] aciotns done in 1.2 please help Re: [ANN 1.2] 1.2.1 Full Release Image

by Mariano Martinez Peck

On Mon, Apr 4, 2011 at 4:46 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 04 Apr 2011, at 16:41, Mariano Martinez Peck wrote: > > > OK, I will start reading through these lists and compare with what was > written about the previous releases and see if I can come up with something > by tomorrow. > > > > > > What I did is: I spent 1 hour reading issues tagged as 1.2 and write down > the most important ones or just the topic. FOr example, for a certain topic > there are several issues. so, I just wrote the topic once. > > Your list looks just great Mariano, can I consider it to be complete ? > I don't know. I think this is not really important (why I send the email?) grrr anyway, I think we should realease NOW, and this should not a stopper. If the rest is ready, then we release, with that list, as it is now. If you can come tomorrow wiht more aactions, even better. Users will judge with their own use, not with a hand written list -- Mariano http://marianopeck.wordpress.com

April 4, 2011

Re: [Pharo-project] Transcript rant

by Igor Stasenko

On 4 April 2011 16:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Apr 4, 2011, at 3:59 PM, Toon Verwaest wrote: > >> On 04/04/2011 03:55 PM, StÃ©phane Ducasse wrote: >>>>>> +1 for both of Igor's mails! >>>>> Why? this is really important to have threadsafe transcript and it is good to have a look at >>>>> what juan did. >>>>> >>>>> We should be able to use a transcript even without morph. >>>> It's that exactly what Igor was fighting for? >>> ah ok this was totally unclear. >> I don't know the implementation, nor the old nor the new. I just read his email and thought it made a lot of sense. >> >> For example where he lost you, he's just saying that it shouldn't matter if the transcript is something that is showing something in a window in the image, or if it's streaming the data to some external client somewhere. The API should just be the writestream API where it's used, independent of how it's being viewed by the second user who is reading the output printed on the transcript. > > I agree on that :) > >> It sounds like at the moment it's mixed and the user can also start reading from the transcript... that seems wrong since the data might have been sent over the wire; thus being gone and not available anymore in the transcript. Viewing the transcript is something totally different than writing to it. > > Thanks. > Yes. Consider and API of well established unix logging facility such as syslog. >From application's point of view there is only one direction in communication: it writes to syslog, and syslog then directs content somewhere else (and where exactly is doesn't matters and not a concern of application). And its also thread safe, of course (but not at cost of having only single way to do things). And apparently there is no API to read what is just written (like #ensureCr, which implies reading the last character from stream to check if it is cr). In this respect an old implementation was much nicer in a sense that it could be replaced by different stream which responds to same protocol.. But now, Transcript is a class, and its much harder to replace it and as to me it is too hardwired. Maybe this is good for Cuis, but as to me, i consider Transcript as a generic/default logging facility in smalltalk system. I was planning to redirect Transcript to write to stdout when in headless mode (and when VMs will provide stdio communication out of the box). But how i suppose to do it now? Hacking existing class? And then again, what if someone wants to redirect transcript to socket (and its easy to imagine where we may need that - suppose you working with remote image and want to see its transcript). So, hacking the same class again? P.S. i know that maybe a preferable way to do logging is through 'self log:' protocol etc.. but lets face reality: there are a tons of code in system which using Transcript. And i don't think that we will abandon it in nearest future. So, lets just keep it and make it more nicer, but lets separate concerns. -- Best regards, Igor Stasenko AKA sig.

April 4, 2011

[Pharo-project] aciotns done in 1.2 please help Re: [ANN 1.2] 1.2.1 Full Release Image

by Mariano Martinez Peck

On Mon, Apr 4, 2011 at 4:31 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 04 Apr 2011, at 16:19, Marcus Denker wrote: > > > On Apr 4, 2011, at 4:09 PM, Sven Van Caekenberghe wrote: > > > >> > >> On 04 Apr 2011, at 15:40, StÃ©phane Ducasse wrote: > >> > >>> Please help because we have not the steam for the splash organization. > >> > >> So we poor users have to do all the work ?? > >> > >> Seriously, what is the easiest/fastest way to get to a rough list of the > changes between 1.1.1 and 1.2.1 ? > >> > >> From that list we could try to make a readable list for release notes > and then we could try to make a list of bullet points / highlights. > >> > > > > Mariano started a list: > > > > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotTwo > > > > All things done should have a tracker entry: > > > > http://code.google.com/p/pharo/issues/list?can=1&q=milestone=1.2 > > > http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D1.2-DevImage > > OK, I will start reading through these lists and compare with what was > written about the previous releases and see if I can come up with something > by tomorrow. > > What I did is: I spent 1 hour reading issues tagged as 1.2 and write down the most important ones or just the topic. FOr example, for a certain topic there are several issues. so, I just wrote the topic once. -- Mariano http://marianopeck.wordpress.com

April 4, 2011

[Pharo-project] Issue 3955 in pharo: Better implementation of the MorphTreeMorph auto select

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com CC: aplan...(a)gmail.com Labels: Nautilus Milestone-1.3 New issue 3955 by Benjamin...(a)gmail.com: Better implementation of the MorphTreeMorph auto select http://code.google.com/p/pharo/issues/detail?id=3955 Now use secondarySelectionColor defined by the current theme and the display is done like the selection Attachments: BetterColorForMorphTreeMorphSearch.3.cs 9.5 KB

April 4, 2011

Re: [Pharo-project] Announcement real problems - please read and comment.

by Henrik Johansen

On Apr 4, 2011, at 1:16 29PM, Igor Stasenko wrote: > On 4 April 2011 12:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>>>>> Henrik what is your answer to problem 1 >>>>>> >>>>>> Problem 1 >>>>>> - the second announcement was never sent, because the first one broke the second was blocked. >>>>>> >> we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass >>>>>> >>>>>> Because we can get the system down just because one guy can register a bug. >>>>> http://forum.world.st/Another-finalization-concern-error-handling-td2989615… >>>>> >>>>> It's basically the same. >>>> ?? >>> Same basic problem, same solutions apply. >>> I'd rather not repeat the exact same discussion. >>> Just exchange "finalization" with "announcement delivery" when reading the thread >> >> Igor what was exactly the summary? >> > > Summary, in short, is following: > > we want to iterate over some arbitrary collection and perform an > action per each element, like: > > collection do: [:each | each doSomeAction ] > > but the problem here is that if one action triggers an error, then > your loop are interrupted and no other actions performed > for the remaining elements of collection. > > So, we need such behavior , that guarantees that: > a) all elements , except errorneous get processed > b) if an error is unhandled by action , then show a debugger window > > in terms of implementation this means that we should run each action > in separate forked process (and Eliot described a clever scheme how to > avoid most overhead of forking). > > So then, even if some action will trigger an error, it won't interrupt > the loop and error could be handled in debugger Or instead of forking each action, simply: (changed to make OC copy) deliver: anAnnouncement | cls copy | cls := anAnnouncement class. "using a copy, so subscribers can unsubscribe from announcer " "Use OrderedCollection , so unwind protection is easier" self protected: [ copy := subscriptions as: OrderedCollection ]. self deliver: anAnnouncement to: copy (private category) deliver: anAnnouncement to: subs subs do: [:each | [each deliver: anAnnouncement] ifCurtailed: [self deliver: anAnnouncement to: (subs after: each)]] This has the added benefits of: - No thread creation overhead (Not sure if how it's written avoids creating a block for argument to each ifCurtailed call though) - Reproducibility. Especially in the case Stephane gave, if you forking in separate threads, his code would appear to work when stepping in debugger. There'd be mucho frustration and grumbling over announcements failing one second, but working the next. :) Downside is ofc that rest of subscribers won't be notified until you proceed/exit the debugger, but compared to reproducibility, that's a small price to pay imho. Cheers, Henry

April 4, 2011