- Pharo-dev - lists.pharo.org

[Pharo-project] cannot update metacello in rc3

by Tudor Girba

Hi, I took the RC3 dev image and I tried "ConfigurationOfMetacello loadLatestVersion", but it fails. I did not have time to look into this, but this is problematic :). Cheers, Doru -- www.tudorgirba.com "It's not how it is, it is how we see it."

March 24, 2010

[Pharo-project] Issue 2205

by laurent laffont

http://code.google.com/p/pharo/issues/detail?id=2205 In PharoInbox: Morphic-LaurentLaffont.558 As all SimpleHierarchicalListMorph & PluggableTreeMorph users put autoDeselect to false (or bug if not), it's now the default. Laurent Laffont

March 24, 2010

Re: [Pharo-project] JPEGReadWriter and JPEGReadWriter2

by Mariano Martinez Peck

Thanks! http://code.google.com/p/pharo/issues/detail?id=2206 Fixed. In Inbox Name: Graphics-MarianoMartinezPeck.225 Author: MarianoMartinezPeck Time: 24 March 2010, 9:16:53 pm UUID: f951fbb9-7db0-4b75-b383-ec616065476d Ancestors: Graphics-StephaneDucasse.224 Fix to issue http://code.google.com/p/pharo/issues/detail?id=2206 Rename JPEGReadWriter2 to PluginBasedJPEGReadWriter On Wed, Mar 17, 2010 at 4:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > PluginBasedJPEGReadWriter > > > > On Mar 17, 2010, at 2:11 PM, Mariano Martinez Peck wrote: > > > I read class comments and seem to be different, but I don't like the name > at all. We should rename (or remove?) JPEGReadWriter2 to something better. > > > > we should merge them ? I have no idea...I just send a warning to you. > > > > Cheers > > > > Mariano > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by Lukas Renggli

>> The ancestry is not broken! The problem is that you miss *ancestor >> versions*, because they were deleted or moved. > > I know now since we systematically merge during our process I wonder how we break it. > May be this is when you publish the smalltalk rewrite. Could check if you have > Â Â Â Â Polymorph-Widgets-lr.214 in your local cache? Yes, and it is also in <http://www.squeaksource.com/PharoTreatedInbox>. So you need to add that repository to be able to merge. > I know now let me repeat the bug I see This is not a bug of Monticello. This is because you move versions around and you don't tell Monticello where to find them. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by StÃ©phane Ducasse

This is normal because ancestry cross over repository. I think that there is something really strange. EIther you get a truly distributed system or you get a local. With MC you get a distributed which can be brittle (even if I understand well the problem ancestry is solving). I think that a pessimistic merge (more than just going one by one on the changes would help). Stef On Mar 24, 2010, at 8:12 PM, Dale Henrichs wrote: > Stef and Lukas, > > The other situation that I have seen these types of errors is when the package that I am merging into(?) does not have the repository where the common ancestor mcz file is located. > > For example if I have Seaside.gemstone-dkh.500 with http://seaside.gemstone.com/ss/seaside in it's repository group. When I attempt to merge Seaside.lr.505 in http://www.squeaksource.com/seaside I get an error. > > If I add http://www.squeaksource.com/seaside to the repository group for Seaside.gemstone-dkh.500 and then try the merge, it works.. > > Does this help or have I missed something along the way:) > > Dale > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | On Mar 24, 2010, at 6:46 PM, Lukas Renggli wrote: > | > | >> what is strange is that when I merge the latest loaded version I > | got the normal "no changes" > | >> and I could merge without having to add a new repository. > | > > | > Sure, because in this situation the common ancestor is the version > | you > | > load (so it can always be found). And the delta between the working > | > copy and the version you merge is empty, so you have no changes. > | > | You did not get me right > | > | scenario 1: I click on the slice press merge get an error ancestor > | not found > | scenario 2: I click on the **latest working copy version* that led to > | the error of scenario and do merge I get no changes of course > | + scenario 1 and it merges without the error of scenario 1 (it means > | that he suddenly magically found the ancestry) > | > | for me there is a bug. Because between scenario 1 and 2 there is no > | difference since this is exactly the same version that I have > | as working copy. > | > | > > | >> I think that in squeak they cut the problem (if you do not have the > | history what do you do). > | >> You should still be able to merge. > | > > | > I don't think they do anything different? If the ancestor version > | is > | > missing you simply cannot do a meaningful merge. It is as simple as > | > that. > | > | Yes i see what you mean. You cannot use the ancestry to do a clever > | merge. What I meant is that we should be able to see what changed > | based on the latest loaded version (no need to have the complete > | ancestor since it is broken). > | > | Because often using the latest working copy and having the diff is > | only what I need. Is whatI'm sayign make sense? > | > | > | _______________________________________________ > | 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

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by StÃ©phane Ducasse

