Hello, "Neil Jerram" <[EMAIL PROTECTED]> writes:
>>> + SCM_VALIDATE_INT_COPY (1, d1, y1); >>> + SCM_VALIDATE_INT_COPY (2, d2, y2); >>> + >>> + calibrated_m = ((double) (y2 - y1)) / (x2 - x1); >>> + calibrated_c = ((double) y2) - calibrated_m * x2; >> >> Shouldn't it be: >> >> calibrated_c = y1 - x1; > > No, don't think so! My model equation is y = mx + c, so c = y - mx. Hmm, OK. >> Could it be moved to a `%print-stack-calibration' function that we'd use >> for troubleshooting? > > Yes. In the attached patch, I've left this out completely, but I > think we should add it back in as %get-stack-calibration. Yes. > I've done this part a bit differently - see the libguile/Makefile.am > changes - because I couldn't see exactly how the recursive make > approach would work. If you think recursive make would be > significantly better, can you describe or propose the detailed changes > that would be needed? Your proposition looks very good actually. I suppose the generated makefile doesn't require recompilation of all `.lo' files to go from `libuguile' to `libguile', right? I'm not sure about cross-compilation (Dale Smith had also raised this issue on IRC some time ago). IIUC, the user is expected to provide a `UGUILE_FOR_BUILD' at configure-time, which is then used to run `calibrate.scm'; however, `UGUILE_FOR_BUILD' runs on the host, not the target system, so the generated file will be erroneous, right? Thus, when cross-compiling, shouldn't we avoid stack calibration altogether and simply emit a warning a configure-time, for instance? At any rate, it's not a problem when cross-compiling with tools like Scratchbox, which actually "hide" the fact that we're cross-compiling and can run executables for the target system through an emulator. Thanks for your work! Ludo'.
