James Bielman wrote:
I've released the current darcs version of CFFI as 0.9.0. The darcs tree has been tagged and checkpointed
You should do that more often, because it creates shorter patch files. Previously, a tiny 10 line patch had 40KB worth of context. That is gone since you tagged cffi recently. Context is now much smaller.
I consider this the "beta" release leading up to a real 1.0 version.
Of course, you're free to tag any version with any number you like. Here are points I'd like to see addressed:
1. IMHO CFFI should not go 1.0 prior to acknowledging that there's a relationship between functions and libraries (i.e. UFFI's :module keyword). Arseny has a case on MS-Windows where there are two versions of sprintf in different MS .dlls. One does not pass some tests, the other does.
So far, CFFI does not allow the user to control which functions gets loaded from there. I consider this a *huge* misfeature.
2. I suggest you add the block operations API with my suggestions (from monthes ago). It's trivial to implement naively, and it would do users good to be able to use it (even CFFI code can benefit from it, there currently are a few block loops here and there). Later CVS versions may then add optimized versions for special cases.
3. (trivial): provide a uffi.asd file in a subdirectory, so people can load that and play with programs using ASDF and UFFI. A system named uffi-compat is IMHO useless, because these programs have ASDF look for a system named #:uffi.
Regards, Jorg
On 2/22/06, Hoehle, Joerg-Cyril Joerg-Cyril.Hoehle@t-systems.com wrote:
Of course, you're free to tag any version with any number you like. Here are points I'd like to see addressed:
[snip]
May I add:
4. support stdcall in addition to the cdecl calling convention.
I know this was briefly discussed once before. The lack of stdcall has caused both CLISP and LispWorks to crash for me when I use the Win32 EnumChildWindows API function, which takes a callback that must be declared as stdcall [1] I can provide a self-contained testcase that demonstrates the problem, if that would be helpful.
I am currently using the obvious workaround right now of coding directly to the vendor FFI for this case.
One the one hand, I think this is also something that could be addressed prior to 1.0, but on the other hand, I personally can continue with my workaround. It's more a question of how many other folks are affected by this.
-- Jack Unrue
[1] Win32 window procedures are also supposed to be declared stdcall, but due to luck, I have been able to get away with cdecl in this case.
On 2006-feb-23, at 01:17, Jack Unrue wrote:
[1] Win32 window procedures are also supposed to be declared stdcall, but due to luck, I have been able to get away with cdecl in this case.
Not due to luck, but due to ugly hacks. :-)
http://blogs.msdn.com/oldnewthing/archive/2004/01/15/58973.aspx
On 2/22/06, Luís Oliveira luismbo@gmail.com wrote:
On 2006-feb-23, at 01:17, Jack Unrue wrote:
[1] Win32 window procedures are also supposed to be declared stdcall, but due to luck, I have been able to get away with cdecl in this case.
Not due to luck, but due to ugly hacks. :-)
http://blogs.msdn.com/oldnewthing/archive/2004/01/15/58973.aspx
Thanks Luís :-) Silly me, I didn't think to search Raymond's blog for this. Ugly indeed.
-- Jack Unrue