- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] Omnibrowser in 1.4

by StÃ©phane Ducasse

>>>> Is the current system simple and minimal? >>> >>> No, it is complex and it is getting bigger with every release. >>> >>>> 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. >> >> So? Maybe we should just stop and do something else. > > No and yes. > > No, don't stop: The cleanup process in Squeak 3.9, Pharo 1.0 and Pharo > 1.1 was awesome. The system got smaller and more stable with every > release. > > Yes, do something else. Be your own customer. Where is the next Reflectivity? Do you think that we are not using Pharo? We are. And we got burned. When is the last time I was using a decent browser? I do not know. Why because I cannot wati 30 min that the tools get loaded in the integration image. Since I burn images like hell one every two minutes. So why did we start more than one year ago to work on a fast binary serializer? I let you guess. But the road is still long. Now just let me tell you that the state of the code definition was so awful (I mean really really really awful) that we burnt hours with johan brichau (far from an idiot), veronica and ben. Benjamin lost days because of this fucking state of the system to build a simple messageListbrowser. Why because a class comment is a method definition with the selector starting with C because the abstraction were wrong or inexistant, not class definition... So may be you do not like Ring and this is ok. Now I want an abstraction so that we can build a remote browser by plugging simply rTalk + nautilus + ring. With the current state of the system this was simply impossible. I want to be able to browse senders in the past and compare them with the current version. Because we use prehistorical tools even if we could have something like torch to help us. I cannot see anymore SystemChangeNotifier (even if this was far better than without) PackageInfo, PackageOrganizer with lazy identification of packages so that when you do an analysis you have to ask sometimes twice to packageOrganiser and packageInfo. Ask cyrille the time he spent there. I want one good browser, one code model (to be used by all the tools), one system notifier and a good one. One AST. For example, did you check the size of Zinc, much larger than the previous crap. So? What conclusion should we draw? Fuel will have probably more classes than IS, DataStream, SmartRefStream but more tests.... And pluggable. So once we will achieved that then it will be ok. And again again again our goal is to have a modular system. At ESUG I was discussing with goran and other to see how we could have pluggable traits in the kernel (so that we can have a kernel without them). Now lukas it would be good that we all spend less time reading and writing these mails. Stef

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Lukas Renggli

>>> 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

Aug. 29, 2011

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

by Nicolas Anquetil

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? nicolas

Aug. 29, 2011