February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Workspace API

by StÃ©phane Ducasse

> >>>> >>>> > > We stopped fixing the kernel in order to try and facilitate some > harmony > through some tools support. One result was LPF, another MC1.6, and of > course the invisible man, Bob. > > Now you have all the experts, why doesnt someone who knows about > traits > help Matthew to fix SystemEditor to work with traits, then we would > all > have atomic loading, and a 3x performance improvement in MC. time time time have you seen that adrian is working on trait sharing and that we are waiting for that since a couple of months or more. Stef

Feb. 12, 2009

Re: [Pharo-project] [ANN][Dev-Images] February 2009 versions

by Klaus D. Witzel

On Tue, 10 Feb 2009 11:57:40 +0100, Damien Cassou wrote: > Hi, > > I've just uploaded new dev and web images based on > Squeak3.9.1-7075, Squeak3.10.2-7179 and Pharo0.1-10231. > > More information and download: > http://damiencassou.seasidehosting.st/Smalltalk/squeak-dev > Pharo-based images can be downloaded at: > http://code.google.com/p/pharo/wiki/Downloads?tm=2 This (Pharo) comes with 18MB - pharo0.1-10231dev09.02.1.changes but the change sorter is empty. Do I miss something? > Download statistics at > http://damiencassou.dabbledb.com/publish/dev-imagesdownloads > > Changes in this version: > --------------------------- > > - Pharo images are based on version 10231 > - Polymorph fixes (by Gary Chambers) > - OmniBrowser changes (by David RÃ¶thlisberger) > - Refactored auto-selection of list items to be easier extensible > - Extended and improved traits integration (various new features) > - Integrated OB patches done by various people > - Improved compatibility to Polymorph (button colors, scrollbars) > - Several defects corrected > - Magritte and Pier have been updated to version 1.1 (by Lukas Renggli > and Tudor Girba) > > Contained packages: > ------------------------ > > This image contains the following packages (some packages are only in > the squeak-web image or 3.10-based images): > > Aida version 5.6 > Algernon version 1.2 > AST version 160 > AutomaticMethodCategorizer version 0.25 > AutomaticMethodCategorizerOB version 0.2 > DynamicBindings version 2.7 > eCompletion version 0.102 > eCompletion-Traits version 0.1 > eCompletionOmniBrowser version 0.5 > Installer version 4.3.284 > KomHttpServer version 7.0.30 > KomServices version 1.12 > Magritte-Model version 1.1.331 > Magritte-Seaside version 1.1.283 > Magritte-Tests version 1.1.148 > OB-Enhancements version 0.292 > OmniBrowser version 0.436 > OmniBrowser-Algernon version 0.5 > OmniBrowser-Full version 0.27 > OmniBrowser-Morphic version 0.74 > OmniBrowser-Refactory version 117 > OmniBrowser-Regex version 0.9.1 > OmniBrowser-Standard version 0.389 > Pier version current > Pier-Blog version 1.1.103 > Pier-Documents version 1.1.7 > Pier-EditorEnh version 1.1.17 > Pier-Model version 1.1.263 > Pier-Seaside version 1.1.331 > Pier-Security version 1.1.119 > Pier-Tests version 1.1.116 > Polymorph EventEnhancements version 1.1 > Polymorph Geometry version 1.1 > Polymorph TaskbarIcons version 1.0 > Polymorph ToolBuilder version 1.2 > Polymorph Tools Diff version 1.3 > Polymorph Widgets version 1.3 > Refactoring Core version 17 > RoelTyper version 0.60 > RSRSS2 version 2.8.3.11 > Scriptaculous version 2.8.3.242 > ScriptManager version 0.6 > Seaside version 2.8.3.572 > Seaside-Adapters-Core version pmm.2.mcz > Seaside-Adapters-Swazoo version 9 > Seaside-Squeak-Adapters version pmm.3.mcz > SeasideAdaptersCompatibility version pmm.1.mcz > Shout version 3.15-tween.72 > ShoutWorkspace version 1-tween.4 > SmaCC runtime version 13 > Sport version 2.31 > Squeak dev packages version 0.27 > Squeak dev packages beta version 0.32 > Squeak web packages version 0.2 > SUnit-improved version 4.0.118 > SUnitGUI-improved version 4.0.50 > Swazoo version 2.1 > Universes version 51 > Universes OmniBrowser version 0.38 > VBRegex version 1.9 > YAXO version 14 > > -- "If at first, the idea is not absurd, then there is no hope for it". Albert Einstein

Feb. 12, 2009

Re: [Pharo-project] Workspace API

by Keith Hodges

