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

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

by Michael Roberts

2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Ok...the problem is that I have just checked and this changes are only in > 1.1 isn't it ? > > :(Â Â Â So...what we do ? we keep like this until 1.1 ? oh sorry yes they are only in 1.1. You just need to change version: string using some string manipulation. If you keep it in the same format it will parse correctly by code that expects the 1.1 format. On principle I did not backport the SystemVersion changes behaviour to 1.0 since it was already at the end of the cycle. However i just migrated the data to work across core branches. > >> >> and you can change the suffix as well, but personally i would not use >> the date in the image name. >> > > For the date you refer to year, month and number of version inside the month > ? 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 core image uses, and Pharo 1.1 will have this behaviour already using #imageVersionString since it is in 1.1. thanks, Mike

Jan. 10, 2010

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

by Mariano Martinez Peck

CÃ©drick: Maybe it is has nothing to do, but a friend of mine once did a little Portia implementation. I think they have a similar Idea. Maybe I am wrong. Anyway, here is a paper about that: http://portal.acm.org/citation.cfm?id=118014.117959 Cheers Mariano On Sun, Jan 10, 2010 at 3:31 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi CÃ©drick, > > Indeed, this is something that one needs from time to time. However, I > wonder, from a usability point of view, if this is the right way to do > it. 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. > > I think the idea is good, but how could it be made easy to understand > and use? > > Cheers, > Adrian > > 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. > > > On Jan 10, 2010, at 14:25 , CÃ©drick BÃ©ler wrote: > > > Hi, > > > > I've always found the need to copy/paste object (not string) between > > say, an > > inspector/explorer and a workspace. > > > > So I did a small class called ObjectBuffer and some extension that > > provide > > this fonctionnality (see the attached picture). I added menu command > > so that > > 'buffer it' is accessible from text selection, inspector and > > explorer. I > > doubt the implementation is optimal but this is working so I decided > > to > > share and see if people would like it too > > > > > > To get the object stored: > > > > self buffer > > or > > ObjectBuffer buffer > > > > hth, > > > > -- > > CÃ©drick > > <bufferIt.PNG><ObjectBuffer-CedrickBeler.1.mcz><ParagraphEditor > > class-yellowButtonExpertMenu.st><Inspector- > > fieldListMenu.st><ObjectExplorer- > > genericMenu.st>_______________________________________________ > > 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] Object Buffer (implementation tryout)

by Adrian Lienhard

Hi CÃ©drick, Indeed, this is something that one needs from time to time. However, I wonder, from a usability point of view, if this is the right way to do it. 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. I think the idea is good, but how could it be made easy to understand and use? Cheers, Adrian 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. On Jan 10, 2010, at 14:25 , CÃ©drick BÃ©ler wrote: > Hi, > > I've always found the need to copy/paste object (not string) between > say, an > inspector/explorer and a workspace. > > So I did a small class called ObjectBuffer and some extension that > provide > this fonctionnality (see the attached picture). I added menu command > so that > 'buffer it' is accessible from text selection, inspector and > explorer. I > doubt the implementation is optimal but this is working so I decided > to > share and see if people would like it too > > > To get the object stored: > > self buffer > or > ObjectBuffer buffer > > hth, > > -- > CÃ©drick > <bufferIt.PNG><ObjectBuffer-CedrickBeler.1.mcz><ParagraphEditor > class-yellowButtonExpertMenu.st><Inspector- > fieldListMenu.st><ObjectExplorer- > genericMenu.st>_______________________________________________ > 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] System -> About in Dev images

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 3:23 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > Hi you need to set > > SystemVersion current type: 'Pharo' > > to change the core image it is built from to be Pharo. or if we > abandon the distinction > > SystemVersion current type: 'PharoDev' > > Ok...the problem is that I have just checked and this changes are only in 1.1 isn't it ? :( So...what we do ? we keep like this until 1.1 ? > and you can change the suffix as well, but personally i would not use > the date in the image name. > > For the date you refer to year, month and number of version inside the month ? > cheers, > Mike > > 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi folks: If you take a Dev image and go to " System->About " you get > > something like: > > > > PharoCore1.0rc1 > > Latest update: #10505 > > > > However, I would like to show something like this for example: > > > > Pharo1.0-10505-rc1dev10.01.1 > > PharoCore1.0rc1 > > Latest update: #10505 > > > > > > Do you know how we can change this? How can I set that name when > building a > > PharoDev image? > > > > Is this related to SystemVersion ?? > > > > We need to have this fixed for the official 1.0 release. > > > > Cheers > > > > Mariano > > > > _______________________________________________ > > 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] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 3:22 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Jan 10, 2010, at 14:35 , Mariano Martinez Peck wrote: > > > On Sun, Jan 10, 2010 at 2:15 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > > >> Lukas is the official maintainer of the OB package for Pharo. > >> Therefore I assume OB should be loaded from his repository... Lukas? > >> > >> > > Wait...this is not a little decision. This is really big. Because a > > lot of > > people commits stuff to wiresong repository. How this will be > > merged ? where > > people that wants to contribute to OB should commit ? > > Until somebody steps up as a maintainer to provide an official > OmniBrowser for Pharo, Lukas' version is the best bet we have. As he > sais, he is not an "official" maintainer, but it worked out very well > so far. Since Lukas uses OB all day and knows how to fix its bugs, we > get a stable browser. > > Therefore, I strongly suggest to continue this way, i.e., to use > Lukas' OB version. I'm sure that Lukas will consider external fixes > and enhancements and merge them into his line if appropriate. > > Sorry Andrian, I sent my last email before this one ;) Ok...I will do a test to build a new Dev image using OB from Lukas repository. Cheers Mariano > Cheers, > Adrian > > _______________________________________________ > 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 2:49 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> Lukas is the official maintainer of the OB package for Pharo. > >> Therefore I assume OB should be loaded from his repository... Lukas? > > > > Wait...this is not a little decision. This is really big. Because a lot > of > > people commits stuff to wiresong repository. How this will be merged ? > where > > people that wants to contribute to OB should commit ? > > You ask a maintainer to pull your changes from your or a separate > public repository. Like about any other open-source project does. > Linux. Pharo. Seaside. > > It does not work when everybody publishes random changes to a > repository that everybody else is pulling from. Even if this looks > like really open open open-source, it is the inferno. This is how you > can turn in no time an excellent piece of software with hundreds of > tests into battlefield of bugs, broken tests, and messed up design. > > I am agree. Now, suppose that "public repository" is wiresong. My main concern is that I don't want to "loose" those commits people do (maybe even from squeak) to that repository. So, someone should take care to integrate to Lukas OB repository the changes that are worth from wiresong repo. We will be able to handle this ? > 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 >

