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

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

Well there are standard steel and aluminium alloys that have well documented 
properties, when a supplier sells you one of these types you know what you 
are getting, and if it's not within the official standard then you can get 
your money back etc.

> Sure. I'm thinking about when the part is in normal use.

Ah I see, you mean if a part is designed to have some force applied during 
normal use, like a door handle or a key or something.  Well yes, obviously 
then you figure out what is the maximum force likely to be applied during 
normal use and simulate/test that it will not break under that load.

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

But who wrote the stage 0 compiler?  Was it written in machine code?

Post a reply to this message

>> Heh. Or do you look that up from the spec sheet of the guys selling 
>> you the metal? ;-)
> 
> Well there are standard steel and aluminium alloys that have well 
> documented properties, when a supplier sells you one of these types you 
> know what you are getting, and if it's not within the official standard 
> then you can get your money back etc.

Ah, I see.

>> Sure. I'm thinking about when the part is in normal use.
> 
> Ah I see, you mean if a part is designed to have some force applied 
> during normal use, like a door handle or a key or something.  Well yes, 
> obviously then you figure out what is the maximum force likely to be 
> applied during normal use and simulate/test that it will not break under 
> that load.

If you're making something like an LCD mounting bracket, do you actually 
do a detailed simulation for that component? Or do you just do "OK, well 
we're using 0.3 mm steel for the rest of the frame, so let's use 0.3 mm 
steel"? (And change it if it turns out to be too weak...)

>> Anyway, you need *something* that can compile Haskell source code. 
>> This is the "stage-0" compiler.
> 
> But who wrote the stage 0 compiler?  Was it written in machine code?

As I say, the "original" GHC was written in ML. (I have no idea what the 
ML interpretter was written in...) These days, the stage-0 compiler will 
just be an older version of GHC which is already compiled.

The fun thing is if you want to ran GHC on an unsupported platform. This 
apparently involves asking GHC to compile itself into ANSI C, and then 
using a suitable C compiler for the target platform to produce a working 
binary. Apparently some nutter used this to get GHC to work on a mobile 
phone powered by an ARM CPU or something random like that...

Aside from GHC, there are a few other Haskell compilers. AFAIK, Hugs is 
written in plain C. NHC98, YHC, JHC, LHC and EHC/UHC are all written in 
Haskell. Most of these are "experimental" compilers that can't be used 
for production use. Only GHC is really "production-ready", and hence 
when people say "Haskell compiler" they almost always mean GHC.

Post a reply to this message

> If you're making something like an LCD mounting bracket, do you actually 
> do a detailed simulation for that component?

Only if it's in a place where someone could grab hold of it and tug it. 
Best example is when it's mounted sticking up from the top of the dashboard 
like this:

http://image.motortrend.com/f/9217160/112_0611_03z+2005_bmw_x3+interior_dash.jpg

It has to be able to withstand somebody grabbing hold of it and pulling to 
help themselves out of the car, in that case the metal is much thicker and 
we run finite element simulations to check.  It's further complicated 
because during an accident if someone hits the display it must collapse 
backwards and not be rigid, so you kind of need 1-way strength :-)

> Or do you just do "OK, well we're using 0.3 mm steel for the rest of the 
> frame, so let's use 0.3 mm steel"? (And change it if it turns out to be 
> too weak...)

For most other things, yes, or just based on our experience from the 100 
other LCDs we've made over the last 10 years.  On a recent project we had to 
change from 0.3 to 0.4 mm metal after some clips that were designed by the 
customer were not strong enough.  Nobody tested for this or simulated it, 
but to be honest there is no need as things like that always show up in the 
early samples before we get anywhere near making the mass production tools.

> The fun thing is if you want to ran GHC on an unsupported platform. This 
> apparently involves asking GHC to compile itself into ANSI C, and then 
> using a suitable C compiler for the target platform to produce a working 
> binary.

And I guess the C compiler can be cross-compiled on a pre-existing platform.

Post a reply to this message

>> If you're making something like an LCD mounting bracket, do you 
>> actually do a detailed simulation for that component?
> 
> Only if it's in a place where someone could grab hold of it and tug it. 

Figures.

> It has to be able to withstand somebody grabbing hold of it and pulling 
> to help themselves out of the car, in that case the metal is much 
> thicker and we run finite element simulations to check.

How long does it take to do a computer simulation to check that 
something won't break? How complicated is the process, and how much 
computer time does it take?

> It's further 
> complicated because during an accident if someone hits the display it 
> must collapse backwards and not be rigid, so you kind of need 1-way 
> strength :-)

So... corrugated? Or something.

>> Or do you just do "OK, well we're using 0.3 mm steel for the rest of 
>> the frame, so let's use 0.3 mm steel"? (And change it if it turns out 
>> to be too weak...)
> 
> For most other things, yes, or just based on our experience from the 100 
> other LCDs we've made over the last 10 years.

Heh, yeah. I guess if you've made something similar before it helps a 
lot. ;-) I was just thinking, I imagine for "most" manufactured items, 
the designers probably have a basic intuition about roughly what 
thickness of metal is required. I don't suppose they do an exhaustive 
mathematical derrivation of optimal thickness for every single component 
ever designed.

> On a recent project we 
> had to change from 0.3 to 0.4 mm metal after some clips that were 
> designed by the customer were not strong enough.  Nobody tested for this 
> or simulated it, but to be honest there is no need as things like that 
> always show up in the early samples before we get anywhere near making 
> the mass production tools.

Right. So you take an educated guess, and if the prototypes fall apart, 
you figure out which bit broke?