>>> > The ancestry cannot be lost. The .mcz files are the one thing that can > disappear. Yes I know but the result is the same. >> > The working copy is just one of the variable things in the merge. > There is also the other version you load (and that might be different > in your scenarios), and the common ancestor between the two (again > that might be different in your scenarios). I know. >> Yes i see what you mean. You cannot use the ancestry to do a clever merge. What I meant is that we should be able to see what changed >> based on the latest loaded version (no need to have the complete ancestor since it is broken). > > The ancestry is not broken! The problem is that you miss *ancestor > versions*, because they were deleted or moved. I know now since we systematically merge during our process I wonder how we break it. May be this is when you publish the smalltalk rewrite. Could check if you have Polymorph-Widgets-lr.214 in your local cache? I know now let me repeat the bug I see scenario1 working copy polymorphWiget.7.mcz I click on polymorphWiget.24.mcz merge -> I get an error ancestor cannot be found scenario1 working copy polymorphWiget.7.mcz I click on polymorphWiget.7.mcz merge -> no changes (ok this is what I hope what arriving) Then I click on polymorphWiget.24.mcz merge -> I get no error. So for me there is something strange. Stef

March 24, 2010

Re: [Pharo-project] Montacello configuration writing

by Dale Henrichs

Hilaire, Thanks for the feedback. I've opened http://code.google.com/p/metacello/issues/detail?id=69 to track this issue. This might be a shortcut worth adding, since it _is_ used very frequently. You'd still need to revert to the #package:with: form if you wanted to set multiple attributes ... does that make sense? Dale ----- "Hilaire Fernandes" <hilaire.fernandes(a)gmail.com> wrote: | Learning Montacello configuration. | | Instead of writing a package dependency as | | spec | package: 'CoolToolSet--Core' with: [spec requires: 'CoolBrowser | ALL'] | | Can't we write more clearly as; | | spec package: 'CoolToolSet--Core' requires: 'CoolBrowser ALL' | | I find the first one far too cryptic. | | Hilaire | | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 24, 2010

Re: [Pharo-project] About MC

by StÃ©phane Ducasse

On Mar 24, 2010, at 7:11 PM, Lukas Renggli wrote: >>> In either case there is never a hole. Each version stores the complete >>> ancestry tree it knows, that is the filename and uuid of each version. >>> The problem you run into is that you delete and move version files. If >>> Monticello cannot find the files that it refers to in its ancestry you >>> cannot merge automatically. That's why repositories should strictly be >>> read-only. >> >> I do not really understand how we ended up with holes then. > > I guess I will have to explain it on a white-board, but here's another try: > > The problem is that Monticello cannot find the common ancestor because > you deleted it from its repository. To fix the problem you have to > find this version and tell Monticello where it can load it from by > adding that repository. It is likely that you find the version > somewhere on SqueakSource or in some package-cache on your machine. I know that ;) > If you can't find the version you have to merge manually. This means > you browse the other version or you calculate the changes between your > version and the version you want to merge and apply the changes that > you think should go in manually one-by-one. Then you 'adopt' that > version to the ancestry. Yes this is for the me the minimum I would like to have instead of an error. Also during the manual merge we do not have to give up the fact that superclass, adding new method first... should be changed first and all the logic Stef

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by Dale Henrichs

