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

[Pharo-project] Deprecation policy

by Sean P. DeNigris

I want to add a comment to #deprecated:on:in: This is my understanding (it is implemented inconsistently in 1.4 update #14112): For methods: 1. Have the method call deprecated:on:in: as its first step - the versionString should be e.g. 'Pharo1.4' (although I found #Pharo1.4, see the problem; and '1.4', those were mine, hee hee). Is it redundant to say 'PharoXxx'? 2. Move the method to protocol e.g. deprecated14 for Pharo 1.4 For classes: 1. Move to Category e.g. 'Deprecated14' for Pharo 1.4 2? Should #deprecated:on:in: be called from the methods? It's inconsistent in the image and seems unnecessary, except maybe for some class-side methods. Is all this correct? Thanks. Sean -- View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777647.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Bug or feature? XMLElement>>allElementsDo:

by Levente Uzonyi

On Mon, 29 Aug 2011, Nicolas Anquetil wrote: > In XML-Parser-Nodes we have: > > XMLNodeWithElements > XMLDocument > XMLElement > > A document is composed of elements that can hold recursively other elements > > XMLNodeWithElements implements (in protocol enumerating) > allElementsDo: aBlock > "Descend depth-first visiting each element with aBlock." > > self hasElements > ifTrue: [self elementsDo: [:each | each allElementsDo: aBlock]] > > Looks perfectly normal to me > But then: > > XMLElement implements (in protocol searching !) > allElementsDo: aBlock > "See superclass version." > > aBlock value: self. > > super allElementsDo: aBlock. > > which means that > anXMLElement allElementsDo: [...] > runs first on itself and then on its elements ?!? > Seems counter intuitive to me. > > Should I remove this? IMHO you shouldn't, because it is enumerating the whole tree, which is exactly what I'd expect from this method. But the method should be recategorized. Levente > > nicolas > >

Aug. 29, 2011

[Pharo-project] NonRentrantWeakMessageSend

by StÃ©phane Ducasse

does it make sense to have to have WeakMessageSend not been reentrant? Because we could merge WeakMessageSend and NonRentrantWeakMessageSend. Or we could move the two subclasses of WekMessageSend to the same package as WeakMessageSend or alternate solution. Rename Polymorph-EventEnhancements into Kernel-Enhancements. What do you think? Stef

Aug. 29, 2011

[Pharo-project] [update 1.4] #14112

by StÃ©phane Ducasse

14112 ----- - Issue 4550: methodSymbol is a bad name for selector. http://code.google.com/p/pharo/issues/detail?id=4550 - Issue 4711: Pharo 1.4 has wrong link to inbox. Thanks Sean De Nigris. http://code.google.com/p/pharo/issues/detail?id=4711 - Issue 4710: Incorrect comment for ProtoObject>>pointersToExcluding: Thanks Sean De Nigris. http://code.google.com/p/pharo/issues/detail?id=4710 - Issue 2394: Halt :) Thanks Sean De Nigris and Stefan Eggermont. http://code.google.com/p/pharo/issues/detail?id=2394 Stef

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by StÃ©phane Ducasse

On Aug 29, 2011, at 11:13 PM, HernÃ¡n Morales Durand wrote: > Hi Stef, > > I just want to know if OB will be supported in Pharo >= 1.4 even if > you don't maintain it, because I've spent energy and time learning the > framework, and I have written one developer guide for OB and I have > planned at least 5 more browsers. I did that too sadly. Alex and me wrote a complete chapter for Pharo by example 2. Now I do not invest in system that cannot handle multiple selection and trees. So good luck. For me trees are the basic minimum. Stef

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by HernÃ¡n Morales Durand

Hi Stef, I just want to know if OB will be supported in Pharo >= 1.4 even if you don't maintain it, because I've spent energy and time learning the framework, and I have written one developer guide for OB and I have planned at least 5 more browsers. 2011/8/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Aug 28, 2011, at 12:45 PM, Sean P. DeNigris wrote: > >> >> Lukas Renggli wrote: >>> >>> There are currently no plans to make OB work in upcoming Pharo >>> versions; Pharo 1.4 is supposed to have its own much better browser >>> framework. > > People can use OB if they want. Since we never maintained OB (only lukas and we are grateful for that) > we will just continue like that. We cannot take responsibility to maintain something we do not understand in addition to all the rest. > >> Until that happens, all development in Pharo 1.4 will be done without a >> refactoring browser? > > It was always like that in the past. Just that you use the image with the work of lukas loaded. > Now for 1.4 yes we are fedup to use the old browser without RB. So Benjamin started to write some > widgets for all the request question of RB engine so that Nautilus supports RB. > > So you see we are improving the core image. > > Stef > >> >> -- >> View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3774231.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Jorge Ressia

