January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] System -> About in Dev images

by Mariano Martinez Peck

> > yes I think it is too complicated a version scheme. The dev tag is > also synonymous with Pharo. > > so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 > I would call it Pharo-1.0-10505-rc1. This is the same scheme that the > The is Pharo-1.0-10505-rc1 or it should be Pharo-1.0-10505rc1 (note the - between 10505 and rc1). I ask because the PharoCore 10502 was released as PharoCore-1.0-10502rc1. I can ask Adrian so that the next PharoCore 1.0 be like: Pharo-1.0-10XXX-rc2 I know...it is a little detail.but...jhhahahha core image uses, and Pharo 1.1 will have this behaviour already using > #imageVersionString since it is in 1.1. > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010

Re: [Pharo-project] Categorizing method extension with pragma

by Mariano Martinez Peck

2010/1/10 CÃ©drick BÃ©ler <cdrick65(a)gmail.com> > Hi, > > Just a 2 cents thought on method extension. > > Why not associating a pragma instead of using the package name prefixed by > a star ? > > Say there is a package named MyPackage and I override a method in String or > add a new one. What I'd like is keeping the original method category name > (or find an appropriate one) instead of using *mypackage. For instance: > > String>>aMethod > <package: MyPackage> > ... > ... > ^result > > > Then, we would have to adapt monticello for that purpose. We could also use > dynamic protocols to get the list of extension method by package. > > What does other think ? I find it could be a good starting point to deal > with packages. > > > That it would be a dream. I really hate the ugly hack to have to use Categories for another purpose than just organize methods regarding its intention. It is really disgusting. I don't have the knoweldege enought to say which solution I like most, but I can say that I hate as it is now and that I don't know the problems it can bring the Monticello and the compatibility. Maybe it would be easier when we have packages as real first class objects. > > -- > CÃ©drick > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 11:05 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> Can you debug them? > > > > Sure. testPushAlphaBeta fails in self assertSelectionIs: 1. because in > > assertSelectionIs: anInteger > > > > you can see that anInteger and index are both 1, but the button answer > false > > to the message isOn > > > > testUpdateSelection fails in self assertSelectionIs: 2 because in > > assertSelectionIs: anInteger and index are both 2 but isOn returns > false.. > > > > Som, it seems both issue are due to the same. > > > > Let me know what else can I test. > > I don't know, I was assuming what you said, but I cannot reproduce it. > I can reproduce with this way (maybe it help you): - download the latest PharoCore 1.0 and upload to 10505 - Evaluate: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; load. (ConfigurationOfOmniBrowser project version: '1.1') load: #('Dev' 'Dev Tests' ) You should be able to debug it. I guess we have to ignore it for now. > > Yes, no problem at all. We are much better :) > Lukas > > > > > > Cheers > > > > Mariano > > > > > >> > >> Lukas > >> > >> > >> > > >> >> > >> >> :) > >> >> > >> >> Thanks > >> >> > >> >> Mariano > >> >> > >> >> > >> >> > >> >> Lukas > >> >> > >> >> -- > >> >> Lukas Renggli > >> >> http://www.lukas-renggli.ch > >> >> > >> >> _______________________________________________ > >> >> Pharo-project mailing list > >> >> Pharo-project(a)lists.gforge.inria.fr > >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> >> > >> >> > >> > > >> > -- > >> > Lukas Renggli > >> > http://www.lukas-renggli.ch > >> > > >> > >> > >> > >> -- > >> Lukas Renggli > >> http://www.lukas-renggli.ch > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Lukas Renggli

>> Can you debug them? > > Sure. testPushAlphaBetaÂ fails in self assertSelectionIs: 1.Â because in > assertSelectionIs: anInteger > > you can see that anInteger and index are both 1, but the button answer false > to the message isOn > > testUpdateSelection fails in self assertSelectionIs: 2Â because in > assertSelectionIs: anInteger and index are both 2 butÂ isOn returns false.. > > Som, it seems both issue are due to the same. > > Let me know what else can I test. I don't know, I was assuming what you said, but I cannot reproduce it. I guess we have to ignore it for now. Lukas > > Cheers > > Mariano > > >> >> Lukas >> >> >> > >> >> >> >> :) >> >> >> >> Thanks >> >> >> >> Mariano >> >> >> >> >> >> >> >> Lukas >> >> >> >> -- >> >> Lukas Renggli >> >> http://www.lukas-renggli.ch >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> > >> > -- >> > Lukas Renggli >> > http://www.lukas-renggli.ch >> > >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 10, 2010

