- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Omnibrowser in 1.4
by Marcus Denker Aug. 30, 2011

Aug. 30, 2011

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. > >> 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. Marcus -- Marcus Denker -- http://marcusdenker.de

8 10

[Pharo-project] Pharo 1.3 release
by laurent laffont Aug. 30, 2011

Aug. 30, 2011

Hi, maybe I haven't read correctly the mailing-list but I still don't know if Pharo 1.3 is released or not, cannot find any official announcement, release date .... The website is misleading, I can help on this, but need to be sure. I've also prepared a french announcement but needs to be up to date before. Cheers, Laurent Laffont

3 5

Re: [Pharo-project] Omnibrowser in 1.4
by Marcus Denker Aug. 30, 2011

Aug. 30, 2011

On Aug 29, 2011, at 10:38 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. > Do not compare image size!!!!!! 1.4 is smaller only(!) because we unloaded ScriptLoader13. And every MC commit makes the image bigger, as does every update. > 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 want my live to be defined by being backward compatibe to what we have. Life is short. I mean that seriously: Should it be my life's goal to make a backward compatible system? I spend quite some time thinking about what to do with my future. Go to industry, have a real salary, and play with etoys the evening? Stay in research and write lots of papers with lots of greek letters that nobody reads? Or it there a third way possible? Maybe? But the idea of building a Smaltalk system whose only goal is to be compatbile to Squeak-minus-eToys I never even thought about ;-) >> > > 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? > Are there a lot of 1.0 and 1.1 users left? They don't submit bug reports, for sure. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] My view on where Pharo is heading
by Damien Cassou Aug. 30, 2011

Aug. 30, 2011

In my point of view, most people in the community wants a micro kernel for Pharo (or better no kernel at all) on top of which it would be possible to load packages such as a graphical interface, browsers, a network library... I see two ways to achieve this goal. 1) The immediate unloading way. In this way, the Pharo maintainers try to remove stuff as they are in the current image. However it is very complex as each stuff is not necessarily well packaged and has dependencies in a lot of other packages. Cycles in these dependencies make things even worse and would prevent these stuff from being loaded back. Some stuff are so complex that no one understands them anymore. 2) The make it better and unload way. Because the Pharo maintainers think the previous way is too difficult, they choose to start by making the current system better. This includes removing some stuff here and there, but also include replacing crappy stuff by better designed ones. When a stuff is correctly packaged it is going to be much easier to remove it and load it back. During the first phase the size of the system is going to decrease slowly as crappy stuff are being replaced or removed. But not as fast as people would like. However, during the second phase, the system will significantly and rapidly shrink because it will be possible to remove stuff without any problem. Even better, anyone will be able to load each stuff back. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

1 0

Re: [Pharo-project] Omnibrowser in 1.4
by Marcus Denker Aug. 30, 2011

Aug. 30, 2011

On Aug 29, 2011, at 10:56 PM, Jorge Ressia wrote: > 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. > So we than just make "Pharo" an unusable download and expect the users to evaluate and pick their favorite browser from 3 to-be-loaded ones? Do you think this is realistic? -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] Pharo 1.3 release
by Marcus Denker Aug. 30, 2011

Aug. 30, 2011

The state is the same as 3 week ago, (and I fear the same as in 3 weeks): -> image is finished, there are some (5 or so bugreport) that will be integrated as they get fixed, but this does not hold up the release -> What is missing are VMs and the one-click. I do not know which VMs to take. This has not changed in 3 weeks. So maybe we should just release with the same VMs as 1.2, just to get it done? Marcus On Aug 30, 2011, at 7:53 AM, laurent laffont wrote: > Hi, > > maybe I haven't read correctly the mailing-list but I still don't know if Pharo 1.3 is released or not, cannot find any official announcement, release date .... > > The website is misleading, I can help on this, but need to be sure. > > I've also prepared a french announcement but needs to be up to date before. > > Cheers, > > Laurent Laffont -- Marcus Denker -- http://marcusdenker.de

3 2

Re: [Pharo-project] Omnibrowser in 1.4
by Marcus Denker Aug. 30, 2011

Aug. 30, 2011

On Aug 29, 2011, at 10:56 PM, Sven Van Caekenberghe wrote: > 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 ;-) > Seaside builds for 1.3 and 1.4 are on my TODO list (like far too many other things). ESUG is nice, but it cuts into the time... -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] Deprecation policy
by Marcus Denker Aug. 30, 2011

Aug. 30, 2011

On Aug 30, 2011, at 1:35 AM, Sean P. DeNigris wrote: > Are pre-1.3 deprecated methods purposely put into protocol *deprecated13? > > For example: > String>>asDefaultDecodedString on: 2/13/2010 in: 1.1 > PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2 > SequencableCollection>>sortBy: on: 9/4/2010 in: 1.2 > SystemDictionary>>hasSpecialSelector:ifTrueSetByte: on: 3/20/2010 in: 1.1 Sometimes we move methods to keep them longer, somtimes methods get "lost" from the package because of accidental re-categoration, and than moved to the current deprecated package. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] Deprecation policy
by Marcus Denker Aug. 30, 2011

Aug. 30, 2011

On Aug 30, 2011, at 1:44 AM, Sean P. DeNigris wrote: > Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August, > 2011'. Does it matter? No > > -- > View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777671.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Bug or feature? XMLElement>>allElementsDo:
by Nicolas Anquetil Aug. 30, 2011

Aug. 30, 2011

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

5 4