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

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

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

by Igor Stasenko

On 17 July 2011 22:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 17, 2011, at 9:57 PM, Lukas Renggli wrote: > >>>> Announcing something should not affect the existing exception handing. >>> >>> Yes but errors in handler should not break other announcements. >> >> I agree, but then it should be possible to intentionally abort the >> announcement handling. >> >> This behavior is used in OB to warn the user about an unsaved method >> and potentially abort the announcement processing. But then again, >> this will never work with the new Pharo announcements, because the >> handlers are stored in an IdentitySet and are executed in random order >> anyway. > > ok but if you do not say it how can we improve? > So now we learned that using an identitySet was a bad idea. > You see if you would have given information when you got the problems > we would have probably fixed everything. > No, i don't think its bad idea. A different subscriptions may not know about each other (otherwise, why you subscribing twice for same announcement, if you can do it only once?). And in such setup the announcement framework is there to provide a guarantees that announcement will be delivered to subscriber even if one/some of them fail to handle it properly and throw an exception. >From announcer point of view a general expectation that different subscriptions may not know about each other. (i think this is not questionable statement?) So, if you follow this expectation, it makes no sense to reason which subscriber should receive an announcement first and which one second. Because announcer simply broadcasting announcement to all interesting parties (subscriptions), and there is no need to maintain the order, but instead we should maintain the guarantee that announcement will be delivered to all subscriptions. If you look at this from given angle, you will see that instead, enforcing a specific order is bad idea. > >>>> Yes, but you should not interfere with intentionally raised exceptions >>>> (and this is not only for notifications). The current announcement >>>> implementation breaks many users and many legitimate use-cases. >>> >>> do you have some examples so that we can understand on real use cases? >> >> Any application that handles exceptions itself and that uses >> announcements likely breaks with then changes in Pharo 1.3: >> >> - Any UI tool that does interactions and queries through exception >> processing: OB, users of UIManager, MenuMorph, ... > > OB I know but this is notification, no? > UIManager? really for the progressNotification? > MenuMorph is using Exception? > >> - Any persistency layer that ties transactions to the stack (or >> process): Magma, OmniBase, Goods, ROE, ... >> - Any web framework (or other non-morphic UI tool) that has its own >> exception handling: Seaside, Kom, GTK, Cocoa, ... >> >>> Again there are parts of the system that we want really robust and >>> breaking the propagation of announcement because one is broken >>> is not really good. >> >> Now this is not really a big deal for me, OB works perfectly in Pharo >> 1.3 with its own "old" announcement implementation. > > this is not the point. We want to make the infrastructure really good. > So we will fix that but for that we need inputs. > If everybody "fixes" his stuff in his corner then we should better stop pharo. > >> It is just that everybody should be aware of the problem and have its own "simple" >> announcements when using any of the frameworks above. > > you know that this is not the good solution. So probably it was a bad idea to catch > everything and probably UnhandledError is a better choice. > Now again without feedback we will just progress but much slower. > But where the guarantees that other Exceptions resuming normally and not breaking a normal processing flow? And where the guarantees that all exception handlers sending #resume after done handling them? The problem that here we have conflict of interests: - we want that announcements to be always delivered to all subscribers - but one of the subscribers while handling anouncement may break the processing using Exception(s) and prevent others from handling an announcement. So, to peacefully resolve the conflict, we added #alwaysResuming flag to exception protocol. It should mean that: - an exception is _always_ resuming a normal processing flow after being handled. Note that it is more responsibility of implementors of exception handlers to maintain that property, rather than exception itself. In this case, only if you guarantee that exception won't break a normal processing flow, then on:fork: doesn't forking and not splitting the stack. Otherwise it have to fork (with all consequences) to ensure announcement delivery. Does that sounds reasonable? Also, let me remind you that exceptions are there is to handle an exceptional conditions in processing flow i.e. when something goes wrong and not as expected. So, it is perfectly reasonable to use #on:fork: to prevent announcement handling process from escaping the normal processing flow. Because normally , there should be no exceptions. For instance, in Seaside (if i remember correctly) it creates a separate process for handling request. And so, for dynamic variables you can use a process-specific storage , provided by Process>>environmentAt: and environmentAt:put:, rather than using exceptions to access dynamic variable values. Like that, you don't need to use exceptions and moreover it will work much faster, because unwinding stack each time you accessing the state is costly! > Stef -- Best regards, Igor Stasenko AKA sig.

July 18, 2011

[Pharo-project] about privShrinking

by StÃ©phane Ducasse

Hi pavel I removed the ref to RecentMessageSet since we will remove it. And I noticed that there was a reference to TranscriptModel, so may be we should remove it since I'm not sure that we will keep it. Or may be this is a good idea of have a model :) Smalltalk globals at: #Transcript put: TranscriptModel new. Stef

July 18, 2011

[Pharo-project] [update 1.4] #14044

by StÃ©phane Ducasse

14044 ----- - Issue 4530: Source enh. Thanks Veronica Uquillas-Gomez. - Issue 4529: Announcement delivery breaks if last subscriber is curtailed. Thanks Henrik Johanssen. Tx Stef

July 18, 2011

Re: [Pharo-project] Sound on Linux

by Lemuus

At least on OpenSuSE 11.4 x86_64 if you copy the pulse audio plugin from SqueakVM 4.4.7.2357-linux_i386, and the evaluate AbstractSoundSystem soundEnabled: true. The sound works. On Mon, Jul 18, 2011 at 8:55 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > To see if sound works on Linux, I grabbed Squeak 4.2 - it works, at least > on Ubuntu Lucid. In Pharo 1.3, I can't enable the sound preference. I'm > not sure if that's good or bad :) Any ideas? > > >

July 18, 2011

[Pharo-project] Sound on Linux

by Schwab,Wilhelm K

To see if sound works on Linux, I grabbed Squeak 4.2 - it works, at least on Ubuntu Lucid. In Pharo 1.3, I can't enable the sound preference. I'm not sure if that's good or bad :) Any ideas?

July 18, 2011

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

by StÃ©phane Ducasse

Yes I have the impression that this is what we should do and do it in 1.3 and 1.4 Stef > Another problem with the fork not mentioned yet, is the assumption all > subscriber actions will have been carried out by the time next statement > occurs. > fork:'ing breaks that, and you can't make the assumption true without > conflicting with the reason to fork: in the first place. > Another argument in favor of only forking on unhandled exceptions I guess :) > > @#after: gripe in previous post: meh, ansi... > > -- > 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. >

July 18, 2011