>> How strong is the metal? And how heavy? I mean, I guess it varies by 
>> which particular alloy you use... Presumably somebody has already 
>> tabulated this data?
> 
> Of course.

Heh. Or do you look that up from the spec sheet of the guys selling you 
the metal? ;-)

>> I imagine for a sufficiently small part, you can't physically apply 
>> enough torque to it to actually bend it. (In normal circumstances, at 
>> least.)
> 
> Why not?  What is going to limit how much torque you can apply, you just 
> get a machine with a beefier tool and press attached.

Sure. I'm thinking about when the part is in normal use. When you're 
manufacturing it, you can use all kinds of machines to apply multiple 
tonnes of force to it. But once you've bolted it to the car, somebody 
isn't going to put 20 tonnes through it with their bare hands. You'd cut 
your fingers for one.

But, if the part was larger, it might be easier to bend it with your 
bare hands. And that's kind of what I'm getting at: does the thickness 
of metal "necessary" to make a part "strong enough" for everyday use 
depend on how large the part is?

>> Hmm. And now I'm wondering... how do you manufacture the tool you use 
>> to manufacture the thing you actually wanted to make in the first 
>> place? :-D
> 
> Some guy sitting at a computerised milling machine I would imagine.
> 
> And yes, how do you make that, etc etc I think at the beginning someone 
> had to make something with their bare hands :-)

Sounds like bootstrapping a compiler.

Haskell's compiler is written in Haskell, so how do you compile it? ;-)



[I realise nobody gives a **** what the answer to that one is, but I'm 
going to tell you anyway.]

To compile GHC, first you need a working Haskell compiler. 
Realistically, a working copy of GHC itself, since the source code uses 
so many GHC-specific features. But it is guaranteed to work with 
anything newer than GHC 6.6, which is pretty old. (Apparently, the very 
first GHC was written in ML.)

Anyway, you need *something* that can compile Haskell source code. This 
is the "stage-0" compiler.

You then take the source code for GHC, compile it using the stage-0 
compiler, and the result is called "stage-1".

This compiler, however, is linked against whatever Haskell libraries 
your stage-0 compiler has. So the next thing you do is recompile all the 
Haskell standard libraries using the stage-1 compiler. (This takes 
drastically longer than compiling the compiler itself!)

You then compiler GHC all over again, using the stage-1 compiler and the 
newly compiled libraries. This produces the "stage-2" compiler, which is 
the final product.

[Optionally, as a stress test, you can recompile GHC using stage-2 
yielding a stage-3 compiler. But the only purpose of this is to check 
that stage-2 is working properly; you don't *use* stage-3 for anything.]

It should also be noted that stage-1 has a bunch of features disabled. 
Stage-2 has everything enabled, because it's the "final" compiler.

Why not just compile the libraries with stage-0, compile GHC with 
stage-0, and be done with it? Well, because libraries compiled with 
different versions of the compiler are incompatible. So a library 
compiled with stage-0 (which might be, say, GHC 6.6) won't be compatible 
with stage-1 (which would be GHC 6.10.x). That's why you have to compile 
stage-1, compile the libraries with stage-1, and then compile stage-2 
with those libraries.

Post a reply to this message