StÃ©phane Ducasse wrote: > On Feb 12, 2009, at 1:47 PM, Keith Hodges wrote: > > >>> Our goal is to make progress. Squeak is dying don't see it? >>> >>> >> The reason it is dying is because once anyone starts a significant >> project they are stuck with the same image that they started with. >> Thus >> everyone gets left along the path of progress. They keep up or get >> left >> behind to fork their own little world. Pharo perpetuates and >> exacerbates >> this problem through its philosophy. >> > > no this is not the reason. > Really few people were fixing it and paying attention to making sure > we could remove > the cruft. > > But the reason that few people were fixing it was.... Andreas forked off Croquet in 3.8 Goran had forked off Gjallar in 3.8 Lots of others forked off Sophie in 3.8 Another group forked off to etoys on the XO, Not to mention Cobalt, SecrureSqueak, etc etc etc. Who is left with the expertise to improve the kernel? Edgar, Myself and Matthew? None of whom are experts. We stopped fixing the kernel in order to try and facilitate some harmony through some tools support. One result was LPF, another MC1.6, and of course the invisible man, Bob. Now you have all the experts, why doesnt someone who knows about traits help Matthew to fix SystemEditor to work with traits, then we would all have atomic loading, and a 3x performance improvement in MC. regards Keith

Feb. 12, 2009

Re: [Pharo-project] Fwd: Workspace API

by StÃ©phane Ducasse

>>>> I am close enough to Stef to affirm you that he respects your work >>>> and >>>> he is really willing to have a look at your code. As I do. I said >>>> that >>>> I would look at your SUnit extension a long while ago. However Stef >>>> and I are extremely busy. We are leading a group of 8 people, which >>>> suck up all our time. Really. >>>> > > One of the guy that suck up all your time thanks you .... Gweanael, come on. You know what alex meant. And yes I'm really busy with the group. I can show you what it means to organize WCRE, ESUG, budgeting things and writing postdoc, phd, doing presentations .... Stef

Feb. 12, 2009

Re: [Pharo-project] OB 10231: search bar does not work

by Simon Denier

On 12 fÃ©vr. 09, at 14:43, David RÃ¶thlisberger wrote: > Hi Simon > >> Using the latest pharo dev 10231dev09.02.1, I cant use the search bar >> anymore. I got a OBEnhancementMetaNode(Object)>>doesNotUnderstand: >> #fan: > > I fixed this in latest OBAlpha. > Can you check if it works for you too? yes it works on a fresh dev + OBAlpha! -- Simon

Feb. 12, 2009

Re: [Pharo-project] Fwd: Workspace API

by Gwenael Casaccio

On Thursday 12 February 2009 15:51:14 StÃ©phane Ducasse wrote: > Begin forwarded message: > > From: Keith Hodges <keith_hodges(a)yahoo.co.uk> > > Date: February 12, 2009 2:38:41 PM CEST > > To: Alexandre Bergel <alexandre(a)bergel.eu>, stephane ducasse > > <stephane.ducasse(a)free.fr > > > > Subject: Re: [Pharo-project] Workspace API > > > > Alexandre Bergel wrote: > >> Hi Keith, > >> > >> I am close enough to Stef to affirm you that he respects your work > >> and > >> he is really willing to have a look at your code. As I do. I said > >> that > >> I would look at your SUnit extension a long while ago. However Stef > >> and I are extremely busy. We are leading a group of 8 people, which > >> suck up all our time. Really. > >> One of the guy that suck up all your time thanks you .... Cheers, Gwenael > >> Regards, > >> Alexandre > > > > Why do you need to look at my code? I am not speaking up because you > > are > > not gathering up my meagre useless coding crumbs. > > > > The argument is not about code its about perspective and philosophy. > > > > MC1.5 is a loadable tool it either works or it doesn't. If it doesn't > > then the way forward is to consider contributing to the MC1.5 effort > > to > > make it work. That is the philosophy choice, inclusive or exclusive. > > > > Will you make the philosophy choice to treat MC as a community project > > or your project, which is it to be? That choice takes no time at all > > to > > make. You make the choice and then you can put your time and effort > > into > > working with the consequences. > > > > I am concerned because your philosophy leads you to continue to fork > > stuff that doesn't need to be forked and should not be forked for the > > good of the community. > > > > Another trivial example: Workspace is another tool, it could be > > loadable, it need not be part of the kernel. > > Variants of Workspace could be available. Whatever is done it could be > > loadable and work in all images. There is no reason at all why my old > > production image that is still in 3.8 cant load a newer implementation > > of Workspace (since ScriptManager loads successfully) > > > > SUnit is a loadable framework it is something that should be managed > > as > > a resource for everyone. Why does the pharo team insist on controlling > > it and forking. I am not asking you to "look at my code" in SUnit. In > > fact I doubt that the filters are actually working at the moment. Some > > of my code in SUnit was really rubbish until recent improvements. > > > > I am asking you to adopt a philosophy of seeing > > MC/SUnit/Workspace/Compiler/Collections etc as a community resource, > > with a repository squeaksource/Testing that the community maintains. > > Not > > something that pharo does its own thing on. > > > > If you dont, then I cant write a package that loads into Squeak and > > Pharo (because MC wont necessarily be compatible) or Tests run in > > squeak > > and Pharo (because SUnit will be incompatible). Why don't you see > > this > > level of compatibility as important? > > > > So again I am not complaining about the fact that you haven't looked > > at > > this or that bit of code. Your response of "we havent had time to look > > at that " winds me up, because I hear it as "we havent had time to > > audit > > your potentially inferior code that might be below us to use." and > > that > > very attitude misses the point completely. > > > > All of Stef objections, demonstrate that this is how he sees it. > > > > I am complaining that you see the issue as a bunch of "potentially > > inferior" code contributions to your cause, rather than "we have > > something to contribute to the community of SUnit and MC users, > > because > > MC and SUnit are frameworks that everyone uses and depends on." > > > > regards > > > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 12, 2009

