[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SchemeQL




For what it's worth, on Friday I confirmed that there is in fact a
*general* linkage problem in SchemeQL; at this point, however, I think the
actual defect may be inside MzScheme itself. Given the movement away from
units, however, I'm not so sure that the PLT Scheme team will be interested
in tracking down the root cause... And, what's more, I think it would be up
to us to do a better job of describing the problem. That may take more time
than anyone is willing to put in.

What I discovered is this: if in schemeqlr.ss you comment out all of the
"cond" clauses for odbc-version < 3.0, you get different behaviour; not
correct behaviour, but different--you no longer get the "get-diag-rec not
defined"  message, you now get "uncaught exception." However, all I did was
to comment out "cond" clauses that shouldn't have even been executed! So I
think there's actually a problem with the way the "unit/sig" form works--or
something like that.

The other thing I discovered is that no matter what odbc-version you
declare, you actually only get srpersist 1.0! The reason you don't notice
that is that the only difference between srpersist 1.0 and 2.0 is two new
primitives--and those two primitives aren't, as far as I could tell, used
by SchemeQL. Good thing, 'cause they aren't available. (The right branch of
all code gets executed; it's just that only the 1.0 primitives are
available.)

There are three possible culprits: SrPersist, SchemeQL, and MzScheme.

I think the first step would be to verify that you can in fact use
SrPersist as a unit within a compound unit--getting the correct version
along the way. (Because of its ODBC versioning issues, SrPersist does
things I haven't seen any other collection do.) If that works, presumably
the next step would be simplifying the way that SchemeQL calls SrPersist; I
achieved that by separating the elements of schemeqlr.ss into separate
files, one for each version. And if that doesn't work, maybe the issue is
in MzScheme... Though the real reasons I suspect MzScheme is the example I
gave above, where commenting out unused "cond" clauses changed the output
of the unit.

As I said, I don't know if anyone wants to put in that kind of time though!