- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Seaside] problem in configuration of swazoo

by Tudor Girba

Thanks, Janko. It works now. Cheers, Doru On 17 Jul 2011, at 23:56, Janko MivÅ¡ek wrote: > Hi Tudor, > > Try now. I published Swazoo once again, but I'm pretty sure I did > exactly that correction already. Anyway. I hope it works now well. > > Best regards > Janko > > S, Tudor Girba piÅ¡e: >> Hi Janko, >> >> The latest version of the ConfigurationOfSwazoo has a problem. >> >> Specifically, version '2.3.0.0' was recently changed to point to the Swazoo package version 'Swazoo-2.3beta2.6'. However, in Monticello we only have 'Swazoo-janko.3beta2.6'. >> >> Could you fix it, or should I try to do it? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Speaking louder won't make the point worthier." >> >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

July 17, 2011

Re: [Pharo-project] [Seaside] problem in configuration of swazoo

by Janko MivÅ¡ek

Hi Tudor, Try now. I published Swazoo once again, but I'm pretty sure I did exactly that correction already. Anyway. I hope it works now well. Best regards Janko S, Tudor Girba piÅ¡e: > Hi Janko, > > The latest version of the ConfigurationOfSwazoo has a problem. > > Specifically, version '2.3.0.0' was recently changed to point to the Swazoo package version 'Swazoo-2.3beta2.6'. However, in Monticello we only have 'Swazoo-janko.3beta2.6'. > > Could you fix it, or should I try to do it? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

July 17, 2011

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

by Tudor Girba

I am sure that improving the system is on everyone's intention. Now, let's go back to the problem and see what we can do about it :). Cheers, Doru On 17 Jul 2011, at 23:45, Lukas Renggli wrote: >> 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. > > I did not judge your work. I only pointed out that if new things are > integrated (like announcements) it might break with existing users > (and how, in this particular case). I am fine if this is the perfect > implementation for Moose, Glamour and Pharo itself; you just cannot > expect that it is perfect for everybody. There are always users that > need something else (in this case I suspect many); and it would be > cool if that could be facilitated. > > Lukas > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

July 17, 2011

[Pharo-project] problem in configuration of swazoo

by Tudor Girba

Hi Janko, The latest version of the ConfigurationOfSwazoo has a problem. Specifically, version '2.3.0.0' was recently changed to point to the Swazoo package version 'Swazoo-2.3beta2.6'. However, in Monticello we only have 'Swazoo-janko.3beta2.6'. Could you fix it, or should I try to do it? Cheers, Doru -- www.tudorgirba.com "Speaking louder won't make the point worthier."

July 17, 2011

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

by Lukas Renggli

> 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. I did not judge your work. I only pointed out that if new things are integrated (like announcements) it might break with existing users (and how, in this particular case). I am fine if this is the perfect implementation for Moose, Glamour and Pharo itself; you just cannot expect that it is perfect for everybody. There are always users that need something else (in this case I suspect many); and it would be cool if that could be facilitated. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 17, 2011

[Pharo-project] Stubbing class-side methods

by Sean P. DeNigris

I keep coming up against this situation over and over in testing. MyClass>>doSomethingWorthTesting ... now := DateAndTime now. ... I want to control DateAndTime class>>now to make this test determinate and simulate interesting edge cases, but can't figure out a good way. In Ruby, I could easily stub it because it's not a live system (or use dependency injection), but here I don't want to mess with the real DateAndTime class in case something goes wrong and leaves my system dirty. I really hate using dependency injection for this kind of thing (especially without Ruby's default parameter values). I've been creating MyClass>>now and stubbing that. Am I being paranoid, should I just hijack the real class and fix it when I'm done? What's the best way to do this? Thanks. Sean -- View this message in context: http://forum.world.st/Stubbing-class-side-methods-tp3674065p3674065.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 17, 2011

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