- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] fun bug: fileouting method with a $!, produces $!!

by StÃ©phane Ducasse

Yes I know. To me, saving a method should make sure that we can reload it and this is not the case. So to me this is a bug. try to fileout getPreambleFrom: aFileStream at: position | writeStream | writeStream := String new writeStream. position to: 0 by: -1 do: [ :p | | c | aFileStream position: p. c := aFileStream basicNext. c == $! ifTrue: [^ writeStream contents reversed] ifFalse: [writeStream nextPut: c]] :) I do not see why the system should not save it correctly even if !! is used as a chunk separator. Stef On Jul 18, 2011, at 4:55 PM, Lukas Renggli wrote: > !! Is the escaping of a single ! (like '' is the escaping of ' in a > string), because the ! Is used to separate junks. > > Lukas > > On Monday, 18 July 2011, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> Hi >> >> with veronica we found a fun bug. >> If you have a method with a $! and you file it out. you get $!! in the fileouted file. >> >> http://code.google.com/p/pharo/issues/detail?id=4531 >> >> Stef >> > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 18, 2011

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

by Igor Stasenko

On 18 July 2011 13:20, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > StÃ©phane Ducasse wrote: >> >> We will think hard and see what is a reasonable solution. >> What we want is the garantee that announcements are processed, that UI >> continue to work even if a piece of code break part of it, same for event >> handling. >> >> > 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. > 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. > Cheers, > Henry > > > > -- > View this message in context: http://forum.world.st/Problem-with-announcements-in-Seaside-when-using-Phar… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

July 18, 2011

Re: [Pharo-project] fun bug: fileouting method with a $!, produces $!!

by Lukas Renggli

!! Is the escaping of a single ! (like '' is the escaping of ' in a string), because the ! Is used to separate junks. Lukas On Monday, 18 July 2011, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi > > with veronica we found a fun bug. > If you have a method with a $! and you file it out. you get $!! in the fileouted file. > > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4531 > > Stef > -- Lukas Renggli www.lukas-renggli.ch

July 18, 2011

[Pharo-project] fun bug: fileouting method with a $!, produces $!!

by stephane ducasse

Hi with veronica we found a fun bug. If you have a method with a $! and you file it out. you get $!! in the fileouted file. http://code.google.com/p/pharo/issues/detail?id=4531 Stef

July 18, 2011