[Cuis] Cuis
Locked
1 ...
56789
1 ...
56789
Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal
 
|
keith wrote:
> MC1.5 has quite a few users out there, anyone who uses LPF, which > included Randal for a start. > > I would expect MC1.5 to be stable enough, this is the one with the > atomic loading preference turned OFF. > > The email you reference above is referring to MC1.6 (MCPackageLoader2) > this is the experimental, atomic loading loader, which everyone knows > isn't finished, no one ever claimed it was stable. We only ever claimed > it would be really worth finishing and I had been asking for help with > for more than 18 months, because it is not my area of expertise at all, > and Matthew had got stuck afaik. > > So the point being, if you test the wrong thing, you wont get the > results you hoped for. I tested what I what I was told by the best authority at hand. How does one load and test the "right" thing? Cheers, - Andreas |
|
|
On 27 Jan 2010, at 07:24, Andreas Raab wrote: > keith wrote: >> MC1.5 has quite a few users out there, anyone who uses LPF, which >> included Randal for a start. >> I would expect MC1.5 to be stable enough, this is the one with the >> atomic loading preference turned OFF. >> The email you reference above is referring to MC1.6 >> (MCPackageLoader2) this is the experimental, atomic loading loader, >> which everyone knows isn't finished, no one ever claimed it was >> stable. We only ever claimed it would be really worth finishing and >> I had been asking for help with for more than 18 months, because it >> is not my area of expertise at all, and Matthew had got stuck afaik. >> So the point being, if you test the wrong thing, you wont get the >> results you hoped for. > > I tested what I what I was told by the best authority at hand. How > does one load and test the "right" thing? > > Cheers, > - Andreas It sounds like you loaded the right thing. You just need to turn the "useAtomicLoading" preference off, this uses MCPackageLoader1b, the non atomic loading code. Keith |
Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal
|
|
keith wrote:
> It sounds like you loaded the right thing. You just need to turn the > "useAtomicLoading" preference off, this uses MCPackageLoader1b, the non > atomic loading code. So I tried this too and it doesn't get very far either (same process described earlier). It fails very early on when it's trying to load a variant of ProgressInitiationException>>defaultMorphicAction. The failure originates from MCMethodDefinition>>preloadOver: which actually *removes* the selector that is being changed. This is a fatal flaw since removing a method that's about to be modified can't possibly work when it comes to any system critical methods (compiler etc. comes to mind but even the progress display is enought to blow up). This version won't be able to deal with many, many changes that went into the trunk. Cheers, - Andreas |
Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal
|
|
At 11:16 PM -0800 1/27/10, Andreas Raab apparently wrote:
>keith wrote: >>It sounds like you loaded the right thing. You just need to turn the "useAtomicLoading" preference off, this uses MCPackageLoader1b, the non atomic loading code. > >So I tried this too and it doesn't get very far either (same process described earlier). It fails very early on when it's trying to load a variant of ProgressInitiationException>>defaultMorphicAction. The failure originates from MCMethodDefinition>>preloadOver: which actually *removes* the selector that is being changed. > >This is a fatal flaw since removing a method that's about to be modified can't possibly work when it comes to any system critical methods (compiler etc. comes to mind but even the progress display is enought to blow up). This version won't be able to deal with many, many changes that went into the trunk. > >Cheers, > - Andreas Andreas, I am finding it somewhat odd that you seem to be willing to hack your ancient trunk fork of MC any which way, but with the big potential wins of the MC1.5/1.6 versions, I'm thinking someone like yourself with the necessary detailed system knowledge, might be able to apply some appropriate fixes to bring MC into a better working state. Even if it might be an interim solution, it seems to me there could be some real gains. How far away from stable working versions can MC1.5/1.6 be? Both Matthew and Keith have used MC 1.5 and 1.6 fairly extensively, but perhaps not exactly for the types of things you have been doing. Maybe I don't fully appreciate the efforts required, but to my mind if the ancient version is able to do what you need, the newer versions must be close too. As Keith recently mentioned: >>At 10:00 PM +0000 1/26/10, keith apparently wrote: >>> >>>All efforts to change this, to move obvious loadable libraries like SUnit, and MC out to be externally managed, have up to now failed. The weakness of my attempts so far has been in the testing side of things. (Matthew Fulmer is worth is weight in gold on that one) >>> >>> >>>However Monticello is a complicated beast, I may have made 400 more commits, merging 3 forks, but one or two bugs is all it takes to reject the entire refactoring of the repositories code, the improved more uniform ui implementation, the password manager, the dual change sorter, the orphanage for out of order loading, public package info properties for package managers, scripting of commits, memory analysis per package, the atomic loader, cleanUp code, improved version numbering, integrated Configurations, separated tests, default packageinfo package types etc etc etc. >>> >> >>Those are package specific problems. I suggest getting in touch with Monticello developers to merge your changes. >> > >Matthew and I were the monticello maintainers for 3 years, after there had been none for at least a year. That was the whole point of setting up a shared repository squeaksource.com/mc so that Monticello could be maintained and worked on by anyone that knew how. > >Most of us work with the latest of established packages on a day to day basis. Yet for some reason, both Pharo and "trunk" adopted the ancient version. There are no more bugs in the new version, the exisiting bugs are just in slightly different places. The new version passes lukas' "difficult test case", whereas the old one doesn't. > >Keith Ken G. Brown |
|
|
In reply to this post by Andreas.Raab
On 28 Jan 2010, at 07:16, Andreas Raab wrote: > keith wrote: >> It sounds like you loaded the right thing. You just need to turn >> the "useAtomicLoading" preference off, this uses MCPackageLoader1b, >> the non atomic loading code. > > So I tried this too and it doesn't get very far either (same process > described earlier). It fails very early on when it's trying to load > a variant of ProgressInitiationException>>defaultMorphicAction. The > failure originates from MCMethodDefinition>>preloadOver: which > actually *removes* the selector that is being changed. > > This is a fatal flaw since removing a method that's about to be > modified can't possibly work when it comes to any system critical > methods (compiler etc. comes to mind but even the progress display > is enought to blow up). This version won't be able to deal with > many, many changes that went into the trunk. > > Cheers, > - Andreas Sigh, Like I said, different bugs in different places. The 1b loader tries to pre-empt problems, whereas the original loader just waits for the problems to occur, and catches the exceptions. It turns out that the 1b approach is a lot harder. If I recall, and my memory is failing, methods are removed, in order to accomodate lukas' difficult load scenario, where the change in the instance vars breaks things. We did think of returning to the old loader approach at one point, but figured it would be better to get AtomicLoading to work. So now we are caught in the middle. Keith |
Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal
|
|
On Thu, Jan 28, 2010 at 12:25 PM, keith <[hidden email]> wrote:
What is this scenario? Does it break the following load ordering?
- add all new inst and class vars to existing classes (avoiding deleting any that need to be deleted until later) - add all new classes - add all new methods - change all to be changed methods
- delete all to be deleted methods - remove all inst and class vars from existing classes (deferred from step 1)
|
|
|
> What is this scenario? Does it break the following load ordering? > > - add all new inst and class vars to existing classes (avoiding > deleting any that need to be deleted until later) > - add all new classes The original innovation of the 1b Loader was to begin by defining classes using a union of the old and new instVars list , in an attempt to keep as much working as possible. So yes that implements your suggestion above. The old loader would just load the new class definition, and if that compilation failed, try again later in the hope that any failing methods were removed in the remove method step. > - add all new methods > - change all to be changed methods > - delete all to be deleted methods > - remove all inst and class vars from existing classes (deferred > from step 1) So basically your scheme is what the 1b loader is originally was designed to do. However it looks like an extra "remove method" step has crept in at some later point in time, probably to fix one of the other conflicting bug scenarios, and this is what is causing the problem. What would have been most useful, (and I didn't know how to achieve this) would be a simple hook to enable new method to be compiled against the fictional not yet installed future class definition, but then installed in the old class, just before committing the new class definition. This would not be full atomic loading, but it would yield a much less quirky standard loader. Keith |
Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal
|
|
On Thu, Jan 28, 2010 at 5:42 PM, keith <[hidden email]> wrote:
That's broken. It should compute the correct definition and not catch compilation errors. A loader that hopes is hopeless ;)
I know it's painful but good tests here are hugely valuable (albeit rather tedious to write).
I don't think so. What is useful is a well-defined readable implementation of the above load order. Bells and whistles and convoluted code are what's _not_ needed.
|
Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal
|
|
On 29 January 2010 19:05, Eliot Miranda <[hidden email]> wrote:
> > > On Thu, Jan 28, 2010 at 5:42 PM, keith <[hidden email]> wrote: >> >>> What is this scenario? Does it break the following load ordering? >>> >>> - add all new inst and class vars to existing classes (avoiding deleting >>> any that need to be deleted until later) >>> - add all new classes >> >> The original innovation of the 1b Loader was to begin by defining classes >> using a union of the old and new instVars list , in an attempt to keep as >> much working as possible. So yes that implements your suggestion above. >> >> The old loader would just load the new class definition, and if that >> compilation failed, try again later in the hope that any failing methods >> were removed in the remove method step. > > That's broken. It should compute the correct definition and not catch > compilation errors. A loader that hopes is hopeless ;) > >> >>> - add all new methods >>> - change all to be changed methods >>> - delete all to be deleted methods >>> - remove all inst and class vars from existing classes (deferred from >>> step 1) >> >> So basically your scheme is what the 1b loader is originally was designed >> to do. >> >> However it looks like an extra "remove method" step has crept in at some >> later point in time, probably to fix one of the other conflicting bug >> scenarios, and this is what is causing the problem. > > I know it's painful but good tests here are hugely valuable (albeit rather > tedious to write). > >> >> What would have been most useful, (and I didn't know how to achieve this) >> would be a simple hook to enable new method to be compiled against the >> fictional not yet installed future class definition, but then installed in >> the old class, just before committing the new class definition. This would >> not be full atomic loading, but it would yield a much less quirky standard >> loader. > > I don't think so. What is useful is a well-defined readable implementation > of the above load order. Bells and whistles and convoluted code are what's > _not_ needed. +1. The loading logic should be clearly defined and straightforward. >> >> Keith >> > > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal
|
|
Igor Stasenko wrote:
>> I don't think so. What is useful is a well-defined readable implementation >> of the above load order. Bells and whistles and convoluted code are what's >> _not_ needed. > > +1. > > The loading logic should be clearly defined and straightforward. And commented. I must be the only person in the world who thinks that this loading stuff isn't trivial and deserves a bit of an outline as to what exactly happens in which order and why. Cheers, - Andreas |
Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal
|
|
In reply to this post by keith1y
On Fri, Jan 29, 2010 at 2:42 AM, keith <[hidden email]> wrote:
Doesn't the FileContentsBrowser do this using PseudoClass etc? Comment says: I use PseudoClass, PseudoClassOrganizers, and PseudoMetaclass to model the class structure of the source file. Karl |
|
|
In reply to this post by Eliot Miranda-2
Totally agree, unfortunately I didn't understand the tests at the time. Keith |
MC 1.5/1.6 (Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal)
|
|
In reply to this post by Ken G. Brown
Hi Ken -
Ken G. Brown wrote: > I am finding it somewhat odd that you seem to be willing to hack your ancient trunk fork of MC any which way, but with the big potential wins of the MC1.5/1.6 versions, I'm thinking someone like yourself with the necessary detailed system knowledge, might be able to apply some appropriate fixes to bring MC into a better working state. Even if it might be an interim solution, it seems to me there could be some real gains. I think you're misunderstanding my relationship with MC. I don't particularly like MC, I find the code base very hard to understand and very difficult to follow due to the complete lack of any comments. Self-documenting code my a** as one of my colleagues here would say. The amount of MC that I have mastered is *just* the package loader and only because I had to in order to fix various broken operations. In the process of mastering it I've added comments to explain what I think happens but from some of the discussion it is obvious that I'm still missing various subtleties. Looking at MC 1.5 I found nothing but more undocumented changes. The practical problem I've encountered makes no sense whatsoever to me (removing a changed method prior to compiling the new version cannot possibly work) but it's actually *different* from the prior version and there is no context to judge *why* it's different. So if you're asking me why I'm not fixing Monticello one part of the answer is: I don't like MC, and unless I absolutely have to I'll stay away from it. However, just as importantly, when we change a critical piece of the infrastructure I'm also looking for who will be providing support for any issues that come up. If something goes wrong in one of these areas, we need help and that help needs to come from the people who wrote that code. A great example in this regard were the recent changes to both CompiledMethodTrailer (Igor) and the >32MB changes file (David). Both of these had issues come up that could have been the result of the changes they did. In both cases, Igor and David were *happy* to help and to dig into the details to make sure people get over these significant changes in the system. They didn't ask the users to fix the problem, they said "thanks for reporting the issue, could you try this or that, and here's the fix". That's the reaction I'm looking for when someone wants to push changes to the core system. I'm *not* looking for them telling their testers to go fix it yourself (neither am I looking fpr people dumping their unfinished projects into my lap). That's the wrong attitude. So if you want to get a newer version of MC into the trunk, the process is this: a) Fix the issues that have been reported so far b) Run the experiment described in http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-October/140345.html to ensure you can load everything in the trunk c) Report your success here At the point where you've successfully re-run the updates in the trunk to ensure that your version of MC can deal with everything currently in use we're in a situation where a switch to MC 1.5 / 1.6 is a win-win situation. Obviously, you don't have to do this all by yourself; if you can find help from people that works just as well. And if you add a few comments explaining what precisely the loader does and why that order and these operations are necessary, I might even give it a second look myself. Cheers, - Andreas |
Re: MC 1.5/1.6 (Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal)
|
|
Andreas, i read about your concerns about MC and i feel like MC
currently is abandonware, since its not maintained by anyone, yet it is de-facto standard tool for sharing the code in squeak universe. This situation is really bad and we need to change it. Also, i am strongly thinking that MC should be maintained as separate entity, because it is crucial for developers to have a tools which can be used to share the code among forks and therefore this tool should behave equally everywhere. On 2 February 2010 08:25, Andreas Raab <[hidden email]> wrote: > Hi Ken - > > Ken G. Brown wrote: >> >> I am finding it somewhat odd that you seem to be willing to hack your >> ancient trunk fork of MC any which way, but with the big potential wins of >> the MC1.5/1.6 versions, I'm thinking someone like yourself with the >> necessary detailed system knowledge, might be able to apply some appropriate >> fixes to bring MC into a better working state. Even if it might be an >> interim solution, it seems to me there could be some real gains. > > I think you're misunderstanding my relationship with MC. I don't > particularly like MC, I find the code base very hard to understand and very > difficult to follow due to the complete lack of any comments. > Self-documenting code my a** as one of my colleagues here would say. > > The amount of MC that I have mastered is *just* the package loader and only > because I had to in order to fix various broken operations. In the process > of mastering it I've added comments to explain what I think happens but from > some of the discussion it is obvious that I'm still missing various > subtleties. > > Looking at MC 1.5 I found nothing but more undocumented changes. The > practical problem I've encountered makes no sense whatsoever to me (removing > a changed method prior to compiling the new version cannot possibly work) > but it's actually *different* from the prior version and there is no context > to judge *why* it's different. > > So if you're asking me why I'm not fixing Monticello one part of the answer > is: I don't like MC, and unless I absolutely have to I'll stay away from it. > > However, just as importantly, when we change a critical piece of the > infrastructure I'm also looking for who will be providing support for any > issues that come up. If something goes wrong in one of these areas, we need > help and that help needs to come from the people who wrote that code. A > great example in this regard were the recent changes to both > CompiledMethodTrailer (Igor) and the >32MB changes file (David). > > Both of these had issues come up that could have been the result of the > changes they did. In both cases, Igor and David were *happy* to help and to > dig into the details to make sure people get over these significant changes > in the system. They didn't ask the users to fix the problem, they said > "thanks for reporting the issue, could you try this or that, and here's the > fix". > > That's the reaction I'm looking for when someone wants to push changes to > the core system. I'm *not* looking for them telling their testers to go fix > it yourself (neither am I looking fpr people dumping their unfinished > projects into my lap). That's the wrong attitude. > > So if you want to get a newer version of MC into the trunk, the process is > this: > a) Fix the issues that have been reported so far > b) Run the experiment described in > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-October/140345.html > to ensure you can load everything in the trunk > c) Report your success here > > At the point where you've successfully re-run the updates in the trunk to > ensure that your version of MC can deal with everything currently in use > we're in a situation where a switch to MC 1.5 / 1.6 is a win-win situation. > > Obviously, you don't have to do this all by yourself; if you can find help > from people that works just as well. And if you add a few comments > explaining what precisely the loader does and why that order and these > operations are necessary, I might even give it a second look myself. > > Cheers, > - Andreas > > > -- Best regards, Igor Stasenko AKA sig. |
Re: MC 1.5/1.6 (Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal)
|
|
Igor Stasenko wrote:
> Andreas, i read about your concerns about MC and i feel like MC > currently is abandonware, > since its not maintained by anyone, yet it is de-facto standard tool > for sharing the code in squeak universe. > This situation is really bad and we need to change it. So what are you proposing to change it? Cheers, - Andreas > Also, i am strongly thinking that MC should be maintained as separate > entity, because it is crucial for developers to > have a tools which can be used to share the code among forks and > therefore this tool should behave equally everywhere. > > On 2 February 2010 08:25, Andreas Raab <[hidden email]> wrote: >> Hi Ken - >> >> Ken G. Brown wrote: >>> I am finding it somewhat odd that you seem to be willing to hack your >>> ancient trunk fork of MC any which way, but with the big potential wins of >>> the MC1.5/1.6 versions, I'm thinking someone like yourself with the >>> necessary detailed system knowledge, might be able to apply some appropriate >>> fixes to bring MC into a better working state. Even if it might be an >>> interim solution, it seems to me there could be some real gains. >> I think you're misunderstanding my relationship with MC. I don't >> particularly like MC, I find the code base very hard to understand and very >> difficult to follow due to the complete lack of any comments. >> Self-documenting code my a** as one of my colleagues here would say. >> >> The amount of MC that I have mastered is *just* the package loader and only >> because I had to in order to fix various broken operations. In the process >> of mastering it I've added comments to explain what I think happens but from >> some of the discussion it is obvious that I'm still missing various >> subtleties. >> >> Looking at MC 1.5 I found nothing but more undocumented changes. The >> practical problem I've encountered makes no sense whatsoever to me (removing >> a changed method prior to compiling the new version cannot possibly work) >> but it's actually *different* from the prior version and there is no context >> to judge *why* it's different. >> >> So if you're asking me why I'm not fixing Monticello one part of the answer >> is: I don't like MC, and unless I absolutely have to I'll stay away from it. >> >> However, just as importantly, when we change a critical piece of the >> infrastructure I'm also looking for who will be providing support for any >> issues that come up. If something goes wrong in one of these areas, we need >> help and that help needs to come from the people who wrote that code. A >> great example in this regard were the recent changes to both >> CompiledMethodTrailer (Igor) and the >32MB changes file (David). >> >> Both of these had issues come up that could have been the result of the >> changes they did. In both cases, Igor and David were *happy* to help and to >> dig into the details to make sure people get over these significant changes >> in the system. They didn't ask the users to fix the problem, they said >> "thanks for reporting the issue, could you try this or that, and here's the >> fix". >> >> That's the reaction I'm looking for when someone wants to push changes to >> the core system. I'm *not* looking for them telling their testers to go fix >> it yourself (neither am I looking fpr people dumping their unfinished >> projects into my lap). That's the wrong attitude. >> >> So if you want to get a newer version of MC into the trunk, the process is >> this: >> a) Fix the issues that have been reported so far >> b) Run the experiment described in >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-October/140345.html >> to ensure you can load everything in the trunk >> c) Report your success here >> >> At the point where you've successfully re-run the updates in the trunk to >> ensure that your version of MC can deal with everything currently in use >> we're in a situation where a switch to MC 1.5 / 1.6 is a win-win situation. >> >> Obviously, you don't have to do this all by yourself; if you can find help >> from people that works just as well. And if you add a few comments >> explaining what precisely the loader does and why that order and these >> operations are necessary, I might even give it a second look myself. >> >> Cheers, >> - Andreas >> >> >> > > > |
Re: MC 1.5/1.6 (Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal)
|
|
On 2 February 2010 10:23, Andreas Raab <[hidden email]> wrote:
> Igor Stasenko wrote: >> >> Andreas, i read about your concerns about MC and i feel like MC >> currently is abandonware, >> since its not maintained by anyone, yet it is de-facto standard tool >> for sharing the code in squeak universe. >> This situation is really bad and we need to change it. > > So what are you proposing to change it? > I thought that i already said that: we need a maintainable separate MC repository. If you remember, i raised this topic before, still no people found, who would take care of that. > Cheers, > - Andreas -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Andreas.Raab
Ok, well comments like this must mean why my hindbrain is looking at Ginsu again.
On 2010-02-01, at 10:25 PM, Andreas Raab wrote: > Hi Ken - > > Ken G. Brown wrote: >> I am finding it somewhat odd that you seem to be willing to hack your ancient trunk fork of MC any which way, but with the big potential wins of the MC1.5/1.6 versions, I'm thinking someone like yourself with the necessary detailed system knowledge, might be able to apply some appropriate fixes to bring MC into a better working state. Even if it might be an interim solution, it seems to me there could be some real gains. > > I think you're misunderstanding my relationship with MC. I don't particularly like MC, I find the code base very hard to understand and very difficult to follow due to the complete lack of any comments. Self-documenting code my a** as one of my colleagues here would say. -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
|
|
In reply to this post by Igor Stasenko
On 2010-02-01, at 11:56 PM, Igor Stasenko wrote: > Andreas, i read about your concerns about MC and i feel like MC > currently is abandonware, > since its not maintained by anyone, yet it is de-facto standard tool > for sharing the code in squeak universe. > This situation is really bad and we need to change it. Ok, I volunteer. Igor's right - it's obvious that MC needs an active maintainer. I've been reluctant to step into this role because I'd rather devote my Squeaking time to MC2. So this will delay the release of MC 2.1, but may make the migration path smoother. I'll post more once I've had a chance to look at the state of the art and figure out a road map. Colin |
|
|
On 02.02.2010, at 20:19, Colin Putney wrote:
> > > On 2010-02-01, at 11:56 PM, Igor Stasenko wrote: > >> Andreas, i read about your concerns about MC and i feel like MC >> currently is abandonware, >> since its not maintained by anyone, yet it is de-facto standard tool >> for sharing the code in squeak universe. >> This situation is really bad and we need to change it. > > Ok, I volunteer. > > Igor's right - it's obvious that MC needs an active maintainer. I've been reluctant to step into this role because I'd rather devote my Squeaking time to MC2. So this will delay the release of MC 2.1, but may make the migration path smoother. I'll post more once I've had a chance to look at the state of the art and figure out a road map. > > Colin Yay! I don't really have time to work on it, but having written my share of MC code, if you want to discuss anything you're welcome :) I actually found MC quite understandable, even without many comments ... - Bert - |
|
|
Bert Freudenberg wrote:
> On 02.02.2010, at 20:19, Colin Putney wrote: >> >> On 2010-02-01, at 11:56 PM, Igor Stasenko wrote: >> >>> Andreas, i read about your concerns about MC and i feel like MC >>> currently is abandonware, >>> since its not maintained by anyone, yet it is de-facto standard tool >>> for sharing the code in squeak universe. >>> This situation is really bad and we need to change it. >> Ok, I volunteer. >> >> Igor's right - it's obvious that MC needs an active maintainer. I've been reluctant to step into this role because I'd rather devote my Squeaking time to MC2. So this will delay the release of MC 2.1, but may make the migration path smoother. I'll post more once I've had a chance to look at the state of the art and figure out a road map. >> >> Colin > > Yay! Indeed! > I don't really have time to work on it, but having written my share of MC code, if you want to discuss anything you're welcome :) I actually found MC quite understandable, even without many comments ... That's because you're smarter than me :-) But I'll use that opportunity to learn more about MC and help writing meaningful comments. Cheers, - Andreas |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |