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

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

by laurent laffont

On Thu, Jan 20, 2011 at 10:12 AM, jaayer <jaayer(a)zoho.com> wrote: > > > > > ---- On Thu, 20 Jan 2011 01:02:54 -0800 jaayer wrote ---- > > I copied the latest version, 1.1.7, to the repository. > Should I update it ? (Don't hesitate to update ConfigurationOfPharo :) Laurent > >> - add project 'XMLSupport Tests' in group 'Dev Tools Tests' > > > >Note that XMLSupport pulls in some "helper" collection packages: an > order-preserving dictionary and a bitmap-based character set, at the moment. > The tests for these packages are *not* loaded in automatically. > > > >>All 361 tests green. > >> > >>Laurent Laffont > >> > >> > >>On Wed, Jan 19, 2011 at 1:18 PM, 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 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 > >> >> > >> >> "We cannot reach the flow of things unless we let go." > >> >> > >> >> > >> >> > >> >> > >> > > >> > -- > >> > Marcus Denker -- http://www.marcusdenker.de > >> > INRIA Lille -- Nord Europe. Team RMoD. > >> > > >> > > >> > > >> > >> > >> > >>-- > >> www.tudorgirba.com > >> > >> "If you interrupt the barber while he is cutting your hair, > >> you will end up with a messy haircut." > >> > >> > >> > >> > >> > > > > > > > > >

Jan. 20, 2011

Re: [Pharo-project] Issue 3554 in pharo: CP1252TextConverter new does not work

by Henrik Johansen

On Jan 20, 2011, at 2:31 59AM, Levente Uzonyi wrote: > On Thu, 20 Jan 2011, pharo(a)googlecode.com wrote: > >> >> Comment #2 on issue 3554 by ryd...(a)gmail.com: CP1252TextConverter new does not work >> http://code.google.com/p/pharo/issues/detail?id=3554 >> >> That's not the "right" way to do it anymore, ever since ByteTextConverter superclass was introduced. (AFAICT that was before 1.0, but after the soup implementation) >> >> The only methods subclasses should implement are class-side methods: >> byteToUnicodeSpec >> encodingNames >> (languageEnvironment) >> >> I'd suggest updating the Soup package to include the implementation found in Core, which works in all versions of Pharo. > > Will it work in Squeak? I'm asking because we're using it in one of our projects and I'll be unhappy if it becomes uncompatible with Squeak the way SmaCC, OB, eCompletion, etc did. > > > Levente Almost... The class variables hold all 256 entries instead of just the non-ascii range, and initialization logic was made a bit different as well when ByteTextConverter was introduced to Squeak :/ It should work with an additional method: CP1252TextConverter class >> initializeDecodeTable ^decodeTable := (0 to: 127) , self byteToUnicodeSpec (decodeTable would be undefined in Pharo, but the method never used) and changing the initialize method, unless you want to implement initializeTables in ByteTextConverter as: initializeTables self initializeDecodeTable; initializeEncodeTable; initializeLatin1MapAndEncodings Looking at initialize implementations in current squeak subclasses that might not be such a bad thing :) Cheers, Henry PS. Is there's a bug in CP1250 in squeak, or is there some hack I don't know about? AFAIK, â¬ (20AC) should be at 128...

Jan. 20, 2011

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

by Norbert Hartl

On 20.01.2011, at 10:18, Tudor Girba wrote: > Hi, > > On 20 Jan 2011, at 10:11, Norbert Hartl wrote: > >> >> On 19.01.2011, at 20:54, StÃ©phane Ducasse wrote: >> >>> 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. >>> >> If it is not just a copy what else is implied? > > As Stef mentioned, there are two things to do: > - copy the actual packages into a different repository > - change the references to Monticello repositories from the Configurations (this should be applied both to packages and to nested configurations) > Thanks Doru for explaining. So this makes total sense to me packaging wise but it is a lot of re-doing while integrating. The repositories have to be changed every single time. But I think that there is a task that automatically copies the packages of a version and that metacello will have some solution for the change in repositories. Norbert > > >> Norbert >> >>> >>>> >>>>> 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." >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > >

Jan. 20, 2011

Re: [Pharo-project] Issue 3553 in pharo: GeneralScrollPane should support both spaceFill and shrinkWrap

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #2 on issue 3553 by marcus.d...(a)gmail.com: GeneralScrollPane should support both spaceFill and shrinkWrap http://code.google.com/p/pharo/issues/detail?id=3553 12312 TODO: 1.3

Jan. 20, 2011

Re: [Pharo-project] Issue 3543 in pharo: Merge latest Glamour theme

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #5 on issue 3543 by marcus.d...(a)gmail.com: Merge latest Glamour theme http://code.google.com/p/pharo/issues/detail?id=3543 in 12312 TODO: 1.3

Jan. 20, 2011

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

by Tudor Girba

Hi, On 20 Jan 2011, at 10:11, Norbert Hartl wrote: > > On 19.01.2011, at 20:54, StÃ©phane Ducasse wrote: > >> 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. >> > If it is not just a copy what else is implied? As Stef mentioned, there are two things to do: - copy the actual packages into a different repository - change the references to Monticello repositories from the Configurations (this should be applied both to packages and to nested configurations) Cheers, Doru > Norbert > >> >>> >>>> 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." >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > -- www.tudorgirba.com "When people care, great things can happen."

Jan. 20, 2011

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

by jaayer

---- On Thu, 20 Jan 2011 01:02:54 -0800 jaayer wrote ---- > > > > >---- On Wed, 19 Jan 2011 12:19:40 -0800 laurent laffont wrote ---- > >>I've copied latest ConfigurationOfXMLSupport in MetacelloRepository. >> >> >>ConfigurationOfPharo-LaurentLaffont.121 >> >> >>XMLSupport: >>- update to release 1.1.6 I copied the latest version, 1.1.7, to the repository. >> - add project 'XMLSupport Tests' in group 'Dev Tools Tests' > >Note that XMLSupport pulls in some "helper" collection packages: an order-preserving dictionary and a bitmap-based character set, at the moment. The tests for these packages are *not* loaded in automatically. > >>All 361 tests green. >> >>Laurent Laffont >> >> >>On Wed, Jan 19, 2011 at 1:18 PM, 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 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 >> >> >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> >> >> >> >> >> > >> > -- >> > Marcus Denker Â -- http://www.marcusdenker.de >> > INRIA Lille -- Nord Europe. Team RMoD. >> > >> > >> > >> >> >> >>-- >> www.tudorgirba.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." >> >> >> >> >> > > >

Jan. 20, 2011

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

by Norbert Hartl

On 19.01.2011, at 20:54, StÃ©phane Ducasse wrote: > 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. > If it is not just a copy what else is implied? Norbert > >> >>> 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. 20, 2011

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

by jaayer

---- On Wed, 19 Jan 2011 12:19:40 -0800 laurent laffont wrote ---- >I've copied latest ConfigurationOfXMLSupport in MetacelloRepository. > > >ConfigurationOfPharo-LaurentLaffont.121 > > >XMLSupport: >- update to release 1.1.6 > - add project 'XMLSupport Tests' in group 'Dev Tools Tests' Note that XMLSupport pulls in some "helper" collection packages: an order-preserving dictionary and a bitmap-based character set, at the moment. The tests for these packages are *not* loaded in automatically. >All 361 tests green. > >Laurent Laffont > > >On Wed, Jan 19, 2011 at 1:18 PM, 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 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 > >> > >> "We cannot reach the flow of things unless we let go." > >> > >> > >> > >> > > > > -- > > Marcus Denker Â -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > > > > >-- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > > > >

Jan. 20, 2011

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

by jaayer

---- On Wed, 19 Jan 2011 04:37:54 -0800 Norbert Hartl 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. I can copy configurations over to MetacelloRepository periodically; it's not too much trouble. Of course, this will result in some redundancy. >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 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 >>>> >>>> "We cannot reach the flow of things unless we let go." >>>> >>>> >>>> >>>> >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." >> >> > > >

Jan. 20, 2011