Xach requested better error reporting from load-foreign-library, so please review this patch
On Sun, Dec 18, 2011 at 4:13 AM, Stelian Ionescu sionescu@cddr.org wrote:
Xach requested better error reporting from load-foreign-library, so please review this patch
So now we consistently get a load-foreign-library-error instead of getting a simple-error for some of the errors. Storing the pathname in the error seems like a good idea too. Is there a specific use-case that motivated that change? I'm asking because it's not populated correctly in the try-foreign-library-alternatives case, and it's not clear what should go there in that case. Perhaps we should store something else? (The foreign-library object perhaps?)
Luís Oliveira luismbo@gmail.com writes:
On Sun, Dec 18, 2011 at 4:13 AM, Stelian Ionescu sionescu@cddr.org wrote:
Xach requested better error reporting from load-foreign-library, so please review this patch
So now we consistently get a load-foreign-library-error instead of getting a simple-error for some of the errors. Storing the pathname in the error seems like a good idea too. Is there a specific use-case that motivated that change? I'm asking because it's not populated correctly in the try-foreign-library-alternatives case, and it's not clear what should go there in that case. Perhaps we should store something else? (The foreign-library object perhaps?)
The use-case I had in mind was an environment that caught the error and offered a useful action, e.g. "install the library via apt/homebrew/macports/etc and continue".
Zach
On Sun, Dec 18, 2011 at 12:17 PM, Zach Beane xach@xach.com wrote:
The use-case I had in mind was an environment that caught the error and offered a useful action, e.g. "install the library via apt/homebrew/macports/etc and continue".
OK, and so you'd like to get a hold of "/maybe/some/path/to/libfoo.so.x" or whatever. Hmm, so maybe in try-foreign-library-alternatives we could store the first alternative since that should usually be something like "libfoo.so.x".
What do you think Stelian? (Also, did I miss any other improvements introduced by this patch?)
Luís Oliveira luismbo@gmail.com writes:
On Sun, Dec 18, 2011 at 12:17 PM, Zach Beane xach@xach.com wrote:
The use-case I had in mind was an environment that caught the error and offered a useful action, e.g. "install the library via apt/homebrew/macports/etc and continue".
OK, and so you'd like to get a hold of "/maybe/some/path/to/libfoo.so.x" or whatever. Hmm, so maybe in try-foreign-library-alternatives we could store the first alternative since that should usually be something like "libfoo.so.x".
It would be nice to have all the alternatives.
Zach
On Sun, Dec 18, 2011 at 12:40 PM, Zach Beane xach@xach.com wrote:
OK, and so you'd like to get a hold of "/maybe/some/path/to/libfoo.so.x" or whatever. Hmm, so maybe in try-foreign-library-alternatives we could store the first alternative since that should usually be something like "libfoo.so.x".
It would be nice to have all the alternatives.
We could store the definition s-exp.
;;; (define-foreign-library opengl ;;; (:darwin (:framework "OpenGL")) ;;; (:unix (:or "libGL.so" "libGL.so.1" ;;; #p"/myhome/mylibGL.so")) ;;; (:windows "opengl32.dll") ;;; ;; an hypothetical example of a particular platform ;;; ((:and :some-system :some-cpu) "libGL-support.lib") ;;; ;; if no other clauses apply, this one will and a type will be ;;; ;; automagically appended to the name passed to :default ;;; (t (:default "libGL")))
In this case, the error's LIBRARY-SPECIFICATION slot (or something along those lines), could hold a string, a pathname, or s-exps whose CARs are one of :OR, :DEFAULT, or :FRAMEWORK.
But it's a bit messy. Wouldn't it be easier to deal with a single string? At first sight, it seems unlikely that some of the alternatives in an :OR clause would hold more project information than others. (Except perhaps for the version, which should be in the first alternative, but sometimes isn't.)
In this example, said string would be "/path/to/OpenGL.framework/something/something.dylib", "libGL.so", "opengl32.dll" on OS X, Unix, and Windows, respectively.
Luís Oliveira luismbo@gmail.com writes:
On Sun, Dec 18, 2011 at 12:40 PM, Zach Beane xach@xach.com wrote:
OK, and so you'd like to get a hold of "/maybe/some/path/to/libfoo.so.x" or whatever. Hmm, so maybe in try-foreign-library-alternatives we could store the first alternative since that should usually be something like "libfoo.so.x".
It would be nice to have all the alternatives.
We could store the definition s-exp.
;;; (define-foreign-library opengl ;;; (:darwin (:framework "OpenGL")) ;;; (:unix (:or "libGL.so" "libGL.so.1" ;;; #p"/myhome/mylibGL.so")) ;;; (:windows "opengl32.dll") ;;; ;; an hypothetical example of a particular platform ;;; ((:and :some-system :some-cpu) "libGL-support.lib") ;;; ;; if no other clauses apply, this one will and a type will be ;;; ;; automagically appended to the name passed to :default ;;; (t (:default "libGL")))
In this case, the error's LIBRARY-SPECIFICATION slot (or something along those lines), could hold a string, a pathname, or s-exps whose CARs are one of :OR, :DEFAULT, or :FRAMEWORK.
But it's a bit messy. Wouldn't it be easier to deal with a single string? At first sight, it seems unlikely that some of the alternatives in an :OR clause would hold more project information than others. (Except perhaps for the version, which should be in the first alternative, but sometimes isn't.)
In this example, said string would be "/path/to/OpenGL.framework/something/something.dylib", "libGL.so", "opengl32.dll" on OS X, Unix, and Windows, respectively.
Ok, that makes sense, and seems sufficient to find a missing library in some system-specific database.
Zach
Luís Oliveira luismbo@gmail.com writes:
OK, and so you'd like to get a hold of "/maybe/some/path/to/libfoo.so.x" or whatever. Hmm, so maybe in try-foreign-library-alternatives we could store the first alternative since that should usually be something like "libfoo.so.x".
It would be nice to have all the alternatives.
We could store the definition s-exp.
[...]
In this case, the error's LIBRARY-SPECIFICATION slot (or something along those lines), could hold a string, a pathname, or s-exps whose CARs are one of :OR, :DEFAULT, or :FRAMEWORK.
When we want to provide a restart for automatic library installation, the most useful thing is a list of *all pathnames actually tried*.
We know that before the error is signalled, every pathname possible (for current implementation's feature set) has been tried. Collecting them along the way shouldn't be hard. And I can't think of an "auto-installer" (or anything external to CFFI) for which the details of *why* those pathnames were used are somehow relevant.
(OTOH, :framework looks like an ugly special case w.r.t. my suggestion above)
On Sun, Dec 18, 2011 at 1:36 PM, Anton Kovalenko anton@sw4me.com wrote:
In this case, the error's LIBRARY-SPECIFICATION slot (or something along those lines), could hold a string, a pathname, or s-exps whose CARs are one of :OR, :DEFAULT, or :FRAMEWORK.
When we want to provide a restart for automatic library installation, the most useful thing is a list of *all pathnames actually tried*.
We know that before the error is signalled, every pathname possible (for current implementation's feature set) has been tried. Collecting them along the way shouldn't be hard. And I can't think of an "auto-installer" (or anything external to CFFI) for which the details of *why* those pathnames were used are somehow relevant.
Excellent point. I like this solution.
-
Anton Kovalenko -
Luís Oliveira -
Stelian Ionescu -
Zach Beane