I have been fiddling with monticello for an intense couple of days, and
now I think it works as I always wish it should have done! For a Monticello revolution check out this version in http://www.squeaksource.com/mc Summary: * This version for 3.9/3.10 supports pseudo-atomic loading. * now up to date with fixes from all over the place. * now supports out-of-order package loading. * now supports safe package removal i.e. unloading a package does not break other packages. Caveats: this has not yet been tested with traits Benefits from the merged version: (should be) - password manager, does not keep passwords in image. - ignore the order of class variables - loading FFI external structures - copyAll versions from one repository to another - ui fixes -- bring the tree for dependent packages back -- provide more progress information -- don't scale the toolbar then resizing the monticello browser Benefits in addition to those in previous versions: * Dont lose your method extensions! * Load/Unload packages to your hearts content. * Edit packages even when all their dependents are not present * Write packages designed to lie-in-wait to enhance other packages when loaded. enjoy Keith ------------------- Details: I have attempted to merge all of the branches of Monticello and PackageInfo that I could find on. squeaksource/impara/wiresong/squeakfoundation 39a and 310. This includes latest fixes including the PasswordManager, preamble's postambles, support for FFI and the ever so useful copyAll button It seems also that the impara branch of mc supported the recovery of overridden methods, any methods which are 'extended' by another package, and categorized with the '-override' suffix, 'should' not be lost when you save a package. (I wish someone had told me about this before!) Out-of order loading of packages, via a new class MCOrphanage. This enables a package to 'extend', and 'override' methods in not-yet-loaded packages, and to subclass not-yet-loaded subclasses. Not yet actually loaded ('orphaned') extensions should also save with the package so as not to be lost. To Do: make this loadable into 3.7 and 3.8, since I am using 3.8 for dev at the moment. See http://bugs.squeak.org/view.php?id=6476 To Do: Test with Traits. ---------- TestSpec Loading a package uses orphanage for not yet loaded items Description: When loading a package: Methods and classes which cant load go in orphanage. Before loading any package, the orphanage is added to the package loader in an attempt to rehome orphans. Test 1) out of order loading step 1) load package OrphanageTest-Test1 Validation: select .Orphanage and 'Browse', there should be 4 orphans in total comrising 2 extension methods, awaiting a class, and one class awaiting a superclass, and one method of this class. step 2) load package OrphanageTest-Test2 Validation: .Orphanage should contain only 1 extension method awaiting a class. System categories 'OrphanageTest-Test1' and 'OrphanageTest-Test2' should be populated with the packages. Test 2) As test 1, but test loading in reverse order. Unloading package remembers to take orphans as well, and mop up When unloading a package: Methods and classes which are in the orphanage for that package need to be removed as well. When a package unloads its classes from the image it removes its own methods, but not its extension methods belonging to other packages, these need to be mopped up and placed in the orphanage so they are not lost. Classes left without a superclass remain in the image, but the orphanage has a class definiton added, ready to relink the class with its superclass should it be reloaded. When browsing or saving, the definitions of such classes should not include the 'AnObsolete' prefix. These classes remain in the image and can be modified, and remain part of the package as normal. Testing package removal Test 1) package removal - simple case step 1) load package OrphanageTest-Test1 step 2) unload package OrphanageTest-Test1 Validation: .Orphanage and system category 'OrphanageTest-Test1' should be empty. Test 2) package removal - complex case step 1) load package OrphanageTest-Test1 (extends Tests 2 and 3) step 2) load package OrphanageTest-Test2 (extends Tests 1) step 3) unload package OrphanageTest-Test2 Validation: This should leave 2 orphaned extension methods awaiting their classes, one to OrphanageTest2, the other to OrphanageTest3, there should also be a class definition for the 'redefinition' of the now obsolete-but-still-present-in-the-image OrphanageTest2Subclass The system does not return to the exact same state as after step 1, because the class OrphanageTest2Subclass having lost its superclass is now superclassed by AnObsoleteOrphanageTest2. Validation 2: Browse the remaining OrphanageTest-Test1 to confirm that the class is depicted without the 'AnObsolete' prefix. Validation 2: Select the package click 'Changes' to verify that the package is unchanged from the package in the repository. Test2b) Reload OrphanageTest-Test2 Validate: OrphanageTest2Subclass now has OrphanageTest2 as a superclass. and OrphanageTest2 now has OrphanageTest2Subclass in its subclasses. Test2c) Unload and Reload OrphanageTest-Test2 Validate that state is similar to Test 2b) |
Hi Keith,
I think this is a really good work. We finally have a place with an up-to-date monticello version. Is loading Monticello-kph.343.mcz the only thing to do to update everything? Since I work a lot with traits, I will tell you if your version supports traits. Thank you very much for your work. 2007/5/11, Keith Hodges <[hidden email]>: > I have been fiddling with monticello for an intense couple of days, and > now I think it works as I always wish it should have done! > > For a Monticello revolution check out this version in > http://www.squeaksource.com/mc > > Summary: > > * This version for 3.9/3.10 supports pseudo-atomic loading. > * now up to date with fixes from all over the place. > * now supports out-of-order package loading. > * now supports safe package removal > i.e. unloading a package does not break other packages. > > Caveats: this has not yet been tested with traits > > Benefits from the merged version: (should be) > > - password manager, does not keep passwords in image. > - ignore the order of class variables > - loading FFI external structures > - copyAll versions from one repository to another > - ui fixes > -- bring the tree for dependent packages back > -- provide more progress information > -- don't scale the toolbar then resizing the monticello browser > > Benefits in addition to those in previous versions: > > * Dont lose your method extensions! > * Load/Unload packages to your hearts content. > * Edit packages even when all their dependents are not present > * Write packages designed to lie-in-wait to enhance other packages > when loaded. > > enjoy > > Keith > > ------------------- > Details: > > I have attempted to merge all of the branches of Monticello and > PackageInfo that I could find on. > > squeaksource/impara/wiresong/squeakfoundation 39a and 310. > > This includes latest fixes including the PasswordManager, preamble's > postambles, support for FFI and the ever so useful copyAll button > > It seems also that the impara branch of mc supported the recovery of > overridden methods, any methods which are 'extended' by another package, > and categorized with the '-override' suffix, 'should' not be lost when > you save a package. (I wish someone had told me about this before!) > > Out-of order loading of packages, via a new class MCOrphanage. > > This enables a package to 'extend', and 'override' methods in > not-yet-loaded packages, and to subclass not-yet-loaded subclasses. Not > yet actually loaded ('orphaned') extensions should also save with the > package so as not to be lost. > > To Do: make this loadable into 3.7 and 3.8, since I am using 3.8 > for dev at the moment. See http://bugs.squeak.org/view.php?id=6476 > > To Do: Test with Traits. > > ---------- > TestSpec > > Loading a package uses orphanage for not yet loaded items > Description: When loading a package: Methods and classes which cant load > go in orphanage. Before loading any package, the orphanage is added to > the package loader in an attempt to rehome orphans. > > Test 1) out of order loading > step 1) load package OrphanageTest-Test1 > Validation: select .Orphanage and 'Browse', there should be 4 orphans in > total comrising 2 extension methods, awaiting a class, and one class > awaiting a superclass, and one method of this class. > step 2) load package OrphanageTest-Test2 > Validation: .Orphanage should contain only 1 extension method awaiting a > class. System categories 'OrphanageTest-Test1' and 'OrphanageTest-Test2' > should be populated with the packages. > > Test 2) As test 1, but test loading in reverse order. > > Unloading package remembers to take orphans as well, and mop up > When unloading a package: Methods and classes which are in the orphanage > for that package need to be removed as well. > > When a package unloads its classes from the image it removes its own > methods, but not its extension methods belonging to other packages, > these need to be mopped up and placed in the orphanage so they are not > lost. > > Classes left without a superclass remain in the image, but the orphanage > has a class definiton added, ready to relink the class with its > superclass should it be reloaded. > > When browsing or saving, the definitions of such classes should not > include the 'AnObsolete' prefix. These classes remain in the image and > can be modified, and remain part of the package as normal. > > Testing package removal > Test 1) package removal - simple case > step 1) load package OrphanageTest-Test1 > step 2) unload package OrphanageTest-Test1 > Validation: .Orphanage and system category 'OrphanageTest-Test1' should > be empty. > > Test 2) package removal - complex case > step 1) load package OrphanageTest-Test1 (extends Tests 2 and 3) > step 2) load package OrphanageTest-Test2 (extends Tests 1) > step 3) unload package OrphanageTest-Test2 > Validation: This should leave 2 orphaned extension methods awaiting > their classes, one to OrphanageTest2, the other to OrphanageTest3, there > should also be a class definition for the 'redefinition' of the now > obsolete-but-still-present-in-the-image OrphanageTest2Subclass > > The system does not return to the exact same state as after step 1, > because the class OrphanageTest2Subclass having lost its superclass is > now superclassed by AnObsoleteOrphanageTest2. > Validation 2: Browse the remaining OrphanageTest-Test1 to confirm that > the class is depicted without the 'AnObsolete' prefix. > Validation 2: Select the package click 'Changes' to verify that the > package is unchanged from the package in the repository. > > Test2b) Reload OrphanageTest-Test2 > Validate: OrphanageTest2Subclass now has OrphanageTest2 as a superclass. > and OrphanageTest2 now has OrphanageTest2Subclass in its subclasses. > > Test2c) Unload and Reload OrphanageTest-Test2 > Validate that state is similar to Test 2b) > > > > -- Damien Cassou |
In reply to this post by keith1y
El 5/11/07 2:50 AM, "Keith Hodges" <[hidden email]> escribió: > For a Monticello revolution check out this version in > http://www.squeaksource.com/mc Horrible. Ask n times about password (That's why I remove of same in 3.10 building) People don't should mess with crucial packages what have fine Squeakers as owners. If some wish play his own game, fine, for me Squeak is TEAM work. Edgar, Advocatus Diaboli again |
Dear Edgar,
I am sorry but you appear to have found what I think is called a minor bug, the host string is not matching the persisted string for some reason. Simple bugs like that can be fixed in a moment. This moment is nothing compared to the 70 or so hours I have invested in the rest of the code. Merging code from 4 repositories, I may have missed a thing or two. Especially when the code you are merging is modifying the tool that you are using to perform the merge! Not to worry the working code is out there somewhere. The PasswordManager is not my code, it comes from Andreas. As I said it worked for me. Incidently, I forgot to include the atomic loading code in that last release, and so have got my self into refactoring it and making it work really well. Monticello is has some pretty cool code in it, I take my hat off to the writers. I just think it is such a shame that it basically doesnt work as it should. When you see it working as it should you realise what you have been missing! If I am wrong then, and Monticello 1.5 ;-) doesnt cut the mustard, then the joke is on me for a wasted week. If I am right then Monticello 2 will have some tough competition. Best regards Keith > Horrible. > Ask n times about password (That's why I remove of same in 3.10 building) > People don't should mess with crucial packages what have fine Squeakers as > owners. > If some wish play his own game, fine, for me Squeak is TEAM work. > > Edgar, Advocatus Diaboli again > > > > > > |
In reply to this post by Edgar J. De Cleene
p.s.
As a bonus, I will include some class comments to explain how some parts of monticello work. Its a shame the maintainers whose code is so crucial to the welfare of squeak and its users don't think it is worth documenting. If they had then someone might have got this working properly years ago! IMHO: Lack of documentation is a false economy. Keith |
In reply to this post by keith1y
Keith, I think it is great that you are trying to merge all the
various branches. One of the problems of Monticello is that it has no owner; there is nobody taking care of it. I thought about trying to track down the various branches and decided I didn't have time. Expect to have a lot of people find things wrong. Merging features tends to result in lots of little problems. This doesn't mean you did a bad job, it is just the nature of merging lots of features. -Ralph |
Ralph Johnson wrote:
> Keith, I think it is great that you are trying to merge all the > various branches. One of the problems of Monticello is that it has no > owner; there is nobody taking care of it. I thought about trying to > track down the various branches and decided I didn't have time. > > Expect to have a lot of people find things wrong. Merging features > tends to result in lots of little problems. This doesn't mean you did > a bad job, it is just the nature of merging lots of features. > > -Ralph you are spot on especially since when I started I didn't understand half of it! I bit of perseverence should pay off. The TTFont bug is proving to be a good test case. I will also try Lukas's. best regards Keith |
In reply to this post by keith1y
Great work Keith. If the password thing gets fixed, then it sounds good.
Team work is a good thing, but Monticello has had some of these problems for quite a while with nothing done about it (afaik). At some point it's time to stop talking and start doing, with or without the team. Good job taking that step, I hope dev-image adopts your Monticello (when it's safe at least :). >From: Keith Hodges <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: [ANN] Monticllo Update >Date: Fri, 11 May 2007 13:00:07 +0100 > >Dear Edgar, > >I am sorry but you appear to have found what I think is called a minor bug, >the host string is not matching the persisted string for some reason. >Simple bugs like that can be fixed in a moment. > >This moment is nothing compared to the 70 or so hours I have invested in >the rest of the code. > >Merging code from 4 repositories, I may have missed a thing or two. >Especially when the code you are merging is modifying the tool that you are >using to perform the merge! Not to worry the working code is out there >somewhere. The PasswordManager is not my code, it comes from Andreas. As I >said it worked for me. > >Incidently, I forgot to include the atomic loading code in that last >release, and so have got my self into refactoring it and making it work >really well. > >Monticello is has some pretty cool code in it, I take my hat off to the >writers. I just think it is such a shame that it basically doesnt work as >it should. When you see it working as it should you realise what you have >been missing! > >If I am wrong then, and Monticello 1.5 ;-) doesnt cut the mustard, then the >joke is on me for a wasted week. >If I am right then Monticello 2 will have some tough competition. > >Best regards > >Keith > >>Horrible. >>Ask n times about password (That's why I remove of same in 3.10 building) >>People don't should mess with crucial packages what have fine Squeakers as >>owners. >>If some wish play his own game, fine, for me Squeak is TEAM work. >> >>Edgar, Advocatus Diaboli again >> >> >> >> >> >> > > _________________________________________________________________ Like the way Microsoft Office Outlook works? Youll love Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_outlook_0507 |
2007/5/11, J J <[hidden email]>:
> Great work Keith. If the password thing gets fixed, then it sounds good. > Team work is a good thing, but Monticello has had some of these problems for > quite a while with nothing done about it (afaik). At some point it's time > to stop talking and start doing, with or without the team. Good job taking > that step, I hope dev-image adopts your Monticello (when it's safe at least > :). I'm waiting for Keith approval :-) -- Damien Cassou |
In reply to this post by keith1y
> p.s.
> > As a bonus, I will include some class comments to explain how some > parts of monticello work. > Its a shame the maintainers whose code is so crucial to the welfare > of squeak and its users don't think it is worth documenting. If > they had then someone might have got this working properly years ago! > > IMHO: Lack of documentation is a false economy. yeap! > Keith I think that colin was paying attention to MC. Stef |
In reply to this post by Edgar J. De Cleene
Edgar J. De Cleene wrote:
> > > El 5/11/07 2:50 AM, "Keith Hodges" <[hidden email]> escribió: > > >>For a Monticello revolution check out this version in >>http://www.squeaksource.com/mc > > > > Horrible. May I kindly request that you NEVER say that again about somebodies work. Keith has put a lot of time and pride in to it. Encourage him, don't knock him down. Otherwise you'll find that you'll have fewer friends. > If some wish play his own game, fine, for me Squeak is TEAM work. Then start acting like a team member and encourage rather than insult him. Besides, anybody can contribute whatever they want. This is unpaid work. Michael. |
El 11/05/2007, a las 23:53, Michael van der Gulik escribió: > Edgar J. De Cleene wrote: >> El 5/11/07 2:50 AM, "Keith Hodges" <[hidden email]> >> escribió: >>> For a Monticello revolution check out this version in >>> http://www.squeaksource.com/mc >> Horrible. > > May I kindly request that you NEVER say that again about somebodies > work. Keith has put a lot of time and pride in to it. Encourage > him, don't knock him down. > > Otherwise you'll find that you'll have fewer friends. > >> If some wish play his own game, fine, for me Squeak is TEAM work. > > Then start acting like a team member and encourage rather than > insult him. > > Besides, anybody can contribute whatever they want. This is unpaid > work. > > Michael. > > an insult, only like his constructive criticism (I don't know if this expression in english is right) Cheers. |
In reply to this post by Michael van der Gulik
Michael van der Gulik <[hidden email]> writes:
> Edgar J. De Cleene wrote: > > El 5/11/07 2:50 AM, "Keith Hodges" <[hidden email]> > > escribió: > > > >>For a Monticello revolution check out this version in > >>http://www.squeaksource.com/mc > > Horrible. > > May I kindly request that you NEVER say that again about somebodies > work. Keith has put a lot of time and pride in to it. Encourage him, > don't knock him down. FWIW, I read it as a joke, because Edgar is obviously a respectful person based on his previous posts. Granted, it is hard to tell for sure on USENET; nobody can see whether you are smiling. Lex |
El 5/13/07 8:02 AM, "Lex Spoon" <[hidden email]> escribió: > FWIW, I read it as a joke, because Edgar is obviously a respectful > person based on his previous posts. Granted, it is hard to tell for > sure on USENET; nobody can see whether you are smiling. > > Lex Apologize myself to all. Special to Keith what is a hard worker. To show my gratitude to all what do hard work in the past and in the present , I finishing FunSqueak 3.10 , what with Klaus help go to his server today. You can have 3.10 and Fabrik, Wonderland, SqueakAmp, MorphicWrappers, MathMorphs , Musical Objects for Squeak, IRC and a couple of bad games of me what I hope don't upset people. If Steph agree, I also could put his Smalltak guide of previous Squeaks. If any have some good old project missed in this and wish I put, let me know. Edgar |
In reply to this post by keith1y
On May 11, 2007, at 14:00 , Keith Hodges wrote:
> Dear Edgar, > > I am sorry but you appear to have found what I think is called a > minor bug, the host string is not matching the persisted string for > some reason. Simple bugs like that can be fixed in a moment. The problem is that the password always has been per-repository rather than per-server-authentication-realm ... It asks you once for each repository, and if you have many of them this gets rather "annoying" (but not "horrible" -- I hope you'll forgive Edgar, me, and other non-native writers that sometimes our words do not exactly come across as we intend to). IMHO this is not a "simple" bug but rather that we need a better theory of HTTP authentication in Squeak. Anyway, I haven't had time to look at your merging, but thanks for doing this! - Bert - |
Bert,
thanks for the feedback > The problem is that the password always has been per-repository rather > than > IMHO this is not a "simple" bug but rather that we need a better > theory of HTTP authentication in Squeak. > I struggled to get Installer to work with this scheme, because installer works on a per repository-host basis. e.g. With installer you do repository := Installer monticello ftp:'ftp.myserver.ba' user: 'kph' password: 'mySecret'. repository project: 'Testing'; browse: 'SUnit-kph' It seemed quirky to have to do: repository := Installer monticello ftp:'ftp.myserver.ba' user: 'kph' repository project: 'Testing'; password: 'mySecret'; browse: 'SUnit-kph' So I changed MCPasswordManager to be on a per-repository-host basis. I figured that would be ok until someone complains. I dont see a need to have multiple squeaksource accounts, but someone might disagree with me. To be honest it is probably my hacking in this area which broke it, Edgar might have just got unlucky and picked up a version before/during the time I put this scheme in place. I also imagine that Edgar has a lot of repositories in his list, so hopefully this is fixed. best regards Keith > Anyway, I haven't had time to look at your merging, but thanks for > doing this! > > - Bert - > > > > |
Hi Keith!
First of all - great work! I haven't yet tried it, but just at the sound of your announcement this seems like quite a nice work through. And regarding team work etc - I must say I also thought Edgar's post was rude - but on the other hand, for us non-native-english speakers "shit happens" so I give him the benefit of the doubt. Now, to my real point - feels slightly odd to give feedback without even having tried your code BUT: Keith Hodges <[hidden email]> wrote: > So I changed MCPasswordManager to be on a per-repository-host basis. I > figured that would be ok until someone complains. I dont see a need to > have multiple squeaksource accounts, but someone might disagree with me. I just wonder what the above means... I use pureFtpd on my server on which I have several repositories - mostly under different ip-names like mc.gjallar.se, squeak.krampe.se etc. But they all point to the same server. And then pureFtpd offers "home directories" for its users, so if you access it with username "banana" (and pass) you can end up in a different repo than if you use username "orange". If I interpret you correctly I will not end up in trouble if I use different ip-names for these repositories, but if I don't, then it gets weird, right? Since in my setup you get to a different repo (a different directory on the server) based solely on the username. regards, Göran |
On May 15, 2007, at 8:16 , [hidden email] wrote:
> Keith Hodges <[hidden email]> wrote: >> So I changed MCPasswordManager to be on a per-repository-host >> basis. I >> figured that would be ok until someone complains. I dont see a >> need to >> have multiple squeaksource accounts, but someone might disagree >> with me. > > I just wonder what the above means... I use pureFtpd on my server on > which I have several repositories - mostly under different ip-names > like > mc.gjallar.se, squeak.krampe.se etc. But they all point to the same > server. And then pureFtpd offers "home directories" for its users, > so if > you access it with username "banana" (and pass) you can end up in a > different repo than if you use username "orange". > > If I interpret you correctly I will not end up in trouble if I use > different ip-names for these repositories, but if I don't, then it > gets > weird, right? Since in my setup you get to a different repo (a > different > directory on the server) based solely on the username. We really should look at Keith's code ;) IIRC Andreas' MCPasswordManager only worked for HTTP anyway - that's why I mentioned authentication realms ... the problem is the same though, you can have a multitude of accounts on the same HTTP server, it's just that SqueakSource does not support per-repository credentials (which is fine for SqueakSource, don't get me wrong). But other HTTP servers or FTP servers would allow this. - Bert - |
In reply to this post by Göran Krampe
>> So I changed MCPasswordManager to be on a per-repository-host basis. I >> figured that would be ok until someone complains. I dont see a need to >> have multiple squeaksource accounts, but someone might disagree with me. >> > > I just wonder what the above means... I use pureFtpd on my server on > which I have several repositories - mostly under different ip-names like > mc.gjallar.se, squeak.krampe.se etc. But they all point to the same > server. And then pureFtpd offers "home directories" for its users, so if > you access it with username "banana" (and pass) you can end up in a > different repo than if you use username "orange". > > If I interpret you correctly I will not end up in trouble if I use > different ip-names for these repositories, but if I don't, then it gets > weird, right? Since in my setup you get to a different repo (a different > directory on the server) based solely on the username. > > regards, Göran > Therefore this means that the restriction is that you cannot have multiple passwords for the same user on the same host for different repositories. For ftp I think that makes perfect sense anyway. Yes you can have different users, and even on the same host if you like. I dont think ftp would For http, I think that makes perfect sense anyway. You only have one password per user account per host. In other words its probably going to work for everyone. Keith Each file has a host password lookup table. This means that as long as you dont have two repositories with the same host that you want to access with different users you should be ok. In your case, you have one ip-name per repository, so thats fine. What would not work is if you have ftp://mc.gjallar.se/myRepo1 that you wish to access under username 'eric' with password: 'yes it works'. and ftp://mc.gjallar.se/myFiles/myRepo that you with to access under username 'eric' with password: 'no it wont'. |
In reply to this post by Bert Freudenberg
> We really should look at Keith's code ;) IIRC Andreas' > MCPasswordManager only worked for HTTP anyway - that's why I mentioned > authentication realms ... the problem is the same though, you can have a I included ftp. Keith |
Free forum by Nabble | Edit this page |