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

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

Re: [Pharo-project] Pharo Future was: Re: Omnibrowser in 1.4

by StÃ©phane Ducasse

> I really do not understand where this feeling of bloating comes from. Perhaps it is from the fact that for a transitional period, we will have a couple of systems in parallel. But, this is necessary to move things forward and to have a smooth transition: > - The Announcements will replace SystemNotifier which is a hack > - The RPackage will replace PackageInfo which is a hack > - To remove PackageInfo and friends, we need to get the tools to work with RPackage > - I did not have enough time to take a closer look at Ring, but from what I understood it does not add much code but it should provide a nice layer for unifying several abstractions that were used for tools > - The old browser is a hack, so Nautilus should be a minimal implementation of a new browser that works with the RPackage. Now, I am not sure if Nautilus did manage to be minimal, but it would be a good goal and in the end it will result in a reduced code base. > - Shout can probably be debated, but for the little code that is added, it is not > - RB should be in the image because it is essential for people that want to code (and the developers that maintain the image do want that) > > I find these to be the right decisions. Having Core + Dev did not make sense because people that maintain Core, did not have the tools. Unifying the two with minimal overhead (and it is minimal in my view) is the right way to go. > > Besides, stressing the creation of a PharoMini will make sure things are modular. Thanks This is why we were working on a bootstrap, not just for fun. And yes our goal is to have a nice layered system with decent abstraction and not spaghetti code. For me stable means that we can build something without having to reimplement everything because everything is so brittle that each time we change something simple all the system shake. Stef

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by StÃ©phane Ducasse

Look at Scanner reference to get a feel! I do not call that simple, stable at all. Stef > > > >>>>> No more for me. >>>> >>>> Introducing more code into Pharo that depends on more parts of Pharo >>>> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it >>>> easier to maintain and change Pharo. Or did I misunderstand something >>>> about cohesion and coupling? :-) >>> >>> With that philosophy, we can just declare Pharo as finished and do something >>> else. >>> My point of view is that I invent new abstractions *and than use them* on and >>> for the system itself. >> >> 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? >> > > Is the current system simple and minimal? > > Do you think the Pharo we have is good enough to have a future? > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Aug. 29, 2011

[Pharo-project] [update 1.4] #14111

by StÃ©phane Ducasse

14111 ----- - Issue 4609: Syntax highlighting broken. ****Thanks**** Alain Plantec and Benjmain van Ryseghem

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Igor Stasenko

On 29 August 2011 19:47, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>> No more for me. >>>>> >>>>> Introducing more code into Pharo that depends on more parts of Pharo >>>>> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it >>>>> easier to maintain and change Pharo. Or did I misunderstand something >>>>> about cohesion and coupling? :-) >>>> >>>> With that philosophy, we can just declare Pharo as finished and do something >>>> else. >>>> My point of view is that I invent new abstractions *and than use them* on and >>>> for the system itself. >>> >>> 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? >> >> 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. 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. 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. >> 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? 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. I don't like some rough edges of Nautilus. And it is certainly having less features than OB. But.. I think if you compare it to basic browser which we have in our image.. you will see. (p.s. and yes i am totally agree with you - a sidebar buttons in Nautilus are ugly ;) -- Best regards, Igor Stasenko AKA sig.

Aug. 29, 2011

Re: [Pharo-project] Halt

by StÃ©phane Ducasse

sounds great. Stef On Aug 29, 2011, at 7:30 PM, Sean P. DeNigris wrote: > Thanks to Stephan Eggermont who paired with me all morning on this. > > Here are the results of the first pass in inbox > (SLICE-Issue-2394-Halt-SeanDeNigris.1): > > Object > * 16 methods deprecated > * 5 halt methods that now forward to Halt > > Globals - can remove #HaltOnce and #HaltCount (I don't know how) > > Halt class > * methods (all heavily refactored from the original Object implementation) > - 5 for halting API > - 3 to enable/disable haltOnce > - 6 private helpers > * 2 class instance variables (for haltOnce/onCount) > > World menu - updated to use Halt API > > Tests > * 6 new assertions in 2 test methods > * 4 test helpers for halt behavior > * changed other halt tests to use the helpers > > Questions remaining: > * countOn: (which I left it in for the time being) > - safety & scope (see earlier in thread) > - method name > > -- > View this message in context: http://forum.world.st/Halt-tp3774723p3776819.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 29, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Marcus Denker

On Aug 29, 2011, at 9:08 PM, Lukas Renggli wrote: >>>> 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. What exactly did we add in 1.2 and 1.3 other than Zinc and Finder? > > Yes, do something else. Be your own customer. Where is the next Reflectivity? > It will come. And it will require changes. Add some code, remove other code. Clients that require on deep system detail that changes will be impacted, too. I am sure you will not like it. I do not know how to move a system forward without changing it. Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 29, 2011

Re: [Pharo-project] Pharo Future was: Re: Omnibrowser in 1.4

by Tudor Girba

Hi, On 29 Aug 2011, at 21:03, Marcus Denker wrote: > > On Aug 29, 2011, at 8:55 PM, Marcus Denker wrote: > >> >> On Aug 29, 2011, at 8:47 PM, Lukas Renggli wrote: >>>> >>>> Is the current system simple and minimal? >>> >>> No, it is complex and it is getting bigger with every release. > > The size of the image is Monticello Meta Data and ScriptLoader. > > Just doing deleting the Monticello History, remove ScriptLoader > and do a Smalltalk cleanUp: true, and we are at 9.2MB Image size with tests. > > This is not that bad. I really do not understand where this feeling of bloating comes from. Perhaps it is from the fact that for a transitional period, we will have a couple of systems in parallel. But, this is necessary to move things forward and to have a smooth transition: - The Announcements will replace SystemNotifier which is a hack - The RPackage will replace PackageInfo which is a hack - To remove PackageInfo and friends, we need to get the tools to work with RPackage - I did not have enough time to take a closer look at Ring, but from what I understood it does not add much code but it should provide a nice layer for unifying several abstractions that were used for tools - The old browser is a hack, so Nautilus should be a minimal implementation of a new browser that works with the RPackage. Now, I am not sure if Nautilus did manage to be minimal, but it would be a good goal and in the end it will result in a reduced code base. - Shout can probably be debated, but for the little code that is added, it is not - RB should be in the image because it is essential for people that want to code (and the developers that maintain the image do want that) I find these to be the right decisions. Having Core + Dev did not make sense because people that maintain Core, did not have the tools. Unifying the two with minimal overhead (and it is minimal in my view) is the right way to go. Besides, stressing the creation of a PharoMini will make sure things are modular. Cheers, Doru > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Aug. 29, 2011