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

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

by Tudor Girba

+1 Doru On 19 Jan 2011, at 20:32, Alexandre Bergel wrote: > +1 > > On 19 Jan 2011, at 16:28, StÃ©phane Ducasse wrote: > >> We do not want our distributions of code to rely on external servers. >> So the act of publishing should means that this is available and stored in a distribution and that we >> can always access/burn it on cd and go on the moon without internet and load the configuration. >> >> Stef >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

Jan. 19, 2011

Re: [Pharo-project] splitters in table layout

by Tudor Girba

Strange. I just did the followings and it worked just fine: 1. downloaded 12303: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/67/artifa… 2. filed in the attached CS 3. executed | m leftMorph scroll | m := PanelMorph new. m hResizing: #shrinkWrap; vResizing: #spaceFill; changeTableLayout; listDirection: #leftToRight. m addMorphBack: (leftMorph := Morph new color: Color red; minimumExtent: 150@10; extent: 150@10; hResizing: #rigid; "shown for clarity, is the default" vResizing: #spaceFill). m addMorphBack: (EdgeGripMorph new width: ProportionalSplitterMorph splitterWidth; hResizing: #rigid; "not the default this time, vResizing is also #spaceFill by default" target: leftMorph). m addMorphBack: (Morph new color: Color green; minWidth: 100; hResizing: #shrinkWrap; vResizing: #spaceFill). scroll := GeneralScrollPane new changeScrollerTableLayout; scrollTarget: m. scroll openInWindow. Cheers, Doru On 19 Jan 2011, at 20:10, Andreas Wacknitz wrote: > Am 19.01.11 09:54, schrieb Tudor Girba: >> That is strange. Are you using Pharo 1.2? > Yes (pharo-dev at 12303). > > Andreas > >> >> Cheers, >> Doru >> >> >> On 18 Jan 2011, at 21:33, Andreas Wacknitz wrote: >> >>> >>> Am 18.01.2011 um 20:58 schrieb Tudor Girba: >>> >>>> Yes, you missed a changeset Gary sent in the aligning morphs thread (he actually sent two, and you should pick the second one). >>>> >>>> Cheers, >>>> Doru >>>> >>> Ah, thank you. I have found two messages with changesets from January 11th, 2011. >>> After I filein the second changeset alas I will get a DNU Morph>>doFastWindowReframe: when I move the splitter... >>> >>> Regards, >>> Andreas >>> >>> >> >> -- >> www.tudorgirba.com >> >> "To lead is not to demand things, it is to make them happen." >> >> >> >> >> > > -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Jan. 19, 2011

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

by StÃ©phane Ducasse

But now if the server of lukas is eaten by monsters during the night or if you don't have your cool distributions containing all the nice packages of the version you want to load you are toasted. Simple just toasted. So when I program with pharo 1.1 I just want to get the work done and load the components loading in pharo1.1 so I open the repositoryOfTheDsitibution and I load the tools I need. If I need something more advanced I decide to go in the project and check if I can load the version may be developed on 1.2, 1,3 in my version. Or I change and switch to that distribution. So the act of publishing a configuration should not be just a copy this is a publication for inclusion in distribution. Stef > >> 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... > > Agreed! > >> >> On Wed, Jan 19, 2011 at 3:01 PM, Dale Henrichs <dhenrich(a)vmware.com >> <mailto:dhenrich@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> >> <mailto:norbert@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> >> <mailto:norbert@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> >> <mailto:marcus.denker@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> >> <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> >> <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] splitters in table layout

by Tudor Girba

