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

Re: [Pharo-project] Question about O2 dependencies

by StÃ©phane Ducasse

lukas could you copy the icons I did from O2 :) steal them please :) Stef On Jan 19, 2010, at 7:15 PM, Lukas Renggli wrote: > 2010/1/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger >> <roethlis(a)iam.unibe.ch> wrote: >>> >>>>> Ok. Good. Right now, the Pharo community decided to use Lukas' >>>>> repository instead of Colin's one, but I guess it can be merged. Lukas ? >>> >>>> I find it unfriendly to merge into a foreign repository -- pull, fork and >>>> merge in your own repository. And eventually ask the maintainer to merge the >>>> code. >>> >>> I'm confused. What is the right process to update OB for Pharo now? In >>> Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this >>> gonna change now? Where should I commit a patch to OB now, to Colin's, to >>> Lukas' repo, somewhere else? >>> >>> Maybe best would be to have a non-personal repo on squeaksource which can >>> be used by all OB developers and from where Pharo takes the code? >>> >>> David >> >> I am confused too. Actually, this is exactly what I asked when people >> suggested to use Lukas' OB. > > Public code repositories do not work. I learned that with Seaside, and > we all saw that in all its ugliness with OmniBrowser. > > If this is a popular project in a public repository people will commit > changes to that repository. Some of the committed changes are ... > > - untested > - break existing tests > - break the architecture > - break other code > - put into the wrong package > - only working for the committer > - badly formatted or commented > - depend on non-existing code > - ... > > Now, if nobody constantly observes that repository and cleans it up, > you have an enormous mess. There are basically dozens of forks and > nobody knows what works, what is broken, what is official, what to > load, what to use, where to continue with development, etc. > > And that's not even the end of it. The next thing that happens is that > people start to merge: so random versions with random changes are > merged in a random order. As a result the problems and bugs multiply. > > After I saw GitHub, I realized that in the open-source world only > read-only code repositories work. The cool thing is that Monticello > and Git have a very similar model, so we just have to adapt their > process: > > - Every open-source project has a public read-only repository. Only > core contributes that trust each other can commit into this > repository. > > - If I want to change something, submit a bug-fix, or an enhancement I > simply fork the complete code base and commit it into my own > repository. > > - As a nice open-source contributor I ask one of the official > maintainers to merge my changes by pointing them to my repository: > > - If they like the changes, they will merge them into the official > repository. > > - If they don't like the changes, that's fine too. I have my own > repository and can use the code in there. > > That's it. It is simple and works really well. > > That's why my OB repository is read-only. I know that the code in > there passes all tests and that it does exactly what I want. Please > fork it, improve it, fix things, etc. If I learn about the changes and > if I like them I will merge them (that's what I did with some of the > O2 code). I do not commit my changes to Colin's repository though, if > he wants the code he can pull it (that's what he did in the past too). > > 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. 19, 2010

Re: [Pharo-project] [update 1.1] #11164

by StÃ©phane Ducasse

Excellent I will integrate it now :) Stef On Jan 19, 2010, at 7:22 PM, Mariano Martinez Peck wrote: > I attached a fix. Can you check ? > > Sorry, don't have time to do a slice. > > On Tue, Jan 19, 2010 at 6:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > strange I do not find the senders of > > isolationHead: > > Stef > > On Jan 19, 2010, at 3:49 PM, Henrik Johansen wrote: > > > The hardcoded debugger change causes the "Debug it" command to fail. > > > > What is the extra isolationHead: parameter for anyways? > > > > Cheers, > > Henry > > > > On Jan 16, 2010, at 9:26 55PM, Marcus Denker wrote: > > > >> 11164 > >> ----- > >> > >> Issue 441: Hardcoded debugger > >> Issue 1828: testAnnotationPane > >> Issue 1819: 1.1: some packages have no repository > >> > >> > >> -- > >> Marcus Denker -- http://www.marcusdenker.de > >> INRIA Lille -- Nord Europe. Team RMoD. > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <DebugIt-isolationHead.1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 19, 2010