>> The fun thing is if you want to ran GHC on an unsupported platform. 
>> This apparently involves asking GHC to compile itself into ANSI C, and 
>> then using a suitable C compiler for the target platform to produce a 
>> working binary.
> 
> And I guess the C compiler can be cross-compiled on a pre-existing 
> platform.

Almost every platform known to man already has a C compiler - even if it 
has nothing else. The C compiler is typically the very first thing that 
gets built. ;-)

Itanium? Yep, that has a C compiler. UltraSPARC? Yeah, C compiler.

Post a reply to this message

> How long does it take to do a computer simulation to check that something 
> won't break? How complicated is the process, and how much computer time 
> does it take?

That sort of simulation is very quick and easy, only a few hours for a 
moderately complicated part and then you get back data about the stress at 
every point.

The harder simulations are the ones where you want to actually simulate some 
dynamic force (like your product being dropped on the floor) and then of 
course the simulator needs to deal with collisions and deformations.  These 
sorts of simulations can take a long time to set up and run for days just to 
simulate a fraction of a second.

> So... corrugated? Or something.

On the one I worked on we just bolted the base of the display to the car, 
and then had two hooks at the back half way up that hooked into the car 
mechanics (no screws).  That way when you pulled forward on the display the 
hooks provided the strength and stiffness, and if you pushed back the hooks 
did nothing so you were free to bend the bottom fixing points if you hit it 
hard enough.

> Heh, yeah. I guess if you've made something similar before it helps a lot. 
> ;-) I was just thinking, I imagine for "most" manufactured items, the 
> designers probably have a basic intuition about roughly what thickness of 
> metal is required. I don't suppose they do an exhaustive mathematical 
> derrivation of optimal thickness for every single component ever designed.

It depends on the product and how critical it is, plus how many you are 
making.  For something you are only making 1 of, like a bridge or a big 
building, you will probably do a lot of calculations.  If you are planning 
to make 10 million of something, you can probably just make a few hundred 
test samples and have chance to optmise them if needed.

> Right. So you take an educated guess, and if the prototypes fall apart, 
> you figure out which bit broke?

Yup, for car parts we usually have 3 rounds of prototypes before mass 
production starts.

> Almost every platform known to man already has a C compiler - even if it 
> has nothing else. The C compiler is typically the very first thing that 
> gets built. ;-)

Someone still has to build it though in the first place.

Post a reply to this message

>> How long does it take to do a computer simulation to check that 
>> something won't break? How complicated is the process, and how much 
>> computer time does it take?
> 
> That sort of simulation is very quick and easy, only a few hours for a 
> moderately complicated part and then you get back data about the stress 
> at every point.

Right. So not instantaneous, but not months of computer time either.

I take it there's more to it then just asking the computer "hey, will 
this break if I put 25 N through it?"

> The harder simulations are the ones where you want to actually simulate 
> some dynamic force (like your product being dropped on the floor) and 
> then of course the simulator needs to deal with collisions and 
> deformations.  These sorts of simulations can take a long time to set up 
> and run for days just to simulate a fraction of a second.

At what point does it become cheaper to just make the thing rather than 
simulate it?

>> So... corrugated? Or something.
> 
> On the one I worked on we just bolted the base of the display to the 
> car, and then had two hooks at the back half way up that hooked into the 
> car mechanics (no screws).  That way when you pulled forward on the 
> display the hooks provided the strength and stiffness, and if you pushed 
> back the hooks did nothing so you were free to bend the bottom fixing 
> points if you hit it hard enough.

Mmm, ingenious.

> It depends on the product and how critical it is, plus how many you are 
> making.  For something you are only making 1 of, like a bridge or a big 
> building, you will probably do a lot of calculations.  If you are 
> planning to make 10 million of something, you can probably just make a 
> few hundred test samples and have chance to optmise them if needed.

Well yeah, it's going to depend on how safety-critical it is. If you're 
making a coathanger, probably not much need to test it. If you're making 
a karabina... there are probably legal requirements for exhaustive testing.

>> Right. So you take an educated guess, and if the prototypes fall 
>> apart, you figure out which bit broke?
> 
> Yup, for car parts we usually have 3 rounds of prototypes before mass 
> production starts.

One thing I always wondered... You see people doing all these crash 
tests, right? So... where the hell do you get an endless supply of red 
cars to crash into things?!

>> Almost every platform known to man already has a C compiler - even if 
>> it has nothing else. The C compiler is typically the very first thing 
>> that gets built. ;-)
> 
> Someone still has to build it though in the first place.

Sure. But not the Haskell development team. ;-)

I would think it's by a cross-compiler though, yes. Indeed, some systems 
are "too small" to run a C compiler natively, so you *must* cross-compile.

Post a reply to this message

Invisible wrote:

> myself. OTOH, I have yet to write a working Tic-Tac-Toe program, so... 
> maybe not. :-/

I did that in grade school. :) It was unbeatable.

-- 
~Mike

Post a reply to this message

>> myself. OTOH, I have yet to write a working Tic-Tac-Toe program, so... 
>> maybe not. :-/
> 
> I did that in grade school. :) It was unbeatable.

The hard part is figuring out how to draw the graphics on screen and 
register the mouse clicks. Usually you have to mutilate your program to 
fit the window manager's event loop...

Post a reply to this message

> The hard part is figuring out how to draw the graphics on screen

Choose a language / IDE / API that gives you easy access to graphics?

>  and register the mouse clicks.

Ditto.

> Usually you have to mutilate your program to fit the window manager's 
> event loop...

Don't see how, if you have written functions like:
MouseClicked(int xpixel , int ypixel)
RedrawScreen()
etc, you just need to call them in response to the correct window manager 
messages.  Of course if you write the whole game as just a big long chunk of 
code you are going to find it hard to fit it in with a window manager.

BTW why don't you just do a text based version?

Post a reply to this message