Yaroslav Kavenchuk wrote:
Oops, if use libintl_sprintf instead of sprintf - all works: Hmm. I do not know why sprintf function does not work in clisp/mingw.
if define sprintf as function from msvcrt.dll - all works:
Oh boy!
Why there is no opportunity to specify from what library link function?
You probably mean in CFFI? UFFI has :module and CLISP has :library
And if I shall link some libraries with identical names of functions - what to do?
"Implementation-dependent" and underspecified On many UNIX systems, the more recently opened libraries probably shadow older ones. Now, do you know in which order the libraries where opened? The general answer is "no". E.g. did you read somewhere in clisp impnotes in what order it's reopening libraries when restarting from an image? Do you know what libraries got loaded in what order, when you're just a library programmer and don't know what the user is doing (and what s/he loaded)? No, you don't.
There are several reasons why I prefer programmers to state which library or module thex expect a function to come from. It helps do the right thing. (But the most important reason back in 1995 was that the Amiga had no introspection of shared libraries. You *had* to tell you want e.g. Close from *that* specific library, and it was a reasonably way to avoid conflicts).
I do not know what library contains bad sprintf function.
Maybe you can figure it out using (foreign-address #<foreign-function>) and see if you can relate that to the addresses of the .dll loaded into the current process?
Regards, Jorg Hohle
Hoehle, Joerg-Cyril wrote:
Why there is no opportunity to specify from what library link function?
You probably mean in CFFI? UFFI has :module and CLISP has :library
CFFI of course
And if I shall link some libraries with identical names of functions - what to do?
"Implementation-dependent" and underspecified
<skip>
no perfection in the world :(
I do not know what library contains bad sprintf function.
Maybe you can figure it out using (foreign-address #<foreign-function>) and see if you can relate that to the addresses of the .dll loaded into the current process?
I shall try...
Thanks!
Yaroslav Kavenchuk kavenchuk@jenty.by writes:
Hoehle, Joerg-Cyril wrote:
And if I shall link some libraries with identical names of functions - what to do?
"Implementation-dependent" and underspecified
no perfection in the world :(
I would like, eventually, to extend CFFI to allow for this case, as it would come up all the time in a program that wanted to load "plugin" style shared objects.
For example, one way to handle this would be for LOAD-FOREIGN-LIBRARY to return a cookie that can be used to refer to a specific shared library. Then, functions defined with DEFCFUN could take an extra :library keyword argument that would be used to specify which library to resolve the function in. (We'd need a way to extend FOREIGN-FUNCALL to do this too: probably a FOREIGN-FUNCALL-IN-LIBRARY operator or something.)
I'm not sure what the status of implementation support on something like this would be...
James
I do not know what library contains bad sprintf function.
Maybe you can figure it out using (foreign-address #<foreign-function>) and see if you can relate that to the addresses of the .dll loaded into the current process?
I have found it! This is ntdll.dll (in this library still more many other functions). F&%k!
It is caused from ole32.dll.
win32 *.dll hell...
Use CFFI with Windows without cpecification of library is problematic :(
Thanks!
On 2006-jan-06, at 10:48, Yaroslav Kavenchuk wrote:
Use CFFI with Windows without cpecification of library is problematic :(
Try (cffi:load-foreign-library "msvcrt.dll") before trying to call sprintf or something standard C function. That should work.
Luís Oliveira wrote:
On 2006-jan-06, at 10:48, Yaroslav Kavenchuk wrote:
Use CFFI with Windows without cpecification of library is problematic :(
Try (cffi:load-foreign-library "msvcrt.dll") before trying to call sprintf or something standard C function. That should work.
[1]> (asdf:operate 'asdf:load-op 'cffi) ... NIL [2]> (cffi:load-foreign-library "msvcrt.dll") #<FOREIGN-POINTER #x78000000> [3]> (in-package :cffi) #<PACKAGE CFFI> CFFI[4]> (with-foreign-pointer-as-string (s 100) (setf (mem-ref s :char) 0) (foreign-funcall "sprintf" :pointer s :string "%.2f" :double (coerce pi 'double-float) :void)) "4{Ъ↓сЭI"
:(
Luís Oliveira wrote:
On 2006-jan-06, at 10:48, Yaroslav Kavenchuk wrote:
Use CFFI with Windows without cpecification of library is problematic :(
Try (cffi:load-foreign-library "msvcrt.dll") before trying to call sprintf or something standard C function. That should work.
In current time all libraries (msvcrt and ntdll) are already loaded. I cannot operate the order of their loading.
Thanks!
Yaroslav Kavenchuk kavenchuk@jenty.by writes:
I do not know what library contains bad sprintf function.
Maybe you can figure it out using (foreign-address #<foreign-function>) and see if you can relate that to the addresses of the .dll loaded into the current process?
I have found it! This is ntdll.dll (in this library still more many other functions). F&%k!
It is caused from ole32.dll.
win32 *.dll hell...
Use CFFI with Windows without cpecification of library is problematic :(
Hmm, that sounds awful.
What sort of interface should CFFI export for this? I've been reluctant to add this because several Lisps don't support it at all, but perhaps silently ignoring :LIBRARY options on those implementations and proceeding with the global lookup is okay for now...
If we added an option syntax to DEFCFUN (I know everyone hates this syntax, but it's backwards compatible), we could have something like:
(defcfun "sprintf" :int :library "msvcrt.dll" (fmt :string) ...)
If we want to break everyone and change the syntax of DEFCFUN, we can make it look like DEFCLASS:
(defcfun "sprintf" :int ((fmt :string) ...) (:library "msvcrt.dll"))
Or, for a completely different approach, what about:
(with-default-library ("msvcrt.dll") (defcfun "sprintf" :int (fmt :string) ...))
Thoughts?
James
On Fri, 2006-01-06 at 03:41 -0800, James Bielman wrote:
If we added an option syntax to DEFCFUN (I know everyone hates this syntax, but it's backwards compatible), we could have something like:
(defcfun "sprintf" :int :library "msvcrt.dll" (fmt :string) ...)
Thoughts?
I forget whether define-foreign-library will have a Lisp name, but if so, it would be nice for :library to accept this as well. Of course, CLISP's :library option is unevalled ....
Am 06.01.2006 um 12:41 schrieb James Bielman:
Yaroslav Kavenchuk kavenchuk@jenty.by writes:
I do not know what library contains bad sprintf function.
Maybe you can figure it out using (foreign-address #<foreign-function>) and see if you can relate that to the addresses of the .dll loaded into the current process?
I have found it! This is ntdll.dll (in this library still more many other functions). F&%k!
It is caused from ole32.dll.
win32 *.dll hell...
Use CFFI with Windows without cpecification of library is problematic :(
Hmm, that sounds awful.
What sort of interface should CFFI export for this? I've been reluctant to add this because several Lisps don't support it at all, but perhaps silently ignoring :LIBRARY options on those implementations and proceeding with the global lookup is okay for now...
This sounds OK for me, really.
If we added an option syntax to DEFCFUN (I know everyone hates this syntax, but it's backwards compatible), we could have something like:
(defcfun "sprintf" :int :library "msvcrt.dll" (fmt :string) ...)
Looks OK.
If we want to break everyone and change the syntax of DEFCFUN, we can make it look like DEFCLASS:
(defcfun "sprintf" :int ((fmt :string) ...) (:library "msvcrt.dll"))
Looks better.
Or, for a completely different approach, what about:
(with-default-library ("msvcrt.dll") (defcfun "sprintf" :int (fmt :string) ...))
Handy...
Let's do the Better and Handy approaches - just my vote. And yes, I think it is OK to "break everyone" because we do version CFFI and also because there's not that many CFFI based packages out there yet (ouch - that might get some serious reponses ;-)
Thoughts?
Yeah, these were mine. Glad someone works on this now. I really had a hard time with these issues and would love to see a clean solution.
Thanks for your work and ideas.
Frank
-
Frank Goenninger - PRION Consulting -
Hoehle, Joerg-Cyril -
James Bielman -
Luís Oliveira -
Stephen Compall -
Yaroslav Kavenchuk