Re: [Pharo-project] [update 1.1] #11164

by Henrik Sperre Johansen

One of the methods sent by a method included in the changeset, #process: controller:context:isolationHead: Only #process: controller:context: exists anymore. On 19.01.2010 18:55, StÃ©phane Ducasse wrote: > strange I do not find the senders of > > isolationHead: > > Stef > > On Jan 19, 2010, at 3:49 PM, Henrik Johansen wrote: > > >> The hardcoded debugger change causes the "Debug it" command to fail. >> >> What is the extra isolationHead: parameter for anyways? >> >> Cheers, >> Henry >> >> On Jan 16, 2010, at 9:26 55PM, Marcus Denker wrote: >> >> >>> 11164 >>> ----- >>> >>> Issue 441: Hardcoded debugger >>> Issue 1828: testAnnotationPane >>> Issue 1819: 1.1: some packages have no repository >>> >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Jan. 19, 2010

Re: [Pharo-project] [update 1.1] #11164

by Mariano Martinez Peck

I attached a fix. Can you check ? Sorry, don't have time to do a slice. On Tue, Jan 19, 2010 at 6:55 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > strange I do not find the senders of > > isolationHead: > > Stef > > On Jan 19, 2010, at 3:49 PM, Henrik Johansen wrote: > > > The hardcoded debugger change causes the "Debug it" command to fail. > > > > What is the extra isolationHead: parameter for anyways? > > > > Cheers, > > Henry > > > > On Jan 16, 2010, at 9:26 55PM, Marcus Denker wrote: > > > >> 11164 > >> ----- > >> > >> Issue 441: Hardcoded debugger > >> Issue 1828: testAnnotationPane > >> Issue 1819: 1.1: some packages have no repository > >> > >> > >> -- > >> Marcus Denker -- http://www.marcusdenker.de > >> INRIA Lille -- Nord Europe. Team RMoD. > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 19, 2010

Re: [Pharo-project] Question about O2 dependencies

by Gary Chambers

I know exactly what you feel for this. Regards, Gary ----- Original Message ----- From: "Lukas Renggli" <renggli(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, January 19, 2010 6:15 PM Subject: Re: [Pharo-project] Question about O2 dependencies > 2010/1/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger >> <roethlis(a)iam.unibe.ch> wrote: >>> >>>>> Ok. Good. Right now, the Pharo community decided to use Lukas' >>>>> repository instead of Colin's one, but I guess it can be merged. Lukas >>>>> ? >>> >>>> I find it unfriendly to merge into a foreign repository -- pull, fork >>>> and >>>> merge in your own repository. And eventually ask the maintainer to >>>> merge the >>>> code. >>> >>> I'm confused. What is the right process to update OB for Pharo now? In >>> Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this >>> gonna change now? Where should I commit a patch to OB now, to Colin's, >>> to >>> Lukas' repo, somewhere else? >>> >>> Maybe best would be to have a non-personal repo on squeaksource which >>> can >>> be used by all OB developers and from where Pharo takes the code? >>> >>> David >> >> I am confused too. Actually, this is exactly what I asked when people >> suggested to use Lukas' OB. > > Public code repositories do not work. I learned that with Seaside, and > we all saw that in all its ugliness with OmniBrowser. > > If this is a popular project in a public repository people will commit > changes to that repository. Some of the committed changes are ... > > - untested > - break existing tests > - break the architecture > - break other code > - put into the wrong package > - only working for the committer > - badly formatted or commented > - depend on non-existing code > - ... > > Now, if nobody constantly observes that repository and cleans it up, > you have an enormous mess. There are basically dozens of forks and > nobody knows what works, what is broken, what is official, what to > load, what to use, where to continue with development, etc. > > And that's not even the end of it. The next thing that happens is that > people start to merge: so random versions with random changes are > merged in a random order. As a result the problems and bugs multiply. > > After I saw GitHub, I realized that in the open-source world only > read-only code repositories work. The cool thing is that Monticello > and Git have a very similar model, so we just have to adapt their > process: > > - Every open-source project has a public read-only repository. Only > core contributes that trust each other can commit into this > repository. > > - If I want to change something, submit a bug-fix, or an enhancement I > simply fork the complete code base and commit it into my own > repository. > > - As a nice open-source contributor I ask one of the official > maintainers to merge my changes by pointing them to my repository: > > - If they like the changes, they will merge them into the official > repository. > > - If they don't like the changes, that's fine too. I have my own > repository and can use the code in there. > > That's it. It is simple and works really well. > > That's why my OB repository is read-only. I know that the code in > there passes all tests and that it does exactly what I want. Please > fork it, improve it, fix things, etc. If I learn about the changes and > if I like them I will merge them (that's what I did with some of the > O2 code). I do not commit my changes to Colin's repository though, if > he wants the code he can pull it (that's what he did in the past too). > > 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. 19, 2010