Hi guys, I am completely for inventing something new. However, I do not think this is the right model for doing so. In a sense we are getting static, we put some tools in the image and expect people to use them. I think that this is going to be contra productive. I believe that a much better model would be a dynamic one in which people can load the tools that make them more productive. Moreover, this model will force us, developers, to better target our tools. Make clear which are their objectives, showing their benefits, improve their design for understandability and extension and thus getting feedback and interested people. At the end better tools will emerge. In a word, better products, with a "natural selection" process. HTH, Jorge On Mon, Aug 29, 2011 at 10:37 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> Is the current system simple and minimal? >>> >>> No, it is complex and it is getting bigger with every release. >> >> No, i wouldn't say so. >> >> Most fixes and improvements are still about cleaning things out and fixing bugs. >> But not about new features. > > Yes, you are right. In fact Pharo 1.4 is roughly 1 MB smaller than Pharo 1.3. > >> Even if you consider Zinc as a movement towards "getting bigger", >> consider an alternative: >> having library which follows standards, or keep using hacks which were >> not complete and useful only >> for most simple cases. > > Zinc is an excellent example, because it is fully backward compatible. > I don't see that with RPackage, SystemAnnouncements, Ring, Shout > (before Alan fixed it), with the proposed RB changes, ... > >> I am also against growing system unless it is necessarily. >> In 1.3. i added a new 'non-interactive' mode and non-interactive ui >> manager. And this was necessarily, because we need a way >> to deal with "hanging images" in headless mode. >> Now we can run images on jenkins, knowing that it will never enter >> 'click ok to proceed' state. > > Yes, this is cool. > >>>> Do you think the Pharo we have is good enough to have a future? >>> >>> No, there is a lot to be improved. I think the future of Pharo is what >>> can be built on top, not what can be integrated and forced upon >>> everybody. >> >> Lukas, there is nobody forcing anyone. >> How we (or anyone else) can force people to use Pharo? > > Right, but you can easily force people not to follow. I don't > understand why all the people that still use Pharo 1.0 or 1.1 don't > speak up? > >> A new and 'unproven' tools are 'forced' into images mainly to collect feedback. >> And i think it is good strategy, because most people *including me* >> are too busy/lazy to go & download and install new stuff and try it >> out. > > Don't we have all these automatic builds with all these tools > pre-loaded? There could be a list of links to these builds on the > website and like/+1/report buttons. That would likely yield some > discussions and give some time to investigate ... > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Jorge Ressia www.jorgeressia.com

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Sven Van Caekenberghe

Lukas, On 29 Aug 2011, at 19:53, Lukas Renggli wrote: > I disagree; I would like a small and stable Pharo in which crazy ideas > can be realized. For that I don't need fancy abstractions, but a > minimal, simple and absolutely stable system in which I can load and > do whatever I want. Maybe this is just me? I guess it all depends on your point of view. I can imagine that for you a clean minimal core is important as you build your own universe. But for most regular users, more stuff is needed. In practice, the core/dev difference was not optimal for all the reasons given before. I really feel crippled in a core image. And I don't like having to do long builds myself. I switched to 1.3, but I am using your one-click image because I need Seaside and there is no client build in Pharo any more. (Thx, BTW ;-) And yes, I think many Pharo users stay away from the more recent builds (1.4 for sure, but also 1.3) until the dust has settles (meaning, important third party code has been ported). But I also think that bold moves going forward are necessary, else nothing will ever change. Sven

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by StÃ©phane Ducasse

>> > > Zinc is an excellent example, because it is fully backward compatible. > I don't see that with RPackage, SystemAnnouncements, Ring, Shout > (before Alan fixed it), with the proposed RB changes, ... I do not understand how SystemAnnouncements could be fully backward compatible, then and this is the most important aspect of pharo. Same for RPackage, why should I reproduce broken semantics like overrides (it never worked over the last 5 years). if we do not fix the infrastructure to be aligned better stop and we will not stop so :) Now I will not comment anymore on this thread because I could have integrated 4 fixes but I spent time arguing the obvious instead. Stef

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by StÃ©phane Ducasse

On Aug 29, 2011, at 10:37 PM, Lukas Renggli wrote: >>>> Is the current system simple and minimal? >>> >>> No, it is complex and it is getting bigger with every release. >> >> No, i wouldn't say so. >> >> Most fixes and improvements are still about cleaning things out and fixing bugs. >> But not about new features. > > Yes, you are right. In fact Pharo 1.4 is roughly 1 MB smaller than Pharo 1.3. > >> Even if you consider Zinc as a movement towards "getting bigger", >> consider an alternative: >> having library which follows standards, or keep using hacks which were >> not complete and useful only >> for most simple cases. > > Zinc is an excellent example, because it is fully backward compatible. > I don't see that with RPackage, SystemAnnouncements, Ring, Shout > (before Alan fixed it), with the proposed RB changes, ... lukas please do not ask impossible suff. This is boring after a while. I'm not doing pharo to be compatible with broken abstractions. >> I am also against growing system unless it is necessarily. >> In 1.3. i added a new 'non-interactive' mode and non-interactive ui >> manager. And this was necessarily, because we need a way >> to deal with "hanging images" in headless mode. >> Now we can run images on jenkins, knowing that it will never enter >> 'click ok to proceed' state. > > Yes, this is cool. > >>>> Do you think the Pharo we have is good enough to have a future? >>> >>> No, there is a lot to be improved. I think the future of Pharo is what >>> can be built on top, not what can be integrated and forced upon >>> everybody. >> >> Lukas, there is nobody forcing anyone. >> How we (or anyone else) can force people to use Pharo? > > Right, but you can easily force people not to follow. I don't > understand why all the people that still use Pharo 1.0 or 1.1 don't > speak up? > >> A new and 'unproven' tools are 'forced' into images mainly to collect feedback. >> And i think it is good strategy, because most people *including me* >> are too busy/lazy to go & download and install new stuff and try it >> out. > > Don't we have all these automatic builds with all these tools > pre-loaded? There could be a list of links to these builds on the > website and like/+1/report buttons. That would likely yield some > discussions and give some time to investigate ...

Aug. 29, 2011