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

Re: [Pharo-project] New 1.4 image on inria forge.

by Pavel Krivanek

Hi Stef, is there some progress with inaccessible build server? Or are we waiting on Marcus? Cheers, -- Pavel On Mon, Jul 18, 2011 at 6:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > https://gforge.inria.fr/frs/download.php/28785/Pharo-1.4-14048.zip > > Stef > >

July 18, 2011

[Pharo-project] New 1.4 image on inria forge.

by StÃ©phane Ducasse

https://gforge.inria.fr/frs/download.php/28785/Pharo-1.4-14048.zip Stef

July 18, 2011

[Pharo-project] [update 1.4] #14048

by StÃ©phane Ducasse

14048 ----- - Issue 4528: Exception on:fork: enhancement. Thanks Igor Stasenko and Lukas Renggli for the idea and ... Stef

July 18, 2011

[Pharo-project] [update 1.4] #14048

by StÃ©phane Ducasse

14048 ----- - Issue 4528: Exception on:fork: enhancement. Thanks Igor Stasenko and Lukas Renggli for the idea and ... Stef

July 18, 2011

Re: [Pharo-project] ESUG 2011 Innovation Technology Awards reminder

by Jordi Delgado

Hi, New deadline for submitting your software to ESUG 2011 Innovation Technology Awards: ----------> August 15, 2011 <---------- Complete information at: http://esug.org/Conferences/2011/InnovationTechnologyAwards Bests, Jordi > Hi, > > Just a reminder: > > ESUG 2011 Innovation Technology Awards > (http://esug.org/Conferences/2011/InnovationTechnologyAwards) > > We are proud to announce the 8th Innovation Technology Awards. > > Have you written innovative Smalltalk? The developers of any > Smalltalk-based software can enter by submitting a 3-5min video of > their software. Entrants demo their systems in a session at the end of > Monday August 22nd 2011, after which the conference attendees vote. (A > vote consists in providing a sorted list of 3 preferred pieces of > software.) > > The top 3 teams with the most innovative software will receive, > respectively, 500 Euros, 300 Euros and 200 Euros. The results are > announced in the Awards ceremony that is held during the social event. > > Applicants should provide the following information on the conference > registration server. Once you have registered your personal info, an > "Awards" menu allows submitting your software. You can provide this > information when you first register, or login again later and update > your details. > > Info to provide: > > Name of the software > Licence information (free, or shareware, or a commercial) > Name of the Smalltalk dialect used > Names, Affiliation and Country of developers > URL for a video (3-5 min) showing a screencast / demo of the software > URL for downloading the software or at least a runnable demo > > Deadline: 30th of july > > Any Smalltalker can apply (students, companies, ...). > The presented piece of code/software should be written in Smalltalk or > directly support Smalltalk (e.g. Smalltalk VM). > All Smalltalk dialects are accepted. > The applicant should own the copyright/copyleft of presented code or > at least be the official representative of the copyright/copyleft > owner. > The software should be available on-line for evaluation (time-limited > evaluation version, demo version, free for non-commercial use ...). > > Bests, > > Jordi

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Igor Stasenko

On 17 July 2011 22:35, Lukas Renggli <renggli(a)gmail.com> wrote: > > IMHO, the goal of Pharo should be to provide a minimal Smalltalk > system where people Pharo can load what they need. Instead Pharo keeps > on growing. I would prefer a system where I can decide myself what > libraries and tools I want to use. I am sure that the current > Announcement implementation can be fixed, but does it really make > sense that the core team bothers about something that could be > external? > No, Lukas. Announcements is not external and not about growing the system. It is still about shrinking it. As you may know, historically there's a lot of different event delivery mechanisms in image. Some of them: Object>>changed SystemChangeNotifier Morphic ActionSequence/WeakActionSequence and i am sure i missed couple more. And we're planning to replace all of them with single but solid Announcement framework. So, it will clean a lot of places and instead will shrink system considerably. That's why we wanting to have a solid foundation - a robust announcements framework. > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Best regards, Igor Stasenko AKA sig.

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by StÃ©phane Ducasse

On Jul 18, 2011, at 5:11 PM, Igor Stasenko wrote: > Ok. Here the fix. > > I don't like an idea to introduce #alwaysResuming because it brittle. > Catching only UnhandledError seems like a good plan. > (other stuff will be catched by ifCurtailed: anyways, so we're safe). I agree. I will integrate it now. Stef

July 18, 2011

[Pharo-project] [update 1.4] #14047

by StÃ©phane Ducasse

14047 ----- - Issue 4527: serialPort enh. Thanks Bill Schwab. - Fixing getPreamble:

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by Igor Stasenko

Ok. Here the fix. I don't like an idea to introduce #alwaysResuming because it brittle. Catching only UnhandledError seems like a good plan. (other stuff will be catched by ifCurtailed: anyways, so we're safe). -- Best regards, Igor Stasenko AKA sig.

July 18, 2011

Re: [Pharo-project] [Seaside] Problem with announcements in Seaside when using Pharo 1.3

by StÃ©phane Ducasse

>>> >>> >> Lukas suggestion of changing it to fork on UnhandledErrors is a perfectly >> reasonable solution. >> >> In case handlers outside the delivery mechanism itself don't resume, well, >> the ifCurtailed: block of deliver:to: takes care of delivery to the >> remaining subscriptions. :) >> (except there's a bug when asking for after: of last element... ifAbsent: >> block used _both_ when element not found, AND when there are none after >> it??) >> > Ah, yes. We have ifCurtailed: there as well. So, putting UnhandledError > in delivery sounds like good way to resolve the conflict of interests. So I let you propose a fix and I will integrate it because I like to do idiot actions :) >> You can still break it though, by using a handler which enters an infinite >> loop/sleep forever, etc... >> I agree with Phillipe: "The only way to fix broken code is to fix broken >> code, not by adding >> additional hacks.". >> Robustness is desirable, but only to a certain extent. (IE guard against >> unforeseen errors, not those handled incorrectly) >> >> As for Lukas' concerns not addressed by switching to UnhandledError: >> In my experience when using announcements in VW, relying on delivery order >> of announcements isasking for trouble later on... >> The code paths get hard to follow, maintainability becomes a nightmare as >> adding new subscribers/modifying old ones might introduce subtle bugs, etc. >> For the use case you described in OB, why not split it into two >> announcements instead, the first one vetoable in the sense Vassily wrote >> about in the blog, and the second announced only if first not vetoed? >> > indeed.

July 18, 2011