Re: [Pharo-project] Question about O2 dependencies

by Lukas Renggli

2010/1/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Tue, Jan 19, 2010 at 2:33 PM, David Roethlisberger > <roethlis(a)iam.unibe.ch> wrote: >> >>>> Ok. Good. Right now, the Pharo community decided to use Lukas' >>>> repository instead of Colin's one, but I guess it can be merged. Lukas ? >> >>> I find it unfriendly to merge into a foreign repository -- pull, fork and >>> merge in your own repository. And eventually ask the maintainer to merge the >>> code. >> >> I'm confused. What is the right process to update OB for Pharo now? In >> Pharo-dev, as far as I see, OB is still taken from Colin's repo. Is this >> gonna change now? Where should I commit a patch to OB now, to Colin's, to >> Lukas' repo, somewhere else? >> >> Maybe best would be to have a non-personal repo on squeaksource which can >> be used by all OB developers and from where Pharo takes the code? >> >> David > > I am confused too. Actually, this is exactly what I asked when people > suggested to use Lukas' OB. Public code repositories do not work. I learned that with Seaside, and we all saw that in all its ugliness with OmniBrowser. If this is a popular project in a public repository people will commit changes to that repository. Some of the committed changes are ... - untested - break existing tests - break the architecture - break other code - put into the wrong package - only working for the committer - badly formatted or commented - depend on non-existing code - ... Now, if nobody constantly observes that repository and cleans it up, you have an enormous mess. There are basically dozens of forks and nobody knows what works, what is broken, what is official, what to load, what to use, where to continue with development, etc. And that's not even the end of it. The next thing that happens is that people start to merge: so random versions with random changes are merged in a random order. As a result the problems and bugs multiply. After I saw GitHub, I realized that in the open-source world only read-only code repositories work. The cool thing is that Monticello and Git have a very similar model, so we just have to adapt their process: - Every open-source project has a public read-only repository. Only core contributes that trust each other can commit into this repository. - If I want to change something, submit a bug-fix, or an enhancement I simply fork the complete code base and commit it into my own repository. - As a nice open-source contributor I ask one of the official maintainers to merge my changes by pointing them to my repository: - If they like the changes, they will merge them into the official repository. - If they don't like the changes, that's fine too. I have my own repository and can use the code in there. That's it. It is simple and works really well. That's why my OB repository is read-only. I know that the code in there passes all tests and that it does exactly what I want. Please fork it, improve it, fix things, etc. If I learn about the changes and if I like them I will merge them (that's what I did with some of the O2 code). I do not commit my changes to Colin's repository though, if he wants the code he can pull it (that's what he did in the past too). Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 19, 2010

Re: [Pharo-project] [update 1.1] #11167

by Mariano Martinez Peck

945 has to be in 1.0 also. On Tue, Jan 19, 2010 at 7:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > 11167 > ----- > > - Issue 945: Annoying bug: UndefinedObject(Object)>>doesNotUnderstand: > #mimeTypes > -polymorph updates > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 19, 2010

[Pharo-project] [update 1.1] #11167

by StÃ©phane Ducasse

11167 ----- - Issue 945: Annoying bug: UndefinedObject(Object)>>doesNotUnderstand: #mimeTypes -polymorph updates

Jan. 19, 2010

Re: [Pharo-project] Polymorph final

by Mariano Martinez Peck

Stef: this is only 1.1 or 1.0 also ? On Tue, Jan 19, 2010 at 6:59 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > As said, ignore those... just not in core. > > Feel free to join IRC for these questions ;-) > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, January 19, 2010 5:54 PM > Subject: Re: [Pharo-project] Polymorph final > > > I get > > This package depends on the following classes: > PackagePaneBrowser > SMSqueakMap > PreferencesPanel > UUniverseBrowser > > when trying to merge the PolymorphTaskBarIcons > > I'm releasing now the rest > Stef > > > On Jan 19, 2010, at 6:35 PM, Gary Chambers wrote: > > > Might be worth merging the TaskbarIcons too. Ignore any warnings > > (UniverseBrowser etc.). Should just load the valid bits. Just a nicety, > > taskbar icons/window icons (for supporting themes) etc. > > > > Regards, Gary > > > > ----- Original Message ----- > > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > > To: <Pharo-project(a)lists.gforge.inria.fr> > > Sent: Tuesday, January 19, 2010 5:31 PM > > Subject: Re: [Pharo-project] Polymorph final > > > > > >> Ok I will do an integration pass later today :) > >> > >> Stef > >> > >> On Jan 19, 2010, at 6:01 PM, Gary Chambers wrote: > >> > >>> Nearly the last version on SqueakSource. Polymorph-Widgets-gvc.101.mcz. > >>> I seem to have lost some fixes for multiFormFillStyle (oddity with > >>> pressed control buttons...). > >>> > >>> Let me know if there are any merge problems. > >>> > >>> Adds OverflowRowMorph to browser switches/button-bar. > >>> > >>> Regards, Gary > >>> _______________________________________________ > >>> 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 > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 19, 2010

Re: [Pharo-project] After OB, compare to current version uses old diff

by Gary Chambers

Clearly the cruicial method is overwritten... VersionsBrowser>>compareToOtherVersion. Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, January 19, 2010 5:57 PM Subject: Re: [Pharo-project] After OB,compare to current version uses old diff 2010/1/19 Gary Chambers <gazzaguru2(a)btinternet.com> Unless code has changed then the setting for "Use Polymorph difference tools" should do. I expect some code regression may have happened though. Thanks Gary. The preference is the one Henrik said, useNewDiffToolsForMC, but it is not working for me. You can try it like this: take the latest PharoCore 1.0 image, (10506). You will notice that it is working with the new diff. Then, evaluate: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; load. ((Smalltalk at: #ConfigurationOfOmniBrowser) project version: '1.0') load. Or download OB by hand from Lukas repo. After this, you will notice it uses the old diff even if the preference is enable and even disabling it and enabling again. Cheers Mariano Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, January 19, 2010 4:35 PM Subject: Re: [Pharo-project] After OB,compare to current version uses old diff On Tue, Jan 19, 2010 at 5:22 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: Preferences >> useNewDiffToolsForMC? I tried this before sending the email, but not. I didn't work :( There was some discussion some time back, I believe Lukas stated he liked the old tools better. Ok..didn't know. Can't say I blame him, I'm never quite sure if I'm installing new one or keeping old when merging from MC until after the fact when I use the Polymorph tools ... I can blame him at all. He is helping us a lot maintaining OB a lot. If we use his OB repository, then we should adapt to him. I don't pretend he change his default values or preferences. I just want to know how to set up again the new diff :) Cheers Mariano Cheers, Henry On Jan 19, 2010, at 5:05 26PM, Mariano Martinez Peck wrote: > Hi: If you take a PharoCore image, and browse the editions of a class, then select an older one, and then select "compare to current", you see the differences using the "new" diff, the same that we use in MC. > > However, after installing OB in a core image, it uses the "old" version. I am not sure that change is due to OB, but at least it seems. I checked in Preferences but I didn't find anything. > > Any hint how to put new diff again after installing OB ? > > Thanks! > > 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 -------------------------------------------------------------------------- _______________________________________________ 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 ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 19, 2010