Re: [Pharo-project] [ANN] Hudson continuous integration server support

by StÃ©phane Ducasse

Lukas is impressive. You would see it coding new parser in helvetia :) or helping to port Moose VisualWorks into pharo. It was cool. Stef On Jan 10, 2010, at 7:48 PM, Yanni Chiu wrote: > Lukas Renggli wrote: >> Thank you for adding me to the repository. I will commit my changes to >> the HudsonBuildTools there, if this is ok with you? >> >> I've made some significant changes: >> >> - added methods to run all tests of a package >> - make the distinction between error and failure >> - measure the time it took to run a test >> - display the exception and stack trace of a failing test >> - encode all XML values properly (I had some problems with the stacks) > > Wow this is great. You guys work so fast, I can't keep up. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] Object Buffer (implementation tryout)

by StÃ©phane Ducasse

I like the idea. I like the idea of a class because you could attach behavior to it: - cleaning for release - exporting - importing ... So instead of using a global I would use instead of Buffer why not ObjectClipBoard ? Stef > The problem is that without explaining someone what the menu item > "Buffer it" does and how to use it (e.g., to evaluate "self buffer") > it makes this feature hard to understand. > > yes I agree > > > I think the idea is good, but how could it be made easy to understand > and use? > > don't really know. I first named it 'copy it' and 'paste it' but I don't think that's the issue > > BTW, the same effect can also be achieved by assigning the object to a > global, e.g., "Buffer := self at: 4" and then in the popup select > "declare global" if Buffer is not a global yet. > > uhmm yes it seems better. No need for an extra class and instead of self buffer, evaluating the global is enough. > Also, am I correct to remove a global like that: > Smalltalk removeKey: #Buffer > > > Maybe then a menu entry more explicit would be 'store in global named Buffer' 'assign to Buffer' "store in Buffer" ? ... uhm a bit too long... > > Maybe having 'buffer it' in the menu (or store it or copy it) and a secondary item named for instance 'paste it' that is accessible when Buffer exists and that paste 'Buffer' wherever needed. > > What do you think ? > > Cheers, > > -- > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] problem installing Nile

by Mariano Martinez Peck

