Just a warning for those who are considering upgrading their existing
systems from either ACL3 (on MS Windows) or ACL4 (on Unix) to the new
ACL5 (on MS Windows or Unix).
If your existing code includes a large amount of foreign function
calls you may want to watch out for the following bugs in ACL5's
compatibility packages. For some reason, Franz deliberately
withhold information (and fixes/work-arounds) about _known_
compatibility problems from their customers, including those with
maintenance contracts. Why are they doing this? The reason given to me
is "to encourage migration to ACL5's new foreign function mechanism!"
After years of having to deal with two incompatible foreign function
mechanisms in the MS Windows versus Unix versions of their Lisp
systems, they have now created yet another different one in ACL5. At
least it is now common across platforms. Anyway, I find it appalling
that they let every customer contemplating an upgrade run into the
same known problems, when they could easily document these issues.
Here are the two issues I've encountered so far:
When upgrading ACL3 code the compatibility package doesn't accept
argument types with double indirection, e.g. the following doesn't
work in ACL5.0:
(ct:defun-dll fun ((foo ((:void *) *)))
:entry-name "cfun"
:library-name "c.dll"
:return-type :short)
They say this will be fixed in the next dot release, but have neither
posted a patch nor included a description of the problem and
work-around in the FAQ document. Until this is fixed, the workaround
is to separately define a type name for the pointer and use that type
name in the declaration of the function (that's what they say, I
haven't tried this yet).
Now to the second problem:
ACL5 has a lot more in common with ACL4 than with ACL3, hence for
people who have code for both ACL3 and ACL4 it makes sense to base
their ACL5 projects on the ACL4 code even on the MS Windows platform
where ACL4 itself was never available. Conveniently, the ACL5/4 FFI
compatibility package is available on the Windows platform.
There is, however, an undocumented problem with 16bit return
values. Apparently, such 16bit return values, typically of C type
short or unsigned short, when declared as :fixnum in the ACL4 FFI
worked correctly. This still works in ACL5 on Unix platforms, at least
that's what I'm told. When you try this on MS Windows, however, the
function returns garbage. The work-around for (signed) short is to use
the undocumented return type declaration :signed-short. For unsigned
short one must stick with :fixnum and then fixup the returned value
manually using (logand value #xffff).
Good luck, Joachim
--
·······@kraut.bc.ca (http://www.kraut.bc.ca)
·······@mercury.bc.ca (http://www.mercury.bc.ca)