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

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

by StÃ©phane Ducasse

Let me put a last comment before going to bed. I think that you are unfair because - if you had a look at the list of features in 1.3 you will see that we removed a lot of bad code, - then if you look at the data that marcus sent recently, you will see that the image size did not change that much and that most of the space is taken by monticello timestamp, - finally I do not buy this growing argument because such argument already killed us when we were doing squeak. I prefer 5 nice little classes with a superclass than a fat one. It is easy to judge other work, but I can tell you that we are concerned about size and quality much more than average people. I'm mainly doing pharo on my free time and I'm spending a lot of energy in making it the best system I dream about. Now when is the last time that you said to us: guys you are doing a good job? Have a look at your emails and you will be surprised. Sometimes positive feedback is much better than absence of negative ones. Stef > > 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? > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 17, 2011

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

by StÃ©phane Ducasse

>> > > 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? How can we remove systemNotifier? How can we remove the update/change mechanism? I think that this kind of feedback is not really nice to hear from you may be you should pay attention not to hurt people that I supposed were close to you and perhaps friends. But may be not after all. Let me repeat it again our goal is really to make a minimal core but not more minimal than useless. For me having a Announcement framework that does not work for RPackage, Moose, Glamour, ... is not good. Stef

July 17, 2011

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

by Tudor Girba

Hi, On 17 Jul 2011, at 22:35, Lukas Renggli wrote: >>> 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. > > The new implementation is so complicated, I only start to understand > all implications now. People were telling me how cool and how > important the new implementation is, so I thought I better take my own > 3-method/2-class implementation that does exactly what was needed. > >>> - Any UI tool that does interactions and queries through exception >>> processing: OB, users of UIManager, MenuMorph, ... >> >> OB I know but this is notification, no? > > Yes, these are notifications. > >> UIManager? really for the progressNotification? > > ProvideAnswerNotification. > > And yes, there is also ProgressInitiationException for the progress > bar, which is not a Notification. > >> MenuMorph is using Exception? > > Yes. > > Just look at the subclasses of Exception and ask yourself which one > people are commonly handling. ZeroDivide, FileDoesNotExistException, > MessageNotUnderstood, ConnectionTimedOut, ProgressInitiationException, > ... are all Exceptions, some of them are resumable. > >>> 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. > > 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? I think it makes a lot of sense. I like very much what the core team is doing. I really do not see how Pharo is growing. I think it is getting more solid, and more modular every day. Yes, there are bumps along the way, but this is why feedback is so important. The Announcement system is very much internal because it is supposed to be used by the core to announce when something changes, and by the IDE to refresh. And yes, the IDE should should be in the feedback loop of the Core development, because it is a critical component. Cheers, Doru > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Value is always contextual."

July 17, 2011

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

by Lukas Renggli

>> 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. The new implementation is so complicated, I only start to understand all implications now. People were telling me how cool and how important the new implementation is, so I thought I better take my own 3-method/2-class implementation that does exactly what was needed. >> - Any UI tool that does interactions and queries through exception >> processing: OB, users of UIManager, MenuMorph, ... > > OB I know but this is notification, no? Yes, these are notifications. > UIManager? really for the progressNotification? ProvideAnswerNotification. And yes, there is also ProgressInitiationException for the progress bar, which is not a Notification. > MenuMorph is using Exception? Yes. Just look at the subclasses of Exception and ask yourself which one people are commonly handling. ZeroDivide, FileDoesNotExistException, MessageNotUnderstood, ConnectionTimedOut, ProgressInitiationException, ... are all Exceptions, some of them are resumable. >> 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. 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? Lukas -- Lukas Renggli www.lukas-renggli.ch

July 17, 2011

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

by StÃ©phane Ducasse

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. >>> 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. Stef > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 17, 2011

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

by Lukas Renggli

>> 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. >> 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, ... - 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. It is just that everybody should be aware of the problem and have its own "simple" announcements when using any of the frameworks above. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 17, 2011

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

by StÃ©phane Ducasse

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. >> in 1.3 we introduced on:fork: to ensure that for example a system announcement is processed even if a user announcement would break for the same registry. > > I saw that, but didn't understand the implications. > >> The idea is that on Error the stack is copied and forked and the current process is resumed. > > The problem is that the code does not only catches Error, but > Exception. This means it will also capture notifications, or any other > exception that your code might be handling. Indeed this is why we probably need to way to let the programmer define the exception that he does not want to be caught. >> Now with DynamicVariable (and probably Notification) >> the stack is cut and the resume of the notification or dynamic variable gets nuts because it does not find the information it needs. > > I think this is a serious problem in the new announcer framework. >From a certain perspective it also work better than the previous one, so this is not black and white. > Announcing something should not affect the existing exception handing. Yes but errors in handler should not break other announcements. > I believe the problem could be fixed (for most users) if announcements > would catch UnhandledError only, this exception is raised to open the > debugger. May be, we will think about that. >> We believe that on: fork: will really improve the stability of the system (ui process, announcement). We want to be able to debug UI process without having to rinstall the current process >> and all the current magic. I do not want to see the new package system on its knees just because somebody registered a broken announcement on a systemEvent (it already happened before on:fork:). > > 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? because we were checking ours and it worked for us. 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. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 17, 2011

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

by Lukas Renggli

> The on:fork: fixes proposed by Igor and Stef plus overriding DynamicVariable>>alwaysResuming, seem to solve the problem. No, that doesn't solve the problem. People throw exceptions (not just notifications) and they expect that their handlers are able to catch them. Furthermore, it is an obscure counterpart of #isResumable (i don't understand the difference). Lukas -- Lukas Renggli www.lukas-renggli.ch

July 17, 2011

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

by Tudor Girba

The issue described by Andrei seems to happen only in the context of an announcement. The on:fork: fixes proposed by Igor and Stef plus overriding DynamicVariable>>alwaysResuming, seem to solve the problem. Btw, how can we get the new implementation of on:fork:? It would be cool to get someone else to test them. Cheers, Doru On 17 Jul 2011, at 21:06, Philippe Marschall wrote: > 2011/7/17 Lukas Renggli <renggli(a)gmail.com>: >> Not sure why the request context is suddenly gone in your code. >> >> It could be that this has something to do with the announcements, the >> implementation changed drastically in Pharo 1.3. I had to revert the >> announcements to the original implementation in OB to make them work. >> >> Do you properly receive the request context before doing the >> announcement, just to rule out any problems in Seaside? Seaside has >> not really been tested on Pharo 1.3 yet, our builds are all based on >> stable Pharo 1.2.1. > > I've been using Pharo 1.3 for some time now and it seem to work so far. > > Cheers > Philippe > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

July 17, 2011

Re: [Pharo-project] image freezes when setting time "back"

by Philippe Marschall

On 17.07.2011 12:17, StÃ©phane Ducasse wrote: >>>> >>>> >>>>> Hi >>>>> >>>>> I have had the following experience. I'm running Pharo 1.3 on a Linux >>>>> box where the time is set on start up using ntp. The hardware clock is >>>>> set to the local time (because I'm dual booting). When there is no >>>>> network connection during booting the system the clock is two hours >>>>> "ahead" until I get network connection and set the time using ntp. When >>>>> a Pharo image is running during this the UI freezes and doesn't react >>>>> anymore. Does anybody else observe this? Is this a known limitation? >>>> >>>> not that we are aware of. >>>> what a bug.... :) >>> >>> i reported it and we discussed it months ago. >> >> So I don't need to report a bug or anything? > > probably on the cog issue tracker. Indeed: http://code.google.com/p/cog/issues/detail?id=15 Cheers Philippe

July 17, 2011