Re: [clisp-list] gdi inclusion

[Reini U. <ru...@x-...>]

Hoehle, Joerg-Cyril schrieb:
> BTW, is somebody using :language :stdc-stdcall on MS-Windows??
> I see it in every definition in CormanLisp examples, but I don't have 
 > it seen yet in CLISP code written by users or developers.

because it's in only used in the WinAPI.
   don't know of any useful pascal dll's :)

And the WinAPI coverage is quite ok with the static gdi and win32 bindings.

> As far as including Dan's gdi into the core distribution, that's fine with me :-)

good!

>>sooner or later jörg's dynamic ffi (new uffi.lisp pending) can be used 
>>to call the winapi, but having them in stone is much more convenient.
> 
>dynamic FFI and UFFI are different things.
>The dynamic FFI (if you mean shared libraries) is there in CVS (and maybe also 
 >the last release?). You can use def-call-out (:library "fooname/path").

> Sam has started adding modules/bindings/win32.lisp which contains
> some  functions of kernel32.dll or whatever he feels the need to add. It's in
> CVS (quite small right now).
> You may wish to contribute to that.

Not enough time, sorry.
I wanted to try out garnet for some demo also.

> I wouldn't count on UFFI to call the winapi. Why do you? What do you expect?
> I cannot guarantee that using UFFI won't introduce even more run-time overhead (make things slower).

Slowness is not the problem. To make it fast just link it.

> As an example, clsql has lots of
>      (let ((info-ptr (allocate-foreign-string 1024))) 
>        (with-foreign-object (info-length-ptr :short)
>           ...
> 	     (SQLGetInfo hdbc info-type info-ptr 1023 info-length-ptr)
> 	   (let ((info (convert-from-foreign-string info-ptr)))
> 	     (free-foreign-object info-ptr)
> Ever read performance benchmarks all showing how slow malloc() is?

I don't care that much about temp. malloc'ed heap space, compared to the 
native advantages. it should just work. :) local optimizations later.
of course :out is much better.

but thanks for the nice examples!

>As the function is always called with the same buffer size, it 
 >would be much more efficient and also convenient in CLISP to write
 >it using :out parameters as:
> (ffi:def-call-out SQLGetInfo-string (:name "SQLGetInfo")
>   (:library "odbc32.dll") (:language :stdc-stdcall)
>   (:arguments
>    (hdbc ffi:c-pointer)
>    (finfotype ffi:sint16)
>    (rgbinfovalue (c-ptr (c-array-max character 1024)) :out)
>    (cbinfovaluemax ffi:sint16)		;pass 1023
>    (*pcbinfovalue (c-ptr sint16) :out))
>  (:return-type ffi:sint16))
> 
> call (SQLGetInfo hdbc info-type 1023)
> and extract string (using nth-value)
> 
> (ffi:def-call-out SQLGetInfo-short (:name "SQLGetInfo")
>   (:library "odbc32.dll") (:language :stdc-stdcall)
>   (:arguments
>    (hdbc ffi:c-pointer)
>    (finfotype ffi:sint16)
>    (rgbinfovalue (c-ptr sint16) :out)
>    (cbinfovaluemax ffi:sint16)		;pass (sizeof 'sint16)
>    (*pcbinfovalue (c-ptr sint16) :out))
>  (:return-type ffi:sint16))
> call (SQLGetInfo hdbc info-type (ffi:sizeof 'sint16))
> and extract short value (using nth-value again)
> 
> (def-call-cout SQLGetInfo-long ...)
> ;same exercise, use (load-time-value (ffi:sizeof '#.$ODBC-LONG-TYPE))
> or just #.(ffi:sizeof '$ODBC-LONG-TYPE)
> 
>[Actually, load-time-value is much, much better than #.(sizeof #),
>because it may allow you to use the same .fas files across different
>machines if you're careful -- (sizeof 'int) depends on the run-time
>CLISP, not the compilation environment. And load-time-value is efficient
>as well.]

> UFFI must go through either foreign-allocate or with-foreign-object, and both mean overhead. How much depends on the application.

well, you could pre-allocate the foreign buffers advance.
the real problem is, if the foreign objects persist when loading a image.
that's why we have the static bindings to postgresql :)
we don't have to care.

> When I have time, I'd like to compare pgsql.lisp with clsql-postgresql and clsql-postgresql-socket speed wise in CLISP.
> It's likely to yield different speed ratios than native-code compilers.

that's fine. I haven't considered ken's uffi2 motivations and problems yet.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/