It would be cool to have ConfigurationOfNile so that not depend in this Nile-All and requiered packages from MC. some volunteer ? On Sun, Jan 10, 2010 at 10:41 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > this is really strange. > > On Jan 10, 2010, at 4:22 PM, Mariano Martinez Peck wrote: > > > I really don't know where the problem is here. If I take an image, both, > installing just Nile from Metacello or from Monticello Browser, it loads ok. > > > > When I run my full ConfigurationOfPharo from a command line sending the > scripts, I always have this errors. > > > > But Dale, you said you have the same problems even running the load from > a workspace? > > > > I don't understand :( > > > > I know the package Nile-All loads all the required packages using the > Monticello required package feature...maybe there is a conflic here ? Maybe > something related to what stef said that the repository is being replaced > with another one like pharo ? > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010

Re: [Pharo-project] CUIS new Text Editor Classes

by StÃ©phane Ducasse

doru ScriptLoader new ddExtraRepositories -> open squeak trunk and you can see their changes and integration of CUIS. This is since the sprint at lille that we should have a look. Stef On Jan 10, 2010, at 5:50 PM, Tudor Girba wrote: > It would be really great to have that in Pharo. I would adopt it in > Glamour in a heartbeat :) > > Is there an easy way to load this code in Pharo? Especially given that > it looks like it can live side-by-side with the current editor. > > Cheers, > Doru > > > On 10 Jan 2010, at 16:45, Fernando olivero wrote: > >> Juan re-factored the smalltalk behavior in the editors, creating the >> following hierarchy >> >> Editor >> TextEditor SimpleEditor >> SmalltalkEditor >> >> >> See the comment in Editor class in Cuis image http://www.jvuletich.org/Cuis/Index.html >> . >> >> New text editors. >> TextEditor provides most of the functionality that used to be in >> TextMorphEditor. This class is no longer a Controller! >> >> SmalltalkEditor is has Smalltalk code specific features. >> >> SimpleEditor provides basic functionality for single line text >> editing. It does not handle fonts and styles, aligning and Smalltalk >> utilities. It handles one single line. >> >> Would be nice to adopt this refactoring into Pharo, i've started to >> port it and cleaning up the textmorph in the process. But it's still >> a work in progress. >> >> Fernando >> >> On Jan 10, 2010, at 3:09 PM, Tudor Girba wrote: >> >>> Hi, >>> >>>> Gary and others >>>> >>>> I really think that we should do an audit of Morphic. In 1.1 we are >>>> going already faster but I'm sure that there is plenty >>>> of space for improvements. >>>> >>>> I see several actions >>>> - checking squeak toolbuilder enhancements and using it for the >>>> tools >>>> >>>> - checking CUIS >>>> - juan did an excellent job remocving a lot of unnecessary code >>>> - juan optimize scrollbar >>>> - juan did a new texteditor morph >>> >>> Indeed, a text editor that does not hardcode smalltalk specific >>> behavior would be great :). >>> >>>> - removing/cleaning extra widgets Pluggable/nonpluggable plague. >>>> - integrating better polymorph into the widgets layer. >>>> >>>> What do you think? >>> >>> >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] CUIS new Text Editor Classes

by StÃ©phane Ducasse

Excellent fernando! Did you start from squeak or cuis I was planning to start from Squeak since they ported back CUIS code in the context of WideStrings (CUIS is pre unicode support) Stef > Juan re-factored the smalltalk behavior in the editors, creating the following hierarchy > > Editor > TextEditor SimpleEditor > SmalltalkEditor > > > See the comment in Editor class in Cuis image http://www.jvuletich.org/Cuis/Index.html. > > New text editors. > TextEditor provides most of the functionality that used to be in TextMorphEditor. This class is no longer a Controller! > > SmalltalkEditor is has Smalltalk code specific features. > > SimpleEditor provides basic functionality for single line text editing. It does not handle fonts and styles, aligning and Smalltalk utilities. It handles one single line. > > Would be nice to adopt this refactoring into Pharo, i've started to port it and cleaning up the textmorph in the process. But it's still a work in progress. > > Fernando > > On Jan 10, 2010, at 3:09 PM, Tudor Girba wrote: > >> Hi, >> >>> Gary and others >>> >>> I really think that we should do an audit of Morphic. In 1.1 we are >>> going already faster but I'm sure that there is plenty >>> of space for improvements. >>> >>> I see several actions >>> - checking squeak toolbuilder enhancements and using it for the tools >>> >>> - checking CUIS >>> - juan did an excellent job remocving a lot of unnecessary code >>> - juan optimize scrollbar >>> - juan did a new texteditor morph >> >> Indeed, a text editor that does not hardcode smalltalk specific >> behavior would be great :). >> >>> - removing/cleaning extra widgets Pluggable/nonpluggable plague. >>> - integrating better polymorph into the widgets layer. >>> >>> What do you think? >> >> >> Doru >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] problem installing Nile

by StÃ©phane Ducasse

this is really strange. On Jan 10, 2010, at 4:22 PM, Mariano Martinez Peck wrote: > I really don't know where the problem is here. If I take an image, both, installing just Nile from Metacello or from Monticello Browser, it loads ok. > > When I run my full ConfigurationOfPharo from a command line sending the scripts, I always have this errors. > > But Dale, you said you have the same problems even running the load from a workspace? > > I don't understand :( > > I know the package Nile-All loads all the required packages using the Monticello required package feature...maybe there is a conflic here ? Maybe something related to what stef said that the repository is being replaced with another one like pharo ?

Jan. 10, 2010