Re: [Pharo-project] Fwd: Workspace API

by Damien Cassou

On Thu, Feb 12, 2009 at 3:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> So again I am not complaining about the fact that you haven't looked >> at >> this or that bit of code. Your response of "we havent had time to look >> at that " winds me up, because I hear it as "we havent had time to >> audit >> your potentially inferior code that might be below us to use." and >> that >> very attitude misses the point completely. >> >> All of Stef objections, demonstrate that this is how he sees it. >> >> I am complaining that you see the issue as a bunch of "potentially >> inferior" code contributions to your cause, rather than "we have >> something to contribute to the community of SUnit and MC users, >> because >> MC and SUnit are frameworks that everyone uses and depends on." We believe your work (MC, SUnit, Sake and Packages) is important enough for an integration into Pharo. We don't want to consider it as an external package. But for that, Pharo's maintainers must have a look at the code and decide if it is safe to include. Your code is not of lower quality. Have a nice day and please continue working on these tools -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 12, 2009

[Pharo-project] Fwd: Workspace API

by StÃ©phane Ducasse

Begin forwarded message: > From: Keith Hodges <keith_hodges(a)yahoo.co.uk> > Date: February 12, 2009 2:38:41 PM CEST > To: Alexandre Bergel <alexandre(a)bergel.eu>, stephane ducasse <stephane.ducasse(a)free.fr > > > Subject: Re: [Pharo-project] Workspace API > > Alexandre Bergel wrote: >> Hi Keith, >> >> I am close enough to Stef to affirm you that he respects your work >> and >> he is really willing to have a look at your code. As I do. I said >> that >> I would look at your SUnit extension a long while ago. However Stef >> and I are extremely busy. We are leading a group of 8 people, which >> suck up all our time. Really. >> >> Regards, >> Alexandre > Why do you need to look at my code? I am not speaking up because you > are > not gathering up my meagre useless coding crumbs. > > The argument is not about code its about perspective and philosophy. > > MC1.5 is a loadable tool it either works or it doesn't. If it doesn't > then the way forward is to consider contributing to the MC1.5 effort > to > make it work. That is the philosophy choice, inclusive or exclusive. > > Will you make the philosophy choice to treat MC as a community project > or your project, which is it to be? That choice takes no time at all > to > make. You make the choice and then you can put your time and effort > into > working with the consequences. > > I am concerned because your philosophy leads you to continue to fork > stuff that doesn't need to be forked and should not be forked for the > good of the community. > > Another trivial example: Workspace is another tool, it could be > loadable, it need not be part of the kernel. > Variants of Workspace could be available. Whatever is done it could be > loadable and work in all images. There is no reason at all why my old > production image that is still in 3.8 cant load a newer implementation > of Workspace (since ScriptManager loads successfully) > > SUnit is a loadable framework it is something that should be managed > as > a resource for everyone. Why does the pharo team insist on controlling > it and forking. I am not asking you to "look at my code" in SUnit. In > fact I doubt that the filters are actually working at the moment. Some > of my code in SUnit was really rubbish until recent improvements. > > I am asking you to adopt a philosophy of seeing > MC/SUnit/Workspace/Compiler/Collections etc as a community resource, > with a repository squeaksource/Testing that the community maintains. > Not > something that pharo does its own thing on. > > If you dont, then I cant write a package that loads into Squeak and > Pharo (because MC wont necessarily be compatible) or Tests run in > squeak > and Pharo (because SUnit will be incompatible). Why don't you see > this > level of compatibility as important? > > So again I am not complaining about the fact that you haven't looked > at > this or that bit of code. Your response of "we havent had time to look > at that " winds me up, because I hear it as "we havent had time to > audit > your potentially inferior code that might be below us to use." and > that > very attitude misses the point completely. > > All of Stef objections, demonstrate that this is how he sees it. > > I am complaining that you see the issue as a bunch of "potentially > inferior" code contributions to your cause, rather than "we have > something to contribute to the community of SUnit and MC users, > because > MC and SUnit are frameworks that everyone uses and depends on." > > regards > > Keith >

