On Sun, Jan 24, 2010 at 10:59 AM, keith <keith_hodges at yahoo.co.uk> wrote:

>
> Honestly, what kind of automation you can invent here to migrate your
> application from using package version A,
> to package version B , which potentially, can be completely rewritten
> from scratch?
> You doomed to either stay with version A, or do a lot of manual work
> migrating to version B and no magic tool will help you with that.
>
>
> No automation at all is needed.
>
> About cross-fork package development.
>
> Each package having an environment-agnostic behavior , and environment
> dependent.
> The goal of developer is to identify these parts and connect them nicely.
> But this is gone too far. It is now about defining and enforcing a
> good practices in package development to avoid cross-dialect pitfalls.
> How many packages we has built with cross-compatibility in mind?
> How many packages having all globals declared in a single place, not
> scattered among code?
> And what automated tools can solve the problems, when your package
> code using 'SmalltalkImage current' instead of 'Smalltalk'?
>
>
> Again no automated tools.
>
> I think you are getting hung up on the automated tools thing. Automation is
> nothing to do with this discussion.
>
> I am not asking you or anyone to automate tools or anything.
>
> 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:
>
> Example:
>
> 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.
>

I did that already.  See
http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/README.txt from
http://www.mirandabanda.org/cogblog/downloads/.  There are two problems with
this.

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  Croquet 1.0& Squeak 3.9 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.

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

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.

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.

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.

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.

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.

So why don't you have a go?



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

Bollocks.


>
> that is the difference, and my example from the bazaar documentation
> clearly shows the difference
>
> Keith
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100124/11f0cde1/attachment.htm