<div class="gmail_quote">On Sun, Jan 24, 2010 at 10:59 AM, keith <span dir="ltr"><<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="im"><br><blockquote type="cite"><div>Honestly, what kind of automation you can invent here to migrate your<br>application from using package version A,<br>to package version B , which potentially, can be completely rewritten<br>
from scratch?<br>You doomed to either stay with version A, or do a lot of manual work<br>migrating to version B and no magic tool will help you with that.<font color="#000000"><font color="#144FAE"><br></font></font></div>
</blockquote><div><br></div></div><div>No automation at all is needed.</div><div class="im"><br><blockquote type="cite"><div>About cross-fork package development.<br><br>Each package having an environment-agnostic behavior , and environment<br>
dependent.<br>The goal of developer is to identify these parts and connect them nicely.<br>But this is gone too far. It is now about defining and enforcing a<br>good practices in package development to avoid cross-dialect pitfalls.<br>
How many packages we has built with cross-compatibility in mind?<br>How many packages having all globals declared in a single place, not<br>scattered among code?<br>And what automated tools can solve the problems, when your package<br>
code using 'SmalltalkImage current' instead of 'Smalltalk'?<font color="#000000"><font color="#144FAE"><br></font></font></div></blockquote><div><br></div></div><div>Again no automated tools.</div><div><br>
</div><div>I think you are getting hung up on the automated tools thing. Automation is nothing to do with this discussion.</div><div><br></div><div>I am not asking you or anyone to automate tools or anything.</div><div><br>
</div><div>I am asking you to use a process of thinking that documents what you do, in a way that enables it to be routinely harvestable. Its a process of knowledge capture. You can write it on paper if you like:</div><div>
<br></div><div>Example:</div><div><br></div><div>If you write me an explanation of how to install closures, it will be a lot easier to write if you say.... Start with a 3.10-release image. Do a,b,c,d,e and you will have a closures image, we shall call 3.10-closures.</div>
</div></div></blockquote><div><br></div><div>I did that already. See <a href="http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/README.txt">http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/README.txt</a> from <a href="http://www.mirandabanda.org/cogblog/downloads/">http://www.mirandabanda.org/cogblog/downloads/</a>. There are two problems with this.</div>
<div><br></div><div>1. the closure bootstrap is tricky (ask Juan). The closure bootstrap has to replace the compiler in just the right order so that the old compiler keeps working until the new compiler is ready to take over. Turns out that this is very sensitive on what you start from. The ocmpiler in 37 is different form that in 3.8 and 3.9. The compiler in a Croquet mage is different. Things are different if FFI is loaded, if Vassili's variadic ifNotNil: code is in or not, if pragmas are in or not. I provided two different bootstraps <span class="Apple-style-span" style="font-family: monospace; font-size: medium; white-space: pre-wrap; "> Croquet 1.0& Squeak 3.9<span class="Apple-style-span" style="font-family: arial; white-space: normal; font-size: small; "> and did a third one in-house at Teleplace. I don't have the time to do a generic one and in fact I don't think it's practicable.</span></span></div>
<div><br></div><div>2. the closure code has evolved since the bootstrap. People found bugs and provided tests and I changed the closure analysis to compile inlined blocks (to:by:do: whileTrue: et al) correctly, and fixed debugger bugs, and provided support for closurised compressed temp names. Then Igor reimplemented the compressed temp names/surce pointer scheme to mase it much better and much more general. I discovered Colin Putney had done a really nice compiler error formaework that wasn't in the original. Now two things follow</div>
<div><br></div><div>a) it is simply way too expensive to go back and revamp those two bootstraps so that they end up at the new bugfixed improved code.</div><div><br></div><div>b) it is pointless; Pharo, Cuis and Squeak trunk have all moved on from their pre-closure starting point. What they need is incremental bug fixes installing in their current state. </div>
<div><br></div><div>So what are the instructions to install closures now? As I'm planning to do this for Etoys sometime soon this is not hypothetical. The basic approach is to compare the starting point with the desired end-point packages (choose Compiler & Kernel-Methods and sundry associated extensions, being familiar with the compiler will make this easier, but its tediously error-prone). Then produce a set of file-ins that gets from the starting-point to as close to the end-pont ass results in a functioning compiler and Monticello. Load the relevant packages and you're done.</div>
<div><br></div><div>And the way I do that is that I file-in until something breaks (as it will, an MNU in the compiler will typically break the debugger because the debugger uses the compiler to create the source map for a method). When something breaks (usually the system locks up with an infinite recursion) I kill it, restart and use recently logged changes to find out what was the last method that I brought in that broke things and then I try and figure out why. SqueakDebug.log probably didn't get the error written to it because the crash was so deep-seated, so some head scratching is required. Then rinse and repeat. Eventually one has closures filed-in.</div>
<div><br></div><div>So - it isn't automatable, it isn't trivial and it isn't very hard; just tedious. Trying to do this will teach you much about the core of the system. People have worked out how to do this without asking me a single question, working out the above process themselves because its obvious. Ask Juan.</div>
<div><br></div><div>So why don't you have a go?</div><div><br></div><div><span class="Apple-style-span" style="font-family: monospace; font-size: medium; white-space: pre-wrap; "><span class="Apple-style-span" style="font-family: arial; white-space: normal; font-size: small; "> </span></span></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><br></div><div>As a trunk developer you cant write me this explanation. If you write me an explanation of how to install closures following trunk, it will be... Hmm when we did it we had this image that was hacked on by 10 people, so this is how I did a,b,c,d,e but I cant be sure that this will work for you. </div>
</div></div></blockquote><div><br></div><div>Bollocks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div><br>
</div><div>that is the difference, and my example from the bazaar documentation clearly shows the difference</div><div><br></div><font color="#888888"><div>Keith</div><div><br></div></font></div></div><br><br>
<br></blockquote></div><br>