Feb. 12, 2009

[Pharo-project] [ANN] 10233 MVCMenuMorph removal + collectSelect...

by StÃ©phane Ducasse

Feb. 12, 2009

Re: [Pharo-project] Workspace API

by StÃ©phane Ducasse

On Feb 12, 2009, at 1:47 PM, Keith Hodges wrote: > >> Our goal is to make progress. Squeak is dying don't see it? >> > The reason it is dying is because once anyone starts a significant > project they are stuck with the same image that they started with. > Thus > everyone gets left along the path of progress. They keep up or get > left > behind to fork their own little world. Pharo perpetuates and > exacerbates > this problem through its philosophy. no this is not the reason. Really few people were fixing it and paying attention to making sure we could remove the cruft. > You could have picked a slice of squeak, instituted a project to > improve > it, and then contributed that improved slice back to everyone, and > so on. No this was not possible. People shouted (may be this was before you joined the community) and were against removal. > > The kernel image itself is not that important to getting actual work > done, once you eliminate certain headaches like FileDirectory (Rio was > my choice of the section of the kernel to improve). Sure, if you are > doing academic little projects, you might be constantly irked by the > lack of change in the kernel. If you are working on a big project with > clients breathing down your neck, you just get on with it. > > The cause (since captials are deemed to be rude, sorry Paul) of > squeak dying is that those who move it forward are too busy making > progress and they dont think about the users of older images. no. :) see above. > How many of our potential millions of future xo users will be taking > their future xo software apart to find Pharo inside? No idea but if a smart kid looks at squeak, he will find pharo :) > >>> And you are ignoring those tools, because you dont see them as >>> important. >>> >> I would love to have a buildServer and also run automatically >> SmallLint rules on the code >> now either pharo does not exist because we build those tools or pharo >> exist. > So please .... explain this to me.... why cant. > > Project A working on the kernel and not the tools, fit together with > project B, working on the tools and not the kernel? Looks simple on > paper doesn't it. Think it over, A+B = AB, and B + A = BA, hmm it > works, > infact its kind of obvious. > > Now why is it that this doesn't work I wonder? Please explain this > to me? spaghetti code, hidden dependencies, responsibilities code ownership, lack of will of one maintainer to integrate changes We got such a problem with Graphics in the past. We were called random refactorers by andreas. > > > Correct me if I am wrong, but I think it is because Project A is > working > on the kernel, and is for some reason forking the loadable tools > (which > should be outside of their remit) thus absorbing all of the expertise, > making things more difficult for everyone. > Project B then gives up and goes off to do something else, because > they > realise that 3 years of efforts trying to open up repositories and to > encourage people to contribute collaboratively to tools as shared > resources over the whole community of projects, is a total and utter > waste of time. yes this is why **I** loaded SUnitextension KernelExtension Installer Rio > All the repo's on Project B are public, and anyone can contribute, > however the majority of Project A contributors don't join in. >> buildserver and this is why >> > I have been working on the Build server since Feb 2007. That was > where > the idea for Rio originally came from. The ruby version of Bob did > work > but it was tricky to set up. The smalltalk one only needs one day of > work to complete, and I said that 3 months ago. > > However since no-one from your team this is not my team. > seems willing to join on > fixing up MC1.5 etc I was left to spend yesterday fixing an MC1.5 bug. > Perhaps there is no point in doing that one day of work on Bob because > no-one will bother looking at it anyway. I do not know. Talk to them. Make a simple call in this list >> we started to write on Installer (and you know that this is not only >> for pharo so you should be happy). >> > You did? yes this is in PharoByExample (aka Squeak by Example (volume two). > >> Now you should ask yourself the question why people are not all using >> your tool extensions. >> > Actually they are. If they were not I wouldn't be here now. >> Conservatism? stupidity? lack of time? lack of trust? Dont'care? >> > None of the above. Many people load LPF and get on with the job they > have to do. > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 12, 2009