Jan. 10, 2010

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

by Michael Roberts

Hi you need to set SystemVersion current type: 'Pharo' to change the core image it is built from to be Pharo. or if we abandon the distinction SystemVersion current type: 'PharoDev' and you can change the suffix as well, but personally i would not use the date in the image name. cheers, Mike 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi folks:Â If you take a Dev image and go to " System->About "Â you get > something like: > > PharoCore1.0rc1 > Latest update: #10505 > > However, I would like to show something like this for example: > > Pharo1.0-10505-rc1dev10.01.1 > PharoCore1.0rc1 > Latest update: #10505 > > > Do you know how we can change this?Â How can I set that name when building a > PharoDev image? > > Is this related to SystemVersion ?? > > We need to have this fixed for the official 1.0 release. > > Cheers > > Mariano > > _______________________________________________ > 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 Adrian Lienhard

On Jan 10, 2010, at 14:35 , Mariano Martinez Peck wrote: > On Sun, Jan 10, 2010 at 2:15 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >> Lukas is the official maintainer of the OB package for Pharo. >> Therefore I assume OB should be loaded from his repository... Lukas? >> >> > Wait...this is not a little decision. This is really big. Because a > lot of > people commits stuff to wiresong repository. How this will be > merged ? where > people that wants to contribute to OB should commit ? Until somebody steps up as a maintainer to provide an official OmniBrowser for Pharo, Lukas' version is the best bet we have. As he sais, he is not an "official" maintainer, but it worked out very well so far. Since Lukas uses OB all day and knows how to fix its bugs, we get a stable browser. Therefore, I strongly suggest to continue this way, i.e., to use Lukas' OB version. I'm sure that Lukas will consider external fixes and enhancements and merge them into his line if appropriate. Cheers, Adrian

Jan. 10, 2010

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

by Schwab,Wilhelm K

Very true!! -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, January 10, 2010 8:49 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1 >> Lukas is the official maintainer of the OB package for Pharo. >> Therefore I assume OB should be loaded from his repository... Lukas? > > Wait...this is not a little decision. This is really big. Because a > lot of people commits stuff to wiresong repository. How this will be > merged ? where people that wants to contribute to OB should commit ? You ask a maintainer to pull your changes from your or a separate public repository. Like about any other open-source project does. Linux. Pharo. Seaside. It does not work when everybody publishes random changes to a repository that everybody else is pulling from. Even if this looks like really open open open-source, it is the inferno. This is how you can turn in no time an excellent piece of software with hundreds of tests into battlefield of bugs, broken tests, and messed up design. 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

Jan. 10, 2010

Re: [Pharo-project] Morphic (for gary :) and others)

by Tudor Girba

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

Jan. 10, 2010