<br><br><div class="gmail_quote">On Wed, Sep 16, 2009 at 2:40 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Michael van der Gulik wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And the flamebait: which release has the fewest bugs in the Kernel-* and Collections-* categories?<br>
</blockquote>
<br></div>
The latest trunk should be pretty good. Plus, if you can get MC to work, you could just merge newer versions.<br>
<br>
BTW, are you planning to support namespaces via Monticello? If so, can I ask you to talk a little more about what you are planning? Personally, I got completely stuck with Monticello's flat representation, i.e., the issue that definitions aren't nested. Since a method definition isn't located "inside" a class definition it makes it pretty much impossible to determine the actual scope of the method definition. For a brief (VERY brief) moment I considered rewriting Monticello but I quickly got cured when looking at the actual code involved.<br>
<font color="#888888"><br></font></blockquote><div><br>I have no plans to support namespace code management via Monticello. I looked at Monticello when I was designing them and decided that I didn't like the design [of version 1.0]. <br>
</div></div><br>I'll briefly describe what I'm planning below. I haven't started work on this yet; Namespaces are currently usable but urgently need major refactoring and then bug-fixing.<br><br>Documentation lives on <a href="http://gulik.pbwiki.com/Namespaces">http://gulik.pbwiki.com/Namespaces</a>. Let me know if anything there is hard to understand and I'll fill it in more.<br>
<br>The core of Namespaces will be the following classes:<br><br>Package - subclass of Namespace, forms the root of a namespace hierarchy.<br>Namespace - subclass of Dictionary mapping #Symbols to other Namespaces, Classes and global variables.<br>
Class - like it is now, sans source code but including intermediate-representation of code from compiler as well.<br>CompiledMethod - like it is now, sans source code, with closures, literals are strictly read-only.<br clear="all">
<br>and other classes to hold the intermediate representation of code, read-only literals, documentation, meta-class stuff, etc.<br><br>The intermediate-representation of code will be generated from the NewCompiler* with the IR (intermediate-representation) classes borrowed from there (from memory, I think they were called "IR classes", I forget). When packages are moved between images, the IR will be serialized and deserialized in binary form rather than using bytecodes because it is much easier to verify that IR is secure than bytecodes. Doing it this way also has some other benefits, such as letting the receiving VM have a completely different bytecode set.<br>
<br>The source code management will be external to the above. Any source code management system can be used as long as it generates a valid Package object structure. The source code tools will need to hold their own mirror objects of the structure of a package and its source. I'll be making a simple set of tools based on what I already have, and I hope that at some stage in the future, other people can make better tools.<br>
<br>(*) the NewCompiler would be an external source code management tool. It would be completely optional.<br><br>Gulik.<br><br>-- <br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a><br>