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

Re: [Pharo-project] Issue 3520 in pharo: Workspaces do not recognize previously evaluated temps

by pharo＠googlecode.com

Updates: Status: Accepted Comment #3 on issue 3520 by marcus.d...(a)gmail.com: Workspaces do not recognize previously evaluated temps http://code.google.com/p/pharo/issues/detail?id=3520 Worked in 12283 Stopped to worked somehow until 12294.

Jan. 19, 2011

Re: [Pharo-project] About XML Support in the 1.2

by Guillermo Polito

But that kind of duplication will lead to having always not up to date configurations... Why not having something like a meta "configuration" (I'm not thinking in a metacello config, but maybe) that knows which are the current configurations and where to find them? And that config would let us build tools on top of it... On Wed, Jan 19, 2011 at 3:01 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > I think that the a good working model is to store the ConfigurationOfXXX in > the project repository along with the project mcz files. > > When a new version is released the configuration should be copied to > MetacelloRepository for the Pharo and Squeak community. I have a GemSource > MetacelloRepository where I put copies of configurations that have been > ported to GemStone .... when a new version for GemStone is available. > > I would not recommend that configurations be removed from > MetacelloRepository as that could break existing configurations that expect > to find the configuration there. So if it is found that there are > out-of-date configurations in MetacelloRepository, a new version of the > configuration should be copied into MetacelloRepository. > > Now that Metacello is more established, I don't think that it is critical > to require that all configurations be copied to MetacelloRepository. > > It still is useful to have a sort of clearinghouse for configurations and > until a better solution comes along it serves that purpose. BTW, I think > Stef has plans to provide better solutions for Pharo... > > Dale > > > > On 01/19/2011 06:12 AM, laurent laffont wrote: > >> On Wed, Jan 19, 2011 at 2:49 PM, Norbert Hartl <norbert(a)hartl.name >> <mailto:norbert@hartl.name>> wrote: >> >> >> On 19.01.2011, at 14:30, laurent laffont wrote: >> >> On Wed, Jan 19, 2011 at 1:37 PM, Norbert Hartl <norbert(a)hartl.name >>> <mailto:norbert@hartl.name>> wrote: >>> >>> It depends where you look at. ConfigurationOfXMLSupport exists >>> in MetacelloRepository as well as in XMLSupport. The latter >>> one being the official one, the former one being very >>> outdated. My sugesstion would be to remove >>> ConfigurationOfXMLSupport from MetacelloRepository to lower >>> the confusion. >>> >>> >>> Personnally I always look in MetacelloRepository, this should be >>> the reference IMHO. >>> >>> Laurent, >> >> I think it is up to the maintainers where to put those files. And in >> the XMLSupport case the decision was made deliberately not to put it >> in MetacelloRepository but in XMLSupport. The only thing I want to >> avoid is having multiple different files floating around that are >> edited in an inconsistent way. >> >> >> I thought that all ConfigurationOfXXX working for Pharo should be put in >> MetacelloRepository so we have a central place to look at. >> >> But I may be wrong. Mariano ? Dale ? >> >> Laurent >> >> >> Norbert >> >> >>> Norbert >>> >>> On 19.01.2011, at 13:18, Tudor Girba wrote: >>> >>> > The last version 1.1.6 is marked as #release. >>> > >>> > Cheers, >>> > Doru >>> > >>> > >>> > On 19 Jan 2011, at 12:26, laurent laffont wrote: >>> > >>> >> I put ConfigurationOfXMLSupport version 1.0 because >>> blessing was #release. But I agree to change. >>> >> >>> >> Laurent >>> >> >>> >> On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker >>> <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >> >>> >> On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote: >>> >> >>> >>> Indeed, this is a problem for Moose in general. We depend >>> on XMLSupport, but now we cannot update it in PharoDev. I >>> would also strongly support the idea of removing XMLSupport >>> from PharoDev. >>> >>> >>> >> >>> >> What would be important: we need the latest version in >>> Pharo 1.2... else how can we ever have a version where the >>> tests are green? >>> >> (not of XML, but in general) >>> >> >>> >> Marcus >>> >> >>> >>> Cheers, >>> >>> Doru >>> >>> >>> >>> >>> >>> On 19 Jan 2011, at 11:32, Fabrizio Perin wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> I have a problem with the XMLSupport version from Pharo 1.2. >>> >>>> >>> >>>> The problem is that I need to work with one of the last >>> version of XMLSupport but in the pharo image 1.2 is loaded an >>> old version of XMLSupport (I mean a version from Jan 2010). I >>> did try to load a newer version of XMLSupport using >>> ConfigurationOfXMLSupport but some errors make this operation >>> impossible. >>> >>>> So either Pharo-dev 1.2 load a newer (possibly the last) >>> version of XMLSupport by default or Pharo-dev 1.2 should not >>> load XMLSupport at all. >>> >>>> >>> >>>> I think that doesn't make sense to use by default such an >>> old version, also considering that the last XMLSupport has >>> nice and useful features like the XMLPluggableElementFactory. >>> >>>> >>> >>>> By avoiding to load XMLSupport in Pharo-dev 1.2 by >>> default you let people free to use the version that they like. >>> >>>> >>> >>>> Thanks, >>> >>>> >>> >>>> Fabrizio >>> >>>> >>> >>> >>> >>> -- >>> >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> >>> >>> >>> "We cannot reach the flow of things unless we let go." >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >> -- >>> >> Marcus Denker -- http://www.marcusdenker.de >>> <http://www.marcusdenker.de/> >>> >> INRIA Lille -- Nord Europe. Team RMoD. >>> >> >>> >> >>> >> >>> > >>> > -- >>> > www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> > >>> > "If you interrupt the barber while he is cutting your hair, >>> > you will end up with a messy haircut." >>> > >>> > >>> >>> >>> >>> >> >> > >

Jan. 19, 2011

Re: [Pharo-project] Issue 3550 in pharo: MenuItemMorph>>mouseDown: has unnecessary check

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #2 on issue 3550 by marcus.d...(a)gmail.com: MenuItemMorph>>mouseDown: has unnecessary check http://code.google.com/p/pharo/issues/detail?id=3550 (No comment was entered for this change.)

Jan. 19, 2011

Re: [Pharo-project] Metacello Help book in Pharo-Dev

by Alexandre Bergel

What I did for Mondrian, is to automatically generate the Pharo By Example chapter from the ProfStef tutorial Alexandre On 18 Jan 2011, at 06:19, laurent laffont wrote: > Note that ProfStef tutorials are automatically visible in Help in 1.2 (I've discarded ProfStefBrowser). > > Laurent > > On Tue, Jan 18, 2011 at 9:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > The problem is that we have 25 pages of metacello explanation before that blog (which will be added to the book chapter). > > So the help should be small but not too much and not that long. > This is all the question of how to manage it (especially with duplication). > > I suggest to have a synthetic help description of a couple of pages and pointers to the chapter. > > Stef > > > On Jan 18, 2011, at 9:48 AM, Torsten Bergmann wrote: > > > Should we add the Metacello Help book to Pharo-dev? > > See > > > > http://gemstonesoup.wordpress.com/2011/01/17/metacello-1-0-beta-28-unearthe… > > -- > > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 19, 2011

Re: [Pharo-project] Pharo Refactoring Tool

by Alexandre Bergel

Hi Alia, This is really cool! I would love to have refactoring on packages: - cutting a packages in two - Extracting unit test from a big package into a dedicated test package - Moving a method as a class extension (I did such an extension in O2, it would be good to have it in OB) Not related to packages: - Method renaming that use unit tests to identify which calling methods need to be affected by the renaming Cheers, Alexandre On 19 Jan 2011, at 14:56, ashubair(a)scs.ryerson.ca wrote: > Hi, > > I'm a Masters student at Ryerson University (Dr.Dave Mason is my > supervisor), and my thesis project is to significantly improve the > refactoring capabilities of Pharo/Squeak. There was an interesting thread > on this back on August 6th, but I would welcome anyone's input on what I > should consider. My starting point is to bring Pharo up to the level of > Eclipse > (seehttp://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.user… > ) but I would love to hear from experienced Smalltalkers about > refactorings that are important to them. > > Thanks, > > Alia > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 19, 2011

[Pharo-project] faro ?

by Sven Van Caekenberghe

On 19 Jan 2011, at 18:43, Noury Bouraqadi wrote: > A student of mine sent me this picture :-) > >> >> http://www.linternaute.com/homme/art-de-vivre/selection/selection-de-mousse… >> > http://www.lindemans.be/start/faro/en Belgian Beer, of course.

Jan. 19, 2011

Re: [Pharo-project] About XML Support in the 1.2

by Dale Henrichs

I think that the a good working model is to store the ConfigurationOfXXX in the project repository along with the project mcz files. When a new version is released the configuration should be copied to MetacelloRepository for the Pharo and Squeak community. I have a GemSource MetacelloRepository where I put copies of configurations that have been ported to GemStone .... when a new version for GemStone is available. I would not recommend that configurations be removed from MetacelloRepository as that could break existing configurations that expect to find the configuration there. So if it is found that there are out-of-date configurations in MetacelloRepository, a new version of the configuration should be copied into MetacelloRepository. Now that Metacello is more established, I don't think that it is critical to require that all configurations be copied to MetacelloRepository. It still is useful to have a sort of clearinghouse for configurations and until a better solution comes along it serves that purpose. BTW, I think Stef has plans to provide better solutions for Pharo... Dale On 01/19/2011 06:12 AM, laurent laffont wrote: > On Wed, Jan 19, 2011 at 2:49 PM, Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>> wrote: > > > On 19.01.2011, at 14:30, laurent laffont wrote: > >> On Wed, Jan 19, 2011 at 1:37 PM, Norbert Hartl <norbert(a)hartl.name >> <mailto:norbert@hartl.name>> wrote: >> >> It depends where you look at. ConfigurationOfXMLSupport exists >> in MetacelloRepository as well as in XMLSupport. The latter >> one being the official one, the former one being very >> outdated. My sugesstion would be to remove >> ConfigurationOfXMLSupport from MetacelloRepository to lower >> the confusion. >> >> >> Personnally I always look in MetacelloRepository, this should be >> the reference IMHO. >> > Laurent, > > I think it is up to the maintainers where to put those files. And in > the XMLSupport case the decision was made deliberately not to put it > in MetacelloRepository but in XMLSupport. The only thing I want to > avoid is having multiple different files floating around that are > edited in an inconsistent way. > > > I thought that all ConfigurationOfXXX working for Pharo should be put in > MetacelloRepository so we have a central place to look at. > > But I may be wrong. Mariano ? Dale ? > > Laurent > > > Norbert > >> >> Norbert >> >> On 19.01.2011, at 13:18, Tudor Girba wrote: >> >> > The last version 1.1.6 is marked as #release. >> > >> > Cheers, >> > Doru >> > >> > >> > On 19 Jan 2011, at 12:26, laurent laffont wrote: >> > >> >> I put ConfigurationOfXMLSupport version 1.0 because >> blessing was #release. But I agree to change. >> >> >> >> Laurent >> >> >> >> On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker >> <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >> >> On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote: >> >> >> >>> Indeed, this is a problem for Moose in general. We depend >> on XMLSupport, but now we cannot update it in PharoDev. I >> would also strongly support the idea of removing XMLSupport >> from PharoDev. >> >>> >> >> >> >> What would be important: we need the latest version in >> Pharo 1.2... else how can we ever have a version where the >> tests are green? >> >> (not of XML, but in general) >> >> >> >> Marcus >> >> >> >>> Cheers, >> >>> Doru >> >>> >> >>> >> >>> On 19 Jan 2011, at 11:32, Fabrizio Perin wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> I have a problem with the XMLSupport version from Pharo 1.2. >> >>>> >> >>>> The problem is that I need to work with one of the last >> version of XMLSupport but in the pharo image 1.2 is loaded an >> old version of XMLSupport (I mean a version from Jan 2010). I >> did try to load a newer version of XMLSupport using >> ConfigurationOfXMLSupport but some errors make this operation >> impossible. >> >>>> So either Pharo-dev 1.2 load a newer (possibly the last) >> version of XMLSupport by default or Pharo-dev 1.2 should not >> load XMLSupport at all. >> >>>> >> >>>> I think that doesn't make sense to use by default such an >> old version, also considering that the last XMLSupport has >> nice and useful features like the XMLPluggableElementFactory. >> >>>> >> >>>> By avoiding to load XMLSupport in Pharo-dev 1.2 by >> default you let people free to use the version that they like. >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Fabrizio >> >>>> >> >>> >> >>> -- >> >>> www.tudorgirba.com <http://www.tudorgirba.com/> >> >>> >> >>> "We cannot reach the flow of things unless we let go." >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> Marcus Denker -- http://www.marcusdenker.de >> <http://www.marcusdenker.de/> >> >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> >> >> >> >> > >> > -- >> > www.tudorgirba.com <http://www.tudorgirba.com/> >> > >> > "If you interrupt the barber while he is cutting your hair, >> > you will end up with a messy haircut." >> > >> > >> >> >> > >

Jan. 19, 2011

[Pharo-project] Pharo Refactoring Tool

by ashubair＠scs.ryerson.ca

Hi, I'm a Masters student at Ryerson University (Dr.Dave Mason is my supervisor), and my thesis project is to significantly improve the refactoring capabilities of Pharo/Squeak. There was an interesting thread on this back on August 6th, but I would welcome anyone's input on what I should consider. My starting point is to bring Pharo up to the level of Eclipse (seehttp://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.user… ) but I would love to hear from experienced Smalltalkers about refactorings that are important to them. Thanks, Alia

Jan. 19, 2011

Re: [Pharo-project] Issue 3509 in pharo: Multi-part MIME support for MailMessage

by Marcus Denker

On Jan 19, 2011, at 5:01 PM, Norbert Hartl wrote: > I'm not sure but I think there was a discussion about Zinc http components and how it will be integrated into pharo. What is the status on this? > > Seeing the issue report below I think there should be made some decision. Zinc has quite some good mime multipart support. No need to double efforts. > Maybe the mime parts should factored out of Zinc and should be integrated first to make up a good mime support. Http based on mime can follow. > For this change... one step at a time. MailMessage already has mime-support, just not multi-part. > Norbert > > On 19.01.2011, at 15:49, pharo(a)googlecode.com wrote: > >> Updates: >> Status: Closed >> >> Comment #3 on issue 3509 by marcus.d...(a)gmail.com: Multi-part MIME support for MailMessage >> http://code.google.com/p/pharo/issues/detail?id=3509 >> >> 13002 >> >> > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 19, 2011

[Pharo-project] faro ?

by Noury Bouraqadi

A student of mine sent me this picture :-) > > http://www.linternaute.com/homme/art-de-vivre/selection/selection-de-mousse… > > >

Jan. 19, 2011