Hi,

> Maybe i'm not right - it is always easier to manage a small group of
> contributors which never asking anyone's opinion how to do things, and
> in result they deliver things like Morphic and Etoys (sorry :) which
> nearly impossible to decouple from the rest of system, because
> obviously no one thought about things like running squeak w/o Morphic
> before.

I think it show that they can´t doit in other way, and it is good to
 work the best way for the "author/worker".
The problem is what is missing that make people think
 they can´t decouple (anyPartOfTheSystem) by themselves.
imho it reveals a failure in education efforts -download aFish
 instead of try fishing- and is a problem of this times (too easy/fast
 to fileIn and doIt).

A compiler framework is described as something we want,
 but we need more than two instances/compilers to start to
 think we have a framework (it can´t be invented).
A way to make a framework emerge is to have more than
 one person/group working on alternatives and provide a set
 of open topDown requirements in form of tutorials/exemplars
 of use of Smalltalk compilation solutions.
A swiki page with guides on how people want to
 use aNewSmalltalkCompiler may be used to guide people
 interested in write a concrete support.

best,
Ale.


----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Monday, September 01, 2008 6:08 PM
Subject: Re: [squeak-dev] Re: Making a better Compiler for all


> 2008/9/1 Eliot Miranda <eliot.miranda at gmail.com>:
>> Please have a look at my closure compiler.  This puts bytecode generation
>> into a separate class (a subclass of Encoder).
>
> This is one of the things we really need to be decoupled.
>
>> You can find the code on the download page of my blog.
>> Marcus Denker and I are in agreement that we will merge my Closure 
>> compiler
>> into Markus' NewCompiler "some time soon".
>> The thought of a committee fills me with horror :)  I don't think we need
>> anything so baroque :)
>
> Well, i only hope, that you will not need to say to people words like:
> 'this stuff not working because you need my compiler to use it'.
> Or words like: 'this stuff works only in mine fork'.
> Maybe it is not hurts someone losing a potential contributors and
> splitting community over and over. But i think having something in
> common, like compiler is for best of all.
> Maybe i'm not right - it is always easier to manage a small group of
> contributors which never asking anyone's opinion how to do things, and
> in result they deliver things like Morphic and Etoys (sorry :) which
> nearly impossible to decouple from the rest of system, because
> obviously no one thought about things like running squeak w/o Morphic
> before.
>
> And me, as a Squeak board member, as well as others were elected on
> the wave of making Squeak having better modularity. The lack of
> modularity in Squeak is one of the bigger issues in system, which
> prevents it to be easily managed and adopted for different solutions.
> One of the critical steps towards modularity is to make better,
> modular compiler. Of course, we can wait a little and start using
> NewSpeak, so there is nothing to do or worry about, isnt? ;)
>
>> Best
>> Eliot
>>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
>