Strange. I just did the followings and it worked just fine: 1. downloaded 12303: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/67/artifa… 2. filed in the attached CS 3. executed | m leftMorph scroll | m := PanelMorph new. m hResizing: #shrinkWrap; vResizing: #spaceFill; changeTableLayout; listDirection: #leftToRight. m addMorphBack: (leftMorph := Morph new color: Color red; minimumExtent: 150@10; extent: 150@10; hResizing: #rigid; "shown for clarity, is the default" vResizing: #spaceFill). m addMorphBack: (EdgeGripMorph new width: ProportionalSplitterMorph splitterWidth; hResizing: #rigid; "not the default this time, vResizing is also #spaceFill by default" target: leftMorph). m addMorphBack: (Morph new color: Color green; minWidth: 100; hResizing: #shrinkWrap; vResizing: #spaceFill). scroll := GeneralScrollPane new changeScrollerTableLayout; scrollTarget: m. scroll openInWindow. Cheers, Doru On 19 Jan 2011, at 20:10, Andreas Wacknitz wrote: > Am 19.01.11 09:54, schrieb Tudor Girba: >> That is strange. Are you using Pharo 1.2? > Yes (pharo-dev at 12303). > > Andreas > >> >> Cheers, >> Doru >> >> >> On 18 Jan 2011, at 21:33, Andreas Wacknitz wrote: >> >>> >>> Am 18.01.2011 um 20:58 schrieb Tudor Girba: >>> >>>> Yes, you missed a changeset Gary sent in the aligning morphs thread (he actually sent two, and you should pick the second one). >>>> >>>> Cheers, >>>> Doru >>>> >>> Ah, thank you. I have found two messages with changesets from January 11th, 2011. >>> After I filein the second changeset alas I will get a DNU Morph>>doFastWindowReframe: when I move the splitter... >>> >>> Regards, >>> Andreas >>> >>> >> >> -- >> www.tudorgirba.com >> >> "To lead is not to demand things, it is to make them happen." >> >> >> >> >> > > -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Jan. 19, 2011

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

by Dale Henrichs

On 01/19/2011 10:28 AM, Guillermo Polito wrote: > 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... Agreed! > > On Wed, Jan 19, 2011 at 3:01 PM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@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> > <mailto:norbert@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> > <mailto:norbert@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> > <mailto:marcus.denker@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> > <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> > <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] 'Unnamed Topic' in Help

by Mariano Martinez Peck

Hi. I am using latest PharoCore1.2 and no matter whcih Help page I browse in the Help System, the label of the windows is "Unnamed Topic". Is this correct? cheers mariano

Jan. 19, 2011

Re: [Pharo-project] Pharo Refactoring Tool

by Mariano Martinez Peck

Hi Alia. Welcome. It is really cool your idea. I hope you can get there. A couple of things: - Iterate. Don't wait the last minute to commit/pubish/announce/integrate in pharo. Give and ask for feedback frequently. - Pharo welcomes you code and fixes. Publish/Commit frequently. Even if you have something not working 100% it is better you publish and Pharo can integrate your changes step by step. - Ask people for feedback and ideas. Write them down. Now, technical. the thing I would love to have to the Pharo "IDE" (not only to refactors), is keyboard shortcuts. I don't care at all the relation between Smalltalk and the mouse (I was not even born). I hate the mouse, and Pharo makes me use muuuuuuch more than I want. It makes me slow. I developed 3 years with Eclipse and I remember being even hours without using the mouse. Check the mailing list and you will see there are millions of mails about it. So....if you can add shortcuts for all current refactoring tools, for me is more than enought ;) Check the project KeyBindings that Guillermo Polito is working on. Good luck and keep us informed. mariano On Wed, Jan 19, 2011 at 6:56 PM, <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/concepts/… > ) but I would love to hear from experienced Smalltalkers about > refactorings that are important to them. > > Thanks, > > Alia > > > >

Jan. 19, 2011

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

by Alexandre Bergel

+1 On 19 Jan 2011, at 16:28, StÃ©phane Ducasse wrote: > We do not want our distributions of code to rely on external servers. > So the act of publishing should means that this is available and stored in a distribution and that we > can always access/burn it on cd and go on the moon without internet and load the configuration. > > Stef > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 19, 2011

Re: [Pharo-project] faro ?

by StÃ©phane Ducasse

Now we understand your question about + and / Noury alcoohol is not good for health :) Stef On Jan 19, 2011, at 6:43 PM, Noury Bouraqadi wrote: > A student of mine sent me this picture :-) > >> >> http://www.linternaute.com/homme/art-de-vivre/selection/selection-de-mousse… >> >> >> > >

Jan. 19, 2011

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

by StÃ©phane Ducasse

We do not want our distributions of code to rely on external servers. So the act of publishing should means that this is available and stored in a distribution and that we can always access/burn it on cd and go on the moon without internet and load the configuration. Stef

Jan. 19, 2011