Stef and Lukas, The other situation that I have seen these types of errors is when the package that I am merging into(?) does not have the repository where the common ancestor mcz file is located. For example if I have Seaside.gemstone-dkh.500 with http://seaside.gemstone.com/ss/seaside in it's repository group. When I attempt to merge Seaside.lr.505 in http://www.squeaksource.com/seaside I get an error. If I add http://www.squeaksource.com/seaside to the repository group for Seaside.gemstone-dkh.500 and then try the merge, it works.. Does this help or have I missed something along the way:) Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | On Mar 24, 2010, at 6:46 PM, Lukas Renggli wrote: | | >> what is strange is that when I merge the latest loaded version I | got the normal "no changes" | >> and I could merge without having to add a new repository. | > | > Sure, because in this situation the common ancestor is the version | you | > load (so it can always be found). And the delta between the working | > copy and the version you merge is empty, so you have no changes. | | You did not get me right | | scenario 1: I click on the slice press merge get an error ancestor | not found | scenario 2: I click on the **latest working copy version* that led to | the error of scenario and do merge I get no changes of course | + scenario 1 and it merges without the error of scenario 1 (it means | that he suddenly magically found the ancestry) | | for me there is a bug. Because between scenario 1 and 2 there is no | difference since this is exactly the same version that I have | as working copy. | | > | >> I think that in squeak they cut the problem (if you do not have the | history what do you do). | >> You should still be able to merge. | > | > I don't think they do anything different? If the ancestor version | is | > missing you simply cannot do a meaningful merge. It is as simple as | > that. | | Yes i see what you mean. You cannot use the ancestry to do a clever | merge. What I meant is that we should be able to see what changed | based on the latest loaded version (no need to have the complete | ancestor since it is broken). | | Because often using the latest working copy and having the diff is | only what I need. Is whatI'm sayign make sense? | | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 24, 2010

Re: [Pharo-project] funny behavior with MC

by Lukas Renggli

>>> what is strange is that when I merge the latest loaded version I got the normal "no changes" >>> and I could merge without having to add a new repository. >> >> Sure, because in this situation the common ancestor is the version you >> load (so it can always be found). And the delta between the working >> copy and the version you merge is empty, so you have no changes. > > You did not get me right > > Â Â Â Â scenario 1: I click on the slice press merge get an error ancestor not found > Â Â Â Â scenario 2: I click on the **latest working copy version* that led to the error of scenario and do merge I get no changes of course I do not understand. - What is the "latest working copy version"? The working copy is the code you currently have in your image. - What do slices have to do with this? They shouldn't, because in the end the dependent versions are merged individually. > Â Â Â Â + scenario 1 and it merges without the error of scenario 1 (it means that he suddenly magically found the ancestry) The ancestry cannot be lost. The .mcz files are the one thing that can disappear. > for me there is a bug. Because between scenario 1 and 2 there is no difference since this is exactly the same version that I have > as working copy. The working copy is just one of the variable things in the merge. There is also the other version you load (and that might be different in your scenarios), and the common ancestor between the two (again that might be different in your scenarios). > Yes i see what you mean. You cannot use the ancestry to do a clever merge. Â What I meant is that we should be able to see what changed > based on the latest loaded version (no need to have the complete ancestor since it is broken). The ancestry is not broken! The problem is that you miss *ancestor versions*, because they were deleted or moved. > Because often using the latest working copy and having the diff is only what I need. Is whatI'm sayign make sense? To get a diff between your working copy and a version you select this version and click on changes. That doesn't require any other version but the selected one. It doesn't even use the ancestry information. No, I can't make sense of it :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 24, 2010