[Cuis] Cuis

> 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
>
>
>

>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 2010-02-12, at 11:17 PM, Andreas Raab wrote:
>
>> Hi Colin -
>>
>> In your newly found role as MC maintainer, I have a question for you: I am wondering about the role of errorDefinitions in MCPackageLoader. What errors are they supposed to capture? The only one I am aware of is when a variable gets moved up or down inside a package. Are there others?
>>
>> (the reason I'm asking is that I fixed this case today with help from Eliot, so we may be able to remove this unnecessary complexity)
>
>I don't think this was meant a workaround to a known problem. It's just a way to gracefully handle unexpected errors while loading a package.
>
>I'm setting up a new repository for MC1 development, where we can collect the history relevant to the current trunk version, and commit fixes and further development. I figure the best way to distribute is just to push to the trunk repository, but we'll at least have well-defined releases. Is the fix you and Eliot made available somewhere?
>
>Colin

> On 2010-02-12, at 11:17 PM, Andreas Raab wrote:
>
>> Hi Colin -
>>
>> In your newly found role as MC maintainer, I have a question for you: I am wondering about the role of errorDefinitions in MCPackageLoader. What errors are they supposed to capture? The only one I am aware of is when a variable gets moved up or down inside a package. Are there others?
>>
>> (the reason I'm asking is that I fixed this case today with help from Eliot, so we may be able to remove this unnecessary complexity)
>
> I don't think this was meant a workaround to a known problem. It's just a way to gracefully handle unexpected errors while loading a package.
>
> I'm setting up a new repository for MC1 development, where we can collect the history relevant to the current trunk version, and commit fixes and further development. I figure the best way to distribute is just to push to the trunk repository, but we'll at least have well-defined releases. Is the fix you and Eliot made available somewhere?