contrast to former versions) someday be capable of returning things
like SQL_TIME_STRUCT, SQL_DATE_STRUCT, SQL_TIMESTAMP_STRUCT and
SQL_NUMERIC_STRUCT.
+ However, SQLGetData() is now even more broken than before (if used
on integer columns). It seems, that I failed to understand the API
reference on SQLGetData() completly!
RX syntax. Namely, a lot of code (used to) assume(s) that the
total-number-of-submatches (TSM) quantity is static even for dynamic
regexps.
Specifically, RE-TSM now returns an unspecific value instead of 0 for
non-regexps which should break most of the code that used to just
silently do the wrong thing. It's likely that more examples involving
dynamic sub-regexps will fail.
In the process, I also removed some of Olin's naming craziness (using
"%" signs to convey meaning) which I needed to do to halfway
understand what's going on.
opened by open-input-string could be closed by the GC before the exec().
Now << stores the port in a global variable.
The test to reveal the bug was:
(let lp ()
(run (head) (<< "a"))
(lp))
printing a "closed channel" message after some a few hundred interations.
- dynamic memory allocation for return values in these functions:
- odbc_sql_get_info_string()
- odbc_sql_get_connect_attr_string()
- odbc_sql_get_stmt_attr_string()
- odbc_sql_get_desc_field_string()
- odbc_sql_get_cursor_name()
- odbc_sql_native_sql()
- odbc_sql_get_data()
- odbc_sql_describe_col()
- odbc_sql_get_diag_recs()
- odbc_sql_data_sources() is still broken: sometimes the result string
is truncated. I'm not sure if this not a unixODBC-bug...
- Don't call SQLGetDiagRec() automatically on SQL_ERROR, some ODBC
seem to have a broken SQLGetDiagRec() implementation. Let user call
SQLGetDiagRec() from Scheme at his own risk.
The ODBC documentation thinks it's a good idea to call SQLGetDiagRec()
after each ODBC-call that might return SQL_SUCCESS_WITH_INFO. IMHO
this sucks. However it's now possible to do so in the user's Scheme
code.
(environment-handle, connection-handle, statement-handle,
database-handle)
- make ODBC functions these records
- Tons of constants for SQLGetInfo()
- get rid of some stupid pseudo-highlevel-ODBC-functions
- extend the VM interrupts to distinguish between read and write
events
- add new ADD-PENDING-CHANNEL instruction to the VM
- add WAIT-FOR-CHANNELS procedure to the run-time system
- implement SELECT and SELECT! on top of that in newports.scm
This runs some basic tests, but in general should be considered
largely untested.
Moreover, SELECT/SELECT! never detect any exceptional conditions---the
returned vectors are always empty. This is because the VM doesn't
really track those, and it's unclear whether it would be worth the
effort.
sperber